Lecture 22 Software Lifecycle Models

8/6/2019 Lecture 22 Software Lifecycle Models

http://slidepdf.com/reader/full/lecture-22-software-lifecycle-models 1/47

Software Development Lifecycle

Models

Fall 2010



Question:� We know that we have to do some things in order

to get a software product completed:

± gather requirements

± Design

± Implement

± Test

± «

� How do you order these activities so that you are

most productive?



One view

� Requirements Elicitation

� Requirements analysis

� Requirements specification

� Prototyping

� Architectural design

� Detailed design

� Implementation

� Unit testing� Integration testing

� System testing

� Delivery

� Maintenance



What is a lifecycle model?



Some Models� Code and fix

� Waterfall

� Prototyping� RAD

� Incremental/evolutionary

� Reusable components

� Automated synthesis� Spiral

� XP



0. Code and Fix (aka ³cowboy´)� Repeat

± write code

± fix it

� Until code is good enough or resources

exhausted



1. Waterfall (traditional)� First systematic approach, best studied.

± Winston Royce

� Some aerospace and government agenciesmandate some form of this model.

� Must be adapted to a particular situation or

organization.



Waterfall

� Requirements Elicitation

� Requirements analysis

� Requirements specification

� Prototyping

� Architectural design

� Detailed design

� Implementation

� Unit testing� Integration testing

� System testing

� Delivery

� Maintenance



Waterfall Phases

Feasibility

Specify

Requirements

Design

Implement

Test

Deliver

Maintain



Maintain (evolution?)Corrective: (fix bugs)

12% = ³emergency fixes´

9% = routine debuggingAdaptive: (secondary changes)17% = change data formats6% = hardware changes

Perfective (improve)5% = improvements in documentation4% = improvements in efficiency42% = change user requirements

Preventive (form of Perfective)



2. Rapid Prototypes� Gomaa and Scott (early 80s)

� Prototypes are throwaway.

± Build prototype,

± User feedback drives correction of

requirements

± Toss the prototype

± Build system in traditional way



3. RAD

� Rapid application development:

± short development cycle based on components and

4GLs.

� Used for ± Modeling: business, data, and process

± Application generation

± Testing/installation



3. RAD

� Difficult to scale to large projects.

� Works best when system can be modularized and

is well understood (eg business apps)

� Does not work well when technical risks are high,system cannot be modularized, or interfaces to

other systems are an issue.



4. Incremental/Evolutionary

� Recognized as desirable by government� Incremental:

± design is totally laid out first

± Functionality is provided in stages

� Evolutionary: prototype evolves into final version� Goal: get feedback earlier in process

repeat

give user something

evaluate/measure

adjust design and objectives



Iteration No.

Incremental Development

Analyzerequirements

Test whole

Implement

Design

Test units

Integrate

1 2 3 867 868

Update SRS3

Update SDD2

Update source code

Update Test documentation

Update SPMP1

1 Software Project Mangement Plan (chapter 2); 2 Software Design Document (chapter 5); 3 Software Requirements Specification (chapter 3);

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.



5. Reusable software:� build it from parts,

� this is the goal of the Ada project.

� need to have parts, specs for parts, and tools

for accessing them.

� there are several methods of automating the

look u p of parts

� specify as pre and post conditions



6. Automated Synthesis

� Transformations: KIDS, SPECWARE,HATS

� Start with a formal specification

(mathematical) ± successively refine this (formally) until code

± may entail theorem proving

± may entail computer assisted software

engineering environment

� Pre and post conditions

� First order specifications, etc



6. Automated Synthesis

� Programmer can no longer fix the code

directly.

� Code is not result of coding, but of

transforming.

± Change the specs and the code changes.

� Also correct by constr uction, proofs as

programs



7. Spiral

� Barry Boehm (see I EEE Computer , vol 21, no5, may 1988, pp61-72.)

� meta-model

� 4 stages in each cycle

± identify objectives and alternatives

± evaluate alternatives, identify risk, deal withrisks

± develop, verify, prototype, use any model

± evaluate and plan next cycle

� starts with hypothesis that something can beimproved

� ends with product



Spiral Model1. O bjective setting: for

each phase--identify

constraints, risk,

management plan

2. Risk Assessment and

reduction

3. Develop and Validate

4. Planning: review project

and decide whether to

continue f urther in loop.

Rapid prototype

SpecificationPlanningDesignImplementationIntegration

VerifyTest

RiskAnalysis



Spiral Model� Focus on eliminating errors early

� Look at level of effort

� Accommodates growth and change(evolution)

� Restrictions

± In-house development (not contracted) ± Good for large-scale systems

± Requires training in risk analysis and resolution



Driving Forces� waterfall: documentation driven

� evolutionary: increment driven

� transformational: specification driven

� spiral: risk driven



ElaborationInception Construction Transition

Requirements

Analysis

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k «.. «..Prelim.

iterations

USDP vs. Standard Terminology (Booch, Jacobson &

R umbaugh)

Design

Implementation

Test

US DP calls these³core workflows´

(Classically called ³phases´)

Classification of iterations

Individual iteration



Requirements

Analysis

USDP vs. Standard Terminology 2 of 2

Design

Implementation

Test

Requirements analysis

Implementation

USDP

Terminology

Classical

Terminology

Integration

Design

Test

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.



Elaboration

Unified Process Matrix

Inception Construction Transition

Requirements

Analysis

Jacobson et al : USDP

Prelim.

iterations

Iter.

#1

Iter.

#n

Iter.

#n+1

Iter.

#m

Iter.

#m+1

Iter.

#k «.. «..

Design

Implementation

Test

..

Amount of effort expended

on the requirements phaseduring the first Construction

iteration



Agile(1) moving quickly and lightly;

