Presentation is loading. Please wait.

Presentation is loading. Please wait.

Rapid Development & Lifecycle Planning

Similar presentations


Presentation on theme: "Rapid Development & Lifecycle Planning"— Presentation transcript:

1 Rapid Development & Lifecycle Planning
COM822J1 Rapid Development & Lifecycle Planning

2 Covers Chapter 6 and Chapter 7
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 , 1996

3 Core Issues In Rapid Development
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 Wilde
Software 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 Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

9 continued … Source: Rapid Development - Taming Wilde
Software 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 Classical View (after requirements) Small project
(2,500 lines code) Large project (500,000 lines code) Activity Architecture, design Detailed design Code and debug Unit test Integration System test 10% 20% 25% 15% 30% 20% 10% 5% 15%

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
Project Efficient Development Ideal Rapid Development Real Life Rapid Development Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

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 Systems Analysis, Steve Skidmore, 1997

20 continued … Strategic study Feasibility 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 Logical systems design
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 Source: Rapid Development - Taming Wilde
Software Projects, McConnell, 1996

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 Wilde Software Projects, McConnell, 1996

25 Code-And-Fix Quite common Jump straight into coding
System Specification (maybe) Code and Fix Release 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

26 Spiral Source: Rapid Development - Taming Wilde
Software Projects, McConnell, 1996

27 Modified Waterfall - Sashimi
Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

28 Waterfall With Subprojects
Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

29 Waterfall With Risk Reduction
Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

30 Evolutionary Prototyping
Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

31 Staged Delivery Source: Rapid Development - Taming Wilde
Software Projects, McConnell, 1996

32 Design-To-Schedule Source: Rapid Development - Taming Wilde
Software Projects, McConnell, 1996

33 Evolutionary Delivery
Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

34 Design-To-Tools Source: Rapid Development - Taming Wilde
Software 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


Download ppt "Rapid Development & Lifecycle Planning"

Similar presentations


Ads by Google