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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 3
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 4
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 6
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 7
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 8
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 9
Waterfall
RequirementsProcess
SystemAllocation
Process
ProjectInitiation
Process
ConceptExploration
Process
DesignProcess
ImplementationProcess
InstallationProcess
Operation &Support Process
Verification& Validation
Process
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 10
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 11
V-model
SystemRequirements
Analysis
Implementation
PreliminaryDesign
DetailedDesign
SoftwareRequirementsElicitation
Operation
ClientAcceptance
RequirementsAnalysis
UnitTest
SystemIntegration
& Test
ComponentIntegration
& Test
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 12
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 13
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 14
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 15
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 16
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 17
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.
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 18
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 19
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”
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 20
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)
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 21
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 22
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 23
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]
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 24
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
McGill University ECSE 321 © 2003 Radu Negulescu Introduction to Software Engineering Life cycle models—Slide 25
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