Quality Management

Software Metrics -quantitative way to access the quality Software Quality and Metrics There are number of conditions that a quality must meet link between the quality criterion that it seeks to measure. Be sensitive to the different degrees of the criterions. Provide objective determination of the criterion.

Quality Management
SOFTWARE METRICS Predictive Descriptive Eg: Structuredness is made to predict the main ability of the software product in use. Reliability metric is based on the number of system crashes "during the given period.

Quality Management
McCall Structuredness metric =n01 / ntot Where,n01=number of models containing one or zero exit point only ntot =total number of modules

Requirements to Effective SW Metrics

Simple and computable Empirically and intuitively persuasive Consistent and Objective Consistent in its use of units and dimensions Programming language independent An effective mechanism for quality feedback

SW METRICS MAIN AREAS

Metrics for Analysis Model Metrics for Design Model Metrics for Source Code Metrics for Testing

Good Metric
Objectivity Reliability Validity Standardization Comparability Economy Usefulness Consistency

Classification of Metrics According to the fundamental property

Readability as the measure of usability
Flesh-Kincaid Readability Index
Grade Level = 0.39a+b-c a= the no of words in the sentence b= the mean no of syllables per 100 words c=15.59

Fog Index=0.4a+b
a=the no of words in the sentence b=the percentage of words with more than two syllables

Classification of Metrics According to the fundamental property

Error Prediction as the measure of correctness Halstead & Ottenstein
No of operators No of operands

Classification of Metrics According to the fundamental property

Error detection as the measure of correctness Remus & Zilles
No of detected errors & error detection efficiency to detect undetected errors No of defects length of program

Classification of Metrics According to the fundamental property

Mean time to failure(MTTF)as the measure of reliability
MTTF=Ttot /Rt
Ttot total no of period

Rt - no of failures in period Ttot

R=exp(-tTOP/tp)
R- reliability tTOP=Length of operation phase tp=current MTTF

Classification of Metrics According to the fundamental property

Complexity as measure of reliability
McCabe using cyclomatic number

Complexity as measure of maintainability

Classification of Metrics According to the fundamental property

Readability of code as a measure of maintainability
Statement of lines Average length of variable names Total no of program branches

Classification of Metrics According to the fundamental property

Modularity as a measure of maintainability
Increased modularity increase maintainability Yau & collofello stability as no of modules affected by modification Kentger defined four level hierarchy of module types
Control modules Problem-oriented modules Management modules for abstract data Realization modules of abstract data

Classification of Metrics According to the fundamental property

Testability as the measure of maintainability

SOFTWARE METRICS FOR PROCESS AND PROJECTS

Quantitative measures to gain insight of the efficiency Quality & Productivity data collected, analyzed & compared with previous results WHO DOES IT?
Collection Software Engineers/Practitioner Analysis - Software Managers

SOFTWARE METRICS FOR PROCESS AND PROJECTS

WHY METRICS IS IMPORTANT? WHAT ARE THE STEPS?
Defining process & projects Results analyzed & compared with previous Trends are assessed & Conclusions generated

SOFTWARE METRICS FOR PROCESS AND PROJECTS

Reasons for measuring
To characterize To evaluate To predict To improve

SOFTWARE METRICS FOR PROCESS AND PROJECTS

Project metrics enables Project Managers to
Assess the status Track potential risks Find problem areas Adjust workflow Evaluate project teams ability

SOFTWARE METRICS FOR PROCESS

Rational way to improve any process
Measure specific attributes Develop a set of metrics Use metrics to provide indicator that lead to improvement

PRODUCT

Customer characteristics

Business Conditions

PROCESS

Development envt PEOPLE TECHNOLOGY

Outcome include measures of

Errors uncovered before release Defects delivered to & reported by end users Work products delivered Human effort expended Calendar time expended Schedule conformance

SOFTWARE METRICS ETIQUETTE

Use common sense & organizational sensitivity when interpreting metrics Provide regular feedback Do not use metrics to appraise individual Work with practitioners & teams to set goals & metrics Never use metrics to threaten individuals Metrics indicate area for process improvement Do not obsess on a single metric

Statistical software process improvement(SSPI)

Rigorous approach for process improvement by using process metrics Software failure analysis

Software Project Metrics

Estimation Effort & Time estimation from past projects Effort & time actually spent are compared with estimates Project manager control & monitor progress

Purpose of Project Metrics

Minimize the project development schedule Asses product quality on an ongoing basis

Applications of Project Metrics

During Estimation
Estimate effort & time

During Project Proceeding

Actual effort & time taken is compared

As Technical work commences

Production rates Review hours Function points Delivered Line of Source Codes

Software Measurement
Direct Measurement
Process
Cost & effort applied

Product
LOC Execution speed Memory size Defect reported over a period of time

Software Measurement
Indirect Measurement
Functionality Quality Complexity Efficiency Reliability Maintainability

Size Oriented Metrics

Errors/KLOC Defect/KLOC Cost/KLOC Page of Document/KLOC Other Metrics
Errors / Person month LOC / Person month Cost / Pages of Dcumentation

Function Oriented Metrics

Measure of functionality Function Point(FP) Computed by completing FIVE INFORMATION DOMAIN CHARACTERISTICS FIVE INFORMATION DOMAIN CHARACTERISTICS
No of Inputs No of Outputs No of user Enquiries No of Files No of External interfaces

Function Oriented Metrics

ERROR / FP DEFECTS /FP COST / FP PAGES / FP FP / PERSON MONTH Average no LOC to build FP is
C C++ VB SQL 128 64 32 12

OBJECT ORIENTED PROJECT METRICS

No. of Scenario Scripts No. of Key Classes No. of Support Classes Average No. of Support classes / Key Classes No. of Sub systems USE CASE ORIENTED METRICS User visible functions Independent of programming languages No of usecases size of appn