Copyright © 2005 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Guest Lecture: Project

Copyright © 2005 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

Guest Lecture: Project EstimatingWolfgang Behr, Accenture

TU MünchenApplied Software EngineeringProf. Bernd BrüggeSoftware Engineering II, SS 2005

Copyright © 2005 Accenture All Rights Reserved.

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

3Copyright © 2005 Accenture All Rights Reserved.

Initial Situation


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 ApproachEstimation 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 ApproachEstimation 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

1

ProgramName

ProgramManagement

OperationsDeploymentCapability

DeliveryVehicle

ProcessApplicationCompetencyFacilities

andEquipment

OrganizationCulture

SolutionComponent 3

SolutionComponent 1t

SolutionComponent 2

Program Work Breakdown Structure


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


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


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)


Weight Factors

Function Type simple middlecomplex

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=

Number

Determining 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


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.


Calculation of Effort

Basic formula:• A = C * KLOCB

• A = Effort in man months• B, C = constants

Project C BSimple 2,4 1,05Semi-Complex 3,0 1,12Complex 3,6 1,20


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


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


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 Use Case 1 8

Function C Medium Use Case 2 16

Etc.

Implementation 39

Screen A High Screen 1 18

Screen B Low Screen 2 8

Batch Job A Medium Batch 1 8

Batch Job B Low Batch 1 5

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


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

?

Documents

Copyright © 2005 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Guest Lecture: Project