Date post: | 14-Jan-2016 |
Category: |
Documents |
Upload: | elvin-bailey |
View: | 218 times |
Download: | 1 times |
Slide # 1CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M05
August 1, 2006
SMU CSE 7315Planning and Managing a
Software Project
Module 05Software Lifecycles and
Processes
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 2
CSE7315M05
Goal of This Module
• To examine different kinds of software lifecycles / process models– Advantages and disadvantages– How to select
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 3
CSE7315M05
Software Lifecycles• The software lifecycle is the top level
view of the software process• The specific lifecycle chosen depends
on the software to be built - its goals and requirements and its intended uses
• Selection of the software lifecycle model(s) is a primary responsibility of a software manager
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 4
CSE7315M05
Recall that there are Many Possible Software Lifecycles
within a Project Lifecycle
Phase 2 Phase 3 Phase 4 Phase nPhase 1 ....c: Software
Lifecycle
b: Software Lifecycle
d: Software Lifecycle
a: Software Lifecycle
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 5
CSE7315M05
Tailoring the Software Lifecycle
• Generally one tailors a given lifecycle model to fit the specific needs of the software
• You may need several lifecycles corresponding to different kinds of software
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 6
CSE7315M05
You May Want to Construct a Matrix to Plan the Lifecycles
Lifecycle# 2
ProductsLifecycl
e# 3Lifecycl
e# 4Lifecycl
e# 1
Mission SW
Support SW
Factory Test SW
Simulator
X
X
X
X
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 7
CSE7315M05
This Chart May Help You Decide How to Group Software
ProductsMission Critical
Support IncidentalLife
Critical
Testing Deliverable Products
Throwaway
Part of a Deliverable Product
Reused in Deliverable
Products
Criticality of Function
A M O U N T
O F
U S E
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 8
CSE7315M05
Entry Criteria for aSoftware Lifecycle
• The Goal is defined and measurable– Throwaway or production or ???– Purpose, requirements, etc.
• The Requirements are allocated to the software– Suggestion: use a trace matrix to show
what requirements are associated with what software items
… continued
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 9
CSE7315M05
Entry Criteria for aSoftware Lifecycle
(continued)
• Intended use and end-users are clear
• Applicable standards of quality and such are clearly stated
• Deliverables are clearly known
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 10
CSE7315M05
Ideal Requirements • Complete (every requirement is known and
allocated)• Sufficient (every required feature is
specified)• Consistent (no requirements contradict
each other)• Unambiguous (only one possible
interpretation)• Testable (you can tell when they are met)
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 11
CSE7315M05
Actual Requirements
• Some requirements will be:– TBD (unknown - to be determined)– Wrong– Missing– Vague or unclear
• Some requirements will– Contradict others– Not be testable– Change in mid-stream
• Technology changes• Customer understanding of problem changes• Problem changes
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 12
CSE7315M05
Risk Management for Imperfect Requirements
• Define a process to accept requirements changes
• Assign someone to be responsible to manage requirements changes– including involvement of software staff
• Select lifecycle based on level of expected requirements stability
• Get ranges for TBD requirements• Work to eliminate wrong and missing
requirements
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 13
CSE7315M05
Interface Requirements• How does your software interface to
other parts of the system?• This is just as important as other
requirements• Make sure the interface requirements
are– Documented– Under Control– Contained in (or controlled by) a SINGLE
document or other control point
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 14
CSE7315M05
Who is Establishing the Requirements? All
Stakeholders!• End user -- will use the software• Champion -- will pay for it• Marketing -- will sell it• Accountants and Lawyers -- will protect
but may not understand the product or the process
• Political factors– Such as engineers -- who “know better”
than the customer
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 15
CSE7315M05
The Software ProcessThis is the detailed process for carrying out the
various steps of the software lifecycle model
Integration & TestDesign CodingRequirements
Unit TestWrite
Test CodeWrite Code
CodeWalkthrough
Lifecycle (Top Level
of SW Process)
More Detailed Software Process
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 16
CSE7315M05
Tailoring / Planning(concept)
DEFINE THE APPROACH
UNDERSTAND THE NEED
All Possible Software Lifecyclesand Processes
High Level Process(Software Lifecycle)
Specific Software Process
“V” ModelA General Model of Software Development
Requirements Analysis
Architecture Design
Detailed Design
Implementation
Unit Test
Integration Test
Acceptance Test
Test Cases Based on Requirements
Test Cases Based on Architecture
Test Cases Based on Design
Note: Test Planning Begins with
Requirements!
Note: Test Planning Begins with
Requirements!
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 18
CSE7315M05
Some General Categories of Lifecycle Models
• Linear: Do each step once, in order– Example: Waterfall model
• Incremental or Evolutionary: add to the product at each phase– Example: Spiral model
• Iterative: re-do the product at each phase
• Ad-Hoc: No set approach, do what seems appropriate at the time
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 19
CSE7315M05
Big-Bang Model (Ad-Hoc)
• Developer receives problem statement.
• Developer implements solution.
• Developer delivers result.
• Developer hopes client is satisfied.
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 20
CSE7315M05
Drawbacks of Big-Bang Model
• Little or no consistency between applications of the model– So hard to incorporate lessons learned
• Little or no discipline• Little or no documentation• Little or no transferability to others– So each developer learns on their own
Generally this model works well only for small software applications
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 21
CSE7315M05
Waterfall Model of theSoftware Process (Linear)
• Basic Idea: Software is developed in a series of phases that mimic the system lifecycle described above
• Goal: to develop, produce, and support a software product
Royce, Winston - several papers in the late 1960’s and early 1970’s outlined this model.
Royce knew of waterfall’s limitations.
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 22
CSE7315M05
Waterfall Model of theSoftware Lifecycle
RequirementsAnalysis
Design
Code
Test
Integrate
Rqmts Specs
Design Specs
Unit Tested Code
Tested Code
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 23
CSE7315M05
Waterfall Model of theSoftware Lifecycle
RequirementsAnalysis
Design
Code
Test
Integrate
Each phase ends with a review and/or signoff
Rqmts Specs
Design Specs
Unit Tested Code
Tested Code
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 24
CSE7315M05
Waterfall Model of theSoftware Lifecycle
RequirementsAnalysis
Design
Code
Test
Integrate
Rqmts Specs
Design Specs
Unit Tested Code
Tested Code
Each phase produces artifacts that are input to the next phase
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 25
CSE7315M05
Waterfall Assumptions
• Assumption 1: Good Requirements– system or other requirements have
been established (defined and validated);
– those requirements to be addressed by software are clearly defined
– requirements are allocated to all system components (software items)
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 26
CSE7315M05
More Waterfall Assumptions
• Assumption 2: A Good System Design– The system design is complete– Software has been fully identified– The software has been divided into
individual “products” or software items– Each software item can be developed
independently– Requirements are clearly allocated to
each software item– Interfaces are clearly defined
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 27
CSE7315M05
Typical Waterfall Phases
Exit Criteria
Software Requirements Specification (states what software must do and tests it must pass)
Software Design Specifications (sufficient to code the software)
Code Compiles
Code Passes Tests
Product Passes Tests
Phase
Requirements Analysis
Design - Preliminary - Detailed
Code
Test
Integrate
Goals
Translate Allocated Requirements into Specific, Detailed Software Requirements
Come up with a Design that will Implement the Requirements
Write the Code
Test the Code
Combine Code Units
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 28
CSE7315M05
Each Phase has Other Aspects
Reviews
SW Requirements Review
Software Design Review(s)
Code Review(s)
Test Reviews
Product Acceptance Test or Review
Phase
Requirements Analysis
Design
Code
Test
Integrate
Goals
Determine What the SW should Do
Determine How to do it
Do It
Does Code Work?
Does Product Work?
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 29
CSE7315M05
An Important Conceptin the Waterfall Model
• Different groups could be assigned to each phase without loss of performance or time
• This concept is the reason behind some of the documentation and review requirements
• This is a good concept in general because on a big project it may be very realistic
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 30
CSE7315M05
Problems with the Concept
• This concept is unrealistic in many cases– It is overkill for small projects– It can be costly for any size project
• The organizational structure may or may not fit these assumptions– does each phase have a different
organization?
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 31
CSE7315M05
Suggested Student Study
• Determine the milestones, entry criteria, exit criteria, and goals for each phase of the waterfall model
• Use waterfall as a basis for looking at other models – Most are described in terms of how
they differ
NOTE: the essence of the waterfall model is not the names of the specific phases, but rather the
fixed, sequential nature of the phases
NOTE: the essence of the waterfall model is not the names of the specific phases, but rather the
fixed, sequential nature of the phases
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 32
CSE7315M05
Waterfall Model Benefits
• Intuitive, logical, basic structure• Tells what, not how• Includes all of the basic tasks of
software development• Adaptable to many situations by
making simple changes or tailoring
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 33
CSE7315M05
Waterfall Model Drawbacks:Waterfall Assumes that:
• Requirements are clearly understood– But they change with time (technology, customer
needs, customer understanding of problem)– As we develop we gain insight
• Phases occur sequentially– But errors may require going back to fix– Overlapping phases can be more efficient
• The customer can understand the requirements specification and verify that it is correct– Prototyping and technical interchange may be
necessary in practice
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 34
CSE7315M05
Waterfall Model with Backflow
RequirementsAnalysis
Design
Code
Test
Integrate
Rqmts Specs
Design Specs
Unit Tested Code
Tested Code
This is what actually happens in practice
with most applications of the
model
This is what actually happens in practice
with most applications of the
model
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 35
CSE7315M05
The Waffle Principle
• “Plan to throw the first one away; you will anyhow.”
Fred Brooks, “The Mythical Man-Month: Essays on Software Engineering”, Addison Wesley, 1975.Revised in 1995.
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 36
CSE7315M05
Spiral Model (Incremental or Iterative)
• Originated by Barry Boehm in the 1970’s
• Basic idea: software is developed as a series of successively more capable prototypes, each of which is designed to build on the previous stages and to address the areas of highest riskBoehm, Barry, “A Spiral Model of Software Engineering,”
IEEE Transactions on Software Engineering, 197?
Prof. Barry
Boehm
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 37
CSE7315M05
Spiral Model (continued)
• Goal: same as waterfall: to develop, produce and support a software product
• Difference: an evolutionary series of small steps rather than a single sequence
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 38
CSE7315M05
Spiral Model
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 39
CSE7315M05
Spiral Assumptions
1) Intial requirements are established but may change based on results of prototypes
2) Good design, allocation – but may also change
3) (new) You know how to identify, analyze, and rank the risks associated with the project
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 40
CSE7315M05
Spiral Advantages
• Accommodates changes in requirements
• Facilitates risk management• Supports various forms of
incremental and evolutionary development
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 41
CSE7315M05
The “Cycles of Learning” Benefit
• You learn a lot during each iteration, which makes the next one more efficient
• Studies show that by the third or fourth iteration (when you are doing the bulk of the actual work), the development team is functioning very effectively– And the total time may be less than
one “big” iteration, as in the waterfall
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 42
CSE7315M05
Spiral Drawbacks• Admits lack of understanding– May be hard for management and
customers to accept)• Does not allow good synchronization
with other parts of the project• Hard to tell exactly where you are
and how much you have left to do– No exit criteria or time-based
milestones• Harder to manage• Can be costly - lots of “throwaway” code
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 43
CSE7315M05
Controlled-Iteration Model
• Four phases per major cycle– Inception: Negotiate and define product for
this iteration– Elaboration: Design– Construction: Create fully functional
product– Transition: Deliver product of phase as
specified• The next phase is started before the end of
the previous phase (say at 80% point).
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 44
CSE7315M05
Rational Unified Process(a form of controlled iteration)
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary Iteration(s)
Iter.#1
PhasesProcess Workflows
Iterations within phases
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 45
CSE7315M05
Rapid Application Development (RAD) (Incremental
or Iterative)• An extension/extrapolation of the spiral
model• Evolved in the 1980’s and 1990’s among
developers of software for the mass market and networks (e-commerce)– Need products quickly– Products often have short lifetimes– Requirements change very rapidly– The system/environment is fluid
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 46
CSE7315M05
DefinitionRapid Application Development
(RAD)
• A collection of programming tools and methods that enables quick production of working software
• Key elements of RAD include:– use of short, incremental development
cycles– libraries of pre-compiled, commonly used
components, such as user interface elements
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 47
CSE7315M05
RADRequirements
Analysis
Design
Code
Test
Integrate
Rqmts Specs
Design Specs
Unit Tested Code
Tested Code
Design
CodeTest
Integrate
RequirementsAnalysis
ComponentLibrary
Artifacts On-lineAnd Dynamic
Rqmts Specs Design
Specs
Code
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 48
CSE7315M05
RAD Assumptions
• Interface requirements are established early and kept relatively firm• Application requirements and
system design are fluid• Risks of quality problems are
mitigated by short product life cycles and opportunity to correct in next release
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 49
CSE7315M05
Advantages of RAD Model
• Accommodates Changes in Requirements– Each iteration can accommodate new
information about the requirements
• Produces a usable product on each iteration
• Deals effectively with the biggest risk in this specific type of software – failing to meet market windows!
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 50
CSE7315M05
The “Cycles of Learning” Benefit
• Even more than with the spiral model, you learn a lot during each iteration, which makes the next one more efficient
• Reuses proven components, so you don’t spend time reinventing
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 51
CSE7315M05
Drawbacks of the RAD Model• Hard for outsiders to understand
where you are• Can be chaotic if not managed
effectively• Comprehensive quality checks and
testing are not normally part of the process• Many documents and artifacts are
not produced or not permanent, so long term maintenance can suffer
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 52
CSE7315M05
Extreme Programming (XP) (Incremental or Iterative)
• A “lightweight” discipline of software development derived from object oriented programming and based on these principles:– Simplicity– Communication among developers– Feedback– Courage!
• Originated with the “C3” project at Chrysler Corporation in 1997
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 53
CSE7315M05
Simple Definition of XP
• A highly iterative form of RAD where the focus is on minimalism– Evolutionary design rather than
planned design• 3-week cycles are typical, even for large
projects• Don’t plan ahead because you will
probably be wrong
– Do only what must be done now - add functionality in later iterations
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 54
CSE7315M05
XP Assumptions
• Small, co-located teams• Customers will change their minds• A perfect product cannot be
produced, so get something out and then improve it
• Close customer contact with programmers
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 55
CSE7315M05
Key XP Practices
• Refactoring - ongoing redesign to respond to change
• Test first, then code• Pair programming - two people
inspect each others’ work• Continuous integration - daily
builds to solidify interfaces early
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 56
CSE7315M05
XP Drawbacks• Simplicity is not always easy to
accomplish• It is easy to drop the discipline and
descend into “hacking”• It doesn’t scale well to really large
projects• The whole thing hinges on the
developers understanding the problem well - no design specs to work from!
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 57
CSE7315M05
Summary of Module
• The lifecycle model is the top level view of the process
• There are many different software lifecycle models
• A process/lifecycle must be tailored to fit the needs of the specific project
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 58
CSE7315M05
END OFMODULE 05
Slide # 59CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and Processes Copyright © 1995-2006, Dennis J. Frailey, All Rights Reserved CSE7315M05
August 1, 2006
Appendix
Other Models
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 60
CSE7315M05
R = Understand RequirementsD = DesignI = ImplementE = EvaluateThese are the Basic Steps of
Any Development EffortEssentially Similar to One
Turn of the Spiral Model or One Cycle through the
Waterfall
Tornado Model – A Meta Model
Basic Development Cycle
R
I
DE
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 61
CSE7315M05
Tornado ModelSequential Application
• This application is like the spiral model
• Incremental development: each cycle adds new features
• Evolutionary development: each cycle improves the previous one
R
I
DE
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 62
CSE7315M05
Tornado ModelOther Applications
• Requirements– Simulation or prototype– To analyze alternatives
or quantify risks
• Design– Build a prototype– Test out a concept
• Implementation– Two incremental pre-
releases
R
I
DE
R
I
DER
I
DE
R
I
DE
R
I
DE
August 1, 2006
CSE 7315 - SW Project Management / Module 5 - Software Lifecycles and
ProcessesCopyright © 1995-2006, Dennis J. Frailey,
All Rights Reserved
Slide # 63
CSE7315M05
Other Models(Look on the Web – the URLs change to often to list here)
• Fountain model• SCRUM model• Ropes model• Time Box model• …