Chapter # 7 Software Quality Metrics

Slides:



Advertisements
Similar presentations
OHT 2.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Advertisements

PERTEMUAN - 2 SOFTWARE QUALITY. OBJECTIVES After completing this chapter, you will be able to: ■ Define software, software quality and software quality.
CHAPTER 1 Introduction to SQA.
Software Quality Metrics
OHT 2.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 What is software? Software errors, faults and failures Classification.
SE 450 Software Processes & Product Metrics Software Metrics Overview.
OHT 22.1 Galin, SQA from theory to implementation © Pearson Education Limited Objectives of cost of software quality metrics 2.The classic model.
Components of software quality assurance system overview
OHT 3.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The need for comprehensive software quality requirements Classification.
OHT 7.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software development methodologies: - The software development life cycle.
Software Process and Product Metrics
Galin, SQA from theory to implementation © Pearson Education Limited Chapter 13 CASE Tools and their Effect on Software Quality.
SQA Architecture Software Quality.
OHT 22.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Prof. Mohamed Batouche Costs of software quality Introduction  More and more, commercial companies or public organizations are requiring.
OHT 19.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Controlled documents and quality records Definitions and objectives.
SE513 Software Quality Assurance Lecture04: Contract Review Galin, SQA from Theory to Education Limited 2004.
OHT 3.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
OHT 21.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
CHAPTER 5 Infrastructure Components PART I. 2 ESGD5125 SEM II 2009/2010 Dr. Samy Abu Naser 2 Learning Objectives: To discuss: The need for SQA procedures.
SQA Architecture Software Quality By: MSMZ.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
Quality Assurance ITEC Rick Price. Expectations This course is not purely a lecture course – Classroom participation is a large portion – Everyone.
National Cheng Kung University 軟體品質管理 期末報告 The SQA Unit and Other Actors in the SQA System Reporter: 羅國益 Teacher: 朱治平 Date: 2014/12/30.
OHT 25.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The quality assurance organizational framework Top management’s quality.
Software Metrics - Data Collection What is good data? Are they correct? Are they accurate? Are they appropriately precise? Are they consist? Are they associated.
SE513 Software Quality Control Lecture01: Introduction to Software Quality Assurance Galin, SQA from Theory to Education Limited.
Galin, SQA from Theory to Implementation
Prof. Mohamed Batouche “If you can’t measure it, you can’t manage it” Tom DeMarco,
Software Project Management Lecture # 3. Outline Chapter 22- “Metrics for Process & Projects”  Measurement  Measures  Metrics  Software Metrics Process.
OHT 21.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Software Quality assurance (SQA) SWE 333 Dr Khalid Alnafjan
Lecture 4 Software Metrics
OHT 21.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Objectives of quality measurement Classification of software quality.
OHT 1.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 The uniqueness of software quality assurance The environments for which.
Computing and SE II Chapter 15: Software Process Management Er-Yu Ding Software Institute, NJU.
LESSON 3. Properties of Well-Engineered Software The attributes or properties of a software product are characteristics displayed by the product once.
OHT 15.1 Galin, SQA from theory to implementation © Pearson Education Limited 2004 Templates The contribution of templates to software quality The organizational.
Hussein Alhashimi. “If you can’t measure it, you can’t manage it” Tom DeMarco,
SE513 Software Quality Assurance Lecture10: Documentation and Quality Records Control Galin, SQA from Theory to Education Limited.
M ANAGKEMENT COMPONENTS OF SOFTWARE QUALITY. S OFTWARE QUALITY METRICS Chapter 21.
Chapter 7.2. Continuing:  Factors affecting intensity of SQA activities  Verification, validation and qualification  Development and quality plans.
Swami NatarajanOctober 1, 2016 RIT Software Engineering Software Metrics Overview.
ITIL: Service Transition
Components of software quality assurance system overview
SOFTWARE TESTING Date: 29-Dec-2016 By: Ram Karthick.
Software Configuration Management
Software Quality Control and Quality Assurance: Introduction
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Components of software quality assurance system overview
Software Quality Assurance
Software quality metrics
Software Verification and Validation
SEVERITY & PRIORITY RELATIONSHIP
Software Quality Assurance Software Quality Factor
د. حنان الداقيز خريف /28/2016 Software Quality Assurance ضمان جودة البرمجيات ITSE421 5 – The components of the SQA.
Introduction Edited by Enas Naffar using the following textbooks: - A concise introduction to Software Engineering - Software Engineering for students-
Engineering Processes
Chapter 13 Quality Management
Software metrics.
Chapter # 8 Quality Management Standards
Chapter # 5 Supporting Quality Devices
Chapter # 6 Software Configuration Management
Chapter # 2 Software Quality Factors
Chapter # 4 Development and Quality Plans
Chapter # 3 The Components of SQA
Chapter # 1 Overview of Software Quality Assurance
Integrating quality activities in
Internal Control Internal control is the process designed and affected by owners, management, and other personnel. It is implemented to address business.
Software verification and Validation
Presentation transcript:

