And the fresh links are...

... here:

• The visual roadmap to ESA Standards - ECSS-E-40 is the ESA engineering standard for space SW development, but as you might notice there are several other "squares", all equally important, corresponding to additional relevant standards for space systems development: http://silvaonsoftware.blogspot.pt/2017/04/what-is-ecss-and-what-are-all-those.html

• About the slang word Git, you might have heard by now. kudos to Mr. Linus for the... insult: https://en.wikipedia.org/wiki/Git_(slang)

• A Corporate site (what a company projects to the outside) example: https://www.criticalsoftware.com/pt/what-we-do
• The focus on quality and certifications on a corporate site (Quality Management - and the summary of what is CMMI-DEV 5, AS9100, etc.): https://www.criticalsoftware.com/pt/how-we-do-it/quality 

• Intranet resources (INTERNAL Resources): 
• Every intranet shall reflect internal departments contents (the organigrams, the relevant documents - processes - procedures - templates, ...): Example of department sub-sites are RH, Finance, IT, ...
• Engineering areas (sometimes called Delivery areas - executing projects and / or delivering services in IT) must play an important role on those intranets showing: platoons (groups of engineers), technical areas (how we solve technically the customer problems), project descriptions (what concrete projects we have been working in). Example: 
• https://spcorp.critical.pt/publishing/work  
• https://spcorp.critical.pt/publishing/platoon
• https://spcorp.critical.pt/publishing/technical-area
• https://spcorp.critical.pt/publishing/content-list?cname1=rdproject&cname2=deliveryproject&
• Tools (for SW development and more, e.g. for interfacing formally with other departments) shall be described in the internet, even if so only to provide the concrete URL destinations of those tools (aggregator links):  
• https://spcorp.critical.pt/publishing/internal-solution-and-tools

Review Procedure: Document reviews for dummies?

You do review documents before delivering/publishing do you?
How do you review documents (hands-on)?
And what do you do when the documents you receive are not in the more commonly editable formats? Or when you do not have a license of Microsoft Office / Microsoft Office 365?
So many questions, so many answers...

Note: Some of the considerations below assume you are using an Office Suite (that supports tracked changes and peer review comments).

Review roles

There should be a moderator for the review (the person that should make sure everyone reviews things in time and that makes sure a reviewed artifact comes out of the peer review activity). This could be the author, or not. All other involved are peer reviewers.

Note: Some process definitions can differentiate the moderator from the author roles. For larger teams, it could make sense. For smaller teams and / or more informal organizations, the author could work as moderator.

Review Types

There are several types of (document peer) reviews. Think: Commentary, Walk-through, Full-reading (run from those ones!). We are talking mainly of the Commentary ones here.

How do you peer review (The Process)? 

Ideally you (as a moderator for the review) should ask for peer reviewers to edit inline trivial errors (such as typos); and comment the document with whatever needs commenting (a comment is a sentence regarding the selected text the comment is about). Comments should be done "near" the paragraph / section they are related to.
The document could be reviewed simultaneously but it will be better (e.g. avoiding duplicated comments) to be circulated between all review members.
Circulation could be made by e-mail, or using the DMS and / or VCS: I will make my review and I will commit the version with my comments to the VCS (while warning the next person - or the whole review team - that the comment is free for the next reviewer).

This really depends on what your review process / procedure states in your QMS.

If the review team is not fully inside the subject of the the document, and/or the objective of the peer review, it might be a good idea for you to do a presentation of the document being reviewed (a meeting where the document and the objectives is presented; eventually the check-lists to use as input for the review could also be presented; and the schedules for the review are emphasized: "Do this for tomorrow, or else..."). In this meeting you could also explain how the review will be done (in sequence, all at the same time, using what tools for commenting, ...).

In the end of the rework (rework is made based on the peer review comments that are approved for implementation) the moderator could have the power to ask for a re-review. Mainly it will be a good idea if the rework that has been done was profound and if you feel that a new review (delta, or full) is needed to ensure the final document quality. Look at the review process / procedure in your company for rules on re-reviews.

