23 1

Chapter 2 – Evolution of Chapter 2 – Evolution of Software EconomicsSoftware Economics

2323 22

2.1 Software Economics2.1 Software Economics

Five fundamental parameters that can be Five fundamental parameters that can be abstracted from software costing models:abstracted from software costing models:• SizeSize• ProcessProcess• PersonnelPersonnel• EnvironmentEnvironment• Required QualityRequired Quality

Overviewed in Chapter 2 Overviewed in Chapter 2 Much more detail in Chapter 3.Much more detail in Chapter 3.

2323 33

Software Economics – ParametersSoftware Economics – Parameters(1 of 4)(1 of 4)

SizeSize: Usually measured in SLOC or number of Function Points required to : Usually measured in SLOC or number of Function Points required to realize the desired capabilities.realize the desired capabilities.• Function Points – a better metric earlier in projectFunction Points – a better metric earlier in project• LOC (SLOC, KLOC…) a better metric later in projectLOC (SLOC, KLOC…) a better metric later in project• These are These are notnot new metrics for measuring size, effort, personnel needs,… new metrics for measuring size, effort, personnel needs,…

ProcessProcess – used to guide all activities. – used to guide all activities.• Workers (roles), artifacts, activities…Workers (roles), artifacts, activities…• Support heading toward target and eliminate non-essential / less important Support heading toward target and eliminate non-essential / less important

activitiesactivities• Process Process criticalcritical in determining software economics in determining software economics

Component-based development; application domain…iterative approach, Component-based development; application domain…iterative approach, use-case driven…use-case driven…

• Movement toward ‘Movement toward ‘leanlean’ … everything!’ … everything!

Process

2323 44

Software Economics – ParametersSoftware Economics – Parameters(2 of 4)(2 of 4)

PersonnelPersonnel – capabilities of the personnel in – capabilities of the personnel in general and in the application domain in general and in the application domain in particularparticular• Motherhood: get the right people; good Motherhood: get the right people; good

people; Can’t always do this.people; Can’t always do this.• Much specialization nowadays. Some are Much specialization nowadays. Some are

terribly expensive.terribly expensive.• Emphasize ‘team’ and team responsibilities…Emphasize ‘team’ and team responsibilities…

Ability to work in a team; Ability to work in a team; Several newer light-weight methodologies are Several newer light-weight methodologies are

totally built around a team or very small group of totally built around a team or very small group of individuals…individuals…

2323 55

Software Economics – ParametersSoftware Economics – Parameters(3 of 4)(3 of 4)

EnvironmentEnvironment – the tools / techniques / – the tools / techniques / automated procedures used to support automated procedures used to support the development effort.the development effort.• Integrated tools; automated tools for Integrated tools; automated tools for

modeling, testing, configuration, managing modeling, testing, configuration, managing change, defect tracking, etc…change, defect tracking, etc…

Required QualityRequired Quality – the functionality – the functionality provided; performance, reliability, provided; performance, reliability, maintainability, scalability, portability, maintainability, scalability, portability, user interface utility; usability…user interface utility; usability…

2323 66

Software Economics – ParametersSoftware Economics – Parameters(4 of 4)(4 of 4)

EffortEffort = (personnel)(environment)(quality)(size ) = (personnel)(environment)(quality)(size )(Note: effort is exponentially related to size….)(Note: effort is exponentially related to size….)

What this means is that a 10,000 line application will cost What this means is that a 10,000 line application will cost lelesss s per lineper line than a 100,000 line application. than a 100,000 line application.

These figures – surprising to the uninformed – are true.These figures – surprising to the uninformed – are true. Fred Brooks – Mythical Man Month – cites over and over Fred Brooks – Mythical Man Month – cites over and over

that the additional that the additional communicationscommunications incurred when incurred when adding individuals to a project is very significant.adding individuals to a project is very significant.• Tend to have more reviews, meetings, training, biases, getting Tend to have more reviews, meetings, training, biases, getting

people up to speed, personal issues…people up to speed, personal issues… Let’s look at some of the trends:Let’s look at some of the trends:

Process

2323 77

Notice the Notice the ProcessProcess Trends….for three Trends….for three generations of software economicsgenerations of software economics

Conventional development (60s and 70s)Conventional development (60s and 70s)• Application – custom; Size – 100% customApplication – custom; Size – 100% custom• Process – Process – ad hocad hoc …(discuss) – laissez faire; …(discuss) – laissez faire; • 70s - SDLC; customization of process to domain / 70s - SDLC; customization of process to domain /

mission, structured analysis, structured design, code.mission, structured analysis, structured design, code. Transition (80s and 90s)Transition (80s and 90s)

