Software Project Management

Estimate effort, cost & time — step by step.

Every technique from the lecture as a live calculator. Change any input and the worked solution rewrites itself, using the same steps and rounding as the course notes.

Which technique should I use?

SLOC — when the programming language and technology are predefined and stay the same through the project (e.g. 3GLs like FORTRAN or COBOL).
Function Points — language-independent; measures functionality from the user's point of view. Use when you have past data to weight the 14 GSCs.
COCOMO — when the project is large and requirements are vague, the environment is new to the organization, or you have no baseline data from past projects. Works with both SLOC and FP.
Delphi — human-based; good for small projects or when you have the experts and data for unambiguous estimates.

4.1 · Source Lines of Code

SLOC Technique

Use the estimated size in lines of code and the team's productivity to get the total effort, duration and cost.

Inputs

Estimated size lines of code

LOC

Average productivity

LOC / PM

Developers

people

Labor rate

$ / PM

Effort = LOC / Productivity
Cost = Effort × Labor rate

Results

Total effort

—

person-months

Duration

—

months

Total cost

—

USD

Cost per LOC

—

$ / line

Lecture notes · Counting SLOC

SLOC is an objective way to estimate the size of a project. Size then drives resources, effort, cost and duration.

The count includes

SLOC delivered to the client
SLOC written only by the development team
Declaration statements

The count excludes

Code created by application generators
Comments inserted to improve readability

Disadvantages

Language-dependent — depends on the specific language used.
The effort needed to write a line of code is not the same for all languages.

4.2 · Function Point Technique

Function Points

Fill in the five measurement parameters, rate the 14 general system characteristics, pick a language — get total FP and LOC.

1 · Count Total (CT)

Set all:

Simple Average Complex

Parameter	Count	Weight · S / A / C	Total
Count Total (CT)			0

2 · Language (AVC)

average LOC per FP

Programming language

AVC

LOC / FP

Language table

Language	LOC/FP

Results

FP = CT × (0.65 + 0.01 × ΣFi) · LOC = AVC × FP

Count total

—

ΣFi

—

total weighting factor

Function points

—

Lines of code

—

LOC

3 · General System Characteristics (ΣFi)

Enter ΣFi directly

0 = No influence · 1 = Incidental · 2 = Moderate · 3 = Average · 4 = Significant · 5 = Critical

#	Question	Degree of influence
	Total Weighting Factor (ΣFi)	0

Lecture notes · History & features of FP

Developed as an alternative to LOC. Allan J. Albrecht invented function points in 1979 at IBM, then introduced the GSCs in 1984. Since 1990, IFPUG revises the theory.
Independent of the computer language, methodology, technology or team capability.
A direct measurement of software functionality from the user's perspective — the most popular size technique.
Total FP can be split across SDLC phases, used to estimate effort per FP, cost per FP and defects per FP.
Each row total = count × selected weight; CT = sum of the five totals.

4.2.3 – 4.2.4 · Estimating with FP

FP Effort & Cost

Two lecture methods: effort from hours per FP, and cost from productivity in FP per person-month.

A · Initial estimation (hours per FP)

Total FP

Productivity

hrs / FP

Work per day

hrs / day

Working days

days / month

Developers

people

Person-hours

—

Person-days

—

Person-months

—

Duration

—

months

B · FP-based estimation (cost per FP)

Total FP

Productivity

FP / PM

Labor rate

$ / PM

Cost per FP

—

$ / FP

Total cost

—

USD

Total effort

—

person-months

4.2.5 · Post-project analysis

Defect Density

Express quality per function point to compare completed projects. The lowest density is the best quality.

Projects

Defect density = Total defects / Total size in FP

Project	Defects	Size (FP)	Defects / FP

Comparison

lower is better

—

4.3.1 · COnstructive COst MOdel

Basic COCOMO

A rough effort estimate from size only — pick the project mode and enter thousands of lines of code.

Inputs

Size

KLOC

Labor rate optional

$ / PM

E = C × (KLOC)^K

Project type	C	K

Results

Effort

—

person-months

Dev. time*

—

months

Avg. staff*

—

people

Cost

—

USD

Same size, every mode

* Development time uses Boehm's schedule equation D = 2.5 × E^d (d = 0.38 / 0.35 / 0.32), which the lecture mentions but doesn't list.

Lecture notes · The three modes

Organic

Relatively small, simple projects; small team with good application experience; less-than-rigid requirements. e.g. banking or inventory systems.

Semi-detached

Intermediate size and complexity; teams with mixed experience; a mix of rigid and less-rigid requirements. e.g. a new OS or a DBMS.

Embedded

Developed within tight hardware, software and operational constraints. e.g. real-time OS, industrial automation, space and aviation systems.

Three steps

S1 — Estimate total delivered lines of code.
S2 — Determine the effort constants for the project type.
S3 — Substitute into the formula.

4.3.2 · Effort Adjustment Factor

Intermediate COCOMO

Initial effort from KLOC, adjusted by rating the 15 cost-driver attributes. Untouched drivers stay at Average (1.0).

Step 1 · Initial effort

Size

KLOC

Labor rate optional

$ / PM

Ei = C × (KLOC)^K · E = EAF × Ei

Results

Initial effort Ei

—

person-months

EAF

—

product of multipliers

Adjusted effort E

—

person-months

Cost

—

USD

Step 2 · Cost driver attributes

Picking a rating fills Boehm's standard multiplier — you can type your own value.

Cost driver	Rating	Multiplier

Lecture notes · Advanced COCOMO & applicability

Typically each driver's value ranges from 0.9 to 1.4; the average rating is a static 1.0.
Advanced COCOMO uses the intermediate steps, plus cost drivers assigned to each phase of the SDLC (analysis, design, …).
COCOMO is flexible and works with both SLOC and FP.

4.4 · Human-based estimation

Delphi Technique

Experts estimate each task independently. Tasks whose variance is above the agreed limit are discussed and re-estimated.

Step 3 · Acceptable variance

Round 1

Maximum variance accepted

The eight steps

1Identify the teams that will estimate.

2Present project details to the expert group.

3Finalize the acceptable variance value.

4Prepare a list of tasks.

5Experts estimate independently.

6Prepare a summary of estimates per task.

7Discuss tasks with unacceptable estimates.

8Repeat from step 5 until all are finalized.

Steps 5–6 · Summary of estimates

Type each expert's estimate in hours, separated by commas. Variance = (Max − Min) / Max × 100.

Task	Expert estimates (hrs)	Max	Min	Var %	A / NA

—

Lecture notes · Roles & rules

Estimation experts — usually 5–6 experienced project managers whose past projects match the current one.
Estimation coordinator — like a moderator; facilitates the meeting and makes sure its goals are met.
Author — like a recorder of minutes; presents the project details and expectations.
No discussion is allowed while experts estimate (step 5) so nobody influences the others.
In step 7 the max and min estimates are not disclosed; tasks can be broken down or combined.
Simple and subjective, yet effective because the estimates are tried and tested.