PCEH-5

8/14/2019 PCEH-5

1/32

Parametric Cost Analysis Handbook

CHAPTER V

SOFTWARE PARAMETRIC

COST ESTIMATING

107

8/14/2019 PCEH-5

2/32

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 !n simple terms, a software program is a set of

instructions for a computer Software is critical, not only in the control of space based systems,

but in "irtually all current military systems #or e$ample, software controls aircraft engines,

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-/S '&icro Soft /isk perating System(, for e$ample, is a trade name for the

operating system for !ntel 23 Personal Computers 4)S 156 and &icro Soft $cel are

e$amples of application based software 4isting a directory of user files is a utility softwarefunction )he system software procured by the S 8o"ernment is usually a comple$ combination

of all three types of software

THE IMPORTANCE OF SOFTWARE TODAY

102

8/14/2019 PCEH-5

3/32


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 re-

engineering or 9ust business re-engineering )he reader should ne"er confuse business re-

engineering 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, chucks? that are functionally integrated )hese >chunks? are then analy.ed and regrouped

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 Software 'and organi.ations(

should correspond to a meta-model of the real-world !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

8/14/2019 PCEH-5

4/32

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

8/14/2019 PCEH-5

5/32


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

"irtually insatiable?

Software is an increasingly important element in military systems of all kinds )he

capabilities of current and future military systems are dependent on the performance of the

systems@ software As a system is upgraded or impro"ed, much of the additional capability is

achie"ed through new software !n fact, many of the functions essential to mission or

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 $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

8/14/2019 PCEH-5

6/32

+ 4ack of control at key points during de"elopment

+ 4ack of standardi.ation

+ 4ack of attention to cost of ownership considerations

+ 4ack of adecontractor? may be a // agency )he de"elopment contractor has the

responsibility for deli"ering a software product that meets all contractual re

8/14/2019 PCEH-5

7/32


processes !ncreasingly, the /o/ demands that software be de"eloped within predictable costs

and schedule nter, 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

//-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:aterfall? &odel, which ser"es as the conceptual guideline for

almost all Air #orce and ASA software de"elopment )he process described by the model

116

8/14/2019 PCEH-5

8/32

in"ol"es de"elopment through specific, se

8/14/2019 PCEH-5

9/32


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

8/14/2019 PCEH-5

10/32

complete, each build may follow the waterfall pattern for subse)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 ne 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 inadesolution? 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

8/14/2019 PCEH-5

11/32


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 ach 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 nce the :;S is established the ne$t step is to

determine which estimating techni)echnical Ge"iews and Audits for Systems,

8/14/2019 PCEH-5

12/32

Additionally, structured approaches to sub-task identification are e$tremely beneficial in

determining tasks and the re

8/14/2019 PCEH-5

13/32


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

8/14/2019 PCEH-5

14/32

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 o

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 ne method may o"erlook

system le"el acti"ities such as integration, while another method may ha"e included this, but

o"erlooked some key post-processing components #i"e of the methods discussed in /r;oehm@s book Software ngineering conomics are* analogy, bottom-up, top-down, e$pert

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!0 Meth!"

stimating 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 stimating 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 ne 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 // weapon systems may not ha"e historical precedents

)he analogy or comparati"e techni

8/14/2019 PCEH-5

15/32


;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

8/14/2019 PCEH-5

16/32

'S4C(, 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

8/14/2019 PCEH-5

17/32


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

8/14/2019 PCEH-5

18/32

+ $perience of team in the application area

+ $perience of team with the programming language and computer

+ se of tools and software engineering practices

+ Ge

8/14/2019 PCEH-5

19/32


to F function points per person month( #PA has been de"eloped and applied almost e$clusi"ely in

!nformation System applications A "ariation, called feature point analysis, has been defined for

other application areas )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

of feature points

/o not depend on a single cost or schedule estimate se se"eral estimating techni

8/14/2019 PCEH-5

20/32

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 !(

)his customi.ation re

8/14/2019 PCEH-5

21/32


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

early and

8/14/2019 PCEH-5

22/32

'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

8/14/2019 PCEH-5

23/32


)he Ge"ised nhanced ersion of !ntermediate CC& 'G!C( model was de"eloped

