The SQA system – an SQA architecture

An SQA system always combines a wide range of SQA components, all of

which are employed to challenge the multitude of sources of software
errors and to achieve an acceptable level of software quality. As stated in
Chapter 1, the task of SQA is unique in the area of quality assurance due
to the special characteristics of software. In addition, the environment in
which software development and maintenance is undertaken directly
influences the SQA components (see Chapter 1). SQA system components
can be classified into six classes:

Pre-project components. To assure that (a) the project commitments

have been adequately defined considering the resources required, the
schedule and budget; and (b) the development and quality plans have
been correctly determined.

Components of project life cycle activities assessment. The project

life cycle is composed of two stages: the development life cycle stage and
the operation–maintenance stage. The development life cycle stage
components detect design and programming errors. Its components are
divided into the following four sub-classes:

– Reviews

– Expert opinions

– Software testing.

The SQA components used during the operation–maintenance phase

include specialized maintenance components as well as development life
cycle components, which are applied mainly for functionality improving
maintenance tasks. An additional sub-class of SQA project life cycle
components deals with assuring 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 objectives of these components, which are applied throughout
the 584 Components of software quality assurance system entire
organization, are to eliminate or at least reduce the rate of errors, based
on the organization’s accumulated SQA experience.

Components of software quality management. This class of

components is geared toward several goals, the major ones being the
control of development and maintenance activities and the introduction of
early managerial support actions that mainly prevent or minimize
schedule and budget failures and their outcomes.
Components of standardization, certification, and SQA system
assessment. These components implement international professional
and managerial standards within the organization. The main objectives of
this class are (a) utilization of international professional knowledge, (b)
improvement of coordination of the organizational quality systems with
other organizations, and (c) assessment of the achievements of quality
systems according to a common scale. The various standards may be
classified into two main groups: (a) quality management standards, and
(b) project process standards.

Organizing for SQA – the human components. The SQA

organizational base includes managers, testing personnel, the SQA unit
and practitioners interested in software quality (SQA trustees, SQA
committee members and SQA forum members). All these actors
contribute to software quality; their main objectives are to initiate and
support the implementation of SQA components, detect deviations from
SQA procedures and methodology, and suggest improvements.

4.2 Pre-project components

The SQA components belonging here are meant to improve the

preparatory steps taken prior to initiating work on the project itself:

■ Contract review

■ Development and quality plans.

4.2.1 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. An internal order may entail a request for developing a
firmware software system to be embedded within a hardware product, an
order for a software product to be sold as a package, or an order for the
development of administrative software to be applied within the company.
In all these instances, the development unit is committed to an agreed-
upon functional specification, budget and schedule. Accordingly, contract
review activities must include a detailed examination of (a) the project
proposal draft and (b) the contract drafts. Specifically, contract review
activities include:

■ 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.

4.2.2 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”). These plans include additional details and needed
revisions based on prior plans that provided the basis for the current
proposal and contract. It is quite common for several months to pass
between the tender submission and the signing of the contract. During
this period, changes may occur in staff availability, in professional
capabilities, and so forth. The plans are then revised to reflect the
changes that occurred in the interim.

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.

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.

4.3 Software project life cycle components

The project life cycle is composed of two stages: the development life
cycle stage and the operation–maintenance stage. 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:

■ Reviews ■ Expert opinions ■ Software testing ■ Software maintenance ■

Assurance of the quality of the subcontractors’ work and the customer
supplied parts.

4.3.1 Reviews

The design phase of the development process produces a variety of

documents. The printed products include design reports, software test
documents, software installation plans and software manuals, among
others. Reviews can be categorized as formal design reviews (DRs) and
peer reviews.

4.3.2 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:

■ 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 such
situations, outside experts may join a DR committee or, alternatively, their
expert opinions may replace a DR. 624 Components of software quality
assurance system

■ In small organizations or in situations characterized by extreme work

pressures, an outside expert’s opinion can replace an inspection.

■ Temporary inaccessibility of in-house professionals (waiting will cause

substantial delays in the project completion schedule).
■ In cases of major disagreement among the organization’s senior
professionals, an outside expert may support a decision.

4.3.3 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 (systems).

4.3.4 Software maintenance components

Software maintenance services vary in range and are provided for

extensive periods, often several years. These services fall into the
following categories:

■ Corrective maintenance – User’s support services and correction of

software code and documentation failures.

