A Method for Improving Developers Software Size Estimates

Transcription

1 A Method for Improving Developers Software Size Estimates Statement of problem How large is this project? Oh, let me see. I believe that this is about a 500 effort hour project In the world of software development size means different things to different groups of people. Those who specify functional requirements and perhaps pay for the project, too, may conceptualize size in financial terms. Since project effort is a key component of cost, sizing in effort units allows them to place the project in a cost and resource framework. Software developers, while keenly aware of the effort required to complete their tasks, are more likely to describe size in terms of the things they have to produce in order to implement the requirements. Their sizing units are screens to be developed and modified, reports, database tables, web pages, scripts, object classes, and a host of others. To the software estimator size quantifies what a project delivers or proposes to deliver. Concrete measures such as source lines of code or more abstract ones like function points are the estimator s size units, and indeed the ones he or she needs to use a commercial estimating tool. What is certain is that in software development the word size may mean effort, programming artifacts, or elementary units of work depending on who is using the term. This is a potential source of confusion and miscommunication. The purpose of this paper is to outline a process for mapping requirements to intermediate units to elementary units of work, as shown in Chart 1, and use the resulting output for estimating. The process is flexible and uses historical data to tune its algorithms. Units of Need Intermediate Units Units of Work Need Development Process Product Chart I

2 Traditional sizing and estimating Historically, software estimating has followed a pattern similar to this: Requirements are broken down into software elements Effort hours for the tasks to create the software elements are estimated The effort hours are summed and a management reserve (fudge factor) is added to give an effort estimate Resources are leveled and a critical path is determined which allow project staff and duration to be estimated. Chart II, below, depicts this process. Requirements Software Elements Final Estimate of Effort Tasks, Effort (p-hours) Σ=Total Effort Fudge Factors Chart II This bottom up approach is fraught with problems. It underestimates the overhead required and the non-software tasks associated with a larger project: often dramatically Bottom up estimating cannot be done effectively early in the project lifecycle when bid/no bid or go/no go decisions are made and money, time, and staff are allocated to the effort. There is simply insufficient detail to determine all of the software elements, much less the project elements. It ignores the impact on schedule and effort of different sized teams It does not account for the non-linear impacts of time, cost, and quality constraints It is not suitable for rapid cost effective what if analysis. A critical element is missing from this approach and that element is project size.

3 An alterative approach to sizing/estimating a project Parametric or model-based estimating takes a different approach. Determine the size of the software elements breaking them down into common low level software implementation units. (This will be discussed in the following section.) Create a model based first cut estimate using a productivity assumption (preferably historically based), the project size, and the critical constraints Perform what if modeling until an agreed upon estimate has been created Create the detailed plans for the project Chart III illustrates this approach. Requirements Software Elements Productivity Assumption Σ=Size Resources & Constraints First-cut Estimate Detailed Planning & Execution Agreed Estimate What-if Modeling Chart III Key to the success of this methodology are an accurate size and a productivity assumption that is consistent with the organization s capabilities. Translating requirements into implementation units Customers have needs. These take the form of requirements that software must fulfill. Developers translate these requirements into intermediate units that they must create or modify to implement the requirements. These can be screens, programs, reports, tables, object classes, interfaces, etc. The list is fluid. Estimators must decompose the intermediate units into implementation units to determine a size for estimating. Conceptually, an implementation unit is the lowest level of programming construct that a

4 software developer performs. It will vary in form depending on what is being developed. It could be setting a property on a web form, indicating the data type of a field on a data base table, or writing a line of procedural code. In each case it is the most elementary activity that the developer performs. Intermediate units are the tangible results of several or many implementation units. Two traditional measures have been source lines of code and function points. Both of these can work in some cases; but both have limitations. Perhaps their largest stumbling block is that neither customers nor developers conceptualize software systems in those terms. So, in addition to having three groups of people having different understandings of what size means, they now have to translate it into units that are completely outside of their conceptual frameworks. An alternative approach to sizing Here is a process that is conceptually simple, easy to implement, and encourages developer buy in. Hold a facilitated session with the developers. Have them identify all of the intermediate units that they have to create. Determine what they physically have to do to create them. Ask if there are other things that they have to create on other projects. The purpose here is to establish a comprehensive list of the things the developers may create For each item, have them define in quantifiable terms what makes that item simple, average, or complex Have them determine what is required to perform the task to create items in the simple, average, and complex categories. Record this in both effort hours and implementation units (which may be a ratio of effort at this stage) Construct a sizing worksheet that captures the results of the session. The following table provides a simple illustration of the concept. This process will take between 4-6 hours with 4-8 developers and is where you get buy-in from the developers

