it sqap plan for easier implementation.

1. Appendix A
Software Development and
Quality Assurance Process
Standards
A.1 Introduction – standards and their use
One can easily imagine professionals asking themselves questions like:
“Should SQA standards be implemented in our organization and software
projects? Wouldn’t it be preferable to apply our experience and professional
knowledge and employ the procedures and methodologies that best suit our
organization?”
Despite the legitimacy of pondering on such issues, it is widely accepted
that the benefits gained from standardization are far beyond those reaped from
professional independence.
To introduce the subject, let us refer to the following issues:
• The benefits of using standards
• The organizations involved in standards development
• The classification of standards
A.1.1 The benefits of using standards
The main benefits gained by the use of standards (benefits that are not expected
in organizations who embrace a high level of professional independence) are
listed in the Frame A.1:
Software Quality: Concepts and Practice, First Edition. Daniel Galin.
 2018 the IEEE Computer Society, Inc. Published 2018 by John Wiley & Sons, Inc.
563

2. 564 Appendix A: Software Development and Quality Assurance
Frame A.1: The benefits of using standards
• The ability to apply for software projects and department’s software development
and maintenance of the state-of-the-art methodologies and procedures of the highest
professional level.
• Better mutual understanding and coordination among development teams, and espe­
cially between development and maintenance teams.
• Better cooperation between the software developer and external participants in the
project.
• Better understanding and cooperation between software suppliers and customers/
acquirers, based on the adoption of known development, maintenance, and quality
assurance standards.
These advantages, together with the growing complexity and scope of soft­
ware projects, have prompted a wider application of standards in the industry.
A.1.2 The organizations involved in standards
development
Development of SQA standards has been undertaken by several national and
international standards institutes; professional and industry-oriented organiza­
tions that invest substantial resources in the development and updating of stan­
dards projects.
The following institutes and organizations are among the most prominent
developers of SQA and software engineering standards, and have gained interna­
tional reputation and standing in this area:
• IEEE (Institute of Electrical and Electronics Engineers) Computer Society
• ISO (International Organization for Standardization)
• ANSI (American National Standards Institute)
• IEC (International Electrotechnical Commission)
• EIA (Electronic Industries Alliance)
The last two decades saw rapid development in international SQA stan­
dards. This was expressed through increasing comprehensive coverage of related
topics, which also led to a greater understanding of the standards and the need
for them. Also, currently a great part of the efforts in development of new and
updating standards is carried out as “joint ventures” of two or more of these
major organizations, a trend that promotes internationalization of standards.
Examples of such “joint ventures” are the standards issued by the IEEE/ANSI,
the ISO/IEC, and the IEEE/ISO. Examples of “mergers” of three institutes are:
• ISO/IEC/IEEE 90003-2014 (ISO, 2014) – Software engineering – Guide­
lines for the application of ISO 9001:2008 to computer software

3. A.1 Introduction – Standards and Their Use 565
• ISO/IEC/IEEE 15504:2012 – Information technology – Process assessment
• ISO/IEC/IEEE 12207:2008 – Systems and software engineering – Soft­
ware life cycle processes
Another parallel and growing trend is the adoption of international standards
as national standards by national standards institutes. This trend further supports
internationalization.
The above developments inaugurated a trend toward the application of soft­
ware industry standards worldwide.
A.1.3 Classification of SQA standards
Software development and quality assurance standards can be classified into two
main classes:
• Process standards. Standards of this class focus on methodologies for
carrying out software development and maintenance projects, and assure
their quality, that is, on “how” a software project is to be implemented.
These standards define: steps to be taken, design documentation require­
ments, the contents of design documents, design reviews and review
issues, software testing to be performed, testing topics, and so forth. Natu­
rally, due to their characteristics, many standards in this class can serve as
software engineering and SQA textbooks versa.
• Management standards. Standards of this class focus on the organi­
zation’s software development and SQA management infrastructure
and requirements, while leaving the choice of methods and tools to
the organization. By complying with quality management standards,
organizations can steadily assure that their software products achieve
an acceptable level of quality. Some current software development ten­
ders require participants to be certified with one of the quality manage­
ment standards.
The characteristics of the two classes of standards are summarized in
Table A.1.
As could be anticipated, standards vary in their scope; from comprehen­
sive standards that cover all (or almost all) aspects to specialized standards
that deal with one specific area or issue. The ISO/IEC/IEEE Std.90003 Stan­
dard and ISO/IEC/IEEE Std. 12207 and IEEE Std. 730 Standard are exam­
ples of comprehensive standards that cover all aspects of software quality
management and the software development life cycle, respectively. Examples
of specialized standards of both classes may be found in IEEE software engi­
neering standards, such as the IEEE 1012 Standard for software quality
assurance verification.

