Software Metrics Product metricsMeasures metrics and IndicatorsFunction Based metricsProcess and project metricsSoftware measurementsMetrics for software qualitySlid reference : Software Engineering: A Practitioners Approach, 7/e by Roger S. Pressman*

Product Metrics*

McCalls Triangle of Quality*

A Comment*McCalls quality factors were proposed in the early 1970s. They are as valid today as they were in that time. Its likely that software built to conform to these factors will exhibit high quality well into the 21st century, even if there are dramatic changes in technology.

Measures, Metrics and IndicatorsA measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or processThe IEEE glossary defines a metric as a quantitative measure of the degree to which a system, component, or process possesses a given attribute.An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself *

Measurement PrinciplesThe objectives of measurement should be established before data collection begins;Each technical metric should be defined in an unambiguous manner;Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable);Metrics should be tailored to best accommodate specific products and processes *

Measurement ProcessFormulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered.Collection. The mechanism used to accumulate data required to derive the formulated metrics.Analysis. The computation of metrics and the application of mathematical tools.Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation.Feedback. Recommendations derived from the interpretation of product metrics transmitted to the software team.*

Goal-Oriented Software MeasurementThe Goal/Question/Metric Paradigm(1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed(2) define a set of questions that must be answered in order to achieve the goal, and (3) identify well-formulated metrics that help to answer these questions.Goal definition templateAnalyze {the name of activity or attribute to be measured} for the purpose of {the overall objective of the analysis} with respect to {the aspect of the activity or attribute that is considered} from the viewpoint of {the people who have an interest in the measurement} in the context of {the environment in which the measurement takes place}.*

Metrics AttributesSimple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or timeEmpirically and intuitively persuasive. The metric should satisfy the engineers intuitive notions about the product attribute under considerationConsistent and objective. The metric should always yield results that are unambiguous. Consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit. Programming language independent. Metrics should be based on the analysis model, the design model, or the structure of the program itself. Effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product*

Collection and Analysis PrinciplesWhenever possible, data collection and analysis should be automated;Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics Interpretative guidelines and recommendations should be established for each metric*

Metrics for the Requirements ModelFunction-based metrics: use the function point as a normalizing factor or as a measure of the size of the specificationSpecification metrics: used as an indication of quality by measuring number of requirements by type*

Function-Based MetricsThe function point metric (FP), first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.Function points are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexityInformation domain values are defined in the following manner:number of external inputs (EIs)number of external outputs (EOs)number of external inquiries (EQs)number of internal logical files (ILFs)Number of external interface files (EIFs)*

Function Points*

The Fi (i 1 to 14) are value adjustment factors (VAF) based on responses to the following questions.1. Does the system require reliable backup and recovery?2. Are specialized data communications required to transfer information to orfrom the application?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational environment?6. Does the system require online data entry?7. Does the online data entry require the input transaction to be built over multiplescreens or operations?8. Are the ILFs updated online?9. Are the inputs, outputs, files, or inquiries complex?10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in the design?13. Is the system designed for multiple installations in different organizations?14. Is the application designed to facilitate change and ease of use by the user?

Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential). The constant values in FP Equation and the weighting factors that are applied to information domain counts are determined empirically.

0 Not important1 Incidental2 moderate3 average4 significant5 important

Example : SafeHome Three external inputspassword, panic button, and activate/deactivate.Two external inquirieszone inquiry and sensor inquiry. One ILF (system configuration file). Two external outputs (messages and sensor status)Four EIFs (test sensor, zone setting, activate/deactivate, and alarm alert) are also present.

we assume that (Fi) is 46 (a moderately complex product). Therefore,FP =50 [0.65 (0.01 46)] 56

Lord Kelvin said:When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of a science.Process and Project Metrics*

Process metrics are collected across all projects and over long periods of time. Their intent is to provide a set of process indicators that lead to long-term software process improvement. Project metrics enable a software project manager to (1) assess the status of an ongoing project, (2) track potential risks, (3) uncover problem areas before they go critical, (4) adjust work flow or tasks, and (5) evaluate the project teams ability to control quality of software work products.

A Good Manager Measures*processmeasurementWhat do we

use as a

basis?

size?

function?project metricsprocess metricsproductproduct metrics

Process MeasurementWe measure the efficacy of a software process indirectly. That is, we derive a set of metrics based on the outcomes that can be derived from the process. Outcomes include measures of errors uncovered before release of the softwaredefects delivered to and reported by end-userswork products delivered (productivity)human effort expendedcalendar time expendedschedule conformance other measures.

We also derive process metrics by measuring the characteristics of specific software engineering tasks. *

Process Metrics GuidelinesUse common sense and organizational sensitivity when interpreting metrics data.Provide regular feedback to the individuals and teams who collect measures and metrics.Dont use metrics to appraise individuals.Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.Never use metrics to threaten individuals or teams.Metrics data that indicate a problem area should not be considered negative. These data are merely an indicator for process improvement.Dont obsess on a single metric to the exclusion of other important metrics.*

Software Process Improvement*SPIProcess modelImprovement goalsProcess metricsProcess improvementrecommendations

Software Process Improvement

Process MetricsQuality-relatedfocus on quality of work products and deliverablesProductivity-relatedProduction of work-products related to effort expendedStatistical SQA data error categorization & analysisDefect removal efficiency propagation of errors from process activity to activityReuse dataThe number of components produced and their degree of reusability*

Project Metricsused to minimize the development schedule by making the adjustments necessary to avoid delays and mitigate potential problems and risksused to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.every project should measure:inputsmeasures of the resources (e.g., people, tools) required to do the work.outputsmeasures of the deliverables or work products created during the software engineering process.resultsmeasures that indicate the effectiveness of the deliverables.*

Typical Project MetricsEffort/time per software engineering taskErrors uncovered per review hourScheduled vs. actual milestone datesChanges (number) and their characteristicsDistribution of effort on software engineering tasks*

Metrics GuidelinesUse common sense and organizational sensitivity when interpreting metrics data.Provide regular feedback to the individuals and teams who have worked to collect measures and metrics.Dont use metrics to appraise individuals.Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.Never use metrics to threaten individuals or teams.Metrics data that indicate a problem area should not be considered negative. These data are merely an indicator for process improvement.Dont obsess on a single metric to the exclusion of other important metrics.*

Typical Size-Oriented Metricserrors per KLOC (thousand lines of code)defects per KLOC$ per LOCpages of documentation per KLOCerrors per person-montherrors per review hourLOC per person-month$ per page of documentation*

Typical Function-Oriented Metricserrors per FP (thousand lines of code)defects per FP$ per FPpages of documentation per FPFP per person-month*

Comparing LOC and FP*Representative values developed by QSM

ProgrammingLOC per Function point

Languageavg.medianlowhigh

Ada154-104205

Assembler33731591694

C16210933704

C++665329178

COBOL777714400

Java635377-

JavaScript58634275

Perl60

-

--

PL/178

67

22263

Powerbuilder32

31

11105

SAS40

41

3349

Smalltalk26191055

SQL40377110

Visual Basic474216158

Why Opt for FP?Programming language independentUsed readily countable characteristics that are determined early in the software processDoes not penalize inventive (short) implementations that use fewer LOC that other more clumsy versionsMakes it easier to measure the impact of reusable components*

Measuring QualityCorrectness the degree to which a program operates according to specificationMaintainabilitythe degree to which a program is amenable to changeIntegritythe degree to which a program is impervious to outside attackUsabilitythe degree to which a program is easy to use*

Defect Removal Efficiency*where:E is the number of errors found before delivery of the software to the end-user D is the number of defects found after delivery.

DRE = E /(E + D)