MAY/JUNE-‘09/CS1020-Answerkey

B.E./B.Tech. DEGREE EXAMINATION, MAY/JUNE 2009.

Eighth Semester (Regulation 2004)
Computer Science and Engineering
CS 1020-SOFTWARE QUALITY MANAGEMENT

Staff Incharge ; A. Anandh

Answer ALL Questions
Part A - (10x2=20 marks)

1. Define Software Quality. What is it from the user’s point of view?

User’s point of view

This can be summarized as ‘fitness for purpose’. It is an important view of quality that has
often been sacrificed in software engineering in the past in favors of technical correctness.

2. List out atleast four important measures of maintainability.

Readability
Complexity
Modularity
Testability

3. State four quality attributes due to Gilb.

o Workability
o Availability
o Adaptability
o Usability

1
 MAY/JUNE-‘09/CS1020-Answerkey
4. What is the need for software quality assurance plan?
The need for the Software Quality Assurance Plan is to define the techniques, procedures and
methodologies that will be used to assure timely delivery of the software that meets specified
requirements within project resources.

5. What are the Ishikawa’s seven basic tools?

1. Checklist (or Checksheet)
2. Pareto diagram
3. Histogram
4. Scatter Diagram
5. Run chart
6. Control Chart
7. Cause-and-effect diagram

6. Explain briefly the significance of time between failure models and fault count models.
In time between failures models, the variable under study is the time between failures.
This is the earliest class of models proposed for software reliability assessment. It is expected
that the failure times will get longer as defects removed from the software product.

In fault count models the variable criterion is the number of faults or failures in a
specified time interval. The time can be CPU execution time or calendar time such as hour,
week, or month. The number of defects or failures observed during the interval is treated as a
random variable. As defects are detected and removed from the software, it is expected that the
observed number of failures per unit time will decrease.

7. What is problem tracking report (PTR) model?

Many development organizations testing defects are tracked via some kind of problem
tracking report (PTR), which is a part of the change control process during testing. Valid PTRs
are therefore valid code defects. It is a submodel because it is part of the overall defect removal
model. PTR submodel spreads over time the number of defects that are expected to be removed
during the machine-testing phase.

8. Define cyclomatic complexity. What is its use is software?

The measurement of cyclomatic complexity was designed to indicate a program’s
testability and understandability. It is the classical graph theory cyclomatic number, indicating
the number of regions in a graph.

2
 MAY/JUNE-‘09/CS1020-Answerkey
As applied to software, it is the number of linearly independent paths that comprise the
program. It is used to indicate the effort required to test a program.

9. What are the main standards of ISO 9000 series? Where do you make use of these
standards in software development?
Main standards are ISO9000, ISO9001, ISO9002, ISO9003 AND ISO9004.

ISO EN BS USE
BS 5750 A guide to selecting the appropriate standard for a quality
IOS9000 EN29000
pt0 management system.
BS 5750 The specification of a QMS for design, development,
ISO9001 EN29001
pt1 production, installation and service.
BS 5750
ISO9002 EN29002 The specification of a QMS for production and installation.
pt2
The specification for a QMS for final inspection and
ISO9003 EN29003 BS5750 pt3
testing.
Guidance in setting up a QMS to meet the ISO9001/2/3
ISO9004 EN29004 BS5750 pt4
standards.

10. What are the six sigma limits? Explain their importance in quality management.

 The term “Six Sigma” refers to the ability of highly capable processes to produce output
within specification. In particular, processes that operate with six sigma quality produce
at defect levels below 3.4 defects per million opportunities (DPMO).
Six sigma limits: The area under the curve as defined by plus and minus one standard deviation
(sigma) from the mean is 68.26%.

PART B-(5x16=80 marks)

11. (a) Discuss in detail the hierarchical models of Boehm and McCall. Explain the
significance of these models in software development process.
GE model (McCall) :

This model was first proposed by McCall in 1977. It was later adapted and revised as the MQ
model. The model is aimed at system developers, to be used during the development process.
However in an early attempt to bridge the gap between users and developers, the criteria were
chosen in an attempt to reflect users views as well as developers priorities.

3
 MAY/JUNE-‘09/CS1020-Answerkey
The model identifies three areas of software work:

1. Product operation, 2. Product revision and 3. Product transition.

