Authors: Zhou Chenghan, Alessandro Versace, Alessandro Landra, Ivan Lombardi
Date: 25 Apr 2021
Version: 1.0
- [Estimate by product decomposition]
- [Estimate by activity decomposition ]
Our estimations in time and costs are based on Lines Of Code (LOCs) approach and on an activity decomposition. In the first case we are computing an average size per class counting all single lines, without any subtraction of comments, packages, etc. In the second case we computed planned person hours needed on each activity based on realistical distribution for each step of the project plan. What we are not confident about is the estimated calendar time in calendar weeks in the product decomposition, because we see productivity as a little bit high. The activity decomposition estimation seems more realitic because we can estimate more deeply each portion of the project and taking in count if parallel work may be possible or not in the Gantt chart. Even if this might be possible during the coding or the testing developing parts, it's very unlikely to be realized during Requirements and Design formalization, expecially using a waterfall approach. The difference at the end of the two estimations is of about 50ph on the effort and a longer calendar time needed on an activity decomposition approach because of non-parallelizable parts.
| Estimate | |
|---|---|
| NC = Estimated number of classes to be developed | 26 class |
| A = Estimated average size per class, in LOC | 180 LOCs |
| S = Estimated size of project, in LOC (= NC * A) | 4680 LOCs |
| E = Estimated effort, in person hours (here use productivity 10 LOC per person hour) | 468 ph |
| C = Estimated cost, in euro (here use 1 person hour cost = 30 euro) | €14040 |
| Estimated calendar time, in calendar weeks (Assume team of 4 people, 8 hours per day, 5 days per week ) | 3w (2.9w) |
| Activity name | Estimated effort (person hours) |
|---|---|
| Requirements | |
| Market analysis | 7 |
| Elicitation | 8 |
| Model process | 6 |
| Progress estimation + planning | 6 |
| Define high level use cases | 4 |
| System requirements document formalization | 25 |
| Software requirements document formalization | 18 |
| Design GUI | 10 |
| Requirements inspection (V & V) | 12 |
| Design | |
| Analysis | 4 |
| High level document formalization | 7 |
| Low level document formalization | 16 |
| Design inspection (V & V) | 10 |
| Units Code Implementation | |
| Implement units code | 160 |
| Units Testing | |
| Tests implementation following use cases | 75 |
| Tests inspection (V & V) | 12 |
| Test code units (V & V) | 28 |
| Integration Testing | |
| Test modules as a group | 25 |
| Integration System | |
| Build up system and test it as a whole | 25 |
| Management | |
| Project - Configuration management - Quality assurance | 60 |
The Gantt chart shows the Management activity that starts a little bit before the real working process and ends the project after the estimation to include internal project management decisions and post mortem activities that are not paid by the buyers, but aims to improve the team future works.