Work Break Down Structure

Work Breakdown Structure (WBS)

2

A detailed, hierarchical (from general to specific) tree structure of deliverables and tasks that need to be performed to complete a project.

Purpose: to identify actual tasks to be done in a project. Serves as basis for project planning.

An extension to PERT.

Work Breakdown Structure3

Identify the major task categories Identify sub-tasks, and sub-sub-tasks Use verb-noun to imply action to

something

Create WBS4

Decomposition of project deliverables and activities into smaller, more manageable parts

The lowest level in WBS is a Work Package based on Statement Of Work (SOW)

Needs to be S.M.A.R.T (Specific, Measurable, Attainable, Realistic, Timely)

Work Breakdown Structure

System Hardware Replacement

RFP Development Vendor Selection Hardware ImplementationStaff Training

Needs Assessment

Needs Analysis

Write RFP

Finalize with Purchasing

Research Vendors

Research Sites

Select Vendors to mail RFP

Review Proposals

Identify training Plan

Schedule Training

Train

Schedule Installation

Prepare Site

Arrange Vendor Support

Rank Proposals

Recommendation

Configure System

Install System

5

Work Breakdown Structure6

System Hardware Replacement

RFP Development Vendor Selection Hardware ImplementationStaff Training

Assess Needs

Analyze Needs

Write RFP

Finalize with Purchasing

Research Vendors

Research Sites

Select Vendors to mail RFP

Review Proposals

Identify training Plan

Schedule Training

Train Sysadmins

Schedule Installation

Prepare Site

Arrange Vendor Support

Rank Proposals

Make Recommendations

Configure System

Install System

WBS Dictionary7

A companion document to the WBS May have detailed content of the components

contained in a WBS, including work packages and control accounts

For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones

Can include a list of associated schedule activities, resources required, and an estimate of cost

Each WBS component is cross-referenced, as appropriate, to other WBS components

Software Cost Estimation

What is cost ?

Dictionary: es·ti·mate (es′ti mit), n.an approximate judgment or

calculation, as of the value or amount of something

Real life view a prediction that is equally likely to be

above or below the actual result

Why Estimate Software?

30% of project never complete100-200% cost overruns not uncommonAverage project exceeds cost by 90%;

Schedule by 120%15% of large project never deliver anythingOnly 16.2% of projects are successfulsource: 1998, 1999, 2000 Standish report, Choas

Fundamental estimation questionsHow much effort is required to complete an

activity?How much calendar time is needed to

complete an activity?What is the total cost of an activity?Project estimation and scheduling and

interleaved management activities

Software cost components

Hardware and software costsTravel and training costsEffort costs (the dominant factor in most

projects) salaries of engineers involved in the project Social and insurance costs

Effort costs must take overheads into account costs of building, heating, lighting costs of networking and communications costs of shared facilities (e.g library, staff restaurant,

etc.)

What Do You Estimate?

Time (schedule)ResourcesCost

Software Cost Factors

Programmer AbilityProduct ComplexityProduct SizeAvailable TimeRequired Level of ReliabilityLevel of Technology

Estimation Options

Expert Judgment Estimation done by panel of experts

Bottom-Up Approach Project separated into components Estimate components, then combined

Algorithmic Models Use of software metrics, formulas Historical models

Expert Judgment

One or more experts are consulted to provide estimates, given information on the software project

Inherently top-down approachCommon approach is to have a panel of

experts, who will agree on estimates by consensus

May be affected by group dynamicsInteresting variation: Delphi technique

Delphi Technique

Developed by Rand CorporationCoordinator provide estimator informationEstimator provides estimation individually,

without discussion with each otherCoordinator summarises estimations and

other responses, distributes for another round of estimation

Estimation repeated as much as required

Often called Delphi method, proposed by Dr. Barry Boehm in his book, Software Engineering Economics.

Useful in assessing differences between past projects and new ones for which no historical precedent exists.

Methodology Expert Opinion

Pros: Little or no historical data needed. Suitable for new or unique projects.

Cons: Very subjective. Experts may introduce bias.

Larger number of experts will help to reduce bias Qualification of experts may be questioned.

Methodology Expert Opinion (cont’d)

MethodologiesExpert Opinion - Steps Gather a group of experts together, Describe overall program in enough detail

so experts can provide an estimate, Each member of the expert group then

does an independent of the resources needed,

Estimates are gathered anonymously and compared,

If there exists significant divergence among the estimates, the estimates will be returned to the expert group,

The expert group then discusses the estimates and the divergence and works to resolve differences, and

The expert group once again submits anonymous, independent estimates which continues until a stable estimate results.

Methodology Expert Opinion - Example

Three software engineers are renown in the ERP software development.

You hold interviews which each explaining the requirements,

sizing level, and development process for your new system.

Bottom-Up Approach

Product or requirements broken down into smaller components

Estimates done for components, then combined for overall estimate