Sometimes it will be mandatory for the review organizer to extract (or make a tool extract) the review metrics. That could include, #of comments, how many of them were acknowledged (and implemented), how many were dismissed, etc. A metrics repository could be fed with this (important performance) information. Ask about that part also (company dependent).

With what tools (The Supporting Tools)? 

- If you are producing the document internally, deliver it internally for peer review in an editable format. If everyone has the app to edit it (and that app supports comments).
- If someone does not have a license of Microsoft Office, try to see if free Office Suites are suitable for your document (some Office Suites will "damage" more complex documents; think: Open Office, Libre Office, ...). If so, recommend installation of those.
- "Google docs" allows you opening and commenting (MS Office) documents. So it could be an option. Just test it with the concrete document you need to review.

If you only have a PDF and you want to peer review it you could:
- Try to create an editable document from the PDF (several utilities can be found - google is your friend, but do test the conversion since more complex docs could not be well extracted/converted).
- Try to comment right away the PDF: https://www.adobe.com/content/dam/Adobe/en/feature-details/acrobatpro/pdfs/adding-comments-to-a-pdf-document.pdf

Merging Comments (If possible, No)? 

In the end, if you do a sequential comment workflow (which is recommended and will dispense you from having to merge all peer reviewers comments into a single document) the document owner (the one responsible to process and close all comments provided) will receive a single file, that went through all peer reviewers to process.

If you have several documents with comments from several reviewers, do not dispair. Remember that MS Word has that wonderful feature to merge 2 versions of the same document (try to save one above the other and MS Word will offer to Merge contents). A tracked changed version (with all comments merged also) can be produced in this way.

Easy ain't it? :)

Note: If you opt to use an Office Suite like google docs (of Office365) that allow concurrent edits by several users at the same time (without frequent unsolvable merge conflicts that tear your hair apart), the merge part is not needed, of course.

Recap 

Read the guidelines to peer review artifacts in your QMS. Know if there are check lists associated to check against, during the review. Know how to edit inline and comment a paragraph, Know how to circulate the document between the team. And be a good boy: do review technically and formally the stuff. Do not just point formatting and English issues (but do report those also).

Further Reading (The Process stuff): For further info, look for your company's SUP03 - Verification Process and the Review Procedure documents (or equivalent), that shall detail the above considerations. Mine's are here: https://goo.gl/4EKKec (INTERNAL resource).


History:
@2017-04-26: Added INTERNAL QMS links; added Google Docs note; updated tags.

SW Construction: Reflections on Trusting Trust (PDF)

To what extent should one trust a statement that a program is free of Trojan
horses? Perhaps it is more important to trust the people who wrote the
software.

PDF download: p761-thompson.pdf

PDF: Report about the State of Software Development Industry in 2017 (codingsans.com)

To download the report, based in a poll made to 126 industry workers (PDF, 31 pages; requires registering):
http://codingsans.com/state-of-software-development-startups-2017

Article based on the report:
What's New in the Software Development Industry in 2017

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

What is the ECSS and what are all those standards about (Roadmap)?

The Short Story

ECSS is the european standards organization for space activities. Follow the link for further details.
Amongst other things they produce... Standards.

If you know some of them, maybe this picture will suffice you (Source: ESA):

The Long Story

Space product development is (as you might know) a demanding area for hardware. As it is for software. ECSS was created to standardize space product development. The standards under ECSS superseeded the PSSs and now abound, i.e. they might confuse you; ECSS-M, ECSS-Q, ECSS-E, ...

So here are two quick intros (roadmaps) to the ESA standards:

• http://www.ecss.nl/wp-content/uploads/2016/09/ECSS-Training-L1(2017-03-14).pdf
• http://www.esa.int/esapub/bulletin/bullet111/chapter21_bul111.pdf

SPA Process: Internal Product Assurance Report (PAR TOC)

The Short Story

The Product Assurance Report (PAR) is the formal mechanism of communicating the Product Assurance Activities status and results in the project.