4. 566 Appendix A: Software Development and Quality Assurance
Table A.1 Classes of standards – comparison
Characteristics Process standards Management standards
The target unit A software development and/or
maintenance project team
The main focus Methodologies for carrying out
software development and
maintenance projects
Standard’s “How” to perform
objective
Standard’s goal Assuring the quality of a
specific software project.
Examples IEEE 730 Standard
ISO/IEC/IEEE12207
Standard
IEEE 1012 Standard
Management of software
development and/or maintenance
and the specific SQA units.
Organization of SQA systems,
infrastructure, and requirements
“What” to achieve
Assuring supplier’s software quality
and assessing its software process
capability
ISO/IEC/IEEE 90003
Standard
SEI CMMI
ISO/IEC 15504 Standard
The next two chapters discuss some of the most commonly used software
quality assurance standards from each of the two classes.
• Appendix A is dedicated to software development and quality assurance
process standards.
• Appendix B is dedicated to software development management standards.
A review of systems engineering standards is presented by Guey-Shin et al.
(2008).
This chapter deals with the following standards:
• IEEE Std. 730: Standard for software quality assurance
• ISO/IEC/IEEE Std. 12207: Establishing common framework for processes
• IEEE Std. 1012: On verification and validation
A.2 IEEE Std. 730-2014 Standard for software
quality assurance
The IEEE Std. 730-2014 (IEEE, 2014) presents requirements that cover all
aspects of software quality assurance; initiation, planning, control, and execution
for the full life cycle of a software project.
A.2.1 IEEE Std. 730 concepts
The concepts expressed in this standard deal with six basic issues:
1. Applicability of the standard – The standard applies to software proj­
ects of all sizes and types; whether new, enhanced, or being actively
maintained.

5. A.2 IEEE Std. 730-2014 Standard for Software Quality Assurance 567
2. Users of standard – The standard serves all participants in a software
life cycle of software and system products, suppliers, developers, opera­
tion and maintenance staff, project managers, and SQA staff.
3. Levels of standard’s task implementation – The standard specifies
three classes of implementation:
Requirement – the user of the standard must conform with this task
(shall tasks).
Recommendations – the user is recommended to implement these tasks
(should tasks).
Might tasks – optional requirements to be considered by the user (may
tasks).
4. Achieving compliance to the standard – An organization achieves
compliance to the standard by performing the standard requirements
(shall tasks).
5. Alignment with software development standard – The standard is
aligned with ISO/IEC/IEEE Std. 12207-2008 (ISO/IEC/IEEE, 2008) and
ISO/IEC/IEEE Std. 15289-2011.
6. Standard adaptability by tailoring – The SQA unit may adapt the stan­
dard to the specific characteristics of the development or maintenance
project. A process of tailoring may take place and omit part of the stan­
dards requirements. Tailoring is limited to tasks mentioned in Sections
5.4 and 5.5 of the standard.
A.2.2 IEEE Std. 730-2014 – structure
The first four clauses of the standard deal with:
• Overview
• Normative references
• Definitions, acronyms, and abbreviations
• Key concepts of software quality assurance
The main part of the standard (Clause 5), describing the SQA processes,
activities, and tasks, is grouped into three major areas:
• SQA process implementation activities
• Product assurance activities
• Process assurance activities
The standard includes 12 appendices, of which I will mention six:
• Appendix C: Guidance to creating a software quality assurance plan
(SQMP). The appendix, holding 36 pages reflects the great importance
attached to preparing an SQAP by the IEEE Std. 730).
• Appendix E: Applying IEEE Std. 730:2014 to specific industries.
• Appendix F: SQA’s relationships to agile development methods.
• Appendix H: Validating software tools.

6. 568 Appendix A: Software Development and Quality Assurance
• Appendix J: Examples of corrective actions, preventive actions, and root
cause analysis processes
• Appendix L: Bibliography of this standard.
A.2.3 IEEE Std. 730-2014 – contents
A total of 16 activities comprise the SQA process. The list of SQA activities is
presented in Frame A.2.
Frame A.2: IEEE Std. 730-3014 SQA activities
Source: IEEE Std. 730-3014
SQA activity title
SQA process implementation activities
• Establish the SQA processes
• Coordinate with related software processes
• Document SQA planning
• Execute the SQA plan
• Manage SQA record
• Evaluate organizational independence and objectivity
Product assurance activities
• Evaluate plans for conformance to contracts, standards, and regulations
• Evaluate product for conformance to established requirements
• Evaluate product for acceptability
• Evaluate product lifecycle support for conformance
• Measure products
Process assurance activities
• Evaluate life cycle processes and plans for conformance
• Evaluate environment for conformance
• Evaluate subcontractors for conformance
• Measure processes
• Assess staff skills and knowledge
The standard provides comprehensive description for each of the activities.
Description of activity
The description of each activity of the standard has a fixed format that includes:
• The text of ISO/IEC/IEEE Std. 12207:2008 relevant to the activity, pre­
senting the conformance of the IEEE Std. 750-2014 with Std. 12207.
• Purpose of the activity.

