Software PA Plan (SPAP) table of contents (as per ECSS/ESA standards)

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

Quality Assurance Plan: External QAP (TOC)

Internal QAP vs. External QAP? 

Sometimes you will have to build also an External Quality Assurance Plan (External QAP), besides having to build the [Internal] QAP for your project (look here for what should be in the internal version).

As for the internal QAP, or just QAP, it is our [internal] document, stating in our terms how we intend to perform the QA activities. The external QAP is typically a deliverable requested by the customer (i.e. contracted with the end customer) according to compliance requirements that concern him, or using the customer templates. As it can be seen, they serve slightly different purposes.

Note. In the space domain/ESA the QAP is sometimes called SPAP (Software Product Assurance Plan).

External QAP TOC 

What should go in an External QAP? The external QAP must follow the quality assurance requirements or the compliance to software product assurance requirements.

It may include, but it is not limited to, some of the following sections:

• Organisational Structure
• Risk Management overview
• Project Lifecycle
• Review Strategy
• Audit Strategy
• Non-Conformances control
• Product / Process Metrics and reporting (reported typically later on in PAR documents)
• Number of defects, NCs, risks, packages, interfaces, LOCs, code comment frequency, nesting level, cyclomatic complexity, etc.
• QA activities and respective transition criteria
• Compliance Matrix with the standard / subcontractor / supplier requirements

If this is not clear enough by itself it's time for you to "google yourself out of this".

Edit log:
2017-04-12: Added reference and link to SPAP (Space domain)

Quality Assurance Plan: What should a QAP contain (TOC)?

The short story: 

- What is a Quality Assurance Plan?
- What should a QAP contain?

