Cost Affecting Software Pricing

7/27/2019 Cost Affecting Software Pricing

1/13

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 1Software cost estimationIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 2-ectives

To introduce the fundamentals of softwarecosting and pricing

To descri-e three metrics for softwareproductivity assessment

To explain why different techniques should-e used for software estimation

To descri-e the principles of the CC 2algorithmic cost estimation modelIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 3Topics covered

Software productivityEstimation techniquesAlgorithmic cost modellingProect duration and staffing

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 4undamental estimation questions

How much effort is required to complete anactivity?

How much calendar time is needed to

complete an activity?What is the total cost of an activity?Proect estimation and scheduling are

interleaved management activities.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 5Software cost components

Hardware and software costs.Travel and training costs.Effort costs (the dominant factor in most

proects) The salaries of engineers involved in the proect; Social and insurance costs.

Effort costs must take overheads into account

Costs of -uilding, heating, lighting. Costs of networking and communications. Costs of shared facilities (e.g li-rary, staff restaurant,etc.).Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 6Costing and pricing

Estimates are made to discover the cost, tothe developer, of producing a softwaresystem.

There is not a simple relationship -etweenthe development cost and the price chargedto the customer.

Broader organisational, economic, political

and -usiness considerations influence theprice charged.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 7Software pricing factorsarketopportunityA development organisation may quote a low price because itwishes to move into a new segment oI the soItware market.Accepting a low proIit on one proiect may give the opportunityoI more proIit later. The experience gained may allow new


2/13

products to be developed.Cost estimateuncertaintyII an organisation is unsure oI its cost estimate, it may increaseits price by some contingency over and above its normal proIit.Contractual terms A c ustomer may be willing to allow the developer toretain

ownership oI the source code and reuse it in other proiects. Theprice charged may then be less than iI the soItware source codeis handed over to the customer.RequirementsvolatilityII the requirements are likely to change, an organisation maylower its price to win a contract. AIter the contract is awarded,high prices can be charged Ior changes to the requirements.Financial health Developers in Iinancial diIIiculty may lower their price to gaina c ontract. It is better to make a smaller than normal proIit orbreak even than to go out oI business.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 8

A measure of the rate at which individualengineers involved in software developmentproduce software and associateddocumentation.

Not quality-oriented although qualityassurance is a factor in productivityassessment.

Essentially, we want to measure usefulfunctionality produced per time unit.Software productivityIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 9

Size related measures -ased on someoutput from the software process. This may-e lines of delivered source code, o-ectcode instructions, etc.

unction-related measures -ased on anestimate of the functionality of the delivered

software. unction-points are the -est knownof this type of measure.Productivity measuresIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 10

Estimating the size of the measure (e.g. howmany function points).

Estimating the total num-er of programmermonths that have elapsed.

Estimating contractor productivity (e.g.documentation team) and incorporating thisestimate in overall estimate.easurement pro-lemsIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 11

What's a line of code? The measure was first proposed when programs weretyped on cards with one line per card; How does this correspond to statements as in Java whichcan span several lines or where there can -e severalstatements on one line.

What programs should -e counted as part of thesystem?

This model assumes that there is a linearrelationship -etween system size and volume of


3/13

documentation.Lines of codeIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 12

The lower level the language, the moreproductive the programmer The same functionality takes more code to implement in alower-level language than in a high-level language.

The more ver-ose the programmer, the higherthe productivity easures of productivity -ased on lines of code suggestthat programmers who write ver-ose code are moreproductive than programmers who write compact code.Productivity comparisonsIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 13System development timesnalysis Design Coding Testing DocumentationAssembly codeHigh-level language3 weeks3 weeks5 weeks5 weeks8 weeks4 weeks

10weeks6 weeks2 weeks2 weeksSize Effort ProductivityAssembly codeHigh-level language5000 lines1500 lines28 weeks20 weeks714 lines/month

300 lines/monthIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 14unction points

Based on a com-ination of program characteristics external inputs and outputs; user interactions; external interfaces; files used -y the system.

A weight is associated with each of these and thefunction point count is computed -y multiplying eachraw count -y the weight and summing all values.& |ruro e( o l e|erer l s o l d| ver l vpe) L |We | drl)Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 15

unction pointsThe function point count is modified -y complexity ofthe proect

Ps can -e used to estimate LC depending on theaverage num-er of LC per P for a given language LC = AVC * num-er of function points; AVC is a language-dependent factor varying from 200-300 for assem-le language to 2-40 for a 4GL;

Ps are very su-ective. They depend on theestimator


4/13

