Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 COM822J1 Rapid Development & Lifecycle Planning.

Similar presentations


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

1 1 COM822J1 Rapid Development & Lifecycle Planning

2 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 3 Chapter 6 Core Issues In Rapid Development

4 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 5 continued … Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

6 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 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 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 9 continued … Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

10 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 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 12 Where The Time Goes Architecture, design Detailed design Code and debug Unit test Integration System test 10% 20% 25% 20% 15% 10% 30% 20% 10% 5% 20% 15% Activity Small project (2,500 lines code) Large project (500,000 lines code) Classical View (after requirements)

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

16 16 Towards Rapid Development Lifecycle planning Estimation Scheduling Customer oriented development Motivation Teamwork Team structure Feature set control Productivity tools Project recovery

17 17 Chapter 7 Lifecycle Planning

18 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 19 continued … Source: Introducing Systems Analysis, Steve Skidmore, 1997

20 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 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 22 Pure Waterfall Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

23 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 24 Salmon Waterfall Model Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

25 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 Fix Release (maybe)

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

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

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

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

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

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

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

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

34 34 Design-To-Tools Source: Rapid Development - Taming Wilde Software Projects, McConnell, 1996

35 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 "1 COM822J1 Rapid Development & Lifecycle Planning."

Similar presentations


Ads by Google