7. A.2 IEEE Std. 730-2014 Standard for Software Quality Assurance 569
• Outcomes: Specific results of the successful implementation of the activ­
ity, such as documentation, a change of project constraint. The number of
activity outcomes varies between 3 and 8.
• Tasks: Specific actions required to achieve the purpose of the activity.
The activity tasks include required (shall), recommended (should),
and might (may) tasks. The number of activity tasks varies between 2
and 13.
An example of an activity description is presented in Frame A.3.
Frame A.3: IEEE Std. 730-2014 activity description – an example
Source: IEEE Std. 730-2014 Section 5.5.3
Activity: Evaluate environment conformance
This subclause addresses the following ISO/IEC/IEEE 12207:2008 subclause:
7.2.3.3.3.2 It shall be assured that the internal software engineering practices, develop­
ment environment, test environment, and libraries comply with the contract.
Purpose
Determine whether software engineering environment (SEE) and software test envi­
ronment (STE) conform to project process and plans.
Outcomes
This activity shall produce the following outcomes:
– Software engineering environments are consistent with project plans.
– Software test environments are consistent with project plans.
– Nonconformances are raised when software engineering environment do not con­
form to project plans.
– Nonconformances are raised when software test environment do not conform to
project plans.
Tasks
To accomplish this activity, the SQA function shall perform the following tasks:
1. Review the software engineering environment used by the project team to deter­
mine whether they conform to the contract.
2. Review the software engineering libraries used by the project team to determine
whether they conform to the contract.
3. Review the software test environment used by the project team to determine
whether they conform to the contract.

8. 570 Appendix A: Software Development and Quality Assurance
A.3 ISO/IEC Std. 12207-2008: system and software
engineering – software life cycle processes
ISO/IEC/IEEE Std. 12207-2008 (ISO/IEC, 2008) provides a framework that
incorporates the entire spectrum of software life cycle processes.
The objectives of the 12207-2008 Standard can be summarized thus:
• To establish an internationally recognized model of common software
life cycle processes that can be referenced by the software industry
worldwide to facilitate communication among acquirers, suppliers, and
other stakeholders.
• To serve all participants in a software life cycle: acquirers of software and
system products, suppliers, developers, operation and maintenance staff,
managers, SQA staff, and product users.
• To promote understanding among business parties by applying commonly
recognized processes, activities, and tasks.
A discussion of the various aspects of implementing the standard is the sub­
ject of a considerable number of papers. I will mention several. The implementa­
tion of the standard to small and medium enterprises (SME) is presented by
Laporte et al. (2006) and Laporte et al. (2008). The issues of application of the
standard for open-source software is discussed by Krishnamurthy and O’Connor
(2013). Clarke et al. (2012) and Clarke and O’Connor (2010) present the aspects
of software process improvement (SPI) activities included in the standard.
The subject of product management and reuse are discussed by Stallinger and
Neumann (2012).
The following sections present the standard’s concepts and contents.
A.3.1. 12207 Standard: concepts
The concepts expressed in this standard deal with 10 basic issues:
1. Applicability to every participant in the software life cycle. The
standard applies to all participants in the software life cycle: buyers,
suppliers, developers, operators, and maintenance professionals. It
provides separate definitions of processes, activities, and tasks for
each role.
2. Adaptability of the standard. Organizations are encouraged to tailor
the standard to their needs by omitting irrelevant or unsuitable elements.
The remaining processes, activities, and tasks thus become the standard
for that particular project. Tailoring the standard allows it to be applica­
ble to a large variety of software projects: large, highly complex as well
as small, simple projects, stand-alone projects, and projects that

9. A.3 ISO/IEC Std. 12207-2008: System and Software Engineering 571
represent parts within extensive systems. Also, tailoring supports the
applicability of the standard to fit all parties, whether external customers
(within customer–supplier relationships) or internal customers (devel­
oped for other departments within the organization).
3. Flexibility and responsiveness to technological changes. The stan­
dard instructs its users “how to” perform activities, but does not
specify “exactly how to” perform the activities”, that is, it leaves
room for users to choose their own life cycle model, development
tools, software metrics, project milestones, and documentation stan­
dards. Despite this freedom, the standard’s highly detailed tasks, as
well as required level of conformance to its principles, are firmly
imposed. Benefits of the “how to” approach include a reduction of
the user’s dependence on a specific technology, a feature that intro­
duces flexibility and enhances responsiveness to changes in informa­
tion technology (software and hardware).
4. Relationship between software and systems. The standard establishes
a strong link between a system and its software, where software is an
integral part of the total system. It is implemented by the strong rela­
tionship with the 15288 system life cycle processes international
standard.
5. Applicability to software products and services. The standard applies
to software products and software services.
6. Nature of evaluation task. The standard requires evaluating entities
and their objectives through defined criteria.
7. Absence of organizational structure requirements. The standard does
not imply a certain organizational structure. The processes of the stan­
dard may serve a wide range of organizations, large or small, where
each organization may select an appropriate set of processes and
activities.
8. Evaluation, verification, and validation. The standard requires that the
performer of a life cycle task evaluates the product of the task. An addi­
tional evaluation will be provided by verification and validation con­
ducted by the buyer, the supplier, or another participator.
9. Life cycle models and stages. The standard allows a range of life cycle
models comprised of sequences of stages that may overlap and iterate,
as appropriate for the project characteristics. Each stage is defined a pur­
pose and an outcome.
10. Absence of certification requirements. The standard does not require
certification of the developer organization; a fact that supports its world­
wide acceptance. It should be noted that the international standard
90003, which does require certification, is closely coordinated with the
international standard 12207.

