1 / 35

COM822J1

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

drew-clay
Download Presentation

COM822J1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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) Architecture, design Detailed design Code and debug Unit test Integration System test Small project (2,500 lines code) Large project (500,000 lines code) Activity 10% 20% 25% 20% 15% 10% 30% 20% 10% 5% 20% 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 Typical 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 • 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 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. System Specification (maybe) Release (maybe) Code and Fix 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

  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

More Related