1. Software Development Lifecycle Models
Fall 2010

2. 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. One view Requirements Elicitation Requirements analysis
Requirements specification
Prototyping
Architectural design
Detailed design
Implementation
Unit testing
Integration testing
System testing
Delivery
Maintenance

4. What is a lifecycle model?

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

6. 0. Code and Fix (aka “cowboy”)
Repeat
write code
fix it
Until code is good enough or resources exhausted

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

8. Waterfall Requirements Elicitation Requirements analysis
Requirements specification
Prototyping
Architectural design
Detailed design
Implementation
Unit testing
Integration testing
System testing
Delivery
Maintenance

9. Waterfall Phases Feasibility Specify Requirements Design Implement
Test
Deliver
Maintain

10. Maintain (evolution?) Corrective: (fix bugs) 12% = “emergency fixes”
9% = routine debugging
Adaptive: (secondary changes)
17% = change data formats
6% = hardware changes
Perfective (improve)
5% = improvements in documentation
4% = improvements in efficiency
  42% = change user requirements
Preventive (form of Perfective)

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

12. 3. RAD Rapid application development: Used for
short development cycle based on components and 4GLs.
Used for
Modeling: business, data, and process
Application generation
Testing/installation

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

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

15. Update Test documentation
Incremental Development
Iteration No. 1 2 3
867
868
Update SPMP1
Test whole
Integrate
Update Test documentation
Test units
Update source code
Implement
Design
Update SDD2
Analyze
requirements
Update SRS3
1 Software Project Mangement Plan (chapter 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.

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

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

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

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

20. Spiral Model
Rapid prototype
Specification
Planning
Design
Implementation
Integration
Objective setting: for each phase--identify constraints, risk, management plan
Risk Assessment and reduction
Develop and Validate
Planning: review project and decide whether to continue further in loop.
Risk
Analysis
Verify
Test

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

22. Driving Forces waterfall: documentation driven
evolutionary: increment driven
transformational: specification driven
spiral: risk driven

23. Classification of iterations (Classically called “phases”)
USDP vs. Standard Terminology (Booch, Jacobson & Rumbaugh)
Classification of iterations
Individual iteration
Inception
Elaboration
Construction
Transition
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k ..
….. …
Requirements
Analysis
USDP calls these
“core workflows”
(Classically called “phases”)
Design
Implementation
Test

24. Requirements analysis
USDP vs. Standard Terminology 2 of 2
USDP Terminology
Classical Terminology
Requirements
Analysis
Requirements analysis
Design
Implementation
Test
Design
Implementation
Integration
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

25. Unified Process Matrix
Jacobson et al: USDP
Inception
Elaboration
Construction
Transition
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k ..
…..
…..
Requirements
Analysis
Amount of effort expended
on the requirements phase
during the first Construction
iteration
Design
Implementation
Test

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

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

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

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

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

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

32. 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”

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

34. Different Agile Methods
Created prior to 2000
Scrum
Crystal Clear (1986)
XP (1996)
Adaptive Software Development
Feature Driven Development
DSDM (1885)

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

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

37. Agile Contrasted with Iterative
Build releasable software in short time periods
Iterative time frames measured in months
Agile
Time frame in weeks
Time frame is strict

38. Agile Contrasted with 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

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

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

41. Agile vs Plan-driven Plan-driven Agile High criticality
Junior developers
Low requirements change
Large number of developers
Culture that demands order
Agile
Low criticality
Senior developers
Requirements change very often
Small number of developers
Culture that thrives on chaos

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

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

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

45. Five Values of XP
Communication
Simplicity
Feedback
Courage
Respect

46. Activities
Coding
Testing
Listening
Designing

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