Chapter 5

Templates
In other areas of work, a template is “a gauge, pattern or mold (as a thin plate or board) used as a guide to the
form of a piece being made” (Webster’s New College Dictionary).
Three examples of templates are presented in the following frames:
■ Software test plan (STP)
■ Software test description (STD)
■ Frame 10.4: Software test report (STR).
A total of 22 DIDs are available for the users of MILSTD-498, for instance:
■ Software Requirements Specification (SRS)
■ System/Subsystem Design Description (SSDD)
■ Computer Operator Manual (COM)
■ Interface Design Description (IDD)
■ Software Test Plan (STP)
■ Software Version Description (SVD).
5.1.1 The contribution of templates to software quality
Template use is quite advantageous to development teams and to review teams.
For development teams, template use:
■ Facilitates the process of preparing documents by saving the time and energy required to elaborate the
report’s structure.
■ Ensures that documents prepared by the developer are more complete as all the subjects to be
included in the document have already been defined and repeatedly reviewed by numerous professionals
over the course of the Template’s use.
■ Provides for easier integration of new team members through familiarity.
■ Facilitates review of documents by eliminating the need to study a document’s structure and confirm its
completeness, if the document is based on the appropriate template.
■ Enables easier location of the information required for performing maintenance tasks.
Updating checklists
Like templates and procedures, initiatives to update an existing checklist generally flow from the following
sources:
■ User proposals and suggestions
■ Changes in technology, areas of activity and clientele
■ Proposals initiated by design review and inspection teams emanating from document reviews
■ Analysis of failures as well as successes
■ Other organizations’ experience
■ SQA team initiatives.
The process of updating checklists is quite similar to their preparation
 (1) Explain the main contribution of templates to software quality assurance.
■ Documents submitted for review tend to be more complete. As a result, review teams can direct their
efforts to further improvement of the final product.
■ Document reviews are facilitated as their structure is standard and well known among reviewers. Freed of
structural concerns, reviewers can focus on issues of document content.

(2) Explain the main contributions of checklists to software quality assurance.

■ Checklists support document completeness and improve document quality as all the relevant items and
quality issues to be reviewed are already listed.
■ Conduct of review sessions becomes less problematic when topics and their order of priority are defined
and well known. An efficient session is expected to carry out a thorough analysis of comments by reviewers.
(3) List the activities involved in maintaining templates and checklists.
The activities involved in maintaining state-of-the-art compilations of template and checklist collections
include preparation, implementation and updating. ration and updating for both types of document is the
work of groups of interested staff, including those who have already offered informal templates and
checklists to their colleagues. Leadership of the group is usually an SQA unit obligation. The group
members decide on target lists of templates and checklists, which they later try to complete.

Chapter 6

Software configuration, its items and its management

The definitions of software configuration items and software configuration versions are presented as
Software configuration, its items and its management The definitions of software configuration items and
software configuration versions are presented as given below.

Software configuration item (SCI) or configuration item (CI)

An approved unit of software code, a document or piece of hardware that is designed for configuration
management and treated as a distinct entity in the software configuration management process.
■ SCI version
The approved state of an SCI at any given point of time during the development or maintenance process.
■ Software configuration version
An approved selected set of documented SCI versions that constitute a software system or document at a
given point of time, where the activities to be performed are controlled by software configuration
management procedures.
. The SCIs are generally placed into four classes, as follows:
■ Design documents
■ Software code
■ Data files, including files of test cases and test scripts
■ Software development tools.
A list of common types of SCIs is presented as
Common types of software configuration items
Design documents
■ Software development plan (SDP)
■ System requirements document
■ Software requirements document (SRD)
■ Interface design specifications
■ Preliminary design document (PDD)
■ Critical design document (CDD)
■ Database description
■ Software test plan (STP)
■ Software test procedure (STPR)
■ Software test report (STR)
■ Software user manuals
■ Software maintenance manuals
■ Software installation plan (SIP)
■ Software maintenance requests (including problem reports)
■ Software change requests (SCRs) and software change orders (SCOs)
■ Version description document (VDD)
Software code
■ Source code
■ Object code
■ Prototype software
Data files
■ Test cases and test scripts
■ Parameters, codes, etc.
Software development tools
(the versions applied in the development and maintenance stages)
■ Compilers and debuggers
■ Application generators
■ CASE tools
Note: The SQA component under whose heading all the activities necessary to attend to the availability and
accuracy of information regarding all aspects of a software configuration is called software configuration
management (SCM), sometimes referred to simply as configuration management (CM).
The tasks of software configuration management
The tasks of software configuration management may be classified into four groups:
■ Control software change
■ Release of SCI and software configuration versions

