Project Management. Week 2. Core Issues in Rapid Development. Lecture Overview. Does One Size Fit All?

Transcription

1 Project Management Week 2 Core Issues in Rapid Development Lecture Overview Core Issues in Rapid Development Introduced to Rapid development strategy for software project management Does One Size Fit All? Different projects have different RD needs even when they all need to be developed as fast as possible The extent of distribution & the required reliability vary greatly among different kinds of software Many products don t fit neatly into categories and products vary in many ways other than the degree of reliability & extent of distribution Most people will need to customize a solution for their situation 1

2 Core Issues in Rapid Development Extent of distribution Horizontal market Vertical market Customer Personal Word processor Mailing label software Sales tracking program Spreadsheet macro Spreadsheet tax program General insurance quote program Real time race track betting system PC operating system Mainframe operating system Embedded pacemaker control or fuel injector system Space shuttle software Applications Systems Life-critical systems What kind of Rapid Development do you need? The most central issue to the topic of RD is determining what kind of RD you need. Do you need speed, more predictability, better progress, visibility, lower costs or more speed at all costs You can ask several questions to help determine what kind of RD you need? Core Issues in Rapid Development How strong is the product schedule constraint? Does the project emphasis on schedule arise because it is really one of the common RD look-alikes? Is your project limited by any weakness that would prevent a RD success? You need to address all of these issues to decide what kind of RD you need 2

3 Products With Strong Schedule Constraints Products that truly need to focus on all-out development speed rather than cost or predictability have a different time value curve than typical products The value of a typical product decreases gradually in time With a product that has a strong schedule constraint, there is a point at which the value of the product declines Products With Strong Schedule Constraints VALUE OF PRODUCT Typical Products Products with Strong Schedule Constraints TIME Rapid Development Lookalikes People will say they require RD for their product, but in reality, they require other things which appear to be RD look-a-likes, such as: Run away prevention - you can distinguish this RD look-alike from a need for all-out development speed either by realizing that there is no specific scheduling other than as soon as possible Predictability - if your customers emphasize the need to complete software on time, they are probably more concerned about predictability than out and out development speed 3

4 Rapid Development Lookalikes Lowest cost - this look-alike gets the software completed quickly, but emphasizes budget concerns rather than schedule concerns Fixed drop dead rate - a look-alike that promotes development speed to ensure that the product is released by a fixed drop dead Desire for free overtime - management using the excuse of RD or increased development speed to get as much overtime from the staff as possible Rapid Development Lookalikes Whether or not you need RD depends on: How much time you have to do the project How much time it would take to develop the project using efficient development methods An organization must produce high quality software whether on time or not on time as quality is remembered for much longer than tardiness This is the best practice to follow Rapid Development Look-Alikes If complete in TF2 need to use speed oriented practices to complete project on time Time frames 1& 2 Value of product If complete in TF1- efficient development techniques are being used with concentration on risk management Time Drop-dead 4

5 Odds Of Completing On Time Software projects contain too many variables to be able to set schedules with 100% accuracy Far from having one particular when a project would finish, for any given project, there is a range of completion s, of which some are more likely and some less likely Since there are more ways to make a project late than there are to make it early, the scope of the curve on the late side is more gradual than it is on the early side Odds Of Completing On Time Probability of completing exactly on the EARLY LATE Odds Of Completing On Time Probability of completing exactly on the 100% chance of completing on planned 5

6 Rapid Development Lookalikes Tom De Marco (1982) proposed that projects should be so that the probability of coming in early would be the same as the probability of coming in late The schedule should be set so the project has a 50/50 % chance of completing on time, a break even schedule Odds Of Completing On Time Planning A Break Even Schedule Curve Probability of completing exactly on the Probability of completing on or before Scheduled completion 50/50% break even Schedule Probability of completing after the completion Odds Of Completing On Time The Planning Zone Of A Schedule Curve Probability of completing exactly on the Impossible development zone Rapid development zone Efficient development zone Slow development zone 6

7 Perception & Reality Systems development should be like the building of a house - it should be both realistic in concept and perception Visibility of progress is important Even if completing on schedule, the perception of slow development can affect the project as much as reality It is unreasonable to expect customers to sit tight for months on end as it is part of the project to provide them with steady signs of progress Unrealistic Customer Expectations Most of today s projects are in the rapid or impossible zones as most projects lack the planning & resource commitments needed to meet their aggressive schedules The gap between the completion and the actual completion accounts for much of the perception that software projects are slow Odds Of Completing On Time Overcoming The Perception of Slow Development Probability of completing exactly on the Most projects are in one of these zones Most projects are completed in one of these zones 7

