Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M11 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 11 Overview of Size Estimating

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Objectives of This Module  To examine why size estimating is useful  To discuss how to measure size  To review several categories of estimating methods

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version When do you Do Estimating  Before writing proposals –To get rough estimates in support of marketing efforts  When writing proposals –To develop a bid  When starting a project –Once you know the final terms of the contract and the budgets  During a project –When things have changed enough to justify updating the estimate Rough Estimates Good Estimates Better Estimates Even Better Estimates

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Detailed Planning - Processes Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost ScheduleOK Complete Detailed Planning Revise & Negotiate Not OK Estimate Size Estimate Effort and Cost

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Why Do You Need to Estimate the Size?  To help you estimate the effort, schedule and cost  And to help you estimate the memory requirements, if you need to know them  In theory, you could estimate effort and cost without knowing size –Since you know the tasks to be performed from the WBS, you can (in theory) compute effort and cost directly

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version How To Estimate Cost and Effort Without Estimating Size For each task, you determine effort and then cost, as follows: Task > Effort > Cost This is known as a “bottom up” estimating technique

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version TaskEffortx factorCost staff months$5000/sm$115, staff months$4000/sm$ 20, (3 trips)$1000/trip$ 3, _______________________ Total$435,000 “Bottom Up” Cost Estimating The highlighted tasks are to develop the software. Other tasks are for related activities required by SOW, etc.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version But Sometimes This is Not So Easy  In practice, the software development tasks may be hard to estimate in this fashion  It is very hard to estimate the effort to perform a software development task unless you know something about the size and the complexity of the software

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Moreover...  Large software projects cost more than small ones; complex software costs more than simple software  So you often need to estimate the size and complexity as part of the process of determining the effort required to develop the software

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version In Fact...  It may be easier and faster to estimate the effort to do a whole software project than to estimate the exact effort of performing each task  Example: -- How long will it take you to answer the questions on the test? vs. -- How long will it take you to answer each individual question?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version “Short Cut” to Estimate Software Development Effort For Software Development Tasks: use software items rather than tasks: Software ----> Size > Effort > Cost Item & Complexity For Other Tasks: Task > Effort > Cost

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Estimating Software Development Effort SW ItemSizeComplexity File System2400 unitssimple User I/F3000 unitsmoderate _____ __________ _______ Total35,000 unitsmoderate Historical Data Effort Estimate

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Inputs to Size Estimate  What you must do (job analysis)  How you will do it (Initial Planning)  Past experience and data

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Good job analysis and initial planning will have identified all of these things and summarized them in the work breakdown structure (WBS) “What You Must Do” Inputs  Statement of work  System design information  Requirements of the software  Tasks to be Performed

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version “How You Will Do It” Inputs  How you will break it into software items  Programming language(s) to be used  Initial concepts of software design  Process and methods to be used for development  Reusable software information These are also identified during job analysis and initial planning

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version “Past Experience” Inputs  Prior experience on similar tasks is valuable in helping you estimate –People who have worked on something similar can be a good source - but they may be biased - or may be unavailable –Historical data can provide useful facts to counteract natural human biases  An organizational data base of past project experience is one of the best investments an organization can make

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Past History May Be Particularly Hard to Find Cindy Wilson did that the last time & she left the company last year. We never have time around here to write down what we learned.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version You May Have to Scramble to Get What Information You Can Hello, Cindy? Can you tell me about how big the user interface module was in project Zing? Hey, George! Who around here knows the most about the HP X123 test station? Anne, can you participate in an estimating session next week? Let’s look at the source code of the old data base module.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Size Estimating Concept Size Estimate WBS Source Documents (SOW, Requirements, Contract, Test Criteria, etc,) Estimate Size Past Experience & Data

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Size Estimate Step 1 - Determine the Gross Size Estimate Size for Each Distinct SW Item  Gross Size Estimate for All Software Items WBS etc.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Gross Size Estimate for All Software Items Equivalent Size Estimate for All Software Items Size Estimate Step 2 - Evaluate the Impact of Reuse Analyze Impact of Reuse

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Risks of Size Estimating 1) Statistical variance & fundamental inaccuracy of estimating methods –Multiple methods are recommended to increase confidence 2) Biases due to lack of knowledge, optimism, etc. –The earlier in the lifecycle, the less accurate the estimates –Therefore, plan to update estimates when you have more facts

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version  Accurate estimates are seldom attained, especially early in the lifecycle –Early estimates tend to be underestimates  The goal of estimating is –to help plan the project –to educate estimators –to manage risk Warning -- Estimate = Goal You don’t need a perfect prediction to manage a project effectively

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Units of Size

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version How Would You Measure the Size of a House?  Square Feet  Number of bedrooms, bathrooms, garages, etc  Number of floors  Size of lot required to build it ... What are the advantages and drawbacks of each measure?

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Important Questions  What unit will you use to measure size? –It should be related to effort  How will you define it? –Everyone should be measuring the same thing  How will you measure it? –Can you measure it accurately? –Can you measure it easily? These questions are important whether you are measuring the size of houses or software

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version The decision about which unit is best should be based on the suitability of a unit to your application domain Some Possible Units of Size for Software  Lines of Code –Which ones count? –Do comments count?  Functions performed  Objects in the design  Required bytes of computer memory  Number of requirements  Web pages

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version How to Decide Between Options?  Are data available to help you estimate? –previous, similar projects are best  Is your unit of measure suited to the application & your organization’s processes?  How easy is it to measure? Consistency between projects is more important than the measure itself.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Keep the Goal in Mind  The primary goal of a software size measure is to help you estimate effort  A secondary goal is to help you estimate how much memory you need to hold the software  The goal is not to have the most precise and perfect unit for measuring size –Don’t get hung up in debates about what unit to measure –If it works, use it

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version How to Define a Unit - Example - What Is a Line of Code?  Source line images? –80 characters/carriage return character  Source statements? –Semicolons (in some languages)  Do comments count? (usually not)  Data Declarations? (usually yes)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Notes Most methods of size estimating will work with just about any size unit you choose We will often illustrate the process with “lines of code”, and will later discuss other units

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Estimating Methods and Models Note: Except where noted, these methods can be used for estimating size OR effort.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Analogy Models –Compare with past experience History is a good ally –But truly similar models seldom exist –Use as a baseline for “sanity” checks or when no other method is available Categories of Estimating Methods Stukes, Sherry, “A Guide to Cost Estimation for Space Systems Software,” Management Consulting and Research, 1995/1999

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Expert Judgment Models –Consult with experts Examples:  Hire a consultant  Wideband Delphi –Good for new, unique & different situations –High risk of biased/insufficient knowledge –Use in conjunction with other models Categories of Estimating Methods (continued)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Prototyping –Build a model of the parts that are riskiest or least well understood Prototypes take time –But they can answer questions raised by other estimating methods Categories of Estimating Methods (continued)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Bottom-up Models –Estimate each component –And add them all up Expensive and time consuming, but –Good for tracking costs later –“Buy-in” from developers –Use if data and time are available –Won’t work if you lack key information –Ignores integration/support Categories of Estimating Methods (continued)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Categories of Estimating Methods (continued) 5. Top-Down Models –Estimate based on general characteristics of application, environment, personnel, etc. –Normally these are used for effort, not size Examples: Cocomo, Price-S, SEER, etc. –Fast, easy to use, requires little detail, captures system costs –Less accurate and stable than bottom-up –Does not foster buy-in to estimate –Use - but calibrate to your own data

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Architecture of Spreadsheet for assignments 3 and 4 Model Based Effort Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Size / Reuse EffortEffort & Cost Schedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Labor Schedule Cost Schedule Other Size Estimates... Final Size Estimate Expert Based Size Estimate

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Architecture of Spreadsheet for assignments 3 and 4 Model Based Effort Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Size / Reuse EffortEffort & Cost Schedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Labor Schedule Cost Schedule Other Size Estimates... Final Size Estimate Expert Based Size Estimate This diagram serves as a guide to the next several modules

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version Module Summary  Size estimates help you estimate effort and memory size  They can also be helpful for tracking (this will be shown in later modules)  Most estimating methods benefit from past experience or history data  Units of size should be chosen based on availability of data in those units

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version END OF MODULE 11