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.

• If a software organization maintains simple records, a table of size-oriented measures, such as shown in below fig.

• The table lists each software develop project that has been completed over past few years and corresponding measure for that project referring to the table entry for project alpha: 12,100 lines of code were developed with 24 person-months of effort at a cost 0f $ \$ $168,000.

• It should be noted that the effort and cost recorded in the table represents all software engineering activities (analysis, design, code and test) not just coding. Further information for project alpha indicates that 365 pages of documentation were developed, 134 error were recorded before the software was released and 29 defects were encountered after release to the customer within the first year of the operation.

  Three people worked on the development of software for project alpha.

• To develop metrics that can be assimilated with similar metrics from other projects, we choose Line of Code as our normalization value.

• So, from information given in table , a set of simple size-oriented metrics can be developed for each projects:

  Errors per KLOC (Thousands line of code)

  Defects per KLOC,

  $ Per KLOC,

  Pages of documentation per KLOC

• Size-oriented metrics are not universally accepted as the best way to measure the software process but most of the controversy swirls around the use line of code as key measure.

• Proponent of line of code measure claims that LOC is an “artefact” of all software development projects that can be easily counted, that many existing software estimation

• models use LOC or KLOC as a key input, and that a large body of literature and data predicated on LOC is already exists.

• On the other hand, opponent argue that LOC measures are programming language dependent, that when productivity is considered, they are short programs, cannot easily accommodate nonprocedural language, and that their use in estimation requires a level of detail that may be difficult to achieve.