Development Models
Terry Sloan, EPCC
Development Models
4All software development makes use of some
form of development model
– Usually one of the two traditional models
• Code-Like-Hell
• Waterfall
4Assume standard tasks in a project
–
–
–
–
–
–
Software concept
Requirements analysis
Architectural design
Detailed design
Coding and debugging
System testing
2
1
The Code-Like-Hell Model
4Assume no time is available for structured
development
– So forget requirements and design
4Development occurs through a cycle of code debug - recode
– Eventually degenerating into code - code - code
4May work for small projects
– Efficiency may not be maximum
4Used for projects far larger than it is suitable
for
– If there are any
3
The Waterfall Model
4
2
The Waterfall Model Features
4The traditional structured approach
4Emphasises quality over cost and time
constraints
4Each stage is marked by a set of deliverables
– Documents in the early stages
– Documents and deliverable code in the later stages
4Stages are discontinuous
– Finish one before starting the next
4Swimming upstream is possible, but hard
5
The Waterfall Model Advantages
4Good for well understood projects with
concrete requirements
4Tackles complexity in an orderly manner
4Is a simple model to follow
4Better than Code-Like-Hell...
6
3
The Waterfall Model Disadvantages
4Shows many signs of being an RIP (Rigid
Inefficent Process)
4Does not take into account cost or time
constraints
4Does not respond to changing requirements
4Low visibility for the customer
– No tangible deliverables until the end of the project
7
Limitations of Traditional Models
4Code-Like-Hell should never be used
4Waterfall is not useful for most “real” projects
– Most projects are carried out under a range of constraints
•
•
•
•
•
Customer
Changing requirements
Cost
Political factors
etc...
– Waterfall is not flexible enough to cope with such factors
8
4
Extending Waterfall
4For Waterfall to be useful, it must be modified
to be more flexible
–
–
–
–
Overlapped Waterfall
Waterfall with Subprojects
Staged Delivery
Design to Schedule
9
Overlapped Waterfall
10
5
Overlapped Waterfall Features
4Development is now carried out in phases
rather than stages
4Phases overlap each other quite considerably
– e.g. Coding can be underway before architecture is complete
4Produces less documentation than Waterfall
11
Overlapped Waterfall Advantages
4Handles changes more easily
– Less cost in making changes as earlier phases are still in
development
4Acknowledges that early designs are rarely
right
– Starting coding before design is complete allows flaws to be
corrected at less cost
– Early work on coding also passes useful information back to
design
4Produces visible progress to the customer
earlier
12
6
Overlapped Waterfall Disadvantages
4Overlapped phases reduce developers’ project
visibility
– Milestones are more ambiguous
– Harder to track progress
– Easier to end up with quick (poor) fixes incorporated into
design
4Where the project is well defined and not
subject to change, can be less efficient than
Waterfall
13
Waterfall with Subprojects
14
7
Waterfall with Subprojects Features
4Subprojects begin after architecture is defined
and relations between application areas are
relatively settled
4Acknowledges that some areas of system are
more complex than others
– Why wait to start on the simple design areas?
– Make progress on the simpler parts of the architecture whilst
complex parts are still being developed
15
Waterfall with Subprojects Advantages
4Has benefits over Overlapped Waterfall
– More project visibility and control
4Has benefits over straight Waterfall
– Exploits modularity of project
– Users can see more visible signs of progress
• Early completion of GUI components can occur whilst internals
are still in design
16
8
Subprojects Waterfall Disadvantages
4Design of the architecture is crucial
4Dependencies between subprojects can have
a bad impact
4Requires more project management to work
successfully
17
Waterfall Models Shortfalls
4Most waterfall models treat the stages of
development as disjoint and sequential
activities
– Most effective software development is iterative
• i.e. models that specify multiple completion stages through
recourse
– In practice most waterfall models have some element of the
overlapping waterfall in their use
• There is no explicit iteration built into overlapping the stages
though
• This becomes a fuzzy area in the model
18
9
Iterative Models
4Three iterative models to examine
– Staged Delivery Waterfall
• Design to Schedule variant
– Evolutionary Prototyping
– Evolutionary Delivery
19
Staged Delivery
20
10
Staged Delivery Features
4Architecture is implicitly defined to allow
incremental design and implementation
4Design and implementation is performed in a
number of stages
4Each stage culminates in a working code
release
21
Staged Delivery Advantages
4Results in good project visibility
– Easier to schedule and track a number of small releases
4Flaws in the design can be picked up at an
early stage
4Allows for specification changes in subsequent
releases
4Gives tangible results to the end-user early in
the project
22
11
Staged Delivery Disadvantages
4Relies heavily on careful management and
architectural design
4For staged delivery to work all module
development needs to be strongly coordinated
– Integration can be a significant overhead otherwise
4Although customer visibility is excellent,
customers must be made aware that earlier
releases will have greater visible changes than
later
– Otherwise they worry that work has stopped
23
Design to Schedule Variant
4A variation of Staged Delivery
4Project has a hard deadline
4Order features in terms of importance
– Implement critical features in earliest releases
– Implement less important features if there is time
4Stop with latest release when time runs out
4Good news:
– Pretty good if lacking estimation skills
4Bad news:
– Bad priorities = bad project
24
12
Evolutionary Prototyping
25
Evolutionary Prototyping Features
4An iterative approach for projects without a
proper initial concept
4Developing system as user requirements
resolve/evolve
4Develop system elements in a prototype
– Show this prototype to the customer
– Customer’s feedback allows development of the next iteration
– Iterative loop continues until customer is satisfied
4Prototype is then evolved into the full product
and released
26
13
Evolutionary Prototyping Advantages
4Suits rapidly changing or poorly understood
requirements
– Suits a project in which the development areas are not well
known to the developers
4Provides the end-user with clear signs of
progress
4Also gives the end-user a sense of control over
the project’s progress
27
Evolutionary Prototyping Disadvantages
4Vulnerable to deterioration into the Code-LikeHell model
– The Process still needs requirements, architecture and
industrial quality design
– These just occur in smaller increments
4Very hard to set deadlines and make time
estimates
– Customers must be prepared for this
28
14
Evolutionary Delivery
29
Evolutionary Delivery Features
4A trade-off between Evolutionary Prototyping
and Staged Delivery
4Develop a product version and show it to the
user
4The user’s comments are used to refine the
product’s design
4Approach is similar to Evolutionary Prototyping
but with a difference in emphasis
– In Evolutionary Prototyping, visuals come first
– In Evolutionary Delivery, code which is unlikely to change
comes first
30
15
Evolutionary Delivery Pros and Cons
4Advantages:
– Allows more flexibility than Staged Delivery
– Allows more control than Evolutionary Prototyping
– Shift in emphasis allows a trade-off in either direction
4Disadvantages:
– Perhaps idle time while waiting for the customer to try and give
feedback
• Must find other things to do meanwhile (e.g. documentation)
• Still hard to tell when you are finished (to a lesser extent)
31
Development Models and Small Projects
4Small projects tend to exhibit the following
characteristics:
– Novel computing
• Complex and with little developer expertise in the subject
• Subject to changing requirements and customer opinions
– Small team sizes
– Cost, time and quality constraints all usually apply
– Risk is in the constraints, the complexity and novel nature of
the application
32
16
Choosing Development Models
4Changing requirements mean than Waterfall is
unsuitable
4Cost, time and quality constraints all cause
non-incremental models to be unsuitable
(Waterfall with Subprojects)
4Evolutionary prototyping too risky (very
vulnerable to Code-Like-Hell syndrome)
33
Choosing Development Models (cont)
4This leaves us with the following suitable
models:
– Staged delivery
– Design to schedule
– Evolutionary delivery
4These three models exhibit versatility
– Between projects
– In mid-project
4All have a reasonably low management
overhead
4All offset more risk than they create
34
17
Development Models - Conclusion
4The development model choice is important for
project success
– But less important than implementing the chosen model well
4Remember that all Process has to be
implemented well to be effective
35
18