Sof Quality
-
Upload
rupinder-rp -
Category
Documents
-
view
220 -
download
0
Transcript of Sof Quality
-
7/31/2019 Sof Quality
1/35
1 Compiled by Rohitashcse final year
Software Quality
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.
-
7/31/2019 Sof Quality
2/35
2
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 duringmanufacturing
This focuses on how well the implementation follows the design and how wellthe resulting system meets its requirements
Quality also can be looked at in terms of user satisfaction
User satisfaction = compliant product+ good quality+ delivery within budget and schedule
-
7/31/2019 Sof Quality
3/35
8/12/2012 3 Compiled by RohitashCse final year
Software Quality Attributeshttp://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html
http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.htmlhttp://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html -
7/31/2019 Sof Quality
4/35
4
The Cost of Quality
Includes all costs incurred in the pursuit of quality or in performingquality-related activities
Is studied to
Provide a baseline for the current cost of quality.
Identify opportunities for reducing the cost of quality. Provide a normalized basis of comparison .
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."
-
7/31/2019 Sof Quality
5/35
5
Kinds of Quality Costs
Prevention costs
Quality planning, formal technical reviews, test equipment, training
Appraisal costs
Inspections, equipment calibration and maintenance, testing
Failure costssubdivided into internal failure costs and externalfailure costs
Internal failure costs
Incurred when an error is detected in a product prior to shipment
Include rework, repair, and failure mode analysis
External failure costs Involves defects found after the product has been shipped
Include complaint resolution, product return and replacement, help linesupport, and warranty work
-
7/31/2019 Sof Quality
6/35
Software Quality Costs There is a price to pay for quality. (Quality is not Free)
Types of software quality costsCost of Quality Approach:
Prevention: Avoiding defects, planning, preparation, training, reviews, tool costs.
Quality Assurance prevents the injection of various types of defects.
Appraisal: Finding defects by inspection, audit, developing test cases, test and
measurement.
Internal Failure: Costs emerging during development. Rework, redesign, modifications,
corrective action, down time, concessions and overtime.
External Failure: Costs emerging from a failure at the customer: Equipment failure, loss of
sales, downtime, administrative cost in dealing with failure, law costs, loss of reputation.
-
7/31/2019 Sof Quality
7/35
Cost of
software
quality
Prevention
costs
Appraisal costs
Internal failure
costs
External failure
costs
Costs of
Control costs
Costs ofFailure of
control costs
The classic model of cost of softwarequality
Feigenbaums Model
7
-
7/31/2019 Sof Quality
8/35
Software Reviews
-
7/31/2019 Sof Quality
9/35
9 Compiled by rohitashCse final year
Software reviews
4.6.1 Purpose
4.6.2 Minimum requirements 4.6.2.1 Software specifications review (SSR)
4.6.2.2 Architecture design review (ADR)
4.6.2.3 Detailed design review (DDR) 4.6.2.4 Verification and validation plan review
4.6.2.5 Functional audit
4.6.2.6 Physical audit
4.6.2.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.6.2.8 Managerial reviews
4.6.2.9 Software configuration management plan review (SCMPR)
4.6.2.10 Post-implementation review
4.6.3 Other reviews and audits
-
7/31/2019 Sof Quality
10/35
10
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, design, coding, and testing activities
Catch large classes of errors that escape the originator more than otherpractitioners
Include the formal technical review (also called a walkthrough orinspection)
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, and theorganization to cover the costs
-
7/31/2019 Sof Quality
11/35
Defects and failures
Not all software defects are caused by
coding errors.
Expensive reason may be requirement gaps
non-functional requirements
testability
scalability.
11
-
7/31/2019 Sof Quality
12/35
Contd
Maintainability
Usability
performance
security
12
-
7/31/2019 Sof Quality
13/35
defect-fault-failure
Software faults occur through the following
processes:
13
EXECUTED INCERTAIN SITUATION
-
7/31/2019 Sof Quality
14/35
Not all defects will necessarily result in
failures.
E.g:- defects in dead code will never result
in failures.
A single defect may result in a wide range
of failure symptoms.
14
-
7/31/2019 Sof Quality
15/35
Cost of faults
The cost of software faults that are not
detected before a system is put into live
operation varies, depending on a number offactors.
Example- the European Space Agencys
Ariane5 rocket exploded.
15
-
7/31/2019 Sof Quality
16/35
16
-
7/31/2019 Sof Quality
17/35
Classification of defects
Severity Wise:
Major: A defect, which will cause an
observable product failure or departure fromrequirements.
Minor: A defect that will not cause a
failure in execution of the product. Fatal: A defect that will cause the system to
crash or close abruptly or effect other
applications. 17
-
7/31/2019 Sof Quality
18/35
Work product wise
SSD: A defect from System Study
document
FSD: A defect from FunctionalSpecification document
ADS: A defect from Architectural Design
Document
DDS: A defect from Detailed Design
document18
-
7/31/2019 Sof Quality
19/35
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
-
7/31/2019 Sof Quality
20/35
Facts about defect rate
In a study conducted at Hewlett Packard,
Lim [LIM94] reports that the defect rate for
reused code is 0.9 defects per KLOC, whilethe rate for newly developed software is 4.1
defects per KLOC. For an application that
was composed of 68 percent reused code,the defect rate was 2.0 defects per KLOC
20
-
7/31/2019 Sof Quality
21/35
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 repair20
-
7/31/2019 Sof Quality
22/35
Measurement scales
Nominal Scale
This is the most primitive form of measurement. A scale is a
nominal one if it divides the set of entities into
categories, with no particular ordering among them [10].
E.g. IEEE 802.1, 802.2, 802.3802.11.
Ordinal Scale
A scale is an ordinal one if it divides the set of entities intocategories that are ordered according to some order
. There is no quantitative comparison.
E.g. programmer skill (low, medium, high).
22
-
7/31/2019 Sof Quality
23/35
Measurement scales
Interval Scale
This scale captures information about the
size of the intervals that separate classes. Inan interval scale, the
exact difference between two values is the
basis for meaningful statements.
E.g. programmer capability between: 60th
and 80th percentile of population23
-
7/31/2019 Sof Quality
24/35
Measurement scales
Ratio Scale
A measurement mapping that preserves ordering, the size of intervals
between entities, and ratios between
entities In a ratio scale, contrary to interval scale, there is an absolute andnon arbitrary zero point .
E.g. project A took twice as long as project B
Absolute Scale
Absolute scale is the most informative in the measurement scalehierarchy. In absolute scale, measurement
is done by counting method.
E.g. number of failures observed during integration testing can be
measured only by counting the number of
failures observed. 24
-
7/31/2019 Sof Quality
25/35
Inspection process
Inspection refers to peer review of any
work product by trained individuals who
look for defects using a well definedprocess.
The goal of the inspection is for all of the
inspectors to reach consensus on a workproduct and approve it for use in the project.
25
-
7/31/2019 Sof Quality
26/35
Inspection process stages
Planning: The inspection is planned by the
moderator.
Overview meeting: The author describesthe background of the work product.
Preparation: Each inspector examines the
work product to identify possible defects.
Inspection meeting: During this meeting
the reader reads through the work product,
part by part and the inspectors point out the
defects for ever art.26
-
7/31/2019 Sof Quality
27/35
Inspection process stages
Rework: The author makes changes to the
work product according to the action plans
from the inspection meeting. Follow-up: The changes by the author are
checked to make sure everything is correct.
27
-
7/31/2019 Sof Quality
28/35
282828
What are Metrics?
Software process and project metrics are quantitativemeasures
They offer insight into the effectiveness of the softwareprocess 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,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
-
7/31/2019 Sof Quality
29/35
29
Product Metrics
Help software engineers to better understand the attributes ofmodels and assess the quality of the software
Help software engineers to gain insight into the design andconstruction of the software
Focus on specific attributes of software engineering workproducts resulting from analysis, design, coding, and testing
Provide a systematic way to assess quality based on a set ofclearly defined rules
Provide an on-the-spot rather than after-the-fact insightinto the software development
-
7/31/2019 Sof Quality
30/35
Classes of product metric
Dynamic metrics which are collected by measurements made of a
program in execution;
Static metrics which are collected by measurements made of thesystem representations;
Dynamic metrics help assess efficiency (response time of a
system) and reliability (no of failures); static metrics help assess
complexity, understandability and maintainability.
30
-
7/31/2019 Sof Quality
31/35
Examples of Product Metrics
Number and type of defects found during
requirements, design, code, 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
-
7/31/2019 Sof Quality
32/35
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 ofintegration testing
Total number of bugs found as a result of
validation testing
Productivity, as measured by KLOC per person-
hour
32
-
7/31/2019 Sof Quality
33/35
Process metrics
A metric used to measure characteristics of the methods,techniques, and tools employed in developing,implementing, and maintaining a software system
Private process metrics are known only to the individual or team concerned.
Public process metrics
enable organizations to make strategic changes to improve thesoftware process.
33
-
7/31/2019 Sof Quality
34/35
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
-
7/31/2019 Sof Quality
35/35
35