A QAP is a plan of how you intend to do QA activities in your project (a plan is where you identify what you'll be doing, related to Quality Assurance (QA), when and with what resources).

This is where tailoring decisions are recorded (according to the tailorings allowed in each of the QMS processes).

As in many QA-related documents, there could be several possible TOCs (Table of Contents) if your QMS do not force you to use one, but in the case of a QAP for a software development project it is expectable to find in it a detailed description of all relevant QMS processes to produce the project outputs, and a description of how we will be applying them (or not) to our project (including the tailoring decisions).
Example topics / TOC can be seen below (in the "long story").

The long story: 

Internal QAP Assurance TOC / relevant topics to be referred:

• Life cycle tailoring decision and review provides an identification of the life cycle phases to which the Software Product Quality Assurance activities are applied.
• Review strategy consists on the definition of the type of verification activities to be held during the project development. These may include code and document reviews.
• Audits, consists of the plan for the audits and inspections. This includes customer audits, internal audits or external audits.
• Risk and Critical Items management, consists of the specification of the methods and procedures employed to identify, assess, monitor, and control areas of risk and critical items arising during the portion of the software life cycle covered by the QAP.
• Alert Procedure, consists of the specification of the methods and procedures employed to manage incoming and outgoing alerts. Alerts occur when new data triggers an impact evaluation on the project. An example of an incoming alert is a new security protocol breach identified by some work group that may require a specific project to change some functionalities implementation.
• Standards, practices, conventions identifies how standards, practices, conventions and metrics are to be applied, and states how compliance with these items is to be monitored and assured.
• Reporting, describes the reporting methods to be applied for the PA activities.
• Documentation, identifies the documentation governing the development, verification, validation, use, and maintenance of the software, and describes how the documents are to be checked for adequacy.
• Non conformances, deviation and change process, provides a description of the practices and procedures to be followed for non-conformances, deviations, and problem resolution during the software development and maintenance phases.
• Dependability and Safety Plan, describes the proposed dependability and safety activities that will be performed within the frame of the project.
• Procurement specifies the practices and procedures to be followed for procured software.
• Identification and traceability, specifies the features of a system for the identification, collection, cataloguing, storage, maintenance and disposition of records aimed at maintaining the integrity and traceability of the quality activities.
• Training identifies the training activities necessary to meet the needs of the development of the software product.
• Warranty identifies the quality activities that must be performed in the period of warranty of the system.
• Maintenance and operations, specifies the SPA activities for maintenance and support.
• Tailoring identifies any adaptation of any of the QMS defined processes, procedures or activities to better fit the project needs. Tailoring can be present in every abovementioned section and does not have to be an independent one.
• In case of Agile projects, the definition of “Done” must be formally specified

The QAP can be internal only, even though sometimes the customer (or the standards) will make you produce an External QAP (to be delivered externally). The final QAP project document could be an Excel or Word document. See what your QMS expects: as an example for CSW, the internal QAP is an Excel, the External is a Word document (delivered as a PDF of the approved version of the doc to the customer).

INDEX: About Project Plans - The Hitchhiker's Guide to the Galaxy (of QMS / SDP Project Plans)

The Short Story

Plans, plans, plans… 

Q: What kind of initial QMS / SDP-related documentation should it be created at project start (also called Kick-off)?

A: "Some" plans. 

Plans, allow us to plan (which by the way everyone should do) and after approval, allow us to monitor and control the project execution against those same plans. PMs are responsible to approve them even though sometimes they will delegate their creation and maintenance to the TM and/or the most experienced SPAE (Software Product Assurance Engineer) in the team.

What plans are we talking about? The project Plan (and the related detailed plan), the QAP, the CMP, …

You'll hear of even more plans (depending on the standards we are being compliant with). Mainly it has to do with the fact that for some standards we have to plan even further (and deliver those plans so that the contractor knows how we plan - and later on, double check the execution of tasks in the plan, through the inspection of produced evidences). Examples of such standards are the ESA standards (ECSS, for space development), DO-178 (for airborne systems), CENELEC 50126 (for railway applications), and so on. 

Examples of those include:

• Software Verification Plan (SVP)
• Software Validation Plan or (the mix of both):
• Software Verification and Validation Plan (SVVP)

Another PA-related artifact is the PA Log book (sometimes called SPAE Logbook). 

And Agile/Scrum projects use yet another log book: The sprint retro logbook.

What is the purpose of those main SDP plans? 

What are their goals , when are they created, when should they be updated?

Before starting, one important thing to remember is the fact that there should be a public list of QMS Process Owners (PO) and some backups for that role (called Process Representatives - PRs).

• One example of such a list can be found here (list of POs - INTERNAL): https://quality.critical.pt/SitePages/QMS-Unified/Process%20Owner%20and%20Process%20Representatives%20(Unified).aspx
• TIP: If the process has not yet been "unified" (the status can be checked here): https://quality.critical.pt/SitePages/QMS-Unified/Alignment%20Status.aspx), you could have to look here: https://quality.critical.pt/SitePages/QMS/Process%20Owner%20and%20Process%20Representatives.aspx
• Having the names, use the Beatles' song tip: "You know my name, look up the number" (in your company contacts database containing, place of work, phone contact and e-mail).

The (Very) Long Story

In order to know more about each artifact, the following "sequence of steps" is recommended:

• Read one entry in the final table below; from there you get to know the QMS process to where it belongs;
• Open the QMS Process and browse (at least) the main activities there described (typically there is only a single table/slide per process activity).
• The plan/artifact in question should be an artifact of this process you've just opened and if not, it is because it probably is just updated by this process. It could be an AD of the process or not - you can check it at the end of the process document.
• Open the template for the artifact (or the provided samples - if any), and scan read its contents. If some concrete examples are available also scan them. Google can also find them.
• Read the associated guidebooks (or the instruction sheets in the spreadsheet files).
• During this process, remember to list your questions / open issues so that in the end you can always go to the PO (or as a last resource the QD) and solve them.
• The one million dollar final questions to answer are:
• Am I able to create these documents from scratch?
• Am I able to understand them and extract the needed information for the activities/tasks I will be performing for the project?
• Do I know who to talk to in case of doubt (who is the doc owner? Who are the PO/PRs)?

INDEX: Plan / Artifact	Templates / Examples / Additional Relevant Docs
Templates (Docs from MT)	<<master template -- Quality Assurance Plan.docx>> <<master template -- Product Assurance Report.docx>> <<master template -- Int. Configuration Management Plan.docx>> <<master template -- Configuration Management Plan.docx>>
Templates (Spreadsheets)	<<internal QAP pre-tailored -- CSW-QMS-2013-TPL-00997-rd-pre-tailored-qap.xltx>> <<internal QAP -- PA Process -- CSW-QMS-2009-TPL-04681-quantitative-qap.xltx>> <<CSW-QMS-2014-TPL-01088-sprint-retrospective-workbook.xltm>> <<CSW-QMS-2007-TPL-0112-configuration-items-list.xltm>> <<CSW-QMS-2006-TPL-1126-spae-log-book.xltm>>
GBKs	<<CSW-QMS-2014-GBK-01269-agile-guidebook.pdf>> <<CSW-QMS-2012-GBK-04055-crucible-guidebook.pdf>> <<CSW-QMS-2012-GBK-02170-research-development-projects-tailoring.pdf>> <<CSW-QMS-2010-GBK-04838-review-report-macro.pdf>> <<CSW-QMS-2009-GBK-04120-wise-project-module-guidebook.pdf>> <<CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf>> <<CSW-QMS-2009-GBK-03591-qap-how-to.pdf>>
Relevant Trainings	<<project-management-practices-at-csw-internal-training.pptx>> <<CSW-QMS-2016-PRS-00605-QMSVerificationProcess2016DocumentandCodeR.pptx>> <<CSW-2015-PRS-00614-managing-baselines-and-change-control-tracking.pptx>> <<CSW-QMS-2015-TPL-00368-excel-project-tips-tricks.pdf>>

Artifact / Work Product (Plan)	Who is mostly involved	QMS Process / Doc. Level	Main Purpose	Artifact Doc Format / Tool	Generated by MT?	Example Doc. / Link	Associated Template and/or GBK / HOW-TO	More info (when to create, update and AOB)	AOB
Master Project Plan	PM	PM Process (MAN.1)	High-level plan (Gantt chart with the main WBS of the project (similar to the one produced for the estimation sum-up sheet if created during proposal elaboration); Relevant topics and uses for this artifact include: high level view of ptoject activities (overall view); end project date determination;  resource balancing; critical path analysis; effort and cost estimation (use of PERT estimation techniques  -Best Case Scenario, Expected Case Sc., Worst Case Sc.)…	MS Project (.mpp, etc.)		Web view of Gantt example  (WISE projects module, project EXOMARSTGO: https://wise.critical.pt/wiseweb/projects/ProjectPlan.action?expandAllTasks=&_sourcePage=%2FWEB-INF%2Fjsps%2Fprojects%2FprojectPlan.jsp&id=7439&showDeliverables=true&showWorkpackages=true&allSelected=true&showMilestones=true) For each project, the WISE export can be opened in MS Project: https://wise.critical.pt/wiseweb/projects/ExportProjectFile.action?id=7439	For MS Project planning tool info, tips and tricks, see training: https://my.critical.pt/humanresources/Documents/CSW-QMS-2015-TPL-00368-excel-project-tips-tricks.pdf	Should be always kept up to date (acc. To CRs/CCNs, approved changes to schedule, …); uploaded to "WISE Projects"; V1 ready at KOM (based on info from PRL, if existent)	Previously: There were ECS and ASD master plan templates as QMS artifacts. A guide for the "WISE Project Module" (covering EVM indicators, managing baselines and more) can be found here: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-04120-wise-project-module-guidebook.pdf
Detailed Project Plan	Typically: PM/TM	PM Process (MAN.1)	Used for detailed planning (day to day tasks, concrete resource allocations, % progress…)	MS Project (.mpp)		Optional: Created if a finer planning and control is needed (by the TM): details the Master Plan (and could be used to report %s progress for each task and calculate overal % progress, etc.)	N/A	Updated weekly (with progress)
External QAP	SPAE (PM typically delegates)	Software Product Assurance Process (MAN.8)	A written statement on how we intend to perform QA activities (i.e. how will the QMS apply to the project).  For instance: Describes the QA aspects of verification including Review activities to be performed Transition criteria for review activities The external QAP is a doc; The internal QAP is a XLS (see entry in this table).	MS Word (Master template, template ID = TBD - empty at MT at the moment, reported PROCIMP-819);	Yes	See template TOC.	See template and "fill in the blanks"; see QAP GBK: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-08-software-product-assurance/CSW-QMS-2009-GBK-03591-qap-how-to.pdf	Optional: If DL, it is created at KO; tailored with the QD (in case of doubt)	Note: This document could not be requested by the customer as deliverable (DL).
Internal QAP	SPAE	Software Product Assurance Process (MAN.8)	XLS that includes all process tailorings: e.g. Verification Process tailoring Includes a record of all tailoring decisions e.g. How will verification be performed (e.g. will the project do code reviews?)? Validation? Reqs, Design and SW Construction?	Spreadsheet (see template ids at right)	No	See spreadhseet contents.	See XLS template: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-08-software-product-assurance/templates/CSW-QMS-2009-TPL-04681-quantitative-qap.xltx Pre-Tailored for R&D project types: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-08-software-product-assurance/templates/CSW-QMS-2013-TPL-00997-rd-pre-tailored-qap.xltx; Also see the QAP GBK (link above)	Same as Ext. QAP	Old Ids: CSW-QMS-2003-TPL-2570 (EN), CSW-QMS-2004-TPL-2755 (PT)
CMP (External Config. Mg. Plan)	Typically: CM (Project Role; PM assigns this role to a team member)	CM Process (SUP.2)	A written statement on how we intend to do  Config. Management (activities). This document is optional but if done typically is to be delivered to the customer; this doc  consolidates info in a single document some information already stated in other internal docs such as the ICMP, QAP, CIL, …	MS Word (Master template, template ID = CSW-QMS-2004-TPL-0234)	Yes	See template contents; check list contents	See template(s) and "fill in the blanks"; See CM checklist: https://quality.critical.pt/QMS%20PT/SUP-support/SUP-02-configuration-management/templates/CSW-QMS-2012-TPL-00068-cm-checkup-checklist.xltx See training: https://my.critical.pt/humanresources/Documents/CSW-QMS-2016-PRS-00605-QMSVerificationProcess2016DocumentandCodeR.pptx (slides 17 and 18); helping scripts are referred there.	Optional: If DL, it is created at KO and kept up-to-date during the project (CRs/CCNs could impact this DL);	Note: This document could not be requested by the customer as deliverable (DL). Template Variants: External and Internal; pre-tailored for certain life cycles: See doc list. EN [CSW-QMS-2004-TPL-0234] {CMP} Configuration Management Plan (CMP) EN [CSW-QMS-2006-TPL-3196] {CMP} Internal CM Plan (ICMP) EN [CSW-QMS-2013-TPL-01989] {CMP} Internal Maintenance Pre-Tailored CM Plan (ICMP) EN [CSW-QMS-2013-TPL-00995] {CMP} Internal R&D Pre-Tailored CM Plan (ICMP) From <https://quality.critical.pt/SitePages/QMS-Unified/Master%20Template%20Content%20Detail%20(PT).aspx>
Internal CMP (ICMP)	CM (project role)	CM Process	The ICMP is a simpler document (when compared to the CMP) that includes the CM process tailoring decisions (what activities in the CM process are to be performed and what are not and with what formality and frequence) and the CM strategies (such as check-up strategy, build, baseline, tagging and branching strategies); it specifies the conventioned text for the TAGs to be applied at certain moments to the Version Control System (VCS).	MS Word (Master template, template ID = CSW-QMS-2006-TPL-3196; pre-tailored templates: CSW-QMS-2013-TPL-01989 (Maintenance); CSW-QMS-2013-TPL-00995 (R&D) )	Yes	See template TOC and pre-tailored templates.	See above		As seen above, there are 3 ICMP templates being generated by the MT.
CIL	Typically: CM (PM approves)	Verification Process	Contains the review strategy (usually internal). It list internal and external configuration items under configuration (built from the proposal and including CFIs received from the customer - be it software or hardware, external input docs, etc.) and for the internal, how we plan to do the reviews.	Excel Template: CSW-QMS-2007-TPL-0112	No	See spreadsheet contents; see CM check list contents;	See XLS template, instructions sheet: https://quality.critical.pt/QMS%20PT/SUP-support/SUP-02-configuration-management/templates/CSW-QMS-2007-TPL-0112-configuration-items-list.xltm; See training: https://my.critical.pt/humanresources/Documents/CSW-QMS-2016-PRS-00605-QMSVerificationProcess2016DocumentandCodeR.pptx (slides 17 and 18);	At KO; aligned with the DLs (and outputs) indicated in the PRL; Typically the CM check list shall be ran before the end of each phase.	Sometimes the CIL info is included in the SVP (Software Verification Plan): The SVP might be provided by the customer or be required by regulatory standards such as ECSS with the detailed review plan (i.e. while te CIL is typically internal, we could have one additional deliverable, the SVP)
More Project Documents
SPAE Log Book	Most experienced SPAE	SPA Process (MAN.8)	A guide for the performance of Product Assurance activities, including verification check lists before milestones	Excel macro-enabled template:  CSW-QMS-2006-TPL-1226	No		See XLS, instructions sheet: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-08-software-product-assurance/templates/CSW-QMS-2006-TPL-1126-spae-log-book.xltm; See Milestone meeting prep. GBK: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf; See training: https://my.critical.pt/humanresources/Documents/CSW-QMS-2016-PRS-00605-QMSVerificationProcess2016DocumentandCodeR.pptx (CR Monitoring is done in the SPAE log book: See slide 43)	Created at KO, updated during phases and at least once per milestone
PAR - External Product Assurance Report	SPAE (PM Approves)	SPA Process (MAN.8)	A report with several metrics collected regarding the project execution. Could be requested by the customer as a deliverable. In case of milestone meetings, the detailed quality verification is performed and the software product assurance report (PAR) is produced, reporting a sum-up of the results. Actions must be created whenever problems are identified and/or when a potential problem is identified. The PAR shall be released for all interested parties (PM and project team, and other departments such as the QD).	MS Word (Master Template, template ID = CSW-QMS-2003-TPL-1860)	No	See template TOC	See template and "fill in the blanks"	If required: Create one new PAR document per milestone (except KOM). A guide for milestone meetings (where the PAR contents could be presented) can be found here: https://quality.critical.pt/QMS%20PT/MAN-management/MAN-01-project-management/CSW-QMS-2009-GBK-03894-project-milestones-meetings.pdf
Sprint Retro Log book	Scrum Master / SPAE	Agile Guidebook (to be split in Scrum/Agile Development SDP)	A book to support sprint retrospectives (which is one of the last events to take place in a Scrum/Agile sprint), with some macro integrations to speed up the collection and display of agile metrics, as well as sheets to collect lessons learned and perform action management from them...	Excel template: CSW-QMS-2014-TPL-01088	No	See spreadsheet contents	See template, namely the instructions sheet: https://quality.critical.pt/QMS PT/HLP-high-level-processes/SDP2-agile-software-development/templates/CSW-QMS-2014-TPL-01088-sprint-retrospective-workbook.xltm	See GBK: https://quality.critical.pt/QMS%20PT/HLP-high-level-processes/SDP2-agile-software-development/CSW-QMS-2014-GBK-01269-agile-guidebook.pdf#search=agile%20GBK	See also the indicators and metrics GBK: https://quality.critical.pt/QMS%20PT/ORG-organisational/ORG-04-measurement-and-analysis/CSW-QMS-2014-DOC-03692-qms-indicators-metrics-dictionary.pdf#search=sprint%20retro