Guest Lecture: Project Estimating Wolfgang Behr, Accenture TU München Applied Software Engineering Prof. Bernd Brügge Software Engineering II, SS 2005 Guest Lecture: Project Estimating Wolfgang Behr, Accenture Copyright © 2005 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

Objectives for Today Build an understanding of… … the importance of estimations … different estimation approaches (initial situation, expectations, top-down versus bottom-up, …) … advantages and disadvantages of different approaches … common pitfalls

Initial Situation Copyright © 2005 Accenture All Rights Reserved.

Importance of Estimations During the planning phase of a project, a first guess about cost and time is necessary Estimations (as part of the project business case) are therefore the basis for the decision to start a project Estimations are the foundation for project planning (resources, staffing, project schedule) and for further actions (market entry, marketing, etc.) à Estimating is one of the core tasks of project management !

Challenges Incomplete knowledge about: Project scope and changes Prospective resources / staffing Technical and organizational environment / infrastructure Feasibility of functional requirements Comparability of projects in case of new or changing technologies, staff, software engineering approaches Learning curve problem (increasing productivity over time, especially when staffing new personnel) Different expectations towards project manager (buyer -> low estimation; contractor -> at least “realistic” estimation…; in general: “political” estimations; tendency to be optimistic)

Guiding Principles Documentation of assumptions about: Estimation methodology Project scope, staffing, technology etc. Definition of estimation accuracy or definition of result bandwidth Increasing accuracy with proceeding project phases (for example: detailed estimation for implementation phase after detailed functional design) Reviews by experienced colleagues

Components of a Project Estimation Cost Personnel (in person days * (PD) or valued in cost) Material (PCs, software, tools etc.) Extra costs (travel expenses, etc.) Time Project duration Dependencies Personnel (number, qualification, availability) Infrastructure (rooms, technical infrastructure etc.; especially in offshore scenarios) * person day = effort for one person per working day

Estimation Approach Determination of estimated person days Allocation to staff types (teamlead, functional expert, programmer, etc.) either: Single cost rate* for all types (no differentiation necessary) Different cost rates depending on staff type (experience, skills etc.) Personnel cost = person days x cost rate * Cost rate = cost per person per day

Determination of Person Days (Effort) Most difficult part during project planning (many other planning tasks (especially project schedule) depend on this) Basic principles:: Evaluation of known information (about project scope, resources etc.) and conversion into effort Most important: knowledge about project scope (what needs to be done), reuse of software engineering approach (steps, work products) and in general: lots of experience

Top-Down versus Bottom-Up (1) There are two possible approaches for estimations: Top-Down Approach Estimation for whole project; then breakdown to different project phases and work products (possibly by using percentages, for example: 10% for project management is a common number) Bottom-Up Approach Estimation of work products on lowest possible level; then aggregation to top-level; possibly supplemented by some general percentages (see above) à Usually, a mixed approach with recurrent estimation cycles is used !

Top-Down versus Bottom-Up (2) Top-Down Approach Normally used in the planning or project idea generation phase (little information) Based on experiences from similar projects Not appropriate for project controlling (too high-level) Risk add-ons usual Bottom-Up Approach Rules based (in order to increase comparability) Result can be used for project controlling (detailed level) Smaller risk add-ons

Work Breakdown Structure Hierarchy of all project work products and tasks which are necessary to reach the project result Structured description of all relevant project tasks (but always based on results / work products !) Decomposition of tasks used to assign responsibilities Basis for estimation, budgeting, staffing and controlling Historically oriented on end product (system and its parts), now increasingly oriented on tasks and processes

Example: WBS

Estimation Approaches There are different approaches available to do project estimations: Expert estimations (“Expertenschätzungen”) and analogies (top-down) Lines of code estimations Function point analysis (top-down) COCOMO Alternative Approach

Expert Estimations Copyright © 2005 Accenture All Rights Reserved.

Expert Estimations = Guess from experienced people No better than the participants Suitable for atypical projects Result justification difficult Important when no detailed estimation can be done (due to lacking information about scope etc.)