For most QMS / SDPs it is mandatory at milestone meetings and can be used to report problems to upper management between milestones.

The Long Story

PAR Purpose

The main purpose of the PAR is to:

• Report the quality assurance activities being developed, along the project tailored life cycle, in order to assess the quality of the software development process (based on measured properties, verification undertaken, problems detected and problems solved);
• Present the current project status (this may include not only the on-process and on-quality but also the overall status of the quality of the product being developed);
• Report compliance to QMS and applicable standards for the project;
• Report metrics and conclusions on these metrics (if found necessary);
• Report of the verification results on the correct use of methods and tools in the software processes;
• Present audit reports for the audits planned in the QAP (these include audits from the annual internal audit plan - if any). Safety audits should also be present, if performed;
• Anticipate possible problems.

Example TOC for a PAR

Information to be included in the PAR (remember that this report can be produced several times during the project execution):

• Highlights of organization and key personnel changes.
• Assurance accomplishments and resulting software assurance program metrics for activities such as inspection and test, reviews, contractor/subcontractor surveys, audits.
• Subcontractor assurance accomplishments, including items listed above, plus summaries of acceptance and certification reports.
• Significant problems, their status, solutions, and preventive actions or corrections.
• Trends in software quality metric data (e.g., defect types, location, priority/criticality).
• Plans for upcoming software assurance activities.
• Recommendations and relevant lessons learned.

The final format of an Internal PAR can be diverse. It could range from an e-mail circulated internaly (to the project team and delivery / execution departments in the company) to full formal documents.

Final Notes

Sometimes you'll have to produce an External PARs (documents) to be delivered to the customer (in PDF format). Remember that it could be counter-productive to disclose all information being collected in the Internal PAR, or that the customer can have template / specific standard requirements that will make him ask for that extra deliverable (see the Proposal/Contract for the specific project).

SPA Process: External PAR (TOC)

The Short Story

As stated in the IPAR topic, sometimes you'll have to produce an External PARs (document) to be delivered to the customer (in PDF format).
Why is that? Isn't this duplicating work? Yes and no.
Remember that it could be counter-productive to disclose all information being collected in the Internal PAR, or that the customer can have template / specific standard requirements that will make him ask for that extra deliverable (see the Proposal/Contract for the specific project).

The Long Story (TOC)

Example TOC for External QA Reports (External PARs):

• Planning documentation progress status
• Development activities status
• Modules / Components development progress
• Code Metrics
• Verification activities status
• Completeness / correctness statistics for Code reviews, Module Testing, Integration Testing
• QA activities status
• Reports, CM check-ups, On-process (SPA Log Book), etc.
• Summary of CAs / NCs status
• Activities / Actions to be performed before the next report

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

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

SW Construction: Cobol in-house development for what?

COBOL still in the headlines (and still in indexes like the TIOBE index). Read to understand why (and how custom / bespoke software developed in-house, which typically is business-critical, is to be replaced):
https://www.fedscoop.com/va-looks-move-past-cobol-house-software-development/

Quoting:
"Thomas’ predecessor CIO LaVerne Council last year launched the idea of a VA digital health platform, which is slated to incorporate commercial cloud computing, open architecture and agile delivery to best keep pace with best-in-class digital health technologies.

That’s because today, VA is still running some systems based on COBOLprogramming, like its decades-old benefits delivery network, and it employs programmers who specialize in the maintenance of the outdated, legacy programming language — though “it’s dwindling, as you well know, they’re retiring,” the acting CIO said. The VA also enlists contractors to support the operations and maintenance of those systems, he added.

Modernizing those COBOL systems is at the top of Thomas and VA’s Office of Information and Technology’s list of priorities for 2017, he said.

“That’s a big risk to us,” Thomas said. “That’s something that’s job No. 1 for this year,” before things like continued development of enterprise cybersecurity strategy, modernizing VA’s health care scheduling program and consolidating financial management systems to be run as a shared service through the Agriculture Department."