• Environmental/tools – some off the shelf.Environmental/tools – some off the shelf. Tools: separate, that is, often not integrated esp. in 70s…Tools: separate, that is, often not integrated esp. in 70s…

• Size: 30% component-based; 70% customSize: 30% component-based; 70% custom Process: Process: repeatablerepeatable

Modern Practices (2000 and later)Modern Practices (2000 and later)• Environment/tools: off-the-shelf; integratedEnvironment/tools: off-the-shelf; integrated• Size: 70% component-based; 30% customSize: 70% component-based; 30% custom• Process: Process: managedmanaged; ; measuredmeasured (refer to CMM) (refer to CMM)

2323 88

Notice Notice PerformancePerformance Trends….for three Trends….for three generations of software economicsgenerations of software economics

Conventional: Predictably bad: (60s/70s) Conventional: Predictably bad: (60s/70s) • usually always over budget and schedule; missed usually always over budget and schedule; missed

requirementsrequirements• All custom components; symbolic languages (assembler); All custom components; symbolic languages (assembler);

some third generation languages (COBOL, Fortran, PL/1)some third generation languages (COBOL, Fortran, PL/1)• Performance, quality almost always Performance, quality almost always less than greatless than great..

Transition: Unpredictable (80s/90s)Transition: Unpredictable (80s/90s) Infrequently on budget or on scheduleInfrequently on budget or on schedule Enter software engineering; ‘repeatable process;’ Enter software engineering; ‘repeatable process;’

project managementproject management Some commercial products available – databases, Some commercial products available – databases,

networking, GUIs; But with huge growth in complexity, networking, GUIs; But with huge growth in complexity, (especially to distributed systems) existing languages and (especially to distributed systems) existing languages and technologies not enough for desired business performancetechnologies not enough for desired business performance

Modern Practices: Predictable (>2000s)Modern Practices: Predictable (>2000s) Usually on budget; on schedule. Managed, measured Usually on budget; on schedule. Managed, measured

process managementprocess management. Integrated environments; 70% off-. Integrated environments; 70% off-the-shelf components. Component-based applications RAD; the-shelf components. Component-based applications RAD; iterative development; stakeholder emphasis. iterative development; stakeholder emphasis.

2323 99

All Advances Interrelated…All Advances Interrelated…

Improved ‘process’ requires ‘improved Improved ‘process’ requires ‘improved tools’ (environmental support…)tools’ (environmental support…)

Better ‘economies of scale’ becauseBetter ‘economies of scale’ because Applications live for years; Applications live for years; • Similarly-developed applications – common.Similarly-developed applications – common.• First efforts in common First efforts in common architectures, architectures,

processesprocesses, , iterative processesiterative processes, etc., all have , etc., all have initialinitial high overhead;high overhead;

• But follow-on efforts result in economies of But follow-on efforts result in economies of scale…and much better ROI. (See p. 25)scale…and much better ROI. (See p. 25)

• ““All simple systems have been developed!”All simple systems have been developed!”

2323 1010

2.2 “Pragmatic” Software Cost Estimation2.2 “Pragmatic” Software Cost Estimation Little available on estimating cost for projects using Little available on estimating cost for projects using

iterative development.iterative development.• Difficult to hold all the controls constantDifficult to hold all the controls constant

Application domain; project size; criticality; etc. Very Application domain; project size; criticality; etc. Very ‘artsy.’ ‘artsy.’

Metrics (SLOC, function points, etc.) Metrics (SLOC, function points, etc.) NOT consistently NOT consistently appliedapplied EVEN in the same application domain! EVEN in the same application domain!

Definitions of SLOC and function points are not even Definitions of SLOC and function points are not even consistentconsistent!!

• Much of this is due to the nature of development. Much of this is due to the nature of development. There is no There is no magic datemagic date when design is ‘done;’ or when design is ‘done;’ or magic date when testing ‘begins’ …magic date when testing ‘begins’ …

• Consider some of the issues:Consider some of the issues:

2323 1111

Three Issues in Software Cost Estimation:Three Issues in Software Cost Estimation: 1. 1. Which cost estimation Which cost estimation modelmodel should should be used?be used? 2. Should 2. Should software sizesoftware size be measured be measured using SLOC or Function Points?using SLOC or Function Points? (there are others too…)(there are others too…) 3. What are the determinants of a 3. What are the determinants of a goodgood estimateestimate? (How do we know our? (How do we know our estimate is good??) estimate is good??)

So very much is dependent upon So very much is dependent upon estimates!!!!estimates!!!!

2323 1212

