Software quality assurance plan document

The SQA procedures defined herein shall be used to examine all deliverable software and documentation to determine compliance with technical and performance requirements.

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]]. The system includes [[enter the number of subsystems, e. TABLE 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. 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. 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.

Reference e and its implementation procedures establish the SQA evaluation criteria. For the following, add or delete documents that were referenced in the SQA Plan. IEEE Std Std 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 shows the SQA organization with relation to the project organization. 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: a. Who interacts with SQA? Who has authority and delegates responsibilities of interacting functions?

Who has product release authority? Who approves the SQA Plan? 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.

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. Establishing a quality program by committing the project to implement the Software Engineering Process Policy, reference g , and reference a.

Resolving and following-up on any quality issues raised by SQA. Identifying the quality factors to be implemented in the system and software. Project Management is responsible for: 1.

Implementing the quality program in accordance with references g and a. Identifying and funding an individual or group independent from the project to perform the SQA functions.

Identifying and ensuring the quality factors to be implemented in the system and software. System Engineering is responsible for: 1. Implementing the quality program in accordance with this SQA Plan.

Resolving and following-up on any quality issues raised by SQA related to software engineering activities. Identifying, implementing, and evaluating the quality factors to be implemented in the system software and hardware.

Resolving and following-up on any quality issues raised by SQA related to software design and development. Identifying, implementing, and evaluating the quality factors to be implemented in the software.

Software Test is responsible for: 1. Resolving and following-up on any quality issues raised by SQA related to software test. Verifying the quality factors are implemented in the system, specifically software.

System Test is responsible for: 1. Resolving and following-up on any quality issues raised by SQA as related to system test. Verifying the quality factors are implemented in the system software and hardware. Logistics is responsible for: 1. Ensuring the quality factors are implemented in the software related to SCM.

Verifying the quality factors are implemented in the system hardware and software. Keeping references a and g current. Providing assistance in software process engineering and software process improvement. SQA will have access to computer resources to perform SQA functions such as process and product evaluations and audits. Additionally, the SQA Manager will be familiar with software quality, software development- related activities, and structured analysis, design, coding, and testing.

The sequence of the tasks should be indicated. 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. The following tasks, requiring coordination and cooperation with the project team, shall be performed by SQA.

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

Section 1. 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.

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.

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: a. Verify that the correct participants are involved in the system requirements analysis process to identify all user needs. Verify that requirements are reviewed to determine if they are feasible to implement, clearly stated, and consistent. Verify that changes to allocated requirements, work products and activities are identified, reviewed, and tracked to closure. 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.

Verify that the commitments resulting from allocated requirements are negotiated and agreed upon by the affected groups. Verify that commitments are documented, communicated, reviewed, and accepted. 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.

Verify that the prescribed processes for defining, documenting, and allocating requirements are followed and documented. Confirm that a configuration management process is in place to control and manage the baseline. Verify that requirements are documented, managed, controlled, and traced preferably via a matrix.

Verify that the agreed upon requirements are addressed in the SDP. 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. Verify that system design documents and the traceability matrix are prepared and kept current and consistent. Verify that relevant documents are updated and based on approved requirements changes. 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. Participate in a sampled set of design walkthroughs and verify all walkthroughs are conducted.

Identify defects, verify resolution for previous identified defects, and verify change control integrity. Selectively review and audit the content of system design documents. Identify lack of compliance with standards and determine corrective actions.

Determine whether the requirements and accompanying design and tools conform to standards, and whether waivers are needed prior to continuing software development. Review demonstration prototypes for compliance with requirements and standards. Verify that the demonstration conforms to standards and procedures. Review the status of design milestones. SQA may use the audit checklist in Figure B-4 as a guide for conducting the evaluation.

Section 4 lists the software requirements documents. 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.

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

Verify that action items resulting from reviews of the design are resolved in accordance with these standards and procedures. 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.

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 process includes unit testing of the software code. 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.

Verify that action items resulting from reviews of the code are resolved in accordance with these standards and procedures. 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. 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.

Reference PG Reference WI The following are typical product assessments that may be conducted by SQ personnel. See the SQ Activity Schedule for the planned assessments:. Peer Review packages Document Reviews see Section 4, Documentation Software Development Folders Software Configuration Management configuration baselines, configuration change requests, and change control records Test results e. The following are typical process assessments that may be conducted by SQ personnel.

Responsibilities include, but are not limited to:. The following are the primary responsibilities for Safety and Reliability personnel in support of software assurance. Staffing to support software assurance i.

The staffing resource levels provided in the table below represent what has currently been agreed upon between Project Management and the SAM. Download also:. Only through the result of this review, the Management Board can evaluate the quality of your project handling. The goal of SQA plan is to craft planning processes and procedures to ensure products manufactured, or the service delivered by the organization are of exceptional quality.

In a project team, every member must have responsibility for the quality of his or her work. Each person has to make sure their work meet the QA criteria. The SQA team is the group of person who plays the major role in the project. Without QA, no business will run successfully. Step 1. For example, for the project Guru99 Bank, you can list out the work products of each Test Management Process and define permission for SQA members to access these work products as per the following table.

In this step, the Test Manager should describe the tasks to be performed by SQA auditor with special emphasis on SQA activities as well as the work product for each task. Test Manager also creates the scheduling of those SQA tasks. Normally, the SQA schedule is driven by the project development schedule. Therefore, an SQA task is performed in relationship to what software development activities are taking place. To review the Management activities against the standards process, you should do the following steps.