- Part 1: Introduction
- Part 2: The Process of Software Development
- Part 3: The Cone of Uncertainty
- Part 4: Expert Judgement
- Part 5: Count
To come up with an estimate for completing a software development project, first you need to really understand the process of completing a project. This concept should be obvious, but too many times it is not. People who have only been involved in the coding piece of a project sometimes do not understand all of the other steps that go into a project. They will come up with an estimate for completing the coding, and not communicate to their management that their estimate did not include the other pieces. This will lead to an estimate that is very small.
Typically a software development project will have six phases. You may have a couple more, or you may call these something a little different, but typically these are the main six phases:
- Scoping: The purpose of this phase is to put a high level boundary around the purpose of the project. What is the customer asking for? It’s a good idea to make a high level list of business goals, what features are in scope, and what is out of scope.
- Requirements: The purpose of this phase is to completely flesh out exactly what the customer is wanting. The result of this phase will be a very detailed requirements document with the following sections: Business Requirements, Functional Requirements, Nonfunctional Requirements, Dependencies, Assumptions, Out of Scope.
- Design: You have now defined exactly what the customer wants. The purpose of this phase is to detail exactly how the solution to the problem is going to be constructed. The result will be a very detailed Technical Specification that will be a blueprint for developing the software. My goal here is to make it so detailed that someone only moderately familiar with the technology and problem domain could pick up the document and complete the project. Its always easiest to figure out the difficult parts of the project there before a single line of code has been written.
- Development: This is the phase where the actual coding is being done. If the requirements and design were solid, then it should be a very smooth process for the development team to complete the construction.
- Testing: This is the phase where the test team takes the requirements and tests every aspect of the application to ensure that every requirement is met by the application. Unit Testing should occur in the Development phase. The testing that should occur here are: Functional Testing, Integration Testing, Performance and Load Testing, and User Acceptance Testing.
- Deployment: This the phase where the application is actually rolled out and made available to the end users.
The above list is very high level. But, from it you can see that there are a lot of different tasks and phases that go into the process of completing a software development project. An estimate put together should include all of these.
One good way to make sure you allocate enough time to each of the phases is to keep records of how you do at previous projects. If this is your first project, lean on some industry averages. But, from then on out, keep records on your execution time and adjust future estimates accordingly.
The following outlines what I’m talking about. Let’s say your project delivery rate normally falls out as follows:
- Scoping: 5%
- Requirements: 20%
- Design: 20%
- Development: 30%
- Testing: 20%
- Deployment: 5%
Having these statistics on hand is very powerful. If you are completing a project very similar than several you have done in the past and you have these numbers, you can estimate just the construction of the project and from that extrapolate how much time the other phases will take.
So, while putting together a project estimate, the first key is to keep in mind the entire process of software development. If you do not do this, you will miss pieces and your estimate will be too small. The next key is to keep detailed data on your completed projects so you can use those numbers to aide in estimating future projects.
In the next post, I will talk about the Cone of Uncertainty, and how the accuracy of your estimate varies based on when you make the estimate.