2
This lecture probes into rapid development analysing some of its core issues. The lecture then investigates an important aspect of software development - lifecycle models
Covers Chapter 6 and Chapter 7 Steve McConnell, Rapid Development: Taming Wilde
Software Projects, Microsoft Press, ISBN 1-55615-900-5, 1996
4
Does One Size Fit All? The first step towards schedule-oriented development
practices is to understand some of the issues that lie at the heart of rapid development
Different projects have different rapid development needs, even when they all need to be developed as fast as possible
On-line game Life support system
Product development is more careful Product widely distributed Reliability is important
6
What Type Of Rapid Development Do You Need?
What do you need? Slight speed edge, more predictability, better progress
visibility, lower cost, more speed at all costs
Determine the type of rapid development needed by asking
How strong is the schedule constraint of the product? Rapid development look-alikes? Are project weaknesses preventing the application of rapid
development success?
7
continued … Products with strong schedule’s constraint
E.g.,if your product doesn’t make it for the Christmas sale, then the product release may be delayed (product might be even worthless)
PR of a product launch already started
Rapid development look-alikes E.g., if a company has a history of running late, then what really
may be required is better project management, or better risk management rather than rapid development
Lowest cost, may not be achieved by shortest schedule but by a somewhat longer schedule with a smaller team
…
Are project weaknesses preventing a rapid development success?
On time - but low quality product Not on time – but a killer product
8
Odds Of Completing On Time One view of software-project estimation
Every project has one exact time at which it should be completed If the project is run well than there is a 100% chance to complete
the project on a particular date
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
10
Perception And Reality
Even if a project is completely on schedule it might be perceived as slow development
It is useful to provide steady signs of progress to the customer
Aim for increased visibility
Unrealistic customer expectations If the average project is scheduled in the impossible zone
and completed in the efficient zone (which is good) the project is still perceived as being late
Here perception is a consequence of poor planning and poor estimation
11
continued …Overcoming the perception of slow development
Address the reality of slow development Make the actual schedule shorter moving from
Slow development to efficient development Efficient development to rapid development
Address the perception of slow development Eliminate wishful thinking Make planned schedules more realistic Use practices that highlight progress visibility
Sometimes both problems need to be addressed at the same time
12
Where The Time Goes
Architecture, design
Detailed designCode and debugUnit testIntegrationSystem test
10%20%25%20%15%10%
30%20%10%5%20%15%
ActivitySmall project
(2,500 lines code)Large project
(500,000 lines code)
Classical View (after requirements)
13
Where to save time … Software industry is only about 35% efficient, so 65% of
time is wasted in some way (Jones 1994)
Rework – may consume 40%-50% of the total cost of software development (Jones 1986, Boehm 1987)
Feature creep – projects may experience about 25% change in requirements (Jones 1981, Boehm 1994)
Requirements specification – typically 10%-30% of overall development time
The fuzzy front end – time spent between the first glimmer (idea) of a software product to the official go-ahead
14
Development-Speed Trade-Offs It is usually not possible to optimise schedule, cost and
features at the same time
Schedule, cost and product trade-offs Product includes quality, features, defect rate, etc.
Quality trade-offs Low defect rates – short development time (requires no trade-
off) Usability, robustness, reliability, etc. (can require trade-off)
Per-person-efficiency trade-off Smaller teams are often more efficient Increased team size increases total productivity, but decreases
individual productivity
15
Typical Schedule-Improvement Pattern
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
TypicalProject
Ideal RapidDevelopment
EfficientDevelopment
Real Life RapidDevelopment
16
Towards Rapid Development Lifecycle planning Estimation Scheduling Customer oriented development Motivation Teamwork Team structure Feature set control Productivity tools Project recovery
18
Lifecycles - Introduction A lifecycle model is a prescriptive model of what should
happen between the first glimmer and the last breath of a (software) project
It establishes the order in which a project specifies, prototypes, designs, implements, reviews, tests, and performs other activities
Choosing a lifecycle for a project has the same influence over the success of a project than any other planning decision made
The right choice can streamline your project and help to approach your goal in a sequence of successful steps
20
continued … Strategic study
Define possible IS contributions to the objectives of the enterprise Identification of candidate applications
Feasibility study Examination and comparison of candidate applications
Economic, technical, operational issues Output: feasibility report
Recommends possible solution and comments whether detailed analysis should commence
From this detailed systems project are initiated
Physical systems analysis Start of a detailed systems investigation of the current system and the
requirements of its successor Output: requirements analysis document
21
continued … Logical systems definition
Development of required system (models for data, processes and events) Output: requirements specification document
Logical systems design Logically defining data structures (normalisation), and definition of detailed
processes Output: logical design document
Physical systems design Development of physical inputs and outputs, e.g., files, programs, databases Output: physical design
Implementation Testing of programs and systems, development of support manuals and
documentation, training courses, phasing in of the new system into the organisation
Maintenance Implementation of amendments and omissions, new requirements, new
hard/software
23
continued … Basis for most models (starting point) Orderly sequence of steps
Review at the end Does not proceed until goals are met Phases do not overlap
Document driven Works well
Stable product definition Well understood, complex problems All planning is done upfront Quality dominates cost and schedule Technically weak staff
Disadvantages Poor visibility No tangible results until the end Sensitive to midstream changes Not flexibility Usually it is not possible to fully specify requirements at the start (before any design)
In reality activities often overlap
24
Salmon Waterfall Model
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
25
Code-And-Fix
Quite common Jump straight into coding If you don’t use any lifecycle model you are probably using
code-and-fix Combined with short schedules it may lead to code-like-hell Advantage
No overhead, may work for small projects
System Specification(maybe)
Code and FixRelease(maybe)
27
Modified Waterfall - Sashimi
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
28
Waterfall With Subprojects
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
29
Waterfall With Risk Reduction
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
30
Evolutionary Prototyping
Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996
35
Commercial Of-The-Shelf Software May not satisfy all your needs but
Immediately available
Often cheap, e.g., no costs for design, development
Software product can be built around the functionality provided by a tool
Free time for more important tasks
Some functionality immediately available – good for customer feedback