Parametric Cost Analysis Handbook

CHAPTER V

SOFTWARE PARAMETRIC COST ESTIMATING

107

CHAPTER V
SOFTWARE PARAMETRIC COST ESTIMATING

SOFTWARE DEFINITION Software, in general, is a set of programs and accompanying documentation that direct computers to perform desired functions but in "irtually all current military systems !n simple terms, a software program is a set of #or e$ample, software controls aircraft engines, instructions for a computer Software is critical, not only in the control of space based systems, dri"ers and simulators% it directs sur"eillance systems, handles space shuttle operations, and controls account, in"entory and &anagement !nformation Systems '&!S( )here are three basic types of software )hese are* + System software 'also known as the operating system( is a collection of programs that manages all the concurrent tasks being performed by a computer, including the e$ecution of application software programs + ,tility software is a set of programs that perform routine day-to-day tasks, such as listing or compressing data, copying files, etc + Application software performs speciali.ed functions like Space Shuttle control and the &!S functions mentioned abo"e, or other useful work not related directly to the operation of the computer itself &ost analysts are familiar with all three types of software as all are used in personal computers &S-/0S '&icro Soft /isk 0perating System(, for e$ample, is a trade name for the operating system for !ntel 123 Personal Computers e$amples of application based software of all three types of software THE IMPORTANCE OF SOFTWARE TODAY 40),S 156 and &icro Soft 7$cel are 4isting a directory of user files is a utility software

function )he system software procured by the ,S 8o"ernment is usually a comple$ combination

102

Parametric Cost Analysis Handbook

As discussed earlier, maintenance problems are a dri"ing force behind re-engineering, but a new business strategy now challenges software organi.ations !t is called business process reengineering or 9ust business re-engineering )he reader should ne"er confuse business reengineering with software re-engineering :e ha"e included this section to discuss how software re-engineering is being used to support business re-engineering ;usiness re-engineering is the fundamental rethinking and radical redesign of business processes to achie"e dramatic impro"ements in measures of performance, such as cost, <uality, ser"ice, and speed )raditionally, organi.ations tend to be structured around di"isions such as manufacturing, marketing, administrati"e support, etc ;ut this structure is often a barrier to <uick responsi"eness to a rapidly changing en"ironment :hen confronted with a new ob9ecti"e, client, strategy, etc , e"ery di"ision must be mobili.ed from the top down So how can software re-engineering help= Software was originally de"eloped to support business functions within the traditional organi.ational structure )hus, we are left with legacy systems that are marketing-oriented, or Software re-engineering captures the design behind the software )hese >chunks? are then analy.ed and regrouped manufacturing-oriented, etc

,sing new tools and techni<ues currently a"ailable, this design-information can be broken up into >chucks? that are functionally integrated around the newly identified business core processes !n many ways, this seems a lot like the process of translating from structured analysis to ob9ect-oriented analysis Some ad"ocates of business re-engineering admit this is the case ;oth in"ol"e changing the basic approach to software and business should correspond to a meta-model of the real-world Software 'and organi.ations( !n the past, we attempted to force our

software designs and organi.ations to conform to a structure that was basically incompatible with the real-world ,sers e$pressed their real-world re<uirements in terms of familiar ob9ects 'e g order forms , personnel records, etc ( which were translated into process oriented programs &aintenance also re<uired a similar translation from the user@s modified needs to the processoriented representation 'i e program( Aow, with ob9ect-oriented analysis and business reengineering, we are beginning to realign our software and organi.ational structure so that they correspond to real world ob9ecti"es and needs Another area where software re-engineering can aid business re-engineering is the identification of business rules from legacy course code 7mbedded within legacy systems are the

10B

implied rules that go"ern how the organi.ation was run at the time the system was de"eloped ;y e$tracting these business rules, an organi.ation can better understand and, later, codify the rules by which they conduct business !mpro"ing software <uality and producti"ity is a ma9or challenge faced by the /epartment of /efense '/o/( and the non-military community '/07, AASA( as well !n addition, pro"iding affordable weapon system fle$ibility through software is a specific challenge for the /o/ !mpro"ing software <uality is basic to how well software meets the re<uirements and e$pectations of the users !t also means ensuring that software is ade<uate, reliable, and efficient !mpro"ing producti"ity means fa"orably increasing the ratio between the resources re<uired to de"elop software and the si.e and comple$ity of the de"eloped software )he growth in computer use and computer hardware capabilities has placed demands of increasing magnitude and comple$ity on computer software Software de"elopment processes, along with attendant methodologies, which may ha"e worked well in the past, often break down when applied to the de"elopment of today@s software #or e$ample, studies show that e"ery fi"e years the si.es of software pro9ects, as measured by Source 4ines 0f Code 'S40C(, increase by an order of magnitude, and that the scaling of the de"elopment effort, demanded by the order-ofmagnitude increases now re<uire fundamental changes in the de"elopment process As the si.es of software pro9ects ha"e increased, software de"elopment processes based on indi"idual programmers ha"e gi"en way to processes based on small teams and, in turn, small teams ha"e gi"en way to larger teams and so on a"ailability )oday@s users of software demand software applications of greater si.e and comple$ity than before Ad"ances in computer hardware capabilities are more than ade<uate to match the demands of users% howe"er, software as it is de"eloped using pre"ailing processes and methodologies is not producti"ity As a percent of total cost, software cost has grown disproportionally more than hardware cost 'see #igure C-1( )he challenge is finding software de"elopment processes with attendant methodologies and technologies that meet user demands and that impro"e software <uality and Higher scaling of software de"elopment processes by merely increasing team si.es reaches limits on effecti"e pro9ect management and resource

110

Parametric Cost Analysis Handbook

FIGURE V-1 HARDWARE/SOFTWARE COST TRENDS

)he military, like the business world today, sees software pro"iding the "ersatility and le"erage to achie"e performance goals #or e$ample, software demonstrated its fle$ibility to <uickly change weapon system capabilities in /esert Storm, the most newsworthy being the rapid de"elopment of a new software package for the Patriot &issile system to counter the SC,/ ;ecause of the "ersatility and le"erage pro"ided by software, the /o/@s appetite for software in the future has been described as >"irtually insatiable ? Software is an increasingly important element in military systems of all kinds systems@ software )he capabilities of current and future military systems are dependent on the performance of the As a system is upgraded or impro"ed, much of the additional capability is !n fact, many of the functions essential to mission or achie"ed through new software

organi.ational success are partly or completely accomplished through the use of software ,nfortunately, software de"elopment and maintenance is an error-prone, time-consuming and comple$ acti"ity 7$perience has re"ealed that many software de"elopment efforts falter because the management of these pro9ects fall into se"eral common traps )hese problems are* + 4ack of ade<uate re<uirementsDspecifications + 4ack of attention to user needs and constraints + 4ack of "isibility into the de"elopment process

111

+ 4ack of control at key points during de"elopment + 4ack of standardi.ation + 4ack of attention to cost of ownership considerations + 4ack of ade<uate documentation + 4ack of ade<uate training and skills in estimating effort and schedule #alling into these traps leads directly to increased de"elopment and support costs, schedule slips, and reduced systems capability /0/-S)/-5137ADEB2, /efense System Software /e"elopment, established uniform re<uirements for software de"elopment and is widely applied in all software application areas by all /0/ components for information systems /0/-S)/-7B6FADEB2, /0/ Automated !nformation System 'A!S( #or embedded systems, /0/-S)/-5137ADEB2 is appropriate #or )he /ocumentation Standards pro"ides guidelines for the de"elopment and re"ision of documentation information systems, both /0/-S)/-5137ADEB2 and /0/-S)/-7B6FA are appropriate 5137ADEB2

