Software Development Lifecycle Models

60
Software Development Lifecycle Models Fall 2009

description

Software Development Lifecycle Models. Fall 2009. 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?. What is a lifecycle model?. - PowerPoint PPT Presentation

Transcript of Software Development Lifecycle Models

Page 1: Software Development Lifecycle Models

Software Development Lifecycle Models

Fall 2009

Page 2: Software Development Lifecycle Models

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?

Page 3: Software Development Lifecycle Models

What is a lifecycle model?• Phase: activities to accomplish goals.• Lifecycle model: A model of the phases

that start when the project is conceived and ends when the product is retired.– Depicts the relationships between the major

milestones, reviews, deliverables. – Determines the order of activities.

Page 4: Software Development Lifecycle Models

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.

Page 5: Software Development Lifecycle Models

Some Models• Code and fix • Waterfall• Prototyping• RAD• Incremental/evolutionary• Reusable components• Automated synthesis• Spiral• XP

Page 6: Software Development Lifecycle Models

0. Code and Fix (aka “cowboy”)

• Repeat– write code – fix it

• Until code is good enough or resources exhausted

Page 7: Software Development Lifecycle Models

In class

• What are the pros and cons of this approach?

• (2 minutes)

Page 8: Software Development Lifecycle Models

1. Waterfall (traditional)

• First systematic approach, best studied.– Winston Royce

• Some aerospace and government agencies mandate some form of this model.

• Must be adapted to a particular situation or organization.

 

Page 9: Software Development Lifecycle Models

Waterfall PhasesFeasibility

Specify Requirements

Design

Implement

Test

Deliver

Maintain

Page 10: Software Development Lifecycle Models

Feasibility Study 

• feasibility study

Page 11: Software Development Lifecycle Models

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-functional requirements

Page 12: Software Development Lifecycle Models

Design

• design (preliminary and detailed)– decompose system into modules, selection of a

software architecture– top-down, iterative

 

Page 13: Software Development Lifecycle Models

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

 

Page 14: Software Development Lifecycle Models

Maintain (evolution?)

Corrective: (fix bugs)12% = “emergency fixes”9% = routine debugging

Adaptive: (secondary changes)17% = change data formats6% = hardware changes

Perfective (improve) 5% = improvements in documentation 4% = improvements in efficiency  42% = change user requirements

Preventive (form of Perfective)

Page 15: Software Development Lifecycle Models

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.

Page 16: Software Development Lifecycle Models

In Class

• Clearly, waterfall has advantages over code and fix.

• There are many criticisms of waterfall: what are they?

• (3 minutes)

Page 17: Software Development Lifecycle Models

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

Page 18: Software Development Lifecycle Models

In Class

• How is this better than waterfall?• What are the costs?

Page 19: Software Development Lifecycle Models

3. RAD• Rapid application development:

– short development cycle based on components and 4GLs.

• Used for– Modeling: business, data, and process– Application generation– Testing/installation

Page 20: Software Development Lifecycle Models

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.

Page 21: Software Development Lifecycle Models

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

repeatgive user somethingevaluate/measure adjust design and objectives

Page 22: Software Development Lifecycle Models

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.

Page 23: Software Development Lifecycle Models

In Class

• What problems are we trying to fix with this method?

• What pitfalls arise?

Page 24: Software Development Lifecycle Models

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.

Page 25: Software Development Lifecycle Models

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

Page 26: Software Development Lifecycle Models

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 construction, proofs as programs

Page 27: Software Development Lifecycle Models

7. Spiral• Barry Boehm (see IEEE Computer, vol 21, no

5, 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 be improved

• ends with product

Page 28: Software Development Lifecycle Models

Spiral Model

1. Objective setting: for each phase--identify constraints, risk, management plan

2. Risk Assessment and reduction

3. Develop and Validate4. Planning: review project

and decide whether to continue further in loop.

Rapid prototypeSpecificationPlanningDesignImplementationIntegration

VerifyTest

RiskAnalysis

Page 29: Software Development Lifecycle Models

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

Page 30: Software Development Lifecycle Models

Driving Forces

• waterfall: documentation driven• evolutionary: increment driven• transformational: specification driven• spiral: risk driven

Page 31: Software Development Lifecycle Models

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 & Rumbaugh)

Design

Implementation

Test

USDP calls these “core workflows”

(Classically called “phases”)

Classification of iterations Individual iteration