(2) mentally quick; "an agile mind";

(3) Refers to the speed of operations within an

organization and speed in responding to

customers (reduced cycle times).



Agile MethodsAgile is an iterative and incremental

(evolutionary) approach to software

development which [sic] is performed in ahighly collaborative manner with "justenough" ceremony that produces highquality software which meets the

changing needs of its stakeholders.» http://www.agilemodeling.com/essays/agileSoftwar

eDevelopment.htm



Values of Agile� Individuals and interactions over processes and

tools

� Working software over comprehensive

documentation

� Customer collaboration over contract negotiation

� Responding to change over following a plan



Outline of Agile Methods

� Minimize risk by developing software in shortcycles ± Iterations

± typically last one to four weeks

� An iteration ± like a miniature software project

± includes planning, requirements analysis, design,

coding, testing, and documentation.� At the end of each iteration, the team re-evaluates

project priorities



Communications� Emphasize real time communication

± face-to-face rather than written documents

� All team members are co-located

± Programmers, testers, techwriters

± managers

± "customers" who define the product



Software� Working software is the primary measure of

progress

� Very little written documentation relative to

other methods

� Criticism of agile methods: undisciplined

± May or may not be tr ue



History� Evolved in the mid 1990s

� Reaction against "heavyweight" methods such as waterfall

± Waterfall

� regimented and micromanaged� Bureaucratic, slow

� Contradicts way SEs actually perform effectivework

± Agile is a return to practices seen early in software

development� Is this good? Bad?

� 2001 meeting at Snowbird adopted name ³agile´ over ³lightweight´



History� Extreme Programming (XP)

± Not first, but most popular

± Established in 1966 by Kent Beck

± Tried to save the Chrysler C3 project (butdidn¶t)

± 1999 Elements of Extreme Programming



Different Agile Methods� Created prior to 2000

± Scr um

± Crystal Clear (1986)

± XP (1996)

± Adaptive Software Development

± Feature Driven Development

± DSDM (1885)



Some of the principles behind the

Agile Manifesto� Customer satisfaction by rapid (two weeks?), continuous

delivery of usef ul software

� Working software is the principal measure of progress.

� Late changes in requirements are welcomed.� Daily, face-to-face conversation is the best form of

communication.

� Projects are built around motivated individuals, who should be tr usted

� Continuous attention to technical excellence and good design.� Simplicity

� Self-organizing teams

� Regular adaptation to changing circumstances



Adaptive vs Predictive Methods� Adaptive methods

± focus on adapting quickly to changing realities

± difficulty describing exactly what will happen in the f uture

± The f urther away a date is, the more vague an adaptive method will be.

� Team can report what tasks will be complete next week

� Team can report what features will be worked on next month

� Team cannot predict what features will be in the release 6 months out

� Predictive methods ± focus on planning the f uture in detail

± difficulty changing direction

± A predictive team can report exactly what features and tasks are

planned for the entire length of the development process. ± The plan is typically optimized for the original destination and

changing direction can cause completed work to be thrown away anddone over differently.



Agile Contrasted with Iterative

� Iterative ± Build releasable software in short time periods

± Iterative time frames measured in months

� Agile

± Build releasable software in short time periods ± Time frame in weeks

± Time frame is strict



Agile Contrasted with Waterfall� Waterfall

± Most predictive of methods: sequence of steps is highly planned ± Document driven: progress is based on delivery of documents

after each stage

± Lengthy testing and integration phase at end of project

± Delivers f ully implemented software at the end of the project

± Some agile teams use the waterfall model on a small scale,repeating the entire waterfall cycle in every iteration

� Agile ± Least predictive methods

± Feature driven: progress based on delivery of features ± Testing is part of feature development: no significantintegration problems

± Delivers f ully developed features (but small su bset of them)each development cycle



Agile Contrasted with Cowboy

� "cowboy coding³ ± Cowboy coding is the absence of a defined method:

team members do whatever they feel is right

± Success depends on heroics

� Agile ± Agile may be conf used with cowboy

± Agile teams follow defined (and often verydisciplined and rigorous) processes



Suitability of Agile Methods� Organization must su pport negotiation

� People must be tr usted

� Requires higher competence

� Organizations must live with the decisions

developers make

� Organizations must su pport rapid communication

� Suitable for projects with small teams, with fewer than 20 to 40 people.



Agile vs Plan-drivenAgile

� Low criticality

� Senior developers

� Requirements change veryoften

� Small number of developers

� Culture that thrives on chaos

Plan-driven

� High criticality

� Junior developers

� Low requirements change� Large number of developers

� Culture that demands order



Some of the well-known agile

software development methods:� Extreme Programming (XP)

� Scr um

� Agile Modeling� Adaptive Software Development (ASD)

� Crystal Clear and Other Crystal Methodologies

� Dynamic Systems Development Method (DSDM)

� Feature Driven Development (FDD)� Lean software development

� Agile Unified Process (AUP)



XP� The main aim of XP is to reduce the cost of

change.



XP� Extreme Programming Explained describes

Extreme Programming as being:

� An attempt to reconcile humanity and productivity

� A mechanism for social change

� A path to improvement� A style of development

� A software development discipline



Five Valu

es of XP� Communication

� Simplicity

� Feedback

� Courage

� Respect



Activities� Coding

� Testing

� Listening

� Designing



12 XP Practices

� Fine scale feedback ± Pair programming

± Planning Game

± Test drive

development ± Whole team

� Continuous process

± Continuous

integration ± Design improvement

± Small releases

� Shared understanding ± Coding Standards

± Collective codeownership

± Simple design ± System metaphor

� Programmer welfare

± Sustainable pace

Documents

Lecture 22 Software Lifecycle Models