Sunday, 7 July 2013
The size of the software needs to be estimated in order to determine the time and resources for the particular project
. The time and resources estimation plays significant role in determining the overall cost of the project. There are number of tools available in software engineering to estimate the size of the soft ware.
Line of code (LOC) and Functional Points are commonly used. In your point of view which one is the better technique?
Function Point Analysis provides the best objective method for sizing software projects, and for managing the size during development. Following are some of the many advantages that FPA offers.
(a) Helps Comparison: Since Function Points measures systems from a functional perspective they are independent of technology. Regardless of language, development method, or hardware/platform used, the number of FP for a system will remain constant. The only variable is the amount of effort needed to deliver a given set of FP; therefore, Function Point Analysis can be used to determine whether a tool, an environment, a language is more productive compared with others within an organization or among organizations. This is a critical point and one of the greatest values of Function Point Analysis.
(b) Helps Monitor Scope Creep: Function Point Analysis can provide a mechanism to track and monitor scope creep. FP counts at the end of requirements, analysis, design, code, testing and deployment can be compared. The FP count at the end of requirements and/or designs can be compared to FP actually delivered. If the project has grown, there has been scope creep. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. If the amount of growth of projects declines over time it is a natural assumption that communication with the user has improved.
(c) Ease of Contract Negotiations: From a customer view point, Function Points can be used to help specify to a vendor, the key deliverables, to ensure appropriate levels of functionality will be delivered, and to develop objective measures of cost-effectiveness and quality. They are most effectively used with fixed price contracts as a means of specifying exactly what will be delivered. From a vendor perspective, successful management of fixed price contracts depends absolutely on accurate representations of effort. Estimation of this effort (across the entire life cycle) can occur only when a normalized metric such as the one provided by Function Points is applied.
Note: Here, my meaning of the word ‘normalized metric’ is that Function Point truly accounts for the entire gamut of software development spreading across all the phases from Requirements through Testing. Whereas, LOC pertains to and is an outcome of only one of the phases.
(d) Handling Volatility: The advantage that Function Points bring to early estimation is the fact that they are derived directly from the requirements and hence show the current status of requirements completeness. As new features are added, the function point total will go up accordingly. If the organization decides to remove features or defer them to a subsequent release, the function point metric can also handle this situation very well, and reflect true state.
(e) Use of Historic Data: Once project size has been determined in Function Points, estimates for Duration, Effort, and other costs can be computed by using historic data. Since FP is independent of languages or tools, data from similar past projects can be used to produce consistent results, unlike Lines of Code data which is much tightly tied to languages requiring many other parameters to be taken into account.
(f) Availability of Empirical Formulae: Unlike lines of code, FP can be used more effectively to develop many predictive formulae such as defect potential, maintenance effort which can help pinpoint opportunities for improvement. Caper Jones estimates that Function Points raised to the 1.2 power (FP1.2) estimates the number of test cases. That is, test cases grow at a faster rate than Function Points. This is logically valid because as an application grows, the number of interrelationships within the application becomes more complex, requiring more test cases. Many empirical formulae have been suggested by Caper Jones which are in wide use among FP practitioners.
(g) Enables Better Communication: FP can help improve communications with senior management since it talks in terms of functionality rather than any implementation details, technical aspects, or physical code. Further more, Function Points are easily understood by the non-technical user. This helps communicate sizing information to a user (or customer) as well.
(h) Offers Better Benchmarking: Since FP is independent of language, development methodology, programming practices, and technology domain, projects using FP become better candidates for benchmarking across organizations and geographies.
. The time and resources estimation plays significant role in determining the overall cost of the project. There are number of tools available in software engineering to estimate the size of the soft ware.
Line of code (LOC) and Functional Points are commonly used. In your point of view which one is the better technique?
Function Point Analysis provides the best objective method for sizing software projects, and for managing the size during development. Following are some of the many advantages that FPA offers.
(a) Helps Comparison: Since Function Points measures systems from a functional perspective they are independent of technology. Regardless of language, development method, or hardware/platform used, the number of FP for a system will remain constant. The only variable is the amount of effort needed to deliver a given set of FP; therefore, Function Point Analysis can be used to determine whether a tool, an environment, a language is more productive compared with others within an organization or among organizations. This is a critical point and one of the greatest values of Function Point Analysis.
(b) Helps Monitor Scope Creep: Function Point Analysis can provide a mechanism to track and monitor scope creep. FP counts at the end of requirements, analysis, design, code, testing and deployment can be compared. The FP count at the end of requirements and/or designs can be compared to FP actually delivered. If the project has grown, there has been scope creep. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. If the amount of growth of projects declines over time it is a natural assumption that communication with the user has improved.
(c) Ease of Contract Negotiations: From a customer view point, Function Points can be used to help specify to a vendor, the key deliverables, to ensure appropriate levels of functionality will be delivered, and to develop objective measures of cost-effectiveness and quality. They are most effectively used with fixed price contracts as a means of specifying exactly what will be delivered. From a vendor perspective, successful management of fixed price contracts depends absolutely on accurate representations of effort. Estimation of this effort (across the entire life cycle) can occur only when a normalized metric such as the one provided by Function Points is applied.
Note: Here, my meaning of the word ‘normalized metric’ is that Function Point truly accounts for the entire gamut of software development spreading across all the phases from Requirements through Testing. Whereas, LOC pertains to and is an outcome of only one of the phases.
(d) Handling Volatility: The advantage that Function Points bring to early estimation is the fact that they are derived directly from the requirements and hence show the current status of requirements completeness. As new features are added, the function point total will go up accordingly. If the organization decides to remove features or defer them to a subsequent release, the function point metric can also handle this situation very well, and reflect true state.
(e) Use of Historic Data: Once project size has been determined in Function Points, estimates for Duration, Effort, and other costs can be computed by using historic data. Since FP is independent of languages or tools, data from similar past projects can be used to produce consistent results, unlike Lines of Code data which is much tightly tied to languages requiring many other parameters to be taken into account.
(f) Availability of Empirical Formulae: Unlike lines of code, FP can be used more effectively to develop many predictive formulae such as defect potential, maintenance effort which can help pinpoint opportunities for improvement. Caper Jones estimates that Function Points raised to the 1.2 power (FP1.2) estimates the number of test cases. That is, test cases grow at a faster rate than Function Points. This is logically valid because as an application grows, the number of interrelationships within the application becomes more complex, requiring more test cases. Many empirical formulae have been suggested by Caper Jones which are in wide use among FP practitioners.
(g) Enables Better Communication: FP can help improve communications with senior management since it talks in terms of functionality rather than any implementation details, technical aspects, or physical code. Further more, Function Points are easily understood by the non-technical user. This helps communicate sizing information to a user (or customer) as well.
(h) Offers Better Benchmarking: Since FP is independent of language, development methodology, programming practices, and technology domain, projects using FP become better candidates for benchmarking across organizations and geographies.