Cost Estimation ModelsCost Estimation Models Many available.Many available. Many Many organization-specificorganization-specific models too based models too based

on their own histories, experiences…on their own histories, experiences…• Oftentimes, these are super if ‘other’ parameters Oftentimes, these are super if ‘other’ parameters

held constant, such as process, tools, etc. etc.held constant, such as process, tools, etc. etc. COCOMO, developed by Barry Boehm, is the COCOMO, developed by Barry Boehm, is the

most popular cost estimation model.most popular cost estimation model. Two Two primaryprimary approaches: approaches:

• Source lines of code (SLOC) andSource lines of code (SLOC) and• Function Points (FP)Function Points (FP)

Let’s look at this – overview.Let’s look at this – overview.

2323 1313

Source Lines of Code (SLOC)Source Lines of Code (SLOC) Many feel comfortable with ‘notion’ of LOCMany feel comfortable with ‘notion’ of LOC SLOC has great value – especially where SLOC has great value – especially where

applications are applications are custom-builtcustom-built.. • Easy to measure & instrument – have tools.Easy to measure & instrument – have tools.• Nice when we have a historyNice when we have a history of development with of development with

applications and their existing lines of code and applications and their existing lines of code and associated costs.associated costs.

Today – with use of components, source-code Today – with use of components, source-code generation tools, and objects have rendered generation tools, and objects have rendered SLOC somewhat ambiguous.SLOC somewhat ambiguous. • We often We often don’t knowdon’t know the SLOC – but do we care? the SLOC – but do we care?

How do we factor this in? How do we factor this in?

2323 1414

Source Lines of Code (SLOC)Source Lines of Code (SLOC) Generally more useful and precise basis than FPs Generally more useful and precise basis than FPs Appendix D – an extensive case study.Appendix D – an extensive case study.

• Addresses how to count SLOC where we have Addresses how to count SLOC where we have reuse, different languages, etc. reuse, different languages, etc.

• Read this appendix (five pages)Read this appendix (five pages)

We will address LOC in much more detail later. We will address LOC in much more detail later.

Appendix provides Appendix provides hint at the complexity of using of using LOC for software sizing particularly with the new LOC for software sizing particularly with the new technologies using technologies using automatic code generationautomatic code generation, , componentscomponents, , development of new codedevelopment of new code, and more., and more.

2323 1515

Function PointsFunction Points Use of Function Points - many proponents. Use of Function Points - many proponents.

• International Function Point User’s Group – 1984 – International Function Point User’s Group – 1984 – “is the dominant software measurement “is the dominant software measurement association in the industry.”association in the industry.”

• Check out their web site (Check out their web site (www.IFPUG.comwww.IFPUG.com ??) ??)• Tremendous amounts of information / referencesTremendous amounts of information / references• Attempts to create industry standards….Attempts to create industry standards….

Major advantage: Measuring with function Major advantage: Measuring with function points is points is independent of the technologyindependent of the technology (programming language, tools …) used and is thus (programming language, tools …) used and is thus better for comparisons among projects. better for comparisons among projects.

2323 1616

Function PointsFunction Points Function Points measure numbers of Function Points measure numbers of

• external user inputs, external user inputs, • external outputs, external outputs, • internal data groups, internal data groups, • external data interfaces, external data interfaces, • external inquiries, etc. external inquiries, etc.

Major disadvantage: Difficult to measure Major disadvantage: Difficult to measure these things.these things.• Definitions are primitive and inconsistentDefinitions are primitive and inconsistent• Metrics difficult to assess especially since normally Metrics difficult to assess especially since normally

done done earlierearlier in the development effort using more in the development effort using more abstractions.abstractions.

Yet, no project will be started without Yet, no project will be started without estimates!!!!estimates!!!!

2323 1717

But:But: Cost estimation is a real necessity!!! Cost estimation is a real necessity!!!

Necessary to ‘fund’ project!Necessary to ‘fund’ project! All projects require estimation in the beginning All projects require estimation in the beginning

(inception) and adjustments…(inception) and adjustments…• These must stabilize; They are rechecked…These must stabilize; They are rechecked…• Must be Must be reusablereusable for additional cycles for additional cycles• Can Can create organization’s own methodscreate organization’s own methods of of

measurement on how to ‘count’ these metrics... measurement on how to ‘count’ these metrics...

No project is arbitrarily started without cost / No project is arbitrarily started without cost / schedule / budget / manpower / resource schedule / budget / manpower / resource estimatesestimates (among other things) (among other things)

SOSO critical to budgets, resource allocation, critical to budgets, resource allocation, and to a host of stakeholdersand to a host of stakeholders

