Summary

< Free Open Study >

Summary Sizing, estimating, and scheduling are inextricably intertwined during the project planning process. It's really impossible to create a realistic schedule (who's going to do what and when, dependencies, overlapping activities, culminating in the product delivery date) without knowing the amount of effort required for each task (e.g., person-months). It's equally difficult to estimate the amount of effort that a task will require without knowing how "big" it is. Therefore, sizing precedes estimating, which precedes scheduling. Each of these critical project activities may be performed using a variety of techniques. The ability to estimate is critical to a maturing software organization. Poor estimates are problematic, increasing risk, which can be mitigated by standard estimating methods. All the methods begin with the best possible understanding of the project breakdown, as shown in the WBS. There are five useful and well-known techniques for sizing, all building upon the WBS: Counting lines of code (LOC) as a measure of size; Counting function points as a measure of size; Counting feature points as a measure of size; Performing a model blitz (also known as the DeMarco bang metric and as bottom-up estimating); Applying Wideband Delphi. Reuse of existing components is not all "gravy." There is a price to pay for integration; existing components may not have been designed for quality and reuse. There exists a set of empirically derived weighting factors to apply during reuse estimation. The software industry often reverts to LOC metrics, the unit of measure that software practitioners find familiar, comfortable, and easy to use. Whatever technique is used, estimating the size of a product is important because it contributes to the single most important task of a project: setting realistic expectations. Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure. Often, it is not project team performance that is poor, but only the prediction of performance. Accurate estimates providing for improved project control are vital to the management of the project; inaccurate estimates typically lead to last-minute panic, resulting in the introduction of defects. To produce accurate estimates, you first need to know how much software is to be produced. This is the software size that must be expressed early in the development life cycle in units that are readily observable and easy to communicate. A summary for an estimating checklist might include: Has a firm foundation been established for the estimate of software size? Have customers, managers, and developers been trained in the basics of sizing and estimating? Has historical data, if used, been applied correctly? Have models been used correctly? Has the estimation method been mapped/calibrated to the development process? Have reasonable assumptions been made about product and process factors that affect productivity? Do aggressive goals have realistic strategies for accomplishment? Have any alternative estimating methods been used for comparison? Have multiple methods been used? (No one method is reliable enough, in most cases. When two methods disagree, you may be missing some facts.) Have all functions been included? (Many are easy to overlook or underestimate, such as control, powerup, power failure, diagnostics, operating systems, and so on.) Have you been cautious not to underscope what you don't understand? Most importantly when estimating software size, remember: History is your ally. Use multiple methods, both to learn and to reduce risk. Account for reuse. The authors especially thank Richard Fairley, who has designed and taught many excellent courses in sizing and estimating, for his mentorship.

< Free Open Study >