Friday, November 27, 2009
Measuring Software Size
Measuring Software Size
The central premise of this estimation approach
is that we have some way to judge the size of the software.
Unfortunately, there is no perfect measure of software size. Following
are several possible software size measurements.
Lines of code You might be able to estimate this by analogy from
previous projects, but lines of code aren't related directly to
requirements size.
Function points Function points are an indirect, abstract
measure of software size that can be estimated from requirements and
user interface design information (IFPUG 2002). Calculating function
points involves counting the number and complexity of five elements
found in information systems: external inputs, external outputs,
internal logical files, external interface files, and external
inquiries. The initial function point count is adjusted by rating 14
characteristics of the project and the development team. Function
points don't work well for systems that have a fairly simple set of
inputs and outputs but a lot of processing complexity under the hood.
Learning to count function points accurately is a specialized skill,
but many organizations have found this to be a valuable size
measurement, particularly for information systems.
3D function points 3D
function points extend function points to measure attributes from the
three dimensions of data, function, and control (Whitmire 1995). This
enhancement makes the function point method more applicable to
real-time systems.
Story points Some approaches for agile software development employ user stories (described in the next section)
as the unit of requirements, rather than functional requirements or use
cases. Thus, user story points serve as a measure of requirements size.
Use case points The analyst can assess the number and complexity of use cases[1]
to get a measure of requirements size, and hence product size (Karner
1993; Ribu 2001). Use case points are adapted from the function point
counting method.
Counts of testable requirements Peter Wilson proposed that
analysts write functional requirements at a consistent level of
granularity that he describes as being individually testable
requirements (1995).
The rest of this chapter describes using counts of
story points, use case points, and testable requirements to estimate
the size of your requirements. As Figure 5-3
illustrates, these three methods represent requirements at increasing
levels of detail available at increasingly later stages of the project.
Figure 5-3: More detailed requirements representations permit more precise estimates.
[1]See Chapter 9—"Use Cases and Scenarios and Stories, Oh My!"—for an overview of use case concepts and terminology.
No comments:
Post a Comment