Software quality assurance

Q1 Write a note on five views of software quality

Ans. Following are the five different views of quality:
i) Transcendental View :
 It envisages quality as something that can be recognized but is difficult to define.
Here quality is something that can be recognized through experience but is not
defined in some tractable form.
 Quality is viewed to be something ideal, which is too complex to lend itself to be
precisely defined.
ii) User View:
 It perceives quality as fitness for purpose. According to this view, while evaluating
the quality of the product, one must ask the key question "Does the product satisfy
user needs and expectations?"
 In this view, a user is concerned with whether or not a product is fit for use. Quality
is not just viewed in terms of what a product can deliver, but it is also influenced by
the service provisions in the sales contract.
iii) Manufacturing View :
 Here quality is understood as conformance to the specifications. The quality level
of a product is determined by the extent to which the product meets its
specifications.
 Any deviation from the stated requirements is seen as reducing the quality of the
product. The manufacturing view has its genesis in the manufacturing sectors,
such as the automobile and electronics sectors.
iv) Product View :
 In this case, quality is viewed as tied to the inherent characteristics of the product.
A product's internal qualities determine its external qualities.
 The product view is attractive because it gives rise to an opportunity to explore
casual relationships between internal properties and external qualities of a
product.
 An example of the product view of software quality is that high degree of
modularity, which is an internal property, makes a software testable and
maintainable.
v) Value - Based View :
 Quality, in this perspective, depends on the amount the customer is willing to pay
for it. The value based view represents a merger of two independent concepts:
excellence and worth where Quality is the measure of excellence and value is the
measure of worth.
Q2 Write a note on McCall’s Quality Factors?
Ans McCall’s factor model

McCall’s factor model classifies all software requirements into 11 software quality factors.
The 11 factors are grouped into three categories

– product operation, product revision and product transition – as follows:

■ Product operation factors: Correctness, Reliability, Efficiency, Integrity, Usability.

■ Product revision factors: Maintainability, Flexibility, Testability.

■ Product transition factors: Portability, Reusability, Interoperability.

Q3 What are the six broad, independent categories of quality characteristics?

ISO 9126, defines six broad, independent categories of quality characteristics as
follows :
1. Functionality:

 A set of attributes that bear on the existence of a set of functions and their
specified properties. The functions are those that satisfy stated or implied needs.

2. Reliability:

 A set of attributes that bear on the capability of software to maintain its

performance level under stated conditions for a stated period of time.
3. Usability:

 A set of attributes that bear on the effort needed for use and on the individual
assessment of such use by a stated or implied set of users.

4. Efficiency:

 A set of attributes that bear on the relationship between the software’s

performance and the amount of resource used under stated conditions.

5. Maintainability:

 A set of attributes that bear on the effort needed to make specified modifications
(which may include corrections, improvements, or adaptions of software to
environmental changes)

6. Portability:

 A set of attributes that bear on the ability of software to be transferred from one
environment to another ( this includes the organizational, hardware or software
environment)

Q4 Point out the objectives of SQA activities?

Ans. The objectives of SQA activities

Software development (process-oriented):

1. Assuring an acceptable level of confidence that the software will conform to

functional technical requirements.

2. Assuring an acceptable level of confidence that the software will conform to

managerial scheduling and budgetary requirements.

3. Initiating and managing of activities for the improvement and greater efficiency of
software development and SQA activities. This means improving the prospects that the
functional and managerial requirements will be achieved while reducing the costs of
carrying out the software development and SQA activities.

Software maintenance (product-oriented):

1. Assuring with an acceptable level of confidence that the software maintenance
activities will conform to the functional technical requirements.

2. Assuring with an acceptable level of confidence that the software maintenance

activities will conform to managerial scheduling and budgetary requirements.

3. Initiating and managing activities to improve and increase the efficiency of software
maintenance and SQA activities. This involves improving the prospects of achieving
functional and managerial requirements while reducing costs.

Q5 With a diagram, interpret SQA architecture?

Ans

SQA is divided into 6 classes, they are:

1. Pre-project components
2. Components of project life cycle activities assessment
3. Components of infrastructure error prevention and improvement
4. Components of software quality management
5. Components of standardization, certification, and SQA system assessment
6. Organizing for SQA – the human components
To make it clearer about each definition of those classes, let’s break it down to you…
Pre-project components. This stage is defined before executing the project. Some
activities which are done at this phase are:
 Ensuring the resources, schedule and the budget required. Those have to
adequately define in order to synchronize everything as it planned.
 Besides the resources, schedule and the budget, there are another plans
have to be defined. They are development and quality plans. Why do they
have to be defined? The developer and the owner of the project may have
different perspective about the quality and the development itself. So, it’s
defined together by those two parties to align the perspectives that may
occur.
Components of project life cycle activities assessment. At this phase, the activities
are divided into 2 stages. They are, the development life cycle stage and the operation-
maintenance stage. At the development life cycle stage, the activities are detecting the
design and programming errors. And it’s also divided again into 4 sub-classes, which are:
 Reviews
 Expert opinions
 Software testing
And for the operation-maintenance stage, the activities that include in that phase is
specialized maintenance component, as it’s ever done in development life cycle phase.
This activity is done for improving the functionality maintenance tasks. Besides that,
there’s an additional sub-class of SQA. It’s to assure the quality of project parts
performed by subcontractors and other external participants during project development
and maintenance.

Components of infrastructure error prevention and improvement. The

