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 – customApplication – custom• Size – 100% customSize – 100% custom• Process – Process – ad hocad hoc …(discuss) – laissez faire; SDLC; …(discuss) – laissez faire; SDLC;

customization of process to domain / missioncustomization of process to domain / mission Transition (80s and 90s)Transition (80s and 90s)

• Environmental/tools – off the shelf, separateEnvironmental/tools – off the shelf, separate• 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 –

Software)Software)

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) • always over budget and schedule; missed always over budget and schedule; missed

requirementsrequirements• All custom components; primitive languages;All custom components; primitive languages;• Performance, quality almost always less than great.Performance, quality almost always less 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% . Integrated environments; 70% off-the-shelf components. Component-based applications off-the-shelf components. Component-based applications can be built very rapidly; iterative development; can be built very rapidly; iterative development; stakeholder emphasis. RAD!stakeholder emphasis. RAD!

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 initial initial high overhead;high overhead; successive efforts successive efforts bring out economies of scale…and much bring out economies of scale…and much better return on investment. (See p. 25)better return on investment. (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 Little available on estimating cost for

projects using iterative development.projects using 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.) NOT consistently Metrics (SLOC, function points, etc.) NOT consistently applied EVEN in the same application domain!applied 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’ …

2323 1111

Three Issues in Software Cost Estimation:Three Issues in Software Cost Estimation: 1. Which cost estimation model should 1. Which cost estimation model should be used?be used? 2. Should software size be measured2. Should software size 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 good3. What are the determinants of a good estimate? (How do we know ourestimate? (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 models too

based on their own histories, experiences...based on their own histories, experiences...• Oftentimes, these are super if ‘other’ Oftentimes, these are super if ‘other’

parameters held constant, such as process, parameters held constant, such as process, tools, etc. etc.tools, etc. etc.

COCOMO, developed by Barry Boehm, is COCOMO, developed by Barry Boehm, is the most popular cost estimation model.the 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)

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 history of development with Nice when we have a history 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) In general, using SLOC is a more useful and precise In general, using SLOC is a more useful and precise

basis of measurement.basis of measurement. See Appendix D – an extensive case study.See 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.

We will address LOC in much more detail later. In We will address LOC in much more detail later. In the meantime, I urge you to read the five pages in the meantime, I urge you to read the five pages in Appendix D entitled, Software Size Evolution from Appendix D entitled, Software Size Evolution from the Case Study. Starts on page 348.the Case Study. Starts on page 348.

This exposition provides a hint at the complexity of This exposition provides a hint at the complexity of using LOC for software sizing particularly with the using LOC for software sizing particularly with the new technologies using automatic code generation, new technologies using automatic code generation, components, development of new code, and more.components, development of new code, and more.

Read these five pages.Read these five pages.

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 siteCheck out their web site• Tremendous amounts of information / referencesTremendous amounts of information / references• Attempts to create standards….Attempts to create standards….

Major advantage: Measuring with function Major advantage: Measuring with function points is points is independent of the technologyindependent of the technology (programming language, …) used and is thus (programming language, …) 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 Metrics difficult to assess especially since

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

2323 1717

But:But: Regardless, cost estimation is a real Regardless, cost estimation is a real

necessity!!! Necessary to ‘fund’ project!necessity!!! 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 reusable for additional cyclesMust be reusable for additional cycles• Can create organization’s own methods of Can create organization’s own methods 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 disconcerting when one Cost estimating is still disconcerting 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 dates, poor deliverables, and significant cost overruns that characterize traditional development.overruns that characterize traditional development.

Yet, all non-trivial software development efforts Yet, all non-trivial software development 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.

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 rather thanthan approaching it a top down, which approaching it a top down, which would yield a ‘should cost.’ would yield a ‘should cost.’

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

Any approach should force the project Any approach 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

This can be good and badThis can be good and bad• If well doneIf well done, it requires considerable , it requires considerable

analysis and expertise based on much analysis and expertise based on much experience and knowledge; development experience and knowledge; development of similar systems a great help; similar of similar systems a great help; similar technologies – great help…technologies – great help…

• If not well doneIf not well done, causes team members to , causes team members to go crazy! (This is not uncommon)go crazy! (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

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 doable by all stakeholders as ambitious but 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 experiencebased on a database of relevant project experience

that includes similar processes, similar technologies, that includes similar processes, similar technologies, similar environments, similar quality requirements, and similar environments, similar quality requirements, and similar people, andsimilar people, and

Is Is defined in enough detaildefined in enough detail so that its key risk areas are so that its key risk areas are understood and the probability of success is objectively understood and the probability of success is objectively assessed.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.”