handout-software lifecycle models

8/8/2019 Handout-Software Lifecycle Models

1/60

Software Development Lifecycle

Models

Fall 2009


2/60

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?


3/60


4/60

A lifecycle model ...

Not a definition of the process an

organization follows.

Does not provide rules or representations

for development.

Is reference used to discuss the

development of software.


5/60

Some Models Code and fix

Waterfall

Prototyping RAD

Incremental/evolutionary

Reusable components

Automated synthesis Spiral

XP


6/60

0. Code and Fix (aka cowboy) Repeat

write code

fix it

Until code is good enough or resources

exhausted


7/60

In class What are the pros and cons of this

approach?

(2 minutes)


8/60

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.


9/60

Waterfall Phases

Feasibility

Specify

Requirements

Design

Implement

Test

Deliver

Maintain


10/60

Feasibility Study

feasibility study


11/60

Requirements

requirements specification document (SRS) states what qualities software must exhibit.

needs to be understandable, precise, complete,consistent, unambiguous, modifiable

preliminary user manual? system test plan?

functional requirements non-f unctional requirements


12/60

Design design (preliminary and detailed)

decompose system into modules, selection of a

software architecture top-down, iterative


13/60

Code, Test, Deliver coding and unit testing

create code (aka programming)

integration and system testing this might be combined with the previous, done

in incremental fashion alpha testing

delivery beta testing acceptance testing


14/60

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)


15/60

Advantages of Waterfall Shows that software can be disciplined.

Forces attention on requirements and design

before code.

Encourages planning.

Provides documents that can be used for

testing. Documents become part of legacy of

system.


16/60

In Class Clearly, waterfall has advantages over code

and fix.

There are many criticisms of waterfall: what

are they?

(3 minutes)


17/60

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


18/60

In Class How is this better than waterfall?

What are the costs?


19/60

3. RAD

Rapid application development: short development cycle based on components and

4GLs.

Used for Modeling: business, data, and process

Application generation

Testing/installation


20/60

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.


21/60

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


22/60

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 SPMP

1

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

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


23/60

In Class What problems are we trying to fix with this

method?

What pitfalls arise?


24/60

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

lookup of parts.

specify as pre and post conditions.


25/60

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


26/60


27/60

7. Spiral

Barry Boehm (seeIEEE Computer, vol 2

1, no5, may 1988, pp61-72.)

meta-model

4 stages in each cycle

identify objectives and alternatives evaluate alternatives, identify risk, deal with

risks

develop, verify, prototype, use any model

evaluate and plan next cycle

starts with hypothesis that something can beimproved

ends with product


28/60

Spiral Model1. Objective 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 further in loop.

Rapid prototype

SpecificationPlanningDesignImplementationIntegration

VerifyTest

RiskAnalysis


29/60


30/60

Driving Forces waterfall: documentation driven

evolutionary: increment driven

transformational: specification driven

spiral: risk driven


31/60


32/60

Requirements

Analysis

USDP vs. Standard Terminology 2 of2

Design

Implemen

tation

Test

Requirements analysis

Implementation

USDP

Terminology

Classical

Terminology

Integration

Design

Test

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


33/60

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


34/60

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).


35/60

Agile MethodsAgile is an iterative and incremental

(evolutionary) approach to software

developmentwhich [sic] is performed in ahighly collaborative manner with "justenough" ceremony thatproduces highquality software which meets the

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

eDevelopment.htm


36/60

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


37/60

Outline of Agile Methods Minimize risk by developing software in short

cycles 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


38/60

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


39/60

In class What are the advantages and disadvantages

of having everyone at one site?


40/60

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 true


41/60

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 overlightweight


42/60

History Extreme Programming (XP)

Not first, but most popular

Established in 1966 by Kent Beck

Tried to save the Chrysler C3 project (butdidnt)

1999Elements of Extreme Programming


43/60


44/60

Some of the principles behind the

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

delivery ofuseful 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 shouldbe trusted.

Continuous attention to technical excellence and good design Simplicity.

Self-organizing teams

Regular adaptation to changing circumstances


45/60

Adaptive vs Predictive Methods Adaptive methods

focus on adapting quickly to changing realities difficulty describing exactly what will happen in the future

The f urther away a date is, the more vague an adaptive method willbe.

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 future 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 andchanging direction can cause completed work to be thrown away anddone over differently.


46/60

In class List several characteristics of projects

suitable for predictive methods and several

characteristics of projects suitable foradaptive methods.


47/60

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


48/60

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 fully 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 fully developed features (but small subset of them)each development cycle


49/60

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 confused with cowboy

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


50/60


51/60

Agile vs Plan-driven

Agile

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


52/60

Problems with Agile

Push to get initial software working may result inpoor architecture, which is difficult to change

Client may be talked into poor choices bydevelopers

Single "dominant" developer may exert undoinfluence

Depends on the ability of the customer to providenegative feedback when necessary

In theory, the rapidly iterative nature should limitproblems, but it assumes that there's a negativefeedback, or even appropriate feedback. If not, errorscould be magnified rapidly.


53/60


54/60

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)


55/60

XP

The main aim of XP is to reduce the cost of

change.


56/60

XP

Extreme Programming ExplaineddescribesExtreme Programming as being:

An attempt to reconcile humanity andproductivity

A mechanism for social change

A path to improvement A style of development

A software development discipline


57/60


58/60

Activities

Coding

Testing

Listening

Designing

12 XP P i


59/60

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


60/60

In class: Choose Development

Model Student Information System for UTEP

Autonomous Network of Mobile Robots for

Asteroid Exploration

Web-based Purchasing System for Car parts

Airborne Navigation System for

Commercial Aircraft

Data-mining System for Human Genome