The Software Life Cycle Elaboration Production Software - PowerPoint PPT Presentation

Inception Software Communication Planning Increment The Software Life Cycle Elaboration Production Software Engineering Deployment Modelling Andreas Zeller • Saarland University Construction Transition Construction

A Software Crisis

Code and Fix (1950–) Build first version Modify until 
 client is satisfied Operate Retirement

Code and Fix: Issues • No process steps – no specs, docs, tests… • No separation of concerns – no teamwork • No way to deal with complexity

Code and Fix

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Communication Communicatio n 
 project initiation

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Planning Planning estimating 
 scheduling 
 tracking

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Waterfall Model (1968) Modeling analysis 
 design

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Waterfall Model Construction code 
 test

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Deployment Deployment delivery 
 support feedback

Waterfall Model (1968) Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Waterfall Model (1968) Communicatio • Real projects rarely follow a sequential n 
 project initiation Planning flow estimating 
 • Hard to state all requirements explicitly scheduling 
 tracking Modeling • No maintenance or evolution involved analysis 
 design • Customer must have patience Construction code 
 • Any blunder can be disastrous test Deployment delivery 
 support feedback

Boehm’s first law Errors are most frequent 
 during requirements and design activities and are the more expensive 
 the later they are removed.

Problem Cost Relative cost of problem per phase 30.0 22.5 15.0 7.5 0.0 Coding Unit test Component test System test Field

Incremental Model Features Increment #3 Communication project initiation requirements gathering Planning estimating scheduling Increment #2 tracking Modeling analysis design Construction Communication code project initiation test requirements gathering Deployment Planning delivery estimating support Increment #1 scheduling feedback tracking Modeling analysis design Communication Construction project initiation code requirements gathering Planning test Deployment estimating delivery scheduling support tracking feedback Modeling analysis design Construction code test Deployment delivery support Time feedback

Incremental Model • Each linear sequence produces a particular “increment” to the software • First increment typically core product; more features added by later increments • Allows flexible allocation of resources

Prototyping Communication Quick Plan Deployment and Quick Design Feedback Prototype Construction

Prototypes Top Layer (GUI) Bottom Layer

Horizontal Prototype Top Layer (GUI) Bottom Layer

Prototypes Top Layer (GUI) Bottom Layer

Vertical Prototype Top Layer (GUI) Bottom Layer

Prototypes • A horizontal prototype tests a particular layer (typically the GUI) of the system • A vertical prototype tests a particular functionality across all layers • Resist pressure to turn a prototype into a final result!

Spiral Model (1988) Planning Modeling Communication Construction Deployment + Feedback Test

Spiral Model • System is developed in series of evolutionary releases • Milestones for each iteration of the spiral • Process does not end with delivery • Reflects iterative nature of development

Unified Process (1999) Inception Software Communication Planning Increment Elaboration Production Deployment Modelling Construction Transition Construction

Inception Inception Inception Software Communication Communication Planning Planning Increment Elaboration Production • Encompasses communication with user + planning Deployment Modelling • Results in a set of use cases • Architecture is just a tentative outline Construction Transition Construction

Elaboration Inception Software Communication Planning Planning • Refines and expands Increment preliminary use cases Elaboration Elaboration Production • Provides architecture and initial design Deployment Modelling Modelling model Construction Transition Construction

Construction Inception • Builds (or acquires) Software Communication Planning software components Increment according to architecture Elaboration Production • Completes design model • Includes implementation, Deployment Modelling Modelling unit tests, acceptance tests Construction Construction Transition Construction Construction

Transition Inception • Software given to end users for beta Software Communication Planning testing Increment • Feedback reports defects and changes Elaboration Production Deployment Deployment Modelling Construction Construction Transition Transition Construction

Production Inception • Software is deployed Software Software Communication Planning Increment Increment • Problems are monitored Elaboration Production Production Deployment Deployment Modelling Construction Transition Construction

Re-Iteration Inception Software Communication Communication Planning Increment • Feedback results in new Elaboration Production iteration for next release Deployment Deployment Modelling Construction Transition Construction

Unified Process Inception Software Communication Planning Increment Elaboration Production Deployment Modelling Construction Transition Construction

Unified Process Inception • Draws on best features of conventional Software Communication Planning Increment process models • Emphasizes software architecture and Elaboration Production design Deployment Modelling • Integrates with UML modeling techniques (more on this later) Construction Transition Construction

Manifesto for Agile Software Development (2001) • Individuals and activities over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation. • Responding to change over following a plan..

What is Agile Development? • Fast development? Hacking? Prototyping? Uncontrolled fun? Programmer heaven? • Agility = ability to react to changing situations quickly, appropriately, and effectively. • notice changes early • initiate action promptly • create a feasible and effective alternative plan quickly • reorient work and resources quickly and effectively

Agile? Communicatio n 
 project initiation Planning estimating 
 scheduling 
 tracking Modeling analysis 
 design Construction code 
 test Deployment delivery 
 support feedback

Incremental Model Features Increment #3 Communication project initiation requirements gathering Planning estimating scheduling Increment #2 tracking Modeling analysis design Construction Communication code project initiation test requirements gathering Deployment Planning delivery estimating support Increment #1 scheduling feedback tracking Modeling analysis design Communication Construction project initiation code requirements gathering Planning test Deployment estimating delivery scheduling support tracking feedback Modeling analysis design Construction code test Deployment delivery support Time feedback

Agile Processes Time Waterfall Iterative Agile Processes Test Implement Design Analyse Scope Credits: Prof. Bodik

Agile vs. Plan-driven Agile Plan-driven • Low criticality • High criticality • Senior developers • Junior developers • Requirements change very • Requirements don't change often too often • Small number of developers • Large number of developers • Culture that thrives on chaos • Culture that demands order

What is an Agile Process? • Difficult to predict which requirements will persist or change in the future. • For many types of software, design and development are interleaved. • Analysis, design, construction, and testing are not as predictable.