Write My Assignment FREE

Section 1. PURPOSE

The purpose of this plan is to define the [[Project Name]] Software Quality Assurance (SQA) organization, SQA tasks and responsibilities; provide reference documents and guidelines to perform the SQA activities; provide the standards, practices and conventions used in carrying out SQA activities; and provide the tools, techniques, and methodologies to support SQA activities, and SQA reporting.

1.1 Scope

This plan establishes the SQA activities performed throughout the life cycle of the [[Project Name]].

This plan is written to follow the Space and Naval Warfare (SPAWAR) Systems Center (SSC) San Diego SQA policy, reference (a), for [[Project Name]]. Specifically, this SQA Plan will show that the SQA function is in place for this project. It will show that the SQA group has a reporting channel to senior management that is independent of the project manager, the project’s software engineering group, and software related groups that includes Software Configuration Management (SCM), System and Software Test, and Logistics.

The goal of the SQA program is to verify that all software and documentation to be delivered meet all technical requirements. The SQA procedures defined herein shall be used to examine all deliverable software and documentation to determine compliance with technical and performance requirements.

Table 1-1 shows the software life cycle activities of the Configuration Items (CIs), as identified by the Institute of Electrical and Electronics Engineers (IEEE)/Electronic Industries Association (EIA) Standard 12207 Series, Software Life Cycle Process, reference (b), to which this SQA Plan applies.

In Table 1-1, add or delete activities that apply to the project’s software lifecycle and as specified in the project’s Software Development Plan (SDP) or other planning document.

1.2 Identification

Table 1-2 shows the CIs to which this plan applies.

If the project chooses to reference the list of CIs from another document, put a pointer here that shows where the project keeps its list of CIs.

Listed below is a brief description of each of the CIs developed and maintained by [[Project Name]].