main activity of this stage is to eliminate or make the errors gone missing or well, at
least reduce the rate of errors. It’s applied to entire organization.
Components of software quality management. This phase is focused on several
goals. The main goal is controlling the development process and maintenance. And also
introducing the managerial support in preventing and minimizing schedule and budget
failure of their outcomes.
Components of standardization, certification, and SQA system assessment. This
phase implement international professional and managerial standard for the
organization. The activities included in this phase are:
 Utilize the international professional knowledge
 Improve the coordination of the organizational quality systems with other
organizations
 Assess the achievement of quality system according to a common scale
For the standard, it’s divided into 2 groups, they are:

 Quality management standard

 Project process standard
Organizing for SQA – human components. At this stage, we’re organizing the people
who relate for SQA things. They are managers, testing personnel, SQA trustees, SQA
committee members and SQA forum members. They all contribute to initiate and support
the implementation of SQA components, detect deviations from SQA procedure and
methodology and suggest improvements.

Q6 Differentiate inspections and walkthroughs?

Ans Difference between Inspection and Walkthrough :

S.No.Inspection Walkthrough
1. It is formal. It is informal.
 2. Initiated by project team. Initiated by author.

Usually team members of the same

A group of relevant persons project take participation in the
from different departments walkthrough. Author himself acts
3. participate in the inspection. walkthrough leader.

Checklist is used to find

4. faults. No checklist is used in the walkthrough.

Walkthrough process includes

Inspection processes overview, little or no preparation, little
includes overview, or no preparation examination (actual
preparation, inspection, and walkthrough meeting), and rework and
5. rework and follow up. follow up.

Formalized procedure in
6. each step. No formalized procedure in the steps.

Inspection takes longer time Shorter time is spent on walkthrough as

as list of items in checklist is there is no formal checklist used to
7. tracked to completion. evaluate program.

Planned meeting with the

fixed roles assigned to all
8. the members involved. Unplanned

Reader reads product code. Author reads product code and his
Everyone inspects it and teammate comes up with the defects or
9. comes up with detects. suggestions.

10 Recorder records the Author make a note of defects and

. defects. suggestions offered by teammate.

Moderator has a role that

moderator making sure that
11 the discussions proceed on Informal, so there is no moderator.
. the productive lines.
Q7 formal design review?
Ans.

Formal design reviews, variously called “design reviews”, “DRs”

and “formal technical reviews (FTR)”, differ from all other
review instruments by being the only reviews that are
necessary for approval of the design product. Without this
approval, the development team cannot continue to the next
phase of the software development project. Formal design
reviews may be conducted at any development milestone
requiring completion of an analysis or design document,
whether that document is a requirement specification or an
installation plan.
The formal design reviews will focus on:

■ The participants

■ The prior preparations

■ The DR session

■ The recommended post-DR activities. The participants in a DR

All DRs are conducted by a review leader and a review team. Preparations for a DR

Review leader preparations

The main tasks of the review leader in the preparation stage are:

■ To appoint the team members

■ To schedule the review sessions

■ To distribute the design document among the team members (hard copy, electronic
file, etc.).

Review team preparations

Team members are expected to review the design document and list their comments prior
to the review session.

Development team preparations

The team’s main obligation as the review session approaches is to prepare a short
presentation of the design document. Assuming that the review team members have read
the design document thoroughly and are now familiar with the project’s outlines, the
presentation should focus on the main professional issues awaiting approval rather than
wasting time on description of the project in general.

The DR session

(1) A short presentation of the design document.

(2) Comments made by members of the review team.

(3) Verification and validation in which each of the comments is discussed to determine
the required actions (corrections, changes and additions) that the project team has to
perform.
(4) Decisions about the design product (document), which determines the project’s
progress. These decisions can take three forms:

■ Full approval – enables immediate continuation to the next phase of the project. On
occasion, full approval may be accompanied by demands for some minor corrections to be
performed by the project team.

■ Partial approval – approval of immediate continuation to the next phase for some
parts of the project, with major action items (corrections, changes and additions) demanded
for the remainder of the project. Continuation to the next phase of these remainder parts
will be permitted only after satisfactory completion of the action items.

This approval can be given by the member of the review team assigned to review the
completed action items, by the full review team in a special review session, or by any other
forum the review leader thinks appropriate.

■ Denial of approval – demands a repeat of the DR. This decision is applied in cases of
multiple major defects, particularly critical defects.

Post-review activities

The DR report

One of the review leader’s responsibilities is to issue the DR report immediately after the
review session.

The report’s major sections contain:

■ A summary of the review discussions.

■ The decision about continuation of the project.

■ A full list of the required actions – corrections, changes and additions that the
project team has to perform. For each action item, the anticipated completion date and
project team member responsible are listed.

■ The name(s) of the review team member(s) assigned to follow up performance of

corrections.

The follow-up process

The person appointed to follow up the corrections, in many cases the review leader him or
herself, is required to determine whether each action item has been satisfactorily
accomplished as a condition for allowing the project to continue to the next phase. Follow-
up should be fully documented to enable clarification of the corrections in the future, if
necessary.

Peer reviews

Two peer review methods are inspections and walkthroughs.

The major difference between formal design reviews and peer review methods is rooted in
their participants and authority. While most participants in DRs hold superior positions to
the project leader and customer representatives, participants in peer reviews are, as
expected, the project leader’s equals, members of his or her department and other units.