1 COM822J1 Rapid Development & Lifecycle Planning

1

COM822J1

Rapid Development &

Lifecycle Planning

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

3

Chapter 6

Core Issues In Rapid Development

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

5

continued …

Source: Rapid Development - Taming WildeSoftware Projects, McConnell, 1996

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


9

continued …


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


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

17

Chapter 7

Lifecycle Planning

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

19

continued …

Source: Introducing SystemsAnalysis, Steve Skidmore, 1997

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

22

Pure Waterfall


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


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)

26

Spiral


27

Modified Waterfall - Sashimi


28

Waterfall With Subprojects


29

Waterfall With Risk Reduction


30

Evolutionary Prototyping


31

Staged Delivery


32

Design-To-Schedule


33

Evolutionary Delivery


34

Design-To-Tools


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

Documents

1 COM822J1 Rapid Development & Lifecycle Planning