SPA Process: Product Assurance Verifications

The Short Story

Quality Assurance (QA) encompasses Product Assurance (PA) amongst other things (sometimes Product Assurance can be a process on its own in your QMS).

The purpose of having a Software Product Assurance activities is to as much as possible being able to produce "first time right" products.

SPA activities help projects achieving high levels of quality standards by:

1. Supporting the projects on applying the QMS processes (throughout all software development phases, before the KOM and up until the PCM);
2. Ensuring that projects are following internally defined processes and best practices;
3. Ensuring that projects are following specific standards contractually defined;
4. Guaranteeing that the product fulfils both CSW and customer's expectations;
5. Ensuring the use of the configuration management process and practises for the project (related with 2);
6. Reporting project performance to the team and to upper management (using PARs, more on those below);
7. Assuring the security of the product (software security assurance).
8. (and so on - insert here whatever makes sense to achieve the "first time right" products concept) 

PA has a focus on doing things right at the first time (as much as possible). In order to achieve that goal, there's a focus on Process Assurance (are we following the Software Development Process dispositions as well as other QMS Processes?). Typically for Process Assurance, product assurance verifications are performed (periodically, e.g. before the end of phase milestones). They consist of several verifications that look for evidences that something has been performed (that search is typically done in the project repositories - docs, code, and could be performed by anyone with access to those repositories).

The Long Story

PA verifications are done (periodically) in order to look for evidences that process activities (outputs of those activities) are being performed (produced) in the project.
Results can be reported in an Excel (e.g. filled-up check list, sometimes called SPA Log book) or in more formal documents such as PARs (Product Assurance Reports - those could also be internal and external, as the QAPs).

Examples of PA verifications (per QMS Process) include:

Project Management activities (MAN01):
Ensure that Project Directory is updated
Review the Project Management Plan (or Software Development Plan)
The plan is updated (work packages closed and reached milestones with 100% of progress)
Work packages are properly tagged
Ensure that issues are reported and resolved
Ensure that progress reports are being produced
Ensure meeting minutes are being produced (progress/milestone/external meetings, etc.)
Risk Management activities (MAN03):
Ensure that project risks and respective actions are being managed.
Ensure that risk identification follows best practices.
Configuration Management activities (SUP02):
Verify that the CM strategy defined in the CM Plan is in place.
Verify if all configuration items are clearly identified (using document identifiers).
Verify that documents and all software items (including tools, test files…) are under configuration management control according to project CM Plan.
Verify if the release strategy is updated and being followed.
Verify Release Management Procedure is being followed and release notes are correctly filled out with all needed information.
Verify if CM audits are being performed as expected (Milestones, Deliveries, other).
Verify that Change Management Procedure is being followed.
Verification activities (SUP03)
Guarantee that the review strategy is defined and being followed as planned.
Guarantee that all deliverables are formally reviewed.
Verify that all subcontractor deliverables are peer reviewed internally before approval or delivery, according to a predefined release and review strategies.
Verify that deliverables, or outputs when applicable, follow defined templates.
Verify that review evidences are produced and stored (reports and metrics).
Verify that all issues identified during the deliverables reviews have been implemented.

(and more...)

Building your own PA Verifications (and Executing them)

For building your own PA verifications, you'll have to know very well the QMS processes that are being used for building the software (and the Standards and Conventions that the projects on your company comply with). You could opt to focus attention on some of them only, at start (the most important ones, the ones that gave you problems in previous projects, etc.).

Then:
1) Go through all Processes of your QMS (SDP-related, be it engineering, support or management), all activities, analyse the required compliance in your processes (if full compliance is required, all tasks in the activities are required to be performed always) and perform checks for all those activities (that apply) and if it makes sense, perform checks for subtasks (particular steps) of those activities.
2) Perform additional PA verifications related to Standards/Conventions not covered by your QMS processes. A Compliance matrix relating your QMS with specific standards (if it exists) can help you find gaps to look at and see if additional verifications are to be performed or not.

When executing the PA verifications, verify them one by one (some verifications can be NA for some milestones, or specific phases your project is in). During that take into account the tailoring decisions for the specific project (the tailoring decisions are typically written in the QAP for later reference and can provide a good justification for some process activity not being performed).  

Final Note

When the QMS (SDP) changes, related processes such as the SPA Process must adapt (and so these PA verifications).
For a complete and up to date list of relevant PA verifications (for every milestone and QMS processes that are relevant to Software Development) see your SPA Log book template (which is an output of the SPA Process).