Estimation Questions How do you estimate? What are you going to estimate? Where do you start?

Slides:



Advertisements
Similar presentations
FPA – IFPUG CPM 4.1 Rules.
Advertisements

INFO 420Chapter 6 1 SW Project Management WBS and Project Estimation INFO 420 Glenn Booker.
Software project management (intro)
1 PROJECT SIZING AND ESTIMATING - EFFECTIVELY USING FUNCTIONAL MEASUREMENT Southern California Software Process Improvement.
CS 551 Estimation Fall December QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing,
SOFTWARE PROJECT MANAGEMENT AND COST ESTIMATION © University of LiverpoolCOMP 319slide 1.
Information Technology Project Management
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
Cost Management Week 6-7 Learning Objectives
1 U08784 Software Project Management lecturer: Timothy Au url:
Copyright © The David Consulting Group, Inc. 1 UNDERSTANDING and EFFECTIVELY USING FUNCTIONAL MEASUREMENT Presented By The David Consulting Group.
Project Cost Estimation
Information Technology Project Management – Third Edition
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Information Technology Project Management
Estimation Why estimate? What to estimate? When to estimate?
Chapter 6 : Software Metrics
Chapter 6 The Work Breakdown Structure and Project Estimation Copyright 2012 John Wiley & Sons, Inc. 6-1.
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
Work Breakdown Structure (WBS) The WBS represents a logical decomposition of the work to be performed and focuses on how the product, service, or result.
1 Estimation Function Point Analysis December 5, 2006.
Lecture 4 Software Metrics
Cost Estimation. Problem Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts.
Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract.
Software complexity estimation by Adam Bondarowicz by Adam Bondarowicz.
Estimating Software Projects & Activity Scheduling in the Dynamic, Multi-Project Setting: Choosing Heuristics Through Deterministic Simulation.
Function Point Analysis. Function Points Analysis (FPA) What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
©1999 Addison Wesley LongmanSlide 3.1 Managing IS Projects Planning –Decomposing Project into Activities –Estimating resources –Developing a schedule –Setting.
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
CSC 480 Software Engineering Lecture 6 September 11, 2002.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
FUNCTION POINT ANALYSIS & ESTIMATION
Information Technology Project Management – Fourth Edition
Cost23 1 Question of the Day u Which of the following things measure the “size” of the project in terms of the functionality that has to be provided in.
THE FAMU-CIS ALUMNI SYSTEM
Chapter 33 Estimation for Software Projects
Project Cost Management
Alternative Software Size Measures for Cost Estimation
The Work Breakdown Structure and Project Estimation
Work Breakdown Structure (WBS)
Testing Techniques.
RET Rules One of the following rules applies when counting RETs:
For University Use Only
Work Breakdown Structure (WBS)
Information Technology Project Management – Fifth Edition
Software Engineering (CSI 321)
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Function Point Analysis
The Work Breakdown Structure and Project Estimation
Software Planning
Software Development & Project Management
Personal Software Process Software Estimation
Function Point.
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
Activities During SPP Size Estimation
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
Information Technology Project Management – Fourth Edition
COCOMO Models.
Cost Estimation Van Vliet, chapter 7 Glenn D. Blank.
Chapter 33 Estimation for Software Projects
Software Engineering: A Practitioner’s Approach, 6/e Chapter 23 Estimation for Software Projects copyright © 1996, 2001, 2005 R.S. Pressman & Associates,
Software Effort Estimation
Software Project Management
Chapter 26 Estimation for Software Projects.
COCOMO MODEL.
Presentation transcript:

Estimation Questions How do you estimate? What are you going to estimate? Where do you start?

Estimation Techniques - Traditional Project Management Approaches  Guesstimating  Delphi Technique  Time Boxing  Top-Down  Bottom-Up  Analogous Estimates (Past experiences)  Parametric Modeling (Statistical)

Guestimating Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget. Unfortunately, many inexperienced project managers tend to guesstimate, or guess at the estimates, because it is quick and easy.

Delphi Technique  Involves multiple, anonymous experts  Each expert makes an estimate  Estimates compared  If close, can be averaged  If not, do another iteration until consensus is reached

Time Boxing  A “box” of time is allocated for a specific activity, task, or deliverable  Can focus a team if used effectively  Can demoralize a team if not used effectively

Top-Down  Top & middle managers determine overall project schedule &/or cost  Lower level managers are expected to breakdown schedule/budget estimates into specific activities (WBS)

Bottom-Up  Schedules & budgets are constructed from WBS  Starts with people who will be doing the work  Schedules & budgets are the aggregate of detailed activities & costs

