Handout-Software Lifecycle Models
-
Upload
madinatul-arradhika -
Category
Documents
-
view
221 -
download
0
Transcript of Handout-Software Lifecycle Models
-
8/8/2019 Handout-Software Lifecycle Models
1/60
Software Development Lifecycle
Models
Fall 2009
-
8/8/2019 Handout-Software Lifecycle Models
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?
-
8/8/2019 Handout-Software Lifecycle Models
3/60
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
5/60
Some Models Code and fix
Waterfall
Prototyping RAD
Incremental/evolutionary
Reusable components
Automated synthesis Spiral
XP
-
8/8/2019 Handout-Software Lifecycle Models
6/60
0. Code and Fix (aka cowboy) Repeat
write code
fix it
Until code is good enough or resources
exhausted
-
8/8/2019 Handout-Software Lifecycle Models
7/60
In class What are the pros and cons of this
approach?
(2 minutes)
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
9/60
Waterfall Phases
Feasibility
Specify
Requirements
Design
Implement
Test
Deliver
Maintain
-
8/8/2019 Handout-Software Lifecycle Models
10/60
Feasibility Study
feasibility study
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
12/60
Design design (preliminary and detailed)
decompose system into modules, selection of a
software architecture top-down, iterative
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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)
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
16/60
In Class Clearly, waterfall has advantages over code
and fix.
There are many criticisms of waterfall: what
are they?
(3 minutes)
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
18/60
In Class How is this better than waterfall?
What are the costs?
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
23/60
In Class What problems are we trying to fix with this
method?
What pitfalls arise?
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
26/60
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
29/60
-
8/8/2019 Handout-Software Lifecycle Models
30/60
Driving Forces waterfall: documentation driven
evolutionary: increment driven
transformational: specification driven
spiral: risk driven
-
8/8/2019 Handout-Software Lifecycle Models
31/60
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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).
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
39/60
In class What are the advantages and disadvantages
of having everyone at one site?
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
43/60
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
46/60
In class List several characteristics of projects
suitable for predictive methods and several
characteristics of projects suitable foradaptive methods.
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
50/60
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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.
-
8/8/2019 Handout-Software Lifecycle Models
53/60
-
8/8/2019 Handout-Software Lifecycle Models
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)
-
8/8/2019 Handout-Software Lifecycle Models
55/60
XP
The main aim of XP is to reduce the cost of
change.
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
57/60
-
8/8/2019 Handout-Software Lifecycle Models
58/60
Activities
Coding
Testing
Listening
Designing
12 XP P i
-
8/8/2019 Handout-Software Lifecycle Models
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
-
8/8/2019 Handout-Software Lifecycle Models
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