Software Engineering

BS (Computer Science)

Lecture-03(a)
Date: 13-10-2012

Dr. S.N Ahsan

1

Phases of Software Life Cycle

Definition

Phase - behavior of the system Development Phase - How to obtain the desired behavior Maintenance - change the behavior Corrective - fix uncovered defect Adaptive - Platform change Enhancement - Perfective, additional functionality Preventive - re-engineering, make system more maintainable

31.03.2014

Dr. S. N Ahsan, IQRA-University

Software Engineering
1. 2.

Software Construction Software Management

08.10.2011

Dr. S. N Ahsan, IQRA-University

Software Common Process Framework

A common process framework is established by defining a small number of framework activities that are applicable to all software projects, regardless of their size or complexity.
08.10.2011 Dr. S. N Ahsan, IQRA-University 4

A Generic Process Framework

1. 2. 3. 4.

5.

Communication Planning Modeling Construction Deployment

08.10.2011

Dr. S. N Ahsan, IQRA-University

Umbrella Activities
1. 2. 3. 4.

5.
6. 7.

8.

Software Project Tracking and Control Risk Management Software Quality Assurance Technical Reviews Measurements Software Configuration Management Reusability Management Work Product Preparation and Production
08.10.2011 Dr. S. N Ahsan, IQRA-University 6

Process Flow
1. 2. 3. 4.

Linear Process Flow Iterative Process Flow Evolutionary Process Flow Parallel Process Flow

08.10.2011

Dr. S. N Ahsan, IQRA-University

Software Process Models

Prescriptive Process Models

1. Waterfall model (Royce, 1970)
V-Model: The V-model depicts the relationship of quality assurance actions to the actions associated with the different step of waterfall model

2. 3.

Incremental Process Models Evolutionary Process Models

Prototyping Spiral model (Boehm, 1988)

4.

Concurrent Models Component Based Development The Formal Methods Model Aspect Oriented Software Development

Specialized Process Models

1. 2. 3.

The Unified Process

08.10.2011 Dr. S. N Ahsan, IQRA-University 8

PRESCRIPTIVE-MODEL

Prescriptive Process Models

Developed

to bring order and structure to the software development process. To get away from the chaos of most development processes. But there is a strange balance between order and chaos. Absolute order means absence of variability. Absolute chaos makes coordination and coherence impossible. Thus, a balance is needed.

08.10.2011

Dr. S. N Ahsan, IQRA-University

10

Waterfall Model
Requirements

Design

Implementation

Testing

Maintenance

08.10.2011

Dr. S. N Ahsan, IQRA-University

11

Waterfall Strengths

Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

08.10.2011

Dr. S. N Ahsan, IQRA-University

12

Waterfall Deficiencies

All requirements must be known upfront The following phase should not start until the previous phase has finished. Deliverables created for each phase are considered frozen inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)
08.10.2011 Dr. S. N Ahsan, IQRA-University 13

When to use the Waterfall Model

Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform.

08.10.2011

Dr. S. N Ahsan, IQRA-University

14

V-Shaped SDLC Model

A variant of the Waterfall that emphasizes the verification and validation of the product. Testing of the product is planned in parallel with a corresponding phase of development

08.10.2011

Dr. S. N Ahsan, IQRA-University

15

V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product development Each deliverable must be testable Project management can track progress by milestones Easy to use

08.10.2011

Dr. S. N Ahsan, IQRA-University

16

V-Shaped Weaknesses
Does not easily handle concurrent events Does not handle iterations or phases Does not easily handle dynamic changes in requirements Does not contain risk analysis activities

08.10.2011

Dr. S. N Ahsan, IQRA-University

17

When to use the V-Shaped Model

Excellent choice for systems requiring high reliability hospital patient control applications All requirements are known up-front When it can be modified to handle changing requirements beyond analysis phase Solution and technology are known

08.10.2011

Dr. S. N Ahsan, IQRA-University

18

Incremental Development Model

08.10.2011

Dr. S. N Ahsan, IQRA-University

19

Incremental Model Strengths

Develop high-risk or major functions first Each release delivers an operational product Customer can respond to each build Uses divide and conquer breakdown of tasks Lowers initial delivery cost Initial product delivery is faster Customers get important functionality early Risk of changing requirements is reduced

08.10.2011

Dr. S. N Ahsan, IQRA-University

20

Incremental Model Weaknesses

Requires good planning and design Requires early definition of a complete and fully functional system to allow for the definition of increments Well-defined module interfaces are required (some will be developed long before others) Total cost of the complete system is not lower

08.10.2011

Dr. S. N Ahsan, IQRA-University

21

When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of benefits. Most of the requirements are known up-front but are expected to evolve over time A need to get basic functionality to the market early On projects which have lengthy development schedules On a project with new technology

08.10.2011

Dr. S. N Ahsan, IQRA-University

22

