1

SOFTWARE LIFE-CYCLES

Beyond the Waterfall

2

Requirements

System Design

Detailed Design

Implementation

Installation & Testing

Maintenance

The WATERFALL LIFE-CYCLE

Standards

Milestones

Documents

3

Problems with the Waterfall Model

• sequentiality• late testing paradigm• late feedback

to customer and engineer• minimal risk management

for customer and engineer

4

The “V” LIFE-CYCLE

Requirements

System Design

Detailed Design

Implementation

Acceptance Test

Integration Test

Module Test

5

Analysis of the V-Shaped Life-Cycle

• Improves the testing paradigm==> Quality Assurance

• Does NOT really improve:– sequentiality– feedback– risk management (during development)

6

Requirements

Global System Design

Detailed D.

Implem.

Testing

Maintenance

INCREMENTAL DEVELOPMENT

Detailed D.

Implem.

Testing

Detailed D.

Implem.

Testing

7

Analysis of Incremental Development

• Assumes independent subsystems!• Improves (by delivering smaller units):

– feedback: stepwise– testing

• Avoids monolithic product• Does not really improve:

– risk management during development– sequentiality: subsystems

8

(Rapid) Prototyping

• Goals:– break away from sequentiality– speed up feedback– minimize risks for

customer and engineer– incomplete but executable– cheap and fast

9

Prototyping

• Definition (A. Davis):A prototype is a partial implementation of

a system, constructed primarily to enable customer, user, or developer to learn about the problem or its solution.

• Types:– evolutionary / throw-away– horizontal / vertical

10

Horizontal Prototyping

f1 fnuser

hardware

11

Vertical Prototyping

f1 fnuser

hardware

13

Analysis of Pure Prototyping

• Improvements:– breaks sequentiality– supports fast feedback– opportunity for risk management

• Problems:– missing organisational structure

==> combine with a life-cycle

14

The Spiral Model

• Goals:– risk management– compatible mix between

clear structure (life-cycle) &flexible prototyping

– supports fast feedback & quality assurance

15determine objectives,alternatives,constraints

evaluate alternatives, identify & resolve risks

develop &verify product

plan the next phase

risk analysis

p r o t o t y p e s

require-system

detaileddesign

implementtest &install

designments

principlesreq. plan

dev.plan

integ.plan

17

The Rational Unified Process (RUP)• A modern generic process derived from the

work on the UML and associated process.

• Brings together aspects of the 3 generic process models discussed previously.

• Normally described from 3 perspectives

- A dynamic perspective that shows phases over time;

– A static perspective that shows process activities;

– A practice perspective that suggests good practice.

17Credit: Sommerville 9th edition: Chapter 2 Software Processes

18

Phases in the Rational Unified Process

18Credit: Sommerville 9th edition, Chapter 2 Software Processes

19

RUP phases• Inception

- Establish the business case for the system.• Elaboration

- Develop an understanding of the problem domain and the system architecture.

• Construction

- System design, programming and testing.• Transition

- Deploy the system in its operating environment.

19Credit: sommerville, 9th edition, Chapter 2 Software Processes

20

RUP iterations• In-phase iteration

- Each phase is iterative with results developed incrementally.

• Cross-phase iteration

- As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.

Credit: Sommerville, 9th edition, Chapter 2 Software Processes 20

21

Static workflows in the Rational Unified Process

21Credit: Sommerville, 9th edition, Chapter 2 Software Processes

22

Static workflows in the Rational Unified Process

22Credit: Sommerville, 9th edition, Chapter 2 Software Processes

23

RUP overview

Credit: Ph, Krutchen,, RUP, Crosstalk, 9 (7) July 1996, pp.11-16.

24

RUP good practices• Develop software iteratively

- Plan increments based on customer priorities and deliver highest priority increments first.

• Manage requirements

- Explicitly document customer requirements and keep track of changes to these requirements.

• Use component-based architectures

- Organize the system architecture as a set of reusable components.

24Credit: Sommerville, 9th edition, Chapter 2 Software Processes

25

RUP good practices• Visually model software

- Use graphical UML models to present static and dynamic views of the software.

• Verify software quality

- Ensure that the software meet’s organizational quality standards.

• Control changes to software

- Manage software changes using a change management system and configuration management tools.

Credit: Sommerville, 9th edition, Chapter 2 Software Processes 25

26

Key points• Processes should include activities to cope with

change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design.

• Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole.

• The Rational Unified Process is a modern generic process model that is organized into phases (inception, elaboration, construction and transition) but separates activities (requirements, analysis and design, etc.) from these phases.

26Credit: Sommerville, 9th edition, Chapter 2 Software Processes

27

End of Section 1c

coming up:methodologiesfor analysis &design