1. [[CI #1]] – [[Include a brief description of the CI and its purpose]].
2. [[CI #2]] – [[Include a brief description of the CI and its purpose]].
3. [[CI #3]] – [[Include a brief description of the CI and its purpose]].

1.3 System Overview

The [[System Name]] complete the sentence by providing a description of the system and the intended use of the system. The system includes [[enter the number of subsystems, e.g., 4]] subsystem(s) within the system. Figure 1-1 identifies the CIs within each subsystem and highlights those to which this SQA Plan applies.

Table 1-1. Software Lifecycle Activities

SOFTWARE LIFECYCLE ACTIVITY

Project Planning and Oversight

Software Development Environment

System Requirements Analysis

System Design

Software Requirements Analysis

Software Design

Software Implementation and Unit Testing

Unit Integration and Testing

CI Qualification Testing

CI/Hardware Configuration Item (HWCI) Integration and Testing

System Qualification Testing

Software Use Preparation

Software Transition Preparation

Life Cycle Maintenance

Table 1-2. CI Nomenclature/Identification

NOMENCLATURE	ACRONYM	CI NUMBER
[[CI Name]]	[[Acronym]]	[[CI ID number]]
[[CI Name]]	[[Acronym]]	[[CI ID number]]
[[CI Name]]	[[Acronym]]	[[CI ID number]]

1.4 Document Overview

This document identifies the organizations and procedures to be used to perform activities related to the [[Project Name]] SQA program as specified in IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans, reference (c) and IEEE Std 730.1-1995, IEEE Guide for SQA Planning, reference (d).

Section 1 identifies the system to which this SQA Plan applies; provides an overview of the system and its software functions; summarizes the purpose and contents of the SQA Plan; and describes the relationship of the SQA Plan to other management plans and lists all documents referenced in this SQA Plan.

Section 2 describes each major element of the organization that influences the quality of the software.

Figure 1-1. [[System Title]] Software

Section 3 describes the various SQA tasks

Section 4 lists the baseline documents produced and maintained by the project.

Section 5 identifies the standards, practices and conventions.

Section 6 describes SQA involvement in testing.

Section 7 describes problem reporting and corrective action.

Section 8 describes SQA tools, techniques, and methodologies.

Section 9 describes the configuration management tool used for code control.

Section 10 describes SQA evaluation of media control.

Section 11 describes control of supplier software.

Section 12 describes SQA procedures for record collection, maintenance, and retention.

Section 13 describes SQA training requirements.

Section 14 describes SQA review of the Risk Management process.

Appendix A provides a list of acronyms.

Appendix B provides checklists to be used or tailored for verifying compliance with general software engineering best practices.

1.5 Relationship to Other Plans

SQA evaluation of the software development processes throughout the life cycle is based on the processes defined in the [[Project Name]] Software Development Plan (SDP), reference (e). Reference (e) and its implementation procedures establish the SQA evaluation criteria. The SQA Plan is implemented in conjunction with the [[Project Name]] Software Configuration Management Plan, reference (f).

1.6 Reference Documents

This section lists the documents referenced in this SQA Plan.

For the following, add or delete documents that were referenced in the SQA Plan.

1. SSC San Diego Software Quality Assurance Policy, Version 1.1, October 1997.
2. IEEE/EIA Standard 12207 Series – Standard for Information Technology – Software life cycle processes, March 1998.
3. IEEE-Std-730-1998, IEEE Standard for Software Quality Assurance Plans, June 1998.
4. IEEE-Std-730.1-1995, IEEE Guide for Software Quality Assurance Planning, December 1995.
5. [[Project Name]] Software Development Plan, [[Documentation Identification]], [[Document Date]].
6. [[Project Name]] Software Configuration Management Plan, [[Documentation Identification]], [[Document Date]].
7. Software Engineering Process Policy, SPAWARSYSCEN SAN DIEGO INST 5234.1, July 2000.
8. [[Program Title]] Program Plan, [[Documentation Identification]], [[Document Date]].
9. Software Quality Assurance Process, PR-SQA-02.
10. Software Quality Assurance Plan Template, TM-SQA-01.
11. A Description of the Space and Naval Warfare System Center San Diego Software Process Assets, PR-OPD-03.
12. MIL-STD-1521, Technical Reviews and Audits for Systems, Equipments, and Computer Software.
13. MIL-STD-973, Configuration Management. NOTE: This standard has been superceded by EIA-649, the Consensus Standard for Configuration Management, but the provisions of MIL-STD-973 are considered useful as a guide for developing Software Configuration Management activities.
14. Peer Review Process, PR-PR-02.
15. Military Standard (MIL-STD)-498, Software Development and Documentation, Data Item Descriptions (DIDs). NOTE: Although MIL-STD-498 has been superceded by IEEE Std 12207, the DIDs for MIL-STD-498 are still considered applicable for the support of developing software engineering procedures and supporting documentation.
16. IEEE Std 1045-1992, IEEE Standard for Software Productivity Metrics, September 1992.
17. IEEE Std 1061-1992, IEEE Standard for a Software Quality Metrics Methodology, December 1992.
18. IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software, June 1988.
19. Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software, September 1988.

Section 2. MANAGEMENT

This section describes each major element of the organization that influences the quality of the software.

2.1 Organization

Good software practice requires a measure of independence for the SQA group. This independence provides a key strength to SQA; that is, SQA has the freedom, if the quality of the product is being jeopardized, to report this possibility directly above the level of the project. While in practice this rarely occurs, for almost all problems are correctly addressed at the project level, the fact that the SQA group can go above the project level gives it the ability to keep many of these problems at the project level.

Figure 2-1 shows the SQA organization with relation to the project organization.

Figure 2-1. [[Project Name]] Organization

Replace Figure 2-1 with your project’s organizational structure or reference the organizational chart’s location. The project may wish to keep a single chart in a central location and reference all of its plans and procedures to that chart to facilitate maintaining the organization char. Provide a description of the functional responsibilities for each functional group in the organizational structure.

In describing the functional responsibilities, answer the questions listed below:

1. Who interacts with SQA?
2. Who has authority and delegates responsibilities of interacting functions?
3. What are the reporting relationships among the interacting elements identifying independence/dependence?
4. Who has product release authority?
5. Who approves the SQA Plan?
6. What are the reporting lines for escalating conflicts and the method by which conflicts are to be resolved among the elements?

In each case, add or delete the functional responsibilities that apply.

SQA is responsible for ensuring compliance with SQA requirements as delineated in this SQA Plan. The SQA organization assures the quality of deliverable software and its documentation, non-deliverable software, and the engineering processes used to produce software.

The following describes the functional groups that influence and control software quality.

1. Program Management/Line Management (Sponsor) is responsible for the following items:
   1. Establishing a quality program by committing the project to implement the Software Engineering Process Policy, reference (g), and reference (a).
   2. Reviewing and approving the [[Project Name]] SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA.
   4. Identifying an individual or group independent from the project to audit and report on the project’s SQA function.
   5. Identifying the quality factors to be implemented in the system and software.
   6. fill-in additional functional responsibilities.
2. Project Management is responsible for:
   1. Implementing the quality program in accordance with references (g) and (a).
   2. Identifying the SQA activities to be performed by SQA.
   3. Reviewing and approving the [[Project Name]] SQA Plan.
   4. Identifying and funding an individual or group independent from the project to perform the SQA functions.
   5. Resolving and following-up on any quality issues raised by SQA.
   6. Identifying and ensuring the quality factors to be implemented in the system and software.
   7. Identifying, developing and maintaining planning documents such as the Program Management Plan, reference (h), references (e) and (f), Test Plans, and this SQA Plan.
   8. fill-in additional functional responsibilities.
3. System Engineering is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA related to software engineering activities.
   4. Identifying, implementing, and evaluating the quality factors to be implemented in the system (software and hardware).
   5. Implementing the engineering practices, processes, and procedures as defined in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
4. Software Design/Development is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA related to software design and development.
   4. Identifying, implementing, and evaluating the quality factors to be implemented in the software.
   5. Implementing the software design/development practices, processes, and procedures as defined in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
5. Software Test is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA related to software test.
   4. Verifying the quality factors are implemented in the system, specifically software.
   5. Implementing the software test practices, processes, and procedures as defined in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
6. System Test is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA as related to system test.
   4. Verifying the quality factors are implemented in the system (software and hardware).
   5. Implementing the system test practices, processes, and procedures as defined in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
7. Logistics is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. fill-in additional functional responsibilities.
8. Software Configuration Management (SCM) is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with this SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA related to SCM.
   4. Ensuring the quality factors are implemented in the software related to SCM.
   5. Implementing the SCM practices, processes, and procedures as defined in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
9. Independent Verification and Validation (IV&V) is responsible for:
   1. Reviewing and commenting on the [[Project Name]] SQA Plan.
   2. Implementing the quality program in accordance with the [[Project Name]] SQA Plan.
   3. Resolving and following-up on any quality issues raised by SQA.
   4. Verifying the quality factors are implemented in the system (hardware and software).
   5. Implementing the practices, processes, and procedures as defined for IV&V in reference (e) and other program/project planning documents.
   6. fill-in additional functional responsibilities.
10. Systems Engineering Process Office (SEPO) is responsible for:
    1. Keeping references (a) and (g) current.
    2. Maintaining the SQA Process, reference (i) and the SQA Plan Template, reference (j).
    3. Ensuring SQA training availability, either by vendor or SEPO.
    4. Providing assistance in software process engineering and software process improvement.
    5. Maintaining the Description of the Space and Naval Warfare System Center San Diego Software Process Assets, reference (k), that describes many artifacts used to support SQA verification activities.

2.2 Resources

2.2.1 Facilities and Equipment

SQA will have access to the facilities and equipment as described in reference (e). SQA will have access to computer resources to perform SQA functions such as process and product evaluations and audits.

2.2.2 Personnel

The SQA effort for this project is person-year effort or indicate the amount of effort if it is less than 100% – ensure the effort agrees with the project Work Breakdown Structure.

Identify the qualification requirements of the SQA Manager

The SQA Manager will be familiar with and will be able to apply the standards and guidelines listed in Section 1.6. Additionally, the SQA Manager will be familiar with software quality, software development-related activities, and structured analysis, design, coding, and testing.

Section 3. SQA TASKS

Describe the portion of the software life cycle covered by this SQA Plan, the tasks to be performed with special emphasis on SQA activities, and relationship between these tasks and the planned major checkpoints. The sequence of the tasks should be indicated. Tailor this section to reflect those tasks being verified that relate to the project’s current/projected activities.

The scheduling of SQA tasks is driven by the software development schedule. Therefore, an SQA task is performed in relationship to what software development activities are taking place. One or more SQA tasks can be performed concurrently until a task is completed. A task is considered completed when the required report e.g., SQA Reports, Process Audits Reports, etc. are satisfactorily completed or action items have been closed. The following tasks, requiring coordination and cooperation with the project team, shall be performed by SQA.

3.1 Task: Review Software Products

Reference (e) identifies all software products to be developed and evaluated, and includes the standards or guidelines to be followed. As required, SQA shall assist the project in identifying the standards or guidelines to be followed in developing the software product. Section 4 lists the software products to be evaluated by SQA and describes the review process to be followed.

3.2 Task: Evaluate Software Tools

SQA shall conduct evaluations of tools, both existing and planned, used for software development and support. The tools are evaluated for adequacy by assessing whether they perform the functions for which the tools are intended and for applicability by assessing whether the tool capabilities are needed for the software development or support. Planned tools are evaluated for feasibility by assessing whether they can be developed with the techniques and computer resources available or by procurement. Section 7 provides the format for reporting the results of a software tool evaluation.

3.3 Task: Evaluate Facilities

SQA shall evaluate facilities, both existing and planned, for adequacy by assessing whether they provide the needed equipment and space used for software development and support. Section 7 provides the format for reporting the results of evaluating the project’s facilities.

3.4 Task: Evaluate Software Products Review Process

This SQA task assures that quality review processes are in place for all software products, which may include representations of information other than traditional hard-copy documents, and that these products have undergone software product evaluation, testing, and corrective action as required by the standard.

SQA shall check that software products that are ready for review are reviewed, verify results are reported and issues or problems reported are resolved in accordance with reference (e).

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.5 Task: Evaluate Project Planning, Tracking and Oversight Processes

Project planning, tracking and oversight involves project management to develop and document plans for Software Development, CI and System Test, Software Installation, and Software Transition. Section 1.6 lists the program/project plans. For project documents to be developed, SQA will assist in identifying the appropriate guidelines, standards, or Data Item Description (DIDs), and will assist with the tailoring of those guidelines, standards, or DIDs to meet the project’s needs.

SQA shall evaluate that the project conducts the relevant activities stated in the Program and Project plans. To verify that these activities are performed as planned, SQA will audit the processes that define the activity, and will use reference (e) or other planning document as the measure of whether those activities are being met.

SQA will use the audit checklists in Figures B-1 and B-2 as guides for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7. Any recommended changes to those plans will require update and approval by project management in accordance with the configuration management procedure as described in the [[Project Name]] SCM Plan.

3.6 Task: Evaluate System Requirements Analysis Process

Requirements analysis establishes a common understanding of the customer’s requirements between that customer and the software project team. An agreement with the customer on the requirements for the software project is established and maintained. This agreement is known as allocating system requirements to software and hardware. Section 4 lists the system requirements documents.

SQA activities are listed below:

1. Verify that the correct participants are involved in the system requirements analysis process to identify all user needs.
2. Verify that requirements are reviewed to determine if they are feasible to implement, clearly stated, and consistent.
3. Verify that changes to allocated requirements, work products and activities are identified, reviewed, and tracked to closure.
4. Verify that project personnel involved in the system requirements analysis process are trained in the necessary procedures and standards applicable to their area of responsibility to do the job correctly.
5. Verify that the commitments resulting from allocated requirements are negotiated and agreed upon by the affected groups.
6. Verify that commitments are documented, communicated, reviewed, and accepted.
7. Verify that allocated requirements identified as having potential problems are reviewed with the group responsible for analyzing system requirements and documents, and that necessary changes are made.
8. Verify that the prescribed processes for defining, documenting, and allocating requirements are followed and documented.
9. Confirm that a configuration management process is in place to control and manage the baseline.
10. Verify that requirements are documented, managed, controlled, and traced (preferably via a matrix).
11. Verify that the agreed upon requirements are addressed in the SDP.

SQA may use the audit checklist in Figure B-3 as a guide for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.7 Task: Evaluate System Design Process

The purpose of the system design process is to develop decisions about the system’s behavioral design and other decisions affecting the selection and design of system components. System architectural design is organizing a system into subsystems, organizing a subsystem into Hardware Configuration Items (HWCIs), CIs, and manual operations, or other variations as appropriate. Section 4 lists the system design documents.

SQA activities are listed below:

1. Verify that system design documents and the traceability matrix are prepared and kept current and consistent.
2. Verify that relevant documents are updated and based on approved requirements changes.
3. Verify that design walkthroughs (peer reviews) evaluate compliance of the design to the requirements, identify defects in the design, and evaluate and report design alternatives.
4. Participate in a sampled set of design walkthroughs and verify all walkthroughs are conducted.
5. Identify defects, verify resolution for previous identified defects, and verify change control integrity.
6. Selectively review and audit the content of system design documents.
7. Identify lack of compliance with standards and determine corrective actions.
8. Determine whether the requirements and accompanying design and tools conform to standards, and whether waivers are needed prior to continuing software development.
9. Review demonstration prototypes for compliance with requirements and standards.
10. Verify that the demonstration conforms to standards and procedures.
11. Review the status of design milestones.

SQA may use the audit checklist in Figure B-4 as a guide for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.8 Task: Evaluate Software Requirements Analysis Process

The purpose of software requirements analysis is to formulate, document and manage the software requirements baseline; respond to requests for clarification, correction or change; analyze impacts; revise the software requirements specification; and manage the software requirements analysis and change process. Section 4 lists the software requirements documents.

SQA activities are listed below:

1. Verify that the software requirements analysis process and associated requirements reviews are conducted in accordance with the standards and procedures established by the project and as described in the SDP.
2. Verify that action items resulting from reviews of the software requirements analysis are resolved in accordance with these standards and procedures.

SQA may use the audit checklist in Figure B-5 as a guide for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.9 Task: Evaluate Software Design Process

Preliminary design activity determines the overall structure of the software to be built. Based on the requirements identified in the previous phase, the software is partitioned into modules, and the function(s) of each module and relationships among these modules are defined.

A goal of detailed design is to define logically how the software will satisfy the allocated requirements. The level of detail of this design must be such that the coding of the computer program can be accomplished by someone other than the original designer. Section 4 lists the software design documents.

SQA activities are listed below:

1. Verify that the software design process and associated design reviews are conducted in accordance with standards and procedures established by the project and as described in the SDP.
2. Verify that action items resulting from reviews of the design are resolved in accordance with these standards and procedures.
3. Evaluate the method used for tracking and documenting the development of a software unit to determine the method’s utility as a management tool for assessing software unit development progress. Example criteria to be applied for the evaluation are the inclusion of schedule information, results of audits, and an indication of internal review and approval of its constituent parts.
4. Verify that the method, such as the Software Development File (SDF) or Unit Development folder (UDF), used for tracking and documenting the development of a software unit is implemented and is kept current.

SQA may use the audit checklist in Figure B-6 as a guide for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.10 Task: Evaluate Software Implementation and Unit Testing Process

Software implementation or coding is the point in the software development cycle at which the design is finally implemented. The process includes unit testing of the software code.

SQA activities are listed below:

1. Verify that the coding process, associated code reviews, and software unit testing are conducted in conformance with the standards and procedures established by the project and as described in the SDP.
2. Verify that action items resulting from reviews of the code are resolved in accordance with these standards and procedures.
3. Verify that the SDF used for tracking and documenting the development of a software unit is implemented and is kept current.

SQA may use the audit checklist in Figure B-7 as a guide for conducting the evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.11 Task: Evaluate Unit Integration and Testing, CI Qualification Testing, CI/HWCI Integration and Testing, and System Qualification Testing Processes

Software integration and test activities combine individually developed components together in the developing environment to verify that they work together to complete the software and system functionality. For joint hardware and software development, integration requires close synchronization of hardware and software to meet designated integration and test milestones.

In the integration and test phase of the development lifecycle, the testing focus shifts from an individual component correctness to the proper operation of interfaces between components, the flow of information through the system, and the satisfaction of system requirements.

SQA activities are listed below:

1. Verify that software test activities are identified, test environments have been defined, and guidelines for testing have been designed. SQA will verify the software integration process, software integration testing activities and the software performance testing activities are being performed in accordance with the SDP, the software design, the plan for software testing, and established software standards and procedures.
2. Verify any transfer of control of code to personnel performing software integration testing or software performance testing is being accomplished in accordance with established software standards and procedures.
3. Verify that as many of the software integration tests as necessary and all of the software performance tests are witnessed to verify that the approved test procedures are being followed, that accurate records of test results are being kept, that all discrepancies discovered during the tests are being properly reported, that test results are being analyzed, and the associated test reports are completed.
4. Verify that discrepancies discovered during software integration and performance tests are identified, analyzed, documented, and corrected; software unit tests, and software integration tests are re-executed as necessary to validate corrections made to the code; and the software unit’s design, code, and test is updated based on the results of software integration testing, software performance testing, and corrective action process.
5. Verify the software performance tests produce results that will permit determination of performance parameters of the software.
6. Verify that the responsibility for testing and for reporting on results has been assigned to a specific organizational element.
7. Verify that procedures are established for monitoring informal testing.
8. Review the Software Test Plan and Software Test Descriptions for compliance with requirements and standards.
9. Verify that the software is tested.
10. Monitor test activities, witness tests, and certify test results.
11. Verify that requirements have been established for the certification or calibration of all support software or hardware used during tests.

SQA may use the audit checklists in Figures B-8 and B-9 as guides for conducting these evaluations.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.12 Task: Evaluate End-item delivery Process

This activity is applicable for those projects providing a one-time delivery of a product and may also be interpreted as required deliveries for a specified time period or time frame.

SQA shall evaluate the activities in preparation for end-item delivery to verify that program or project requirement, if any, for functional and physical audits of the end-item products are being satisfied. In some cases, the SQA organization should be allowed to prohibit delivery of certain items, such as documentation, code, or a system, if the project fails to meet contractual requirements or standards.

SQA may use the audit checklist in Figure B-10 as a guide for conducting this evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.13 Task: Evaluate the Corrective Action Process

The corrective action process describes the steps for (1) problem identification and correction occurring during software development to verify early detection of actual or potential problems, (2) reporting of the problem to the proper authority, (3) analysis of the problem to propose corrective measures, (4) timely and complete corrective action, and (5) the recording and follow-up of each problem’s status. Problems in this context include documentation errors, software errors, and noncompliance with standards and procedures.

SQA activities are listed below:

1. Periodically review the corrective action process and their results against the SCM Plan to assess the effectiveness of the corrective action process.
2. Perform periodic analysis of all reported problems to identify trends that may disclose generic problem areas. These analyses shall include the study of the causes, magnitude of impact, frequency of occurrence, and preventive measures.

SQA may use the audit checklist in Figure B-11 as a guide for conducting this evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.14 Task: Media Certification

SQA shall verify that SCM certifies that the media containing the source code, and the media containing the object code which are delivered to the procuring agency, correspond to one another. SQA shall verify also that the software version represented by this media matches that on which software performance testing was performed, or correctly represents an authorized update of the code, as applicable.

SQA may use the audit checklist in Figure B-12 as a guide for conducting this evaluation.

SQA reports, together with the corrective action records, software test reports, and software product evaluation records can constitute the required evidence for certification.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.15 Task: Non-Deliverable Software Certification

The project may use non-deliverable software in the development of deliverable software as long as the operation and support of the deliverable software after delivery to the acquirer do not depend on the non-deliverable software or provision is made to verify that the acquirer has or can obtain the same software. SQA shall certify that the use of non-deliverable software meets the above criteria, that is, deliverable software is not dependent on non-deliverable software to execute, or verify that the acquirer can obtain the same software. SQA shall verify that all non-deliverable software used on the project performs its intended functions.

SQA may use the audit checklist in Figure B-13 as a guide for conducting this evaluation.

SQA reports, together with the corrective action records, software test reports, and software product evaluation records can constitute the required evidence for certification.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.16 Task: Evaluate Storage and Handling Process

SQA shall verify that there is an established plan, methodology, or set of procedures for storage and handling of the media. SQA shall evaluate the storage of the software product and documentation to verify that storage areas for paper products or media are free from adverse environmental effects such as high humidity, magnetic forces, and dust.

SQA may use the audit checklist in Figure B-14 as a guide for conducting this evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.17 Task: Evaluate Subcontractor Control

SQA shall be responsible for ensuring that the quality of all software products from subcontractors conforms to the contract requirements and that the subcontractor’s SCM plan and procedures are being followed.

SQA may use the audit checklist in Figure B-15 as a guide for conducting this evaluation.

SQA reports, together with the corrective action records, and software product evaluation records shall be provided to project management for corrective action by the subcontractor as required.

3.18 Task: Evaluate Deviations and Waivers

SQA shall assist program or project management, with requests for deviations and waivers, if required, and verify that the deviation or waiver request is processed in accordance with the project’s SCM Plan and approved by the approving agency.

SQA may use the audit checklist in Figure B-16 as a guide for conducting this evaluation.

3.19 Task: Evaluate Configuration Management Process

CM is the discipline that applies technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of CIs, (2) control the changes to CIs and their related documentation, (3) record and report information needed to manage CIs effectively, including the status of proposed changes and the implementation status of approved changes, and (4) audit the CIs to verify conformance to specifications, interface control documents, and other contract requirements.

SQA activities are listed below:

1. Verify that configuration identification of documents, code, and computer data has established standards for titling, naming, and describing change status.
2. Verify that baseline management of changes to the developmental baseline (including documents, code and computer data) are identified, reviewed, implemented, and incorporated in accordance with established procedures.
3. Verify configuration control of changes to baseline documents and software are being managed in accordance with SCM requirements as stated in the SCM Plan.
4. Verify configuration status accounting reports are prepared at established times, are prepared in accordance with established procedures, and report the status of items that are significant with respect to the management of the configuration of the software product and documentation.
5. Verify that the personnel assigned to participate in the configuration audits comply with the SCM Plan.
6. Verify for document control that only approved, up-to-date documentation is provided for use by project personnel, and that the document distribution process results in receipt of correct documentation.
7. Verify that the program support library is the single place of storage for the baseline version of all software. Verify that the identification of all software includes the software name and a unique version identifier. The evaluation shall also determine that control of access to software products is being properly exercised and that unauthorized changes to master files cannot occur.

SQA may use the audit checklist in Figure B-17 as a guide for conducting this evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.20 Task: Evaluate Software Development Library Control Process

The SDL functions as the main control point for SCM. A SDL contains all units of code developed for evolving project CIs, as well as carefully identified listings, patches, errata, CI and system magnetic tapes and disk packs, and job control streams for operating or building software systems. The SDL also contains previous versions of the operational software system in the form of magnetic tapes or disk packs.

SQA activities are listed below:

1. Verify the establishment of the SDL and procedures to govern its operation.
2. Verify that documentation and computer program materials are approved and placed under library control.
3. Verify the establishment of formal release procedures for SCM approved documentation and software versions.
4. Verify that library controls prevent unauthorized changes to the controlled software and verify the incorporation of all approved changes.

SQA may use the audit checklist in Figure B-18 as a guide for conducting this evaluation.

The results of this task shall be documented using the Process Audit Form described in Section 7 and provided to project management. SQA recommendation for corrective action requires project management’s disposition and will be processed in accordance with the guidance in Section 7.

3.21 Task: Evaluate Non-Developmental Software

Non-Developmental Software (NDS) is software that is provided by the contractor, the Government, or a third party. NDS may be referred to as reusable software, Government-furnished software, or commercially available software depending on it source. SQA shall verify that non-developmental software performs its intended functions.

SQA may use the audit checklist in Figure B-19 as a guide for conducting this evaluation.

SQA reports, together with the corrective action records, software test reports, and software product evaluation records can constitute the required evidence for certifying the software performs its intended functions.

3.22 Task: Verify Project Reviews and Audits

Define the technical and managerial reviews and audits to be conducted. State how the reviews and audits are to be accomplished. State what further actions are required and how they are to be implemented and verified. The type and scope of technical reviews depends heavily on the size, scope, risk and criticality of the software project. The reviews and audits identified here should be the same as specified in reference (e).

Table 3-1 identifies the required reviews and audits for the system and software development phases.

3.22.1 Task: Verify Technical Reviews

A primary component of engineering quality into software is the conduct of technical reviews of software products, both deliverable and non-deliverable. Participants of a technical review shall include persons with technical knowledge of the software products to be reviewed. The purpose of the technical review will be to focus on in-progress and final software products rather than the materials generated especially for the review. SQA will assure that technical reviews are accomplished and will selectively attend them in accordance with approved sampling techniques. The guidelines of MIL-STD-1521B, Technical Reviews and Audits for Systems, Equipments, and Computer Software, reference (l), may be used for conducting a technical review. A summary of each kind of technical review appears below:

1. System Requirements Review (SRR) – the objective is to ascertain the adequacy of the developer’s efforts in defining system requirements.
2. System Design Review (SDR) – the objective is to evaluate the optimization, correlation, completeness, and risks associated with the allocated technical requirements. Also included is a summary review of the system engineering process that produced the allocated technical requirements and of the engineering planning for the next phase of effort.
3. Software Specification Review (SSR) – the objective is to review the finalized CI requirements and operational concept. A successful SSR shows that the Software Requirements Specification (SRS), Interface Requirements Specification (IRS), and Operational Concept Document (OCD) form a satisfactory basis for proceeding into preliminary software design.
4. Software Preliminary Design Review (PDR) – the objective is to evaluate the progress, consistency, and technical adequacy of the selected top-level design and test approach, compatibility between software requirements and preliminary design, and the preliminary version of the operation and support documents.
5. Software Critical Design Review (CDR) – the objective is to determine acceptability of the detailed design, performance, and test characteristics of the design solution, and on the adequacy of the operation and support documents.
6. Software Test Readiness Review (TRR) – the objective is to determine whether the software test procedures are complete and to assure that the developer is prepared for formal CSCI/SU testing.
7. Formal Qualification Review (FQR) – the test, inspection, or analytical process by which a group of configuration items comprising the system are verified to have met specific program or project management performance requirements.

Table 3-1. Reviews and Audits

SYSTEM AND SOFTWARE DEVELOPMENT PHASE	SOFTWARE PRODUCTS	REQUIRED AUDITS AND REVIEWS
System Requirements	(1) System/Subsystem Specification (SSS), IRS, OCD (2) SDP, SCM Plan, SQA Plan	(1) System Requirements Review (SRR) (2) Process Audits (3) Management Review (4) Peer Review
System Design	(1) System/Subsystem Design Description (SSDD), Interface Design Description (IDD)	(1) System Design Review (SDR) (2) Process Audits (3) Management Review (4) Peer Review
Software Requirements	(1) SRS, IRS	(1) Software Specification Review (SSR) (2) Process Audits (3) Management Review (4) Peer Review
Software Design	(1) Software Design Document (SDD), Database Design Description (DBDD), IDD	(1a) Software Preliminary Design Review (PDR) (1b) Software Critical Design Review (CDR) (2) Process Audits (3) Managerial Review (4) Peer Review
Software Implementation	Software products	(1) Process Audits (2) Management Review (3) Peer Review
Test	(1) Test Documentation	(1a) Software Test Readiness Review (TRR) (1b) Formal Qualification Review (FQR) (2) Process Audits (3) Managerial Review (4) Functional Configuration Audit (5) Peer Review
Software Release	(1) Software Version Description (SVD), User documentation	(1) Production Readiness Review (PRR) (2) Process Audits (3) Management Review (4) Physical Configuration Audit (5) Peer Review

Note: Peer review is discussed in Section 4.

8. Production Readiness Review (PRR) – the objective is to determine the status of completion of the specific actions that must be satisfactorily accomplished prior to executing a production go-ahead decision.

Technical reviews will be conducted to review evolving software products, demonstrate proposed technical solutions, and provide insight and obtain feedback on the technical effort. The outcome of a technical review is listed below:

1. Identify and resolve technical issues.
2. Review project status, specifically surface near- and long-term risk regarding technical, costs, and schedule issues.
3. Arrive at agreed-upon mitigation strategies for identified risks, within the authority of those present.
4. Identify risks and issues to be raised at joint management reviews.
5. Verify on-going communications between acquirer and developer technical personnel.

The entrance criteria for a technical review will require that an item to be reviewed is distributed to the group prior to the review meeting. Additionally, a recorder will be assigned to record any issues requiring resolution stating action item assignee and due date, and decisions made within the authority of the technical review participants.

Various measurements are collected as part of technical reviews to help determine the effectiveness of the review process itself as well as the process steps that are used to produce the item being reviewed. These measurements, reported to the project manager, will include the amount of time spent by each person involved in the review, including preparation for the review.

3.22.2 Task: Verify Management Reviews

SQA periodic management review of software project status, progress, problems, and risk will provide an independent assessment of project activities. SQA will provide the following information to management:

1. Compliance – Identification of the level of compliance of the project with established organizational and project processes.
2. Problem areas – identification of potential or actual project problem areas based on analysis of technical review results.
3. Risks – identification of risks based on participation and evaluation of project progress and trouble areas.

Because the SQA function is integral to the success of the project, SQA will freely communicate its results to senior management, project management and the project team. The method for reporting compliance, problem areas, and risks will be communicated in a documented report or memorandum. Compliance, problem areas, and risks will be followed-up and tracked to closure.

3.22.3 Task: Conduct Process Audits

Software development processes are audited according to the tasks specified in this Section and performed in accordance with the software development schedule specified in the SDP.

3.22.4 Task: Conduct Configuration Audits

3.22.4.1 Functional Configuration Audit. The Functional Configuration Audit (FCA) is held prior to software delivery to compare the software as built (including its executable forms and available documentation) with the software requirements as stated in the baseline SRS. The purpose is to ensure that the code addressed all, and only, the documented requirements and functional capabilities stated in the SRS. MIL-STD-973, Configuration Management, reference (m), provides the guidelines for conducting an FCA. SQA will participate as a member of the FCA team with other FCA team members to be assigned by the project manager. SQA will assist in the preparation of the FCA findings. Any follow-up to the reported FCA finding will be monitored and tracked to closure.

3.22.4.2 Physical Configuration Audit. The Physical Configuration Audit (PCA) is held to verify that the software and its documentation are internally consistent and are ready for delivery. The purpose is to assure that the documentation to be delivered is consistent and correctly describes the code. Reference (m) provides the guidelines for conducting a PCA. SQA will participate as a member of the PCA team with other PCA team members to be assigned by the project manager. SQA will assist in the preparation of the PCA findings. Any follow-up to the reported PCA finding will be monitored and tracked to closure.

3.23 Task: Verify Software Quality Assurance

The Project Manager requests periodic independent assessments of project SQA. These assessments will be conducted at least annually. The auditor, who must be independent of the assessed SQA group, will review SQA audits conducted on the project, including documented findings and corrective actions, and will consult with project personnel to ensure that SQA activities have been accomplished, and that corrective actions have been implemented or resolved. The auditor will report findings of the independent assessment to the Project and, where appropriate, Program Manager.

Independent assessments may be requested of higher-level SQA personnel (where available, Department-level SQA personnel) or from SEPO.

3.24 Responsibilities

This paragraph should identify the specific organizational elements responsible for each task.

The ultimate responsibility for the quality of the [[Project Name]] software and associated documentation produced by [[SSC San Diego or Agency Name]] rests with the [[Project Name]] Software Project Manager. The SQA Manager shall implement the SQA procedures defined in this plan.

SQA derives its authority from the Project Manager through the [[SSC San Diego Branch/Division/Department or Agency Name]] Manager. SQA shall monitor project staff activities and review products for compliance to applicable standards, procedures, and reference (e). The results of SQA monitoring and analysis along with SQA recommendations for corrective action shall be reported to the Software Project Manager, and, as required, to the [[SSC San Diego Branch/Division/Department or Agency Name]] Manager. All documents and software approved by the Software Project Manager for release to [[user activity]] shall have been reviewed and approved by SQA. Table 3-2 is a responsibility matrix for the tasks identified in this Section.

The post SOFTWARE QUALITY ASSURANCE PLAN appeared first on My Assignment Online.

Expert Help With This Assignment — On Your Terms