3.SQA Components - 0

OHT 4.
Software Quality assurance (SQA)

SWE 333
SQA Components
Dr Khalid Alnafjan
kalnafjan@ksu.edu.sa
Galin, SQA from theory to implementation © Pearson Education Limited 2004
OHT 4.2
• Pre-project components
• Software project life cycle components
• Infrastructure components for error prevention and improvements
• Management SQA components
• SQA standards, system certification and assessment components
• Organizing for SQA – the human components
• Considerations guiding construction of organization’s SQA system

OHT 4.3
The SQA components belonging

here are meant to improve the
preparatory steps taken prior to
initiating work on the project
itself
OHT 4.4
• Contract reviews
• Development and quality plans

OHT 4.5
Pre project component: Contract
Review
• Software may be developed within the
framework of a contract negotiated with a
customer or in response to an internal order
originating in another department.
• Contract review activities must include a
detailed examination of the project proposal
draft and the contract drafts. contract
review activities include:
OHT 4.6
■ Clarification of the customer’s requirements

■ Review of the project’s schedule and
resource requirement estimates
■ Evaluation of the professional staff’s
capacity to carry out the proposed project
■ Evaluation of the customer’s capacity to
fulfill his obligations
■ Evaluation of development risks.

OHT 4.7
Pre project component:
Development and quality plans
• Once a software development contract has
been signed or a commitment made to
undertake an internal project for the benefit
of another department of the organization, a
plan is prepared of the project
(“development plan”) and its integrated
quality assurance activities (“quality plan”)

OHT 4.8
The main issues treated in the project

development plan are:
■ Schedules
■ Required manpower and hardware resources
■ Risk evaluations
■ Organizational issues: team members,
subcontractors and partnerships
■ Project methodology, development tools, etc.
■ Software reuse plans.
OHT 4.9
The main issues treated in the project’s

quality plan are:
■ Quality goals, expressed in the appropriate
measurable terms
■ Criteria for starting and ending each project
stage
■ Lists of reviews, tests, and other scheduled
verification and validation activities.

OHT 4.10
• Several SQA components enter the

software development project life
cycle at different points. Their use
should be planned prior to the
project’s initiation. The main
components are:

OHT 4.11
• Reviews
• Expert opinions
• Software testing
• Software maintenance components
• Assurance of the quality of external
participants’ work

OHT 4.12
Software Project life cycle components:

Reviews
• Several phases of the development process
produce a variety of documents.
• For example: design reports, software test
documents, software installation plans
and software manuals.
• These have to be reviewed to ensure that
specified qualities have been met.

OHT 4.13

Expert opinions
• Expert opinions support quality assessment
efforts by introducing additional external
capabilities into the organization’s in-house
development process. Turning to outside
experts may be particularly useful in the
following situations:

OHT 4.14

Expert opinions
• Insufficient in-house professional
capabilities in a given area.
• In small organizations in many cases it is
difficult to find enough suitable candidates
to participate in the design review teams.
• In cases of major disagreement among the
organization’s senior professionals, an
outside expert may support a decision.
OHT 4.15

Software testing
• Software tests are formal SQA components
that are targeted toward review of the actual
running of the software.
• The tests are based on a prepared list of test
cases that represent a variety of expected
scenarios. Software tests examine software
modules, software integration, or entire
software packages
OHT 4.16

Software maintenance
• Software maintenance services vary in
range and are provided for extensive
periods, often several years. These services
fall into the following categories:
• Corrective maintenance, Adaptive
maintenance and Functionality
improvement maintenance.
• Similar to components of SDLC
OHT 4.17
Assurance of the quality of the external
participant’s work
• Subcontractors and customers frequently join
the directly contracted developers in carrying
out software development projects.
• The larger and more complex the project, the
greater the likelihood that external participants
will be required, and the larger the proportion
of work transmitted to them (subcontractors,
suppliers of COTS software and the customer).
OHT 4.18
Assurance of the quality of the external
participant’s work
• Most of the SQA controls applied to external
participants are defined in the contracts signed
between the relevant parties. If an external
participant’s work is performed using software
assurance standards below those of the supplier’s,
risks of not meeting schedule or other
requirements are introduced into the project.
Hence, special software assurance efforts are
required to establish effective controls over the
external participant’s work.
OHT 4.19
• Procedures and work instruction

• Templates and checklists
• Staff training, retraining and
certification
• Preventive and corrective actions
• Configuration management
• Documentation control

OHT 4.20
Infrastructure components for error
prevention
and improvement
• The goals of SQA infrastructure are the
prevention of software faults or, at least, the
lowering of software fault rates, together
with the improvement of productivity. SQA
infrastructure components are developed
specifically to this end. These components
are devised to serve a wide range of
projects and software maintenance services.
OHT 4.21
Infrastructure components for error
prevention
and improvement
This class of SQA components includes:
■ Procedures and work instructions
■ Templates and checklists
■ Staff training, retraining, and certification
■ Preventive and corrective actions
■ Configuration management
■ Documentation control.
OHT 4.22
Procedures and work instructions