Product operation
Product revision
Product transition
Requires that it can be learnt easily, operated efficiently and that
the results are those required by the user.
Is concerned with error correction and adaption of the system.
This is important because it is generally considered to be the most
costly part of s/w development.
May not be so important in all applications. However the move
towards distributed processing and the rapid rate of change in h/w
is likely to increase its important.

Product Product
revision Transition

Product Operations

Fig : McCall Model

McCall criteria of quality defined

Usability is the ease of use of the software.

Integrity is the protection of the program from unauthorized access

Efficiency is concerned with the use of resources

Correctness is the extent to which a program fulfils its specification

Reliability is its ability not to fail.

Maintainability is the effort required to locate and fix a fault in the program within its
operating environment.

Flexibility is the ease of making changes required by changes in the operating environment.
Testability is the ease of testing the program.

4
 MAY/JUNE-‘09/CS1020-Answerkey
Portability is the effort required to transfer the program from one environment to another.
Reusability is the ease of reusing software in a different context.
Interoperability is the effort required to couple the system to another system

Boehm Model:

Boehm model was defined to provide a set of well defined, well differentiated characteristics
of software quality. The model is hierarchical in nature but the hierarchy is extended, so that
quality criteria are subdivided. The first division is made according to the uses made of the
system. These are classed as ‘general’ or ‘as is’ utility. There are two levels of actual quality
criteria, the intermediate level being further split into primitive characteristics which are
amenable to measurement.

The two models share a number of common characteristics arising from their hierarchical
nature and also from their origins in the computing culture.

 The quality criteria are supposedly based upon the user’s view.

 The models focus on the parts that designers can more rapidly analyze.

 Hierarchical models cannot be tested or validated.

 The measurement of overall quality is achieved by a weighted summation of the

characteristics.

5
 MAY/JUNE-‘09/CS1020-Answerkey

Device
Portability independence

Self-
As-is utility Reliability containedness

Accuracy

Completeness
Efficiency

Integrity
General
Utility
Human Consistency
Engineering

Accountability

Device
efficiency

Accessibility

Testability
Communicativeness

Maintainability Self descriptiveness

Understand
-ability
Structuredness
Modifiability

Conciseness

Legibility

Augmentability

Fig : Boehm Model:

6
 MAY/JUNE-‘09/CS1020-Answerkey
(or)

(b) Explain the purpose of Goal-Question-Metric (GQM) model. Suppose the development
team has as its goal “improve effectiveness of testing”. Use GQM approach to suggest
relevant questions and measures that will enable you to determine if you have met your
goal.

In Goal-Question-Metric model goals were identified, questions were formulated in

quantifiable terms and metrics were established. The goals and measurement areas identified by
the Motorola quality policy for software development are listed in the following.

Goals : Improve project planning

Increase defect containment

Increase software reliability

Decrease software defect density

Improve customer service

Measurement Areas:

Delivered areas

Total effectiveness throughout the process

Accuracy of estimates

Number of open customer problems

Time that problems remain open

Software reliability

For each goal the questions to be asked and the corresponding metrics were also
formulated. In the following, we list the questions and metrics for each goal.

Goal: “improve effectiveness of testing”

Question1:How will you improve the testing methodology?

Metric: Decrease Failure Rate(FR)

FR=Number of failures/Execution time

Question2: Which method you will prepare to test the software?

Metric : Average hour per defect, and defect causes.

Question3: What is the normalized number of in-process faults

7
 MAY/JUNE-‘09/CS1020-Answerkey
Metrric: IPF=In-process fault caused by s/w development/Assembly data source size

12 (a) What are the important quality tasks to be performed for effective Quality
Management? Discuss issues and remedies in quality assurance management.
Quality Tasks:
1. Build awareness of need and opportunities for improvement
2. Set goals for improvement
3. Organize to reach the goals
4. Provide training
5. Carry out projects to solve problems
6. Report progress
7. Give recognition
8. Communicate results
9. Keep score
10. Maintain momentum by making annual improvement part of the regular process of
the company
Problems in quality assurance:
The system must be completed within a short time scale
Close co-operation should be needed with machine-tool manufacturers.
The customer does not understand the need of system development.
Only the leader is experienced.
remedies in quality assurance management:
Break down the units of management to provide greater control.
Cut down management workload through design of tools.
Standardize procedures to allow knowledge transfer to other projects.
Tools was established and reviewed.
Further enhancements were added to the tool.