Applies to Work Breakdown Structure, or other similar methods of decomposing the project

Bottom-Up Approach (Continued)

Easier to estimate, more accurate and detailed estimate can be done

However, the product may be more than the total of the components

Additional cost may be required to consolidate the components

Analogy

Estimates costs by comparing proposed programs with similar, previously completed programs for which historical data is available. Actual costs of similar existing system are adjusted for

complexity, technical, or physical differences to derive new cost estimates

Analogies are used early in a program cycle when there is insufficient actual cost data to use as a detailed approach

Compares similarities and differencesFocus is on main cost drivers.

MethodologiesAnalogy (cont’d)

Often use single historical data point.May have several analogy estimates of sub elements to

make up the total cost.Comparison process is key to success.

May have to add or delete functionality from historical costs to match new program

Consult technical experts for advice on complexity factors, technical, performance or physical differences.

Impact of differences on cost is subjective.

Algorithmic Models

Costs are analyzed using mathematical formulae linking costs with metrics

Common methods use kLOCExample: 3-point estimationDetailed studies of software project provides

empirical estimation modelsExample: COCOMO

Algorithmic cost modelling

Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers: Effort = A SizeB M A is an organisation-dependent constant, B reflects the

disproportionate effort for large projects and M is a multiplier reflecting product, process and people attributes.

The most commonly used product attribute for cost

estimation is code size.Most models are similar but they use different

values for A, B and M.

COCOMO

Constructive Cost Model (COCOMO) is one of the earliest cost models widely used by the cost estimating community.

COCOMO was originally published in Software Engineering Economics by Dr. Barry Boehm in 1981.

COCOMO is a regression-based model that considers various historical programs software size and multipliers.

COCOMO (cont.)

COCOMO’s most fundamental calculation is the use of the Effort Equation to estimate the number of Person-Months required to develop a project. Example: # of person months * loaded labor rate =

Estimated CostMost of the other estimates (requirements,

maintenance, etc) are derived from this quantity.

COCOMO Mode & ModelThree development environments (modes)

Organic Mode Semidetached Mode Embedded Mode

Three increasingly complex models Basic Model Intermediate Model Detailed Model

COCOMO Modes

Organic Mode Developed in familiar, stable environment Product similar to previously developed product <50,000 DSIs (ex: accounting system)

Semidetached Mode somewhere between Organic and Embedded

Embedded Mode new product requiring a great deal of innovation inflexible constraints and interface requirements

(ex: real-time systems)

COCOMO Models

Basic Model Used for early rough, estimates of project cost,

performance, and schedule Accuracy: within a factor of 2 of actual 60% of time

Intermediate Model Uses Effort Adjustment Factor (EAF) from 15 cost

drivers Doesn’t account for 10 - 20 % of cost (trng, maint,

TAD, etc) Accuracy: within 20% of actuals 68% of time

Detailed Model Uses different Effort Multipliers for each phase of

project (everybody uses intermediate model)

Basic Model Effort Equation (COCOMO 81)

Effort=A(size)exponent

A is a constant based on the developmental mode organic = 2.4 semi = 3.0 embedded = 3.6

Size = 1000s Source Lines of Code (KSLOC) Exponent is constant given mode

organic = 1.05 semi = 1.12 embedded = 1.20

Basic COCOMO

Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs

It does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on software costs, which limits its accuracy

Basic COCOMO Model: Formula

E=ab (KLOC or KDSI) bb

D=cb (E) db

P=E/D where E is the effort applied in person-months, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.

Contd…

Software project ab bb cb db Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32

Basic COCOMO Model: Equation

Mode Effort Schedule

Organic E=2.4*(KDSI)1.05 TDEV=2.5*(E)0.38

Semidetached E=3.0*(KDSI)1.12 TDEV=2.5*(E)0.35

Embedded E=3.6*(KDSI)1.20 TDEV=2.5*(E)0.32

Basic COCOMO Model: Limitation

Its accuracy is necessarily limited because of its lack of factors which have a significant influence on software costs

The Basic COCOMO estimates are within a factor of 1.3 only 29% of the time, and within a factor of 2 only 60% of the time

Basic COCOMO Model: Example

We have determined our project fits the characteristics of Semi-Detached mode

We estimate our project will have 32,000 Delivered Source Instructions. Using the formulas, we can estimate:

Effort = 3.0*(32) 1.12 = 146 man-months Schedule = 2.5*(146) 0.35 = 14 months Productivity = 32,000 DSI / 146 MM

= 219 DSI/MM Average Staffing = 146 MM /14 months

= 10 FSP

Intermediate COCOMO

Takes basic COCOMO as starting point Identifies personnel, product, computer

and project attributes which affect cost and development time.

Multiplies basic cost by attribute multipliers which may increase or decrease costs

Intermediate ModelEffort Equation (COCOMO 81)

Effort=EAF*A(size)exponent

EAF (effort adjustment factor) is the product of effort multipliers corresponding to each cost driver rating

