Process-Based Estimation
5.6.4 Process-Based Estimation
The most common technique for estimating a project is to base the estimate on the process that will be used. That is, the process is decomposed into a relatively small set of tasks and the effort required to accomplish each task is estimated.
XRef
Like the problem-based techniques, process-based estimation begins with a delin-
A common process eation of software functions obtained from the project scope. A series of software framework (CPF) is
process activities must be performed for each function. Functions and related soft- discussed in
Chapter 2. ware process activities may be represented as part of a table similar to the one pre- sented in Figure 3.2.
Once problem functions and process activities are melded, the planner estimates the effort (e.g., person-months) that will be required to accomplish each software process activity for each software function. These data constitute the central matrix of the table in Figure 3.2. Average labor rates (i.e., cost/unit effort) are then applied to the effort estimated for each process activity. It is very likely the labor rate will vary for each task. Senior staff heavily involved in early activities are generally more expensive than junior staff involved in later design tasks, code generation, and early testing.
F I G U R E 5.5 Activity
Planning analysis Engineering
CC Risk
Construction
release CE Totals
Code Test
0.50 2.50 0.40 5.00 n/a
7.35 3DGA
0.75 4.00 0.60 2.00 n/a
8.50 CGDF
0.50 4.00 1.00 3.00 n/a
6.00 DBM
0.50 3.00 1.00 1.50 n/a
5.75 PCF
0.50 3.00 0.75 1.50 n/a
4.25 DAM
0.25 2.00 0.50 1.50 n/a
0.50 2.00 0.50 2.00 n/a
10% 36% CC = customer communication CE = customer evaluation
Costs and effort for each function and software process activity are computed as the last step. If process-based estimation is performed independently of LOC or FP estimation, we now have two or three estimates for cost and effort that may be com-
If time permits, use pared and reconciled. If both sets of estimates show reasonable agreement, there is greater granularity
when specifying tasks good reason to believe that the estimates are reliable. If, on the other hand, the results in Figure 5.5, such as
of these decomposition techniques show little agreement, further investigation and breaking analysis into
analysis must be conducted. its major tasks and estimating each
5.6.5 An Example of Process-Based Estimation
separately. To illustrate the use of process-based estimation, we again consider the CAD soft- ware introduced in Section 5.6.3. The system configuration and all software func- tions remain unchanged and are indicated by project scope.
Referring to the completed process-based table shown in Figure 5.5, estimates of effort (in person-months) for each software engineering activity are provided for each CAD software function (abbreviated for brevity). The engineering and construction release activities are subdivided into the major software engineering tasks shown. Gross estimates of effort are provided for customer communication, planning, and risk analysis. These are noted in the total row at the bottom of the table. Horizontal and vertical totals provide an indication of estimated effort required for analysis, design, code, and test. It should be noted that 53 percent of all effort is expended on front-end engineering tasks (requirements analysis and design), indicating the rela- tive importance of this work.
Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months. If desired, labor rates could be associated with each software process activity or software engineer- ing task and computed separately.
Total estimated effort for the CAD software range from a low of 46 person-months (derived using a process-based estimation approach) to a high of 58 person-months Do not expect that all
(derived using an FP estimation approach). The average estimate (using all three estimates will agree
approaches) is 53 person-months. The maximum variation from the average esti- within a percent or
mate is approximately 13 percent. two. If the estimates
are within a 20 What happens when agreement between estimates is poor? The answer to this percent band, they can question requires a re-evaluation of information used to make the estimates. Widely
be reconciled into a divergent estimates can often be traced to one of two causes: single value.
1. The scope of the project is not adequately understood or has been misinter- preted by the planner.
2. Productivity data used for problem-based estimation techniques is inappro- priate for the application, obsolete (in that it no longer accurately reflects the software engineering organization), or has been misapplied.
The planner must determine the cause of divergence and then reconcile the estimates.
5 . 7 E M P I R I C A L E S T I M AT I O N M O D E L S
An estimation model for computer software uses empirically derived formulas to pre- dict effort as a function of LOC or FP. Values for LOC or FP are estimated using the approach described in Sections 5.6.2 and 5.6.3. But instead of using the tables described
An estimation model in those sections, the resultant values for LOC or FP are plugged into the estimation reflects the population
model. of projects from which
The empirical data that support most estimation models are derived from a lim- it has been derived. Therefore, the model is ited sample of projects. For this reason, no estimation model is appropriate for all
domain sensitive. classes of software and in all development environments. Therefore, the results obtained from such models must be used judiciously. 13
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