Introduction
The article is comprehensive and quite informative. To start with, I like the way reasons why major software programs fail have been clearly outlined and the precautions or action that need to be taken discussed broadly. I have noted that major software-intensive acquisition programs fail mostly due to poor size estimation. The size of the program as a result determines the cost, schedule and effort. It is for this reason that size estimation must be constantly updated with actual courts throughout the life cycle. If software is assessed to determine status of the program then meaningful, effective remedial action needs to be taken, for example, improving response to the developer, relaxing performance requirements, controlling requirement changes, extending schedule, adding money or any other alternative.
Problems
The article illustrates clearly how one need to take control to keep software acquisition and development process from breaking down. As for the case of software estimation, I have been enlightened that the key to credible software sizing is to use a variety of software sizing techniques and not rely on a single source or method for the estimate. To improve the accuracy, programmers are advised to base estimates on the smallest possible unit of each component. I have also liked the fact that problems that commonly arise as a result of deviations in software size data are clearly listed for this will help the program developers to plan well. Some of the problems include.
- Problems in requirements stability, design, coding and processes.
- Unrealistic interpretation of original requirements and resource estimates to develop the system.
- Problems in the model(s), logic and rationale used to develop the estimate.
- Faulty software productivity rate estimates.
The basic methods for measuring software size have also been clearly outlined, that is; Function points, feature points and SLOC (source lines- of-code).
Most SLOC estimates count all executable instructions and data declarations but exclude comments, blanks and continuation lines.
Function points are the weighted sums of five different factors that relate to user requirements i.e. Inputs outputs logic [or master] files, inquiries and interfaces.
Feature points were developed to estimate or measure real-time systems software with high algorithmic complexity and generally fewer input /outputs than management information systems (MIS).
To prevent problems associated with deviations in software size, then program developers should determine how much software to build and make sure they allow adequate fund or allow enough time for development. Poor size estimates result in increase in cost and schedule overruns. Due to shortcomings in size estimation, it is absolutely critical to measure, track and control software size against original estimates both incrementally and for the total build.
I have also found the cost and schedule estimation methodologies or techniques very useful. Just to list down, a few of them include:
- Analogies: estimates are based on data from completed similar efforts.
- Expert: cost and schedule estimates are determined by required effort based on input from personnel with extensive experience on similar programs.
- Parametric models: they generate estimates through statistical formulas that relate a dependent variable (cost, schedule, resources) to one or more independent variables.
- Engineering build: Estimates are determined by estimating effort based on the effort summation of detailed functional breakout of task at the lowest feasible level of work.
- Cost performance report (CPR) analysis: Estimates are based on current progress.
- Cost estimating relationships (CER) factors: estimates are determined by effort based on algebraic relationships between a dependent (cost) variable and independent variables.
Though, the above mentioned techniques and methodologies are widely used none of them is a hundred percent effective. However, parametric model is most commonly used. Before adopting any of them one need to understand software’s functionality, architecture and characteristics and contract is necessary to accurately estimate required effort, schedule and cost.
Software measurement is essential to achieving the basic management objectives of prediction, progress and process improvement. The key components of an effective measurement process are:
- Clearly defined software development issues and the measures (data elements) needed to provide insight into those issues.
- Processing of colleted data into graphical or tabular reports to aid in issue analysis.
- Analysis of indicators to provide insight into development issues.
- Use of analysis result to implement process improvement and identify new issues and problems.
For measurement to be effective, insights gained from metrics should be merged with process knowledge gathered from other sources in the conduct of daily program activities. Metrics gives one the ability to identify, resolve and/or curtail risk issues before they surface.
Despite the fact that the article is informative and clearly guides the program developers on how to measure, estimate software, I think the amendment of some sections is required for I did not like it. For instance, having described methods for measuring software, in other areas it is indicated that it is difficult to relate software functional requirements to source lines-of-code (SLOC) especially during the early stages of development.
It is virtually impossible to estimate SLOC from initial requirement statements. Their use in estimation required a level of detail that is hard to achieve i.e. the planer must often estimate the SLOC to be produced before sufficient detail is available to accurately do so. Because SLOC are language-specific, the definition of how SLOC are accounted has been troublesome to standardize. Functional points are also difficult to estimate at the very early stages of system development. The complexity factors applied to the equation are subjective since they are based on the analyst/engineers judgment. Few automated tools are available to count either unadjusted or adjusted function points making comparisons between or among programs difficult, and making the fun point’s counts for single program inconsistent when calculated by different analysts. Both function points and SLOC are affected by changes in system or software requirements. After analyzing the drawbacks of each method, it is my opinion that the best method should have been recommended in the article.
For the part of cost and schedule estimation methodologies, I found out analogy method is not effective because it is difficult to find analogous effort at the total system level. In cost performance report (CPR) analysis, progress in one phase may not be predictive of progress in the next phase and lack of progress in one phase may not show up until subsequent phases.
Lastly, having said that metrics will help one to identify, resolve and curtail risk issues then there is contradiction when so many limitations and constraints of metrics are highlighted i.e.
- Metrics should not be used to judge your contractor or individual performance.
- Metrics must be understood to be of value.
- Metrics are only as good as the data that support them.
- Metrics must be used as indicators not as absolutes.
- Metrics cannot identify or predict everything.
Analysis of metrics should not be performed exclusively by the contractor:
- Direct comparison of programs should be avoided.
- A single metrics should not used.
Conclusion
I can conclude that a good measurement program is an investment in success by facilitating early detection of problems, and providing quantitative clarification or critical development issues.
Reference
Software measurement. 2008. Web.