Intro to Software Engineering - Life Cycle Models

Life cycle models

McGill ECSE 321Intro to Software Engineering

Radu Negulescu

Fall 2003

McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 2

About this module

The power of a process does not lie in bureaucracy and overhead, but in stimulating effectiveness

• “Too little process” or “too much process” can kill a software project

• Need to understand process elements and how they are supposed towork in context

Here we discuss

• What is a software life cycle

• Common life cycle models and what makes them tick

• Applicability to various situations

• Beyond software life cycles:Agile movementCapability maturity model


Software project failures

Examples

• Famous bugs: Ariane 5 rocket, Therac 25 cancer treatment machine

• Stories on [BD page 4]

IT projects have a poor record, but getting better

• Why? “Nature of the beast”ComplexVolatileIntangible...

• [Standish Group International – CHAOS reports]2003: 34% successes, 15% failures1994: 16% successes, 31% failuresBalance: “challenged projects”

• Other hi-tech projects: similar trends


Software life cycle models

The software process (a.k.a. life cycle): activities and associated results which produce a software product [Sommerville]

• Activities: figure from [BD] (next slide)

• Product: code, manuals, related artifacts

Software life cycle model

• An abstraction representing the software life cycle

• Understand, monitor, control the life cycle

Software project

• Tasks, deadlines, staff, budget, resources, schedule, risks, …

• Project management: estimate, allocate, monitor, control

Do not confuse process, product, and project

Verification& Validation

Process

ConfigurationManagement

Process

DocumentationDevelopment

Process

TrainingProcess

ProjectMonitoring &Ctrl Process

S/W QualityManagement

Process

ProjectInitiation

Process

Operation& Support

Process

MaintenanceProcess

DesignProcess

ConceptExploration

Process

SystemAllocation

Process

RequirementsProcess

ImplementationProcess

InstallationProcess

RetirementProcess

Development processes Management processes Integral processes


Software life cycle models

Desirable characteristics of a software process:

• EfficiencyMaximize: feature set, qualityMinimize: overall effort budget, time-to-marketScalability: holds well for larger projects

• Risk-tolerance, predictabilityStability in presence of mishapsThe effort, time, quality are likely to meet the estimates

• VisibilityProgress can be monitored and estimates can be narrowed down as project progresses

• ControllabilityThe process has high-leverage decision points


Build-and-fix

Cycle: implement, debug, show to client

• Until the project is accepted

• No specifications, no design

Strengths

• Quick solution for 100-200 lines of code

Weaknesses

• Not scalable: fixing faults for larger projects; manifesting the less obvious failures; extensions, changes, and other maintenance

• Low risk-tolerance: any mistakes require re-coding; exposure to staff risks

• Low visibility: monitoring requires to scan raw code; product reliability is unknown

• Low predictability: based solely on initial estimates

• Difficult team coordination


Waterfall

Simply arrange the activities in a linear sequence

• Specification, design, test

• Figure from [BD] (next slide)

• Variation: “Verification step”

Strengths

• Easy management: visibility, team coordination, predictability

• Good for simple application, large team

Weaknesses

• Does not accommodate iteration / change

• Risks of bad design, requirements, etc.

• “Blocking states” in development

• Not helpful in rapid development, volatile requirements


Waterfall

RequirementsProcess

SystemAllocation

Process

ProjectInitiation

Process

ConceptExploration

Process

DesignProcess

ImplementationProcess

InstallationProcess

Operation &Support Process

Verification& Validation

Process


V-model

V-model

• Figure from [B&D]Variation of waterfallMakes explicit the level of abstractionIdea: plan tests early

• StrengthsSome early validationMore parallelism in development

• WeaknessesConfiguration management overheads

Variations

• Sawtooth: interleave demos to customer

• Sharktooth: interleave demos to customer and demos to manager


V-model

SystemRequirements

Analysis

Implementation

PreliminaryDesign

DetailedDesign

SoftwareRequirementsElicitation

Operation

ClientAcceptance

RequirementsAnalysis

UnitTest

SystemIntegration

& Test

ComponentIntegration

& Test


Prototyping

Iterative development of several prototypes until a suitable system is obtained

• Throw-away: clarify functionality, requirementsE.g.: A1, “project prototype”

• Evolutionary: will evolve into the final systemE.g.: chess playing program

Strengths

• Accommodates highly volatile requirements and technical risks

• Good for “wicked problems”: not well understood before development

• Leverage RAD/Component assembly/4 GL techniques4-5x less effort; 3-4x less time; 4-5x fewer defects

Weaknesses

• Lacks visibility, predictabilityHard to manageNeeds motivated developers


Prototyping

Example: FIREMAPS – a state-machine based circuit analysis tool

• A research tool, for knowledgeable users

• Only a few commands known in advance at the time of development

• Uses a BDD (binary decision diagram) library

Two prototypes: ~ 2-3 days each

