Skip to main content

Software engineering

4 Cost estimation

Cost estimation, see figure 4.1. Course material for this chapter is on blackboard online.manchester.ac.uk

Accurately estimating how long things will take can be hard. The author of the windows file copy dialog box visits some friends: “I’m just outside town, so I should be there in fifteen minutes” … “Actually, it’s looking more like six days” … “No Wait, thirty seconds”. Estimation (xkcd.com/612) by Randall Munroe is licensed under CC BY-NC 2.5

Figure 4.1: Accurately estimating how long things will take can be hard. The author of the windows file copy dialog box visits some friends: “I’m just outside town, so I should be there in fifteen minutes” … “Actually, it’s looking more like six days” … “No Wait, thirty seconds”. Estimation (xkcd.com/612) by Randall Munroe is licensed under CC BY-NC 2.5

4.1 Work Breakdown Structures

Estimating how long something will take is often a challenging task and why many estimates like the one in figure 4.1 are not accurate. Its important to be able to justify any estimates you make, rather than just making a vague guess.

One technique for improving the accuracy (and justifiably) of your estimates is called Work Breakdown Structures (WBS) which is explained in the video in figure 4.2.

Figure 4.2: Work Breakdown Structures (WBS) will help to improve the accuracy and justifiability of your cost estimations in software engineering. You can also watch the full seven minute video embedded in this figure at youtu.be/tKCfnF-z2hY

For example, in stendhal, lets say you needed to estimate the cost if fixing a bug about players losing health points between 5.00am and 7.00am in the morning. This is 100% of your task that you could break this down into several sub-tasks follows:

  1. Replicate the bug (20%)
  2. Fix the bug (20%)
  3. Check that the bug is really fixed (20%)
  4. Push the bug fix to the repository (20%)
  5. Make sure the same bug doesn’t exist elsewhere (20%)

You could break each step down further into sub-sub-tasks

  1. Replicate the bug (20%)
    1. Replicate the bug manually (5%)
    2. Gather missing info from reporter (5%)
    3. Find tests for this or similar functionality (5%)
    4. Write test that reveals the bug (5%)

We’ve split the tasks evenly here, though in practice you would probably give them different percentages depending on the size and difficulty of the tasks.