Project Management. Week 4 Software Project Estimation & Metrics. Lecture Overview. Software Project Estimation

Transcription

1 Project Management Week 4 Software Project Estimation & Metrics Lecture Overview The software estimation story Estimation process overview Size estimation Effort estimation Schedule estimation Ballpark schedule estimates Estimates refinement Software Project Estimation Some estimates are created & planned carefully. Others are basic guesses. Most software projects overshoot their estimated schedules anything from 25% - 100%. Some organizations have achieved schedule prediction accuracies to within 10%. An accurate schedule estimate is part of the foundation of maximum development speed. 1

2 Software Project Estimation Without an accurate schedule estimate, there is no foundation for effective planning & no support for RD. Software Project Estimation involves coming up with a useful estimate of when the project will be finished. It involves crunching the numbers and creating a reasonably accurate schedule. The reasons for having accurate SPE schedules are primarily as a result of the software estimation story. The Software Estimation Story SE is difficult & what some people try to do with SE is impossible. Personnel involved in PM in general don t seem to understand why estimation is so complex. If the inherent difficulties are not fully understood, it makes the SE process more complicated. The SE story is underpinned by the fact that the SD process is a process of gradual refinement. It begins with a fuzzy idea or picture of what you want to build & the rest of the project is spent trying to bring that picture into clearer focus. Software Project Estimation Because the picture of the software you are trying to build is fuzzy, the estimate of the time & effort (schedule) needed to build it is also fuzzy. The estimate can only come into focus along with the software itself - therefore, SPE is also a process of gradual refinement. Software Construction - difficult to know whether you can build the product that the customer wants in the desired time frame until you have a detailed understanding of what the customer wants. 2

3 Software Development as a Process of Refinement How much does a new house cost? - it depends on the house and like most things, cost depends exactly on the features or characteristics involved - software is the same. Some organizations want cost estimates to be written within +/- 10% of the total cost before they ll fund any work on Requirements Analysis. This degree of SPE precision isn t theoretically possible, especially when you are not sure what the customer wants;. This also applies when these requirements may change Software Development as a Process of Refinement Until software features are understood in detail - you can t estimate the cost of a program precisely. SD is a process of making increasingly detailed decisions as you refine the product concept into a statement of requirements; refine requirements into a preliminary design; refine preliminary design into detailed design; refine the detailed design into working code. Software Development as a Process of Refinement At each stage of the software development process, decisions are made which affect the projects ultimate cost & schedule. And because you can t know how each of these decisions about the nature of the product contributes to the uncertainty in the estimation. It is therefore, difficult to make an accurate project schedule early on in the project. 3

4 Software Development as a Process of Refinement Some examples of questions that contribute to estimation uncertainty: Will the customer want feature X? Will the customer want the cheap or expensive version of feature X? If you implement the cheap version of feature X will the customer want the expensive version after all? How will feature X be designed? Software Development as a Process of Refinement What will be the quality level of feature X? How long will it take to debug & correct mistakes made in the implementation of feature X? How long will it take to integrate feature X with all the other features? Software Development as a Process of Refinement The uncertainty about even one single feature of the software can introduce a lot of uncertainty into an early project estimate. Multiplied across an entire project, literally thousands of specification, design and implementation decisions have to be made before the cost of the whole project can be determined. As you are responsible for making a greater % of these decisions yourself, you also have the power to narrow the estimate range as well. 4

5 Amount of Refinement Possible It has been discovered that project estimates fall within predictable precisions at various stages of a project. The following estimates conversion graph illustrates how estimates become more precise as a project progresses. Amount of Refinement Possible Project Cost (effort & size) For any given feature set, estimation precision can only improve when the software also becomes more refined,as illustrated by the estimate conversion graph. HIGH LOW Project Schedule Initial product definition Approved product definition Requirements Product specification design specification Detailed design specification Product complete Amount of Refinement Possible This graph illustrates that software estimation is difficult - when developers are typically asked to provide a rough estimate there can be a vast difference between high and low estimates. Even after requirements have been completed, you can only know the amount of effort needed to complete the schedule to around 50% by the time most organizations want estimates to the $. 5

