Write My Assignment FREE

To verify the delivery of a fully conforming, high-quality product, every individual assigned to the project will participate in quality assurance. Reference (e) defines the procedures by which the software development staff shall verify the quality of the product during the development process. The remainder of this section describes the procedures used by SQA to verify that the quality assurance provisions of this SQA Plan and applicable standards, practices, conventions, and metrics are met.

Identify the standards (mandatory requirements) to be applied. State how compliance with these items is to be monitored and assured.

[[MIL-STD-498, reference (o) or reference (b)]] is the software development standard used by the [[Project Name]] and any tailoring of this standard is documented in reference (e). Section 3 identifies SQA evaluation of the requirements, design, implementation, and test phase to verify compliance with [[references (o) or (b)]] and reference (e).

Section 4 identifies the associated DID for each software product to be developed and maintained. Any tailoring of the DID is described in reference (e). SQA will verify documentation format and content complies with the DID and reference (e).

Standards for logic structure, coding, and code comments are described in reference (e). SQA will verify source code complies with these standards as detailed in reference (e).

Standards and practices for testing are described in reference (e). SQA will verify testing activities complies with reference (e).

5.1 Metrics

Identify or reference the standards, practices, and conventions to be used in the definition, collection and utilization of software measurement data. Cite any internal (e.g., project, corporate) and external (e.g., user, customer) requirements or standards with which metrics practices must comply. IEEE Std 1045-1992, IEEE Standard for Software Productivity Metrics, reference (p) describes conventions for counting the results of the development processes. IEEE Std 1061-1992, IEEE Standard for a Software Quality Metrics Methodology, reference (q), provides a methodology for selecting and implementing process and product metrics. IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software, reference (r) and IEEE Std 982.2-1988, IEEE Guide for using reference (r), reference (s) provide various measures for use in different life cycle phases to gain confidence in the building of reliable software. To keep metrics simple, an example of cost and schedule metrics is offered.

The following measurements will be made and used to determine the cost and schedule status of the SQA activities:

1. SQA milestone dates (planned)
2. SQA milestone dates (completed)
3. SQA work scheduled (planned)
4. SQA work completed (actual)
5. SQA effort expended (planned)
6. SQA effort expended (actual)
7. SQA funds expended (planned)
8. SQA funds expended (actual)
9. Number of noncompliance items open
10. Number of noncompliance items closed
11. Total Number of noncompliance items

SQA is responsible for reporting these measurements to the Project Manager on a monthly basis.

Section 6. TEST

Identify all other tests not included in verification and validation and state the methods used. Describe any testing techniques or methods that can be used to detect errors, to develop sets of test data, and to monitor computer system resources.

[[Project Name]] testing activity includes unit level testing, integration testing (at Unit and CI/HWCI level), performance testing (CI Qualification Testing), and acceptance testing (System Qualification Testing). Figure 6-1 provides the Test Process Flow. SQA shall audit the testing activities as defined in reference (e), and shall verify that the software and test documentation is subject to configuration management control. SQA shall witness the tests and verify that test results are recorded and evaluated. SQA shall coordinate the maintenance of Problem/Change Report (P/CR), sometimes called Software Trouble Report (STR), logs with SCM and shall verify that software changes are controlled according to reference (e). SQA shall witness regression testing resulting from P/CRs or STRs to verify the effectiveness of the correction.

Table 6-1. Test Process Flow Diagram

This page intentionally left blank.

Section 7. SQA PROBLEM REPORTING AND Resolution

Describe the practices and procedures to be followed for reporting, tracking, and resolving problems identified in both software items and the software development and maintenance procesess. State the specific organizational responsibilities concerned with their implementation.

This section describes the reporting and control system used by SQA to record and analyze discrepancies and to monitor the implementation of corrective action. The forms utilized by SQA for reporting are the Process Audit Report, P/CR or STR, Software Tool Evaluation Report, and Facilities Evaluation Report. Each of these forms and their uses are discussed in the following section.

7.1 Process Audit Report

SQA reports the results of a process audit and provides recommendations, if necessary, using the Process Audit Report. The Process Audit Report is used to record that the process is (1) being followed correctly and working effectively, (2) being followed but is not working effectively, or (3) not being followed.

