# Software Engineering (2160701)

BE | Semester-6   Winter-2017 | 11/03/2017

## Q2) (c)

### Size-Oriented Metrics

• Derived by normalizing (standardizing) quality and/or productivity measures by considering the size of the software produced
• Thousand lines of code (KLOC) are often chosen as the normalization value
• A set of simple size-oriented metrics can be developed for each project
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $per KLOC • Pages of documentation per KLOC • In addition, other interesting metrics can be computed, like • Errors per person-month • KLOC per person-month •$ per page of documentation
• Size-oriented metrics are not universally accepted as the best way to measure the software process
• Opponents argue that KLOC measurements
• Are dependent on the programming language
• Penalize well-designed but short programs
• Cannot easily accommodate nonprocedural languages
• Require a level of detail that may be difficult to achieve

### Function Oriented Metrics

• Function-oriented metrics use a measure of the functionality delivered by the application as a normalization value
• Most widely used metric of this type is the Function Point
• FP = Count Total * [0.65 + 0.01 * Sum (Value Adjustment Factors)]
• Function Point values on past projects can be used to compute,
• for example, the average number of lines of code per function point

### 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 (detailing) for the schedule and effort adjustments that are required as you iterate through an evolutionary or incremental process
• Lorenz and Kidd suggest the following set of metrics for OO projects
• Number of scenario scripts
• Number of key classes (the highly independent components)
• Number of support classes

### Use Case Oriented Metrics

• Like FP, the use case is defined early in the software process, allowing it to be used for estimation before significant (valuable) 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 (doubtful).
• Ex., effort expended / use case