Introduction to Software Estimating

© Galorath Incorporated 2004 1

Introduction to Software EstimatingIntroduction to Software Estimating

A Galorath Web Seminar3 March 2004

2© Galorath Incorporated 2004

Presentation OutlinePresentation Outline

Background• Definitions• Estimate contents

Best practices (process/project management)• Preparation• Analysis• Deliverables

Summary & Review• Checklist• Pep talk



Background• Definitions• Estimate contents

Best practices (process/project management)Best practices (process/project management)•• PreparationPreparation•• AnalysisAnalysis•• DeliverablesDeliverables

Summary & ReviewSummary & Review•• ChecklistChecklist•• Pep talkPep talk


Rule Number OneRule Number One

Don’t be intimidated!• Most people give up before they start

– Software is a “black art”– “I don’t understand it”– “I can’t estimate it”

If you’d rather be intimidated, call Galorath Professional Services to support your software estimating needs• [email protected] 310-414-3222 x644


What is What is ““Software?Software?””

“Software” includes all resources (money, people, time) required to:• Define requirements• Design architecture• Plan & manage the project• Produce new code• Rework pre-existing code• Integrate (to other software and to hardware)• Incorporate COTS packages• Test & repair• Document• Maintain (bug fixes, enhancements, etc.)

… in order to produce a deliverable program that provides some level of functionality to a customer or end user.


Software Cost Management IssuesSoftware Cost Management Issues

While software may be a relatively small portion of system cost, it is often the largest portion of system risk• People disregard software productivity laws• Because it is “soft” ware people think it is easy to change

Past ad hoc management techniques are problematic at best• Depended on heroes and luck rather than repeatable processes

Many software developers are “artists” rather than engineersHuman beings usually are optimists and often underestimate effort & schedule to complete tasksSoftware cost models can provide viable cost, schedule, risk, reliability estimates


On time & budgetOverranCancelled

For a variety of projects* ranging from $500K to $2.3M:• 28% completed on time & within budget• 49% experienced serious overruns:

– +45% on cost– +63% on schedule– Only 67% of initial requirements implemented

• 23% canceled before completionTrack record for very large & embedded software is even worse

Source: Standish Group International, Inc. “CHAOS Report,” 2000* Sample size = 30,000

Software = CHAOSSoftware = CHAOS


Why Projects Get Into TroubleWhy Projects Get Into Trouble

People• Skill mix• Management styles• Incentives & rewards

Process• Lack of definition• Volatility

Product• Requirements volatility / scope creep• Trying to do the impossible

Other• Unidentified risks• What reasons can you think of?


An Estimate DefinedAn Estimate Defined

An estimate is the most knowledgeable statement you can make at a particular point in time regarding:• Effort• Cost• Schedule• Staffing• Risk• Reliability

Estimates get more precise as the project progresses -more detailed information becomes available• See chart next page courtesy of NAVAIR


Lifecycle Estimating AccuracyLifecycle Estimating Accuracy


Two Approaches to EstimatingTwo Approaches to Estimating

“Bottom-up” or “grass roots” approach:• Measure everything directly and exactly• Each project/task is unique• Predictive value?• Analysis of alternatives?

Parametric approach:• Employs cost estimating relationships or equations• Allows estimation based on measurement of key parameters

that drive time and effort– Technical or physical characteristics of the product, personnel,

and development environment• Once relationships are known, parameter values can be

changed and the effects evaluated


WhatWhat’’s Included in the Estimate?s Included in the Estimate?

Development effort breaks down into…

What will be done?• Sequential activity phases

Who will do the work?• Personnel labor categories


Software Development Activities (1)Software Development Activities (1)

System Concept• Development of conceptual design

System Requirements Design• Create initial system requirements• Decide which functions are allocated to software

Software Requirements Analysis• Detailed software requirements analysis and synthesis

Preliminary Design• Subdivide software into packages or functions • Define data flows between different program components• Map design to software requirements

Detailed Design• Further define software is down to single decision points


Software Development Activities (2)Software Development Activities (2)

Coding and Unit Test• Software programming• Unit level testing performed by programmers

Component Integration and Test • Integrate software units into cohesive software components• Component-level testing• Integrate components into a cohesive program

Program Test • Formal testing to determine compliance with requirements