Figure 7-1 provides the format of a Process Audit Report.

7.1.1 Submittal and Disposition of Process Audit Report

The Process Audit Report is directed to the groups listed below:

1. Senior Management – The results of process audits are used in conjunction with other project status information to guide senior management attention to identify and mitigate project risks at the organizational level.
2. SEPG – The SEPG utilizes the process audits results, in conjunction with the results of audits of other projects, to identify process weaknesses and initiate or enhance process improvement in specific areas. This data becomes part of the process database so that it is available for future project analysis and use.
3. Project Manager – The project manager utilizes the report in the ways listed below:
   1. To provide insight into whether there is compliance with the development process and its effectiveness in meeting project goals. Where necessary and appropriate, the project manager may initiate enforcement activities or initiate change to the established processes using the approved procedures.
   2. To indicate agreement, disagreement, or deferral of recommendations cited in the Process Audit Report. Should the Project Manager indicate disagreement with the recommendations recorded on the Process Audit Report, the final disposition of report recommendations is made by the appropriate Project Sponsor as described in Section 7.1.2.

PROCESS AUDIT REPORT

TRACKING IDENTIFIER:____________

LEAD AUDITOR:______________________________________ DATE OF REPORT:_____________

AUDIT TEAM:_____________________________________________________________________________

____________________________________________________________________________________

PROJECT NAME:____________________________________________________________________

DATE OF AUDIT:________________________

PROCESS/PROCEDURE AUDITED:_____________________________________________________

AUDIT CHECKLIST USED: (Attach)_____________________________________________________

AUDIT FINDINGS: (Check one.)

_____ Process/Procedure Acceptable

_____ Process/Procedure Conditionally Acceptable

(Subject to satisfactory completion of action items listed below)

Conditions noted:

_____ Process/Procedure Unacceptable

(Subject to satisfactory completion of action items listed below)

Conditions noted:

____________________________________________________________________________________________ACTION ITEM (AI):

AI # TITLE ASSIGNED TO: DUE DATE: COMP DATE:___

____________________________________________________________________________________

____________________________________________________________________________________

____________________________________________________________________________________

CORRECTIVE ACTION:

____________________________________________________________________________________

DISPOSITION: APPROVE CANCEL DEFER

Project Manager: DATE:

____________________________________________________________________________________

AI CLOSURE:

SQA Sign-off: DATE:

(FILE COMPLETED FORM IN SQA EVALUATION RECORD.)

Figure 7-1. Process Audit Report

7.1.2 Escalation Procedure for Resolution of Non-Concurrence on Process Audit Report

In the event that affected project personnel dispute the findings and recommendations of a Process Audit Report, SQA will first communicate with the affected Project Manager to resolve the dispute. If the affected Project Manager also disputes the findings and/or recommendations, the Project Sponsor (or at least one management level higher than that affected by the Process Audit Report recommended actions) directs final disposition of Process Audit Report recommendations. The affected project implements, defers, or cancels the implementation of corrective actions recommended on the Process Audit Report as directed by the Project Sponsor/Upper Level Manager. This direction is recorded and dated by the Project Sponsor (or other management, as appropriate) to be added to the SQA evaluation records of the project. SQA retains the original record of findings and subsequent resolution data in its audit files.

7.2 Recording Problems in Software Code or Documentation

Problems found in the software code or documentation that is under configuration management must be recorded by means of a P/CR (or STR, as appropriate to the project) regardless of how or by whom the problem was discovered. P/CRs generated by SQA shall be prepared and processed in accordance with reference (f). SQA shall analyze P/CRs for problem trends in an effort to prevent recurring discrepancies. SQA shall report the results of P/CR trend analyses along with suggestions for problem resolution and prevention. The format of the P/CR or STR is found in reference (f).

7.3 Software Tool Evaluation Report

Figure 7-2 provides the format for evaluating software tools as described in Section 3.2.

7.4 Facilities Evaluation Report

Figure 7-3 provides the format for evaluating existing and planned [[Project Name]] facilities as described in Section 3.3.

SOFTWARE TOOL EVALUATION

SQA:_________________________ DATE OF EVALUATION:___________