Page 32: Software Development Lifecycle Models

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.

Page 33: Software Development Lifecycle Models

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 expendedon the requirements phaseduring the first Constructioniteration

Page 34: Software Development Lifecycle Models

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

Page 35: Software Development Lifecycle Models

Agile Methods

Agile is an iterative and incremental (evolutionary) approach to software development which [sic] is performed in a highly collaborative manner with "just enough" ceremony that produces high quality software which meets the changing needs of its stakeholders.

» http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

Page 36: Software Development Lifecycle Models

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

Page 37: Software Development Lifecycle Models

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

Page 38: Software Development Lifecycle Models

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

Page 39: Software Development Lifecycle Models

In class

• What are the advantages and disadvantages of having everyone at one site?

Page 40: Software Development Lifecycle Models

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

Page 41: Software Development Lifecycle Models

History• Evolved in the mid 1990s• Reaction against "heavyweight" methods such as waterfall

– Waterfall • Regimented and micromanaged• Bureaucratic, slow• Contradicts way SEs actually perform effective

work– Agile is a return to practices seen early in software

development• Is this good? Bad?

• 2001 meeting at Snowbird adopted name “agile” over “lightweight”

Page 42: Software Development Lifecycle Models

History• Extreme Programming (XP)

– Not first, but most popular– Established in 1966 by Kent Beck– Tried to save the Chrysler C3 project (but

didn’t)– 1999 Elements of Extreme Programming

Page 43: Software Development Lifecycle Models

Different Agile Methods

• Created prior to 2000– Scrum– Crystal Clear (1986)– XP (1996)– Adaptive Software Development– Feature Driven Development– DSDM (1885)

Page 44: Software Development Lifecycle Models

Some of the principles behind the Agile Manifesto

• Customer satisfaction by rapid (two weeks?), continuous delivery of useful 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 trusted. • Continuous attention to technical excellence and good design • Simplicity.• Self-organizing teams • Regular adaptation to changing circumstances

Page 45: Software Development Lifecycle Models

Adaptive vs Predictive Methods• Adaptive methods

– focus on adapting quickly to changing realities– difficulty describing exactly what will happen in the future– The further 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 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 and

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

Page 46: Software Development Lifecycle Models

In class

• List several characteristics of projects suitable for predictive methods and several characteristics of projects suitable for adaptive methods.

Page 47: Software Development Lifecycle Models

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

Page 48: Software Development Lifecycle Models

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 significant

integration problems– Delivers fully developed features (but small subset of them)

each development cycle

Page 49: Software Development Lifecycle Models

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 very

disciplined and rigorous) processes

Page 50: Software Development Lifecycle Models

Suitability of Agile Methods• Organization must support negotiation • People must be trusted • Requires higher competence• Organizations must live with the decisions

developers make • Organizations must support rapid communication • Suitable for projects with small teams, with fewer

than 20 to 40 people.

Page 51: Software Development Lifecycle Models

Agile vs Plan-drivenAgile• Low criticality • Senior developers • Requirements change very

often • 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

Page 52: Software Development Lifecycle Models

Problems with Agile• Push to get initial software working may result in

poor architecture, which is difficult to change• Client may be talked into poor choices by

developers• Single "dominant" developer may exert undo

influence• Depends on the ability of the customer to provide

negative feedback when necessary– In theory, the rapidly iterative nature should limit

problems, but it assumes that there's a negative feedback, or even appropriate feedback. If not, errors could be magnified rapidly.

Page 53: Software Development Lifecycle Models

Criticisms include:

• lack of structure and necessary documentation

• only works with senior-level developers • incorporates insufficient software design • requires too much cultural change to adopt • can lead to more difficult contractual

negotiations

Page 54: Software Development Lifecycle Models

Some of the well-known agile software development methods:

• Extreme Programming (XP) • Scrum • 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)

Page 55: Software Development Lifecycle Models

XP

• The main aim of XP is to reduce the cost of change.

Page 56: Software Development Lifecycle Models

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

Page 57: Software Development Lifecycle Models

Five Values of XP

• Communication• Simplicity• Feedback• Courage• Respect

Page 58: Software Development Lifecycle Models

Activities

• Coding• Testing• Listening • Designing

Page 59: Software Development Lifecycle Models

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 code

ownership– Simple design– System metaphor

• Programmer welfare– Sustainable pace

Page 60: Software Development Lifecycle Models

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