The Short Story
SPAP is the Software Product Assurance Plan, as per the ECSS standards (ESA). The SPAP is related with the Software product assurance planning and control.- A Software Product Assurance Plan (SPAP) must be produced and delivered for customer approval
• May be part of the overall project PA plan
The SPAP must be up-to-date at each milestone
The SPAP must contain a compliance matrix with respect to the applicable requirements
• For each requirement, reference to the implementation of that requirement
A Document Requirements Description (DRD) for the SPAP is provided in ECSS-Q-ST-80C - Annex B
Source: ECSS-Q-ST-80C training.
The Long Story (the TOC)
The SPAP document shall answer to this requirements (what they mean with calling this a DRD and not a TOC, is that you can use whatever TOC you want, provided that the final document contents "answers" to all these requirements). I would say that the easier way to make sure nothing is forgotten is to user the requirements below as the TOC.1. Introduction
2. Applicable and reference documents
3. Terms, definitions and abbreviated terms
4. System Overview
5. Software product assurance programme implementation
5.1 Organization
5.2 Responsibilities
5.3 Resources
5.4 Reporting
5.5 Quality models
5.6 Risk management
5.7 Supplier selection and control
5.8 Methods and tools
5.9 Process assessment and improvement
5.10 Operations and maintenance (optional)
6 Software process assurance
6.1 Software development cycle
6.2 Projects plans
6.3 Software dependability and safety
6.4 Software documentation and configuration management
6.5 Process metrics
6.6 Reuse of software
6.7 Product assurance planning for individual processes and activities
6.8 Procedures and standards
7 Software product quality assurance
The SPAP shall describe the approach taken to ensure the quality of the software product including the:
1. specification of the product metrics, their target values and the means to collect them;
2. definition of a timely metrication programme;
3. analyses to be performed on the collected metrics;
4. way the results are fed back to the development team;
5. documentation quality requirements;
6. assurance activities meant to ensure that the product meets the quality requirements.
8 Compliance matrix to software product assurance requirements
The Very Long Story (the commented TOC)
DRD explained, as in the Annex of the Standard:<1> Introduction
a. The SPAP shall contain a description of the purpose, objective, content and the reason prompting its preparation.
<2> Applicable and reference documents
a. The SPAP shall list the applicable and reference documents to support the generation of the document.
<3> Terms, definitions and abbreviated terms
a. The SPAP shall include any additional terms, definition or abbreviated terms used.
<4> System Overview
a. The SPAP shall include or refer to a description of the system and software products being developed.
<5> Software product assurance programme implementation
<5.1> Organization
a. The SPAP shall describe the organization of software product assurance activities, including responsibility, authority and the interrelation of personnel who manage, perform and verify work affecting software quality.
b. The following topics shall be included:
1. organizational structure;
2. interfaces of each organisation, either external or internal, involved in the project;
3. relationship to the system level product assurance and safety;
4. independence of the software product assurance function;
5. delegation of software product assurance tasks to a lower level supplier, if any.
<5.2> Responsibilities
a. The SPAP shall describe the responsibilities of the software product assurance function.
<5.3> Resources
a. The SPAP shall describe the resources to be used to perform the software product assurance function.
b. The description in B.2.1<5.3>a. shall include human resources and skills, hardware and software tools.
<5.4> Reporting
a. The SPAP shall describe the reporting to be performed by software product assurance.
<5.5> Quality models
a. The SPAP shall describe the quality models applicable to the project and how they are used to specify the quality requirements.
<5.6> Risk management
a. The SPAP shall describe the contribution of the software product assurance function to the project risk management.
<5.7> Supplier selection and control
a. The SPAP shall describe the contribution of the software product assurance function to the next level suppliers selection and control.
<5.8> Methods and tools
a. The SPAP shall describe the methods and tools used for all the activities of the development cycle, and their level of maturity.
<5.9> Process assessment and improvement
a. 1. The SPAP shall state the scope and objectives of process assessment.
b. 2. The SPAP shall describe the methods and tools to be used for process assessment and improvement.
<5.10> Operations and maintenance (optional)
a. The SPAP shall specify the quality measures related to the operations and maintenance processes (alternatively, a separate SPAP is produced).
<6> Software process assurance
<6.1> Software development cycle
a. The SPAP shall refer to the software development cycle description in the software development plan.
b. If not covered in the software development plan, the life cycle shall be described.
c. The life cycle shall include a milestone immediately before the starting of the software validation.
<6.2> Projects plans
a. The SPAP shall describe all plans to be produced and used in the project.
b. The relationship between the project plans and a timely planning for their preparation and update shall be described.
<6.3> Software dependability and safety
a. The SPAP shall contain a description and justification of the measures to be applied for the handling of critical software, including the analyses to be performed and the standards applicable for critical software.
<6.4> Software documentation and configuration management
a. The SPAP shall describe the contribution of the software product assurance function to the proper implementation of documentation and configuration management.
b. The nonconformance control system shall be described or referenced. The point in the software life cycle from which the nonconformance procedures apply shall be specified.
c. The SPAP shall identify method and tool to protect the supplied software, a checksum-type key calculation for the delivered operational software, and a labelling method for the delivered media.
<6.5> Process metrics
a. The SPAP shall describe the process metrics derived from the defined quality models, the means to collect, store and analyze them, and the way they are used to manage the development processes.
<6.6> Reuse of software
a. The SPAP shall describe the approach for the reuse of existing software, including delta qualification.
<6.7> Product assurance planning for individual processes and activities
a. The following processes and activities shall be covered, taking into account the project scope and life cycle:
1. software requirements analysis;
2. software architectural design and design of software items;
3. coding;
4. testing and validation (including regression testing);
5. verification;
6. software delivery and acceptance;
7. operations and maintenance.
<6.8> Procedures and standards
a. The SPAP shall describe or list by reference all procedures and standards applicable to the development of the software in the project.
b. The software product assurance measures to ensure adherence to the project procedures and standards shall be described.
c. The standards and procedures to be described or listed in accordance with B.2.1<6.8>a shall be as a minimum those covering the following aspects:
1. project management;
2. risk management;
3. configuration and documentation management;
4. verification and validation;
5. requirements engineering;
6. design;
7. coding;
8. metrication;
9. nonconformance control;
10. audits;
11. alerts;
12. procurement;
13. reuse of existing software;
14. use of methods and tools;
15. numerical accuracy;
16. delivery, installation and acceptance;
17. operations;
18. maintenance;
19. device programming and marking.
<7> Software product quality assurance
a. The SPAP shall describe the approach taken to ensure the quality of the software product.
b. The description of the approach specified in B.2.1<7>a shall include the:
1. specification of the product metrics, their target values and the means to collect them;
2. definition of a timely metrication programme;
3. analyses to be performed on the collected metrics;
4. way the results are fed back to the development team;
5. documentation quality requirements;
6. assurance activities meant to ensure that the product meets the quality requirements.
<8> Compliance matrix to software product assurance requirements
a. The SPAP shall include the compliance matrix to the applicable software product assurance requirements (e.g. ECSS-Q-ST-80 clauses, as tailored by a product assurance requirements document), or provide a reference to it.
b. For each software product assurance requirement, the following information shall be provided:
1. requirement identifier;
2. compliance
(C = compliant, NC = non–compliant, NA = not applicable);
3. reference to the project documentation covering the requirement (e.g. section of the software product assurance plan);
4. remarks.
Source: ECSS-Q-ST-80C, Annex C (listing several TOCs, or at least some DRDs).