• Quality assurance procedures usually provide
detailed definitions for the performance of
specific types of development activities in a
way that assures effective achievement of
quality results. Procedures are planned to be
generally applicable and to serve the entire
organization. Work instructions, in contrast,
provide detailed directions for the use of
methods that are applied in unique instances
and employed by specialized teams.
OHT 4.23
Templates and checklists

One way to combine higher quality with higher
efficiency is to use Templates and checklists.
■ Saving the time required to define the structure
of the various documents
■ Contributing to the completeness of the
documents and reviews.
■ Improving communication between development
team and review committee members by
standardizing documents and agendas.
OHT 4.24
Staff training, instruction and certification
keeping an organization’s human resources
knowledgeable and updated at the level
required is achieved mainly by:
■ Training new employees and retraining those
employees who have changed assignments.
■ Continuously updating staff with respect to
professional developments and the in-house,
hands-on experience acquired.
• ■ Certifying employees after their knowledge
and ability have been demonstrated.
OHT 4.25
Preventive and corrective actions

Systematic study of previous failures and success
stories to implement. Among them we can list:
■ Implementation of changes that prevent similar
failures in the future.
■ Correction of similar faults found in other
projects and among the activities performed by
other teams.
■ Implementing proven successful methodologies
to enhance the probability of repeat successes.
OHT 4.26
Configuration Management
• The regular software development and
maintenance operations involve intensive
activities that modify software to create new
versions and releases. These activities are
conducted throughout the entire software service
period in order to cope with the needed
corrections, adaptations to specific customer
requirements, application improvements, and so
forth. Different team members carry out these
activities simultaneously.
OHT 4.27
• Changes may take place at different sites. As a
result, serious dangers arise, whether of
misidentification of the versions ,releases or
documentation loss.
• Configuration management deals with these
hazards by introducing procedures to control the
change process. These procedures relate to the
approval of changes, the recording of those
changes performed,
OHT 4.28
• Also the issuing of new software versions and
releases, the recording of the version and release
specifications of the software installed in each site,
and the prevention of any changes in approved
versions and releases once they are issued.
• Most configuration management systems
implement computerized tools to accomplish their
tasks. These computerized systems provide the
updated and proper versions of the installed
software and their documentation.
OHT 4.29
• Project progress control

• Software quality metrics
• Software quality costs

OHT 4.30
• Project process standards

• Quality management standards
Objectives:
 Utilization of international professional knowledge
 Improvement of coordination with other organizations’
quality systems
 Objective professional evaluation and measurement of the
organization’s SQA achievement
OHT 4.31
Quality Management Standards

• The organization can clearly benefit from quality
standards that guide the management of software
development, maintenance, SQA standards,
system certification, and assessment components
and infrastructure. These standards focus on what
is required and leave the decision about how to
achieve it to the organization.

OHT 4.32
Quality management standards

• The application of a managerial quality system
provides a fairly objective assessment of the
organization’s achievements. Organizations that
comply with quality achievement requirements
can then seek SQA certification. The most
familiar examples of this type of standard are:
■ SEI CMM assessment standard
■ ISO 9001 and ISO 9000-3 standards.

OHT 4.33
Project process standard

• Project process standards are professional
standards that provide methodological guidelines
(dealing with the question of “how”) for the
development team. Well-known examples of this
type of standards are:
■ IEEE 1012 standard
■ ISO/IEC 12207 standard.

OHT 4.34
Quality management standards

• The application of a managerial quality system
provides a fairly objective assessment of the
organization’s achievements. Organizations that
comply with quality achievement requirements
can then seek SQA certification. The most
familiar examples of this type of standard are:
■ SEI CMM assessment standard
■ ISO 9001 and ISO 9000-3 standards.

OHT 4.35
Management’s role in SQA

• The responsibilities of top management (through
the executive in charge of software quality),
departmental management and project
management include the following:
■ Definition of the quality policy
■ Effective follow-up of quality policy
implementation Components of software quality
assurance system
■ Allocation of sufficient resources to implement
quality policy

3.SQA Components - 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

3.SQA Components - 0

Uploaded by

Copyright:

Available Formats

OHT 4.

Software Quality assurance (SQA)

Galin, SQA from theory to implementation © Pearson Education Limited 2004

The SQA components belonging

Galin, SQA from theory to implementation © Pearson Education Limited 2004

■ Clarification of the customer’s requirements

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Galin, SQA from theory to implementation © Pearson Education Limited 2004

The main issues treated in the project

The main issues treated in the project’s

Galin, SQA from theory to implementation © Pearson Education Limited 2004

• Several SQA components enter the

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Software Project life cycle components:

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Software Project life cycle components:

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Software Project life cycle components:

Software Project life cycle components:

Software Project life cycle components:

• Procedures and work instruction

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Procedures and work instructions

Templates and checklists

Preventive and corrective actions

• Project progress control

Galin, SQA from theory to implementation © Pearson Education Limited 2004

• Project process standards

Quality Management Standards

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Quality management standards

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Project process standard

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Quality management standards

Galin, SQA from theory to implementation © Pearson Education Limited 2004

Management’s role in SQA

You might also like