Problem-Based Estimation
5.6.2 Problem-Based Estimation
In Chapter 4, lines of code and function points were described as measures from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation: (1) as an estimation variable to "size" each element of the software and (2) as baseline metrics collected from past proj- ects and used in conjunction with estimation variables to develop cost and effort projections.
LOC and FP estimation are distinct estimation techniques. Yet both have a num-
What do ? What do
LOC- and
ment of software scope and from this statement attempts to decompose software
FP-oriented
into problem functions that can each be estimated individually. LOC or FP (the esti-
estimation have
mation variable) is then estimated for each function. Alternatively, the planner may
in common?
choose another component for sizing such as classes or objects, changes, or busi- ness processes affected.
Baseline productivity metrics (e.g., LOC/pm or FP/pm 9 ) are then applied to the appropriate estimation variable, and cost or effort for the function is derived. Func- tion estimates are combined to produce an overall estimate for the entire project.
When collecting It is important to note, however, that there is often substantial scatter in produc- productivity metrics for
projects, be sure to tivity metrics for an organization, making the use of a single baseline productivity establish a taxonomy
metric suspect. In general, LOC/pm or FP/pm averages should be computed by proj- of project types. This
ect domain. That is, projects should be grouped by team size, application area, com- will enable you to
plexity, and other relevant parameters. Local domain averages should then be compute domain-
specific averages, computed. When a new project is estimated, it should first be allocated to a domain, making estimation
and then the appropriate domain average for productivity should be used in gener- more accurate.
ating the estimate. The LOC and FP estimation techniques differ in the level of detail required for decomposition and the target of the partitioning. When LOC is used as the estima- tion variable, decomposition 10 is absolutely essential and is often taken to consider- able levels of detail. The following decomposition approach has been adapted from Phillips [PHI98]: 11
define product scope; For LOC estimates,
identify functions by decomposing scope; decomposition focuses
do while functions remain on software functions.
select a function j assign all functions to subfunctions list;
9 The acronym pm stands for person-month. 10 In general, problem functions are decomposed. However, a list of standard components (Section
5.6.1) may be used instead. 11 The informal process design language noted here is intended to illustrate the general approach for sizing. It does not consider every logical contingency.
do while subfunctions remain select subfunction k
if subfunction k resembles subfunction d described in a historical data base
then
note historical cost, effort, size (LOC or FP) data for subfunction d ; adjust historical cost, effort, size data based on any differences; use adjusted cost, effort, size data to derive partial estimate, E p ; project estimate = sum of {E p };
else
if cost, effort, size (LOC or FP) for subfunction k can be estimated then derive partial estimate, E p ; project estimate = sum of {E p }; else subdivide subfunction k into smaller subfunctions; add these to subfunctions list; endif
endif enddo
enddo
This decomposition approach assumes that all functions can be decomposed into subfunctions that will resemble entries in a historical data base. If this is not the case, then another sizing approach must be applied. The greater the degree of partitioning, the more likely reasonably accurate estimates of LOC can
be developed. For FP estimates, decomposition works differently. Rather than focusing on function, each of the information domain characteristics—inputs, outputs, data
For FP estimates, files, inquiries, and external interfaces—as well as the 14 complexity adjustment decomposition focuses on information domain values discussed in Chapter 4 are estimated. The resultant estimates can then be
characteristics. used to derive a FP value that can be tied to past data and used to generate an estimate.
Regardless of the estimation variable that is used, the project planner begins by estimating a range of values for each function or information domain value. Using historical data or (when all else fails) intuition, the planner estimates an optimistic, most likely, and pessimistic size value for each function or count for each informa- tion domain value. An implicit indication of the degree of uncertainty is provided when a range of values is specified.
A three-point or expected value can then be computed. The expected value for the estimation variable (size), S, can be computed as a weighted average of the optimistic
? ) estimates. For example,
How do I
(s ), most likely (s ), and pessimistic (s
compute the
opt
pess
expected value
S = (s opt + 4s m +s pess )/6 (5-1)
for software size?
gives heaviest credence to the “most likely” estimate and follows a beta probability distribution. We assume that there is a very small probability the actual size result will fall outside the optimistic or pessimistic values.
Once the expected value for the estimation variable has been determined, histor- ical LOC or FP productivity data are applied. Are the estimates correct? The only rea- sonable answer to this question is: "We can't be sure." Any estimation technique, no matter how sophisticated, must be cross-checked with another approach. Even then, common sense and experience must prevail.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more