Software Tool Evaluated:

Methods or criteria used in the evaluation:

Evaluation Results:

Recommended Corrective Actions

Corrective Action Taken

Figure 7-2. Software Tool Evaluation

PROJECT FACILITIES EVALUATION

SQA:_________________________ DATE OF EVALUATION:__________

Facility Evaluated (Equipment, User/Test/Library Space):

Methods or criteria used in the evaluation:

Evaluation Results:

Recommended Corrective Actions

Corrective Action Taken

Figure 7-3. Project Facilities Evaluation

This page intentionally left blank.

Section 8. TOOLS, TECHNIQUES, AND METHODOLOGIES

Identify the special software tools, techniques, and methodologies that support SQA, state their purposes, and describe their use.

Tools – SQA software tools include, but are not limited to, operating system utilities, debugging aids, documentation aids, checklists, structuring preprocessors, file comparators, structure analyzers, code analyzers, standards auditors, simulators, execution analyzers, performance monitors, statistical analysis packages, software development folder/files, software traceability matrices, test drivers, test case generators, static or dynamic test tools, and information engineering CASE tools.

Techniques – techniques include review of the use of standards, software inspections, requirements tracing, requirements and design verification, reliability measurements and assessments, and rigorous or formal logic analysis.

Methodologies – methodologies are an integrated set of the above tools and techniques. The methodologies should be well documented for accomplishing the task or activity and provide a description of the process to be used.

Where applicable, SQA will use SEPO organizational processes and tailor the processes specific to the project.

This page intentionally left blank.

Section 9. CODE CONTROL

The purpose of this section is to define the methods and facilities used to maintain, store, secure and document controlled versions of the identified software during all phases of the software life cycle whose appropriate use will be verified by SQA. This may be implemented in conjunction with a computer program library. This may be provided as a part of the SCM Plan. If so, an appropriate reference should be made.

Code control includes the items listed below:

1. Identifying, labeling, and cataloging the software to be controlled
2. Identifying the physical location of the software under control
3. Identifying the location, maintenance, and use of backup copies
4. Distributing copies of the code
5. Identifying the documentation that is affected by a change
6. Establishing a new version
7. Regulating user access to the code.

[[Project Name]] uses [[identify CM Code Control Software]] for code control. The code control method is described in reference (f). SQA will conduct ongoing evaluations of the code control process to verify that the process of controlling the code is effective and in compliance with reference (f). Section 3.19 further describes SQA activities for verifying the SCM process.

This page intentionally left blank.

Section 10. MEDIA CONTROL

The purpose of this section is to state the methods and facilities to be used, and whose proper use is to be verified by SQA, to identify the media for each computer product and the documentation required to store the media, including the copy and restore process, and to protect the computer program physical media from unauthorized access or inadvertent damage or degradation during all phases of the software life cycle. This may be provided as a part of reference (f). If so, an appropriate reference should be made.

Media control includes the items listed below:

1. Regularly scheduled backup of the media.
2. Labeled and inventoried media filed in a storage area in accordance with security requirements and in a controlled environment that prevents degradation or damage to the media.
3. Adequate protection from unauthorized access.

The software media control methods and facilities are described in reference (f). SQA will conduct ongoing evaluations of the software media control process to verify that the process of controlling the software media is effective and in compliance with reference (f). Further guidelines for SQA verification of media control are described in Section 3.16.

This page intentionally left blank.

Section 11. SUPPLIER CONTROL

The purpose of this section is to state the provisions by which SQA assures that software provided by suppliers meets established requirements.

Prior to any purchase of software to support the development effort, SQA and project members will define and provide complete requirements to the supplier/vendor. The Software Tool Evaluation Process will be followed. Part of the evaluation process will require the supplier or vendor to describe their technical support, handling of user questions and problems, and software product upgrades. Further guidance for SQA verification activities is described in Sections 3.17 and 3.21.

In some cases, projects do not foresee purchasing software. If that’s the case, the following paragraphs may apply.

All supplier software has been operationally tested in the target system. No future supplier software is planned.

The post STANDARDS, PRACTICES, CONVENTIONS AND METRICS appeared first on My Assignment Online.

Expert Help With This Assignment — On Your Terms