■ Provision of SCM information services

■ Verification of compliance to SCM procedures.

Approval to carry out proposed changes

Once the baseline version of the software system becomes operational, it is just a matter of time before
proposals for changes begin to flow.
The factors affecting the decision whether to implement a proposed change include:
■ Expected contribution of the proposed change
■ Urgency of the change
■ Effect of the proposed change on project timetables, level of service, etc.
■ Efforts required in making the change operational
■ Required software quality assurance efforts
■ Estimated required professional resources and cost of performing the change.
Software change request (SCR) document – a template
(1) Change principles
■ The initiator
■ The date the SCR was presented
■ The character of the change
■ The goals
■ The expected contribution to the project/system
■ The urgency of performance
(2) Change details
■ Description of the proposed change
■ A list of the SCIs to be changed
■ Expected effect on other SCIs
■ Expected effect on interfaces with other software systems and hardware firmware
■ Expected delays in development completion schedules and expected disturbances to services to customers

(3) Change timetable and resources estimates

■ Timetable for implementation

■ Estimated required professional resources
■ Other resources required
■ Estimated total cost of the requested change

Release of software configuration versions

The need to release a new software configuration version usually stems from one or more of the following
conditions:
■ Defective SCIs
■ Special features demanded by new customers
■ The team’s initiatives to introduce SCI improvements.
A discussion of the following issues, all of which are part of the process of software configuration version
release, occupy the remainder of this section:
■ Types of software configuration releases
■ Software configuration management plans (SCMPs)
■ Software configuration evolution models
■ Documentation of software configuration versions.
Types of software configuration releases

Among software configuration releases, baseline versions, intermediate versions and revisions are
considered to be the three main types of release.
Baseline versions
Baseline software configuration versions are planned early, during a system’s development or operating
stage. As part of the process, they are reviewed, tested and approved, as are their SCIs
Intermediate versions
When problems arise that require immediate attention – such as the need to correct defects identified in an
important SCI, or perform immediate adaptations as defined in a contract with a new customer – an
intermediate version of the software is often prepared.
Revisions
Revisions introduce minor changes and corrections to a given software configuration version. In some cases,
several successive revisions are released before a new baseline version is released.

Numeration conventions for identification of SCI and software versions

Numeration conventions have been formulated to identify SCIs; the most commonly used is decimal
numeration, which indicates the successive version and revision numbers and is registered accordingly.

Software configuration evolution models

Successive development or evolution of a software system’s configuration versions should be undertaken
according to a route that is planned in advance by the system’s developer.
■ The linear evolution model
According to the linear model, only one unique software system’s configuration version serves all customers
at any given time. Each new configuration version then replaces the prior version.
■ The tree evolution model
According to this model, several parallel versions of the software are developed to serve the needs of
different customers simultaneously throughout the system’s life cycle.

Documentation of software configuration versions

Within the framework of software configuration management, the project manager must see to it that all
documentation tasks are properly performed.
SCI version document – a template Identification
■ SCI Version number
■ Name(s) of software engineer(s) who implemented the change
■ Date the new version was completed and approved
Changes in the new version
■ Former SCI version number
■ Short description of the introduced changes
■ List of other SCIs that had to be changed as a result of the current changes
■ List of SCOs included in the new version
■ List of software problem reports resolved by the new version
■ Operational as well as other implications of the changes introduced in the new version
Software configuration release documentation – VDD template
Identification and installations
■ Release version and revision number
■ Date of the new version’s release
■ List of installations where the release was entered (site, date, name of technician who installed the
version), if applicable
Configuration of the released version
■ List of SCIs in the released version, including identification of each SCI version
■ List of hardware configuration items required for operating the specified version, including specification
of each hardware configuration item
■ List of interfacing software systems (including version) and hardware systems (including model)
■ Installation instructions for the new release
Changes in the new version
■ Previous software configuration version
■ List of SCIs that have been changed, new SCIs introduced for the first time, and deleted SCIs
■ Short description of introduced changes
■ Operational and other implications of changes introduced in the new release
Further development issues
■ List of software system problems that have not been solved in the new version
■ List of SCRs and proposals for development of the software system for which implementation of
development was delayed