Chapter # 7 Software Quality Metrics 435-INFS-3 Software Quality Assurance Chapter # 7 Software Quality Metrics Software Quality Assurance from Theory to Implementation by Daniel Galin Prepared by: S.Hashmi

What is Software Quality Metrics? The word 'metrics' refer to standards for measurements. Software Quality Metrics means measurement of attributes, pertaining to software quality along with its process of development. The term "software quality metrics"illustrate the picture of measuring the software qualities by recording the number of defects or security loopholes present in the software. However, quality measurement is not restricted to counting of defects or vulnerabilities but also covers other aspects of the qualities such as maintainability, reliability, integrity, usability, customer satisfaction, etc.

Software Quality Metrics Main objectives of software quality metrics: (1) To facilitate management control as well as planning and execution of the appropriate managerial interventions. Achievement of this objective is based on calculation of metrics regarding: ■ Deviations of actual functional (quality) performance from planned performance ■ Deviations of actual timetable and budget performance from planned performance. (2) To identify situations that require or enable development or maintenance process improvement in the form of preventive or corrective actions introduced throughout the organization. Achievement of this objective is based on: ■ Accumulation of metrics information regarding the performance of teams, units, Comparison provides the practical basis for management’s application of metrics and for SQA improvement in general.

Continue

continue The metrics are used for comparison of performance data with indicators, quantitative values such as: ■ Defined software quality standards ■ Quality targets set for organizations or individuals ■ Previous year’s quality achievements ■ Previous project’s quality achievements ■ Average quality levels achieved by other teams applying the same development tools in similar development environments ■ Average quality achievements of the organization ■ Industry practices for meeting quality requirements. Software quality metrics – requirements

Classification of software quality metrics Software quality metrics can fall into a number of categories. Here we use a two-level system. The first classification category distinguishes between life cycle and other phases of the software system: ■ Process metrics, related to the software development process ■ Product metrics, related to software maintenance The second classification category refers to the subjects of the measurements: ■ Quality ■ Timetable ■ Effectiveness (of error removal and maintenance services) ■ Productivity ■ KLOC – this classic metric measures the size of software by thousands of code lines. KLOC (thousands of lines of code) is a traditional measure of how large a computer programis or how long or how many people it will take to write it. The code measured is usually source code ■ Function points – a measure of the development resources (human resources) required to develop a program, based on the functionality specified for the software system

Process metrics Software development process metrics can fall into one of the following categories: ■ Software process quality metrics ■ Software process timetable metrics ■ Error removal effectiveness metrics ■ Software process productivity metrics. Software process quality metrics Software process quality metrics may be classified into two classes: ■ Error density metrics ■ Error severity metrics. Example 1. This example demonstrates the calculation of the number of code errors (NCE) and the weighted number of code errors (WCE). A software development department applies two alternative measures, NCE and WCE, to the code errors detected in its software development projects. Three classes of error severity and their relative weights are also defined:  

Continue Error Severity class Relative weight Low severity 1 Medium severity 3 High severity 9 The code error summary for the department’s Atlantis project indicated there were 42 low severity errors, 17 medium severity errors, and 11 high severity errors. Calculation of NCE and WCE gave these results.

Continue ■ Error density Metrics

Continue Example 2. This example follows Example 1 and introduces the factor of weighted measures so as to demonstrate the implications of their use. A software development department applies two alternative metrics for calculation of code error density: CED and WCED. The unit determined the following indicators for unacceptable software quality: CED > 2 and WCED > 4. For our calculations we apply the three classes of quality and their relative weights and the code error summary for the Atlantis project mentioned in Example 1. The software system size is 40 KLOC. Calculation of the two metrics resulted in the following:

Continue Error severity metrics The metrics belonging to this group are used to detect adverse situations of increasing numbers of severe errors in situations where errors and weighted errors, as measured by error density metrics, are generally decreasing. Two error severity metrics are presented in Table 7.2

Software process timetable metrics Software process timetable metrics may be based on accounts of success (completion of milestones per schedule) in addition to failure events (non completion per schedule).

Error removal effectiveness metrics Software developers can measure the effectiveness of error removal by the software quality assurance system after a period of regular operation (usually 6 or 12 months) of the system Error removal effectiveness metrics

Product metrics Product metrics refer to the software system’s operational phase – years of regular use of the software system by customers, whether “internal” or “external” customers, who either purchased the software system or contracted. Process productivity metrics