System Integration and Test • Program-level software-to-software integration• Software-to-hardware integration

Software maintenance• Bug fixes, adaptations, fine-tuning, enhancements


Software Labor Categories (1)Software Labor Categories (1)

Management• Direct, indirect, technical, non-technical

Software Systems Engineers• Developing requirements and specifications

Designers• Defining software architecture to implement software

requirements, preparing architectural design specifications, specifying the layout of physical data structures and interfaces

Coders / Programmers• Coding, unit testing, maintaining appropriate unit

documentation


Software Labor Categories (2)Software Labor Categories (2)

Data Preparation (Documentation)• Preparing specifications, standards, engineering draft manuals

(engineering effort only), and other engineering documentation

Test• Preparing test plans and procedures, running tests, and preparing

test reports

Configuration Management• Configuration identification, change control, configuration status

accounting, and configuration auditing

Quality Assurance• Quality engineering functions, quality inspections and audits



BackgroundBackground•• DefinitionsDefinitions•• Estimate contentsEstimate contents

Best practices (process/project management)• Preparation• Analysis• Deliverables

Summary & ReviewSummary & Review•• ChecklistChecklist•• Pep talkPep talk


Preliminary StepsPreliminary Steps

Determine points of contact & prepare a list• Your customer (the software developer or acquirer)• Your customer’s customer(s) (vice versa)

Scope the project• Estimate or calibration task?• Acquisition only or full life-cycle (includes maintenance)?• Single delivery or multiple incremental builds/releases?

Scope your effort• Labor hours & categories • Line up staff to support you

Manage customer expectations & relations• Deliver project plan that outlines your activity & schedule


The Task/Project Plan (1)The Task/Project Plan (1)

Usually only a required deliverable for long term projects• Estimates that take three months or longer• All calibration tasks

Good to have one for internal purposes even if not a requireddeliverable• Scope/plan effort/activities, deliverables• Lay out schedule• Organize personnel resources• Track actual vs. plan, help prepare monthly reports• Essential for green analysts & new project managers


The Task/Project Plan (2)The Task/Project Plan (2)

Use to manage customer expectations & relationsTranslate SOW into specific requirements, processes, andproductsContents:• What will be analyzed (scope)• How the analysis will be performed, by whom, when• What will be delivered, when• Contact list• Budget• Personnel resources (optional)

Helps project continuity in cases of employee turnover


The Importance of ScopeThe Importance of Scope

Nature of estimate• ROM or precision?• Most likely, worst case, or “should cost” scenario?• Cross-check or “target costing” exercise?• Acquisition or life-cycle?• Risk analysis included?

Nature of system• Number of subsystems: flight, ground• Number of WBS elements• Level of indenture (CSCI, CSC, CSU)• Number of releases / incremental builds

Nature of code• All new, any reuse?• Effort applied to reused code: modify, I&T, etc.• Any COTS or GOTS to be integrated?• Any code generators to be used?

Know what you need to do before you need to do it


Estimating MethodologyEstimating Methodology

Bottom-up or parametricDocument the process• What you did• How you did it• Let the reader trace your steps from inputs to outputs• Reference the project plan or copy/paste


Data CollectionData Collection

Begin with available documentation• SDP, TRD, SRS, COO, ORD, CARD, BAFO, BOE, SOW• A-level Spec, Program Schedule, Contractor Presentations

Perform interviews where & when possible• Development contractor(s)• Program office personnel, FFRDC engineers• Preparation is paramount!• Use a questionnaire, sent in advance• Phraseology determines answers• Confirm key definitions• Be willing to challenge, point out inconsistencies


The Importance of SizeThe Importance of Size

Software size is the main driver of software development effort, cost, and schedule -- use the best available estimate of size and use a range (least / likely / most)• Spend the most amount of data collection time on size• Use alternative sizing methods and/or metrics


Effort is Most Sensitive to SizeEffort is Most Sensitive to Size

Vehicle Model (C++): Programmer Capabilities

0.0

6.8

13.5

20.3

27.0

VLo Low- Low+ Nom Hi- Hi+ VHi VLo+ Low Nom- Nom+ Hi VHi-

RANGE

USER

Vehicle Model (C++): Modern Development Practices Use

0.0

6.3

12.5

