Software Measurement helps in estimation, quality control, productivity assessment and project control throughout a software project.Software measurements are of direct measures and indirect measures. Direct measures include software processes like cost and effort applied and products like lines of code produced, execution speed, and other defects that have been reported. Indirect measures include products like functionality, quality, complexity, reliability, maintainability, and many more.
- Direct Measures (internal attributes)
– Cost, effort, LOC, speed, memory
- Indirect Measures (external attributes)
– Functionality, quality, complexity, efficiency, reliability, maintainability
Size Oriented metrics
- Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced
- simple size-oriented metrics for each project:
- Errors per KLOC (thousand lines of code)
- Defects per KLOC
- $ per KLOC
- Pages of documentation per KLOC
- Errors per person-month
- KLOC per person-month
- $ per page of documentation
- Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value
- The most widely used function-oriented metric is the function point (FP).
- Computation of the function point is based on characteristics of the software’s information domain and complexity
- Object-Oriented Metrics Conventional software project metrics (LOC or FP) can be used to estimate object-oriented software projects
- However, these metrics do not provide enough granularity for the schedule and effort adjustments that are required as you iterate through an evolutionary or incremental process
- Like function point (FP),the use case is defined early in the software process, allowing it to be used for estimation before significant modeling and construction activities are initiated
- Use cases describe (indirectly, at least) user-visible functions and features that are basic requirements for a system. The use case is independent of programming language.
- Because use cases can be created at vastly different levels of abstraction, there is no standard “size” for a use case
- Without a standard measure of what a use case is, its application as a normalization measure is suspect