5 Item Effort Hours IU's Count Total IU's Forms - Simple 8 80 Forms - Average Forms - Complex New Report - Simple New Report - Average New Report - Complex Changed Report - Simple Changed Report - Average Changed Report - Complex Table Changes - Simple Table Changes - Average Table Changes - Complex JCL Changes - Simple JCL Changes - Average JCL Changes - Complex SQL Procedures - Simple SQL Procedures - Average SQL Procedures - Complex Total Implementation Units 6020 Chart IV Creating estimating templates While interviewing the developers it is important to have them define their project types. These may be as simple as small, medium, and large based on estimated effort hours. They may be platform based such as web, client server, or mainframe projects. And they can also be application or customer based. Have the developers define what components are in each project type and a range of how many of each are typically found. Ask them to identify the effort range associated with each project type and identify typical durations. Tailor the estimating spreadsheets to each project type so that they include the appropriate intermediate units. At this point the estimator can use the estimated size to create a template and calculate time, effort and cost with a parametric estimating tool such as SLIM-Estimate

6 Tuning the process The templates created above are starting points and will need to be tuned. They are based on assumptions about the number of components in a project and the amount of effort required for each component. The number of implementation units per component is also an estimate. How do you refine this? One method is to compare the results of a real completed project with industry trends such as those seen below in Chart V. On these graphs, the actual project schedule and staffing is reconstructed to match what actually happened. The data for this project is plotted against the industry benchmarks for duration, effort, based on the size produced from the newly developed sizing method. (The X axis on trend lime charts are in implementation units). It the effort trends too high, it may indicate that the implementation units are understated. Too low an effort could indicate that they are overstated. In either case, the ratio of implementation units per intermediate unit can be adjusted on the estimating spreadsheet. Likewise, the duration and productivity parameter can be examined to see if they are consistent with the industry benchmarks and adjustments made to implementation unit ratios to create a better fit. If nothing fits despite all of the tuning, it may indicate that important components are missing (or perhaps duplicated) or that the project on which the template is modeled did not include all of the effort or perhaps excluded activities normally associated with a project. This is a starting point for sizing and template design. Over time the process should be refined by capturing actual effort and implementation units required to build the intermediate units. An organization s past performance is always a good beginning point for estimating its future

7 Validate Estimate Effort vs Effective Implementation Units 10,000 1,000 Effort (MHR) 100 1,000 10,000 Implementation Units Duration (Months) vs Effective Implementation Units 10 Duration (Months) 1 1,000 10,000 Effective Implementation Units Chart V It the example above an actual project is recreated based on this sizing method and the actual time and effort. The actual project data is then plotted against comparable industry trend lines for schedule and effort. You will notice that the actuals are not exactly on the average but they are very close. The productivity parameter required to produce this estimate is very normal. Actual time and effort from a completed project along with the computed implementation units have produced an estimating template that is internally consistent and also is a good match industry trends. This increases one s confidence that the process for determining size has functioned well.

8 Benefits As Frederick Brooks warned us nearly 30 years ago, there is no silver bullet. This approach to sizing may not be the best fit for every software development situation. But, it will work in many and has some real benefits. It speaks the developer s language. It describes the system in the components they work with: screens, reports, tables, programs, web pages. This improves communication. It involves the developers in the estimating process which creates buy-in and reduces the chance of obtaining bogus data. It is adaptable. It allows new tools and components to be incorporated easily. It is an excellent way to get a handle on a new technology. It provides the ability to articulate what and how developers build a product. It is applicable to many different development paradigms o ERP (PeopleSoft & SAP) o Rational Unified Process o Traditional development It can (and should) be tuned on actual project data If you are running into road blocks when estimating the size of your application development projects give this method a try. You might be pleasantly surprised by the cooperation that you receive from the technical staff and the increased value that is attached to your end product estimates.