1

Software life cycle model software life cycleseries of identifiable stages that a

software product undergoes during its lifetime

software life cycle modelIt is a descriptive and diagrammatic

representation of software life cycle

2

Why Software life cycle model?It encourages development of s/w in a

systematic and discipline way

It is necessary to have precise understanding among team members otherwise it will lead to chaos and project failure

3

PHASE ENTRY AND EXIT CRITERIA Every software life cycle model normally

define entry and exit criteria every phase

A phase can begin only when corresponding phase entry are satisfied

4

99% complete syndrome When there is no clear specification of the

entry and exit criteria for every phase and if no life cycle model is followed

It becomes very difficult to chart the progress of the project

5

Software process modelAttempt to organize the software life cycle

by defining activities involved in software production order of activities and their relationships

Goals of a software processstandardization, predictability, productivity,

high product quality, ability to plan time and budget requirements

Code&FixThe earliest approach Write code Fix it to eliminate any errors that have

been detected, to enhance existing functionality, or to add new features

Source of difficulties and deficiencies impossible to predict impossible to manage

Models are neededSymptoms of inadequacy: the software

crisisscheduled time and cost exceededuser expectations not metpoor quality

The size and economic value of software applications required appropriate "process models"

The Waterfall Model

9

Waterfall Model Assumptions

10

1. The requirements are knowable in advance of implementation.

2. The nature of the requirements will not change very much During development; during evolution

3. The requirements are compatible with all the key system stakeholders’ expectations e.g., users, customer, developers, maintainers,

investors

4. The right architecture for implementing the requirements is well understood.

5. There is enough calendar time to proceed sequentially.

Process for Offshore?

11

Deploy

Analysis

Design

Accept. test

Construct

System test

12

Disadvantages of waterfall model

Real projects rarely follow sequential flow

Difficult for the customer to state all requirements

Customer to show patience. Working version of program will not be available until late in the project

13

Evolutionary Models: Prototyping

14

Prototyping modelThis begins with requirement gathering . Developer and customer meet and define overall objectives for the s/w

Then quick design occurs which focus on representation of those aspects of the s/w that are visible to customer

After the quick design prototype is build and then evaluated and feedback given

15

16

Evolutionary process modelsAll the linear sequential models are design

for straight line developmentIn waterfall model complete system will be

delivered after linear sequence is completedThe prototyping is designed to assist the

customer in understanding requirements

17

Incremental Models: Incremental

18

Incremental modelThe incremental model combines elements of

linear sequential model with iterative nature of prototyping

For example: word processing s/wFirst increment product is core product which

is used by customer in which modifications he can add

The process is repeated until the complete product is produced

19

Usefulness of the model When staffing unavailable for whole

complete implementation by business deadline

Increments can be planned to manage technical risks

Best when: you encounter a difficult deadline that cant be changed

20

21

If we rely on testing alone, defects created first are detected last

SystemRequirements

SoftwareRequirements

SoftwareDesign

SoftwareImplementation

UnitTesting

IntegrationTesting

SoftwareTesting

SystemTesting

system test plan

software test plan

integration plan

unit plan

ProductRelease

time

UserNeed

Incremental Models: RAD Model

22

Risk Exposure

23

Unified Process Model

24

A software process that is:A software process that is:

use-case drivenuse-case driven architecture-centricarchitecture-centric iterative and incrementaliterative and incremental

Closely aligned with theClosely aligned with the

Unified Modeling Language Unified Modeling Language (UML)(UML)

The Unified Process (UP)

25

inceptioninception

UP Work Products

26

inceptioninception

Lifecycle for Enterprise Unified Process

27

inceptioninception

Synchronize-and Stabilize Model Microsoft’s life-cycle model Requirements analysis—interview

potential customers Draw up specifications Divide project into 3 or 4 builds Each build is carried out by small

teams working in parallel

28

Synchronize-and Stabilize Model (contd) At the end of the day—synchronize (test

and debug) At the end of the build—stabilize (freeze

build) Components always work together

› Get early insights into operation of product

29

Evolutionary Models: The Spiral

30

Spiral ModelSimplified form

Waterfall model plus risk analysis

Precede each phase byAlternativesRisk analysis

Follow each phase byEvaluationPlanning of next

phase 31

Simplified Spiral Model

32

If risks cannot be resolved, project is immediately terminated

Full Spiral ModelRadial dimension: cumulative cost to

dateAngular dimension: progress through

the spiral

33

Full Spiral Model (contd)

34

Analysis of Spiral ModelStrengths

Easy to judge how much to testNo distinction between development, maintenance

WeaknessesFor large-scale software only For internal (in-house) software only

35

Object-Oriented Life-Cycle Models

Need for iteration within and between phasesFountain modelRecursive/parallel life cycleRound-trip gestaltUnified software development process

All incorporate some form of IterationParallelism Incremental development

DangerCABTAB

36

Fountain ModelFeaturesOverlap

(parallelism)Arrows

(iteration)Smaller

maintenance circle

37

Software Process Spectrum

38

lightweight heavyweightmiddleweight

XPSCRUM

DSDMFDD RUPdX

ICONIXCrystal Clear Crystal Violet

EUPOPEN

ConclusionsDifferent life-cycle modelsEach with own strengthsEach with own weaknessesCriteria for deciding on a model include

The organization Its managementSkills of the employeesThe nature of the product

Best suggestion “Mix-and-match” life-cycle model

39

40

What is MDA in essence?Automated approach to translate high

level design to low level implementation by means of separation of concerns

From high-level model to running application

Risk proportional to expectations!41

Finding the “right” language

42

Assembler

3GL

IDEs & 4GL

Model Driven Architecture

Computer Hardware

DeveloperA

uto

matio

n

Ab

straction

Martin FowlerMartin Fowler

43

Model Driven ArchitectureCan you actually have incremental MDA?

Or is it automated waterfall?

Need rigorous modelsNeed high quality requirements

Capture requirementsUnderstand requirements

44

MDA or Offshore?Automation versus reduce cost of labor

ObjectivesReduce required intelligenceIncrease repetition

GoalReduce costs of development

45