昨天看到一篇好文章，以Use Case方式来评估项目成本。核心在于对Use Case复杂度的分解，如角色个数、事务个数、技术因素、相关经验（是不是有contingency的影子）、步骤、报表复杂度（output复杂度）。原文链接：http://www.ironspeed.com/articles/Estimating%20Software%20via%20Use%20Cases/article.aspx
| Estimating Software Via Use Cases | 
| Creating accurate cost estimates for software product-development projects early in the product lifecycle has always been a challenge for the industry. This article provides an example of how to make estimating predictability possible when an engineering team gathers highly quantifiable metrics about their engineering processes.
-Ed Carroll, former VP of Engineering for Egghead.com June 28, 2005
|
| | Introduction | In a previous article, I discussed an extensive metrics-gathering program as an essential tool toward improving software engineering processes. This article is a follow-on to that article, A Software Metrics Case Study, and provides an example of what an engineering team can achieve when they gather highly quantifiable metrics about their engineering processes. It is well documented that software product cost estimates are notoriously inaccurate across the software industry. Creating accurate cost estimates for software product-development projects early in the product lifecycle has always been a challenge for the industry. Most software engineering managers, and sometimes the teams, estimate project cost by using a gut feeling for the basis of their estimate. At best they base their estimates on their personal experience (which may be significant) in developing like work, although those experiences are likely not documented methodically in a database where the data can be extracted and applied systematically to the next project (with proper modification for the differences between the efforts). Nor, typically, do these engineering teams routinely measure the accuracy of their estimates. Any measurements of the engineering processes that created the product are often limited to a one-hour discussion at the end of the project (called a lessons-learned meeting), if anything is discussed at all.
This article describes how the case study teams create accurate estimates for software product projects early in the product development lifecycle, well before the requirements are fully defined and the system fully designed. The basis for these estimates starts with initial definitions of Use Cases, given point factors and modified for technical and environmental factors.
| | History | Several estimating models have been developed over the years. Those preceding Use Case Point (UCP) and forming the basis for the UCP model include Function Point Analysis and the Constructive Cost Model. Function Point Analysis (FPA) was a valuable technique developed by A. J. Albrecht, in 1977. FPA assigns a point to each function in an application. Various modifiers then act on the function points in order to adjust for the product environment. Modifiers typically included applying weighted percentages or multipliers that would directly increase or decrease the point values. Environment factors included modifiers for complexity of technical issues, developer skill level, and risk. One problem organizations attempting to use this method would run into was consistent definition of a function and consistent definition of environmental factors across multiple projects and multiple development languages. To produce reliably accurate estimates, FPA relies heavily on historical data to derive weighting values and modifiers.
The Constructive Cost Model, also known as COCOMO, was created by Barry Boehm, in 1981. COCOMO used statistical returns to calculate project cost and duration within a given probability. The model sought to provide a tool for predictably estimating cost, and continues to evolve today under the sponsorship of the University of Southern California. The model was/is interesting and produced worthy merits in applying statistical analysis to the problem of cost estimating. However, a major defining point in statistics is sample set size. The underlying assumption for COCOMO (like FPA) is that a statistically significant historical database exist to drive the statistical factoring. This will become a common theme through many attempts to create estimating models. Software engineering teams are typically very good at collecting lists of bugs, but notoriously bad at gathering meaningful historical or statistically significant metrics useful in predicting future projects.
In the mid-1990s, Jim Rumbaugh, Grady Booch and Ivar Jacobson of Rational Software Corporation developed the Unified Modeling Language (UML) as notation and methodology for developing object-oriented software. UML was incorporated into the Rational Unified Process (RUP) by Rational Software. Within UML is the concept of defining the requirements for software products with Use Cases. Around the same time, Gustav Karner, also of Rational Software Corporation, created a software project estimating technique based on Use Case Points, much the way that FPA assigns points to functions, and including statistical and weighted modifiers. Karner’s technique is now incorporated into RUP.
Use Cases, as defined by UML, describe the things actors want the system to do and have proven to be an easy method for capturing the scope of a project early in its lifecycle. For their use, the case study team liked being able to create estimates early in the project lifecycle as a way to respond to the needs of their customers. Additionally, they find Use Cases to be a more consistent artifact then functions upon which to base an early project estimate. However, like FPA and COCOMO, the accuracy of estimates created using the RUP UCP estimating technique is largely dependent on a sizable volume of relevant historical data.
The case study team started collecting relevant project estimate metrics approximately five years ago. Three years ago, they started using the Rational Software suite and adopted the RUP methodology. Based on extensive feedback from historically compounding data provided by their project teams, their estimating model has been validated.
The objective of this article is to describe how their feedback process has been effective in creating estimates that are accurate to less then 9 percent deviation from original estimate to completed actual, across 95 percent of hundreds of projects. Their average project size is 60 man-months, with team sizes of 6-12 members. Their data is based on results from more than 200 projects, over a five-year period, using a resource pool that has grown to more than 450 software engineers cross-assigned into projects in a software-engineering-project consulting business environment with continuously changing customers and priorities.
| | Estimating Use Case Points | The model presented here is essentially the same as published by Geri Schneider and Jason Winters in their book, Applying Use Cases [1]. Actors
The process starts by considering the actors. For each actor, determine whether the actor is simple, average or complex. A simple actor represents another system with a defined Application Programming Interface (API). An average actor is either another system that interacts through a protocol such as TCP/IP or a person interacting through a text-based interface. A complex actor is a person interacting through a graphical user interface (GUI).
Count the number of simple, average and complex actors and list the quantity of each in the table. Multiply the quantity of each type of actor times the weighting factor and sum the total.
Table 1. Weighting Actors for Complexity
| Actor Type | Description | Quantity | Weight Factor | Subtotal | | Simple | Defined API | 3 | 1 | 3 | | Average | Interactive or protocol-driven interface | 2 | 2 | 4 | | Complex | Graphical user interface | 1 | 3 | 3 | | Total Actor Points | | | | 10 |
It should be apparent that the weighted values used to modify the quantity of actors (in this section, as in subsequent sections) are valid only if the impact they have on the result is backed up by feedback from historical data. In the case of Actors, use the feedback from historical data to adjust the definition of simple, average or complex.
| | Weighting Use Cases | For each Use Case, determine whether it is simple, average or complex based on the number of transactions in a Use Case, including secondary scenarios. For this purpose, a transaction is defined as an atomic set of activities that is performed entirely or not at all. A simple Use Case has up to 3 transactions, an average Use Case has 4 to 7 transactions, and a complex Use Case has more than 7 transactions. If analysis classes have been defined for the system, and it has also been identified as to which ones are used to implement a particular Use Case, use this information in place of transactions to determine the Use Case complexity. Note: Used Use Cases or extended existing Use Cases do not need to be considered.
Table 2. Weighting Use Cases for Complexity
| Use Case Type | Description | Quantity | Weight Factor | Subtotal | | Simple | Up to 3 transactions | 3 | 5 | 15 | | Average | 4 to 7 transactions | 2 | 10 | 20 | | Complex | More than 7 transactions | 1 | 15 | 15 | | Total Use Cases | | | | 50 |
Count the number of simple, average and complex Use Cases and list the quantity of each in the table. Multiply the quantity of each type of Use Case by the weighting factor and sum the total.
Add the total for Actors to the total for Use Cases to determine the Unadjusted Use Case Points (UUCP).
Weighted Actors + Weighted Use Cases = UUCP 10 + 50 = 60
| | Weighting Technical Factors | Weighting technical factors is an exercise to calculate a Use Case Point modifier, which will modify the UUCP by the weight of the technical factors. Start by calculating the technical complexity of the project. This is called the technical complexity factor (TCF). To calculate the TCF go through the following table and rate each factor from 0 to 5. A rating of 0 means the factor is irrelevant for this project, and 5 means it is essential. Table 3. Weighting Technical Factors
| Technical Factor | Factor Description | Weight Factor | Project Rating | Subtotal | | T1 | Must have a distributed solution | 2 | 5 | 10 | | T2 | Must respond to specific performance objectives | 1 | 3 | 3 | | T3 | Must meet end-user efficiency desires | 1 | 5 | 5 | | T4 | Complex internal processing | 1 | 5 | 5 | | T5 | Code must be reusable | 1 | 3 | 3 | | T6 | Must be easy to install | .5 | 3 | 1.5 | | T7 | Must be easy to use | .5 | 3 | 1.5 | | T8 | Must be portable | 2 | 0 | 0 | | T9 | Must be easy to change | 1 | 5 | 5 | | T10 | Must allow concurrent users | 1 | 0 | 0 | | T11 | Includes special security features | 1 | 5 | 5 | | T12 | Must provide direct access for third-parties | 1 | 0 | 0 | | T13 | Requires special user training facilities | 1 | 3 | 3 | | Total TFactor | | | | 42 |
For each factor multiply its rating by its weight from the table. Add the resultant values together to get the total T factor.
(Weighting Factor) * ∑(Tlevel) = TFactor The TFactor does not directly modify the UUCP. To calculate Technical Complexity Factor (TCF), multiply TFactor by 0.01 and then add 0.6. (0.01 * Tfactor) + 0.6 = TCF (0.01 * 42) + 0.6 = 1.02 TCF
Calculate the size of the software (Use Case) project by multiplying UUCP times TCF. UUCP * TCF = SzUC 60 * 1.02 = 61.2
Note on Reusable Components: Reusable software components should not be included in this estimate. Identify the UUCP associated with the reusable components and Adjust the size of SzUC accordingly. | | Weighting Experience Factors | The experience level of each team member can have a great effect on the accuracy of an estimate. This is called the Experience Factor (EF). Table 4. Weighting Experience Factors
| ExperienceFactor | Factor Description | Weight Factor | Project Rating | Subtotal | | E1 | Familiar with FPT software process | 1 | 4 | 4 | | E2 | Application experience | 0.5 | 2 | 1 | | E3 | Paradigm experience (OO) | 1 | 4 | 4 | | E4 | Lead analyst capability | 0.5 | 4 | 2 | | E5 | Motivation | 0 | 4 | 0 | | E6 | Stable Requirements | 2 | 2 | 4 | | E7 | Part-time workers | -1 | 0 | 0 | | E8 | Difficulty of programming language | -3 | 1 | -3 | | Total EFactor | | | | 12 |
To calculate EF, go through the preceding table and rate each factor from 0 to 5. For factors E1-E4, 0 means no experience in the subject, 3 means average, and 5 means expert. For E5, 0 means no motivation on the project, 3 means average, and 5 means high motivation. For E6, 0 means unchanging requirements, 3 means average amount of change expected, and 5 means extremely unstable requirements. For E7, 0 means no part-time technical staff, 3 means on average half of the team is part-time, and 5 means all of the team is part-time. For E8, 0 means an easy to use programming language is planned, 3 means the language is of average difficulty, and 5 means a very difficult language is planned for the project.
For each factor multiply its rating by its weight from the table. Add the resultant values together to get the total T factor.
For each factor, multiply its rating by its weight from the table. Add these factors to get the total E factor.
∑(Elevel) * (Weighting Factor) * = Efactor Calculate the Experience Factor (EF) by multiplying Efactor times –0.03 and adding 1.4. (-0.03 *Efactor) + 1.4 = EF (-0.03 * 12) + 1.4 = 1.04
To calculate Use Case Points (UCP), multiply SzUC by EF SzUC * EF = UCP 61.2 * 1.04 = 63.648
or UUCP * TCF * EF = UCP
60 * 1.02 * 1.04 = 63.648
| | Estimating Effort | Calculating Man-hours from UCP Translating Use Case points into man-hours per UCP is a matter of calculating a standard usage or effort rate (ER) and multiplying that value by the number of UCPs. The case study team’s historical data sets the project man-hour effort rate at 28 man-hours per UCP. Moreover, their experience agrees with Schneider and Winters[1] in that not all projects are equal, so they differentiate simple from complex projects by using 20 man-hours per UCP on simple projects.
Count the number of factor ratings of E1-E6 that are below 3 and the number of factor ratings of E7-E8 that are above 3. If the total is 2 or less, then use 20 man-hours per UCP. If the total is 3 or 4, use 28 man-hours per UCP. If the total is 5 or more then consider restructuring the project team so that the numbers fall at least below 5. A value of 5 indicates that this project is at significant risk of failure with this team.
Calculate man-hours by multiplying UCP by the effort rate:
ER * UCP = total man-hours 20 * 63.648 = 1,272.96 man-hours
or 28 * 63.648 = 1,782.144
Adjusting Man-hours for Risk Up to this point, the UCP estimating model has considered factors that affect every project in general. However, it is likely that each project will have unique influencing factors. The Risk Coefficient is a project-specific modifier applied as a ratio to the estimate to accommodate risk factors that are not inherently incorporated elsewhere in the model. Such risk coefficients might include identified risk for special training, out-of-normal development for reusability, or special system-level integration requirements. Note: the risk coefficient might also present an opportunity for management to up the estimate to assuage their gut feeling. Try to resist this temptation, because it will skew the value of the historical data feedback process.
Risk Coefficients are a specific addition to the original model by the case study team and not defined in other publications. The team uses risk coefficients to adjust an estimate when a project includes specific risk that cannot be compensated for within the model itself. Process controls have been put in place to prevent overzealous use.
Identify the assumptions and apply a coefficient as a percentage. Increase total man-hours by the percentage change:
(1.0 + .xx[%]) * total man-hours = adjusted man-hours i.e., Increase estimate by 5% for a new reuse effort:
(1.0 + .05[%]) * 1,782.144 = 1,871.25 (adjusted man-hours)
| | Estimating for Reports | The case study team deviates from the UCP estimating model again when calculating their estimate for reports. Calculate effort for reporting output directly into man-hours, rather than use UCP. This is done because development of reports typically does not involve the same level of programming complexity as the rest of the application. Additionally, report creation often has a repetitive aspect to it that is easily leveraged and therefore would skew UCP estimates when mixed in with estimates for the application. Begin by creating a comprehensive list (if possible) of the reports to be produced and classify each report for complexity (simple, medium, complex).
Table 5. Reporting Output
| Number | Report Name | Complexity | Availability | | 1 | Sales by $ | Simple | X | | 2 | COGS | Medium | X | | 3 | Revenue by department | Complex | |
Add the number of reports for each complexity type and multiply the number of each report type by the average number of man-hours it takes to create one report of each type, using historical data to determine effort levels.
Table 6. Weighting Reports for Complexity
| Report Type | Quantity | Average Man-Hours | Subtotal | | Simple | 20 | 12 | 240 | | Average | 15 | 20 | 300 | | Complex | 10 | 40 | 400 | | Total Report Man-Hour Estimate | | | 940 |
Total the number of reporting man-hours and add this to the adjusted man-hours calculation for the project.
reporting man-hours + adjusted man-hours = total man-hours 1,871.25 + 940 = 2,811.25 total man-hours
As it is throughout the UCP estimating process, the key to a good estimate for report development lies in the accuracy of the average man-hour calculation used per report type. And like UCP data, this average must be derived from empirical historical data, not gut feelings. Keep in mind that, when gathering metrics and evaluating the historical data, report development time varies by platform and tools used.
Table 7. Process Improvement Cycle
The Feedback Loop
Feedback into the estimating process centers around two processes: (1) extensive collection of empirical post-mortem data from each project and (2) a detailed causal analysis of the data by the Software Engineering Process Group (SEPG) every six months. A project post-mortem is a rigorous process that works from multiple goals including but not limited to obtaining a documented record of understanding of what happened on the project, personnel management and penalty/reward, and gathering data for analyses that will drive improvements to management and engineering processes, including the estimating model. The post-mortem and causal analyses are about the analysis of the data and applying lessons learned from that analysis, not an exercise in collecting data, which is actually gathered throughout the project life-cycle. For the purpose of validating the estimating model, anomalies that arise in the post-mortem of a single project or are noticed during the project but outside of the regular six month SEPG analyses process can also be promoted for special review.
| | Quantitative Management Analyses | | When trying to discuss metric gathering and analysis, it is more understandable to view the specific metric data than simplified graphs. For this reason, the examples given thus far have been from a single project. However, single projects do not reflect trends that might prevail across teams. Every six months, the SEPG aggregates detailed project data from all projects completed during that term into quantitative management graphs. Quantitative management graphs (such as the one following) easily highlight anomalies: outside of predetermined limitations (in this example, 9 percent for upper and lower control limits), one standard deviation (5.2 percent below), and showing clear deviation trends. All projects are included in these analyses. High and low points crossing out of limitation indicate anomalies that require further explanation. Trends are noticed in the slope of a line or in multiple results consistently falling outside of limits. | | Conclusion | The reader may notice there are no easy systematic answers offered. The decision of whether to change a work process, provide employee training, modify the estimating tool, or some other action (no action is an action), is often subject to the judgment of the evaluator. The case study team’s estimating tool is still fairly close to the model published in Applied Use Cases [1]. This is intentional, in order to preserve the integrity of the model. A constantly changing model is difficult to use consistently, and consistency is the lifeblood of the case study team. Their ability to accurately predict the cost of a project early in the project lifecycle is a major differentiator for their business. Therefore, they suffer continuous process improvement to their processes and training, and evolve their estimating model very slowly. The decision on whether to improve a process, educate the team, or change the estimating tool is handled by the Steering Committee for Quality Assurance. The committee seeks to balance changes in process against education. In the past two years, there have not been any changes to the estimating model, demonstrating the stability of the model (and their continuously improving processes).
Collecting historical data does not guarantee success; the metrics must be specifically relevant to improving the engineering processes; and this cannot be done effectively until those engineering processes are well-managed and standardized. Collecting data, devoting time to analysis and seriously looking for ways to improve processes are not trivial activities; however, it should be clear that one benefit is a very accurate parametric estimating tool.
| | References | | [1] Schneider, G.,Winters, J.P., Applied Use Cases, Second Edition, A Practical Guide, Addison-Wesley, Reading, MA, 2001. | | About the Case Study Company | | Agilis Solutions specializes in developing engineered software solutions for companies that require predictable, flexible and affordable services. We employ a blended model of local, experienced project managers, architects and analysts teamed with our development group at our Offshore Development Center (OSDC) in Hanoi, Vietnam. Our OSDC is one of only 120 organizations in the world certified at level-5, the highest level, of the Capability Maturity Model (CMM) from the Software Engineering Institute (SEI) of Carnegie Mellon University. | | About the Author | | Ed Carroll has been building software products for over 20 years, with particular expertise in automating economic analyses, decision support, and supply-chain management processes. He is presently a sales executive with Agilis Solutions and has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike, and director of software engineering at Boeing. He can be reached at EdCarroll@AgilisSolutions.com. |
|
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图