Automatic function-point counting is impossi-le.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 16-ect points-ect points (alternatively named applicationpoints) are an alternative function-related measureto function points when 4Gls or similar languagesare used for development.-ect points are NT the same as o-ect classes.The num-er of o-ect points in a program is a

weighted estimate of The num-er of separate screens that are displayed; The num-er of reports that are produced -y the system; The num-er of program modules that must -e developedto supplement the data-ase code;Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 17-ect point estimation-ect points are easier to estimate from aspecification than function points as they aresimply concerned with screens, reports andprogramming language modules.

They can therefore -e estimated at a fairlyearly point in the development process.

At this stage, it is very difficult to estimatethe num-er of lines of code in a system.

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 18#eal-time em-edded systems, 40-160LC/P-month.

Systems programs , 150-400 LC/P-month.Commercial applications, 200-900

LC/P-month.n o-ect points, productivity has -een

measured -etween 4 and 50 o-ectpoints/month depending on tool support anddeveloper capa-ility.Productivity estimatesIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 19actors affecting productivity

ApplicationdomainexperienceKnowledge oI the application domain is essential Ior eIIectivesoItware development. Engineers who already understand adomain are likely to be the most productive.Process quality The development process used can have a s igniIicant eIIect onproductivity. This is covered in Chapter 28.Proiect size The larger a proiect, the more time required Ior teamcommunications. Less time is available Ior development soindividual productivity is reduced.Technology

supportGood support technology such as C ASE tools, conIigurationmanagement systems, etc. can improve productivity.WorkingenvironmentAs I discussed in Chapter 25, a q uiet working environment withprivate work areas contributes to improved productivity.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 20

All metrics -ased on volume/unit time areflawed -ecause they do not take quality into


5/13

account.Productivity may generally -e increased at the

cost of quality.t is not clear how productivity/quality metrics

are related.f requirements are constantly changing then an

approach -ased on counting lines of code is notmeaningful as the program itself is not static;Quality and productivityIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 21Estimation techniques

There is no simple way to make an accurateestimate of the effort required to develop a softwaresystem nitial estimates are -ased on inadequate information in auser requirements definition; The software may run on unfamiliar computers or usenew technology; The people in the proect may -e unknown.

Proect cost estimates may -e self-fulfilling The estimate defines the -udget and the product isadusted to meet the -udget.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 22Changing technologies

Changing technologies may mean that previousestimating experience does not carry over to newsystems Distri-uted o-ect systems rather than mainframesystems; Use of we- services; Use of E#P or data-ase-centred systems; Use of off-the-shelf software; Development for and with reuse; Development using scripting languages; The use of CASE tools and program generators.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 23Estimation techniques

Algorithmic cost modelling.Expert udgement.Estimation -y analogy.Parkinson's Law.Pricing to win.

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 24Estimation techniquesAlgorithmiccost modellingA model based on historical cost inIormation that relates some soItwaremetric (usually its size) to the proiect cost is used. An estimate is madeoI that metric and the model predicts the eIIort required.Expert

iudgementSeveral experts on the proposed soItware development techniques andthe application domain are consulted. They each estimate the proiectcost. These estimates are compared and discussed. The estimationprocess iterates until an agreed estimate is reached.Estimation byanalogyThis technique is applicable when other proiects in the same applicationdomain have been completed. The cost oI a new proiect is estimated byanalogy with these completed proiects. yers (yers 1989) gives a


6/13

very clear description oI this approach.ParkinsonOsLawParkinsonOsLaw states that work expands to Iill the time available. Thecost is determined by available resources rather than by obiectiveassessment. II the soItware has to be delivered in 12 months and 5people are available, the eIIort required is estimated to be 60 person-months.Pricing to win The soItware cost is estimated to be whatever the customer hasavailable to spend on the proiect. The estimated eIIort depends on thecustomerOs budget and not on the soItware Iunctionality.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 25Pricing to win

The proect costs whatever the customer hasto spend on it.

Advantages: You get the contract.

Disadvantages: The pro-a-ility that the customer gets thesystem he or she wants is small. Costs do notaccurately reflect the work required.

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 26Top-down and -ottom-up estimationAny of these approaches may -e used top-

down or -ottom-up.Top-down

Start at the system level and assess the overallsystem functionality and how this is deliveredthrough su--systems.

Bottom-up Start at the component level and estimate theeffort required for each component. Add theseefforts to reach a final estimate.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 27

Top-down estimationUsa-le without knowledge of the systemarchitecture and the components that might-e part of the system.

Takes into account costs such as integration,configuration management anddocumentation.

