LEARNING OBJECTIVES

Develop a work breakdown structure.

Describe the difference between a deliverable and a
milestone.
Describe and apply several project estimation
methods. These include the Delphi technique, time
boxing, top-down estimation, and bottom-up
estimation.
Describe and apply several software engineering
estimation approaches. These include lines of code
(LOC), function point analysis, COCOMO, and
heuristics.
 PROJECT TIME MANAGEMENT (PTM)
PMBOK®

Activity definition
 Identifying what activities must be completed to produce the project scope deliverables
Activity sequencing
 Determining whether activities can be completed sequentially or in parallel and any
dependencies that may exist among them
Activity resource estimation
 Identifying the type of resources (people, technology, facilities, etc.) and the quantity of
resources needed to carry out project activities
Activity duration estimation
 Estimating the time to complete each activity
Schedule development
 Based on the availability of resources, the activities, their sequence, and time estimates, a
schedule for the entire budget can be developed
Schedule control
 Ensuring that proper processes and procedures are in place in order to control changes to
the project schedule
WHAT IS A WBS?
Definition: Deliverable-oriented hierarchical decomposition of the
work to be ‘executed’ by the team to accomplish the project
objectives and create the required deliverables.
Purpose: Organizes and deliver the total scope of project
 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 is naturally subdivided. It is an outline of what work is to be
performed
 PMBOK Guide® (17).

WBS is a hierarchical and incremental decomposition of the project into

phases, deliverables and work packages. It is a tree structure, which shows
a subdivision of effort required to achieve an objective; for example a
program, project, and contract.
WORK PACKAGE
 DELIVERABLES VERSUS MILESTONES

Deliverables
 Tangible, verifiable work products
 Reports, presentations, prototypes, final application system, etc.
Milestones
 Significant events or achievements
 Acceptance of deliverables or phase completion
 Cruxes (proof of concepts) – test idea, concept, technology
 Quality control (not only be done, but must be done right)
 Keeps team focused
DELIVERABLES VERSUS MILESTONES
CRUXES EXAMPLE

Suppose that an organization is building a data warehouse using a

particular Vendor's relational database product for the first time .
A crux for this project may be the collection of data from several
different legacy system .
Milestone that would encourage the organization to invest more
time and resources to complete the project.
 DEVELOPING THE WBS

A work package is developed for each of the phases and deliverables

defined in the Deliverable Structure Chart (DSC)
 DELIVERABLE: TEST RESULTS REPORT

Logical Activities:
1. Review the test plan with the client so that key stakeholders are
clear as to what will be tested, how the tests will be conducted, and
when the tests will be carried out.
2. Carry out the tests as outlined in the plan.
3. Once the test results are collected, we need to analyze them.
4. The results should be summarized in the form of a report and
presentation to the client.
5. If all goes well, the client will sign-off or approve the test results and
then we can move on to the implementation phase of the project. If
not, then we need to address and fix any problems.

What are the deliverables? Milestones?

EXAMPLE WORK BREAKDOWN
SCHEDULE
THE WBS SHOULD FOLLOW THE WORK
PACKAGE CONCEPT
 THE WBS…

 Should be “deliverable-oriented”
 Should support the project’s MOV
 Have enough detail to support planning and control
 Should involve those who will be doing the work
 Should include learning cycles and past lessons learned
ESTIMATION QUESTIONS

What are you going to estimate?

Where do you start?

How do you estimate?

 ESTIMATION TECHNIQUES - TRADITIONAL
PROJECT MANAGEMENT APPROACHES

1. Guesstimating
2. Delphi Technique
3. Time Boxing
4. Top-Down
5. Bottom-Up
6. Analogous Estimates (Past experiences)
7. Parametric Modeling (Statistical)
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.

Guestimating
 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
ESTIMATES ARE MADE FOR EACH ACTIVITY IN THE
WBS

6.2 Test Results Report