documentation re<uirements of /0/-S)/-7B6FA take precedence o"er those of /0/-S)/!n both application areas, tailoring of these standards must be done to reflect the uni<ue needs and constraints of each pro9ect )he actual software de"elopment tasks will be accomplished by a de"elopment organi.ation that is an element of, or subcontractor to, the system de"elopment contractor 0n occasion, this >contractor? may be a /0/ agency )he de"elopment contractor has the responsibility for deli"ering a software product that meets all contractual re<uirements ,nfortunately, at the beginning of a contract@s de"elopment efforts, it us usually not possible to specify precisely and completely all of the characteristics of the final software products and their de"elopment processes 7$perience has shown that the difference between successful and unsuccessful de"elopment efforts is the "igor and timeliness of the direction gi"en to the contractor by the Program &anager, supported by the Pro9ect 0ffice #igure C-5 indicates the relati"e impact of the penalty 'cost( for delayed error correction during a software pro9ect@s life cycle, from almost no cost during preliminary design to high cost impacts during "alidation and operati"e stages ;PG focuses on the later stages 'maintenance( and the reduction of errors at those times by re-engineering the early phases !n today@s world of shrinking budgets, pro"iding affordable, fle$ible software systems re<uires cost control and predictability that are not found in the traditional software de"elopment

115

Parametric Cost Analysis Handbook

processes !ncreasingly, the /o/ demands that software be de"eloped within predictable costs and schedule 7nter, therefore, parametric cost modeling

FIGURE V-2 RELATIVE PENALTY-ERROR CORRECTION THE SOFTWARE DEVELOPMENT PROCESS )his section defines the basic process of software de"elopment as currently practiced by the ma9ority of go"ernment contractors &a9or phases and software de"elopment acti"ities are defined, as well as key milestones for the measurement of progress The Waterfa M!"e /0/-S)/-5137ADEB2, the current pre"ailing standard guiding software de"elopment, has been interpreted as mandating as specific process for use on all military ac<uisitions almost all Air #orce and AASA software de"elopment )his process is represented by the >:aterfall? &odel, which ser"es as the conceptual guideline for )he process described by the model

116

in"ol"es de"elopment through specific, se<uential stages subse<uent phase

)here are specific ob9ecti"es to be 7ach phase re<uires the

accomplished in each stage% each acti"ity must be deemed successful for work to proceed to the )he process is usually considered non-iterati"e deli"ery of particular documentation products 'Contract /ata Ge<uirements 4ist - C/G4 !tems( &any of the phases re<uire successful completion of a go"ernment re"iew process Critics of the >:aterfall? &odel, in fact, find that the model is geared to recogni.e documents as a measure of progress rather than actual results )he eight ma9or acti"ities described in 5137ADEB2 are as follows* + Systems ConceptDSystem Ge<uirements Analysis + Software Ge<uirements Analysis + Software Parametric Cost 7stimating + Preliminary /esign + /etailed /esign + Coding and Computer Software unit 'CS,( )esting + Computer Software Component 'CSC( !ntegration and )esting + Computer Software Configuration !tem 'CSC!( )esting + System !ntegration and 0perational )esting A schematic o"er"iew of the :aterfall &odel, representing concurrent hardware and software de"elopment, is presented in 5137ADEB2, and reproduced below as #igure C-6

11E

Parametric Cost Analysis Handbook

FIGURE V-# WATERFALL MODEL An alternati"e approach to software de"elopment in"ol"es the use of incremental builds :ith this approach, software de"elopment begins with the design of certain core functions to meet critical re<uirements, and each successi"e software >build? pro"ides additional functions or enhances performance 0nce system re<uirements are defined and preliminary system design is

11F

complete, each build may follow the waterfall pattern for subse<uent de"elopment phases 7ach successi"e build will usually ha"e to be integrated with prior builds THE SOFTWARE COST ESTIMATING PROCESS )he o"erall process of de"eloping a cost estimate for software is not different from the process for estimating any other element of cost )here are, howe"er, aspects of the process that are peculiar to software estimating Some of the uni<ue aspects of software estimating are dri"en by the nature of software as a product estimating methodologies 0ther problems are created by the nature of the ;rooks, in his 1B25 collection of essays, referred to large system

software programming as a >tar pit ? His description of one such pro9ect is typical of Space and &issiles Center and AASA e$perience with software de"elopment He states* >)he product was late, it took more memory than planned, the costs were se"eral times the estimate, and it did not perform "ery well until se"eral releases after the first ? :hy is it so difficult to estimate the cost of software de"elopment= &any of the problems that plague the de"elopment effort itself are responsible for the difficulty encountered in estimating that effort 0ne of the first steps in any estimate is to understand and define the system to be estimated Software, howe"er, is intangible, in"isible, and intractable !t is inherently more difficult to understand and estimate a product or process that cannot be seen and touched Software grows and changes as it is written :hen hardware design has been inade<uate, or when hardware fails to perform as e$pected, the >solution? is often attempted through changes to the software )his change may occur late in the de"elopment process, and sometimes results in unanticipated software growth !n this case it is most important to create a picture, since the product can be highly ambiguous at this time )he software :;S 'see Appendi$ ;( is an e$cellent tool for "isuali.ing the software product )he :;S need not be comple$, nor does it need to be highly detailed A simple product tree line drawing is often ade<uate for initial software estimates )he hardware :;S can be a useful tool in de"eloping the initial :;S for software )here is usually a software Computer Software Configuration !tem 'CSC!( or similar module associated with each hardware 4ine Geplaceable ,nit '4G,( As the program e"ol"es, the initial or draft :;S should include all

113

Parametric Cost Analysis Handbook

