Mumbai University > Information Technology > Sem 8 > Software Testing and Quality Assurance

Marks: 10 Marks

Difficulty : Medium

Measurement are a key element for controlling software engineering processes. By controlling it meant that one access the status of the process, observe the trends to what is likely to happen and take corrective action for modifying our practices. Measurements improve our processes by modifying the activities based on different measures –

Understanding – metrics help in making the aspect of processes more visible, thereby giving better understanding of relationships among the activities and entities they Control – using baselines, goals we can predict what is likely to happen and make appropriate changes in process to help meet the goals. Improvement – By taking corrective actions and make appropriate changes, we can improve a product. Based on the analysis of a project, a process can be improved.

Classification of software metrics.

The software metrics can be classified as follows:

1. Product vs. process metrics. Software metrics may be broadly classified as either product metrics or process metrics. Product metrics are measures of the software product at any stage of its development, from requirements to installed system. Product metrics may measure the complexity of the software design, the size of the final program of the number of pages of documentation produced. Process metrics are measures of the software development process, such as the overall development time, type of methodology used, or average level of experience of programming staff.

2. Objective vs. subjective metrics. Objective measures should always result in identical values for a given metric, as measured by two or more qualified observers. For subjective measures, even qualified observers may measure different values for a given metric. For example, for product metrics, the size of product measured in line of code is an objective measure. In process metrics, the development time is an example of objective measure, where the level of a programmer’s experience is likely to be a subjective measure.

3. Primitive vs. computed metrics. Primitive metrics are those metrics that can be directly observed, such as the program size in LOC, the number of defects observed in unit testing, or the total development time for the project. Computed metrics are those that cannot be directly observed but are computed in some way from other metrics. For example, productivity metrics like LOC produced per person month or product quality like defects per thousand LOC.

4. Private vs. public metrics. This classification is based on the use of different types to process data. It is natural that individual software engineers might be sensitive to the use of metrics collet on an individual basis, and therefore these data should be private to individuals and serve as an indicator for individual only. Examples of private metrics include defect rates and errors found during development.

Public metrics assimilate information that originally was private to individual’s and teams. Project level defect rate effort, calendar times and related data are collected and evaluated in an attempt to uncover indicators that can improve organizational process performance.