6.2.1 Review test plan with client 1 day
6.2.2 Carry out test plan 5 days
6.2.3 Analyze results 2 days
6.2.4 Prepare test results report and presentation 3 days
6.2.5 Present test results to client 1 day
6.2.6 Address any software issues or problems 5 days

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
1. Lines of Code (LOC)
2. Function Points
3. COCOMO
4. 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
 LINES OF CODE (LOC)

A popular method for estimating and tracking programmer

productivity.
Have some issues such as;
 a 1,000 LOC Java program will be ten times larger than a 100 LOC Java
program—counting LOC is not all that straightforward.
 Adding comments or declaring variables may or may not count a LOC.
 Experienced programmers tend to write less code than novice
programmers
 The same can be said for different programming languages. In fact, one
could argue that counting LOC could encourage programmers to write
inefficient code, especially when LOC are used as a productivity metric.
 Finally, it is much easier to count the lines of code after a program is
written than it is to estimate how many lines of code will be required to
write the program.
LINES OF CODE (LOC)
 FUNCTION POINT ANALYSIS

Allan Albrecht, IBM – 1979

Method used to break systems down into smaller components
so that they can be better understood and analyzed.
Independent of the Technology, we can compare one
application written in one language with another application
developed in another.
IFPUG standards (www.ifpug.org)
FUNCTION POINT ANALYSIS
 THE FIVE COMPONENTS OF FUNCTION POINTS

Data Functions
1) Internal Logical Files (ILF)
 ERD, can be classified as L,A,H based on number of data
elements and subgroup maintained by the ILF.
 Few data elements, less complex
2) External Interface Files (ELF)
 Maintained by another application system
Transactional Functions
3) External Inputs (EI)
 data user input to system
4)External Outputs (EO)
 reports, confirmation messages
5)External Inquiries (EQ)
 includes combination of input and output, does not change any data
THE APPLICATION BOUNDARY FOR FUNCTION POINT
ANALYSIS
TO DETERMINE THE TOTAL UNADJUSTED
FUNCTION POINTS (UAF)
1) Determine the UAF, for example after reviewing the
EC system, the following complexity has been
determined.

Complexity
Low Average High
Internal Logical Files (ILF) 3 2 1
External Interface Files (EIF) 2
External Input (EI) 3 5 4
External Output (EO) 4 2 1
External Inquiry (EQ) 2 5 3
 Complexity

Low Average High Total

Internal Logical Files

(ILF) _3 x 7 = 21 _2 x 10 = 20 _1 x 15 = 15 56

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 = 24 53

External Output (EO)

_4 x 4 = 16 _2 x 5 = 10 _1 x 7 = 7 33

External Inquiry (EQ)

_2 x 3 = 6 _5 x 4 = 20 _3 x 6 = 18 44

Total Unadjusted Function Points (UAF) 200

Table 1
TO COMPUTE THE VAF (VALUE ADJUSTMENT FACTOR)
Next, compute the VAF.
VAF is based on the Degrees of Influence (DI).
Derived from 14 GSC (General System
Characteristic)
Scale from 0-5
Total Degrees of Influence (TDI) is the sum of all DI
Formula:
Value Adjustment Factor VAF = (TDI * 0.01) + .65
Total Adjusted Function Points = FP = UAF * VAF
General System Characteristic Degree of Influence

Data Communications 3

Distributed Data Processing 2

Performance 4

Heavily Used Configuration 3

Transaction Rate 3

On-line Data Entry 4

End User Efficiency 4

Online Update 3

Complex Processing 3

Reusability 2

Installation Ease 3

Operational Ease 3

Multiple Sites 1

Facilitate Change 2
Total Degrees of Influence (TDI) 40
Value Adjustment Factor VAF = (TDI * 0.01) + .65 VAF = (40 * .01) + .65 = 1.05

Total Adjusted Function Points = FP = UAF * VAF

FP = 200 * 1.05 = 210

Table 2 :GSC and Total Adjusted Function Point