software associated with the program regardless of whether it is de"eloped, furnished, or purchased !f furnished or purchased software were omitted, it would not be possible to capture the cost of integrating pree$isting or purchased software with the de"elopment software )he :;S should depict only ma9or software functions, and ma9or subdi"isions !t should not attempt to relate the software to the hardware it controls 7ach of the ma9or software functional units can be modeled as a Computer Software Configuration !tem 'CSC!( 4ower le"el :;S elements can be modeled as a component 0nce the :;S is established the ne$t step is to determine which estimating techni<ue should be used for deri"ing the estimate 0ne of the most challenging tasks in pro9ect management is accurately estimating needed resources and re<uired schedules for software de"elopment pro9ects )he software estimation process includes estimating the si.e of the software product to be produced, determining which functions the software product must perform, estimating the effort re<uired, de"eloping preliminary pro9ect schedules, and finally, estimating o"erall cost of the pro9ect Si.e and number of functions performed are considered ma9or producti"ity '>comple$ity?( factors during the software de"elopment process referred to as software cost estimation Software life cycle models identify "arious phases and associated acti"ities re<uired to de"elop and maintain software, and pro"ide e$cellent input into the software estimation process Some of the more common and accepted life cycle models include* '1( :aterfall &odel% '5( Gapid Prototyping% '6( !ncremental /e"elopment &odel% 'E( Spiral /e"elopment &odel% 'F( Geusable Software &odel% and '3( the )ransform &odel H;oehm and /a"isI tailored to the proposed pro9ect Software identified as mission-critical and de"eloped for the ,nited States go"ernment usually must be de"eloped in accordance with /0/-S)/-5137ADEB2 )his standard establishes uniform re<uirements for software de"elopment, and does not specify or discuss any particular method of software de"elopment Howe"er, it re<uires the inclusion and documentation of the ma9or software de"elopment life cycle acti"ities 7<uipment, and Computer Programs ? )he standard also re<uires that re"iews and audits be held in accordance with &!4-S)/-1F51;, >)echnical Ge"iews and Audits for Systems, )hese models form a baseline from which to begin the software estimation process and should be re"iewed and 7ffort is di"ided into labor categories and multiplied by labor rates to determine o"erall costs )herefore, software estimation is sometimes

117

Additionally, structured approaches to sub-task identification are e$tremely beneficial in determining tasks and the re<uired effort for each task support this process )he software estimation acti"ity should be approached as a ma9or task and therefore should be well planned, re"iewed and continually updated )he basic steps re<uired to accomplish software estimation are described in the following paragraphs Def$%e Pr!&e't O(&e't$)e* a%" Re+,$re-e%t* )he ob9ecti"es and re<uirements of a software pro9ect are usually established by upper management directi"e or by a contract Statement 0f :ork 'S0:( A clear set of ob9ecti"es must be established in order to accurately identify pro9ect re<uirements Pro9ect re<uirements must also include specifications that must be met and applicable standards that must be followed Pro9ect ob9ecti"es and re<uirements must be defined as clearly and precisely as possible in order to accomplish the pro9ect correctly, as well as identify tasks and ultimately estimate costs as accurately and early as possible P a% The A't$)$t$e* As pre"iously mentioned, the software estimation acti"ity should be planned as a ma9or task )he plan should detail the purpose, products, schedules, responsibilities, procedures, )he plan should include which estimation re<uired resources, and assumptions made methodologies, techni<ues, and tools will be used )he pro9ect should be organi.ed into a hierarchical set of tasks to the lowest le"el of detail that a"ailable information will allow Additionally, a breakdown of documentation re<uirements and associated tasks should be defined 'the detailed :;S( )he :;S helps establish a hierarchical "iew and organi.ation of the pro9ect )he top le"el is the software system or final software product, and subse<uent le"els help identify tasks and associated sub-tasks and are used to define and encapsulate system functions 7ach of these tasks are di"ided into software de"elopment phases such as design, code and test, and integration All acti"ities associated with each le"el must be defined including* pro9ect planning and control, configuration management, product assurance and documentation !n addition to early de"elopment of detailed knowledge about the pro9ect, the :;S pro"ides an e$cellent methodology for pro9ect data collection, tracking, and reporting /uring )he :;S is a method which strongly

112

Parametric Cost Analysis Handbook

de"elopment of the pro9ect, each of the :;S tasks can be gi"en a pro9ect budget, and a 9ob number which is used for reporting time spent on each pro9ect phase or acti"ity )his pro"ides an e$cellent pro9ect tracking and history data collection method &ost go"ernment contracts re<uire that such a CostDSchedule Control System Criteria 'CDSCSC( be established :hen the data are collected to an established :;S, the information can be placed in a database to be used in refining, tailoring, and customi.ing the software estimation process )his information becomes an in"aluable input to the software estimation process for future pro9ects Software pro9ect tasksDsubtasks should be defined to the smallest component possible All technical aspects of the pro9ect should be understood as fully as possible since the more details known about the pro9ect the more accurate the estimates will be pro9ect, such as 0b9ect-0riented Analysis and /esign '00A, 00/( should acti"ely keep abreast of e"ol"ing technologies S!ft.are E*t$-at$!% R$*/* )he effects of inaccurate software estimation and schedule o"erruns are well known )he problem stems from an inability to accurately assess risks associated with "arious software de"elopment pro9ects which are* '1( )he inability to accurately si.e the software pro9ect )his results in poor implementations, emergency staffing, and cost o"erruns caused by underestimating pro9ect needs '5( )he inability to accurately specify a de"elopment en"ironment which )his results in defining cost dri"ers which may be inappropriate, )his results in misalignment of reflects reality '6( Software estimation errors generally result from four ma9or risk areas, Aewer methodologies are )herefore, organi.ations e"ol"ing which aid software de"elopers in identifying "arious functions needed to support the

underestimated or o"erestimated )he improper assessment of staff skills skills to tasks and ultimately miscalculations of schedules and le"el of effort re<uired, as well as either underestimating or o"erestimating pro9ect staffing re<uirements 'E( )he lack of well defined ob9ecti"es, re<uirements, and specifications, or unconstrained re<uirements growth during the software de"elopment life cycle )his results in fore"er changing pro9ect goals, frustration, customer dissatisfaction, and ultimately, cost o"erruns

11B