10. 572 Appendix A: Software Development and Quality Assurance
A.3.2 12207 Standard: contents
The main body of the 12207-2008 Standard is dedicated to a description of the
processes, activities, and tasks of the software life cycle:
The software life cycle architecture outlined in the 12207-2012 Standard is
structured as a five-level tree composed of:
1. Process classes: System context processes and software-specific pro­
cesses. Each process class includes 3–4 process categories.
2. Process categories: A total of seven categories are defined. Each process
category includes 2–11 processes.
3. Processes: A total of 43 processes are defined for the 7 process categories.
4. Activities
5. Tasks
The three upper levels of the standard’s process architecture, namely, the
process classes, the process categories, and their integral processes, are illus­
trated in a fishbone diagram in Figure A.1.
The standard provides comprehensive definitions of the tasks comprising
each activity. Comprehensiveness is realized in the number of tasks assigned to
each activity and the level of detail characterizing the descriptions. An example
of the tasks of an activity is presented in Frame A.4.
Frame A.4: Standard 12207 activity’s tasks description – an example
Source: ISO/IEC Std. 12207-2008
Activity: Contract agreement (Standard section 6.1.1.3.4)
The activity consists of the following three tasks:
1. The acquirer may involve other parties, including potential suppliers or any neces­
sary third parties (such as regulators), before contract award, in determining the
acquirer’s requirements for tailoring of this international Standard for the project.
In making this determination, the acquirer shall consider the effect of the tailoring
requirements upon the supplier’s organizationally adopted processes. The acquirer
shall include or reference the tailoring requirements in the contract.
2. The acquirer shall then prepare and negotiate a contract with the supplier that
addresses the acquisition requirements, including the cost and schedule, of the
software product or service to be delivered. The contract shall address proprietary,
usage, ownership, warranty, and licensing rights associated with the reusable off-
the-shelf software products.
3. Once the contract is underway, the acquirer shall control changes to the contract
through negotiation with the supplier as part of a change contract mechanism.
Changes to the contract shall be investigated for impact on project plans, costs,
benefits, quality, and schedule.

11. A.3 ISO/IEC Std. 12207-2008: System and Software Engineering 573
Figure A.1 ISO/IEC Std. 12207-2008 – a fishbone diagram
The standard includes nine annexes. Three of these are dedicated to the fol­
lowing issues:
• Annex A – Discusses the various aspects of the tailoring process.
• Annex B – Process reference model for assessment purposes, presents
conformance of the 12207 standard with the 15404-2 international stan­
dard: information technology – process attribute – number 2: performance
management.

12. 574 Appendix A: Software Development and Quality Assurance
• Annex D – ISO/IEC 12207 and ISO/IEC 15288 process alignment pres­
ents the relationships between the processes of both these standards.
A.4 IEEE Std. 1012-2012 systems and software
verification and validation
A.4.1 Introduction
The IEEE Std.1012-2012 (IEEE, 2012) is a process that defines all SQA activi­
ties throughout the entire software life cycle as V&V activities. The standard
requires the application of V&V activities for system, software, and hardware
processes as well as for managerial and administrative processes. As such, it
became a comprehensive broad standard, and includes hundreds of SQA activi­
ties and tasks to be performed during the software life cycle. The IEEE Std.
1012 deals with the processes applied to determine whether a software product
conforms to its requirements specifications (verification) and whether it satisfies
the objectives of its intended use (validation).
The current standard version, IEEE Std. 1012-2012, is the fourth version,
first issued in 1986. The following standard versions were issued in 1998 and
2004.
The IEEE Std. 1012 presented in this section was chosen as an example of
the collection of IEEE typical software engineering standards, dedicated to a
wide variety of software engineering topics. Each of the IEEE typical standards
deals with a specific phase of the software cycle, a methodology or process in
the software life cycle process. The standards are updated once every 5–10
years, when the updating process by technical committees is completed.
Typical examples are presented in Table A.2.
In addition to typical software engineering standards, the IEEE develops
and adopts several international comprehensive standards that deal with the
entire software life cycle or the whole range of managerial activities throughout
the entire software life cycle. A great part of these standards is developed in
cooperation with other standard institutes or adopted from these institutes, that
is, ISO/IEC/IEEE Std. 12207 and ISO/IEC/IEEE Std. 90003.
The objectives of the IEEE Std. 1012 are:
• To help developers introduce quality into the software system during the
software life cycle.
• To establish a common framework for V&V activities and tasks for soft­
ware life cycle processes.
• To define V&V processes to provide an objective assessment of the prod­
uct and processes to demonstrate whether these are correct, complete,
accurate and consistent, and also conform with relevant requirements and
satisfy their intended use and user needs.