RAD Model
Rapid Application Development an incremental model that emphasizes a short development cycle. Uses component-based construction method. Does not work for all projects particularly large projects or when project is high risk.

08.10.2011

Dr. S. N Ahsan, IQRA-University

23

RAD Strengths

Reduced cycle time and improved productivity with fewer people means lower costs Time-box approach mitigates cost and schedule risk Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs Focus moves from documentation to code (WYSIWYG). Uses modeling concepts to capture information about business, data, and processes.

08.10.2011

Dr. S. N Ahsan, IQRA-University

24

RAD Weaknesses

Accelerated development process must give quick responses to the user Risk of never achieving closure Hard to use with legacy systems Requires a system that can be modularized Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.

08.10.2011

Dr. S. N Ahsan, IQRA-University

25

When to use RAD

Reasonably well-known requirements User involved throughout the life cycle Project can be time-boxed Functionality delivered in increments High performance not required Low technical risks System can be modularized

08.10.2011

Dr. S. N Ahsan, IQRA-University

26

Evolutionary Process Models

Software evolves over time (web pages are a prime example) Limited version is needed to meet business pressures. Time does not allow a full and complete system to be developed. Evolutionary models are iterative as software engineers develop increasingly more complete and complex systems

08.10.2011

Dr. S. N Ahsan, IQRA-University

27

Prototyping (Evolutionary Model)

Prototypes are built when goals are general and not specific. Prototyping can be used as a standalone process or by one of the processes presented. The prototype serves as the first system. Users get a feel for the actual system and devleopers get something built quickly. A prototype is intended for short term use but too often they are used much longer.

08.10.2011

Dr. S. N Ahsan, IQRA-University

28

Prototyping (Evolutionary Model)

Requirements

Design Design Implementation Implementation

Testing
Testing Maintenance

08.10.2011

Dr. S. N Ahsan, IQRA-University

29

Prototyping Strengths

Customers can see the system requirements as they are being gathered Developers learn from customers A more accurate end product Unexpected requirements accommodated Allows for flexible design and development Steady, visible signs of progress produced Interaction with the prototype stimulates awareness of additional needed functionality

08.10.2011

Dr. S. N Ahsan, IQRA-University

30

Prototyping Weaknesses

Tendency to abandon structured program development for code-and-fix development Bad reputation for quick-and-dirty methods Overall maintainability may be overlooked The customer may want the prototype delivered. Process may continue forever (scope creep)
08.10.2011 Dr. S. N Ahsan, IQRA-University 31

When to use Prototyping

Requirements are unstable or have to be clarified As the requirements clarification stage of a waterfall model Develop user interfaces Short-lived demonstrations New, original development With the analysis and design portions of objectoriented development.
08.10.2011 Dr. S. N Ahsan, IQRA-University 32

The Spiral Model

An evolutionary model that couples the iterative nature of prototyping with the controlled, systematic aspects of waterfall model. Spiral model is often developed in a series of releases or versions. Is Adobe or Microsoft working on new releases? Better for large projects.

08.10.2011

Dr. S. N Ahsan, IQRA-University

33

Spiral Model (Evolutionary Model)

08.10.2011

Dr. S. N Ahsan, IQRA-University

34

Spiral Model (Evolutionary Model)

Determine objectives alternatives and constraints Risk analysis Risk analysis Risk analysis Prototype 3 Prototype 2 Operational protoype Evaluate alternatives identify, resolve risks

REVIEW Requirements plan Life-cycle plan

Risk analysis Prototype 1 Concept of Operation

Simulations, models, benchmarks S/W requirements Product design

Development plan Integration and test plan

Plan next phase

Code Unit test Design V&V Integr ation test Acceptance test Develop, verify Service next-level product
08.10.2011 Dr. S. N Ahsan, IQRA-University 35

Requirement validation

Detailed design

Spiral Model Strengths

Provides early indication of insurmountable risks, without much cost Users see the system early because of rapid prototyping tools Critical high-risk functions are developed first The design does not have to be perfect Users can be closely tied to all lifecycle steps Early and frequent feedback from users Cumulative costs assessed frequently
08.10.2011 Dr. S. N Ahsan, IQRA-University 36

Spiral Model Weaknesses

Time spent for evaluating risks too large for small or low-risk projects Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive The model is complex Risk assessment expertise is required Spiral may continue indefinitely Developers must be reassigned during nondevelopment phase activities May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration
08.10.2011 Dr. S. N Ahsan, IQRA-University 37

When to use Spiral Model

When creation of a prototype is appropriate When costs and risk evaluation is important For medium to high-risk projects Long-term project commitment unwise because of potential changes to economic priorities Users are unsure of their needs Requirements are complex New product line Significant changes are expected (research and exploration)

08.10.2011

Dr. S. N Ahsan, IQRA-University

38

Evolutionary Models: Concurrent

none Modeling act ivit y

Under development

represents the state of a software engineering activity or task

A wait ing changes