Analogous Estimates  Similar to Top-Down approach  Use information from previous, similar projects as a basis for estimation

Parametric Modeling  Use project characteristics (parameters) in a mathematical model to estimate  Example: $50/ LOC based on:  Programming language  Level of expertise  Size & complexity

6.2 Test Results Report Review test plan with client1 day Carry out test plan5 days Analyze results2 days Prepare test results report and presentation3 days Present test results to client1 day Address any software issues or problems5 days Estimates are made for each activity in the WBS How did we come up with these estimates? Using a technique, or combination of techniques, with the exception of guestimating!

Estimating Techniques - Software Engineering Approaches  Lines of Code (LOC)  Function Points  COCOMO  Heuristics Software engineering techniques focus on estimating the size of the system to be developed

Determinants of Estimating the Largest Deliverable of the Project – The Application System

Function Point Analysis  Allan Albrecht, IBM – 1979  Synthetic metric  Independent of the Technology  IFPUG standards (  5 Primary Elements  Inputs  Outputs  Inquiries  Logical Files  Interfaces

The Application Boundary for Function Point Analysis

Complexity LowAverageHighTotal Internal Logical Files (ILF) _3 x 7 = 21_2 x 10 = 20_1 x 15 = 1556 External Interface Files (EIF) __ x 5 = ___2 x 7 = 14__ x 10 = __14 External Input (EI) _3 x 3 = 9_5 x 4 = 20_4 x 6 = 2453 External Output (EO) _4 x 4 = 16_2 x 5 = 10_1 x 7 = 733 External Inquiry (EQ) _2 x 3 = 6_5 x 4 = 20_3 x 6 = 1844 Total Unadjusted Function Points (UAF) 200

General System CharacteristicDegree of Influence Data Communications3 Distributed Data Processing2 Performance4 Heavily Used Configuration3 Transaction Rate3 On-line Data Entry4 End User Efficiency4 Online Update3 Complex Processing3 Reusability2 Installation Ease3 Operational Ease3 Multiple Sites1 Facilitate Change2 Total Degrees of Influence 40 Value Adjustment Factor VAF = (TDI * 0.01) +.65 VAF = (40 *.01) +.65 = 1.05 Total Adjusted Function Points = FP = UAF * VAFFP = 200 * 1.05 = 210

LanguageAverage Source LOC per Function Pont Average Source LOC for a 210 FP Application Access387,980 Basic10722,470 C12826,880 C++5311,130 COBOL10722,470 Delphi296,090 Java5311,130 Machine Language640134,440 Visual Basic 5296,090 Source:

COCOMO  COnstructive COst MOdel  Developed by Barry Boehm,  Has been extended to COCOMO II  _main.html _main.html

COCOMO Models (Effort)  Organic – Routine  Person Months = 2.4 * KDSI 1.05  Embedded – Challenging  Person Months = 3.6 * KDSI 1.20  Semi-Detached – Middle  Person Months = 3.0 * KDSI 1.12

COCOMO – Effort Example  Semi-Detached 10,600 Java LOC = 200 FP * 53 Person Months = 3.0 * KDSI 1.12 = 3.0 * (10.6) 1.12 = 42.21

COCOMO Models (Duration)  Organic  Duration = 2.5 * Effort 0.38  Semi-Detached  Duration = 2.5 * Effort 0.35  Embedded  Duration = 2.5 * Effort 0.32

COCOMO Duration Example Duration = 2.5 * Effort 0.35 = 2.5 *(42.21) 0.35 = 9.26 months People Required = Effort / Duration = / 9.26 = 4.55

Heuristics (Rules of Thumb) When scheduling a software task: 1/3 – Planning 1/6 – Coding 1/4 – Component test and early system test 1/4 – System test, all components in hand

The Man Month Months People Months People Time versus number of workers perfectly partitionable task – i.e., No communication among them e.g., reaping wheat. When a task that cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.

Adding People  Increases the total effort necessary  The work & disruption of repartitioning  Training new people  Added intercommunication

What can cause inaccurate estimates?  Scope changes  Overlooked tasks  Poor developer-user communication  Poor understanding of project goals  Insufficient analysis  No (or poor) methodology  Changes in team  Red tape  Lack of project control  Not identifying or understanding impact of risks

Other Factors to Consider When Estimating  Rate at which requirements may change  Experience & capabilities of project team  Process or methods used in development  Specific activities to be performed  Programming languages or development tools to be used  Probable number of bugs or defects & removal methods  Environment or ergonomics of work space  Geographic separation of team across locations  Schedule pressure placed on the team

How can estimates be improved?  Experience!  Lessons learned  Best Practices  Revision  Monitor  Focus on deliverables  Control