o Syllabus
o Introduction
Unit Contents
1. Software Quality Assurance Framework: What is
Quality? Software Quality Assurance, Components of
Software Quality Assurance, Software Quality
Assurance Plan. Steps to develop and implement a
Software Quality Assurance Plan.
Unit Contents
2. Quality Standards: ISO 9000 and Comparison ISO
Standards, CMM, CMMI, PCMM, Malcolm Balridge,
3 Sigma, 6 Sigma, Software Quality Models.
Unit Contents
3. Measurement in Software Engineering: scope of software
metrics, Basics of Measurement: Measuring External
Product Attributes: Modeling Software Quality, Measuring
aspects of quality, Framework for Software Measurement,
Measuring Internal Product Attributes, Size and Structure:
Aspects of Software Size, Length, Reuse, Functionality,
Complexity, Types of Structural Measures, Modularity and
information flow attributes.
Unit Contents
4. Software Quality Assurance Metrics and
Measurement: Software Quality Metrics, Product
Quality Metrics, Process Quality Metrics, Metrics for
Software Maintenance, Software Quality Metrics
methodology, Object Oriented Metrics in quality.
Unit Contents
5. Software Quality Estimation Tools:
.
Desirable features 1n software quality
estimation tools, Study of some existing
tools for quality estimation.
Unit Contents
6. Computer Aided Quality Engineering
(CAQE) Concepts, Design Techniques
for CAQE.
o Software metrics and anti-patterns.
o Design generation, design representation, and
heuristics for good design.
o Dynamic software verification: unit, integration,
regression, and acceptance testing.
o Static software verification: reviews, walk
throughs.
o Standard representations for requirements, such
as user stories and interaction prototypes.
o References:
- Pressman Roger S, Software Engineering:
A Practitioner's Approach, 81h Edition,
McGraw Hill. ISBN-13: 978-0071267823
o References:
- Software Metrics, Fenton, CRC press
- Yogesh Singh & Ruchika Malhotra, "Object
Oriented Software Engineering", 1st Ed., PHI
Learning.
o What is software quality?
o How can it be measured?
- How can it be measured before/after the software
is delivered?
Think of an everyday object
-e.g. a chair
-How would you measure it's "quality"?
. construction quality? (e.g. strength of
the joi nts,...)
· aesthetic value? (e.g. elegance,...)
. fit for purpose? (e.g. comfortable,...)
· All quality measures are relative
- there is no absolute scale
- we can say A is better than B but it is
usually hard to say how much better
o Worki ng and living
• Cost of utilities for the month
• Cost of groceries for the month
• Amount of monthly rent per month
• Time spent at work each Saturday for
the past month
• Time spent mowing the lawn for the
past two times
o College experience
• Grades received in class last semester
• Number of classes taken each semester
• Amount of time spent in class this week
• Amount of time spent on studying and
homework this week
• Number of hours of sleep last night
o Travel
• Cost of utilities for the month
• Time to drive from home to
the airport
• Amount of miles traveled today
• Cost of meals and lodging for
yesterday
o Conformance to requirements.
o Narrowest sense of software quality.
· Lack of bugs.
· High reliability (number of failures per n hours
of operation).
According to IEEE, Software quality is
o The degree to which a system, component, or
process meets specific requirements.
o The degree to which a system, component, or
process meets customer or user needs or
expectations.
o Definition:
Conformance to explicitly stated
functional and performance requirements,
explicitly documented development
standards , and implicit characteristics that
are expected of all professionally
developed software.
For example, if two cars meet their specified
speed, standard, style, and performance, then
they are said to meet the specified
requirements.
o Three important points in the
definition
• Explicit software reguirements are the
foundation from which quality is
measured.
• Lack of conformance to requirements
is lack of quality.
o Three important points in the definition
• Specific standards define a set of
development criteria that guide the manner in
which software is engineered. If the criteria
are not followed, lack of quality will most
surely result.
o Three important points in the definition
• There is a set of implicit reguirements that
often goes unmentioned (e.g., ease of use).
If software conforms to its explicit
requirements but fails to meet implicit
requirements, software quality is suspect.
o The goal of software quality is to determine:
0
How well is the design of the software?
0
How the software conforms to
the developed design?
o The attribute domains that are required
for a given software are:
• Functionality
• Usability
• Testability
• Reliability
• Maintainability
• Adaotabilitv
Functionality Us.ability Testability
_.,.. -Learnability
Completeness
Vedfiabdity
Operillhi liy
Correctne:ss
Efficiency User-fri.endIiness Valid.atable
Traceabili t-y Installabi lity
Security Satisfaction
software
quality
Agility anributes
-Modifiability Portability
&cadability lnteropcrabili ty
Fllexibilit.y
Reliability Maintainab lity AdapUibility
Functionality: The degree to which the purpose
of the software is satisfied.
1 Completeness The deg ree to w hich softwa
re is comp lete.
2 Correctness The degree to which software is
correct.
Functionality: The degree to which the purpose
of the software is satisfied.
3 Efficiency The degree to which the software
requires resources to perform a
software function.
4 Traceability The degree to which requirement
is traceable to software design and
source code.
Functionality: The degree to which the purpose
of the software is satisfied.
5 Security The degree to which the software is
able to prevent unauthorized
access to the proqram data.
Usability: The degree to which the software is
easy to use.
1 Learnability The degree to which the software
is easy to learn.
2 Operability The degree to which the software
is easy to operate.
Usability: The degree to which the software is
easy to use.
3 User The degree to which the interfaces of
friendliness the software are easy to use and
understand.
4 Installability The degree to which the software is
easy to install.
Usability: The degree to which the software is
easy to use.
5 Satisfaction Thedegree to which the
user's feel satisfied with the
software.
Testability: The ease with which the
software can be tested to demonstrate
the faults.
1 Verifiability The degree to which the
software deliverable meets
the specified standards ,
procedures and process.
Testability: The ease with which the
software can be tested to demonstrate
the faults.
2 Validatable The ease with which the
software can be executed to
demonstrate whether the
established testing criteria
is met.
Maintainability: The ease with which
the faults can be located and fixed,
quality of the software can be improved
or software can be modified in the
maintenance
1Agility The degree to which the software
is uick to chan e or modif .
Maintainability: The ease with which
the faults can be located and fixed,
quality of the software can be improved
or software can be modified in the
maintenance hase.
2 Modifiabilit The degree to which the
software is easy to
implement, modify and test in
the maintenance hase.
Maintainability: The ease with which the faults
can be located and fixed, quality of the software
can be improved or software can be modified
in the
3 Reada The degree to which the software
bility documents and programs are easy to
understand so that the faults can be easily
located and fixed in the maintenance hase.
Maintainability: The ease with which
the faults can be located and fixed,
quality of the software can be improved
or software can be modified in the
maintenance
hase.
4 Flexibility The ease with which changes
can be made in the software
in the maintenance hase.
Adaptability: The degree to which the
software is adaptable to different
technolo ies and latforms .
1 Interoperability The degree to which the
system is compatible with
other s stems.
Adaptability: The degree to which the
software is adaptable to different
technolo ies and latforms .
2 Portability The ease with which the
software can be transferred
from one platform to
another latform.
Reliability: The degree to which the
software performs failure free functions.
1 Robustness The degree to which software
performs reasonably under
unexpected circumstances.
Reliability: The degree to which
the software performs failure free
functions.
2 Recoverability The speed w ith
which the software
recovers after the
occurrence of a
failure.
There are two goals of the software quality
system (SQS).
o The first goal is to buildquality into the
software from the beginning. This means
assuring that the
problem or need to be addressed is clearly
and accurately stated, and that the
requirements for the solution are properly
defined, expressed, and understood.
There are two goals of the software quality
system (SQS).
o The second goal of the SQS is to keep that
quality
in the software throughout the software life
cycle (SLC).
The 10 elements of the SQS are as bllows:
• Standards,Processes & Metrics• Security & Sai3ty
• Reviews &Audits • Training
• Testing • Supplier control
• Defect analysis • Documentation
• Co nfiguration management (C M ) • Risk
management
o Requirement Analysis phase- gathering and
documentation of requirements
o Design phase- preliminary and detailed design
of the software.
o Imple me ntat ion and unit testing
phase- development of source code
and initial testing of independent units.
o Integration and system testing phase
testing the integrated parts of various
units and the system as a whole.
o Operational phase- delivering and installing
the software at the customer 's site.
o Ma int e na nce phas e- re mov ing
def e cts , accommodating changes and
improving the quality of the software after it
goes into operational phase.
Requireme Design lmpleme Integration Operat Mainten
nt Analysis ntation and system ional ance
and unit testing
testing
Standards, process and '1 '1 '1 '1 '1 '1
metrics
Reviews and audits '1 '1 '1 '1 '1
Software testing '1 '1 '1 '1 '1 '1
Defect ma nage ment and '1 '1 '1 '1 '1
trend a nalys is
Configuration management '1 '1 '1 '1 '1
Risk analysis and '1 '1 '1 '1 '1
assessment
Supplier control '1 '1 '1 '1
Training '1 '1 '1 '1 '1 '1
Documentation '1 '1 '1 '1 '1
Safety and security '1 '1 '1
oStandards provide procedures that must be
enforced during the software development life cycle.
o Standard may be defined by
• Institute of Electrical and Electronics Engineers
(IEEE),
• American National Standards Institute (ANSI), or
• International Organization for Standardization
(ISO).
These include the following:
1.Necessity: No standard will be observed for long if
there is no real reason for its existence.
2.Feasibility: Common sense tells us that if it is not
possible to comply with the tenets of a standard,
then it will be ignored.
3.Measurability: It must be poss ible to
demonstrate that the standard is being followed.
o Standards should be supported by concrete, well
defined and effective processes so that they are
effectively implemented.
o Process is a collection of activities that are
required to produce a good quality product.
o An effective process is well practiced, enforced,
documented and measured.
o The metrics must be used to measure the
effectiveness of software processes and
practices followe d duringthe software
development.
o Reviews are conducted as a part of verification
activities.
o Reviews are very effective as they are
conducted in early phases of software
development.
o Ttiey minimizethe probability of occurrence
of faults in the earlier phases of software
development i.e. before the validation activities
begins.
o Reviews are cost effective and consume less
cost.
o They increase the confidence about the
correctness of the software under development.
• Reviews are of two types:
• Formal Reviews
• Informal Reviews.
• The informal reviews are carried out
throughout software development life
cycle and are known as in process
reviews.
• Formal reviews are carried out at the
end of software development life cycle
phase.
reviews
In-process De1aile
reviews d
Cowng and
testing
Acceptance and
implomontation
Operation
Postimplomontation
review
o Informal reviews include w alk-throughs
and inspections.
o Walkt hroughs are informal, but
scheduled, reviews, usually conducted in
and by peer groups.
o The author of the subject component-a
design specification, test procedure,
coded unit, or the like-walks through his
or her component, explaining it to a
small group of peers.
n1spectionsareamorestructuredtypeof
walk- through.
o Though the basic goal of an inspection
removal of defects-is the same as that of
the walk- through, the format of the
meeting and the roles of the participants
are more strictly defined, and more formal
records of the proceedings are prepared.
1000
Cost in units
100
10
1
Requirement analysis Design Implementation Integration and Maintenance
System testing
Time when fault is detected
DProcess reviews may be held at
any time. The purpose of a
process review is to examine the
success of the software process in
effect.
physical audit (PA), often
included as a part of the CM
process, is an example of a formal
audit.
DIt compares the final form of the
code against the final
documentation for that code.
DThe goal of the physical audit is to
assure that the two products,
documentation and code, are in
agreement before being released to
the user or customer.
DAnother formal audit is the functional
audit. The f unct iona l a udit ( FA),
aga in ofte n a CM responsibility,
compares the test results with the
currently approved requirements to
assure that all requirements have
been satisfied.
Rcqu.u-ornonu:
Tesit plan
de::sign
Design
Test
Testing- >
procedures
'Ibst
da1a
Test
Repor1s
Deliver
y
planning begins during the
re q uire me nts phase
a nd parallels the
requirements development.
DAs each requirement is generated, the
corresponding method of test for that
requirement should be a consideration.
DA requirement is faulty if it is not testable.
dtual testing begins with the debuggingand
early unit and module tests conducted
by t he programmer.
DAn important aspect of complete testing is
user acceptance testing.
DTest execution required the use of
detailed test procedures.
DTest reports document the actual results of
the testing effort as it progresses.
DFor each test that is run, a report of the
expected results, actual results, and the
conclusions of the test conductor concerning
success of the test should be prepared.
Permision
Change Situ;ttion to change?
Begin 1equested 1 --i verified? t----1M (configuration
-
(by anvone) (by developer) mnn gement)
No No
Change Change
m de
Defect
1-- coneet?
(by developer)
(te.qt)
Analysis
No
Change reported (coniigurabon management)
Change Installation correct? (ted)
installed (developer/ operations)
End
No
mfect analysis is the combination of defect
detection and correction, and defect trend
analysis.
DThe record of defects and their solutions
can serve to do the following:
./ Prevent defects from remaining
y nsolved for inappropriate lengths of
time;
./ Prevent unwarranted changes;
recordofdefectsandtheir solutions
can serve to do the following:
./ Point out inherently weak areas in
the software;
./ Provide analysis data for development
process evaluation and correction;
./ Provide warnings of potential
defects through analysis of defect trends
r····························sc»F!TWA·E··1· o·uetE..A.EfSOT
······································································1
I coumo. r _
PRtO
ii MITTHOOE-- R-D C-"T-
O----- y"
------------
Code Meaning
or
Field
ontro sua y a sequent 1a num er
number for l<eeping track of the
individual STRs.
Code M eaning
or
Field
An indication of the speed with which this STR
should be addressed:
E = emergency; work must stop until this STR is
Priority closed.
H = hi h; work is im eded while this STR is o en.
M = medium; some netive impact on work
exists until this S is closed.
L = low; This STR must be closed, but it does
not interfere with current work.
Code Meaning
or
Field
The phase in which the error was made
that introduced the defect being described
Source (these will depend on the organization's
actual life cycle model and its phase
names):
• R = reQ ui rements., D = design, C =
=code, T test,
o =o erat1on
Meaning
n estimate o t e impact o t 1s e ect
had it not been found until the so tware
was in operation:
•C = critical-persons could die or a firm
Severit could go out of business
•S = eripus = grave injury to persons o
organ1zat1ons
•M = Moderate injury or loss, but no
permanent
•T = Trivial = little or no im act
Meaning
e p ase 1n w 1c t 1s e ect was
detected (typically the same names as tor
source):
Phase •R = requirements
•D = design
•C = code
•T = test
•O = o eration
Code Meaning
or
Fi eld
st1mate:
hours and
mone
ctua : e actua costs o correct1nq
hours this defect and retesting the
and product
mone
Code or Meaning
Field
The defect detection technique with which
this defect was detected (each
Method organization will have its own set
of techniques):
•Q = quality audit
•W = walk-through
•I = ins ection
Code Meaning
or
Field •D = debugging or unit testing
Method
•T = testing
•A = user acceptance testing
•O = o eration
Configuration
management
Configuration
audits
Configuration identification Configuration control Configuration
accounting
DConfiguration identification is, as its name
implies, the naming, and documentation, of
each component (document, unit, module,
subsystem, and system) so that at any given
time, the particular component of interest
can be uniquely identified.
DConfiguration control is that activity that
prevents unauthorized changes to any
software product. Early in the SLC,
documentation is the primary product.
Configuration control takes on an
increasingly formal role as the documents
move from draft to final form.
igu 1
ation accounting keeps track of the status of
each component.
DThe latest version or update of each software
component is recorded.
DThus, w hen changes or other activities are necessary
with respect to the component, the correct version of
the component can be located and used.
DTraining assures that
the people involved with
software development,
and those people using
the software once it is
developed, are able to
do their jobs correctly.
D It is important to the quality
of the software that the 'I,
producers be educated in
the use of the various
development tools at his or
her disposal.
DThe proper use of the
software once it has been 'I,
developed and put into
operation is another area
requiring education.
DThe following are
three basic types of
purchased software:
• Off-the-shelf;
• Tailored shell;
• Contracted.
-... ,' -the-shelf software is the package we buy at
the store. Microsoft Office, Adobe Photoshop,
virus checkers.
DThe second category may be called the
tailored shell. In this case, a basic, existing
framework is purchased and the vendor then
adds specific capabilities as required by the
contract.
DThe third category is contracted software. This
is software that is contractually specified and
provided by a third-party developer.
DSecurity activities are applied
both to data and to the
physical data cente r itse lf .
DT hese act iv ities are
intended to protect the
usefulness of the software
and its environment.
DThehighestqualitysoftware systemis
of no use if the data center in which it is
to be used is damaged or destroyed.
DAnother frequent damager of the quality
of output of an otherwise high-quality
software system is data that has been
unknowingly modified.
DAdditionally, though not really a
software quality issue per se, is the
question of theft of data.
DFinally, the recent onslaught of hackers
and software attackers and the
burgeoning occurrences of viruses also
need to be considered.
DThe software quality practitioner is
responsible for alerting management to the
absence, or apparent inadequacy, of
security provisions in the software.
DIn addition, the software quality
practitioner must raise the issue of data
center security and disaster recovery to
management's attention.
- sl computers software
importance and impact more and more of
our lives, the safety of the devices becomes
•
a maj or concern.
2. The literature records overdoses of
medicines, lethal doses of radiation, and
other catastrophic and near-
catastrophic events.
3. Every software project must consciously
consider the safety implications of the
software and the system of which it is a part.
4. The project management plan should
include a paragraph describing the safety
issues to be considered. If appropriate , a
software safety plan should be prepared.