Continue for its development. In most cases, the software developer is required to provide customer service during the software’s operational phase. Customer services are of two main types: ■ Help desk services (HD) – software support by instructing customers regarding the method of application of the software and solution of customer implementation problems. Demand for these services depends to a great extent on the quality of the user interface (its “user friendliness”) as well as the quality of the user manual and integrated help menus. ■ Corrective maintenance services – correction of software failures identified by customers/users or detected by the customer service team prior to their discovery by customers. The number of software failures and their density are directly related to software development quality. For completeness of information and better control of failure correction, it is recommended that all software failures detected by the customer service team be recorded as corrective maintenance calls.

Continue The array of software product metrics presented here is classified as follows: ■ HD quality metrics ■ HD productivity and effectiveness metrics ■ Corrective maintenance quality metrics ■ Corrective maintenance productivity and effectiveness metrics. It should be remembered that software maintenance activities include: ■ Corrective maintenance – correction of software failures detected during regular operation of the software. ■ Adaptive maintenance – adaptation of existing software to new customers or new requirements. ■ Functional improvement maintenance – addition of new functions to the existing software, improvement of reliability, etc. HD quality metrics The types of HD quality metrics discussed here deal with: ■ HD calls density metrics – the extent of customer requests for HD services as measured by the number of calls.

Continue ■ Metrics of the severity of the HD issues raised. ■ HD success metrics – the level of success in responding to these calls HD calls density metrics Three HD calls density metrics for HD performance are presented

Success of the HD services The most common metric for the success of HD services is the capacity to solve problems raised by customer calls within the time determined in the service contract (availability). Thus, the metric for success of HD services compares the actual with the designated time for provision of these services One metric of this group is suggested here, HD Service Success (HDS): NHYOT HDS = –––––––––– NHYC where NHYOT = number of HD calls per year completed on time during one year of service. HD productivity and effectiveness metrics Productivity metrics relate to the total of resources invested during a specified period, while effectiveness metrics relate to the resources invested in responding to a HD customer call.

Continue HD productivity metrics HD productivity metrics makes use of the easy-to-apply KLMC measure of maintained software system’s size HD effectiveness metrics The metrics in this group refer to the resources invested in responding to customers’ HD calls. One prevalent metric is presented here, HD Effectiveness (HDE): HDYH HDE = ––––––– NHYC Corrective maintenance quality metrics Software corrective maintenance metrics deal with several aspects of the quality of maintenance services Thus, software maintenance metrics are classified as follows:

Continue ■ Software system failures density metrics – deal with the extent of demand for corrective maintenance, based on the records of failures identified during regular operation of the software system. ■ Software system failures severity metrics – deal with the severity of software system failures attended to by the corrective maintenance team. Failures of maintenance services metrics – deal with cases where maintenance services were unable to complete the failure correction on time or that the correction performed failed. ■ Software system availability metrics – deal with the extent of disturbances caused to the customer as realized by periods of time where the services of the software system are unavailable or only partly available Software system failures density metrics The software system failures density metrics presented here relate to the number and/or weighted number of failures. The size of the maintenance tasks is measured by the total number of code lines of the maintained software as well as by the function point evaluation

Software system failures severity metrics Software system failures density metrics

Software system availability metrics User metrics distinguish between: ■ Full availability – where all software system functions perform properly ■ Vital availability – where no vital functions fail (but non-vital functions may fail) ■ Total unavailability – where all software system functions fail. Software system availability metrics

Software corrective maintenance productivity and effectiveness metrics While corrective maintenance productivity relates to the total of human resources invested in maintaining a given software system, corrective maintenance effectiveness relates to the resources invested in correction of a single failure. Software corrective maintenance productivity and effectiveness metrics

Implementation of software quality metrics The application of software quality metrics in an organization requires: ■ Definition of software quality metrics – relevant and adequate for teams, departments, etc. ■ Regular application by unit, etc. ■ Statistical analysis of collected metrics data. ■ Subsequent actions: Changes in the organization and methods of software development and maintenance units and/or any other body that collected the metrics data Change in metrics and metrics data collection Application of data and data analysis to planning corrective actions for all the relevant units. Limitations of software metrics

Continue A unique difficulty faced by use of software quality metrics is rooted in the measures (parameters) that comprise many software quality metrics. As a result, a large proportion of software metrics, including most of the commonly used metrics, suffer from low validity and limited comprehensiveness. Examples of metrics that exhibit severe weaknesses are: ■ Software development metrics that are based on measures such as KLOC, NDE and NCE ■ Product (maintenance) metrics that are based on measures such as KLMC, NHYC and NYF. For example, the KLOC measure is affected by the programming style, the volume of documentation comments included in the code and the complexity of the software. NYF is affected by the quality of the installed software and its documentation as well as the percentage of reused code, among the other factors affecting maintenance

Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level. Process metrics can be used to improve software development and maintenance. Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time. of the fix process Project metrics describe the project characteristics and execution. Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity. Metrics are the means by which the software quality can be measured; they give you confidence in the product. You may consider these product management indicators, which can be either quantitative or qualitative. THANK YOU