8 Unrealistic Customer Expectations The problem of development can be overcome in one of two ways by : Addressing the reality of slow development Making schedules shorter by moving from slow development to efficient development or by moving from efficient development to rapid development Addressing the perception of slow development Eliminate wishful thinking and make planned schedules more realistic by lengthening them to close the gap between planned and actual completion s using practices that highlight customer progress visibility Where Time Is Spent? One strategy for achieving rapid development is to determine the areas in which most of the time is spent on a typical project and then try to reduce that time, if possible You can view time on a software project from many angles and the different views produce different insights into where the time goes How Time Is Spent In Software Projects Approximate activity breakdown by project size Small Large Activity Project Project Architecture & design Detailed design Code/debugging Unit test Integration Systems test 10% 20% 25% 20% 15% 10% 30% 20% 10% 5% 10% 15% 8

9 Where Time Is Spent? A more effective strategy than trying to abbreviate the earlier stages arbitrarily is to perform them as effectively as possible the first time Alternatively, choose practices that require less design Soft Spots Where can time be saved in systems development projects? Rework - reworking defective requirements design & code, correcting defects early when they are cheapest to correct Feature creep - can arise from requirements changes or developer gold-plating. A project must experience a change in requirements throughout, instead of leaving it to the end, which extends development time and cost Soft Spots Where can time be saved in systems development projects? Requirements Specification - this is concerned with specifying the problem itself. It is more open-ended than other development activities and therefore it is possible to burn huge amounts of time unnecessarily. A moderate sense of urgency during requirements gathering can help prevent panic at the end of the project 9

10 Soft Spots Where can time be saved in system development projects? The fuzzy front-end - the time between initial glimmer and the go decision can be a long time, consuming much of the time available for getting a product to market The only way to recapture a month wasted on the frontend is to shorten the product development cycle by a month on the backend, the cheapest & most effective rapid development opportunities Development Speed Trade-Offs If development speed is truly your top priority, then increase the cost of the project & compromise the products feature set in order to deliver it on time You must, however, understand the implications of these decisions as it will be impossible to optimize your project for scheduling and cost features at the same time Schedule Cost & Product Trade- Offs In software management a trade-off triangle with schedule cost & product is common as opposed to the business oriented schedule cost and quality Schedule Cost Product The product side of the triangle includes all the product quality and related attributes and features 10

11 Quality Trade-Offs There are two types of quality which affect the product schedule in different ways The first type of quality lies in getting the product right first time so that time is not wasted reworking design & code The second type includes all other characteristics of high quality software products - usability, efficiency, robustness etc.. Attention to this quality type lengthens the development schedule so there is an opportunity for trading-off this kind of quality against the schedule Per Person Efficiency Trade- Offs Is there a conflict between trying to achieve the greatest per person productivity and the greatest schedule efficiency? YES! The easiest way to maximize PPTO is to keep the team size small. One of the easiest ways to shorten a schedule is to increase team size, which increases productivity, but usually makes each person less efficient Per Person Efficiency Trade- Offs Organizations that try to improve their development speed by moving toward efficient development follow a predictable pattern The schedule speed is narrower with most projects coming close to their cost and schedule targets About half the projects finish earlier than the target and half finish later 11

12 Per Person Efficiency Trade- Offs The planned schedules are longer than typical development, but the actual schedules are shorter This is partly a result of learning how to develop software faster The move from wishful thinking to meaningful project planning is what it takes to move from typical to efficient development Typical Schedule Improvement Pattern A Typical Development Schedule Curve Probability of completing exactly on the Planned Schedule 50/50% Schedule Typical Schedule Improvement Pattern Once you have achieved efficient development, the improvement pattern depends on whether you want to improve raw development speed or schedule predictability, or both 12

13 Typical Schedule Improvement Pattern Efficient Development Probability of completing exactly on the Schedule Curve Planned schedule & 50/50% Schedule are the same Typical Schedule Improvement Pattern Ideally you can employ practices that provide the ideal Rapid Development curve Unfortunately, for us all, this curve is elusive Typical Schedule Improvement Pattern Probability of completing exactly on the Ideal Rapid Development Schedule curve 13

14 Scheduling Options Probability of completing exactly on the Increased speed Reduced risk Typical Schedule Improvement Pattern This graph shows that most RD practices are tilted either towards increasing development speed or reducing schedule risk, but NOT both When you choose RD practices, you need to decide whether you would rather improve the chance of delivering a product earlier or reduce the risk that the product will slip past a certain 14