13. A.4 IEEE Std. 1012-2012 Systems and Software Verification and Validation 575
Table A.2 Examples to IEEE typical standards
Standard code Standard name
IEEE Std. 610.12-1990 Glossary of Software Engineering Terminology
IEEE Std. 828-2012 Configuration Management – Systems and Software
Engineering
IEEE Std. 829-2008 Software Test Documentation
IEEE Std. 982.1-2005 IEEE Dictionary of Measures to Produce Reliable Software
IEEE Std. 1012-2012 Software Verification And Validation
IEEE Std. 1016-2009 IEEE Recommended Process for Software Design
Descriptions
IEEE Std. 1028-2008 Software Reviews
IEEE Std. 1061-1998 Software Quality Metrics Methodology
IEEE Std. 1175.4-2008 CASE tools Interconnections Reference Model for
Specifying System Behavior
IEEE Std. 1233-1998 Guide for Developing System Requirement Specifications
IEEE Std. 1420.1b-1999 Information Technology - Software Reuse, Data Model for
Reuse Library Interoperability: Intellectual Property
A.4.2 IEEE Std. 1012-2012 concepts
The concepts expressed in IEEE 1012-2012 address six basic issues:
1. Broad definition of V&V activities
Broad definition of V&V activities enables the standard to embrace
all SQA activities performed throughout the software life cycle, relating
to management, systems, software, and hardware.
2. Integrity levels system performance
“Major” – A function that affects important system performance.
“Moderate” – A function that affects system performance; however,
availability of an alternative method of operation enables the system
to overcome the associated difficulties.
“Low” – A function that affects system performance only by inconven­
iencing the user.
The standard requires that integrity levels be assigned to components
as early as the software V&V plan (SVVP) is prepared.
3. Minimum V&V tasks
The standard defines the minimum tasks required for each integrity
level, and includes tables of optional task selection for each integrity
level.
4. Detailed criteria for V&V tasks
The standard includes criteria for each V&V task, including mini­
mum criteria for correctness, consistency, completeness, accuracy,

14. 576 Appendix A: Software Development and Quality Assurance
readability, and testability. The V&V task descriptions include a list of
required inputs and outputs.
5. Intensity and rigor applied to V&V tasks
According to the standard, the intensity and rigor applied to the
V&V tasks vary according to the integrity level, the higher the integrity
level, the higher the required intensity and rigor applied to the V&V task.
6. Detailed criteria for V&V tasks
The V&V task descriptions include a list of required inputs and out­
puts. They also include specific quantitative criteria for each V&V task,
including minimum criteria for correctness, consistency, completeness,
accuracy, readability and testability.
7. Compliance and compatibility to international standards
The IEEE Std. 1012-2012 standard defines the V&V processes to
conform to the international life cycle standards ISO/IEC/IEEE Std.
12207-2008 and ISO/IEC/IEEE Std. 15388-2008, as well as to the entire
group of IEEE typical software engineering standards.
A.4.3 IEEE Std. 1012-2012 contents
a. Processes, activities, and tasks
The main body of IEEE 1012-2012 is dedicated to a description of
the processes, activities, and tasks of the software life cycle.
The software life cycle architecture presented in the standard is
structured as a three-level tree composed of:
• Processes
• Activities
• Tasks
The processes covered by the standard are classified as:
1. Common processes
2. System processes
3. Software processes
4. Hardware processes
The description of each process includes the requisite 1–6 activities,
while 3–10 tasks are assigned to each activity. The common processes
include verification and validation activities of management, acquisition,
supply planning, project planning, and configuration planning. The verifi­
cation and validation activities for systems, software, and hardware relate
to the entire variety of software systems development, including concept
definition, requirements analysis, design, implementation, transition, reg­
ular operation, maintenance efforts, and finally disposal of used systems.
The task descriptions provided by the standard are very detailed and
include task details and required inputs and outputs. An example of a
task description is shown in Frame A.5.