All potential risks associated with the proposed software de"elopment pro9ect should be defined and weighed, and impacts to pro9ect cost should be determined )his information should always be included in the software estimation process E*t$-at$!% Meth!"! !0$e* Se"eral methods 'if possible( should be used during the software estimation process Ao one methodology is necessarily better than the other, in fact, their strengths and weaknesses are often complimentary to each other !t is recommended that more than one software estimation methodology be used for comparison and "erification purposes o"erlooked some key post-processing components 9udgment, and algorithms 'parametrics( )hese methods are often used in con9unction with each other and ha"e been used for many years by managers of software pro9ects without the use of any formal software estimation tools Software estimation tools ha"e only recently been de"eloped which incorporate these methods, and many incorporate multiple methodologies A%a !01 Meth!" 7stimating by analogy means comparing the proposed pro9ect to pre"iously completed similar pro9ects where pro9ect de"elopment information is known Actual data from the completed pro9ects are e$trapolated to estimate the proposed pro9ect 7stimating by analogy can be done either at the system le"el or the component le"el )he main strength of this method is that the estimates are based on actual pro9ect data and past e$perience /ifferences between completed pro9ects and the proposed pro9ect can be identified and impacts estimated 0ne problem with this method is in identifying those differences )his method is also limited because similar pro9ects may not e$ist, or the accuracy of a"ailable historical data is suspect Also, many pro9ects for /0/ weapon systems may not ha"e historical precedents )he analogy or comparati"e techni<ue uses parametric approaches including the use of C7GJs 2!tt!--U3 Meth!" 0ne method may o"erlook system le"el acti"ities such as integration, while another method may ha"e included this, but #i"e of the methods discussed in /r ;oehm@s book Software 7ngineering 7conomics are* analogy, bottom-up, top-down, e$pert

150

Parametric Cost Analysis Handbook

;ottom-up estimation in"ol"es identifying and estimating each indi"idual component separately, then combining the results to produce an estimate of the entire pro9ect !t is often difficult to perform a bottom-up estimate early in the life cycle process because the necessary information may not be a"ailable )his method also tends to be more time consuming and may not be feasible when either time or personnel are limited T!3-D!.% Meth!" )he top-down method of estimation is based on o"erall characteristics of the software pro9ect )he pro9ect is partitioned into lower-le"el components and life cycle phases beginning at the highest le"el )his method is more applicable to early cost estimates when only global properties are known Ad"antages include consideration of system-le"el acti"ities 'integration, documentation, pro9ect control, configuration management, etc (, many of which may be ignored in other estimating methods )he top-down method is usually faster, easier to implement and re<uires minimal pro9ect detail Howe"er, disad"antages are that it can be less accurate and tends to o"erlook lower-le"el components and possible technical problems !t also pro"ides "ery little detail for 9ustifying decisions or estimates E43ert 5,"0-e%t Meth!" 7$pert 9udgment in"ol"es consulting with human e$perts to use their e$perience and understanding of a proposed pro9ect to pro"ide an estimate for the cost of the pro9ect )he ob"ious ad"antage of this method is the e$pert can factor in differences between past pro9ect e$periences and re<uirements of the proposed pro9ect )he e$pert can also factor in pro9ect impacts caused by new technologies, applications, and languages compliments other estimation methodologies the e$pert who contributed to the estimate Para-etr$' Or A 0!r$th-$' Meth!" )he algorithmic method in"ol"es the use of e<uations to perform software estimates )he e<uations are based on research and historical data and use such inputs as Source 4ines 0f Code 7$pert 9udgment always 0ne disad"antage is that the estimates can be no

better than the e$pertise and 9udgment of the e$pert !t is also hard to document the factors used by

151

'S40C(, number of functions to perform, and other cost dri"ers such as language, design methodology, skill-le"els, risk assessments, etc Ad"antages of this method include being able to generate repeatable results, easily modifying input data, easily refining and customi.ing formulas, and better understanding of the o"erall estimating methods since the formulas can be analy.ed Howe"er, the results are <uestionable when estimating future pro9ects which use new technologies, end e<uations are generally unable to deal with e$ceptional conditions such as e$ceptional personnel in any software cost estimating e$ercises, e$ceptional teamwork, and an e$ceptional match between skill-le"els and tasks Howe"er, any estimating approach can be impacted by these drawbacks, and care should be e$ercised when accounting for such concerns Additionally, sometimes algorithms are de"eloped within companies for internal use and many be proprietary as well as more reflecti"e of a specific companyJs performance characteristics S!ft.are C!*t E*t$-at$%0 Sta%"ar"* As stated earlier, "ery often the go"ernment re<uires software de"elopment to follow /0/S)/-5137ADEB2, which is the /epartment of /efense standard that specifies the o"erall process for the de"elopment and documentation of mission critical software systems )his standard also re<uires technical re"iews and audits to be conducted in accordance with /0/-S)/-1F51; 0ther standards that may affect the estimating process are* &!4-S)/-EBBA, &!4-S)/EB2, 7ngineering &anagement% &!4-S)/-EB0A, Specification Practices% &!4-S)/-E20;, Configuration Control-7ngineering Changes, /e"iations and :ai"ers% /0/-S)/-1706, Software Products Standards Software de"eloped in accordance with these standards generally re<uires more resources and is more time consuming )herefore, the software estimation process must include and ad9ust for these re<uirements where applicable 2e%ef$t* :hen the software estimation process is performed correctly, the benefits reali.ed far outweigh the cost of doing the estimating Some of the ma9or benefits include lowering the cost of doing business, increasing the probability of winning new contracts, increasing and broadening the skill-le"el of key staff members, ac<uiring a deeper knowledge of the proposed pro9ect prior to beginning the software de"elopment effort, and understanding, refining, and applying the proper software life cycle mode

155

Parametric Cost Analysis Handbook

