Key Software Metrics Identified by Galorath

Introduction

This page categorizes, lists, and defines the software metrics that Galorath has identified as being the most useful for monitoring and controlling projects.

Size Metrics

Size metrics measure the magnitude of the product being developed in the project.

Source Lines of Code (SLOC)

The following table describes in detail precisely what is and is not included in a SLOC count. For each logical line of code,

Include: All executable lines.
Include: Non-executable declarations and compiler directives.
Exclude: Comments, banners, blank lines, and non-blank spacers.

Also, look at the means by which a line was produced,

Include: Manually programmed lines.
Include: Lines developed by the developer for use with a Source Code Generator.
Exclude: Lines generated as output from a Source Code Generator.
Include: Lines converted with automated code translators. However, these lines should be entered as pre-existing code. The user will then define how much rework must be done on the translated code through the use of rework percentages.
Include: Copied, reused, or modified lines of code. Again, these lines should be entered as pre-existing lines of code.
Exclude: Deleted lines of code.

Furthermore, look at the origin of each line:

Include: New lines developed from scratch
Include: Pre-existing lines taken from a prior version, build, or release
Include: Invocation statements or lines considered for rework evaluation from COTS or other off the shelf packages. The user should define the level of rework required for those lines which will be modified in any way.
Include: Invocation statements only for unmodified vendor supplied or special support libraries.
Include: Modified vendor supplied or special support libraries, commercial libraries, reuse libraries, or other software component libraries. The user should define the level of rework required for those lines which will be modified in any way.
Exclude: Lines which are part of an unmodified vendor supplied operating system or utility or other non-developed code.

Lastly, consider the end usage of each line:

Include: Lines which are in or part of the primary product
Include: Lines which are external to or in support of the primary product, only if they are deliverable.
Exclude: Lines which are external to or in support of the primary product, but are not deliverable, or any other non-deliverable lines.

Function Point

A Function Point is a measure of business functionality delivered to a user by an information system. It is defined by IFPUG, the International Function Point Users Group, and several ISO standards.

Story Point

A Story Point is a measure of the effort required to implement a user story in Scrum Agile projects. Story points are measured in units defined by the development team as a reflection of their own capability, or team velocity, and therefore should not be directly compared across teams. However, if an Agile team has a constant team velocity, the story points can be related to person-hours of effort

Schedule Metrics

Schedule metrics measure the duration of the project. Schedules are not unique to software projects, so definitions from [[http://pmi.org][PMI], the Project Management Institute, could be used.

In SEER-SEM, project duration is measured from the start of software requirements to the end of "operational test and evaluation", i.e., just up to installation or production of the finished system. The concept stage is not included nor, for hardware-integrated systems, is hardware integration.

Effort Metrics

Effort metrics measure the amount of labour expended in the project. Effort is not unique to software projects, so definitions from [[http://pmi.org][PMI], the Project Management Institute, could be used.

In SEER-SEM, effort refers to the amount of total labor or work involved with a certain task. This value is typically measured in units of person months. For example, a task which will take one person ten months to complete represents ten person months of effort. Another task which will take ten people one month also represents ten person months of effort.

Quality Metrics

Quality metrics measure the characteristics of the defect injection and removal processes used in the project, the latent defects in the product being developed and its subsequent reliability.

SEER-SEM defines a software defect as any condition where the software does not behave as it was designed to behave. This could be an unexpected program or system termination, failure to operate at all, failure to produce output, incorrect output, or any situation where the software does not behave correctly. Each individual defect is only counted once regardless of how many times it appears in the program output. For example, if a single internal calculation which appears in several outputs is incorrect the failure is counted as a single defect. Defects can be often be correlated to test procedure failures or program change requests. However, in both cases, care must be used in applying these definitions. For example, a single defect can cause many test procedure failures, and program change requests can be generated from changes in user requirements as well as from software defects.

SEER-SEM estimates only delivered defects which have escaped detection during the test phase and still remain in the program when it is delivered to the end customer.

Comments

Enter your comments here: