Transcript Software Development Lifecycle Models Fall 2010

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 agencies
mandate 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 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)
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
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
2 Software Design Document (chapter 5);
Project Mangement Plan (chapter 2);
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
lookup 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 construction, proofs as
programs
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
Spiral Model
1.
2.
3.
4.
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
Rapid prototype
Specification
Planning
Design
Implementation
Integration
Verify
Test
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
USDP vs. Standard Terminology (Booch, Jacobson &
Rumbaugh)
Classification of iterations
Individual iteration
Inception Elaboration Construction
Transition
Prelim. Iter. .. Iter. Iter. ….. Iter. Iter. … Iter.
#k
iterations #1
#n #n+1
#m #m+1
Requirements
Analysis
USDP calls these
“core workflows”
Design
Implementation
Test
(Classically called
“phases”)
USDP vs. Standard Terminology 2 of 2
USDP
Terminology
Classical
Terminology
Requirements
Requirements analysis
Analysis
Design
Design
Implementation
Implementation
Integration
Test
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Unified Process Matrix
Jacobson et al: USDP
Inception Elaboration
Construction
Prelim. Iter. .. Iter. Iter.
iterations #1
#n #n+1
Requirements
Analysis
Design
Implementation
Test
…..
Transition
Iter. Iter. …..
#m #m+1
Amount of effort expended
on the requirements phase
during the first Construction
iteration
Iter.
#k
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 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/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 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
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 true
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”
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
Different Agile Methods
• Created prior to 2000
–
–
–
–
–
–
Scrum
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 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
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.
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 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
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
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.
Agile vs Plan-driven
Agile
• 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
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)
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 Values 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 code
ownership
– Simple design
– System metaphor
• Programmer welfare
– Sustainable pace