15. A.4 IEEE Std. 1012-2012 Systems and Software Verification and Validation 577
Frame A.5: IEEE Std. 1012 task description – an example
Source: IEEE Std. 1012:2012
Process: Common V&V activities
Activity 7.3: Supply planning V&V
Task (2): Contract verification
Task description Required input Required output
Verify the following 1. V&V Plan (VVP) 1. Task(s) reports
characteristics of the contract: 2. RFP of tender 2. Contract
1. System requirements (from 3. Contract verification
RFP or tender and contract)
satisfy and are consistent
with user needs.
4. Supplier development
plans and schedules
3. Updated VVP
4. Anomaly report(s)
2. Procedures are documented
for managing requirement
changes and for identifying
management hierarchy to
manage problems.
3. Procedures for interface and
cooperation among the
parties are documented,
including ownership,
warranty, copyright, and
confidentiality.
4. Acceptance criteria and pro­
cedures are documented in
accordance with requirement.
The standard defines four integrity levels, where the higher the integrity
level, the greater the number of tasks assigned to the pertinent activity.
Accordingly, the standard presents tables as follows:
• Minimum V&V – task assigned to each integrity level
• Optimal V&V – technical suggested applications in implementation process
b. Reporting, administrative, and documentation requirements
The next chapter of the standard is dedicated to reporting, administra­
tive and documentation requirements and includes lists of required reports.
c. Outline of the V&V plan (VVP)
A detailed outline of the V&V plan is presented in the following
discussion.
The comprehensive scope of the required VVP is well demonstrated
by its outline (template). For the VVP to conform to the standard’s

16. 578 Appendix A: Software Development and Quality Assurance
Table A.3 IEEE Std.1012-2012’s V&V plan outline (template)
1 Purpose
2 Referenced Documents
3 Definitions
4 V&V Overview
4.1 Organization
4.2 Master Schedule
4.3 Integrity Level Scheme
4.4 Resources Summary
4.5 Responsibilities
4.6 Tools, Techniques, and
Methods
5 V&V Overview
5.1 Common V&V processes, activities and tasks
5.2 System V&V processes, activities and tasks
5.3 Software V&V processes, activities and tasks
5.4 Hardware V&V processes, activities and tasks
6 V&V reporting requirements
6.1 Test reports
6.2 Anomaly reports
6.3 V&V final reports
6.4 Special studies report (optional)
6.5 Other reports (optional)
7 Administrative requirements
7.1 Anomaly resolution and reporting
7.2 Task iteration policy
7.3 Deviation policy
7.4 Control procedures
7.5 Standards, practices and conventions
8 V&V test documentation requirements
Source: IEEE Std. 1012:2012
requirements, planners have to thoroughly understand the software sys­
tem and ascertain the professional, administrative, and resource issues
implicit in the V&V project as planned. Table A.3 presents the outline
for the VVP document as required by the IEEE Std.1012.
For each section and subsection of the VVP outline, the IEEE 1012
supplements provide detailed definitions of the requisite contents.
The standard includes 10 informative annexes that present a great vari­
ety of subjects. Five of the annexes are dedicated to the following topics:
Annex D: V&V of reuse software
Annex E: V&V measures. Included are V&V measures for evaluating
anomaly density, effectiveness, and efficiency
Annex I: V&V of system, software, and hardware integration
Annex J: Hazard, security, and risk analysis

17. Summary 579
Summary
1. The concepts underlying IEEE Std. 730-2014
a. Applicability of the standard
The standard applies to software projects of all sizes and types;
whether new, enhanced, or being actively maintained.
b. Users of standard
The standard serves all participants in a software life cycle:
acquirers of software and system products, suppliers, developers,
operation and maintenance staff, project managers, and SQA staff.
c. Levels of standard’s task implementation
The standard specifies three classes of implementation:
Requirement – the user of the standard must conform with these
tasks (shall tasks).
Recommendations – the user is recommended to implement these
tasks (should tasks).
Might tasks – optional requirements to be considered by the user
(may tasks).
d. Achieving compliance to the standard
An organization achieves conformance compliance to the stan­
dard by performing the standard requirements (shall tasks).
e. Alignment with software development standard
The standard is aligned with ISO/IEC/IEEE Std. 12207-2008
and ISO/IEC/IEEE Std. 15289-2011.
f. Standard adaptability by tailoring
The SQA unit may adapt the standard to the specific character­
istics of the development or maintenance project by a process of lim­
ited tailoring.
2. The content of the IEEE Std. 730-2014
The standard defines 16 activities to be performed by the SQA unit.
These activities are divided into three areas:
• SQA process implementation activities – processes to be implemented
by the SQA unit/team.
• Product assurance activities – evaluation activities for products of
software development projects.
• Process assurance activities – activities of evaluation of processes
employed by software development project teams comply with the
standard.
3. The concepts underlying IEEE/EIA Std. 12207-2008
a. Applicability and adaptability of the standard
The standard is applicable to all participants in the software life
cycle for projects that vary in size and complexity. Much of its broad
applicability is due to tailoring within the limits allowed to users.

