The first step in comprehensively evaluating the project is to approximately assess the size of this product. One may base the size estimation on textual requirements, analysis models, prototypes or user interface elements. Although there is no ideal measure of software size, the following are most commonly used metrics:
- The number of separately testable requirements.
- Functional points and characteristic points or three-dimensional functional points, including data, functions and controls.
- Number, type and complexity of graphical user interface elements (GUI).
- Evaluated lines of code necessary to implement special requirements.
- Number of object classes or other object-oriented metrics.
All these methods are suitable for estimating the size. Choose any, given your own experience and the nature of the software being developed. Understanding what the development team has successfully achieved on the same projects using the same technologies will allow you to gauge the productivity of the team.
As soon as you have an estimate of the size, you will be able to use a commercial estimating tool that offers beneficial combinations of development effort and timing. This tooling will allow you to adjust estimates based on factors such as the expertise and the skill of the developers, the complexity of the project, and the team’s experience in the subject area.
Do you want to create better IT products? You do not have enough time to focus on your core activities, because you have to do testing work, do you? Get rid of this problem by outsourcing your testing to third party partners! What about resorting to quality assurance testing services provided by highly qualified Ukrainian specialists?
If you do not compare your estimates with the actual results of the project and do not improve the estimating capability, then your estimate will forever remain just a guess. It will sure take time to collect enough data to correlate the metric of the software size with the development effort. Your goal is to derive equations so that you can confidently estimate the size of the completed software based on its requirements.
However, even the best estimating methods will not work if clients, managers or lawyers will often change requirements. If the changes are so great that the analyst and the developers do not have time to keep up, the team may become paralyzed, unable to make meaningful progress. In this case, it may be worthwhile to defer the project until the clients’ needs are clarified.