18.8

25.0

VLo Low- Low+ Nom Hi- Hi+ VHi VLo+ Low Nom- Nom+ Hi VHi-

RANGE

USER

Vehicle Model (C++): Language Type (complexity)

0

5

10

15

20

Low Nom- Nom+ Hi VHi-Low+ Nom Hi- Hi+ VHi

RANGE

USER

Vehicle Model (C++): New Lines of Code

0.0

15.8

31.5

47.3

63.0

10126 16165 22204 28244 34283 40323 46362 52402 58441 64481 13145 19185 25224 31264 37303 43343 49382 55422 61461

RANGE

USER


Technical BaselineTechnical Baseline

First or second major deliverable (after project plan)Include ground rules & assumptionsInclude estimating methodologyList software by WBS element (CSCI, CSC, CSU)Describe each work element• Core functionality• Key qualitative modeling inputs• Size, if available

Identify multiple builds/releases (if any)Reference or excerpt available documentationProvide rationale & justification for BOE


Ground Rules & AssumptionsGround Rules & Assumptions

Aka, CYA managementWhat’s known, what’s unknownAnything relating to scope• What’s included, what’s excluded

Anything relating to modeling inputs• Who you interviewed and when• What you learned


Generate the EstimateGenerate the Estimate

Using your chosen methodology and tool, do a first runNever report preliminary results!Focus on the inputs • Verify completeness• Verify accuracy

Focus on the outputs• Sanity check for reasonableness, completeness

What’s driving the estimate?• SEER-SEM top ten parameters chart

Use “fresh eyes” to review• Ask a colleague for help• Set aside overnight


Update/Refine the EstimateUpdate/Refine the Estimate

Optional or more specific information may become available in the futureFollow configuration control guidelines to keep estimates straight• Change log• Naming conventions• File storage

Maintain estimating integrity – eschew artificially driving the estimate to a predetermined result


Risk AnalysisRisk Analysis

If risk analysis is required, follow methodology outlined in project planUsually, report two estimates at different confidence levels• Most likely case (appx. 50%)• Risk adjusted case (usually 70-90%)

Fulfill customer requests for project-unique risk• Risk associated with a particular contractor or development team• Volatility• Code growth• Size and condition of existing software

Identify most sensitive parametersNote risk factors that drive:• Effort• Schedule• Programmatics


Cross ChecksCross Checks

A cross check estimate prepared using a different methodology and/or tool may be required• Beware the battle of parametric models• Understand the usage of the cross check methodology and/or tool• Keep the focus on the estimate, not on the tool


Document the EstimateDocument the Estimate

Refer to data collection notesCopy/paste from tech baselineBe thorough to satisfy BOE requirements• Explain parametric modeling inputs via technical rationale, data

sources


Deliver the EstimateDeliver the Estimate

Refer back to list of deliverables in project planGenerate final report (if required)• Copy/paste from project plan & tech baseline



BackgroundBackground•• DefinitionsDefinitions•• Estimate contentsEstimate contents

Best practices (process/project management)Best practices (process/project management)•• PreparationPreparation•• AnalysisAnalysis•• DeliverablesDeliverables

Summary & Review• Checklist• Pep talk


Process ChecklistProcess Checklist

Scope project• Depth & breadth• Use project plan

Data collection• Spend most time on sizing• Document sources

Tech baseline• Document all critical inputs• GR&A, estimating process

Prepare estimate• Verify inputs• Sanity check outputs• Use “fresh eyes”• Never deliver preliminary results


Final Pep TalkFinal Pep Talk

“Now go do that voodoo

that you do so well!”

-- Hedley Lamar


Thanks For Your InterestThanks For Your Interest

If Pepsi is “The Joy of Cola”…Galorath must be “The Joy of Parametrics”

Contact Information:• www.galorath.com• [email protected] 310-414-3222 x635• [email protected] 310-414-3222 x642

©Copyright 2004, Galorath Incorporated. ALL RIGHTS RESERVEDReproduction, copy, or excerpt in whole or in part

is strictly prohibited without written permission

SEER is a trademark of Galorath Incorporated100 N. Sepulveda Bl., Suite 1801, El Segundo, CA 90245

Introduction to Software Estimating

Documents

Transcript of Introduction to Software Estimating