Function Point Analysis Copyright © 2005 Accenture All Rights Reserved.

Function Point Analysis Initially developed by Albrecht, A.J., IBM Research, 1979 Method for determining dimension and complexity of software projects, depending on the system functions (not on tasks !) Estimations are based on a user view (functionality) Independent of… Implementation language / technology Software engineering approach Top-Down approach

Function Types # of external input (Eingabefunktionen, EF) # of external output (Berechnungsfunktionen, BF) # of external inquiries (Abfragefunktionen, AF) # of logical internal files (Dateneinheiten, DE) # of external interface files (Schnittstellen zu externen Systemen, SES) Result: unadjusted function points: UFP = (a · EF) + (b · BF) + (c · AF) + (d · DE) + (e · SES) a-f = weight factors (see following slide)

Determining Unadjusted Function Points Weight Factors Function Type Number simple middle complex Input Functions x 3 4 6 = Calculation Functions x 4 5 7 = Query Functions x 3 4 6 = Datasets x 7 10 15 = Interfaces x 5 7 10 = # Unadjusted Function Points =

Adjusting Function Points Function points are then adjusted depending on system complexity, represented by 14 general complexity factors (for example transaction rate, performance, online data input, …), valid for the whole system Weighted complexity numbers between 0 (not important) to 5 (very important) Result: System Complexity Factor (SCF): SCF = 0,65 + (0,01 · Sum of weight factors) (Thus, the results can vary by 35% due to the general system complexity factors…) Then: Calculation of Function Points (FP): FP = UFP · SCF

Advantages of Function Point Analysis Independent of implementation language and technology (no LOC (lines of code) determination necessary) Estimates are based on design specification (results, which are usually known before necessary tasks are known) Users without technical knowledge can be integrated into the estimation process -> increases acceptance of estimation Incorporation of experiences from different organizations (but resulting also different factors) Adaptable to new technologies and individual situations Easy to learn and limited time effort

Disadvantages of Function Point Analysis Complexity of the function (the result) is estimated – but: complexity of its implementation would be the relevant factor for an estimation ! Complete description of functions necessary (often not the case in early project stages) -> too much focus on functionality High uncertainty in calculating function points: Components difficult to determine Weight factors deducted from past experiences (independency from technology ?) Difficulty to determine weight factors Increasing uncertainty in case of emphasis on a certain type of function types (for example output functions) Code reuse and external providers of software components are not considered Task planning and controlling not possible (also: no breakdown to single project phases considered)

Conclusion Good as a support tool for determining functionality of a system Involvement of persons without deep technical understanding increases acceptance – but: they have to be trained in using the method High uncertainties Further developments (see IFPUG, International Function Point Users Group) Feature Points (better, if emphasis on special function types; it considers also algorithm complexity)

COCOMO Copyright © 2005 Accenture All Rights Reserved.

COnstructive COst MOdel (COCOMO) Developed by Boehm, Barry W., “Software Engineering Economics”, Prentice-Hall, 1981 Top-down approach to estimate cost, effort and schedule of software projects, based on size and complexity of projects Assumptions: Derivability of effort by comparing finished projects (COCOMO database) System requirements do not change during development Exclusion of some efforts (for example admin, training, rollout, integration, etc.)