A is a constant based on the developmental mode organic = 3.2 semi = 3.0 embedded = 2.8

Size = 1000s Delivered Source Instruction (KDSI) Exponent is constant given mode

COCOMO COST DRIVERSRatings range: VL, L, N, H, VH, XH

RELY Reliability PCAP Programmer Capability

DATA Database Size AEXP Applications Experience

CPLX Complexity PEXP Platform Experience

RUSE Required Reusability LTEX Language and Tool Experience

DOCU Documentation PCON Personnel Continuity

TIME Execution Time Constant TOOL Use of Software Tools

STOR Main Storage Constraint SITE Multisite Development

PVOL Platform Volatility SCED Required Schedule

ACAP Analyst Capability

Gone:VIRT,TURN,MDDP,VEXP New: RUSE, DOCU, PVOL, PCON

Project Scale FactorsPMestimated

3.67i

(Size)(SF) EMi

SF .0.910.01 wi

Scale Factors(Wi)

Very Low Low Nominal High Very High Extra High

PREC thoroughlyunprecedented

largelyunprecedented

somewhatunprecedented

generallyfamiliar

largely familiar throughlyfamiliar

FLEX rigorous occasionalrelaxation

somerelaxation

generalconformity

someconformity

general goals

RESL little (20%) some (40%) often (60%) generally(75%)

mostly (90%) full (100%)

TEAM very difficultinteractions

some difficultinteractions

basicallycooperativeinteractions

largelycooperative

highlycooperative

seamlessinteractions

PMAT weighted sum of 18 KPA achievement levels

Early Design and Post-Architecture Model

FactorsScaleProcessSizeEffort

sMultiplier

Environment

Environment: Product, Platform, People, Project Factors

Size: Nonlinear reuse and volatility effects

Process: Constraint, Risk/Architecture, Team, Maturity Factors

FactorsScaleProcess EffortSchedule Multiplier

Relativecost

Amount Modified

1.0

0.75

0.5

0.25

0.25 0.5 0.75 1.0

0.55

0.70

1.0

0.046

Usual LinearAssumption

Data on 2954NASA modules

[Selby, 1988]

Nonlinear Reuse Effects

COCOMO Model ComparisonsCOCOMO Ada COCOMO COCOMO II:

Application CompositionCOCOMO II:Early Design

COCOMO II:Post-Architecture

Size Delivered Source Instructions(DSI) or Source Lines ofCode (SLOC)

DSI or SLOC Application Points Function Points (FP) andLanguage or SLOC

FP and Language or SLOC

Reuse Equivalent SLOC = Linear(DM,CM,IM)

Equivalent SLOC = Linear(DM,CM,IM)

Implicit in Model Equivalent SLOC = nonlinear(AA, SU,UNFM,DM,CM,IM)

Equivalent SLOC = nonlinear(AA, SU,UNFM,DM,CM,IM)

Rqts. Change Requirements Volatilityrating: (RVOL)

RVOL rating Implicit in Model Change % : RQEV

Maintenance Annual Change Traffic(ACT) = %added + %modified

ACT Object Point ACT (ACT,SU,UNFM) (ACT,SU,UNFM)

Scale (b) inMMNOM=a(Size)b

Organic: 1.05 Semidetached:1.12 Embedded: 1.20

Embedded: 1.04 -1.24depending on degree of: early risk elimination solid architecture stable requirements Ada process maturity

1.0 .91-1.23 depending on thedegree of: precedentedness conformity early architecture, risk

resolution team cohesion process maturity (SEI)

.91-1.23 depending on thedegree of: precedentedness conformity early architecture, risk

resolution team cohesion process maturity (SEI)

Product Cost Drivers RELY, DATA, CPLX RELY*, DATA, CPLX*,RUSE

None RCPX*, RUSE* RELY, DATA, DOCU*,CPLX, RUSE*

Platform Cost Drivers TIME, STOR, VIRT, TURN TIME, STOR, VMVH,VMVT, TURN

None Platform difficulty: PDIF * TIME, STOR, PVOL(=VIRT)

Personnel CostDrivers

ACAP, AEXP, PCAP,VEXP, LEXP

ACAP*, AEXP, PCAP*,VEXP, LEXP*

None Personnel capability andexperience: PERS*, PREX*

ACAP*, AEXP, PCAP*,PEXP*, LTEX*, PCON*

Project Cost Drivers MODP, TOOL, SCED MODP*, TOOL*, SCED,SECU

None SCED, FCIL* TOOL*, SCED, SITE*

* Different Multipliers Different Rating Scale

RQEV

Percentage of sample projects within 30% of actuals

-Without and with calibration to data source

COCOMO II Estimation Accuracy:

COCOMO81 COCOMOII.2000COCOMOII.1997

# Projects 63 83 161

Effort

Schedule

81% 52%64%

75%80%

61%62%

72%81%

65%