DEVELOPMENT ESTIMATION
From the Total Adjusted Function Point (TAFP), the function
point count can be transformed into development
estimation.
Such as productivity for a programmer, days of man work etc..
Second approach is converting the FP to equivalent lines of
code (for different programming language)
Example: An application/module has 210 total adjusted
function point would require 134, 440 lines of code using
machine language but only 6090 lines using VB5.
 Language Average Source LOC per Function Point Average Source LOC for a 210 FP Application

Access 38 7,980

Basic 107 22,470

C 128 26,880

C++ 53 11,130

COBOL 107 22,470

Delphi 29 6,090

Java 53 11,130

Machine Language 640 134,440

Visual Basic 5 29 6,090

Table 3. Source: http://www.spr.com/library/0langtbl.htm

 COCOMO

COnstructive COst MOdel

Developed by Barry Boehm,
Has been extended to COCOMO II
http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html
Is an example of Parametric model because it uses dependent variable such as cost or
duration.
PROJECT TYPES
Project types can be classified as:
Organic—These are routine projects where the technology, processes, and
people are expected to all work together smoothly. One may view these types
of projects as the easy projects where few problems are expected.
Embedded—An embedded project is viewed as a challenging project. For
example, it may be a system to support a new business process or an area
that is new ground for the organization. The people may be less experienced,
and the processes and technology may be less mature.
Semi-Detached—If organic projects are viewed as easy and embedded as
difficult or challenging, then semi-detached fall somewhere in the middle.
These projects may not be simple and straightforward, but the organization
feels confident that its processes, people, and technology in place are
adequate to meet the challenge.
 COCOMO MODELS (EFFORT)

Uses Equation based on Project Types;

1) Organic – Routine
 Person Months = 2.4 * KDSI1.05
2) Embedded – Challenging
 Person Months = 3.6 * KDSI1.20
3) Semi-Detached – Middle
 Person Months = 3.0 * KDSI1.12

In COCOMO, a person-month is defined as 152 hours.

KDSI refers to Thousand of delivered source instructions (LOC)
 COCOMO – EFFORT EXAMPLE

For example for a medium project (a Semi-Detached) equation can be used.

We have 200 FP, refer to Table 3 using Java.

10,600 Java LOC = 200 FP * 53

Person Months = 3.0 * KDSI1.12
= 3.0 * (10.6) 1.12
= 42.21

* A 200 FP project will require 10600 LOC and 42.21 (effort) person-month to complete.
 COCOMO MODELS (DURATION)

To determine the duration of the project, below formula is used;

1) Organic
 Duration = 2.5 * Effort0.38
2) Semi-Detached
 Duration = 2.5 * Effort0.35
3) Embedded
 Duration = 2.5 * Effort0.32
 COCOMO DURATION EXAMPLE

Duration = 2.5 * Effort0.35

= 2.5 *(42.21)0.35
= 9.26 months to complete

People Required = Effort / Duration

= 42.21 / 9.26
= 4.55
So the EC project requires 4/5 people to complete in 9 months.
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 seeds of major software disasters are usually
sown in the first three months of commencing the
software project. Hasty scheduling, irrational
commitments, unprofessional estimating techniques,
and carelessness of the project management
function are the factors that tend to introduce
terminal problems. Once a project blindly
lurches forward toward an impossible
delivery date, the rest of the disaster will
occur almost inevitably.

T. Capers Jones, 1988 Page 120

BROOKS’ LAW

Adding manpower to a late software

project makes it later.
 ADDING PEOPLE

Increases the total effort necessary

 The work & disruption of
repartitioning
 Training new people
 Added intercommunication
WHAT CAN CAUSE INACCURATE ESTIMATES?

Scope changes No (or poor) methodology

Overlooked tasks Changes in team
Poor developer-user Red tape
communication Lack of project control
Poor understanding Not identifying or
of project goals understanding impact
Insufficient analysis 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