As these software estimating components are enhanced, refined, and continually applied, the software estimating process, associated tools, and resulting products attain higher le"els of <uality and ultimately benefit all E6AMPLES OF PARAMETRIC SOFTWARE COST ESTIMATING Accurately estimating the resources and time needed for a software de"elopment pro9ect is essential e"en for the sur"i"al of the pro9ect !n the great ma9ority of cases, the resources and time actually e$pended are much more than the initial planning estimates An approach for estimating the resources and schedule needed for software de"elopment is the use of a software cost and schedule model that calculates the resources and time needed as a function of some other software parameters 'such as the si.e of the program to be de"eloped( )he more times an organi.ation has de"eloped software of the same si.e and comple$ity for the same type of application, the more accurate the estimates for a new pro9ect will be ,nfortunately, when the Program &anager attempts to e$trapolate information from small and less comple$ software de"elopment efforts to larger, more comple$ software in different application areas, the results are often unreliable )he problem results from and e$ponential relationship between software si.e and de"elopment effort #or e$ample, one "ery widely used parametric software cost model is the Constructi"e Cost &odel 'C0C0&0( )he basic C0C0&0 model has a "ery simple form* &AA-&0A)HS K L1 ')housands of /eli"ered Source !nstructions( +L5 :here L1 and L5 are two parameters dependent on the application and de"elopment en"ironment 7stimates from the basic C0C0&0 model can be made more accurate by taking into account other factors concerning the re<uired characteristics of the software to be de"eloped, the <ualification and e$perience of the de"elopment team, and the software de"elopment en"ironment Some of these factors are* + Comple$ity of the software + Ge<uired reliability + Si.e of data base + Ge<uired efficiency 'memory and e$ecution time( + Analyst and programmer capability
156

+ 7$perience of team in the application area + 7$perience of team with the programming language and computer + ,se of tools and software engineering practices + Ge<uired schedule &any of these factors affect the person months re<uired by an order of magnitude or more C0C0&0 assumes that the system and software re<uirements ha"e already been defined, and that these re<uirements are stable )his is often not the case Another popular software cost model is the Putnam model )he form of this model is* P7GS0A M7AGSK '4ines of /eli"ered source !nstructions( Ck '/e"elopment )ime in Mears( :here* CL is a parameter dependent on the de"elopment en"ironment CL has a range from-3,F00 'poor( to 15,F00 'e$cellent( )he Putnam model is "ery sensiti"e to the de"elopment time* decreasing the de"elopment time can greatly increase the person-months needed for de"elopment 0ne significant problem with the C0C0&0, P,)AA& and similar models is that they are based on knowing, or being able to estimate accurately, the si.e 'in lines of code( of the software to be de"eloped )here is often great uncertainty in the software si.e Computer programs, se"eral of which are a"ailable for PCs, ha"e been de"eloped to implement "ariations of the C0C0&0 and other cost models Another estimating approach, called #unction Point Analysis '#PA(, is used to estimate both the si.e of the software to be de"eloped and the effort re<uired for the de"elopment !n #PA, you determine the number and comple$ity of inputs, outputs, user <ueries, files, and e$ternal interfaces of the software to be de"eloped )he sum of these numbers, weighted according to the comple$ity of each, is the number of function points in the system )his function point number is directly related to the number of end-user business functions performed by the system ,sing data from past pro9ects, it is possible to estimate the si.e of the software needed to implement these function points 'typically about 100 source language statements are needed for each function point( and the labor needed to de"elop the software 'typically about 1

15E

Parametric Cost Analysis Handbook

to F function points per person month( #PA has been de"eloped and applied almost e$clusi"ely in !nformation System applications other application areas of feature points /o not depend on a single cost or schedule estimate ,se se"eral estimating techni<ues or cost models, compare the results, and determine the reasons for any large "ariations /ocument the assumptions made when making the estimates &onitor the pro9ect to detect when assumptions that turn out to be wrong 9eopardi.e the accuracy of the estimate PARAMETRIC SOFTWARE COST ESTIMATING TOOLS As mentioned earlier, one of the critical problems facing software de"elopment pro9ect managers is determining accurate software estimations for le"el of effort, schedules, S40C, and o"erall costs Since trends indicate that the cost of producing software products is escalating and consuming an e"er increasing percentage of budgets, the need to <uickly generate more reliable estimates is becoming e"en more important #or many years, pro9ect managers ha"e relied on software de"elopment teams to estimate the cost of producing software products )his has always been a sub9ecti"e and intuiti"e process influenced by such factors as personality, opinions, and pressure to win contracts )he process has encouraged low estimates and short schedules, the results of which ha"e been de"astating to companies and pro9ects, including pro9ects of national importance #or these reasons, software parametric cost estimating tools ha"e been de"eloped since the late 1B70Js to pro"ide a better defined and more consistent software estimating process )hese tools ha"e been de"eloped from historical data collected from thousands of software pro9ects, as well as research performed to identify key producti"ity factors 7arly tools were hampered by the scarcity of reliable data% howe"er, as more data became a"ailable, estimating tools were impro"ed and continued to e"ol"e &ost parametric software estimation tools use algorithms, and some of the more !f ad"anced tools are rule-based or knowledge-based as well as interacti"e 8ood software estimating tools do not always guarantee reliable software estimates inaccurate software si.e estimates and attribute ratings are input, then inaccurate estimates will result A "ariation, called feature point analysis, has been defined for )he chief difference between feature point analysis and #PA is that the

number and comple$ity of the algorithms to be implemented are considered in calculating the number

15F

Additionally, organi.ations need to customi.e the software estimation tools to their own de"elopment en"ironment 'the calibration process was discussed pre"iously in Chapter !C( )his customi.ation re<uires collecting and maintaining historical data from current and past pro9ects to pro"ide the necessary inputs re<uired for the software estimating tools )he software de"elopment organi.ation should establish a staff that is thoroughly trained in the software estimating process and a"ailable estimating tools, and they should perform all the software estimating acti"ities 7$perience and e$isting tools dictate what pro9ect de"elopment information needs to be maintained De*$re" F,%'t$!%a Ca3a($ $t$e* Of Para-etr$' T!! * )he following section pro"ides an o"er"iew of some of the more popular and a"ailable software estimating tools, including the ma9or functional capabilities which software estimating tools should perform, and the input data re<uired to support the use of those tools &a9or functional capabilities that should be considered when selecting a software estimating tool are listed below /epending on the organi.ationJs needs, the le"el of significance of these )he capabilities may differ, and should be considered accordingly !n addition, the organi.ation should analy.e their own needs and identify additional desired capabilities specific to them organi.ation should then match a"ailable tools with o"erall needs !n general, the tool should* '1( Allow easy adaptation to an organi.ationJs de"elopment en"ironment - )his Customi.ation includes allowing the de"eloper to define means the tool needs to be capable of being customi.ed to fit the using organi.ationJs de"elopment en"ironment by the tool applicable inputs, as well as to modify coefficients and e$ponents of the e<uations used )his feature will allow continuous impro"ement to the estimation capability of the tool since the organi.ationJs historical data and current pro9ect data will be included in the software estimate generated '5( ;e relati"ely easy to learn and use - )he tool should be well documented including methodologies and e<uations used /ocumentation should be at a le"el that is understandable )he tool should include help menus and e$amples sufficient to assist the support staff in answering <uestions and pro"iding training )he amount of formal training re<uired to use the tool should be relati"ely minimal, re<uired inputs should be well defined, and "isibility into internal e<uations and theories should be pro"ided

153

Parametric Cost Analysis Handbook

'6(

Pro"ide early estimates - )he tool should be capable of generating estimates

early and <uickly in the life cycle process when re<uirements and de"elopment en"ironments are not fully defined )he tool should also allow task detail to be added incrementally as functions, acti"ities, and other information becomes more completely defined Since there are many unknowns early in the estimating process, the tool should reflect degrees of uncertainty based on the le"el of detail input 'risk analysis( !n general, the tool should pro"ide sufficient information to allow initial pro9ect resource planning as well as reasonably early NgoDno goN decisions 'E( ;e based on software life cycle phases and acti"ities - )he tool should be capable of pro"iding estimates for all phases and acti"ities of the most commonly used software life cycle models !t should allow the organi.ation to decompose and map software de"elopment tasks into those phases and acti"ities, as well as support a program :;S !n addition, it should allow for Nwhat ifN situations and include factors for design trade-off studies 'F( Allow for "ariations in application languages and application function - !t is "ery important that the tool pro"ide estimates specific to the application of the software pro9ect since the associated estimating e<uations, cost dri"ers, and life cycle phases should be uni<ue to each application are 8eneral application categories include !nformation Systems '!S(, simulation and modeling systems, real-time systems, accounting systems, and systems based on higher-order languages '3( Pro"ide accurate si.e estimates - )he si.e of a software de"elopment pro9ect )he tool should include the capability to help is a ma9or cost dri"er in most estimating tools, yet si.e is one of the most difficult input parameters to estimate accurately for estimating the si.e '7( Pro"ide accurate schedule estimates - As pre"iously mentioned, schedule )he software estimating tool o"erruns are common and can be e$tremely costly estimate the si.e of the software de"elopment pro9ect, or at least help define a method

should be able to pro"ide schedule estimates accurately )he purpose of scheduling is not only to predict task completion gi"en task se<uence and a"ailable resources, but also to establish starting and ending dates for the associated work packages and life cycle phases

157

'2(

Pro"ide maintenance estimates separately - )he software estimating tool

should be able to pro"ide software maintenance estimates as a separate item Software maintenance includes such acti"ities as correcting errors, modifying the software to accommodate changes in re<uirements, or e$tending and enhancing software performance I%3,t Data C! e't$!% A "ery important aspect of software estimating is data collection /ata must be collected for inputs to the parametric tool and tool "erification, "alidation, customi.ation, and calibration 7stimates generated by the tools are only as good as the input data used Careful analysis of all tool inputs are essential since small changes in input "alues can result in large "ariations in o"erall cost and schedules !nputs "ary between tools ;efore using a tool, re"iew input re<uirements and information collected, documentation, and e$amples pro"ided with the tool :hen possible, discuss these with indi"iduals familiar with the tool ,sing historical data as a basis for customi.ing or calibrating a tool is essential !nsure that information for current pro9ect de"elopment efforts are sa"ed for future reference At a "ery minimum, use software life cycle model phases and acti"ities as a basis for collecting and maintaining pro9ect de"elopment information for future tool use S!-e C!--er'$a T!! * )here are many software estimating tools on the market today that pro"ide software estimation support Some tools estimate the si.e of the software pro9ect, while others use si.e as an input and pro"ide estimates of effort, schedule and cost )he tools presented in this handbook are not being recommended o"er other tools as each one has uni<ue capabilities and limitations )herefore, organi.ations considering using estimating tools should re"iew as many a"ailable tools as possible, analy.e their software estimating needs, and then determine which tools are most appropriate to their application and de"elopment en"ironment )he list that follows is not all inclusi"e, and should not be considered complete )he tools discussed are representati"e only, since there are many others that could be used REVIC

152

Parametric Cost Analysis Handbook

)he Ge"ised 7nhanced Cersion of !ntermediate C0C0&0 'G7C!C( model was de"eloped by &r Gaymond 4 Lile formerly of Hughes Aerospace de"elopment for use by its contract administrator )he main difference between G7C!C and C0C0&0 is the coefficients used in the effort e<uations G7C!C changed the coefficients based on a database of recently completed /0/ pro9ects !t also uses a different method of distributing effort and schedule to each phase of product de"elopment, and applies an automatic calculation of standard de"iation for risk assessment G7C!C pro"ides a single Nweighted a"erageN distribution for effort and schedule along with the ability to let the user "ary the percentages in the system engineering and de"elopment test and e"aluation phases G7C!C employs a different Ada model than Ada C0C0&0 )he G7C!C model has also been enhanced by using a Program 7"aluation and Ge"iew )echni<ue 'P7G)( statistical method for determining the lines of code to be de"eloped !n addition to pro"iding estimates for cost, manpower, and schedule, the program creates estimates for typical /0/-S)/-5137ADEB2 documentation si.ing and long term software maintenance G7C!CJs schedule estimates are often considered lengthy because it assumes that a pro9ectJs documentation and re"iews comply with the full re<uirements of /0/-S)/-5137ADEB2 G7C!C operates on PC compatible systems PRICES )he PG!C7S tool is distributed by 4ockheed - &artin PG!C7 Systems )his tool was first de"eloped in 1B77, and is considered one of the first comple$ commercially a"ailable tools used for software estimation )he e<uations used by this tool are proprietary Howe"er, descriptions of the methodology algorithms used can be found in papers published by PG!C7 Systems describing the PG!C7S parametric tool is shown in #igure C-E A model )he Air #orce Contract &anagement /i"ision, Air #orce System Command, Lirtland Air #orce ;ase, Aew &e$ico, sponsored the