2323 1818

So, How Good are the Models?So, How Good are the Models? COCOMO is said to be ‘within 20%’ of actual costs COCOMO is said to be ‘within 20%’ of actual costs

’70% of the time.’ (COCOMO has been revised over ’70% of the time.’ (COCOMO has been revised over the years…)the years…)

Cost estimating is still Cost estimating is still disconcertingdisconcerting when one when one realizes that there are realizes that there are alreadyalready a plethora of missed a plethora of missed dates, poor deliverables, and significant cost overruns dates, poor deliverables, and significant cost overruns that characterize traditional development.that characterize traditional development.

Yet, Yet, all non-trivial software developmentall non-trivial software development efforts efforts require costing; It is a basic management activity.require costing; It is a basic management activity.

RFPs on contracts RFPs on contracts force contractorsforce contractors to estimate the to estimate the project costs for their survival.project costs for their survival.

So, let’s look at top down and bottom up estimating.So, let’s look at top down and bottom up estimating.

2323 1919

Top Down versus Bottom UpTop Down versus Bottom UpSubstantiating the Cost…Substantiating the Cost…

Most estimators perform bottom up costing - Most estimators perform bottom up costing - substantiatingsubstantiating a target cost - a target cost - rather thanrather than approaching it a top down, which would yield approaching it a top down, which would yield a ‘should cost.’ a ‘should cost.’

Many project managers create a ‘target cost’ Many project managers create a ‘target cost’ and then play with parameters and sizing and then play with parameters and sizing until the target cost can be justified…until the target cost can be justified…• Work backwards!Work backwards!• Attempts to win proposals, convince people, …Attempts to win proposals, convince people, …

Any approachAny approach should force the project should force the project manager to assess risk and discuss things manager to assess risk and discuss things with stakeholders…with stakeholders…

2323 2020

Top Down versus Bottom UpTop Down versus Bottom Up

Bottom up … substantiating? Good?Bottom up … substantiating? Good?• If well doneIf well done, it requires considerable , it requires considerable

analysis and expertise analysis and expertise based on much based on much experience and knowledgeexperience and knowledge; ; Development Development of similar systems a great of similar systems a great

help; similar technologies… help; similar technologies… • If not well doneIf not well done, causes team members to , causes team members to

go go crazycrazy! (This is not uncommon)! (This is not uncommon) Independent cost estimators Independent cost estimators

(consultants…) not reliable.(consultants…) not reliable.

2323 2121

Author suggests:Author suggests: Likely best cost estimate is undertaken by an Likely best cost estimate is undertaken by an

experienced project managerexperienced project manager, software , software architect, developers, and test managers – and architect, developers, and test managers – and this process can be quite iterative!this process can be quite iterative!

Previous experience is essentialPrevious experience is essential. Risks . Risks identifiable, assessed, and factored in.identifiable, assessed, and factored in.

When created, the When created, the team must live withteam must live with the the cost/schedule cost/schedule estimateestimate. .

More later in course. But for nowMore later in course. But for now (Heuristics (Heuristics from our text:) from our text:)

2323 2222

A Good Project Estimate: A Good Project Estimate: Is Is conceived and supportedconceived and supported by the project manager, by the project manager,

architecture team, development team, and test team architecture team, development team, and test team accountable for performing the work.accountable for performing the work.

Is Is acceptedaccepted by all stakeholders as ambitious but by all stakeholders as ambitious but doable doable

Is Is basedbased on a well-defined software cost modelon a well-defined software cost model with a with a credible basiscredible basis

Is Is based on a database of relevant project based on a database of relevant project experienceexperience that includes similar processes, similar that includes similar processes, similar technologies, similar environments, similar quality technologies, similar environments, similar quality requirements, and similar people, andrequirements, and similar people, and

Is Is defined in enough detaildefined in enough detail so that its key risk areas so that its key risk areas are understood and the probability of success is are understood and the probability of success is objectively assessed.objectively assessed.

2323 2323

A Good Project EstimateA Good Project Estimate QuotingQuoting: “An ‘ideal estimate’ would be : “An ‘ideal estimate’ would be

derived from a mature cost model with an derived from a mature cost model with an experience base that reflects multiple experience base that reflects multiple similar projects done by the same team similar projects done by the same team with the same mature processes and tools.with the same mature processes and tools.

““Although this situation rarely exists when a Although this situation rarely exists when a project team embarks on a new project, project team embarks on a new project, good estimates can be achieved in a good estimates can be achieved in a straightforward manner in later life-cycle straightforward manner in later life-cycle phases of a mature project using a mature phases of a mature project using a mature process.”process.”