18. 580 Appendix A: Software Development and Quality Assurance
b. Flexibility and responsiveness to technological changes
The standard instructs “how to do” and not “exactly how to
do” a project; hence, users can choose their life cycle model,
development tools, software metrics, project milestones, and
product and documentation standards. As a consequence, this
approach contributes to reduced dependency on specific technolo­
gies, coupled with increased responsiveness to technological
change.
c. Software links with its system
The standard establishes strong links between the software and
the system of which it is a part in each phase of the life cycle. The
standard is implemented with a strong relationship with the ISO/IEC
15288 system’s life cycle international standard.
d. Nature of evaluation tasks
The standard requires that an evaluation of entities (process,
activity, report, etc.) with the associated objectives be conducted
against their defined criteria. An additional evaluation will be pro­
vided by verification and validation conducted by the buyer, the sup­
plier, or others.
e. Life cycle models and stages
The standard allows a range of life cycle models comprised of a
sequence of stages that may overlap and iterate, as appropriate for
the project characteristics, where each stage is defined by objective
and outcome.
f. Absence of certification of developer organizations
The standard does not require certification of the developer
organization.
4. The concepts underlying of IEEE Std. 1012.
a. A broad definition of V&V activities
The standard provides a broad review of the V&V activities to
be performed throughout the software life cycle. These include:
reviews, tests, evaluations, risk analyses, hazard analyses, retirement
assessments, and so on.
b. Software integrity levels and adapted V&V requirements
The standard identifies four integrity levels – high, major, mod­
erate, and low – according to the criticality of the software function,
module, or unit. Graded requirements are attuned to the integrity
level. The standard requires that integrity levels be assigned to com­
ponents as early as the SVVP.
c. Minimum V&V tasks
The standard defines the minimum tasks required for each integ­
rity level, and includes tables of optional task selection for each
integrity level.

19. Selected Bibliography 581
d. Detailed criteria for V&V tasks
The V&V task descriptions include a list of required inputs and
outputs. They also include specific quantitative criteria for each
V&V task, including minimum criteria for correctness, consistency,
completeness, accuracy, readability, and testability. The V&V task
descriptions include a list of required inputs and outputs.
e. Detailed criteria for V&V tasks
The V&V task descriptions include a list of required inputs and
outputs. It also includes specific quantitative criteria for each V&V
task, including minimum criteria for correctness, consistency, com­
pleteness, accuracy, readability, and testability. The V&V task
descriptions include a list of required inputs and outputs.
f. Compliance and compatibility to international standards
The IEEE Std. 1012-2012 defines the V&V processes to con­
form to the international life cycle standards; ISO/IEC/IEEE Std.
12207-2008 and ISO/IEC/IEEE Std. 15388-2008 as well as the
entire group of IEEE topical software engineering standards.
g. Recognition of special characteristics of V&V of reusable
software
The difficulties of performing V&V activities for reusable soft­
ware are recognized, and possible directions for performing V&V
activities are shown.
5. Explain the essence of the SVVP as required by IEEE Std.1012.
The SVVP is designed to thoroughly delineate a plan for V&V
activities that will include all aspects of their performance, including
the schedule, resources, responsibilities, tools, and techniques to be
used. In addition, the SVVP documents administrative directions con­
cerning anomaly resolution procedures, task iteration and deviation
policies, performance control procedures, and the standard practices
and conventions that have to be applied. Special instructions are
given for documentation.
Selected bibliography
Clarke P. and O’Connor R. V. (2010) Harnessing ISO/IEC 12207 to Examine the Extent of SPI
Activity in an Organization, Proceedings of the 17th Conference on European Systems, Software
and Services Process Improvement, CCIS, Vol. 99, Springer, Berlin, Germany, pp. 25–36.
Clarke P., O’Connor R. V., and Yilmaz M. (2012) A Hierarchy of SPI Activities for Software SMEs:
Results from ISO/IEC 12207-Based SPI Assessments, Proceedings of the 12th International Con­
ference on Software Process and Capability Conference (SPICE’12), CCIS Vol. 290, Springer,
Berlin, Germany, pp. 62–74.
Guey-Shin C., Horng-Linn P., and Jer-Nan J. (2008) A review of systems engineering standards and
processes, Journal of Biomechanics Engineering, Vol. 1, No. 1, pp. 71–85.