15B

FIGURE V - 7

)he PG!C7S tool is based on Cost 7stimation Gelationships 'C7Gs( that make use of product characteristics in order to generate estimates de"eloped with e$pert 9udgment A ma9or input to PG!C7S is Source 4ines of Code 'S40C( Software si.e may be input directly, or automatically calculated from <uantitati"e descriptions 'function point si.ing( 0ther inputs include software function, operating en"ironment, software reuse, comple$ity factors, producti"ity factors, and risk analysis factors Successful use of the PG!C7S tool depends on the ability of the user to define inputs correctly !t can be customi.ed and calibrated to the needs of the user !t is now a"ailable for :indows and ,A!1D&otif C7Gs were determined by statistically analy.ing completed pro9ects where product characteristics and pro9ect information were known, or

160

Parametric Cost Analysis Handbook

SASET )he Software Architecture, Si.ing and 7stimating )ool 'SAS7)( was de"eloped for /0/ by the &artin &arietta Corporation a wide range of applications SAS7) pro"ides functional software si.ing "alues, de"elopment schedules, and associated man-loading outputs de"elopment cycle !t pro"ides estimates for all types of programs and all phases of the !t also pro"ides estimates for maintenance support and performs a risk SAS7) is a forward-chaining, rule-based e$pert system utili.ing a hierarchiacally structured knowledge database )he database is composed of pro9ects with

