BACK to

MS WORD

PDF
   
  
Sample Pages
   

ISO/IEC 12207: 2008

   
Evidence Product Checklist  for the
standard
ISO/IEC 12207: 2008 System and Software Engineering
Software life cycle processes

   
Available in MS WORD format or PDF format
   
  

Overview of the checklist  
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.  This checklist was produced to aid in determining what is actually “required” by the document in the way of physical evidence of compliance.  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.    

After careful review of the document “ISO/IEC Standard 12207:2008 Software Life Cycle Processes”, the physical evidence required was identified based upon this classification scheme. A second review of the complete list was conducted 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. The individual items are called out 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.


Checklist
   
General Principles of the standard ISO/IEC 12207:2008
Software Life Cycle Processes
 

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

 

Condition
Action Required
1. The title of the documented evidence specified by the checklist (document, plan, etc) agrees with the title of the evidence being planned by the enterprise.  Record in checklist that the enterprise is compliant.
2. The title of the documented evidence specified by the checklist (document, etc) disagrees with the title of the evidence planned by the enterprise but the content is the same.  Record in the checklist the evidence title the enterprise uses and record that the enterprise is compliant, and the evidence is the same although the title is different. 
3. The title of the documented evidence specified by the checklist (document, etc) is combined with another piece of evidence.  Record in the checklist the title of the evidence (document, etc) in which this information is contained.
4. The title of the documented evidence specified by the checklist (document, etc) is not planned by the enterprise because it is not required. Record in the checklist that the evidence is not required and the rationale for this decision.
5. The title of the documented evidence called out by the checklist (document, etc) is not planned by the enterprise and should be planned by it. Record in the checklist when this evidence will be planned and reference a plan for accomplishing the task. 

 


Components of the Checklist 
This checklist is composed of 9 sections:
  • Section 1.  Introduction
  • Section 2.  Composites of all required and suggested “ISO/IEC 12207:2008 System Life Cycle Processes” evidence products.
  • Sections 3-8.  Individual checklists for each evidence type.
  • Section 9.  “About the Author”
   
Product Support 

All reasonable questions concerning this checklist or its use will be addressed free of charge for 60 days from time of purchase, up to a maximum of 4 hours consultation time.

 

ISO/IEC 12207:2008
Clause Number and Name

Policies And Procedures

Plans

Records  

Documents

Audits And Reviews

6.0 System Life Cycle Processes

 

 

 

 

 

6.1 Agreement Processes

 

 

 

 

 

6.1.1 Acquisition Process

·        Acceptance Document Procedure *

·        Acceptance Plan Procedure*

·        Acceptance Procedure*

·        Acquisition Requirements Document Procedure*

·        Acquisition Strategy Document Procedure*

·        Audit Plan Procedure*

·        Concept or Acquisition Need Document Procedure*

·        Acceptance Plan*

·        Acquisition Plan*

·        Audit Plan*

·        Off the Shelf Software (OTS) Support Plan*

·        Supplier Selection Plan*

 

·        Acquirer Payment Records*

·        Acquisition Advertisement Records

·        Acquisition Records*

·        Contract Change Records*

·        Off the Shelf Software (OTS) Receipt Records*

·        Supplier Selection Notification Records*

 

·        Acceptance Document*

·        Acquisition Requirements Document

·        Acquisition Strategy Document

·        Concept or Acquisition Need Document

·        Contract Milestone Document

·        Contract or Agreement Document

·        Off the Shelf Software (OTS) Document*

·        Acceptance Document Review*

·        Acquisition Plan Review*

·        Acquisition Requirements Document Review*

·        Acquisition Strategy Document Review*

·        Audit Plan Review*

·        Concept or Acquisition Need Document Review*

6.1.1 Acquisition Process (Cont. 1)

·        Contract Milestone Document Procedure*

·        Contract or Agreement Document Procedure*

·        Contract Preparation Procedure*

·        Off the Shelf Software (OTS) Document's Procedure *

·        Off the Shelf Software (OTS) Support Plan Procedure*

·        Off the Shelf Software (OTS) Upgrade Procedure *

 

 

·        Purchasing Requirements Document*

·        Purchasing Specification Document*

·        Contract Change Review*

·        Contract Milestone Document Review*

·        Contract Milestone Review

·        Contract or Agreement Document Review*

·        Milestone Reviews and Audits

·        Off the Shelf Software (OTS) Document Review*

·        Off the Shelf Software (OTS) Support Plan Review*

6.1.1 Acquisition Process (Cont. 2)

·        Purchasing Requirements Document Procedure*

·        Purchasing Specification Document Procedure*

·        Review Plan Procedure*

·        Supplier Selection Plan Procedure*

·        Supplier Selection Procedure*

 

 

 

·        Purchasing Requirements Document Review*

·        Purchasing Specification Document Review*

·        Supplier Selection Plan Review*