(1) Define software configuration version.

A software configuration version is an approved set of the SCI versions that constitute a documented
software system at a given point of time. The respective activities are controlled by software configuration
management procedures.
(2) Explain the tasks of software configuration management.
Software configuration management tasks are classified into the following four groups:
■ Control of software change
■ Release of SCI and software configuration versions
■ Provision of SCM information services
■ Verification of compliance to SCM procedures.
(3) List the main tasks of software change control.
The main tasks of software change management can be described as:
■ Examining change requests and approving implementation those requests that qualify.
■ Controlling the changes and assuring the quality of approved changes.
■ Documenting the approved changes.
■ Applying mechanisms that prevent more than one team from simultaneously introducing changes into the
same SCI.
4: Explain the difference between baseline and intermediate software configuration versions.
Baseline versions are configuration versions that are planned ahead, during a system’s development or
operating stage. As part of the process, baseline versions are also reviewed and approved. As a rule, they
serve as milestones in the software system’s life cycle.
Intermediate versions are software configuration versions released, in most cases, to respond to immediate
needs. These may range from correction of defects identified in an important SCI to swift introduction of
adaptations to meet a new customer’s requirements. As expected, intermediate versions will not receive the
attention and efforts typically invested in baseline versions.
(5) Explain the objectives of software configuration management plans.
The main objective of a software configuration management plan (SCMP) is to plan ahead the required
resources to carry out all the activities required for the software configuration releases. An additional
objective of the SCMP is to enable one to follow up the progress of activities involved in software version
release. SCMPs are required during the development stage as well as the operation (maintenance) stage.
(6) Describe the nature of the tasks performed in software configuration management audits.
SCM audits are based on checking the tasks performed for samples of change requests, SCIs, and software
configurations. Typical checks included in SCM audits include the percentage of cases of compliance with
procedures or, alternatively, of failure to comply with procedures.

Chapter 7

Main objectives of software quality metrics

1: To facilitate management control as well as planning and execution of the appropriate managerial
interventions. Achievement of this objective is based on calculation of metrics regarding:
■ Deviations of actual functional (quality) performance from planned performance
■ Deviations of actual timetable and budget performance from planned performance.
2: To identify situations that require or enable development or maintenance process improvement in the
form of preventive or corrective actions introduced throughout the organization. Achievement of this
objective is based on:
■ Accumulation of metrics information regarding the performance of teams, units,

The first classification category distinguishes between life cycle and other phases of the software system:
■ Process metrics, related to the software development process
■ Product metrics, related to software maintenance
■ KLOC – this classic metric measures the size of software by thousands of code lines.
.
Software development process metrics can fall into one of the following categories:
1. Software process quality metrics
2. Software process timetable metrics
3. Error removal effectiveness metrics
4. Software process productivity metrics.
Software process quality metrics may be classified into two classes:
■ Error density metrics
■ Error severity metrics.

Three classes of error severity and their relative weights are also defined:
The code error summary for the department’s Atlantis project indicated there were 42 low severity errors,
17 medium severity errors, and 11 high severity errors. Calculation of NCE and WCE gave these results.
Error severity metrics
The metrics belonging to this group are used to detect adverse situations of increasing numbers of severe
errors in situations where errors and weighted errors, as measured by error density metrics, are generally
decreasing. Two error severity metrics are presented in Table 7.2
Table 7.2:. Error severity metrics

Q1: Explain the objectives of software quality metrics.

Software quality metrics are implemented:
■ To support control of software development projects and software maintenance contracts. Their aim is to
provide management with information regarding:
– Compliance with functional (quality) performance requirements
– Compliance with project timetable and budget.
■ To deliver the metrics accumulated and analyzed by the CAB. Use of these metrics data is aimed at
enabling preventive and corrective actions throughout the organization.

Q2:List the requirements for successful software quality metrics.