Can underestimate the cost of solvingdifficult low-level technical pro-lems.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 28Bottom-up estimation

Usa-le when the architecture of the systemis known and components identified.

This can -e an accurate method if thesystem has -een designed in detail.t may underestimate the costs of system

level activities such as integration anddocumentation.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 29Estimation methods

Each method has strengths and weaknesses.Estimation should -e -ased on several methods.f these do not return approximately the same result,


7/13


8/13

complexityFormula DescriptionSimple!V = 2. 1 |K0$ )1.0 5L VWell-understood applications

developed by small teams.oderate!V = 3. 0 |K0$ )1.1 2LVore complex proiects where

team members may have limitedexperience oI related systems.Embedded!V = 3. |K0$ )1.2 0L VComplex proiects where the

soItware is part oI a stronglycoupled complex oI hardware,soItware, regulations andoperational procedures.

Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 36CC 2CC 81 was developed with the

assumption that a waterfall process would -eused and that all software would -e developedfrom scratch.

Since its formulation, there have -een manychanges in software engineering practice andCC 2 is designed to accommodatedifferent approaches to software development.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 37CC 2 models

CC 2 incorporates a range of su--models

that produce increasingly detailed softwareestimates.The su--models in CC 2 are:

Application composition model. Used when software iscomposed from existing parts. Early design model. Used when requirements areavaila-le -ut design has not yet started. #euse model. Used to compute the effort of integratingreusa-le components. Post-architecture model. Used once the systemarchitecture has -een designed and more informationa-out the system is availa-le.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 38

Use of CC 2 modelsIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 39Application composition model

Supports prototyping proects and proects wherethere is extensive reuse.

Based on standard estimates of developerproductivity in application (o-ect) points/month.

Takes CASE tool use into account.ormula is

W !V = | NA! L |1 - (euse/100 ) ) / !#0


9/13

W !V is the effort in person-months, NA! is the num-er ofapplication points and !#0 is the productivity.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 40-ect point productivityDeveloperOs experienceand capabilityVery low Low Nominal High Very highICASE maturity andcapabilityVery low Low Nominal High Very highPROD (NOP/month) 4 7 13 25 50Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 41Early design model

Estimates can -e made after therequirements have -een agreed.

Based on a standard formula for algorithmicmodelsW !V = A L $|ze8L V whereW V = PE#S L #CPX L #USE L PD L P#EX LCL L SCED; A = 2.94 in initial cali-ration, Size in KLC, Bvaries from 1.1 to 1.24 depending on novelty of

the proect, development flexi-ility, riskmanagement approaches and the processmaturity.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 42ultipliersultipliers reflect the capa-ility of thedevelopers, the non-functional requirements,the familiarity with the development platform,etc. #CPX - product relia-ility and complexity; #USE - the reuse required; PD - platform difficulty; P#EX - personnel experience;

PE#S - personnel capa-ility; SCED - required schedule; CL - the team support facilities.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 43The reuse model

Takes into account -lack--ox code that isreused without change and code that has to-e adapted to integrate it with new code.

There are two versions: Black--ox reuse where code is not modified. Aneffort estimate (P) is computed. White--ox reuse where code is modified. A sizeestimate equivalent to the num-er of lines of

new source code is computed. This then aduststhe size estimate for new code.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 44#euse model estimates 1

or generated code: P = (ASLC * AT/100)/ATP#D ASLC is the num-er of lines of generatedcode AT is the percentage of code automaticallygenerated.


10/13

ATP#D is the productivity of engineers inintegrating this code.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 45#euse model estimates 2

When code has to -e understood andintegrated: ESLC = ASLC * (1-AT/100) * AA. ASLC and AT as -efore. AA is the adaptation adustment multipliercomputed from the costs of changing the reusedcode, the costs of understanding how tointegrate the code and the costs of reusedecision making.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 46Post-architecture level

Uses the same formula as the early designmodel -ut with 17 rather than 7 associatedmultipliers.

The code size is estimated as: Num-er of lines of new code to -e developed; Estimate of equivalent num-er of lines of new codecomputed using the reuse model; An estimate of the num-er of lines of code thathave to -e modified according to requirements

changes.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 47This depends on 5 scale factors (see next slide).

Their sum/100 is added to 1.01A company takes on a proect in a new domain. The

client has not defined the process to -e used andhas not allowed time for risk analysis. The companyhas a C level 2 rating. Precedenteness - new proect (4) Development flexi-ility - no client involvement - Very high(1) Architecture/risk resolution - No risk analysis - V. Low .(5) Team cohesion - new team - nominal (3)

