Iterative Cost Estimation

Assume a proposed system has n initial requirements:

R = {r₁, ..., r_n}

Assume there will be k iterations:

I₁, ..., I_k

During each iteration a subset of requirements will be implemented. Thus:

R = I₁ + ... + I_k

where + denotes disjoint union. This subset is determined by the customer at the beginning of each iteration. Also, each iteration will have a fixed duration, usually two or three weeks.

Assume the development team consists of four members. Assume an iteration lasts three weeks, and assume each team member will work no more than 40 hours per week. Then:

M = 4 * 40 * 3 = 480 man-hours/iteration

Of course the value of M will vary depending on the length of an iteration and the size of the development team. Asking developers to work for more than 40 hours/week can lead to morale and quality problems.

For 1 <= j <= k, let:

e_j: R -> int

where:

e_j(r) = estimated # man-hours needed to implement requirement r

The idea of iterative cost estimation is that at the end of each iteration, in addition to a release, we also produce an improved cost estimation function.

Let:

t(r) = actual # man-hours needed to implement requirement r

Then:

e_j+1(r) = t(r) for r in I₁ + ... + I_j
e_j+1(r) = e_j(r) + delta_r for r in I_j+1 + ... + I_k

where delta_r is a correction (which can be positive or negative) to e_j(r) based on the experience gained during the previous iterations.

There are two basic rules to iterative cost estimation.

Rule 1: Never promise more than you can deliver. Assume

I_j = {r_j1, ..., r_jm}

define

e_j[I_j] = e_j(r_j1) + ... + e_j(r_jm) = estimated # man-hours to complete I_j

then:

e_j[I_j] <= M

Rule 2: Let requirements slip, not deadlines, not M. In other words, if during I_j it appears that

e_j[I_j] > M

then make the customer modify I_j:

I_j' = I_j - delta

Where delta = a subset of I_j that will be postponed to I_j+1 and such that

e_j[I_j'] <= M