assessment on si.ing, scheduling, and budget data SAS7) uses a fi"e-tiered approach for estimating including class of software, source lines of code, software comple$ity, maintenance staff loading, and risk assessment )he user can either input the program si.e directly or allow SAS7) to compute si.e, based on function-related inputs )he tool also has an e$tensi"e customi.ation file in which the user can ad9ust many parameters operates on PC compatible systems SEER-SEM System 7"aluation and 7stimation of Gesources - Software 7stimation &odel 'S77G-S7&( is distributed by 8alorath Associates and is currently under a fi"e year Air #orce wide license agreement !t pro"ides software estimates with knowledge bases de"eloped from many years of completed pro9ects )he knowledge base allows estimates with only minimal high le"el inputs )he user need only select the platform 'i e ground, unmanned space, etc (, application 'i e command and control, diagnostic(, de"elopment methods 'i e prototype, incremental(, and de"elopment standards 'i e 5137ADEB2( S77G-S7& is applicable to all types of software pro9ects and considers all phases of software de"elopment S77G-S7& is designed to run on PC compatible systems running &icrosoft :indows 6 0D6 1 'Air #orce license includes &S-/0S "ersion( !t is also a"ailable for the Apple &ac!ntosh running system 3 0 6 and abo"e and the ,A!1DS,A work station A companion tool called the S77G-Software Si.ing &odel 'SS&( is also distributed by 8alorath Associates and is used to estimate the si.e of the software product SLIM !t

161

)he Software 4ife Cycle &odel 'S4!&( is marketed by Ouantitati"e Software 'OS&( S4!& was de"eloped in 1B7B by &r 4arry Putnam 0riginally de"eloped from analyses of groundbased radar programs, the S4!& tool has been e$panded to include other types of programs !t can be customi.ed for the userJs de"elopment en"ironment S4!& supports all phases of software de"elopment, e$cept re<uirements analysis, as well as all si.es of software pro9ects, but was especially designed to support large pro9ects Success in using S4!& depends on the userJs ability to customi.e the tool to fit the software de"elopment en"ironment and to estimate both a Producti"ity !nde$ 'a measure of the software de"eloperJs efficiency( and a &anpower ;uildup !nde$ 'a measure of the software de"eloperJs staffing capability( S4!& also pro"ides a life cycle option which e$trapolates de"elopment costs into the maintenance phase A companion tool named S!P7 Planner is also distributed by OS& and is used to estimate the si.e of the software product OS& pro"ides a training course and leases the tool "ia a time sharing ser"ice )here is also a PC compatible "ersion of S4!& that can be leased for a yearly fee SOFTCOST-R S0#)C0S)-G is a software estimating tool de"eloped by Geifer Consultants, !nc 'GC!( S0#)C0S)-G is based upon the modeling work done by /r Gobert )ausworthe of the Qet Propulsion 4aboratory !t contains a database of o"er 1F00 data processing, scientific and real-time programs A key input is S40C, which can be input directly or computed from #unction Points S0#)C0S)-G is applicable to all types of programs, howe"er, it was specifically configured to estimate real-time and scientific software systems, and considers all phases of the software de"elopment cycle )he toolJs primary input is S40C, howe"er, it also uses the same inputs and pro"ides the same outputs as C0C0&0 which allows direct comparisons to be made S0#)C0S)-G has some uni<ue inputs such as user and peer re"iews, customer e$perience, and degree of standardi.ation !t also supports a standard :;S for task planning and scheduling GC! pro"ides S0#)C0S)-Ada, which is a tool to estimate Ada and CRR de"elopment costs Softcost-Ada is a cost estimation tool specifically de"eloped to estimate systems using ob9ectoriented techni<ues

165

Parametric Cost Analysis Handbook

GC! also has a separate estimating tool called ASS7)-G to estimate the si.e of the software product S0#)C0S)-G, S0#)C0S)-Ada, and ASS7)-G are leased on an annual license basis, and re<uire a PC compatible running /0S 5 6 or higher SYSTEM-7 SMS)7&-E is marketed by Computer 7conomics, !nc 'C7!( !t contains a proprietary model that is based on the work of Qensen, ;oehm, Putnam, and other noted software e$perts SMS)7&-E is applicable to all types of programs and all phases of the software life cycle !nputs consist of si.e 'S40C(, twenty en"ironmental factors, se"en de"elopment factors, software type, and constraints )his tool comes with 56 predefined default parameter files )he default sets pro"ide typical "alues for all parameters e$cept si.e )here are also se"en parameter subset files for "arious implementations of /0/-S)/-1706, /0/-S)/-5137ADEB2, and "arying degrees of Ada e$perience )he user must select one of the default sets and input the S40C estimate to perform a <uick estimate SMS)7&-E can accommodate multiple CSC!s or tasks, and each task can be broken down into elements and units )here is a limit of 3E tasks, 3E elements, and 3E units SMS)7&-E can be customi.ed to reflect the userJs software de"elopment en"ironment C7! has a companion software si.e estimating tool called Computer 7conomics !ncorporated Si.ing 'C7!S( System )hese tools operate on PC compatible systems S!ft.are S$8$%0 T!! * As discussed pre"iously, a "ery important factor in estimating software de"elopment pro9ects is the ability to estimate the si.e of the product &any software estimating tools use si.e in S40C or functions performed as the ma9or input Si.e is also considered by software de"elopment pro9ect managers as a ma9or technical performance or producti"ity indicator that allows them to track the pro9ect during software de"elopment )he most commonly used method to estimate the si.e of a software product is by using both e$pert 9udgment and the analogy method )he e$perts determine the functions the software will perform and estimate the si.e by comparing the new system to completed pro9ects with similar characteristics 0ften, parametric methods are the used to precisely si.e the software 7stimating tools using analogy methods compare the new program to similar programs of known si.e ;ecause past pro9ects are not always e$actly like the new pro9ect, the estimate is

166

ad9usted by a factor determined from e$perience )hese tools accept characteristics of new programs as inputs, then search a database for similar programs )he tools either list the similar programs or pro"ide an estimate of si.e based on an a"erage of the si.e of the similar programs selected from the database 7$pert 9udgment tools use the opinion of one or more e$perts to estimate the si.e of the program, or use structured <uestions designed to e$tract 9udgment from the e$perts )hese are the rule-based or e$pert system tools &any tools use the algorithmic method by applying e<uations to determine si.e estimates A techni<ue that is becoming "ery widely used is #unction Point Analysis '#PA( 0ne problem with #PA is that it was de"eloped for !S-oriented programs and does not take into consideration the number or comple$ity of algorithms in scientific and real-time programs &any software estimating tools such as G7C!C and S4!& use e$tensions of the Program 7"aluation and Ge"iew )echni<ue 'P7G)( 7$pected Si.e K 'S R E'&( R 4(D3 where S, &, and 4 are estimates of the smallest si.e, most likely si.e, and the largest si.e, respecti"ely ASSET-R ASS7)-G is a function point si.ing tool de"eloped to estimate the si.e of data processing, real-time, and scientific software systems, and is marketed by Geifer Consultants, !nc !t utili.es a knowledge-based system which e$tends the theory of function points into scientific and real-time systems by considering issues like concurrence, synchroni.ation, and reuse in its mathematical formulation )he formulas use as many as nine parameters to de"elop function point counts !t also couples function point and operandDoperator counts with architectural, language e$pansion, and technology factors to generate the si.e estimate ASS7)-G works with GC!Js S0#)C0S)-G and S0#)C0S)-Ada software estimation tools !t operates on PC compatible systems CA-FP63ert CA-#P1pert is distributed by Computer Associates !nternational, !nc !t uses #PA for si.e estimation of !S type software pro9ects, and conforms to accepted !#P,8 standard counting practices !t includes an on-line tutor to help the function point counting process CA-#P1pert P7G) is based on a beta distribution of estimates pro"ided by the user and calculates e$pected si.e according to the e<uation*