(or)
(b) Discuss the techniques used by quality auditors for software explain the importance of
each technique.
The objective of this section is to uncover errors in function, logic, or implementation for
any representation of software, to verify that the software under review meets its requirements,

8
 MAY/JUNE-‘09/CS1020-Answerkey
ensure that the software has been represented according to predefined standards and to0 achieve
software that is developed in a uniform manner.
Following reviews shall be conducted as a minimum.
Software requirement review: This review will guarantee the technical feasibility,
adequacy, and completeness of the requirements.
Preliminary design review: To evaluate the technical adequacy of the preliminary
design of the s/w as depicted in the s/w architectural design description.
Critical design review: To determine the acceptability of the detailed s/w design as
depicted in the software design description.
Software verification and validation plan review: Tries to access the correctness of
the transition to the next phase. Also meet the user’s requirements.
Functional audits: To be performed prior to the software delivery to end-users.
Physical audits: To verify that the software and its documentations are internally
consistent and are ready for delivery.
In-process audits: Verifies the consistency of the design from the various aspects
including code versus design documentation, interface specifications.
Managerial review: Access the execution of all actions with items identified in software
quality assurance plans.
Software Configuration management plan review: Software management plan will be
evaluated through s/w configuration management plan review.
Post-Mortem review: This review is conducted to accept and approve the finished
software work.

13. (a) Bring out salient features of Rayleigh model. Discuss the significance of this model in
the reliability analysis of the software. How does it provide a framework for quality
management?
Rayleigh model is a good overall model for quality management. It articulates the points
on defect prevention and early defect removal related to the preceding items. Based on the
model error injection rate is reduced.
A Rayleigh model derived from a previous release or from historical data can be used to
track the pattern of defect removal of the project under development.
If the current pattern is more front loaded than the model would predict, it is a positive
sign and vice versa. If the tracking is via calendar time such as month or week. Quality
projections based on early data would not be reliable compared to the final estimate at the end of
the development cycle.

9
 MAY/JUNE-‘09/CS1020-Answerkey
To facilitate early defect removal actions implemented include focus on the design
review/code inspection process.
Framework for Quality management:
Deployment of moderator training;
Use of an inspection checklist;
Use of in-process escapes measurements to track the effectiveness of reviews and
inspections;
Use of mini builds to flush out defects by developers before the system library build
takesplace;
(or)
(b) Explain clearly the concept of defect removal effectiveness and its importance in the
software development. How the metrics associated with defect removal effectiveness help
in quality planning and management.
Defects are injected into the product or immediate deliverables of the product at various
phases.
For the development phase before testing, the development activities themselves are
subject to defect injection and the reviews or inspections at end-f-phase activities are the key
vehicles for defect removal.
For the testing phases the testing itself is for defect removal.
Defect removal effectiveness can be defined as:
Defects remove (at the step)

Defects existing on step entry+ Defects injected during development (of the step)
Activities associated with Defect Injection and Removal
Development phase Defect injection Defect removal
Requirements Requirements gathering Requirement analysis and
process and the development review
of programming functional
specifications
High level design Design work High level design inspections
Low-level design Design work Low-level design inspections
Code Implementation Coding Code inspections
Integration/build Integration and build process Build verification testing
Unit test Bad fixes Testing itself

10
 MAY/JUNE-‘09/CS1020-Answerkey
Component test Bad fixes Testing itself
System Test Bad fixes Testing itself

14. (a) What are the important components of Quality management system? Discuss how
the reliability growth models are useful for quality management system.
The ISO definition of a QMS lists five components:
 Organizational structure
 Responsibilities
 Procedures
 Processes
 Resources
The Organizational structure must seek to assign responsibility for quality. Quality must have a
clear line of responsibility running right up to the top to an individual who is ultimately
responsible for quality.
Reliability Growth Models (RGM)
Reliability growth models are meant for reliability assessment.
They are also useful for quality management at the back end of the development process.
A special quality improvement program (QIP) was then proposed, evaluated, approved and
swiftly implemented.
1. Blitz testing- “artistic testing” in stressful environments.
2. Customer Evaluation- customers conducting testing in the development laboratory.
3. Code inspections- additional inspections of error phone modules especially routines
that are difficult to test such as the error recovery exception handling routines.
4. Design reviews- review of designs of suspect components and modules
5. Extension of system test-improvement of test suites and extension of testing schedules
to allow thorough final test execution.
(or)
(b) What are the module design metrics used in practice? Discuss the significance of these
metrics.
Based on experience in Object Oriented development Lorenz proposed eleven metrics as
OO design metrics.
OO metrics :
1. Average method size
2. Average number of methods per Class