■ Adaptive maintenance – Adaptation of current software to new

circumstances and customers without changing the basic software
product. These adaptations are usually required when the hardware
system or its components undergo modification (additions or changes).

■ Functionality improvement maintenance – The functional and

performance-related improvement of existing software, carried out with
respect to limited issues.

The main SQA components employed in the quality assurance of the

maintenance system are as follows.

Pre-maintenance components

■ Maintenance contract review

■ Maintenance plan.

Software development life cycle components

These components are applied for functionality improvement and adaptive

maintenance tasks, activities whose characteristics are similar to those of
the software development process.

Infrastructure SQA components

■ Maintenance procedures and instructions

■ Supporting quality devices

■ Maintenance staff training, retraining, and certification

■ Maintenance preventive and corrective actions

■ Configuration management

■ Control of maintenance documentation and quality records

Managerial control SQA components

■ Maintenance service control

■ Maintenance quality metrics

■ Maintenance quality costs.

4.4 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.

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.

4.4.1 Procedures and work

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.

4.4.2 Supporting quality devices

One way to combine higher quality with higher efficiency is to use

supporting quality devices, such as templates and checklists. These
devices, based as they are on the accumulated knowledge and experience
of the organization’s development and maintenance professionals,
contribute to meeting SQA goals by:
■ Saving the time required to define the structure of the various
documents or prepare lists of subjects to be reviewed.

■ Contributing to the completeness of the documents and reviews.

■ Improving communication between development team and review

committee members by standardizing documents and agendas.

4.4.3 Staff training, instruction and certification

■ 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.

4.4.4 Preventive and corrective actions

Systematic study of the data collected regarding instances of failure and

success contributes to the quality assurance process in many ways.
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.

4.4.5 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 (usually lasting several years) in order to cope with the
needed corrections, adaptations to specific customer requirements,
application improvements, and so forth.

4.4.6 Documentation control

SQA requires the application of measures to ensure the efficient long-term

availability of major documents related to software development
(“controlled documents”)

■ Definition of the types of controlled documents needed

■ Specification of the formats, document identification methods, etc.

■ Definition of review and approval processes for each controlled

document
■ Definition of the archive storage methods.

4.5 Management SQA components

Managerial SQA components support the managerial control of software

development projects and maintenance services. Control components
include:

■ Project progress control (including maintenance contract control)

■ Software quality metrics

■ Software quality costs.

4.5.1 Project progress control

The main objective of project progress control components is to detect the

appearance of any situation that may induce deviations from the project’s
plans and maintenance service performance.

Project control activities focus on:

■ Resource usage ■ Schedules ■ Risk management activities ■ The

budget.

4.5.2 Software quality metrics

■ Quality of software development and maintenance activities ■

Development teams’ productivity ■ Help desk and maintenance teams’
productivity ■ Software faults density ■ Schedule deviations.

4.5.3 Software quality costs

The quality costs incurred by software development and application are,

according to the extended quality costs model, the costs of control
(prevention costs, appraisal costs, and managerial preparation and control
costs) combined with the costs of failure (internal failure costs, external
failure costs, and managerial failure costs)

4.6 SQA standards, system certification, and assessment

components

(1) Utilization of international professional knowledge. (2) Improvement of

coordination with other organizations’ quality systems. (3) Objective
professional evaluation and measurement of the achievements of the
organization’s quality systems

4.6.1 Quality management standards

The organization can clearly benefit from quality standards of the second
sub-class that guide the management of software development,
maintenance, 694.6 SQA standards, system certification, and assessment
components and infrastructure.

The most familiar examples of this type of standard are: ■ SEI CMM
assessment standard ■ ISO 9001 and ISO 9000-3 standards.

4.6.2 Project process standards

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.

4.7 Organizing for SQA – the human components

■ To develop and support implementation of SQA components. ■ To detect

deviations from SQA procedures and methodology. ■ To suggest
improvements to SQA components.

4.7.1 Management’s role in SQA

■ Definition of the quality policy ■ Effective follow-up of quality policy

implementation 704 Components of software quality assurance system ■
Allocation of sufficient resources to implement quality policy ■ Assignment
of adequate staff ■ Follow-up of compliance of quality assurance
procedures ■ Solutions of schedule, budget and customer relations
difficulties.

4.7.2 The SQA unit

This task can be broken down into a number of primary roles: ■