20. 582 Appendix A: Software Development and Quality Assurance
IEEE (2012) IEEE Std. 1012–2012 - IEEE Standard for System and Software Verification and Vali­
dation, The IEEE Computer Society, IEEE, New York, NY.
IEEE (2014) IEEE Std. 730–2014 Software Quality Assurance, The IEEE Computer Society, IEEE,
New York.
ISO/IEC/IEEE (2008) ISO/IEC/IEEE Std. 12207-2008 – Systems and Software Engineering - Soft­
ware Life Cycle Processes, ISO – International Organization for Standardization, Geneva,
Switzerland.
ISO (2014) ISO/IEC 90003:2014 Software Engineering – Guidelines for the Application of TSO
9001: 2008 to Computer Software, International Organization for Standardization (ISO), Geneva,
Switzerland.
Krishnamurthy A. and O’Connor R. V. (2013) Using ISO/IEC 12207 to Analyze Open Source Soft­
ware Development Processes: An e-Learning Case Study, Proceedings of the 13th International
Conference on Software Process Improvement and Capability Determination (SPICE 2013), CCIS
Vol. 349, Springer, Berlin, Germany, pp. 1–12.
Laporte C. Y., April A., and Renault A. (2006) Applying ISO/IEC software engineering standards in
small settings: historical perspectives and initial achievements, in Proceedings of SPICE 2006
Conference, Luxembourg, May 2006, pp. 1–5.
Laporte C. Y., Alexandre S., and O’Connor R. V. (2008) A software engineering lifecycle standard
for very small enterprises, Software Process Improvement. Communications in Computer and
Information Science, Vol. 16, No. 2, pp. 129–141.
Stallinger F. and Neumann R. (2012) Extending ISO/IEC 12207 with Software Product Management:
A Process Reference Model Proposal, Communications in Computer and Information Science,
Vol. 290, Springer, Berlin, Germany, pp. 93–106.
Review questions
A.1 Two classes of standards dealing with software development and quality assurance
are discussed in the book: process standards and management standards.
• Explain the difference between these two classes.
A.2 The IEEE Std.730-2014 presents six concepts.
• Explain these concepts in your own words.
A.3 The IEEE Std.730-2014 divides its activities into three areas.
• Explain the difference between the SQA process implementation activities and the
product and process assurance activities, regarding methods of implementation
and relationships with the software development project teams.
A.4 ISO/IEC/IEEE Std.12207-2008 is considered an international standard.
a. Explain, in your own words, why this status is warranted.
b. Explain the importance of international standards.
A.5 The initiators of Std. 12207 were highly interested in the broad applicability of the
standard.
• Name concept topics contributing to its broad applicability, and explain the way
these topics contribute to the applicability.

21. Topics for Discussion 583
A.6 Consider the purpose of the IEEE Std.1012-2012.
• Explain, in your own words, the purpose of the standard.
A.7 The 2012 version of the IEEE Std. 1012 incorporates system and software V&V
activities.
• Explain the contribution of both system and software V&A activities in the same
standard.
Topics for discussion
A.1 One of the concepts of IEEE Std. 730-2014 is its alignment with ISO/IEC/IEEE Std.
12207-2008 and ISO/IEC/IEEE Std. 15289-2011.
a. How does the alignment contribute to an SQA unit’s activities?
b. How does the alignment contribute to software product quality?
A.2 IEEE Std. 730-2014 assigns a special activity and an annex to SQA planning.
• What is the special importance of the SQA planning?
A.3 The annual SQA plan is usually required to be revised several times a year.
a. List events that warrant revising the annual SQA plan.
b. What are some possible results of failing to revise the SQA plan following an
event or events listed in your above answer.
A.4 The 10 concepts at the foundation of the ISO/IEC/IEEE Std. 12207-2008 are listed
in Section A.3.2.
• Examine the concepts and determine which of these contributes most to the stan­
dard’s wide applicability. Explain your choice.
A.5 IEEE/EIA Std. 12207-2008 sets three levels of tasks: requirements, recommenda­
tions, and permissible tasks. These represent levels of conformance to the standard’s
requirements.
a. Explain, in your own words, the significance of each level.
b. Discuss the contribution made by the clear definition of these levels.
A.6 IEEE Std.1012-2012 dedicates a special appendix to V&V of reusable
software.
a. List the kind of software that is considered to be “reusable.”
b. Explain the special characteristics of “reusable software” in relation to V&V
activities.
c. List what you consider to be options for overcoming the difficulties inherent in
performing V&V for reusable software.

22. 584 Appendix A: Software Development and Quality Assurance
A.7 Some senior system analysts claim that as a result of their experience, the VVP
required in the IEEE Std. 1012-2012 is simply a “waste of time,” and that a develop­
ment (project) plan should suffice.
a. Do you agree with this claim?
b. List the arguments backing your position. Base them on a comparison of the con­
tents of the two document templates (a VVP and a project plan).
A.8 The IEEE Std. 1012 includes the notion “level of integrity.”
a. Address the contribution of the “level of integrity” to the effectiveness of the
standard’s prescribed V&V activities.
b. How does the notion “level of integrity” influence the standard’s applicability?