by &r Gaymond 4 Lile formerly of Hughes Aerospace )he Air #orce Contract &anagement

/i"ision, Air #orce System Command, Lirtland Air #orce ;ase, ew &e$ico, sponsored the

de"elopment for use by its contract administrator

)he main difference between G!C and CC& is the coefficients used in the effort

e

8/14/2019 PCEH-5

24/32

FIGURE V - 7

)he PG!CS tool is based on Cost stimation Gelationships 'CGs( that make use of

product characteristics in order to generate estimates CGs were determined by statistically

analy.ing completed pro9ects where product characteristics and pro9ect information were known, or

de"eloped with e$pert 9udgment

A ma9or input to PG!CS is Source 4ines of Code 'S4C( Software si.e may be input

directly, or automatically calculated from

8/14/2019 PCEH-5

25/32


SASET

)he Software Architecture, Si.ing and stimating )ool 'SAS)( was de"eloped for //

by the &artin &arietta Corporation SAS) is a forward-chaining, rule-based e$pert system

utili.ing a hierarchiacally structured knowledge database )he database is composed of pro9ects with

a wide range of applications

SAS) pro"ides functional software si.ing "alues, de"elopment schedules, and associated

man-loading outputs !t pro"ides estimates for all types of programs and all phases of the

de"elopment cycle !t also pro"ides estimates for maintenance support and performs a risk

assessment on si.ing, scheduling, and budget data

SAS) 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 SAS) to compute si.e, based on function-related inputs )hetool also has an e$tensi"e customi.ation file in which the user can ad9ust many parameters !t

operates on PC compatible systems

SEER-SEM

System "aluation and stimation of Gesources - Software stimation &odel 'SG-S&(

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 'ie ground, unmanned space, etc(, application 'ie command and control,

diagnostic(, de"elopment methods 'ie prototype, incremental(, and de"elopment standards 'ie

5137ADEB2( SG-S& is applicable to all types of software pro9ects and considers all phases of

software de"elopment

SG-S& is designed to run on PC compatible systems running &icrosoft :indows

60D61 'Air #orce license includes &S-/S "ersion( !t is also a"ailable for the Apple &ac!ntosh

running system 306 and abo"e and the !DS work station

A companion tool called the SG-Software Si.ing &odel 'SS&( is also distributed by

8alorath Associates and is used to estimate the si.e of the software product

SLIM

161

8/14/2019 PCEH-5

26/32

)he Software 4ife Cycle &odel 'S4!&( is marketed by Ouantitati"e Software 'OS&(

S4!& was de"eloped in 1B7B by &r 4arry Putnam riginally de"eloped from analyses of ground-

based 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

8/14/2019 PCEH-5

27/32


GC! also has a separate estimating tool called ASS)-G to estimate the si.e of the software

product S#)CS)-G, S#)CS)-Ada, and ASS)-G are leased on an annual license basis,

and re

8/14/2019 PCEH-5

28/32

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

$pert 9udgment tools use the opinion of one or more e$perts to estimate the si.e of the

program, or use structured

8/14/2019 PCEH-5

29/32


works in con9unction with CA-S)!&ACS to pro"ide software si.e estimation input, and operates

on PC compatible systems

CEIS

C!S is marketed by Computer conomics, !nc stimates 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 C!S works in

con9unction with SMS)&-E, and operates on PC compatible systems

SI9EE6PERTS!PG) was de"eloped by the !nstitute for Systems Analysis and is marketed by

)echnology ApplicationDngineering Corporation )his tool is an e$pert 9udgment tool that

produces estimates of liens of code based on

8/14/2019 PCEH-5

30/32

)he act of calibration standardi.es a model &any models are de"eloped for specific

situations and are, by definition, calibrated to that situation Such models usually are not useful

outside of their particular en"ironment Howe"er, general cost estimating models including

commercially a"ailable ones such as the #AS), PG!C and SG 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 'ie calibrated(, unless

used by an e$perienced modeler with the appropriate education, skills and tools, and e$perience inthe 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!C 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

8/14/2019 PCEH-5

31/32


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

8/14/2019 PCEH-5

32/32

)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 )hese tools should be used

throughout the software de"elopment process Parametric tools are considered to be the best for

software estimating for the following reasons*

+

PCEH-5

Documents