Preparation of annual quality programs ■ Consultation with in-house staff
and outside experts on software quality issues ■ Conduct of internal
quality assurance audits ■ Leadership of quality assurance various
committees ■ Support of existing quality assurance infrastructure
components and their updates, and development of new components.

4.7.3 SQA trustees, committees and forums

Their contributions include: ■ Solving team or unit local quality problems ■

Detecting deviations from quality procedures and instructions ■ Initiating
improvements in SQA components ■ Reporting to the SQA unit about
quality issues in their team or unit.

SQA committee members are members of various software development

and maintenance units, and are usually appointed for term or ad hoc
service.
 The main issues dealt with by the committees are: ■ Solution of software
quality problems. ■ Analysis of problem and failure records as well as
other records, followed by initiation of corrective and preventive actions
when appropriate. ■ Initiation and development of new procedures and
instructions; updating existing materials. ■ Initiation and development of
new SQA components and improvement of existing components.

Development and quality plans

To sum up, the project needs development and quality plans that:

■ Are based on proposal materials that have been re-examined and

thoroughly updated.

■ Are more comprehensive than the approved proposal, especially with

respect to schedules, resource estimates, and development risk
evaluations.

■ Include additional subjects, absent from the approved proposal.

■ Were prepared at the beginning of the project to sound alerts regarding

scheduling difficulties, potential staff shortages, paucity of development
facilities, problems with meeting contractual milestones, modified
development risks, and so on.

6.1 Development plan and quality plan Objectives

Planning, as a process, has several objectives, each of which is meant to

prepare adequate foundations for the following:

(1)Scheduling development activities that will lead to the successful and

timely completion of the project, and estimating the required
manpower resources and budget. (2) Recruiting team members and
allocating development resources (according to activity schedules and
manpower resource requirement estimates). (3) Resolving
development risks. (4) Implementing required SQA activities. (5)
Providing management with data needed for project control.
6.2 Elements of the development plan
The following elements, each applicable to different project
components, comprise a project development plan.
(1) Project products
The development plan includes the following products: ■ Design
documents specifying dates of completion, indicating those items to
be delivered to the customer (“deliverables”) ■ Software products
 (specifying completion date and installation site) ■ Training tasks
(specifying dates, participants and sites).
(2) Project interfaces: Project interfaces include: ■ Interfaces
with existing software packages (software interface) ■ Interfaces
with other software and/or hardware development teams that are
working on the same system or project (i.e., cooperation and
coordination links) ■ Interfaces with existing hardware (hardware
interface).
(3)Project methodology and development tools to be applied at
each phase of the project

4) Software development standards and procedures :A list

should be prepared of the software development standards and
procedures to be applied in the project.

(5) The mapping of the development process

Mapping of the development process involves providing detailed

definitions of each of the project’s phases. These descriptions include
definitions of inputs and outputs, and the specific activities planned.
Activity descriptions include:

(a) An estimate of the activity’s duration. These estimates are highly

dependent on the experience gained in previous projects. (b) The
logical sequence in which each activity is to be performed, including
a description of each activity’s dependence on previously
completed activities. (c) The type of professional resources required
and estimates of how much of these resources are necessary for
each activity.
6) Project milestones
For each milestone, its completion time and project products
(documents and code) are to be defined.
(7) Project staff organization
The organization plan comprises:
■ Organizational structure: definition of project teams and their
tasks, including teams comprised of a subcontractor’s temporary
workers. ■ Professional requirements: professional certification,
experience in a specific programming language or development
tool, experience with a specific software product and type, and so
forth.

(8) Development facilities

Required development facilities include hardware, software and hardware

development tools, office space, and other items. For each facility, the
period required for its use should be indicated on the timetable.
(9) Development risks

Typical development risks are: ■ Technological gaps – Lack of adequate

and sufficient professional knowledge and experience to carry out the
demands of the development contract. ■ Staff shortages – Unanticipated
shortfalls of professional staff. ■ Interdependence of organizational
elements – The likelihood that suppliers of specialized hardware or
software subcontractors, for example, will not fulfill their obligations on
schedule

(10) Control methods

In order to control project implementation, the project manager and the

department management apply a series of monitoring practices when
preparing progress reports and coordinating meetings

(11) Project cost estimation

Project cost estimates are based on proposal costs estimates, followed by

a thorough review of their continued relevance based on updated human
resource estimates, contracts negotiated with subcontractors and
suppliers, and so forth.