6 Estimate Multipliers by Project Phase Cost models for future software life cycle processes Phase Effort & Size Optimistic Pessimistic Optimistic Schedule Pessimistic Initial product concept Approved product concept Requirements specification Product design specification Detailed design specification Amount of Refinement Possible Estimates made throughout a project should start general and become more refined as the project progresses. The ranges in the table are broad, but even so, there are some extreme cases that they won t catch. How to refine an estimate using the estimate multipliers table: To use factors in the table, simply multiply your most likely single point estimate by the optimistic factor to get the optimistic estimate - and by the pessimistic factor to get the pessimistic estimate. Amount of Refinement Possible You can then present your estimate as a range rather than as a point estimate. If your most likely estimate is 50 man-months and you have completed the RS, (0.67*1.5) = an estimate range of man-months. (0.67*50=33.5) (1.5*50=75) 6

7 Amount of Refinement Possible Optimistic & pessimistic factors for schedule estimates are different than the factors for effort & size - as the schedule estimates assume that you estimate the schedule by first creating an effort estimate and then computing the schedule from that. If you have estimated the schedule by guessing, you would be better off using effort & size ranges in the estimate multipliers table instead of schedule ranges. Estimation Vs Control Most software customers initially want more than they can afford, therefore, they have to bend either their ideas about the product or their ideas about the resources they are willing to commit. Sometimes the customer will want to bend both the resources and the feature set to meet each other half way - if that happens you have to decide how to do this. Estimation Vs Control How can the feature set bend to meet the available resources? Software builders face a choice between estimation, accuracy and project control when estimating a schedule. If you can be flexible about the product characteristics, you can have some control over costs and schedule and can build to budget as a result. You must decide to either implement: a cheap feature quickly or an expensive feature more slowly. 7

8 Estimation Vs Control But each time you will have to choose between including or excluding features according to cost, time etc.. Whether or not you choose to implement the cheap or expensive software feature - you must accept the discipline and the trade-offs involved in a build-to-budget approach. As a result of using this approach, you have to accept imprecisions in early-in-the-project estimates. Co-operation Project Managers have the extra responsibility of offering as much estimate-related information as they can to the customer. They should help the customers by informing them of the parts of the project that they are able to estimate, instead of leaving them in the dark throughout. They must help the customers understand the strategy for the whole project by mapping out the whole set of estimates they intend to provide when they decide they can. Co-operation Ideally, a PM should offer to try to build the project to budget, but make sure that the customers understand the trade-offs involved in this approach. The PM should make it clear that they want to cooperate - but also to tell the customer that they can t give them what they are asking for, because they don t know themselves. 8

9 Co-operation There must be a convergence between estimates & reality Customers must also co-operate, if they want a short schedule, they should not pressure you to lower your estimates. In reality, the shortest schedule results from the most accurately planned project schedule. If estimate too low - the planning inefficiencies will drive up the actual cost of the project. If the estimate too high - the work will expand to fill available time. Co-operation Convergence between estimates & reality Relationship between estimated effort & actual effort. An estimate that is neither too low or too high will result in a longer optimal actual schedule. One must bend to meet the other. Actual Schedule Minimum actual schedule Estimate too low:costs higher due to planning inefficiencies & mistakes Estimate too high:costs higher due to Parkinson's law Actual schedule = Estimated Schedule Estimated Schedule Co-operation In achieving co-operation in estimating a schedule - the trick is to neither estimate too high nor too low - the goal of this trick is to seek a convergence between your estimates and reality. Both estimation & reality should converge upon the software s release. 9

10 Co-operation Therefore, both SDP & SPE should refine together in a gradual process. The sooner the two track together - the tighter all involved in the SDP can plan the project and its interdependencies. Summary of the Estimation Story Constructing software is like constructing a house - you can t tell the cost until you know exactly what features are involved. If you are going to build to budget, you must be very flexible about product characteristics and understand the trade-off between cheap and expensive product functions. Summary of the Estimation Story Software development is a process of gradual refinement, therefore some imprecision is unavoidable, therefore it is best practice to actually build the product to in order to build the estimate. The best way to refine an estimate is to refine it over the course of a project - converging estimate with reality upon software release. 10

11 Accuracy & Precision of SD Estimates An estimate can be either accurate or precise; Accuracy & precision are related but not identical concepts, therefore, the difference is important in SE. Accuracy - how close to the mark a measurement is. Precision - refers to how many significant digits a measurement has. Accuracy & Precision of SD Estimates It is best practice that the shortest-possible software schedules are achieved by creating the most accurate estimates possible, not the most precise. It is also best practice that if you want to achieve maximum development speed, you should avoid false precision. Estimation-Process Overview How do you make an estimate? Creating an accurate development schedule consists of four steps, you should: Estimate size of the product (number of lines of code or function points); Estimate the effort (man-months); Estimate the schedule (calendar months) - getting a realistic schedule estimate accepted can be the most difficult part of the project. Provide estimates in ranges and periodically refine the ranges to provide increasing precision as the project progresses. 11