Under review Under revision Baselined

Done

Dr. S. N Ahsan, IQRA08.10.2011 University

39

Evolutionary Models: Concurrent

The former image depicted only the modeling activity Indeed, concurrent engineering is a set of framework activities such as Communication, Modeling, etc. Each of these activities is in one of its states A state is some externally observable mode of behaviour PROBLEMS: Prototyping (and other evolutionary processes) pose problems to project planning (too much uncertainty) Evolutionary speed may not be optimal: too slow affects productivity, too fast leads to chaos Sometimes software processes should focus on flexibility and extensibility, rather than on quality - delivery delays may make us miss the market niche and window of opportunity 08.10.2011 Dr. 40 S. N Ahsan, IQRA-University

SPECIALIZED PROCESS MODELS

41

Component Based Development

COTS or Commercial Off-The-Shelf components are becoming more available. Most (not all) COTS components have targeted functionality with good interfaces that enable the component to be integrated. This approach incorporates many of the aspects of the spiral model.

08.10.2011

Dr. S. N Ahsan, IQRA-University

42

Formal Methods Development Model

Formal mathematical specification of the software. Specify, develop and verify by rigourous math notation. Eliminates ambiguity, incompleteness, and inconsistency. Used more where safety-critical software is developed, e.g., aircraft avionics, medical devices, etc.

08.10.2011

Dr. S. N Ahsan, IQRA-University

43

Aspect-Oriented SW Development
Nearly all SW has localized features, functions and information content. User or customer concerns or needs must be included. These can be high-level concerns like security or lower-level such as marketing business rules or systemic such as memory management.

08.10.2011

Dr. S. N Ahsan, IQRA-University

44

Crosscutting Concerns

AOP addresses behaviors that span many, often unrelated, modules. Core Concerns: Primary core functionality. Central functionality of a module. Crosscutting Concerns: System wide concerns that span multiple modules. Cuts across the typical division of responsibility. OOP creates a coupling between core and crosscutting concerns. AOP aims to modularize crosscutting concerns.
08.10.2011 Dr. S. N Ahsan, IQRA-University 45

Aspects

In AOP crosscutting concerns are implemented in aspects instead of fusing them into core modules. Aspects are an additional unit of modularity. Aspects can be reused. By reducing code tangling it makes it easier to understand what the core functionality of a module is. An aspect weaver takes the aspects and the core modules and composes the final system.

08.10.2011

Dr. S. N Ahsan, IQRA-University

46

THE UNIFIED PROCESS MODELS

47

Unified Process Models

A use-case driven, architecture-centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML)

Dr. S. N Ahsan, IQRA08.10.2011 University

48

UP Phases
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows Requirements Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

Dr. S. N Ahsan, IQRA08.10.2011 University

49

rules of thumb about approach to be used

IF uncertainty is high THEN use evolutionary approach IF complexity is high but uncertainty is not THEN use incremental approach IF uncertainty and complexity both low THEN use one-shot IF schedule is tight THEN use evolutionary or incremental

50

The Unified Process

Benefits of iterative development include:

1. Early mitigation of high risks 2. Early visible progress. 3. Early feedback, user engagement, and adaptation, leading to a system that more nearly meets the needs of the various stakeholders. 4. Managed complexity no compounding of complexity by postponing the implementation phase. 5. Learning within an iteration.

Timeboxing
Management of a UP project:
Iterations are timeboxed or fixed in length. Iteration lengths of between two to six weeks are recommended. Each iteration period has its own development plan.

The Unified Process

phase phase

Inc.

Elaboration

Construction

Trans.

iteration

Release
The end of each iteration is a minor release

Final release

Agile Development
Agile Software Engineering combines a philosophy and a set of development guidelines. The philosophy encourages customer satisfaction and early incremental delivery of software, Small highly motivated project teams Informal method Minimal Software Engineering work products Development simplicity

54

Agile Software Development

Speed up or bypass one or more life cycle phases Usually less formal and reduced scope Used for time-critical applications Used in organizations that employ disciplined methods

What is Agility? Quick and effective response to change

31.03.2014

Dr. S. Nadeem Ahsan, IQRA-University

55

Agility and the Cost of Change

31.03.2014

Dr. S. Nadeem Ahsan, IQRA-University

56

Extreme Programming

Developers work in pairs Coding is the key activity throughout a software project Test cases and expected results devised before software design After testing of increment, test cases added to a consolidated set of test cases Developers work in pairs Test cases and expected results devised before software design After testing of increment, test cases added to a consolidated set of test cases
57

XP Practices (1-12)
Planning game 2. Small releases 3. Metaphor 4. Simple design 5. Testing 6. Refactoring 7. Pair-programming 8. Collective ownership 9. Continuous integration 10. 40-hour week 11. On-site customer 12. Coding standards
1.

31.03.2014

Dr. S. Nadeem Ahsan, IQRA-University

58