introduction requirements and the software lifecycle (3)
DESCRIPTION
Different Types of Lifecycles Code and Fix Stepwise Process Waterfall Method Spiral Method Iterative Method Agile Method Copyright Leffingwell, Widrig, & SIS FacultyTRANSCRIPT
IntroductionRequirements and the Software Lifecycle (3)
Software Lifecycle•What is the software lifecycle
▫Who (is doing what task)▫What (is the task they are doing)▫When (is the task being performed)▫How (is the task being performed)
What are all the steps
Copyright Leffingwell, Widrig, & SIS Faculty
Different Types of Lifecycles•Code and Fix•Stepwise Process•Waterfall Method•Spiral Method•Iterative Method•Agile Method
Copyright Leffingwell, Widrig, & SIS Faculty
Code and Fix •The original software design process•Start coding your product •Correct until the product is complete•Works for very simple projects
▫Sufficient for the type of projects of the time
•Problems ▫Major limitations to small projects ▫Could run into major design issues as you
are coding •Still used in some capacity during the
development phaseCopyright Leffingwell, Widrig, & SIS Faculty
Stepwise Process•Dates back to as early as the 1950’s•Provided the necessary steps to design
software
•Problem is ▫It was unidirectional▫Define all the requirements upfront▫Complete every step in its entirety ▫No feedback built in
Copyright Leffingwell, Widrig, & SIS Faculty
Waterfall Method•Formally introduced in 1970’s by Royce•Included feedback loops to the stepwise
process•Recognized the fact that lessons learned
should be used to fix future problems•Not included in the figure is prototyping
which Royce introduced
Copyright Leffingwell, Widrig, & SIS Faculty
Waterfall Method•Figure 3-1
Copyright Leffingwell, Widrig, & SIS Faculty
Waterfall Method•Delayed easily by rigid company guidelines
•Requirements are frozen so they cannot be changed
•Loose touch with the real world in which they are building the application for
•As projects reach budget limits some latter steps might be shortened to produce an on time and on budget project
Copyright Leffingwell, Widrig, & SIS Faculty
Waterfall Method• Why did it come about
▫ Discovered the rework from fixing bugs later in the cycle was more costly.
• Why wasn’t it ideal?▫ Still a linear process▫ Requires Complete system definition ▫ Typically produced software that is
Low quality Over budget and past deadlines
• What was the result?▫ Regression to coding first▫ Agile methods
Copyright Leffingwell, Widrig, & SIS Faculty
Requirements Handling
0
5
10
15
20
25
30
35
40
10 100 1000 10000Project Size in Function Points
Req
uire
men
ts c
hang
e
Changing increases with project sizeOne reason why the waterfall process is not effective
Copyright Craig Larman & SIS Faculty
Spiral Method•Introduced by Boehm in 1988
•This was more of a risk driven and incremental development path▫Starts with risk-driven prototypes▫Then follows a waterfall type process
Copyright Leffingwell, Widrig, & SIS Faculty
Spiral Method•Benefits
▫Feedback right away with your designs This is also referred to today as rapid
prototyping▫Receive quality feedback from the User early ▫Starts with requirement and concept
validation▫Has multiple feedback opportunities early on
Get out all the “Yes, buts”
Copyright Leffingwell, Widrig, & SIS Faculty
Spiral Method•Issues
▫Can create different code streams/branches from the very beginning
▫Rapid prototypes can lead the user believe that the system is almost complete
▫Very time and resource heavy of creating prototypes and following the waterfall process
Copyright Leffingwell, Widrig, & SIS Faculty
Spiral Method•Figure 3-2
Copyright Leffingwell, Widrig, & SIS Faculty
Iterative Process•Introduced in 1990s•Is like doing numerous mini-waterfalls•Lifecycle
▫Inception = Analysis▫Elaboration = Design▫Construction = Code▫Transition = Test, Implement, …
Copyright Leffingwell, Widrig, & SIS Faculty
Iterative Process
inc. elaboration construction transition
iteration phase
development cycle
release
A stable executable subset of the final product. The end of each iteration is a minor release.
increment
The difference (delta) between the releases of 2 subsequent iterations.
final production release
At this point, the system is released for production use.
milestone
An iteration end-point when some significant decision or evaluation occurs.
Copyright Craig Larman & SIS Faculty
Iterative Software Development Process
Requirements
Design
Implementation &Test & Integration
& More Design
Final Integration & System Test
Requirements
Design
3 weeks (for example)The system grows incrementally.
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
Iterations are fixed in length, or timeboxed.
TimeImplementation &Test & Integration
& More Design
Final Integration & System Test
Each Iteration is a min-waterfall processCopyright Craig Larman & SIS Faculty
Timeline
Iterations
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Focus of this book
Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.
This example is suggestive, not literal.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.
Copyright Craig Larman & SIS Faculty
Timeline
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
...
The relative effort in disciplines shifts across the phases.
This example is suggestive, not literal.
incep-tion elaboration construction transi-
tion
...
Copyright Craig Larman & SIS Faculty
Requirements Definition
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
20%2%
requ
irem
ents
softw
are
30%
5%
requ
irem
ents
softw
are
50%
8%
90% 90%
20%10%
requirements workshops
Imagine this will ultimately be a 20-iteration project.
In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.
1 2 3 4 5 ... 20
week 1
M T W Th F
week 2
M T W Th F
week 3
M T W Th F
kickoff meeting clarifying iteration goals with the team. 1 hour
team agile modeling & design, UML whiteboard sketching.5 hours
start coding & testing
a 3-week iteration
de-scope iteration goals if too much work
final check-in and code-freeze for the iteration baseline
demo and 2-day requirements workshop
next iteration planning meeting;2 hours
Most OOA/D and applying UML during this period
Use-case modeling during the workshop
Copyright Craig Larman & SIS Faculty
Iterative Process•Creating or modifying an existing module
•Creating the systems piece by piece over time
•The users will see new functionality after each iteration
Copyright Craig Larman & SIS Faculty
Iterative SW Success•What are the factors that lead to success
with the Iterative Process▫Good initial architecture▫Library of units tests▫Refactoring▫Automated tools
Copyright Craig Larman & SIS Faculty
Refactoring Early iterations are farther from the "truepath" of the system. Via feedback andadaptation, the system converges towardsthe most appropriate requirements anddesign.
In late iterations, a significant change inrequirements is rare, but can occur. Suchlate changes may give an organization acompetitive business advantage.
one iteration of design,implement, integrate, and test
Copyright Craig Larman & SIS Faculty
Benefits of the Iterative Process
•Higher project success rate▫Easier to manage complexity▫Better mitigation of high risks▫Easier adaptation to changing requirements
•Lower defect rates•Higher productivity•Increased visibility (Management, Client)•Knowledge from previous iterations
applied to future iterations•No code is thrown away in prototypes
Copyright Craig Larman & SIS Faculty
Important Practices•Tackle hi-risk/hi-priority early•Continuously engage users•Build core early•Test throughout to ensure quality•Focus on essential models using UML•Manage reqs. using Use Cases•Implement sound change &
configuration management
Copyright Craig Larman & SIS Faculty
Agile Methodology•Eliminate as many unnecessary processes as
possible
•Believes in Verbalize instead of documenting▫Usually only with small teams▫Usually only with small projects
•There are versions for larger more complex projects and project teams ▫Starts to look like the iterative process