Software Engineering (2160701)

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