Applicability of quality metrics is determined by the degree to which the following general and operative
requirements are fulfilled:
General requirements
■ Relevant – measures an attribute of considerable importance
■ Valid – measures the required attribute
■ Reliable – produces similar results when applied in similar conditions
■ Comprehensive – applicable to a large variety of situations
■ Mutually exclusive – does not measure attributes already measured by other metrics.
Operative requirements
■ Easy and simple – data collection is implemented with minimal resources
■ Does not require independent data collection – metrics data collection is based on currently employed data
collection systems, e.g. employee attendance records, cost accounting methods
■ Immune to biased interventions by interested parties (team members and others).

Chapter 8

Q:1 ISO 9000-3 quality management system: guiding principles

(1) Customer focus. Organizations depend on their customers and therefore should understand current and
future customer needs.
(2) Leadership. Leaders establish the organization’s vision.
(3) Involvement of people. People are the essence of an organization; their full involvement, at all levels of
the organization, enables their abilities to be applied for the organization’s benefit.
(4) Process approach. A desired result is achieved more efficiently when activities and resources are
managed as a process.
(5) System approach to management. Identifying, understanding and managing processes, if viewed as a
system, contribute to the organization’s effectiveness and efficiency.
(6) Continual improvement. Ongoing improvement of overall performance should be high on the
organization’s agenda.
(7) Factual approach to decision making. Effective decisions are based on the analysis of information.
(8) Mutually supportive supplier relationships. An organization and its suppliers are interdependent; a
mutually supportive relationship enhances the ability of both to create added value.

. The new ISO 9000-3 (ISO/IEC, 2001) offers a new structure, with its 22 requirements classified into
the following five groups:
■ Quality management system
■ Management responsibilities
■ Resource management
■ Product realization
■ Management, analysis and improvement.

Organizations wishing to obtain ISO 9000-3 certification are required to complete the following:
■ Develop the organization’s SQA system
■ Implement the organization’s SQA system
■ Undergo certification audits.

(1) Explain the benefits of the use of SQA standards.

■ The ability to make use of the most sophisticated and comprehensive professional methodologies and
procedures
■ Better understanding and cooperation between users of the same standards:
– Between team members and between project teams
– Between software developers and external participants in the project
– Between suppliers and customers.

(2) Describe the contributions made by the use of standards.

■ Provision of superior professional methodologies for use in the development process and for its
management
■ Provision of SQA certification services based on independent professional quality audits
■ Provision of tools for “self-assessment” of achievements in planning and operating an organization’s SQA
system.

(3) Describe the general principles underlying quality management according to ISO 9000-3.
■ Customer focus – understanding a customer’s current and future needs
■ Leadership exercised in the creation and maintenance of a positive internal environment in order to
achieve the organization’s objectives
■ Involvement of people at all levels to further organizational goals
■ Process approach – activities and related resources perceived and managed as a process
■ Systems approach to management – managing processes as a system
■ Continual improvement of the organization’s overall performance
■ Factual approach to decision-making – decisions based on the analysis of data and information
■ Mutually beneficial supplier relationships – emphasis on coordination and cooperation.

(4) Describe the ISO 9000-3 certification process.

To acquire ISO 9000-3 certification, organizations must:
■ Plan the organization’s activities for gaining certification
■ Develop the organization’s SQA system, including procedures
■ Obtain approval of procedures by the certifying organization
■ Implement the organization’s SQA system
■ Undergo certification audits of actual performance of the SQA system.

(5) Describe the principles embodied in the Capability Maturity Model (CMM).
■ Application of more highly elaborated software quality management methods increases the organization’s
capability to control quality and improve software process productivity
■ Application of the five levels of the CMM enables the organization to evaluate its achievements and
determine what additional efforts are needed to reach the next capability level
■ Process areas are generic, with the model defining “what” and leaving the “how” to the implementing
organizations, i.e., the choice of life cycle model, design methodology, software development tool,
programming language and documentation standard.

(6) Describe the principles that guided the developers of ISO/IEC 15504.
■ Harmonization of independent assessment methodologies by providing a conceptual framework based on
“what”, not “how.”
■ Universality of applicability to all or almost all categories of software suppliers and customer
organizations as well as software categories
■ Professionalism
■ Worldwide acceptance.