|
Sample Pages | RCGLOBAL |
|
|
| Introduction
The process of defining what is necessary for compliance with a system engineering process standard such as “ISO/IEC Standard 15288 System 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. The 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 unless it is a normative reference or the words appear “for further reference”. The document “ISO/IEC Standard 15288 System Life Cycle Processes” and Amendment 1 has been carefully reviewed and the physical evidence required was defined 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 System Detail Specification Document could be a subset of System Architecture Design Specification Document. These individual items have been 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 system project or business requirements. General Principles of the ISO/IEC Standard 15288 System Life Cycle
Processes Checklist
Using the Checklist
Detail Steps
|
|
|
|
| 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:
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. |
|
CLAUSE NUMBER and NAME |
|
|
|
|
|
| 3.0 Normative references |
|
|
|
|
|
| 5.0 System Life Cycle Process | |||||
| 5.1 Introduction | |||||
| 5.2 Agreement Processes | |||||
| 5.2.1 Introduction | |||||
| 5.2.2 Acquisition Process |
|
|
|
|
|
| 5.2.3 Supply Process |
|
|
|
|
|
| 5.3 Enterprise Process | |||||
| 5.3.1 Introduction |
© 2002. Software Engineering Process Technology.
All rights reserved.