IEEE WG 12 Software Meeting
08
February 27, 2001
Final Meeting Minutes
The
eighth meeting of the working group was held on December 5th and 6th,
2000 at the Safetran offices in Rancho Cucamonga, CA.
The
agenda was accepted as distributed.
Document: sw agenda 08.
The
committee approved the minutes from meetings six and seven. Both sets of minutes will be posted on the
website.
The
next working group meeting will be on February 27th and 28th.
D.
Edgecomb-Cope will confirm availability of the Safetran facility.
T.
McGean stated that there are seven published standards and the committee is
working with APTA and transit research board to get these standards published
to transit community. The eighth standard “Environmental Conditions for Transit
Rail Car Electronic Equipment, should be approved in the near term by
IEEE. NJT is using the communications
protocol standard (standard 1473) and the data elements standard (standard
1544) for their car procurement. The committee is very eager to observe the
standards in action on this procurement and is looking for other transit
agencies to do the same.
B.
MacArthur questioned how our initiatives relate to ITS initiatives. T. McGean stated that the ITS initiatives
basically cover surface transportation.
There are clear crossovers with rail, for example, in the highway
crossings area. L. Denney suggested that the committee view ITS as an
inter-modal control system that handles all facets of transportation within a
corridor.
P.
Jamieson stated that the next full committee meeting is in Miami on February 12th
and 13th. P. Jamieson stated that the goal of meeting 8 is to discuss
modification to the draft standard such that it can be presented to the full
committee in February. The completed
draft standard must be submitted to the full committee for their review by Mid
January 2001 in preparation for the February 2001 meeting. A revision to the
draft standard would be required for the 2nd full committee meeting
of 2001. The completed standard would be required by the end of this year.
J-STD-016
will no longer be supported, therefore P1588 should not reference this
standard. The IEEE direction is to use 12207. The working group discussed
absorbing the text from J-STD-016 into standard P1588 as needed. T. McGean
stated that we need to verify whether we can extract verbiage from the
J-Std-016. To do so, we would need to contact the IEEE/EIA working group since
the standard is copyrighted. T. McGean
suggested that it may be easier to attach J-STD-016 in an annex to our
standard. T. McGean will contact the EIA to
determine what we are allowed to do with respect to this standard.
The
working group has access to a number of standards in PDF format. J. Corvin will inform the team on how to
extract text from Adobe Acrobat for insertion into P1588.
The working group walked through the draft standard and
modified language such that it can be presented to the full committee in
February 2001. The draft standard was updated during the course of meeting 8
with track changes turned on. A copy of
the updated draft is attached. Please note that this version will be
further updated for the February 2001 working group meeting.
Additional Modifications to the Standard (not yet made
during meeting 8) are as follows:
·
T.
McGean stated that bullets are not allowed within the body of the standard.
·
Remove
all text that states “in conformance with P1588”
·
Remove
the sentences that state “… shall comply with standard…”. The standard
compliance will be provided in table format and attached to the draft standard
for the February 2001 full committee meeting.
·
W.
MacArthur stated that P1588 should include a section that addresses consistency
among software documents. The working group agreed.
·
Remove
the documents that correspond to the gray boxes on the diagram (i.e. OCD,
SSS). The standard will no longer refer
to these documents; it will only refer to the system level activities that are
identified on the diagram.
·
Ensure
that “shall” language is used within the body of the standard instead of
“will”.
J.
Corvin stated that we need to discuss how CASE tools will effect the format and
content of the required deliverables.
We need to strike a balance by allowing the supplier to use his/her CASE
tool, and still meet the intent of our standard. It was suggested that the intent
to use the CASE tool documentation be defined within the SDP/SPMP or be
addressed within the tailoring guidelines within P1588.
The
diagram that will be inserted into P1588 shall be entitled “Software
development activities and associated documentation”. It should not be referred
to as a lifecycle diagram.
Modifications to the Software development activities and Associated Documentation diagram are as follows:
·
Remove
the documents associated with the gray boxes on the diagram. The standard will no longer refer to these
documents
·
A
note must be added on the diagram stating that the terminology used is drawn
from 12207.
· The diagram will be modified to change Software Item 2 to Software Item n.
L.
Karr will update standard based on the review conducted during the meeting.
P.
Jamieson to update diagram to use within the standard.
P.
Jamieson to draft a document template to be used for all documents.
T. Simon will discuss with J. McDermott the use of P1588 on an NYCT software project.
T. McGean will check with IEEE on how to add IEEE/EIA 12207 to our coordination effort and whether a PAR change is needed.
D. Edgecomb-Cope and S. Morar will review whether there are additional requirements and/or standards to be followed for Safety Critical Systems. For example, are there special V&V standards to be followed for safety critical systems? Refer to IEEE 1228 and 1483. This action item must be resolved before the February 2001 committee meeting.
B. MacArthur highly recommends that the working group
purchase and read a copy of the following: "Software Engineering
Standards, A User's Road Map" by James W. More. This book provides a good
introduction to the 4-volume set of IEEE standards. The book is available at “www.amazom.com”. It also describes how the various standards
relate to each other. It was suggested
to add this document to our list of references within our standard.
Day Two:
It was decided that if we are referencing sections within existing standards, then we should reference the date associated with the standard.
Document Reviews
S. Morar presented the template for development of the
SDP. S. Morar and his group need to evaluate
whether we can use IEEE 1058 SPMP as a basis for the description of the SDP.
J. Corvin presented the SQAP. It was decided that IEEE
730.1 (the guide) provides additional clarification to IEEE 730 (the standard)
and that our standard should not be solely dependent upon IEEE 730. J. Corvin
stated that there are a number of differences between IEEE 730 and IEEE 730.1. P. Jamieson will ask IEEE if an update to
730 is being worked on and if so, when it will be released, in hopes that the
guide will match the standard more closely. P. Jamieson also stated that he
will follow up on all standards that we are referencing from within our
standard to determine if there are outstanding PARs.
Other Actions
P. Jamieson will generate an agenda for the
February 2001 meeting, ASAP such that the transit authorities can get approval
60 days prior to this trip.
P. Jamieson to take the draft standard from
meeting 8 and update the reference standard listing to incorporate all
standards from the draft.
P. Jamieson to speak with T. Tougas on
whether he can lead the effort on the four maintenance documents.
P. Jamieson to remind L. Martinez of action
item 06.09.
T. Simon will provide a sample RTM from the
NYCT 63rd Street project for use in the RTM section of P1588.
W. MacArthur identified the following major issues that the working group must address in the near term:
· Legacy issues
· Software development tools
· COTS
· RTM
Presentations on SDP and SQAP are included.
The following table describes the content of the Software Development Plan (SDP) that is adopted from J-STD-016 –1995 for the Railway Software Development Standards. The table identifies sections that are needed for the Railway Software Development Standards and is complemented by additional information for sub-clauses and by introducing new subsections that are required for the Railway Software Standards.
Each of section defined in the J-STD 16 SDP has been assigned an attribute that identifies the requirements of each section as follows:
Mandatory: This means that the section is mandatory in the SDP document.
Highly Recommended: This means that the section is highly recommended and the rational for not including the section should be described Software Quality Plan or Project Management Plan.
Recommended: This means that the section is recommended.
|
Current J-STD 16 |
J-STD 16 SDP Content List |
Applicable to Railway Software Development
Standards |
Amendments to J-STD 16 For Railway Software Development Standards |
|
1.0 |
Scope |
Mandatory |
|
|
1.1 |
Identification |
Mandatory |
|
|
1.2 |
System Overview |
Mandatory |
Add following Subsections 1.2.1 Context Diagram 1.2.2 Functional Elements |
|
1.3 |
Document Overview |
Mandatory |
|
|
1.4 |
Relationship to Other Plans |
Mandatory |
|
|
2.0 |
Reference Documents |
Mandatory |
Add following Subsections 2.1 Abbreviations 2.2 Definitions |
|
3.0 |
Overview of Required Work |
Mandatory |
Add following Subsection 3.1 Software Artefacts 3.2 Deliverable Software Artefacts |
|
4.0 |
Plans for Performing General Software Development Activities |
Mandatory |
Addition to sub-clause. |
|
4.1 |
Software Development Process |
Mandatory |
Addition to sub-clause |
|
4.2 |
General Plans for Software Development |
Mandatory |
|
|
4.2.1 |
Software Development Methods |
Mandatory |
Add following Subsections 4.2.1.1 New Software 4.2.1.2 Reusable Software 4.2.1.3 Prototype Software |
|
4.2.2 |
Standards and Practice for Software Products |
Mandatory |
|
|
4.2.3 |
Traceability |
Mandatory |
Update to the sub-clause. Add following Subsections 4.2.3.1 New Software 4.2.3.2 Reusable Software |
|
4.2.4 |
Reusable Software Product |
Mandatory |
|
|
4.2.5 |
Handling of Critical Requirements |
Mandatory |
|
|
4.2.6 |
Computer Hardware Resource Utilisation |
Recommended |
|
|
4.2.7 |
Recording Rationale |
Highly Recommended |
|
|
4.2.8 |
Access for Acquire Review |
Highly Recommended |
|
|
5.0 |
Plans for Performing Detailed Software Development Activities |
Mandatory |
|
|
5.1 |
Project Planning and Oversight |
Mandatory |
|
|
5.1.1 |
Software Development Planning |
Mandatory |
|
|
5.1.2 |
Software Item Test Planning |
Mandatory |
This is Software Qualification Testing |
|
5.1.3 |
System Test Planning |
Highly Recommended |
|
|
5.1.4 |
Software Installation Planning |
Highly Recommended |
|
|
5.1.5 |
Software Transition Planning |
Highly Recommended |
|
|
5.1.6 |
Following and Updating Plans |
Mandatory |
Update to the sub-clause. |
|
5.2 |
Establishing a Software Development Environment |
Mandatory |
|
|
5.2.1 |
Software Engineering Environment |
Mandatory |
|
|
5.2.2 |
Software Test Environment |
Mandatory |
|
|
5.2.3 |
Software Development Library |
Recommended |
|
|
5.2.4 |
Software Development Files |
Recommended |
|
|
5.2.5 |
Non-Deliverable Software |
Recommended |
Update to the sub-clause |
|
5.3 |
System Requirements Definition |
Highly Recommended |
|
|
5.3.1 |
Analysis of User Inputs |
Highly Recommended |
|
|
5.3.2 |
Operational Concept |
Highly Recommended |
|
|
5.3.3 |
System Requirements |
Highly Recommended |
|
|
5.4 |
System Design |
Highly Recommended |
|
|
5.4.1 |
System-Wide Design Decisions |
Highly Recommended |
|
|
5.4.2 |
System Architectural Design |
Highly Recommended |
|
|
5.5 |
Software Requirements Definition |
Mandatory |
Add the following Subsections 5.5.1 New Software 5.5.2 Reusable Software |
|
5.6 |
Software Design |
Mandatory |
Add the following Subsections 5.6.1 New Software 5.6.2 Reusable Software |
|
5.6.1 |
Software Item-Wide Design Decisions |
Recommended |
|
|
5.6.2 |
Software Item Architectural Design |
Mandatory |
|
|
5.6.3 |
Software Item Detailed Design |
Mandatory |
|
|
5.7 |
Software Implementation and Unit Testing |
Mandatory |
|
|
5.7.1 |
Software Implementation |
Mandatory |
|
|
5.7.2 |
Preparing for Unit Testing |
Mandatory |
|
|
5.7.3 |
Performing Unit Testing |
Mandatory |
|
|
5.7.4 |
Revision and Re-testing |
Mandatory |
|
|
5.7.5 |
Analysing and Recording Unit test Results |
Mandatory |
|
|
5.8 |
Unit Integration and Testing |
Mandatory |
|
|
5.8.1 |
Preparing for Unit Integration and Testing |
Mandatory |
|
|
5.8.2 |
Performing Unit Integration and Testing |
Mandatory |
|
|
5.8.3 |
Revision and Re-testing |
Mandatory |
|
|
5.8.4 |
Analysing and Recording Unit Integration and Test Results |
Mandatory |
|
|
5.9 |
Software Item Qualification Testing |
Highly Recommended |
|
|
5.9.1 |
Independence in Software Item Qualification Testing |
Recommended |
|
|
5.9.2 |
Testing on Target Computer System |
Highly Recommended |
|
|
5.9.3 |
Preparing for Software Item Qualification Testing |
Highly Recommended |
|
|
5.9.4 |
Dry Run Software Item Qualification Testing |
Highly Recommended |
|
|
5.9.5 |
Performing Software Item Qualification Testing |
Highly Recommended |
|
|
5.9.6 |
Revision and Re-testing |
Highly Recommended |
|
|
5.9.7 |
Analysing and Recording Software Item Qualification Test Results |
Highly Recommended |
|
|
5.10 |
Software/Hardware Item Integration and Testing |
Mandatory |
|
|
5.10.1 |
Preparing for Software/Hardware Item Integration and Testing |
Mandatory |
|
|
5.10.2 |
Performing Software/Hardware Item Integration and Testing |
Mandatory |
|
|
5.10.3 |
Revision and Re-testing |
Mandatory |
|
|
5.10.4 |
Analysing and Recording Software/Hardware Item Integration and Test Results |
Mandatory |
|
|
5.11 |
System Qualification Testing |
Mandatory |
|
|
5.11.1 |
Independence in System Qualification Testing |
Mandatory |
|
|
5.11.2 |
Testing on the Target Computer System |
Mandatory |
|
|
5.11.3 |
Preparing for System Qualification Testing |
Mandatory |
|
|
5.11.4 |
Dry Run of System Qualification Testing |
Mandatory |
|
|
5.11.5 |
Performing System Qualification testing |
Mandatory |
|
|
5.11.6 |
Revision and Re-testing |
Mandatory |
|
|
5.11.7 |
Analysing and Recording System Qualification Test Results |
Mandatory |
|
|
5.12 |
Preparing for Software Use |
Mandatory |
|
|
5.12.1 |
Preparing the Executable Software |
Mandatory |
|
|
5.12.2 |
Preparing Version Descriptions for User Site |
Mandatory |
|
|
5.12.3 |
Preparing User Manuals |
Mandatory |
|
|
5.12.4 |
Installation at User Site |
Mandatory |
|
|
5.13 |
Preparing for Software Transition |
Mandatory |
|
|
5.13.1 |
Preparing the Executable Software |
Mandatory |
|
|
5.13.2 |
Preparing Source Files |
Mandatory |
|
|
5.13.3 |
Preparing Version Descriptions for the Maintenance Site |
Highly Recommended |
|
|
5.13.4 |
Preparing the “as built” Software Item Design and Other Software Maintenance Information |
Mandatory |
|
|
5.13.5 |
Updating the System Design Description |
Highly Recommended |
|
|
5.13.6 |
Updating the Software Requirements Specification |
Mandatory |
|
|
5.13.7 |
Updating the System/Subsystem Specification |
Mandatory |
|
|
5.13.8 |
Updating the Maintenance Manuals |
Mandatory |
|
|
5.13.9 |
Transition to Designated Maintenance Site |
Highly Recommended |
|
|
5.14 |
Software Configuration Management |
Mandatory |
Add the following subsection 5.14.6 Baseline Definitions |
|
5.14.1 |
Configuration Identification |
Mandatory |
|
|
5.14.2 |
Configuration Control |
Mandatory |
|
|
5.14.3 |
Configuration Status Accounting |
Highly Recommended |
|
|
5.14.4 |
Configuration Audits |
Highly Recommended |
|
|
5.14.5 |
Packaging, Storage, Handling and Delivery |
Highly Recommended |
|
|
5.15 |
Software Product Evaluation |
Highly Recommended |
|
|
5.15.1 |
In-process and Final Software Product Evaluation |
Highly Recommended |
|
|
5.15.2 |
Software Evaluation Records |
Highly Recommended |
|
|
5.15.3 |
Independence in Software Product Evaluation |
Highly Recommended |
|
|
5.16 |
Software Quality Assurance |
Mandatory |
|
|
5.16.1 |
Software Quality Assurance Evaluation |
Mandatory |
|
|
5.16.2 |
Software Quality Assurance Records |
Mandatory |
|
|
5.16.3 |
Independence in Software Quality Assurance |
Mandatory |
|
|
5.17 |
Corrective Action |
Mandatory |
|
|
5.17.1 |
Problem/Change Reports |
Mandatory |
|
|
5.17.2 |
Corrective Action System |
Mandatory |
|
|
5.18 |
Joint Technical and Management Reviews |
Recommended |
|
|
5.18.1 |
Joint Technical Reviews |
Recommended |
|
|
5.18.2 |
Joint Management Reviews |
Recommended |
|
|
5.19 |
Risk Management |
Mandatory |
|
|
5.20 |
Software Management Indicators |
Recommended |
Updated of the sub-clause. |
|
5.21 |
Administrative Security and Privacy Protection |
Recommended |
|
|
5.22 |
Managing Subcontractors |
Mandatory |
|
|
5.23 |
Interfacing with Software IV&V Agents |
Highly Recommended |
|
|
5.24 |
Co-ordinating with associated Developers |
Highly Recommended |
|
|
5.25 |
Project Process Improvement |
Recommended |
|
|
6.0 |
Schedule and Activity Network |
Mandatory |
|
|
7.0 |
Project Organisation and Resource |
Mandatory |
|
|
7.1 |
Project Organisation |
Mandatory |
|
|
7.2 |
Project Resource |
Mandatory |
Add the following subsection 7.2.1 Project Resource Training |
|
8.0 |
Notes |
Recommended |
Note: Abbreviation and Definitions have been brought foreword into section 2.0 under subsection 2.1 and 2.2 respectively. |
|
A |
Annexes |
Recommended |
|
|
|
|
|
|
Sub-Clause Description
1.2.1 Context Diagram: This sub-clause shall depict the overall system and shall identify system and elements that are covered by this plan. A system context diagrams which shows the interface between the system to be provided and the rest of the world with which it interacts.
1.2.2 Functional Elements: This sub-clause shall describe each of the functional elements that will be developed using this plan.
2.0 Reference Documents: This sub-clause shall identify by reference number, title, revision and date of all documents that are applicable to the software development. This sub-clause shall also identify: The priority of documents if applicable, the methods to be applied to resolving conflicts identified between documents and the methods to be applied to issuing, updating and verifying the accuracy of the documents used by project staff.
2.1 Abbreviations: This sub-clause shall provide description of all the abbreviations that are used within the Software Development Plan.
2.2 Definitions: This sub-clause shall provide description of all the definitions that are used within the Software Development Plan.
3.1 Software Artefacts: This sub-clause shall state
all the software artefacts that will be produced using this Software
Development Plan. It shall summarise when each of the software artefacts will
be produced, it will identify the verification method to be deployed.
3.2 Deliverable Software Artefacts: This sub-clause shall identify software work products to be delivered to the customer and any specific or special requirements for these documents (Format, Content, Schedule, Acquirer Approval, etc.)
4.0 Plans for Performing General Software Development Activities: This sub-clause shall identify all the software development actives and shall identify any special resource and expertise required during each phase of the software life cycle.
4.1 Software Development Process: This sub-clause shall also describe all the inputs that are required for each of the development life cycle and outputs that will be produced for each development phase. If iterative development life cycle is to be adpoted, than it will describe in which build the particular output is considered complete.
4.2.1.1 New Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be developed from start.
4.2.1.2 Reusable Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be modified from an existing baseline that has been previously qualified for similar application.
4.2.1.3 Prototype Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be modified from an existing baseline that has been previously qualified for similar application.
4.2.3 Traceability: This sub-clause shall provide description of how the traceability for each software life cycle will be conducted. It shall describe all the inputs required to perform the traceability for each phase of the software life cycle. It will identify any untraceable item and will provide rational why this will not have any bearing upon the safety and integrity of the system.
4.2.3.1 New Software: This sub-clause shall describe the software traceability technique and approach for upward and downward traceability for a system that has all new software development.
4.2.3.2 Reusable Software: This sub-clause shall describe the software traceability approach for upward and downward traceability for a system where the reusable software is deployed. For legacy software, the untraceable items will be backed up by rational why the delivered system is considered complete.
5.1.6 Following and Updating Plans: This sub-clause shall describe the replanning actives that will be performed for the duration of the project. At minimum, the following replanning activities shall be covered: Change to the Scope of Work; Addressing of Corrective Actions.
5.2.5 Non-Deliverable Software: This sub-clause shall describe all the non-deliverable software that will be used in the development of deliverable software. It shall describe provisions that will be made to ensure that the same software can be obtained for future development and/or maintenance.
5.20 Software Management Indicators: This sub-clause shall describe the set of management indicators that might be used for the duration of the project. It will identify when the metric collection activity will start and when it will stop. It will describe what indicators will be used to trigger management action plan to mitigate potential risks projected by the metrics. As a guidance, the following management indicators may be used:
a) Requirements Volatility,
b) Software Size,
c) Problem/change report status,
d) Milestone performance.
7.2.1 Project Resource Training: This sub-clause shall describe the orientation training of new software personnel on the project. It will describe minimum sets of training courses that should be taken in order for the new personnel to be effective on the project.
SQAP
Consider:
Since the J-STD-016-1995 was chosen as the “standard of choice” for the Software Development Plan, it seems a likely place to start. Per the standard,
“This EIA/IEEE Interim (Trial-Use) Standard is based upon the major technical content of ISO/IEC 12207 Information Technology Software Life Cycle Process, 22 February 1995, for the software development process.”
The intent of IEEE/EIA 12207.0 is to “… provide clarifications, additions, and changes accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA) …” to ISO/IEC 12207. Thus, we have a tight coupling here too.
Finally, Annex A of IEEE Std 730-1998 explores the correlation between the IEEE Std 730-1998 and IEEE/EIA 12207.0-1996. In general, it finds that IEEE Std 730 is more prescriptive with respect to process and format, but lists several areas where additional information is required.
Therefore, it seems appropriate to use a modification of IEEE Std 730 for our standards effort.
One warning, however. Per J-STD-016-1995, the “EIA/IEEE Interim (Trial-Use) Standards contain information deemed to be of technical value to the industry, and are published at the request of the originating Committee without necessarily following the rigorous public review and resolution of comments which is a procedural part of the development of an EIA/IEEE Standard.” The lack of the rigorous review probably means that our use of the J-STD-16 will be controversial in some circles.
|
Section |
SQAP Content List |
Applicable to Railway Software Standards |
Amendments For Railway Software Standards |
|
Cover |
Date of issue and
document status |
Mandatory |
12207 |
|
Inside Cover |
SQAP Change
History |
Mandatory |
12207 |
|
1.0 |
Purpose |
Mandatory |
|
|
1.1 |
SQAP Purpose |
Mandatory |
|
|
1.2 |
Scope |
Mandatory |
|
|
1.4 |
SQA Objectives |
Mandatory |
Documents motivating the SQAP shall be referenced - 12207 |
|
1.5 |
Software Items Covered |
Mandatory |
|
|
1.6 |
SQA Life Cycle |
Recommended |
|
|
1.7 |
SQAP Standards |
Mandatory |
|
|
1.8 |
SQAP Maintenance |
Mandatory |
12207 |
|
2.0 |
References |
Mandatory |
|
|
2.1 |
Document References |
Mandatory |
|
|
2.2 |
Acronyms |
Mandatory |
12207 |
|
2.3 |
Definitions |
Mandatory |
12207 |
|
3.0 |
Management |
Mandatory |
|
|
3.1 |
Organization |
Mandatory |
Identify issuing organization |
|
3.1.1 |
Quality Element Description |
Mandatory |
|
|
3.1.2.1 |
SQA Project Estimates |
Mandatory |
(cost, effort, size, etc.) 12207 |
|
3.1.2.2 |
SQA Independence |
Mandatory |
12207 |
|
3.1.n |
Organizational Element n |
Recommended |
List all elements that interact with or approve the SQAP |
|
3.2 |
Tasks |
Mandatory |
|
|
3.2.1 |
SQA Task 1 |
Mandatory |
|
|
3.2.1.1 |
Life Cycle Portion |
Mandatory |
12207 |
|
3.2.1.2 |
Task Milestones and Schedule |
Mandatory |
12207 |
|
3.2.2 |
SQA Task n |
Mandatory |
|
|
3.2.2.1 |
Life Cycle Portion |
Mandatory |
12207 |
|
3.2.2.2 |
Task Milestones and Schedule |
Mandatory |
12207 |
|
3.3 |
Responsibilities |
Mandatory |
|
|
3.3.1 |
Software Quality Assurance Engineer |
Mandatory |
|
|
3.3.2 |
Project Software Engineer |
Mandatory |
|
|
3.3.3 |
Project System Engineer |
Recommended |
|
|
3.3.4 |
Customer |
Recommended |
|
|
3.3.5 |
Organizational Element n |
Recommended |
|
|
4.0 |
Documentation |
Mandatory |
|
|
4.1 |
Purpose |
Mandatory |
|
|
4.1.1 |
Governing Documentation |
Recommended |
|
|
4.1.2 |
Document Validation |
Mandatory |
|
|
4.2 |
Minimum Documentation Requirements |
Omit, Move to SDP |
|
|
4.2.1 |
Software Requirements Specification (SRS) |
Omit, Move to SDP |
|
|
4.2.2 |
Software Design Description (SDD) |
Omit, Move to SDP |
|
|
4.2.3 |
Software Verification and Validation Plan (SVVP) |
Omit, Move to SDP |
|
|
4.2.4 |
Software Verification and Validation Report (SVVR) |
Omit, Move to SDP |
|
|
4.2.5 |
User Documentation |
Omit, Move to SDP |
|
|
4.2.6 |
Software Configuration Management Plan (SCMP) |
Omit, Move to SDP |
|
|
4.3 |
Other Documentation |
Omit, Move to SDP |
|
|
4.3.1 |
Software Development Plan (SDP) |
Omit, Move to SDP |
|
|
4.3.2 |
Software and Procedures Manual |
Omit, Move to SDP |
|
|
4.3.3 |
Software Project Management Plan (SPMP) |
Omit, Move to SDP |
|
|
4.3.4 |
Software Maintenance Manual (SMM) |
Omit, Move to SDP |
|
|
5.0 |
Standards, Practices, Conventions And Metrics |
Mandatory |
Omit S, P, & C (included in SDP) |
|
5.1 |
Purpose |
Mandatory |
|
|
5.1.1 |
Application of S, P, C, & M |
Mandatory |
|
|
5.1.2 |
Compliance Verification of S, P, C, & M |
Mandatory |
|
|
5.2 |
Content |
Mandatory |
|
|
5.2.1 |
Documentation Standards |
Omit, Move to SDP |
|
|
5.2.2 |
Logic Structure Standards |
Omit, Move to SDP |
|
|
5.2.3 |
Coding Standards And Conventions |
Omit, Move to SDP |
|
|
5.2.4 |
Commentary Standards |
Omit, Move to SDP |
|
|
5.2.5 |
Testing Standards And Practices |
Recommended |
|
|
5.2.6 |
Software Quality Assurance Product Metrics |
Mandatory |
|
|
5.2.7 |
Software Quality Assurance Process Metrics |
Mandatory |
|
|
6.0 |
Reviews And Audits |
Mandatory |
|
|
6.1 |
Purpose |
Mandatory |
|
|
6.1.1 |
Technical Reviews and Audits |
Recommended |
|
|
6.1.2 |
Managerial Reviews and Audits |
Recommended |
|
|
6.1.3 |
Additional Reviews and Audits |
Recommended |
|
|
6.2.1 |
Software Requirements Review (SRR) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.2 |
Preliminary Design Review (PDR) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.3 |
Critical Design Review (CDR) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.4 |
Software Verification And Validation Plan (SVVP) Review (SVVPR) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.5 |
Functional Audit (FA) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.6 |
Physical Audit (PA) |
Mandatory |
|
|
6.2.7 |
In-Process Audits |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.7.1 |
Code Verification Audit |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.7.2 |
Interface Specification Audit |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.7.3 |
Design Verification Audit |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.7.4 |
Test Procedure Functional Audit |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.8 |
Managerial Reviews |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.9 |
Software Configuration Management Review (SCMPR) |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.2.10 |
Post Mortem Review |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.3 |
Other Reviews and Audits |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
6.3.n |
Other Review/Audit n |
Limit discussion to SQA Involvement, move rest to SDP |
SDP, SQAP, SCMP, SVVR, STP, SUM, SMM |
|
6.4 |
Review and Audit Schedules |
Mandatory |
Added for 12207 |
|
7.0 |
Test |
Omit, Include in SVVP |
|
|
7.1.1 |
Test Omitted in SVVP n |
Omit, Include in SVVP |
|
|
8.0 |
Problem Reporting And Corrective Action |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
8.1 |
Software Problem Reporting |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
8.2 |
Software Problem Tracking |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
8.3 |
Software Problem Resolution |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
8.4 |
Software Problem Corrective Action |
Limit discussion to SQA Involvement, move rest to SDP |
|
|
9.0 |
SQA Tools, Techniques, And Methodologies |
Mandatory |
|
|
10.0 |
Code Control |
Omit, Move to SCMP |
|
|
11.0 |
Media Control |
Omit, Move to SCMP |
|
|
12.0 |
Supplier Control |
Mandatory |
|
|
12.1 |
Supplier SQA Provisions |
Mandatory |
|
|
12.2 |
Supplier Requirements Delivery Verification |
Recommended |
|
|
12.3 |
Software Reuse SQA Validation |
Recommended |
|
|
12.4 |
Supplier SQA Verification |
Mandatory |
|
|
13.0 |
Records Collection, Maintenance And Retention |
Mandatory |
|
|
13.1 |
Collection |
Mandatory |
|
|
13.2 |
Maintenance |
Mandatory |
|
|
13.3 |
Retention |
Mandatory |
|
|
14.0 |
Training |
Mandatory |
|
|
14.1 |
SQAP Training Requirements |
Mandatory |
|
|
15.0 |
Risk Management |
Mandatory |
|