|
Overview
of ISO/IEC 12207:2008 System and software engineering --- Software life cycle
processes standard
ISO/IEC
12207:2008 establishes a common framework for software life cycle processes,
with well-defined terminology, that can be referenced by the software
industry. It contains processes, activities, and tasks that are to be applied
during the acquisition of a software product or service and during the supply,
development, operation, maintenance and disposal of software products.
Software includes the software portion of firmware.
ISO/IEC
12207:2008 applies to the acquisition of systems and software products and
services, to the supply, development, operation, maintenance, and disposal of
software products and the software portion of a system, whether performed
internally or externally to an organization. Those aspects of system
definition needed to provide the context for software products and services
are included.
ISO/IEC
12207:2008 also provides a process that can be employed for defining,
controlling, and improving software life cycle processes.
The processes, activities and tasks of
ISO/IEC
12207:2008 - either alone or in conjunction with ISO/IEC 15288 - may also be
applied during the acquisition of a system that contains software
Introduction
to the checklist
The process of defining what is necessary for compliance with a software
engineering process standard such as “ISO/IEC Standard 12207 Software Life
Cycle Processes” is often confusing and laborious because the directions
contained in the standards are unclear or ambiguous.
To aid in determining what is actually “required” by the document
in the way of physical evidence of compliance, the experts at SEPT have
produced this checklist. This checklist is constructed around a classification scheme
of physical evidence comprised of policies, procedures, plans, records,
documents, audits, and reviews. There
must be an accompanying record of some type when an audit or review has been
accomplished. This record would
define the findings of the review or audit and any corrective action to be
taken. For the sake of brevity
this checklist does not call out a separate record for each review or audit.
All procedures should be reviewed but the checklist does not call out a
review for each procedure, unless the standard calls out the procedure review.
In this checklist “manuals, reports, scripts and specifications”
are included in the document category. When
the subject standard references another standard for physical evidence, the
checklist does not call out the requirements of the referenced standard.
SEPT has
carefully reviewed the document “ISO/IEC Standard 12207:2008 Software Life
Cycle Processes” and
identify the physical evidence required based upon this classification
scheme. SEPT has conducted a second review of the complete list to
ensure that the documents’ producers did not leave out a physical piece of
evidence that a “reasonable person” would expect to find. It could certainly be argued that if the document did not
call it out then it is not required; however if the standard was used by an
enterprise to improve its process, then it would make sense to recognize
missing documents. Therefore,
there are documents specified in this checklist that are implied by the
standard, though not specifically called out in the document, and they are
designated by an asterisk (*) throughout this checklist.
If a document is called out more than one time, only the first
reference is stipulated.
There
are occasional situations in which a procedure or document is not necessarily
separate and could be contained within another document.
For example, the Software Detail Specification Document could be a
subset of Software Design Specification.
SEPT has called out these individual items separately to ensure that
the organization does not overlook any facet of physical evidence.
If the organization does not require a separate document, and an item
can be a subset of another document or record, then this fact should be
denoted in the detail section of the
checklist for that item. This should be done in the form of a statement reflecting
that the information for this document may be found in section XX of Document
XYZ. If the organizational
requirements do not call for this physical evidence for a particular project,
this should also be denoted with a statement reflecting that this physical
evidence is not required and why. The
reasons for the evidence not being required should be clearly presented in
this statement. Further details
on this step are provided in the Detail Steps section of the introduction.
The size of these documents could vary from paragraphs to volumes
depending upon the size and complexity of the software project or business
requirements.
"General Principles of the
standard ISO/IEC 12207:2008 - Software Life Cycle Processes" Checklist
This checklist was
prepared by analyzing each clause of this draft document for the key words
that signify a:
-
Policy
-
Procedure
-
Plan
-
Records
-
Document ( Including Manuals, Reports, Scripts and Specifications)
-
Audit
-
Review
This checklist
specifies evidence that is software or system unique.
After reviewing the completed document, the second review was conducted
from a common sense “reasonable man” approach.
If a document or other piece of evidence appeared to be required, but
was not called out in the document, then it is added with an asterisk (*)
after its notation in the checklist. The
information was transferred into checklist tables, based on the type of
product or evidence.
Using the Checklist
When a company is
planning to use “ISO/IEC Standard 12207:2008 Software Life Cycle
Processes” as their main software
process standard, the company should review the evidence checklist.
If the company’s present process does not address an “ISO/IEC
12207:2008 Software Life Cycle Processes product, then this question should be
asked: “Is the evidence product required for the type of software the
business is producing? If in the
view of the company the evidence is not required, the rationale should be
documented and inserted in the checklist and quality manual.
This rationale should pass “the
reasonable person rule.” If
the evidence is required, plans should be prepared to address the missing
item(s).
Detail Steps
An enterprise should
compare the proposed output of their software project or organization against
the checklist. In doing this,
they will find one of five conditions that exist for each item listed in the
checklist. The following five
conditions and the actions required by these conditions are listed in the
table below.
|