• Process calculator

• BDD library use

Core parts: ~ 2 months

• A simple recursive parser for Polish expressions, process automata

• Basic operations: composition, refinement checks

Additional parts: ~ on-going, need-to basis

• Advanced operations: hiding, non-deterministic choice

• Case-study driven: process representations, timing constraints

• 100+ operators


Spiral model

A generic process model for risk management

Identify risks, impacts, contingencies, priorities:

• Product size

• Customer-related (business misunderstandings, change)

• Defects

• Process, technology, development environment

• Staff turnover

Phases of a round:

• Explore alternatives

• Analyze risks; build prototype

• Build part of the system

• Plan next round: review


Spiral model

Strengths

• Risk reduction (through prototyping)

• Systematic

• Iterative

Weaknesses

• Relies on expertise for risk assessment

Examples

• Waterfall + risk control phases

• Project management in RUPIdentify risksRevisit risk lists


Spiral model

Requirements

Development

Integration

plan

plan

plan

Requirements

Design

validation

validation

Software SystemProduct

Riskanalysis

Riskanalysis

Prototype1Prototype2

Prototype3

Riskanalysis

Concept ofoperation

RequirementsDesign

Code

Unit Test

Integration & TestAcceptance

DetailedDesign

Test

Evaluate alternatives Identify & resolve risks

Develop & verify next level product

Plan next phase

Determine objectives, alternatives, and constraints


Incremental and iterative model

Several increments

• Each increment adds new functionality

• Each consists of analysis, design, code, test

Several iterations

• Each increment induces revision/adaptation of previous increments

Strengths

• Flexibility of delivery of functionality

• Can be done with less staff

• Can be planned to manage technical and business risks

Best practice

• Followed in RUP, XP, etc.


Incremental and iterative model

E.g. Rational unified process [Kruchten, "The Rational Unified Process -An Introduction", Addison-Wesley, 1998]

Four phases, orthogonal to the development cycle:

• Inception: concept exploration

• Elaboration: project planning, resource allocation

• Construction: several iterations

• Transition: installation and post-development


Extreme programming

A new and somewhat controversial process model

Good ideas:

• Incremental delivery (based on “stories”)

• Rules for playing the planning game

• Iterative development, refactoring

• Pair programming

• Team ownership of the code

Not quite proven:

• Flat cost of change

• Complete absence of an overall design or architecture phase“Replaced by refactoring”


Formal methods

The “dream” that started the field of “software engineering”: apply rigorous mathematical methods to develop software

• Verification, testing, design: driven by partial specificationsSuccessive refinementAssertion checking (!)

Strengths

• Utmost defect reduction

• Can stabilize intermittent failures (hard to do by other methods)

Weaknesses

• Time-consuming, skill-intensive

• “Correctness is overrated”

Applications

• Safety-critical software (“cleanroom” process)

• Distributed or highly concurrent software (e.g. PBX)


Life cycle model selection

Depends on:

• Application domainDesktop / shrink-wrapClient-server, internetSystem softwareEmbedded, real-timeSafety-critical

• Knowledge of application domainRe-engineering => more linearFirst-of-a-kind => substantial prototyping

• Schedule constraintsRapid vs. economical development

• Developer training & experienceFlexibility, control overhead

• Risk-tolerance of the projectFaster vs. safer


Examples: selection of a process model

Which life cycle models would you select for the following software projects?

• Safety-belt controller

• Digital camera controller

• Walking robot competition

• Account management software on a contract

• Account management software shrink-wrapped

• Account management software deployed on the web

• Chess-playing program

• Robot arm movement controller

• Operating system

• Spreadsheet program


Agile vs. plan-driven methods

Agile principlesEarly and frequent delivery; measure progress by working softwareAccommodate and harness changeFrequent interaction of business and developmentMotivated individuals, face-to-face conversation, sustainable developmentSimplicity, technical excellence, good designContinual improvement of team behavior

Agile – plan-driven spectrum [Barry Boehm]


Capability maturity model (CMM)

How “mature” is the software development process in your organization? or your personal process?

• Level 1: initial. No structure, relies on individuals

• Level 2: repeatable. Mimick previous success and use basic processManaged requirements, project planning and tracking, subcontractor management, QA, CM

• Level 3: defined. Standardized management and development process

Process definition, process focus, training program, product engineering, peer reviews

• Level 4: managed. Detailed measures are collectedQuantitative process management, quality management

• Level 5: optimizing. Implementing new approaches by using feedback from level 4 and by trying new technologies

Defect prevention, technology change management, process change management


References

Software life cycles

• BD: 12.4

Agile software development

• Agile alliance on-line libraryhttp://www.agilealliance.com/articles/index

CMM

• BD: 12.3

• SEI technical report “Capability Maturity Model”: Section 2 “The five levels of process maturity”

http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf

Technology

Intro to Software Engineering - Life Cycle Models