Process maturity - some control - nominal (3)Scale factor is therefore 1.17.The exponent termIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 48Exponent scale factorsPrecedentedness ReIlects the previous experience oI the organisation with thistype oIproiect. Very low means no previous experience, Extra high meansthat the organisation is completely Iamiliar with this applicationdomain.DevelopmentIlexibilityReIlects the degree oI Ilexibility in the development process. Very

low means a prescribed process is used; Extra high means that theclient only sets general goals.Architecture/riskresolutionReIlects the extent oI risk analysis carried out. Very low means littleanalysis, Extra high means a complete a thorough risk analysis.Team cohesion ReIlects how well the development team know each other and worktogether. Very low means very diIIicult interactions, Extra highmeans an integrated and eIIective team with no communicationproblems.


11/13

Process maturity ReIlects the process maturity oI the organisation. The computationoI this value depends on the C aturity Questionnaire but anestimate can be achieved by subtracting the C process maturitylevel Irom 5.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 49

Product attri-utes Concerned with required characteristics of the softwareproduct -eing developed.

Computer attri-utes Constraints imposed on the software -y the hardwareplatform.

Personnel attri-utes ultipliers that take the experience and capa-ilities of thepeople working on the proect into account.

Proect attri-utes Concerned with the particular characteristics of thesoftware development proect.ultipliersIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 50Effects of cost driversExponent value 1.17System size (including Iactors Ior reuseand requirements volatility)

128, 000 DSInitial COCOMO estimate withoutcost drivers730 person-monthsReliability Very high, multiplier 1.39Complexity Very high, multiplier 1.3emory constraint High, multiplier 1.21Tool use Low, multiplier 1.12Schedule Accelerated, multiplier 1.29djusted COCOMO estimate 2306 person-monthsReliability Very low, multiplier 0.75Complexity Very low, multiplier 0.75emory constraint None, multiplier 1

Tool use Very high, multiplier 0.72Schedule Normal, multiplier 1djusted COCOMO estimate 295 person-monthsIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 51

Algorithmic cost models provide a -asis forproect planning as they allow alternativestrategies to -e compared.

Em-edded spacecraft system ust -e relia-le; ust minimise weight (num-er of chips); ultipliers on relia-ility and computer constraints > 1.

Cost components Target hardware;

Development platform; Development effort.Proect planningIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 52anagement optionsIan Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 53anagement option costsOption RELY STOR TME TOOLS LTEX Total effort Software cost Hardwarecost


12/13

Total costA 1.39 1.06 1.11 0.86 1 63 949393 100000 1049393B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025C 1.39 1 1.11 0.86 1 60 895653 105000 1000653D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490E 1.39 1 1 0.72 1.22 56 844425 220000 1044159F 1.39 1 1 1.12 0.84 57 851180 120000 1002706Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 54ption choiception D (use more experienced staff)appears to -e the -est alternative However, it has a high associated risk asexperienced staff may -e difficult to find.ption C (upgrade memory) has a lower costsaving -ut very low risk.verall, the model reveals the importance ofstaff experience in software development.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 55Proect duration and staffing

As well as effort estimation, managers mustestimate the calendar time required to complete aproect and when staff will -e required.

Calendar time can -e estimated using a CC 2formula

TDEV = 3 L (P)(0.33+0.2*(B-1.01)) P is the effort computation and B is the exponentcomputed as discussed a-ove (B is 1 for the earlyprototyping model). This computation predicts the nominalschedule for the proect.

The time required is independent of the num-er ofpeople working on the proect.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 56Staffing requirements

Staff required can't -e computed -y divingthe development time -y the requiredschedule.

The num-er of people working on a proectvaries depending on the phase of the proect.The more people who work on the proect,

the more total effort is usually required.A very rapid -uild-up of people often

correlates with schedule slippage.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 57Key points

There is not a simple relationship -etweenthe price charged for a system and itsdevelopment costs.

actors affecting productivity includeindividual aptitude, domain experience, the

development proect, the proect size, toolsupport and the working environment.Software may -e priced to gain a contract

and the functionality adusted to the price.Ian Sommerville 2004 Software Engineering. 7th edition. Chapter 26 Slide 58Key points

Different techniques of cost estimation should -e usedwhen estimating costs.

The CC model takes proect, product, personneland hardware attri-utes into account when predicting


13/13

effort required.Algorithmic cost models support quantitative option

analysis as they allow the costs of different options to-e compared.

The time to complete a proect is not proportional to thenum-er of people working on the proect.

Documents

Cost Affecting Software Pricing