This action might not be possible to undo. Are you sure you want to continue?
• The degree to which a system, component, or process meets specified requirements. • The degree to which a system, component or process meets customer or user needs or expectations.
Compiled by Rohitash cse final year
Quality Defined (continued)
• Two kinds of quality are sought out
– Quality of design
• The characteristic that designers specify for an item • This encompasses requirements, specifications, and the design of the system
– Quality of conformance (i.e., implementation)
• The degree to which the design specifications are followed during manufacturing • This focuses on how well the implementation follows the design and how well the resulting system meets its requirements
User satisfaction = compliant product + good quality + delivery within budget and schedule
Software Quality Attributes
Compiled by Rohitash Cse final year
– Identify opportunities for reducing the cost of quality. • Involves various kinds of quality costs (See next slide) • Increases dramatically as the activities progress from – Prevention Detection Internal failure External failure "It takes less time to do a thing right than to explain why you did it wrong. – Provide a normalized basis of comparison .The Cost of Quality • Includes all costs incurred in the pursuit of quality or in performing quality-related activities • Is studied to – Provide a baseline for the current cost of quality." 4 .
formal technical reviews. and warranty work 5 . repair. and failure mode analysis – External failure costs • Involves defects found after the product has been shipped • Include complaint resolution. testing • Failure costs – subdivided into internal failure costs and external failure costs – Internal failure costs • Incurred when an error is detected in a product prior to shipment • Include rework.Kinds of Quality Costs • Prevention costs – Quality planning. product return and replacement. training • Appraisal costs – Inspections. test equipment. equipment calibration and maintenance. help line support.
developing test cases. planning. administrative cost in dealing with failure. training.Software Quality Costs • There is a price to pay for quality. concessions and overtime. Rework. corrective action. law costs. External Failure: Costs emerging from a failure at the customer: Equipment failure. downtime. Quality Assurance prevents the injection of various types of defects. Appraisal: Finding defects by inspection. test and measurement. Internal Failure: Costs emerging during development. preparation. (Quality is not Free) • Types of software quality costs – Cost of Quality Approach: • • • • Prevention: Avoiding defects. audit. tool costs. modifications. loss of reputation. reviews. . loss of sales. down time. redesign.
The classic model of cost of software quality Feigenbaum’s Model Costs of Control costs Cost of software quality Costs of Failure of control costs Internal failure costs Prevention costs Appraisal costs External failure costs 7 .
Software Reviews .
6.6.5 Functional audit 184.108.40.206.6.3 Other reviews and audits 9 Compiled by rohitash Cse final year .2.6.8 Managerial reviews 4.Software reviews • • 4.2.6 Physical audit 220.127.116.11 Software configuration management plan review (SCMPR) 18.104.22.168.22.214.171.124.6.3 Detailed design review (DDR) 4.4 Verification and validation plan review 4.2 Minimum requirements – – – – – – – 4.6.7 In-process audits • • • • a) Code versus design documentation b) Interface specifications (hardware and software) c) Design implementations versus functional requirements d) Functional requirements versus test descriptions – – – – 4.1 Purpose 4.6.2 Architecture design review (ADR) 4.1 Software specifications review (SSR) 4.10 Post-implementation review 4.2.2.
and the organization to cover the costs 10 . design.Purpose of Reviews • • • • • Serve as a filter for the software process Are applied at various points during the software process Uncover errors that can then be removed Purify the software analysis. and testing activities Catch large classes of errors that escape the originator more than other practitioners • Include the formal technical review (also called a walkthrough or inspection) – – – – Acts as the most effective SQA filter Conducted by software engineers for software engineers Effectively uncovers errors and improves software quality Has been shown to be up to 75% effective in uncovering design flaws (which constitute 50-65% of all errors in software) • Require the software engineers to expend time and effort. coding.
11 .Defects and failures • Not all software defects are caused by coding errors. • Expensive reason may be requirement gaps • non-functional requirements • testability • scalability.
Cont’d • • • • Maintainability Usability performance security 12 .
defect-fault-failure • Software faults occur through the following processes: EXECUTED IN CERTAIN SITUATION 13 .
• Not all defects will necessarily result in failures.defects in dead code will never result in failures.g:. • A single defect may result in a wide range of failure symptoms. 14 . • E.
• Example. depending on a number of factors.Cost of faults • The cost of software faults that are not detected before a system is put into live operation varies.the European Space Agency’s Ariane5 rocket exploded. 15 .
Classification of defects • Severity Wise: Major: A defect. • Fatal: A defect that will cause the system to crash or close abruptly or effect other 17 applications. which will cause an observable product failure or departure from requirements. . • Minor: A defect that will not cause a failure in execution of the product.
Work product wise • SSD: A defect from System Study document • FSD: A defect from Functional Specification document • ADS: A defect from Architectural Design Document • DDS: A defect from Detailed Design document 18 .
• Source code: A defect from Source code • Test Plan/ Test Cases: A defect from Test Plan/ Test Cases • User Documentation: A defect from User manuals. Operating manuals 19 .
1 defects per KLOC.0 defects per KLOC 20 .9 defects per KLOC. Lim [LIM94] reports that the defect rate for reused code is 0. the defect rate was 2. while the rate for newly developed software is 4.Facts about defect rate • In a study conducted at Hewlett Packard. For an application that was composed of 68 percent reused code.
Software Reliability • Defined as the probability of failure free operation of a computer program in a specified environment for a specified time. • It can measured. directed and estimated • A measure of software reliability is mean time between failures where • MTBF = MTTF + MTTR • MTTF = mean time to failure • MTTR = mean time to repair 20 .
g. programmer skill (low. 802. 22 . medium. A scale is a nominal one if it divides the set of entities into categories. 802.3…802. There is no quantitative comparison. high).2. • – E.1. IEEE 802. with no particular ordering among them .11.Measurement scales • Nominal Scale This is the most primitive form of measurement. • Ordinal Scale A scale is an ordinal one if it divides the set of entities into categories that are ordered according to some order . – E.g.
– E.Measurement scales • Interval Scale – This scale captures information about the size of the intervals that separate classes. In an interval scale.g. the exact difference between two values is the basis for meaningful statements. programmer capability between: 60th and 80th percentile of population 23 .
Measurement scales • Ratio Scale A measurement mapping that preserves ordering. 24 . In absolute scale. project A took twice as long as project B • Absolute Scale Absolute scale is the most informative in the measurement scale hierarchy. – E.g. number of failures observed during integration testing can be measured only by counting the number of failures observed. there is an absolute and non arbitrary zero point . the size of intervals between entities. measurement is done by counting method. and ratios between entities In a ratio scale. contrary to interval scale.g. – E.
Inspection process • Inspection refers to peer review of any work product by trained individuals who look for defects using a well defined process. • The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. 25 .
• Overview meeting: The author describes the background of the work product. • Preparation: Each inspector examines the work product to identify possible defects.Inspection process stages • Planning: The inspection is planned by the moderator. . part by part and the inspectors point out the 26 defects for every part. • Inspection meeting: During this meeting the reader reads through the work product.
27 . • Follow-up: The changes by the author are checked to make sure everything is correct.Inspection process stages • Rework: The author makes changes to the work product according to the action plans from the inspection meeting.
and assessed • The goal is to determine whether quality and productivity improvements have occurred • Remedies can then be developed and the software process can be improved 28 .What are Metrics? • Software process and project metrics are quantitative measures • They offer insight into the effectiveness of the software process and the projects that are conducted using the process as a framework • Basic quality and productivity data are collected • These data are analyzed. compared against past averages.
Product Metrics • Help software engineers to better understand the attributes of models and assess the quality of the software • Help software engineers to gain insight into the design and construction of the software • Focus on specific attributes of software engineering work products resulting from analysis. design. and testing • Provide a systematic way to assess quality based on a set of clearly defined rules • Provide an “on-the-spot” rather than “after-the-fact” insight into the software development 29 . coding.
• Classes of product metric – Dynamic metrics which are collected by measurements made of a program in execution. – Dynamic metrics help assess efficiency (response time of a system) and reliability (no of failures). 30 . understandability and maintainability. static metrics help assess complexity. – Static metrics which are collected by measurements made of the system representations.
and test inspections • Number of pages of documentation delivered • Number of new source lines of code created • Number of source lines of code delivered • Total number or source lines of code delivered • Average complexity of all modules delivered 31 . code.Examples of Product Metrics • Number and type of defects found during requirements. design.
as measured by KLOC per personhour 32 .• Average size of modules • Total number of modules • Total number of bugs found as a result of unit testing • Total number of bugs found as a result of integration testing • Total number of bugs found as a result of validation testing • Productivity.
implementing. and maintaining a software system • Private process metrics – are known only to the individual or team concerned. and tools employed in developing. techniques. • Public process metrics – enable organizations to make strategic changes to improve the software process. 33 .Process metrics • A metric used to measure characteristics of the methods.
Examples of Process Metrics • • • • • Average find-fix cycle time Number of person-hours per inspection Number of person-hours per KLOC Average number of defects found per inspection Number of defects found during inspections in each defect category • Average amount of rework time • Percentage of modules that were inspected 34 .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.