Section Introduction to Software Cost Estimation Software cost estimation is a complex activity that requires Enowledge of a number of key atiributes about the project for which the estimate is being constructed. Cost estimating is sometimes termed “parametric estimating” because accuracy demands understanding the relationships among scores of discrete parameters that can affect the outcomes of software projects, both individually and in concert. Creating accurate software cost estimates requires knowledge of the following parameters: = The sizes of major deliverables, such as specifications, source code, and manuals = The rate at which requirements are likely to change during development = The probable number of bugs or defects that are likely to be encountered = The capabilities of the development team = The salaries and overhead costs associated with the development team = The formal methodologies that are going to be utilized (such as the Agile methods) « The tools that are going to be utilized on the projectin 2 Section: Introduction to Software Cost Estimate ; -e going to be © The set of development activities that are KONE tob carried out © The cost and schedule constraints set by clients of the project being estimated Although the factors that influence the outcomes of software projects are numerous and some are complex, modern commercial software cost-estimation tools can ease the burden of project managers by providing default values for all of the key parameters, using industry values derived from the integral knowledge base supplied with the estimation tools. In addition, software cost-estimation tools allow the construction of customized estimating templates that are derived from actual projects and that can be utilized for estimating projects of similar sizes and kinds. This section discusses the origins and evolution of software cost-estimation tools and how software cost estimation fits within the broader category of software project management. In addition, this section discusses the impact of software cost-estimation tools on the success rates of software projects and uses this data to illustrate the approximate return on investment (ROI) from software cost-estimating and project management tools.Chapter Introduction Software cost estimating has been an important but difficult task since the beginning of the computer era in the 1940s. As software applications have grown in size and importance, the need for accuracy in software cost estimating has grown, too. In the early days of software, computer programs were typically less than 1000 machine instructions in size (or less than 30 function points), required only one programmer to write, and seldom took more than a month to complete. The entire development costs were often less than $5000. Although cost estimating was difficult, the economic conse- quences of cost-estimating errors were not very serious. Today some large software systems exceed 25 million source code statements (or more than 300,000 function points), may require technical staffs of 1000 personnel or more, and may take more than five calendar years to complete. The development costs for such large software systems can exceed $500 million; therefore, errors in cost estimation can be very serious indeed. Even more serious, a significant percentage of large software systems run late, exceed their budgets, or are canceled outright due to severe underestimating during the requirements phase. In fact, excessive opti- mism in software cost estimation is a major source of overruns, failures, and litigation. Software is now the driving force of modern business, government, and military operations. This means that a typical Fortune 500 corporation or a state government may produce hundreds of new applications and modify hundreds of existing applications every year. As a result of the host of software projects in the modern world, software cost estimating is now a mainstream activity for every company that builds software. In addition to the need for accurate software cost estimates for day- to-day business operations, software cost estimates are becoming ation 4. Section 1; Introduction to Software Cost Estima years, the author $id: t fifteen. significant aspect in litigation. Over the past 3 where software wsuits and his colleagues have observed sens oa a efendania rbot, cost estimates were produced by the plaintiffs, key part in lawsuits For example, software cost estimation now plays a key pi involving the following disputes: fu nd Wonk Bheabt cunphasnict ; to ™ Breach of contract suits between clients and contractors © Suits involving the taxable value of software assets Suits involving recovering excess costs for defense software due to scope expansion *® Suits involving favoritism in issuance of software contracts * Suits involving wrongful termination of software personnel From many viewpoints, software cost estimating has become a critical technology of the 21st century because software is now so pervasive, Proreut [rustican ble the every park La How Software Cost-Estimating Tools Work Think / plese ‘There are many kinds of automated tools that experienced project man- gers can use to create cost, schedule, and resource estimates for soft- Ware projects. For example, an experienced software project manager can create a cost-estimate and schedule plan using any of the following: = Spreadsheets ™ Project management tools * Software cost-estimating tools A frequently asked question for software cost-estimating tool vendors is “Why do we need your tool when we already have spreadsheets and project management tools?” The commercial software-estimating tools are differentiated from all other kinds of software project management tools and general-purpose tools, such as spreadsheets, in these key attributes: = They contain knowledge bases of hundreds or thousands of software projects. = They can perform size predictions, which general-purpose tools cannot. = They can automatically adjust estimates based on tools, languages, and processes. = They can predict quality and reliability, which general-purpose tools cannot.Chapter 1; Introduction 5 © They can predict maintonnnee and support: conta after deployment, = They can pradiet (and provent) problems long before the problema actually oc Unlike other kinds of project management tools, the commercial soft- ware cost-estimating tools do not depend upon the expertise of the user or project manager, although experienced managers can refine the estimates: produced. The commercial cost-estimating tools contain the accumulated experience of many hundreds or thousands of software projects. Because of the attached knowledge bases associated with commercial cost-estimating tools, novice managers or managers faced with unfamil- iar kinds of projects can describe the kind of project being dealt with, and the estimating tool will construct an estimate based on similar projects derived from information contained in its associated knowledge base. Figure 1.1 illustrates the basic principles of modern commercial soft- ware cost-estimating tools. The starting point of software estimation is the size of the project in terms of either logical source code statements, physical lines of code, function points, or, sometimes, all three metrics. The project's size can be derived from the estimating tool’s own sizing logic, supplied by users as an explicit input, or derived from analogy with similar projects stored in the estimating tool's knowledge base. Even for Agile projects and those using iterative development, at least approximate size information can be created. Once the basic size of the project has been determined, the estimate can be produced based on the specific attributes of the project in ques- tion. Examples of the attributes that can affect the outcome of the esti- mate include the following: = The rate at which project requirements may change « The experience of the development team with this kind of project = The process or methods used to develop the project ranging from Agile to Waterfall ESTIMATES PROJECT PROJECT = Schedule SIZE x ATTRIBUTES Effort Costs — Deliverables Figure 1.1. Software-estimating principles.oF 8 that will be performed during developmen, & Section: Introduetion to Software Coal atimation ™ The specific activities * The number of inerey "The Programming | ™ The presence or abs * The development ments, iterations, or “sprinta” that will be Uuaod language or langungos wtilizod sence of reusable artifacts tool suites used to develop the project * The environment OF ergonomies of the office work space "The Beographic Separation of the * The schedule prossu * Contractual obligati toam aeross multiple locations Te put on the team. by clionts or executives ions in terms of costs, datos, defects, or features Using ‘commercial estimating tools, these Project attributes can eithor qeblied by the user crinherited from similar p in the estimating tool knowledge base. re some of the char; istic template for other projects, y other attributes from and can become aspects of cof a fall estimatin, topics as the fo historical Projects can ware-estimatiy ig template can contain inherit llowing: © The experience of the development team in similar applications ™ The process or methodology used to develop the application The SEI capability maturity level of the organization * The standards that will be adhered to, such as ISO, DoD, IEEE, and 8o forth ® The tools used during design, coding, testing, and so forth = The programming language or langu lages utilized ™ The volumes of reusable artifacts available * The ergonomics ofthe programming office environment Since software proj jects are not identi butes can be modifie ical, any of these inherited attri- d as the need arises, However, the availability ofChapter 1: Introduction 7 templates makes the estimation process quicker, more convenient, and more reliable because templates substitute specific knowledge from local projects for generic industry default values, ‘Templates can also be derived from sets of projects rather than from one specific project, or can even be custom-built by the users, using artificial factors. However, the most common method of template devel- opment is to use the automatic template construction ability of the estimating tool, and simply select relevant historical projects to be used as the basis for the template. Asa general rule, software-estimating templates are concerned with four key kinds of inherited attributes: (1) personnel, (2) technologies, (3) tools, and (4) the programming environment, as illustrated by Figure 1.2. Three of these four factors—the experience of the personnel, the devel- opment process, and the technology (programming languages and sup- Port tools)—are fairly obvious in their impact. What is not obvious, but is equally important, is the impact of the fourth factor—environment. The environment factor covers individual office space and the commu- nication channels among geographically dispersed development teams. Surprisingly, access to a quiet, noise-free office environment is one of the major factors that influences programming productivity. The ability to include ergonomic factors in an estimate is an excellent example of the value of commercial software cost-estimating tools. Not only do they contain the results of hundreds or thousands of ‘completed projects, but the tools contain data about influential factors that many human project managers may not fully understand. Technology Software Personnel Quality Processes and Productivity Environment Figure 1.2 Key estimate factors.ee ® Section 1: Introduetion to Software Cost Estimation The four key sets of attribut ing manual tes must be considered whether estimat, ly or using an au tomated estimating tool. However, one of the key features of commercial software-estimating tools is the fact that ‘ey are repositories containing the results of hundreds or thousands PESoftware projects, and so the effect of these fren attribute areas can be examined, and their impacts can be analyzed. There is a standard sequence ‘sed for more than ‘Ware-estimation tox There are ten steps in this sequence, although the sequence starts with O because the first stage is a pre-estit imate analysis of the requirements of the application, » a Acommon estimating activity today isto analyze the software require- tion point totals based on those requirements, This ize data used for formal cost estimation. Function this method may appear i within a few years, It is a known fact that requirements for large systems cannot be fully defined at the start of the Project. This fact is the basis for the Agile methods, extreme Programming, Scrum, and a number of others, This fact is also embedded in the algorithms for several commercial software estimating tools. Once the initial requirements are understood, the aver- age rate of growth of new requirements is about 2 percent, per calendar month. This growth can be planned for and included in the estimate. Step 1: Start with Sizing Every form of estimation and every commercial software cost-estimating tool needs the sizes of key deliverables in order to complete an estimate, Size data can be derived in several fashions, including the following:Chapter 1: Introduction 9 "= Size prediction using an estimating tool’s built-in sizing algorithms ® Sizing by extrapolation from function point totals ® Sizing by analogy with similar projects of known size = Guessing at the size using “project manager's intuition” ™ Guessing at the size using “programmer's intuition” «= Sizing using statistical methods or Monte Carlo simulation For Agile methods and those projects using iterative development, sizing of the entire application may be deferred until the early increments are complete. However, even for Agile and iterative projects it is possible to make an approximate prediction of final size just by comparing the nature of the project to similar projects or using size approximations based on the class, type, and nature of the software. Later in this book examples are given of such sizing methods. ‘The basic size of the application being estimated is usually expressed in terms of function points, source code statements, or both. However, it is very important to size all deliverables and not deal only with code. For example, more than 50 kinds of paper documents are associated with large software projects, and they need to be sized also. Of course, when using one of the commercial software estimating tools that support docu- ments sizing, these sizes will automatically be predicted. Source code sizing must be tailored to specific programming lan- guages, and more than 600 languages are now in use. About one-third of software projects utilize more than a single programming language. More than a dozen kinds of testing occur, and each will require different volumes of test cases. Sizing is a key estimating activity. If the sizes of major deliverables can be predicted within 5 to 10 percent, then the accuracy of the over- all estimate can be quite good. If size predictions are wildly inaccu- rate, then the rest of the estimate will be inaccurate, too. As mentioned earlier, empirical evidence from large software projects indicates that requirements grow at an average rate of about 2 percent per calendar month from the end of the requirements phase until the start of the testing phase. The total growth of requirements can exceed 50 percent of the volume of the initial requirements when measured with function points. A major problem with estimating accuracy has been ignoring or leaving out requirements creep. Modern cost-estimating tools can predict requirements growth and can include their costs and schedules in the estimate. ‘The technologies available for sizing have been improving rapidly. In the early days of software cost estimation, size data had to be sup- plied by users, using very primitive methods, Now modern software10 Section 1: Introduction to Software Cost Estimation cost-estimating tools have a number of sizing capabilitios available, including support for very early size estimates even before the require. ments are firm. Step 2: Identify the Activities to Be Included Once the sizes of key deliverables are known, the next step is to solect the set of activities that are going to be performed. In this context the term activities refers to the work that will be performed for the project being estimated, such as requirements, internal design, external design, design inspections, coding, code inspections, user document creation, meetings or Scrum sessions, change control, integration, quality assur- ance, unit testing, new function testing, regression testing, system tost- ing, and project management, Accurate estimation is impossible without knowledge of the activities that are going to be utilized. Activity patterns vary widely from project to project. Large systems utilize many more activities than do small projects. Waterfall projects utilize more activities than Agile projects. For projects of the same size, military and systems software utilize more activities than do information systems, Local patterns of activities are the ones to utilize, because they reflect your own enterprise's software development methodologies. Modern software cost-estimating tools have built-in logic for selecting the activity patterns associated with many kinds of software develop- ment projects. Users can also adjust the activity patterns to match local variations. Step 3: Estimate Software Defect Potentials and Removal Methods ‘The most expensive and time-consuming work of software development is the work of finding bugs and fixing them. In the United States the number of bugs or defects in requirements, design, code, documents, and bad-fixes averages five per function point. Average defect removal efficiency before delivery is 85 percent. The cost of finding and repairing these defects averages about 35 percent of the total development cost of building the application. The schedule time required is about 30 percent of project development schedules. Defect repair costs and schedules are often larger than coding costs and schedules. Accuracy in software cost estimates is not possible if defects and defect removal are not included in the estimates. The author's software cost-estimating tools include full defect-estimation capabilities, and support all known kinds of defect- removal activity. This is necessary because the total effort, time, and cost devoted to a full series of reviews, inspections, and multistage tests will cost far more than source code itself.‘Chapter tr Inteoduetlon tt a a estimation includes predictive abilities (yr requirements lefects, design defects, coding detwots, user doctumentation dlothota, and Avery troubling category called bad fledepots, Nhe phrane bad fhe ralbra to new defects accidentally injected asa by-produet of repairing previ: ous defects. Bad fix defects average about 7 percent ofall defeet nepali, Some estimating tools can predict bad lives Estimating tools that support commercial wuftiware ean alae predict duplicate defect reports, or bugs found by more than one custome, Ht also possible to estimate invalid defect ports, or byt reportee that lun Out not to be the fault of the software, such as user errors oF hardware problems. The ability to predict software delvets would not be vory uwelttl with out another kind of estimation, which is predicting the defeet-removal efficiency of various kinds of reviews, inspections, und teat stages, Modern software cost-estimating tools ean predict how many buge will be found by every form of defect removal, from dosk choking through external beta testing. Step 4: Estimate Staffing Requirements Every software deliverable has a characteristic assignment scope, or amount of work that can be done by a single employee, For oxumplo, an average assignment for an individual programmer will range from 5000 to 15,000 source code statements (from about 50 up to 2000 fune- tion points). However, large systems also utilize many specialists, such as systom architects, database administrators, quality assurance specialists, soft> Ware engineers, technical writers, testers, and the like, Identifying oach category of worker and the numbers of workers for the overall project is the next step in software cost estimation, Staffing requirements depend upon the activities that will bo por formed and the deliverables that will be created, so sta! fing prodictions are derived from knowledge of the overall size of the application and the activity sets that will be included. Staffing predictions also nood to be aware of “pair programming” or two-person teams, which ure part of some of the new Agile methods, For large systems, programmers themselves may comprise loss than half of the workforce. Various kinds of specialists and project, managers comprise the other half. Some of these specialists include quality assurance personnel, testing personnel, technical writers, systems analysts, databaso administrators, and configuration control specialists, If the project is big enough to need specialists, accurate estimation requires that their efforts be included. Both programming and other kinds of noncoding activities,Sy 12 Section 1: Introduction to Software Cost Estimation Such as production of manuals and quality assurance, must be included to complete the estimate successfully, Step 5: Adjust Assumptions Based on Capabilities and Experience Software personnel can range from top experts with years of experience torank novices on their first assignment. Once the categories of tochni- cal workers have been identified, the next step is to make adjustments based on typical experience levels and skill factors, Perts can take on more work, and perform it faster, than can novices, This means that experts will have larger assignment scopes and higher Production rates than average or inexperienced personnel. Other adjustments include work houre Per day, vacations and holidays, sapald and paid overtime, and assumptions abect the geographic disper- age” capabilities, and allow users to adjust this assumption upward or downward to match specific team characteristics, Step 6: Estimate Etfort and Schedules Effort and schedule estimates are closel; formed in an iterativ, Yy coupled, and often are per. e manner. Accurate effort estimation requires knowledge of the basie size of the application plus the numbers and experience levels of the software team members and the sizes of various deliverables they are expected ‘0 Produce, such as specifications and user manuale Accurate schedule estimation it that will be performed, the number of increments or “sprint: be carried out, the sizes of var rious deliverables, activities with mutual dependencies, s” that will the overlap between and the numbers and experience levels of the software team members. Schedule and effort estimates are closely coupled, but the interaction between these two dimensions is complicated and sometimes is coun- terintuitive. For example, if'a software project will take six months if it is developed by one programmer, adding a second Programmer will not cut the schedule to three months. Indeed, a point can be reached where putting on additional personnel may slow down the project’s schedule rather than accelerating it The complex sets of rules that link effort and schedules for software projects are the heart of the algorithms for software cost-estimating tools, 7 jn Ry SonyChaptor 1: introduotion 13 As an example of one of the more eubtlo rules that estimating toola contain, adding personnel to a software project within one department will usually shorten development schedules. Butif enough personnel are added so that a Second department is involved, schedules will stretch Out. The reason for this is that software schedules, and also productivity rates, are inversely related to the number of project managers engaged. There are scores of rules associated with the interaction of schedules and effort, and some of these are both subtle and counterintuitive. In fact, for very large software projects with multiple teams, the rate at which development productivity declines tends to correlate more closely tothe number of managers that are engaged than to the actual number of programmers involved. This phenomenon leads to some subtle find. ings, such as the fact that projects with a small span of control (less than six developers per manager) may have lower productivity than similar Projects with a large span of control (12 developers per manager), Step 7: Estimate Development Costs Development costs are the next-to-last stage of estimation and are very complex. Development costs are obviously dependent upon the effort and schedule for software projects, so these factors are predicted first, and then costs are applied afterwards, Costs for software projects that take exactly the same amount of effort in terms of hours or months ean vary widely due to the following causes: © Average salaries of workers and managers on the project "= The corporate burden rate or overhead rate applied to the project = Inflation rates, if the project will run for several years Currency exchange rates, if the project is developed internationally There may also be special cost topics that will have to be dealt with separately, outside of the basic estimate: ® License fees for any acquired software needed " Capital costs for any new equipment ™ Moving and living costs for new staff members * Travel costs for international projects or projects developed in differ: ent locations ™ Contractor and subcontractor costs = Legal fees for copyrights, patents, or other matters ™ Marketing and advertising costs14 Section 1: Introduction to Software Cost Estimation g videos or CD-ROM tutorial materials and = Costs for developin; training = Content acquisition costs if tl he application is © web-based product te cost estimate for soft- veloping a resource that are likely to be needed. Many travel, are only indirectly related f the project significantly. id comple On the whole, developing a full an than simply de ware project is much more complex estimate of the number of work hours cost elements, such as burden rates or to effort and can impact the final cost of The normal pattern of software estimation is to use hours, days, weeks, or months of effort as the primary estimating unit, and then apply costs at the end of the estimating cycle once the effort patterns have been determined. Step 8: Estimate Maintenance and Enhancement Costs ‘ects often continue to be used and modified for many years. Software proj are special topics, and Maintenance and enhancement cost estimation are more complex than new project cost estimation. Estimating maintenance costs requires knowledge of the probable number of users of the application, combined with knowledge of the prob- able number of bugs or defects in the product at the time of release. Estimating enhancement costs requires good historical data on the rate of change of similar projects once they enter production and start being used. For example, new software projects can add 10 percent or more in total volume of new features with each release for several releases in a row, but then slow down for a period of two to three years before another major release occurs. Many commercial estimating tools can estimate both the initial con- struction costs of a project and the maintenance and enhancement cost patterns for more than five years of usage by customers. There is no actual limit on the number of years that can be estimated, but because long-range projections of user numbers and possible new features are highly questionable, the useful life of maintenance and enhancement estimates runs from three to five years. Estimating. main- tenance costs ten years into the future can be done, but no estimate of that range can be regarded as reliable because far too many uncontrol- Jable business variables can occur. Step 9: Present Your Estimate to the Client and Defend It Against Rejection prepared, the next step is to fund the project. Once a cost estimate is to present the estimate For large systems and to the client who is goingChapter 1: Introduction — 15 applications of 5000 function points or larger (equivalent to roughly 500,000 source code statements) about 60 percent of the initial esti- mates will be rejected by the client. Either the estimated schedule will bye too long, the costs will be too high, or both. Often the client will decree 1a specific delivery date much shorter than the ‘estimated date. Often the client will decree that costs must be held within limits much lower than the estimated costs, Projects where formal estimates are rejected and replaced by arbitrary schedules ‘and costs derived from external business neods rather than team capabilities have the highest failure rates in the industry. About 60 percent of such projects will be cancelled and never completed at all. (At the point of cancellation, both costs and schedules will already have exceeded their targets.) Of the 40 percent of projects that finally do get, completed, the average schedule will be about one year late, and the average cost will be about 50 percent higher than targets. ‘The best defense against having a cost estimate rejected is to have solid historieal data from at least a dozen similar projects. The second- best defense against have a cost estimate rejected is to prepare a full activity-based estimate that includes quality, paperwork, requirements creep, all development activities, and all maintenance tasks, You will need to prove that your estimate has been carefully prepared and has left nothing to chance. High-level or phase-level estimates that lack detail are not convincing and are easy to reject. Cautions About Accidental Omissions from Estimates Because software-estimating tools have such an extensive knowledge base, they are not likely to make the kinds of ‘mistakes that inexperienced human managers make when they ercate estimates by hand or with gen- eral-purpose tools and accidentally omit activities from the estimate. For example, when estimating large systems, coding may be only the fourth most expensive activity. Haman managers often tend to leave out or underestimate the non-code work, but estimating tools can include these other activities. « Historically, the effort devoted to finding and fixing bugs by means of reviews, walkthroughs, inspections, and testing takes more time and costs more than any other software activities. Therefore, accurate cost estimates need to start with quality predictions, because defect- removal costs are often more expensive than anything else. «= In second place as major cost elements are the expenses and effort devoted to the production of paper documents, such as plans, speci- fications, user manuals, and the like. For military software projects,— 16 Paperwork will v cost twice as much as the code itself. For large ciyi). Section 1: Introduction to Software Cost Estlmation itn projects greater than 1000 function points or 100,000 source code statements, pa @pproach or ex: * In third place for man ‘creeping dealing with “ Project after ¢ due to creepin; integral part o " For some large distributed applicati opment locations or among the locations he requirements phase, 1 requirements and th ‘per documents will be a major cost clement and will ‘ceed the cost of the code, large projects are the costs and schedules of i requirements” or new features added to the All software projects will grow refore this factor should be an the estimates for all major software projects, ions that involve multiple devel- subcontractors, the costs of meetings and travel “an cost more than the source code and may be in fourth place in the ians, secretaries, Part of the proje This is far too software costs. A frequent omis- or different countries, For very ting systems, telecommunication Which may involve distributed develop. ies and a dozen cities, the costs of travel and this topic should not ct and can, in some cases, top 20 Percent of total costs, much to leave out by accident. ™ The software domain has fragmented into a number of specialized skills and occupations. It is formance tunii = The most common omission from information systems are the cost ments definition, prototyping, mentation, inspections, acceptar ly assurance Specialists, technical writing specialists, pecialists, database administration specialists, per- ng specialists, network specialists, and system admin, combined contributions internal software cost estimates for 's expended by users during require- status reviews, phase reviews, docu. ince testing, and other activities whereChapter 1: Introduction 17 the developers have a key role. Since user representatives are not usually considered to be part of the project team, their contributions to the project are seldom included in software cost estimates, and are seldom included in measurement studies, either. The actual amount of effort contributed by users to major software development projects can approach 20 percent of the total work in some cases, which is not a trivial amount and is far too significant to leave out by accident. Some commercial software cost-estimating tools keep separate chart of accounts for user activities and allow user efforts to be added to total project costs, if desired. For many projects, maintenance after delivery quickly costs more than the development of the application itself. It is unwise to stop the estimate at the point of delivery of the software without includ- ing at least five years of maintenance and enhancement estimates. Since maintenance (defect repairs) and enhancements (adding new features) have different funding sources, many estimating tools sepa- rate these two activities. Other forms of maintenance work, such as customer support or field service, may also be included in post-release estimates. ‘A key factor that differentiates modern commercial software cost- estimating tools from general-purpose tools, such as spreadsheets and project management tools, is the presence of full life-cycle historical data, This gives them the ability to estimate quality and to estimate the Sizes and costs of producing paper deliverables, the probable volumes of creeping requirements, and the costs of coding and testing. When considering acquisition of a software cost-estimating tool, be sure that the knowledge base includes the kind of software you are interested in. The real-life cost and schedule results of information sys- tems, systems software, commercial software, military software, and embedded software are not identical, and you need to be sure the esti- mating tool contains data on the kinds of software you are concerned with, Some tools support all classes of software, but others are more narrow in focus. Software Cost Estimating and Other Development Activities Software cost estimating is not a “standalone” activity. The estimates are derived in large part from the requirements of the project, and will be strongly affected by the tools, process, and other attributes associated with the project. A cost estimate is a precursor for departmental bud- gets, and also serves as a baseline document for comparing accumulated costs against projected costs.oF ¥8 Section 1: Introduction to Software Cost Estimation For any project larger than trivial, multiple cost estimates will be Prepared during the course of development, including but not limiteg to the following: © Arough pre-requirements guesstimate * An initial formal estimate derived from the project requirements = One or more midlife estimates, which reflect requirements changes = A final cost accumulation usin, 6 Project historical data 1n addition, since the software industry is somewhat litigious, cost estimates may also be Prepared as a by-product of several kinds of liti- Bation, including the following: ® Litigation for breach of contract between software clients and out- source companies ® Litigation involving the taxable value of software in tax disputes In the course of developing a Software project, historical data will steadily be accumulated, This means that after the first rough guessti- mate and the initial requirements estimate, future estimates will] need to interleave his estimating tools need th torical data with Predicted data. Therefore, software- e ability to capture historical data and to selec- tively display both historical dat: Ki a and predicted values igure 1.3 illustrates how soft ‘emt of other key software development activites As can be seen from Figure 1.3, estimating is closely aligned with other key development phi ell, software cost estimates 1ases, When done we are among the most valuable documents in the entire software world, because they make a Software project real and tangible in terms of the resources, schedules, and costs that will be required, However, cost estimates that ar curate are key factors in almost every major software disaster. The best advice for those charged with constructing software cost estimates is the following: ™ Be accurate, = Be conservative, « Base the estimate on solid historical data, * Include quality, since software quality affects schedules and costs «= Include paper documents, since they can cost more than source code. = Include project management,i be 19 Introduction Chapter 1: ‘“somtanpe za0 pue uoHeUTse 3800 aTeMYOS EL eINBi4 (S31SVYSATSO) LNSWSOVNVW NOILVENDISNOO __| 1 T WELSAS _| | Noisaa Noissza |_| BONWNALNTYW || LNAWaTEWI ‘9NIG09 ORisa owns SLNAWSUINOTY | —| (2u043 ONY 31NGSHOS) ONILNNODOV 103Owd co _— SSILINLLOV wieheay tos Surg Buig 4uoddns Ayxojdwioo di dd d4 Ww 3A eyewys3 couse a SOT ‘polos Seca SSLLUIALLOV G3Lv7aY ~LNIWIUNS VIN waaeo) FUORI) he | [aeieuy sate) [RERETWS ino pefoig Pejeq Perea wo9j80 noe I [om] ape Lo3roudd ANSWAYNSVSW | |LNSWSYNSVSW ‘SLVWILSS ‘SLVWILSS ANAaWSSa3ssv] "WaTANILSOd soaroud WIINI AWNIDIHO | 4oaroud $dals vdals eds Zadals ldston 20 Section 1: Introduction to Software Cost Estimatlo © Include the effects of creeping requirements. © Do not exaggerate the effect of tools, languages, or methods. © Get below phases to activity-level cost estimates. = Be prepared to defend the assumptions of your estimate. Even with the best estimating tools, accurate software cost estimat- ing is complicated and can be difficult, But without access to good historical data, accurate software cost estimating is almost impossi- ble. Measurement and estimation are twin technologies and both are urgently needed by software project managers, Measurement and estimation are also linked in the commercial software cost-estimation marketplace, since many of the commercial estimating companies are also benchmark and measurement compa- nies. As better historical data becomes available, the features of the commercial software cost-estimating tools are growing stronger. References Barrow, Dean, Susan Nilson, and Dawn Timberlake: Software Estimation Technology Report, Air Foree Software Technology Support Center, Hill Air Force Base, Utah, Bock, Barry: Software Engineering Economics, Prentice-Hall, Englewood Clif, NJ, car Wftware Cost Estimation with COCOMO it, Prentice-Hall, Englewood Clifts, NJ; Brown, Norm (ed: The Program Manager's Guide to Software Acquisition Best Practices, Nersion 1.0, US. Department of Defense, Washington, D.C, duly 1996, Charette Robert N- Software Engineering Risk Analyse ond Management, MeGraw-Hil, ‘New York, 1989, Sm plication Strategies for Risk Analysis, McGraw-Hill, New York, 1990, Cohn, Mike: Agile Estimating and Planning (Robert C, Martin Series), Prentice-Hall PTR, Englewood Cliffs, NJ, 2008, Coombs, Paul: IT Project Estimation: A Practical Guide to the Costing of Software, Cambridge University Press, Melbourne, Australia, DeMarco, Tom: Controlting Software Projects, Yourdon Press, New York, Deadline, Dorset House Press, New York, 1997, Department ofthe Air Force: Guidelines for Succesfl Acquistion and Monagement of Software Intensive Systems; vols. 1 and 2, Software Technology Support Conter, Hi Air Force Base, Utah, 1994, Dreger, Brian: Function Point Analysis, Prontice-Hall, Englewood Cliffs, NJ, 1989. Galorath, Daniel D. and Michael W. Evans: Software Sizing, Estimation, and Risk ‘Management, Auerbach, Philadelphia, PA, 2006, Garmus, David, and David Herron: Measuring the Software Process: A Practical Quide to Functional Measurement, Prentice-Hall, Englewood Cliffs, N.L, 1995, Garmus, David and David Herron: Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley, Boston, Mass,, 2001 Grady, Robert B.: Practical Software Metrics for Project Management and Process Improvement, Prentice-Hall, Englewood Cliffs, NJ, 1992, ‘and Deborah L. Caswell: SoRtware Metrics: Establishing a Company Wide Program, Prentice-Hall, Englewood Cliffs, Nl, 1987Chapter 1: Introduction — Bt Galledge, Thomas R, Wi and Analysis—Balan : ‘New York, 1992. foward, Alan (ed.): So .: Softioune Metrics . eet (ACR, Phoonis.a ee Dryiict Management Tots, Applied Computer UG Counting Practices \ Ret a sterile hie att Mawel, Release 4, International Funetion Point Users Croup mes, Capers: Crifi a ‘Management peacoat Probleme in Softwar Measurement, Information Syatome = Softiware Productivityar : ‘ Stems santana oo Quality Today—The Wontdwide Perspective Lnformation: Tag Aesement and Contr of Soprare Rists, Prentice-Hall, Bngtewoo CHT = Directions in Sofzoare Management, Informati — Paternsof Softcore System Failureond Sao ternational Thon Compuer Measurement, 2nd ed, McGraw-Hill, New York 1606, ‘ cOneated Sofware, Soficare Productivity Research Burlington, Mass, April 19978 = Software Quality—Analysi ‘Computer Press, Boston, 19970. aor e900 SoRtcare Problem—Quartfvng the Costs and Assessing the Consejuences, Addison-Wesley, Reading, Mass, 1985 see ienare Assessments, Benchinarks, and Best Prostiees _Adison-Wesley, Boston, ‘Mass, 2000. m P. Hutelor, and sown mB Mata: aa don Saves Ca Kalai nology with Dechining Budgets, oe antl jon Systerne Managernent is and Guidelines for Success, International ‘Thomson Engineering, 2nd edition, Metrics and Models in Software Quality ; Boston, Mass, 2003. Kemerer, C.F: "Reliability of Function Point Measurement—A Field Bst ‘Communications of the ACN, 36: 85-97 (1999) Keye, Jessica: Software Buginocring s eanetvity Handbook, McGraw-Hill, New York, periment,” sare Measurement and Bstimation: A pract- 2006. Lewis, James P.: Pro er asutiag & Control, McGraw-Hill, New Yor! ‘New York, 2005 pungre Breiner, vols, Land 3, John Wiley Marciniak, John J.(ed.): Eneveloped ‘& Sons, New York, 1994. McConnell, Steve: Softteare Estimation: Dems 4 ‘Redmond, WA, 2006. Mertes, Karen B.: Calibration of the CHECKPOINT Model to #! ‘Systems Center (SMC) Softicare Dotobare rDB), Thesis, Deforee Institute of Technology (AFIT), Wright-Patterson 1996. Ourada, Gerald, and Daniel V. Ferens: “Software Cost Estimating Models: A Calibration, ‘Validation, and Comparison,” in Cost Estimating rand Analysis: Balancing Technolagy Mat Declining Budgets, Springer Verlag, New York, 1992, pp, $3-101, Perry, William E.: Handbook of Diagnosing “pnd Solving Computer Problems, TAB Books, Bie Ridge Summit, Pa., 1959. preseman, Roger: Software Engineering: Practition on Agile Development, McGraw Hill, New Hon 03. Putnam, Lawrence H.: Measures for ‘Brcellence—Reliadle Softecare on Time, Within ‘Budget: Yourdon PressPrentice-Hall, Englewood Clifls, Nab, 1992, _Buetend Ware Myers: Industrial Strenst Byfective Management Using Messurement, IEEE Press, Las Alamitos, C G Reifer, Donald (ed.): Software Management, th 1993. the Black Art, Microsoft Press Space and Missile TGCALAS968-11, ‘AEB, Ohio, September se lpproach with Bonus Chapter Press, Los Alamitos, Calif22 Section 1: Introduction to Software Cost Estimation , r 1, 1996, (This Rethinking the Software Process, CD-ROM, Miller Freeman, Lawr a eine Hall CD-ROM in n book ealloction jointly produced by the book publist 1 tig op ‘and the jouran! publisher, Miller Freeman. Itcontaing the full tex! a To. fivo Prentico-Hall books: Assessment and Control of Software Risks fh “ape Bilan Controlling Software Projects by ‘Tom DeMarco; Function Point Analysis 1 i) Drogor; Measures for Excellence by Larry Piet ‘and Ware Myers; and Object- Software Metrics by Mark Lorenz and Jef Kidd.) : : Howard: Software Benchmark Studies for 1997, Howard Rubin. Associates, Pound NY,, 1997, Rootuhoim, William H., and Reyna A. Beasley: Best Practices in Software Cost and Schedule Estimation, Prentice-Hall PTR, Upper Saddle River, NJ, 1998. Stukes, Sherry, Jason’ Deshoretz, Henry’ Apgar, and Iona Macias: Air Force Cost Analysis Agency Software Estimating Model Analysis—Final Report, TR-9545/008-2, Contract. F04701-96-D-0003, Task 008, Management Consulting & Research, Inc., ‘Thousand Oaks, Calif, September 1996. Stutrko, Richard D.: Estimating Software-Intensive Systems: Projects, Products, and Processes, Addison-Wesley, Boston, Mass, 2005. Symons, Charles R.: Software Sizing and Estimating—Mk II FPA (Function Point Analysis), John Wiley & Sons, Chichester, UK., 1991. Wellman, Frank: Software Costing: An Objective Approach to Estimating and Controlling the Cost of Computer Software, Prentice-Hall, Englewood Cliffs, NuJ., 1992, Yourdon, Ed: Death March—The Complete Software Developer's Guide to Surviving “Mission Impossible” Projects, Prentice-Hall PTR, Upper Saddle River, N.J., 1997. 2ells, Lois: Managing Software Projects—Selecting and Using PC-Based Project ‘Management Syslems, QED Information Sciences, Wellesley, Mass., 1990, Zvegintzov, Nicholas: Software Management Technology Reference Guide, Dorset House Press, New York, 1994.