Step Four: Software Sizing
Size is generally the most significant (but certainly not the only) cost and schedule driver. Overall scope of a software project is defined by identifying not only the amount of new software that must be developed, but also must include the amount of preexisting, COTS, and other software that will be integrated into the new system. In addition to estimating product size, you will need to estimate any rework that will be required to develop the product, which will generally be expressed as source lines of code (SLOC) or function points, although there are other possible units of measure. To help establish the overall uncertainty, the size estimate should be expressed as a least-likely-most range.
PREDICTING SIZE
Whenever possible, start the process of size estimation using formal descriptions of the requirements such as the customer’s request for proposal or a software requirements specification. You should re-estimate the project as soon as more scope information is determined. The most widely used methods of estimating product size are:
Expert opinion – This is an estimate based on recollection of prior systems and assumptions regarding what will happen with this system, and the experts’ past experience.
Analogy – A method by which you compare a proposed component to a known component it is thought to resemble, at the most fundamental level of detail possible. Most matches will be approximate, so for each closest match, make additional size adjustments as necessary. A relative sizing approach such as SEER-AccuScope can provide viable size ranges based on comparisons to known projects.
Formalized methodology – Use of automated tools and/or pre-defined algorithms such as counting the number of subsystems or classes and converting them to function points.
Statistical sizing -Provides a range of potential sizes that is characterized by least, likely, and most. Lead a developer through a carefully designed series of simple questions such as, “What do you think the size of the product will be?” and “What if everything that can go wrong does?” to determine the range:
- Least = What is the best case?
- Likely = What is the expected size? (record the answer the second time this is asked)
- Most = What is the worst case size – including things that may go wrong?
SLOC VS. FUNCTION POINTS
The two predominant sizing measures are SLOC and function points. Both are uniquely powerful, useful, and can be used individually or in combination.
SLOC are straightforward measures of the number of lines of programmed code in an item of software. SLOC was among the first, and remains the most common, sizing measure because lines can be very easily and precisely – even automatically – counted. The SLOC method provides a firm indication of the volume of software developed, which is a critical first step in making comparisons and predictions. SLOC estimates are most accurate at the end of a project when lines of code can be counted.
SLOC has been the dominant method for sizing complicated, real time or embedded systems and works well for hand-generated systems in general. Use lines of code when SLOC-based historical data exists, when the development organization is comfortable with SLOC estimates, when add-ons to existing systems allow counting of actual SLOC in a system, and as a relatively easy check on other methods.
Despite the dominance of SLOC measures, some confusion exists regarding which types of lines to count, which has led to difficulty in comparing methods of counting SLOC. However, within the past several years, code counting methods have become more standardized.
Drawbacks associated with SLOC include the fact that it does not indicate how much functionality an item of software contains, and the difficulty involved in estimating the number of lines of code before they have been written.
Function points provide a logical (functional) unit of measure (size) for the software functions of a system as seen by the user. They provide the essential value of what the software is and what it does with data from a user’s point of view. Function points alone do not capture the impacts of requirements volatility and scope creep.
Develop your estimate based on function points if the project is primarily IT and the system’s functions are known in detail. You can also use SEER’s Estimate By Comparison to develop a function point count. Use function points when sizing by SLOC could be misleading, for example, if you know the code in question was created by an autogenerator rather than by hand. The great strength of function point counts is that they are developed directly from specifications, independent of implementation, which means estimates of project scope are more comparable across projects. By using the SEER function-based sizing method, function points can be estimated without conducting detailed counts.
STEPS TO ESTIMATING SOFTWARE SIZE
If you want to contain the risk of unexpected cost growth for your project, it is essential that you use a software sizing method that is consistent and repeatable, and that you regularly reestimate the size of the product and the associated cost of the project as specs change. By applying the sizing steps described below, you can make consistent and relevant size projections and use them to derive cost estimates.
- Establish a baseline definition of the size metric you will use, and identify a normalization process to use if size information is provided in a format different from the definition chosen.
- Define sizing objectives-are you trying to describe the size of individual computer programs, plan major milestones in the estimation process, or adjust for project replanning? Varying granularities of sizing detail will be appropriate.
- Plan data and resource requirements of the sizing activity.
- Identify and evaluate software requirements, a set of software specifications that are as unambiguous as possible.
- Use several independent techniques and sources in order to take advantage of their complementary strengths and avoid their individual weaknesses.
- Track the accuracy of the estimate versus actuals as the project progresses, and reestimate the product size periodically with actual data.
SIZING DATABASES
Sizing databases for both defense and commercial projects exist and may be useful for understanding the basic size ranges for the type of project you are estimating. Proprietary in-house sizing databases can include much more relevant information about past projects. If your organization does not already have such a database, you should consider establishing one. The payoff for time spent establishing an internal software sizing database that includes both size estimates and summary specifications for completed projects comes with the very first estimate. As you refine the database, you can increase its granularity and add entries that describe not only whole programs but lower level modules as well, which will enable you to make more accurate comparisons. A well developed sizing database will also enable you to produce detailed bottom-up estimates significantly more quickly than if you had to develop such estimates from scratch.
Previous:
Step Three: Collect Data
More information about lines vs function points vs use cases.
Coming Next:
Step Five: Prepare Baseline Estimate