12 Size Estimation The size of a project can be estimated in several ways: Using an algorithmic approach such as function points, that estimates program size from program features. Using size-estimation software that estimates program size from your description of program features (screens, dialogs, files, database tables. Using a similar project that you have worked on by estimating each new part of the system as a % of the size of a similar piece of the old system. Most software programs require that you calibrate the estimation practice to you environment before you use it. Size Estimation Function-Point Estimation A function-point is a synthetic measure of program size that is often used in the early stages of a project; They are easier to determine from a RS than lines of code and they provide a more accurate measure of a program size; Many methods exist for counting function points : we will use the IBM(1984) method Size Estimation Function-Point Estimation The number of function points in a program is based on the number & complexity of the following : Inputs - screens, forms, dialog boxes, controls, messages; Outputs - screens, reports, graphs, messages; Inquiries - input/output combinations; Logical internal files - groups of end-user data or control information controlled by the program, table in a a relational database; External interface files - files controlled by other programs, data or control information that enters or leaves the program. 12

13 Size Estimation Function-Point Estimation The function-point approach is database oriented and works for most kinds of software, but that will need tailored to individual projects. To compute the number of function points in a program you take all the program characteristics and multiply them according to their complexity in conjunction with Jones s (1991) functionpoint multiplier table. The sum of all the numbers multiplied calculates the Unadjusted function-point total Program Characteristic Number of inputs Number of outputs Inquires Logical internal files External interface files Size Estimation Function-Point Estimation Function-point multipliers table : Jones (1991) Low Complexity Function-Points Medium Complexity High Complexity x 3 x 4 x 6 x 4 x 5 x 7 x 3 x 4 x 6 x 7 x 10 x 15 x 5 x 7 x 10 Size Estimation Function-Point Estimation You can compute an influence multiplier based on the influence that 14 factors have on the program, factors that include data communications, on-line data entry, processing complexity, ease of installation - the influence multiplier ranges from using Jones software measurement tables. When you multiply the unadjusted total by the influence multiplier, you get the total function-point count. 13

14 Size Estimation Function-Point Estimation Example of computing the number of function points Function-Points Program Characteristic Low Complexity Medium Complexity High Complexity Number of inputs 6 x 3 = 18 2 x 4 = 8 3 x 6 = 18 Number of outputs 7 x 4 = 28 7 x 5 = 35 0 x 7 = 0 Inquires Logical internal files 0 x 3 = 0 2 x 4 = 8 4 x 6 = 24 External interface files 5 x 7 = 35 2 x 10 = 20 3 x 15 = 45 9 x 5 = 45 0 x 7 = 0 2 x 10 = 20 Unadjusted function-point total = 304 Adjusted function-point total = 350 Influence multiplier = 1.15 Size Estimation Function-Point Estimation Example of computing the number of function points Unadjusted function-point total = 304 *1.15=350 Adjusted function-point total = 350 Influence multiplier = 1.15 Estimation Tips Some guidelines for making size estimates: Avoid off-the-cuff estimates; Allow time for the estimate and plan it; Use data from previous projects; Use developer-based estimates; Estimate by walk-through; Estimate by categories; Estimate at a low level of detail; Do not omit common tasks; 14

15 Estimation Tips Some guidelines for making size estimates: Use software estimation tools; Use several different estimation techniques & compare the results - i.e. lines of code/schedules/function-points & Jones first order measurement practice. Change estimation practices as the project progresses In the early stages of the project, a look-up table is the most accurate; By mid-design, estimate each of the tasks individually as this will be the most accurate project estimate. Estimation Presentation Styles The way you present an estimate initially can have a huge impact on what happens when the estimate needs changing later. Software estimation usually involves a great deal of risk and uncertainty and a good estimate captures that risk and uncertainty. Estimation Presentation Styles Techniques for presenting schedule estimates include: Plus-or-minus qualifiers; Ranges; Risk quantification; Cases - best, worse, planned & current cases. Coarse dates & time periods; Confidence factors; 15

16 Estimation Presentation Styles Example of a Risk-Quantification Estimate allows for things that might happen or go wrong Estimate : 6 months.+3 months,-2 months. +1 month for late delivery of graphics-formatting sub-system; +1 month for new development tools not working as well as planned; +0.5 months from staff sickness; +0.5 months from understanding size. -1 month for less delay in hiring new developers than expected; -1 month from new development tools working better than planned. Estimation Presentation Styles Example of a Case-Based Estimate Case Best Case Planned Case Current Case Worst Case Estimate April 1st May 15th May 30th July 15th Estimation Presentation Styles Example of a Confidence-Factor Estimate Delivery Date April 1st May 1st June 1st Probability of Delivering on/before Scheduled Date 5% 50% 95% 16

17 Effort Estimation Although an estimate is not strictly necessary for estimating a software schedule, you will need an effort estimate in order to know how many people to put on your project. Having an effort estimate makes it easy to derive the schedule estimate. Effort Estimation Ways to convert a size estimate into an effort estimate: estimation software to create an effort estimate directly from the size estimate; schedule tables to convert a size estimate in lines of code to an effort estimate; organizations historical data to determine the effort taken by previous projects; algorithmic approach (Boehms COCOMO model) to convert a lines of code estimate into an effort estimate. Schedule Estimation The third step in estimating a software project is to compute the schedule estimate - as a rule of thumb, a schedule can be computed from the effort estimate using the following software schedule equation: Schedule in months = 3.0 * man-months 1/3 E.g.. If you have estimated that it will take 65 man-months to build the project, according to the equation, the optimal schedule is 12 months (3.0*65 1/3 ). This implies an optimal team size of 65 man-months divided by the 12 month schedules - 5 or 6 team members. If you don t have any more accurate data from your organization, using this equation is a good place to start. 17

18 Schedule Estimation Estimation ranges are broader for cost effort estimates than they are for schedule ranges as larger projects take longer, have bigger teams and more inefficiencies which automatically increases effort; Schedule Estimation Here are alternative methods of calculating the software schedule from the effort estimate (same as size estimate to effort estimate): estimation software to create an effort estimate directly from the size estimate; schedule tables to convert a size estimate in lines of code to an estimate; organizations historical data to determine the effort taken by previous projects; algorithmic approach (Boehms COCOMO model) to convert a lines of code estimate into an effort estimate. Schedule Estimation One of the common problems with schedule estimates is that they are usually done so crudely that people pad them to give themselves a margin of error - sometimes too much or too little; The software schedule equation and the periodic refinement approach will allow you to avoid padding in your project as it provides customers with an unrealistic schedule estimate; 18

19 Commitment-Based Scheduling Few organizations proceed directly from requirements to scheduling without creating intermediate effort estimates. They typically do so within a commitment-based culture where the developer is asked to make a schedule commitment rather than a schedule estimate (i.e. stating size, effort & schedule estimates). This approach forces the responsibility for creating both size and effort estimates onto the the developer. Commitment-Based Scheduling Commitment has a place in RD, however, commitment-based planning will not help to achieve shorter schedules. It is essential that the commitments be realistic and achievable. The only good kind of schedule, commitment is an accurate one. Jones s First-Order Estimation Practice If you have a function-point count, you can compute a rough schedule from this using Jones s First-order estimation function-point table. To use it, take the function-point total and raise it to the appropriate power according to Jones s exponents for computing schedules from function-point table. Delivery Date Systems Business Shrink-wrap Best in Class Average Worst in Class

20 Jones s First-Order Estimation Practice If you estimated you project s total number of function points to be 350 on an average shrink-wrap software organization: Raise 350 to the power of 0.42 (350 ^ 0.42), for a rough schedule of 12 calendar months. This practice isn t a substitute for more careful schedule estimation, but it does provide a simple means of getting a rough schedule estimate that is better than guessing. One of the toughest obstacles to meaningful software scheduling is that usable, concrete information about software scheduling is hard to come by; The information that is available is usually found in one of two forms: Embedded in a software estimation program (expensive); In books of equations or multipliers (time consuming); What many people are looking for is a ballpark estimate of how long a program of a particular size will take; The accuracy of the data in these tables won t be any match for the accuracy of data from projects within your own organization; If your organization has not recorded the size of past projects - it should be more accurate than a gut instinct; 20

21 Ballpark schedule estimates concerns tables A,B,C which also refer to three types of projects: Systems software; Business software; Shrink-wrap software; Systems software as used here does not include firmware, real-time embedded software or process control etc..since productivity for those kinds of systems would be much lower; If your project does not fit neatly into these categories, you can approximate an estimate for it by combining numbers from two or three of the columns in these tables; Ballpark schedule estimates concerning tables A,B,C also consist of the following aspects : Schedules; Efforts; System sizes; Small projects; Lines of code; Accuracy of the estimates; Each of these will be discussed individually. 21

22 Schedules Schedules listed are in terms of calendar months which includes the design, construction & testing time needed to complete a project; Three types of schedules are included in these tables: Shortest possible schedule; Efficient schedule; Nominal schedule; Efforts The efforts described in the ballpark schedule estimate tables are given in developer-team man-months (including management & quality assurance; You can compute the average team size by dividing the effort months by the schedule months; The schedules do not attempt to represent the full range of possible combinations of schedules and team sizes - they are basically a guide. System Sizes The system sizes listed in the ballpark schedule estimates tables are listed in lines of code; This code is non-blank, non-comment lines of source text; Using the C programming language this would probably amount to an approximation of the number of semi-colons in the file. 22

23 Small Projects The ballpark tables do not contain schedules for projects smaller than 10,000 lines of code. Projects in that range are usually completed by one person and do not require a team; Efforts and schedule estimates for such projects are highly dependent on the capabilities of the individual performing the work. Lines of code Project sizes in these tables are also listed in terms of the line of code; Lines of code metrics have problems, but are more commonly understood than function-points - at PM discretion. Accuracy of the Estimates Schedules These tables have been criticized for being so oversimplified that they can t possibly produce useful estimates; These tables are simple, but that is the purpose; They are useful if you do not have organizational historical data, which will undoubtedly provide a more accurate estimate. 23

24 Shortest Possible Schedules When you have a project to complete, a year or two seems like a long period of time; The ballpark schedules table will help you to be sure that your schedules are at least in the ballpark; If you think that you shouldn t have any trouble developing a 75,000 line shrink-wrap application in nine months, think again! The shortest schedule for such an application is 10 months with 14 developers; Assumptions The shortest possible schedules contain extremely optimistic assumptions: Staffing - assumes that your team has drawn its talent from the top 10% of the talent pool; Management - assumes that the project has ideal project management and that the developers time is not diverted into activities unrelated to technical development work; Tool support - assumes advanced software tools are available and the developers have unlimited access to computer resources; Methodology - assumes the most time-efficient development methods and tools are also used, requirements are completely known at the time design work starts and they don t change; Compression - assumes that these schedules have been compressed as much as possible below the nominal schedules for this set of assumptions and can not be compressed further. 24

25 Assumptions Two facts of life regarding scheduling that cannot be changed: There is a shortest possible schedule and you can t beat it - because at some point adding more software developers slows a project down instead of making it faster; Costs increase rapidly when you shorten the schedule below nominal - because once your tools and methods are in place, you can reduce your schedule simply by increasing the number of developers or the amount of overtime, this is called schedule compression. Schedule Compression The relationship between cost & schedule on a software project is that the cost of achieving the efficient schedule is much less than the cost of achieving the shortest possible schedule - to finish fast costs money; There are many methods of estimating the cost of schedule compression, Rule of thumb: You first estimate the initial effort and initial schedule; Then combine those estimates with your desired schedule to compute the schedule compression factor using the following equations. 25

26 Schedule Compression Schedule Compression Factor Schedule compression factor = desired schedule / initial schedule; (if initial schedule for project is 12 mths and you want to complete it in ten, the compression factor would be 0.83 (10/12=0.83), if initial effort estimate was 78 man-mths, you plug 0.83 into the compressed schedule effort equation to become the compressed schedule effort equation). Schedule Compression Compressed Schedule Effort Compresses schedule effort = initial effort / schedule compression factor. (using this equation yields a compressed schedule effort of 94 man-mths (78/0.83=94)). Schedule compression factors also work backwards, therefore, if you are willing to lengthen your schedule, you can reduce the cost of your project by reducing the team size. Efficient Schedules Given that the shortest possible schedules are out of reach for most organizations, scheduling according to the efficient or nominal schedules provide a more realistic solution; 26

27 Assumptions This scheduling approach assumes that you do most things right, but they stop short of making the idealcase assumptions that underlie the shortest possible schedules; These schedules assume that your team has drawn its talent from the top 25% of the talent pool in both analyst and developer cases, also that everyone has worked with the programming language and environment for a few years; Efficient Schedules Relationship between shortest possible & efficient schedules It is interesting that the efficient schedules approach requires less overall effort than the shortest possible schedule approach; Shortest possible schedule approach uses more optimistic assumptions, however, the reason for this is that this schedule is compressed as much as possible and trade-offs occur in other areas as a result; Efficient Schedules Efficient schedules will represent the best-case schedules and will be achievable if all goes right; The shortest possible schedules will simply be unachievable; 27

28 Nominal Schedules This schedule approach is normally used on average projects, given that by definition that most projects are average; Assumptions Nominal schedules use less optimistic assumptions than the other two schedule approaches; They assume that the team has been drawn from the top 50% of the talent pool, where the average team member may have some familiarity with the programming language and environment; Assumes that programming tools and modern programming languages are used to an extent. Nominal Schedules Assumptions Nominal schedules are not as fast as the efficient development schedules, but they do not constitute the worst-case schedule; They assume that you are doing a lot of things correctly; Achieving nominal schedules, or simply using this scheduling approach offer a 50/50 chance for the average software development project. 28

29 Why Develop Efficiently? The efficient scheduling approach is much more expensive than the nominal approach; Efficient Schedule approach - 250,000 line of code shrink-wrap project = 470 man-months over 22 months; Nominal Schedule approach - 250,000 line of code shrink-wrap project = 800 man-months, twice as much as efficient development over 22 months; Why Develop Efficiently? Compressing the nominal schedules can produce schedules that are similar duration to the efficient schedules but that are far more costly because of less efficient development practices; Compressing the nominal schedule for the 250,000 lines of code shrink-wrap application to finish in the same 22 mths as efficient development would cost 800 man-mths; What to do first with the Ballpark Schedules The first thing that most people will do when they see these schedules is to look at the documentation of a previous project and compare the numbers in the tables; This is the best thing to do when given a new project as it is the best way to learn how to calibrate past and present projects for the future. 29

30 Estimate Refinement The more refined the project estimate definition, the more accurate the estimate; The more the system is nailed down, the less uncertainty feeds into the estimate; It is possible to refine a project estimate as the project progresses - this is the best practice to use as making single-point estimates early-on in the project can result in you being accountable for them later on; Estimate Refinement If a team leader uses the single-point approach, the customer will consider the project to have slipped over budget and behind schedule the first time the estimate increases (the opposite can of course occur); After that, the project will be considered to be slipping into ever more trouble - this is untrue as it is evident that not enough was known about the project to make the estimations made at the start; Estimate Refinement The number of times that an estimate is revised can affect whether or not it is accepted; If you explain the estimation story in advance and provide increasingly refined estimates at regular milestones a respectable process will result 30

31 Recalibration If you have a 6 month schedule and plan to meet your first milestone in 4 weeks, but it takes 5 weeks, the question of what to do arises. When you miss a scheduled date, How do you recalibrate the schedule? Should you: Assume you can make up for lost time later in the schedule? Add the week to the total schedule time? Multiply the whole schedule by the magnitude of the slip, in this case by 25%? Recalibration The first method is the most common approach taken: Assume you can make up for lost time later in the schedule? It is assumed that time can be made up in the coding and testing phase. Estimation errors tend to be inaccurate for systematic reasons that pervade the entire schedule such as pressure from management, use of too optimistic schedules; Recalibration As a result, it is unlikely that the whole schedule is accurate except for the part that you have had experience with. This eliminates recalibration option 2 : Add the week to the total schedule time? 31

32 Recalibration The correct response to a missed milestone is recalibration option 3: Multiply the whole schedule by the magnitude of the slip. This option makes most sense analytically. Changing the estimate after missing a milestone is not the only option of recalibration, several other options exist. Additional Recalibration Techniques You can also change the product corner of the schedule/product/cost triangle; You can change the spec to save time; You can spend more money; The only thing you can not do is keep the schedule and everything else and expect the project to improve as it progresses. Additional Recalibration Techniques Problems associated with schedule slips are confidence problems as missing a milestone may be viewed as a failure; If you have stated that your project schedule estimate will mature as the project matures within the given ranges, there will be fewer slips; As long as you are within the range, the project is on track - a slip then becomes something that is completely out of the estimation range. 32

33 Lecture Review The software estimation story Estimation process overview Discussed how to calculate: Size estimation Effort estimation Schedule estimation Ballpark schedule estimates Estimates refinement Next week : Scheduling & Networks 33