11
 MAY/JUNE-‘09/CS1020-Answerkey
3. Average number of Instance variables per class
4. Class hierarchy nesting level
5. Number of subsystem/subsystem relationship
6. Number of class/class relationships in each subsystem
7. Instance variable usage
8. Average number o comment lines (per method)
9. Number of problem reports per class
10. Number of times class is reused.
11. Number of classes and methods thrown away
Metric 8 is a statement of good programming practices, metric 9 is a quality indicator, and
metric 11 is a metric for validating the OO development process.

15. (a) Discuss the need for quality standards. Do they ensure the adequate quality?
Explain ISO 9000-3 standard for software development.
Standards: It is defined in terms of a model of best practice against which all others may be
compared.
The standards are available for software quality management.
Needs for standards:
 It provides external validation to see whether the investment made in the QMS is being
effective.
 It gives the supplier and their quality system external credibility
 It allows the supplier to sell to those customers who insist on accreditation as a condition
of tender
 It qualifies the supplier to be included in buyers guides compiled by the accreditation
bodies and circulated to potential customers.
The standards ensure the adequate quality. The qualities are
ISO EN BS USE
A guide to selecting the appropriate standard for a quality
IOS9000 EN29000 BS 5750 pt0
management system.
The specification of a QMS for design, development,
ISO9001 EN29001 BS 5750 pt1
production, installation and service.
ISO9002 EN29002 BS 5750 pt2 The specification of a QMS for production and installation.
The specification for a QMS for final inspection and
ISO9003 EN29003 BS5750 pt3
testing.
ISO9004 EN29004 BS5750 pt4 Guidance in setting up a QMS to meet the ISO9001/2/3

12
 MAY/JUNE-‘09/CS1020-Answerkey
standards.

ISO 9000-3 Standards: It has a target audience of the IT community. It is intended as

complete documents in its own right, and its structure therefore differs from ISO9001. The
structure of ISO 9000-3 is as follows
Introductory material
The first three clauses of the standard are concerned with defining the scope of the
standard.
Section 4 : Quality system – framework
Section 5 : Quality system – lifecycle activities
Section 6 : Quality system - supporting activities.
(or)

(b) Write short notes on the following: (i) Capability Maturity Model (CMM). (ii)
Comparison of ISO 9000 and CMM.

i)CMM (Capability Maturity Model) :The basic premise underlying the Software Engineering
Institute(SEI) maturity model is that the quality of a software product is largely determined by
the quality of the software development and maintenance processes used to build it.

The model is question-based. Questions are divided into ‘essentials’ and ‘highly
desirable’.

Five levels of the SEI CMM

1. Initial : The organization has undefined process and control

2. Repeatable : The organization has standardized methods facilitating repeatable processes

3. Defined: The organization monitors and improves its processes.

4. Managed : The organization possesses advanced controls, metrics and feedback

5. Optimizing: The organization uses metrics for optimization purposes.

The role of the CMM:

The role of the CMM is increasing. This may be attributed to a number of factors:
The maturity of the model itself;
The increasing general awareness of the need for externally recognized quality standards;
Comparison of ISO9000 and SEI CMM
characteristics ISO9001 ISO9000-3 SEI CMM
Scope Quality system Notes for guidance for Application of TQM to

13
 MAY/JUNE-‘09/CS1020-Answerkey
application quality software development and
system to software maintenance
development.
Goal Quality and Quality and Quality and productivity
productivity productivity Improvement
Improvement Improvement
External Purpose Quality system Quality system Capability evaluation
certicficate certicficate
Outcome Yes/No Yes/No Levels 1-5
Identification of Internal quality audits Internal quality audits Process assessment
improvement
needs
Results Audit reports Audi reports Final presentation
Realization of Responsible person Responsible person Process improvement
follow-up actions named for each named for each team
observation observation

14