Software Size and Reuse Estimating

Forecasting the "size" of a software system becomes more and more easier as the project progresses. The first time an effort is made, at the front end of the life cycle, little is known except for high-level customer requirements. This is equivalent to requesting a custom-built home, beginning with only an idea of the layout - the square footage may be estimated by architect and client, but it may well change as requirements are clarified and blueprints develop. Near the end of a software development project, there are fewer tasks remaining and stable specifications, allowing for far more accurate estimation. Certainly, we can't wait until near the end to provide estimates - we are required to estimate cost, calendar time, and effort seemingly way too early. At no other time are the estimates so important than at the beginning of a project, yet we are so unsure of them. Go/no-go decisions are made, contracts are won and lost, and jobs appear and fade away based on these estimates. As confident and uncomfortable as we may be, we must provide these estimates.

There are two most important steps in determining how long a project will take and how much it will cost. The first is to estimate its size; the second is to use size along with other environmental factors to estimate effort and its associated cost. Sizing is the prediction of coding required to fulfill requirements. Estimation is the prediction of resources required to complete a project of predicted size, considering factors of calendar time, staff, and budget constraints. We will discuss the second step in "Estimating Duration and Cost". Here, in "Software Size and Reuse Estimating", we are concerned with the first step, which is estimating the size of the software project. Size may be measured in various units, according to what is appropriate for the project and for your organization.

Software size has been described in terms of lines of code (LOC), function points, feature points, number of bubbles on a data flow diagram (DFD), a count of process/control specifications (PSPECS/CSPECS), number of module boxes on a structure chart, number of major entities and/or relationships on an entity relationship diagram (ERD), "shalls" versus "wills" in a government requirements document, number of pages of user documentation, objects and/or classes on an object model, and many other ways. Do not be concerned if some of these terms are foreign because we'll discuss some of the more popular definitions. Whether we are estimating the end product, as with LOC, or some abstraction or model of it, as with object classes, we are guessing about something that doesn't yet exist. This is what makes size estimation so difficult.

Where We Are in the Product Development Life Cycle

Estimating the size and reuse potential of software occurs during the early stages of project planning. Referring to our generic life cycle model, planning takes place during the concept exploration, system exploration, and requirements phases ( see Figure (a) ). Estimating size and effort will take place many times during the life cycle, increasing confidence with each occurrence - after initial customer requirements, after analysis, after design, and so on. Our process model describing the phases of the life cycle (see "Selecting Software Development Life Cycles") serves us well in indicating where estimates and re-estimates should take place. A good practice for project managers is to require size estimates and re-estimates as exit criteria from each phase.

"Software Size and Reuse Estimating" Relation to the 34 Competencies

The estimate of the size of the software product, which is then used to estimate the effort and cost of the project, falls under the project competencies umbrella. Software size estimates, adjusted for reuse, are recorded in the project plan; therefore, a third project competency, documenting plans, also has a relationship to this section. An estimate of software size is a metric that should be maintained as the project advances. Lastly, knowledge of software size also feeds the scheduling of the project.

Project Management Skills

12. Building a work breakdown structure - Product and project tasks are decomposed into small enough increments to be estimated in size.

13. Documenting plans - Decomposed product and project tasks lead to size, effort, and cost estimation, and then ultimately to the project schedule. All are represented in the software project management plan (SPMP); estimation risks are documented in a separate risk plan or as a segment in the SPMP.

14. Estimating cost and 15. Estimating effort - Predictions of size lead to predictions of effort. For instance, if we estimate that we have to produce 500 LOC (size), and we can produce an average of 5 LOC/hour (productivity rate), then the effort will be 100 hours. If we have a small team of two people who can split the load, then each can work for 50 hours. Effort leads to cost - if one developer makes $65 per hour, and the other makes $55 per hour, then the software will cost $6,000 ($3,250 + $2,750).

18. Scheduling - Effort also leads to schedule. In our example, if each developer can put in 25 productive hours each week and can work in parallel (no dependencies), then the 500 LOC product is estimated to be delivered in two weeks.

19. Selecting metrics - Units of size are a metric. Once chosen (LOC, in the previous example), they will be referred to consistently throughout the project.

Learning Objectives for "Software Size and Reuse Estimating"

By the end of this section, the reader should be able to:

● Explain why the sizing of software is an important estimating technique, when it should occur in the life cycle, and how it reduces risk and enhances the maturity of an organization;

● Explain how the work breakdown structure (WBS) influences the ability to estimate software size;

● List several models frequently used in the software industry to estimate size;

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.