16E

Parametric Cost Analysis Handbook

works in con9unction with CA-7S)!&ACS to pro"ide software si.e estimation input, and operates on PC compatible systems CEIS C7!S is marketed by Computer 7conomics, !nc 7stimates are generated by comparing the attributes of the new pro9ect to the attributes of three reference pro9ects of known si.e )he user determines any si$ attributes that contribute to the number of lines of code and ranks them in order of importance, then selects three reference pro9ects of known si.e Separate algorithms are used to produce four independent estimates and to determine a le"el of confidence con9unction with SMS)7&-E, and operates on PC compatible systems SI9EE6PERT S!P771P7G) was de"eloped by the !nstitute for Systems Analysis and is marketed by )echnology ApplicationD7ngineering Corporation )his tool is an e$pert 9udgment tool that produces estimates of liens of code based on <uestions asked by C0S)71P7G) ;oth tools are packaged and distributed together, and operate on PC compatible systems SEER-M S77G-& is marketed by 8alorath Associates and is a"ailable to go"ernment personnel under and Air #orce-wide contract !t produces software si.e estimates in lines of code or function points !t also pro"ides its own historical database in producing the si.e estimate S77G-& works with S77G-S7& software estimating tool, and operates on PC compatible systems Appendi$ # includes other currently a"ailable cost models, and discusses in more detail the most popular software estimating tools GLOSSARY OF TERMS Appendi$ A contains definitions of terms commonly used in software estimation technology MODEL CALI2RATION C7!S works in

16F

)he act of calibration standardi.es a model outside of their particular en"ironment

&any models are de"eloped for specific Such models usually are not useful

situations and are, by definition, calibrated to that situation

Howe"er, general cost estimating models including

commercially a"ailable ones such as the #AS), PG!C7 and S77G models 'described earlier( are designed to be useful as estimating tools for a wide range of situations )he act of calibration is needed to increase the accuracy of one of these general models by making it temporarily a specific model for whate"er product it has been calibrated for Calibration is in a sense customi.ing a generic model !tems which can be calibrated in a model are* product types, operating en"ironments, labor rates and factors, "arious relationships between functional cost items, and e"en the method of accounting used by a contractor All general models should be standardi.ed 'i e calibrated(, unless used by an e$perienced modeler with the appropriate education, skills and tools, and e$perience in the technology being modeled Calibration is the process of determining the de"iation from a standard in order to compute the correction factors #or cost estimating models, the standard is considered historical actual costs )he calibration procedure is theoretically "ery simple !t is simply running the model with normal inputs 'known parameters such as software lines of code( against items for which the actual cost are known )hese estimates are then compared with the actual costs and the a"erage de"iation becomes a correction factor for the model !n essence, the calibration factor obtained is really good only for the type of inputs that were used in the calibration runs #or a general total model calibration, a wide range of components with actual costs need to be used ;etter yet, numerous calibrations should be performed with different types of components in order to obtain a set of calibration factors for the "arious possible e$pected estimating situations #or instance, the PG!C7 Software &odel addresses this situation using internal producti"ity factors )hese can be modified by the calibration process TRENDS AND CONCLUSIONS Tre%"* Ad"ances in languages, de"elopment methodologies, and other areas will ha"e to be addressed by future software cost estimating models and associated methodologies As software technology matures, changes in de"elopment and support concepts occur which will impact software

163

Parametric Cost Analysis Handbook

cost estimating Concepts such as prototyping and spiral de"elopment present a challenge to cost estimation since normal software de"elopment cycles are altered Artificial !ntelligence 'A!( represents a growing area of modern technology Since A! is software-intensi"e, proper management of A! software, including cost estimating, will be a challenge for software managers )he de"elopment of software for e$pert system and other A! applications will probably re<uire a different de"elopment process )he trend for the future will include better and more accurate ways of de"eloping software estimating methodologies for* + Software si.e estimates + Gesource 7stimates for maintenance and support + !ncorporating the effects of Ada and new paradigms such as rapid prototyping and fourth generation languages + &odeling the dynamic interaction of "ariables that affect producti"ity, cost, and <uality + 0b9ect-0riented /esign )he trend in software estimating tools is to pro"ide a whole family of models which not only estimate cost and effort of software de"elopment, but hardware as well upgraded to support higher-order languages such as Ada and CRR )he tools are being )he most significant

impro"ement is the use of data collected from past software pro9ects to customi.e the tool to an organi.ationJs en"ironment )his is especially true within agencies of /0/ and AASA C!%' ,*$!%* )his chapter has discussed the software estimating process and the "arious methodologies used in software estimation )he basic software estimating functional capabilities were also discussed A few different software estimating tools were e$amined A re"iew of product literature and user manuals indicate that many tools will perform most of the functional capabilities outlined in this chapter )he users generally agree that the tools they are using satisfy their re<uirements )he software estimating organi.ation must be able to customi.e the software estimating tool to their own software de"elopment en"ironment )his re<uires collecting historical data from past completed pro9ects to accurately pro"ide the inputs that the software tool re<uires )he software de"elopment organi.ation should establish a staff that is thoroughly trained in the use of the tools

167

)his staff should do all the software estimating acti"ities and determine what data should be collected to pro"ide a historical database for future reference )he use of two or more software estimating tools using different methodologies is recommended )he software de"elopment organi.ation should select a primary tool for software estimating and an alternate tool for comparison and "alidation software estimating for the following reasons* + 7<uations are based on pre"ious historical de"elopment pro9ects + 0utputs are repeatable and formulas can be analy.ed + )hey can be customi.ed to fit the userJs en"ironment + )hey re<uire minimal time and effort to use + )hey are particularly useful in earlier phases of software de"elopment + )hey are most fre<uently used by /0/ agencies )hese tools should be used throughout the software de"elopment process Parametric tools are considered to be the best for

162