Approach Estimation of number of instructions (“Kilo Delivered Source Instructions” = KDSI) Determination of project complexity by scale factors simple project (“organic mode”) Semi-complex project (“semidetached mode”) complex project (“embedded mode”) Other cost factors are rated on a qualitative scale between “very low” and “extra high” and multiplied whith each other; by using them, more accurate estimations are possible Software reliability Data base size Programmer capability etc. einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld mittelschwer: Komplexität zwischen „einfach“ und „komplex“ kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld [PM] bedeutet „Einheit in Personenmonaten“ [KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

Calculation of Effort Basic formula: A = C * KLOCB A = Effort in man months B, C = constants Project C B Simple 2,4 1,05 Semi-Complex 3,0 1,12 Complex 3,6 1,20 einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld mittelschwer: Komplexität zwischen „einfach“ und „komplex“ kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld [PM] bedeutet „Einheit in Personenmonaten“ [KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

Calculation of Time to Develop Basic formula: T = D * AE T = Time to develop D, E = constants A = Effort in man months (see slide before) Project D E Simple 2,5 0,38 Semi-Complex 2,5 0,35 Complex 2,5 0,32 einfach: kleine Entwicklergruppen arbeiten in bekanntem Problemumfeld mittelschwer: Komplexität zwischen „einfach“ und „komplex“ kompex: komplexes, im Wesentlichen unbekanntes Problemumfeld [PM] bedeutet „Einheit in Personenmonaten“ [KDSI] bedeutet „Einheit ist Kilo Delivered Source Instructions“

Advantages of COCOMO Appropriate for a quick, high-level estimation of project costs Fair results with smaller projects which are done in a known development environment (comparison with past projects is possible) All project phases (from design to test) are covered (partially by using experiences like 10% project management, 10% infrastructure etc.)

Disadvantages of COCOMO Some very important factors are not considered in the original model: Development hardware Use of modern CASE tools Skills of team members Management quality User interface quality Comparability with past projects not always possible Lots of influencing factors which have to be determined in advance

Conclusion Use it for quick estimations after first analysis phase Results will improve if one large project is split up into smaller part projects which are estimated separately Experience shows, that estimation results can deviate from real effort by a factor of 4 ! There are further developments in place: COCOMO II (since the mid 1990s) and others Commercial versions

Alternative Model Copyright © 2005 Accenture All Rights Reserved.

Approach (1) Use both top-down and bottom-up elements: Determine essential characteristics of a project (infrastructure, technology, project team skills and experience, etc.) and derive some generic factors Factors for fixed efforts and activities like 10% for project management or infrastructure Factors for project phases (for example 50% test effort), often derived from already finished phases (step-by-step detailling of estimations)

Approach (2) Determine all work products (WBS…) of the system to be developed (# of screens, # of database tables, # of queries, # of logical modules etc.) and give them complexity factors Determine work product types (screen, table, module, …) Define all necessary tasks that need to be done to produce these work product types (for example design, coding, unit test are tasks to produce a module) Assign effort to tasks by using past experience Extrapolate to project effort (summing up) Use add-ons (contingency and risk factors)

Example (non-exhaustive) Work Package Complexity Type Multiplier / Factor PDs Requirements Elicitation 29 Function A Low Use Case 1 5 Function B Medium 8 Function C 2 16 Etc. Implementation 39 Screen A High Screen 18 Screen B Batch Job A Batch Batch Job B Technical Architecture 10 % 3,9 10% of

Prerequisites Identical estimation approach for different projects necessary Lots of experience with estimating projects necessary in order to develop good parameters Multicheck of top-down with bottom-up results and vice versa Post calculation after end of project important for improving parameters

Summary and Outlook Project Estimating Copyright © 2005 Accenture All Rights Reserved.

Importance of Estimations (1) Basis for decision to start, plan and manage a project (project controlling, earned-value analysis) If used properly, transparent way to discuss project scope and effort All approaches depend very much on personal experiences Approaches have lots of possibilities to influence the results (“Stellschrauben”) – these have to be used carefully

Importance of Estimations (2) Estimation results (effort and time) are almost always too high (for political / human reasons) and have to be adjusted in a structured and careful manner Review by experts (top-down versus bottom-up) are always necessary New technologies can make new parameters necessary Depending on the situation, multiple methods are to be used in combination

Outlook Project Planning In general, Duration = Effort / People, but: A larger project team increases team communication complexity which usually reduces productivity Therefore it is not possible to reduce duration ad libitum by adding more people to a project (on the contrary, it can even take longer !) A trade-off has always to be found between duration and people

Questions ?