SOFTWARE QUALITY ASSURANCE PLANS

INTRODUCTION
The Software Quality Assurance Plan helps to put aside the steps towards the quality goals of the association. A standard
for SQA arrangement is prearranged in the IEEE 94.
The Software Quality Assurance Plan helps to put aside the steps towards the quality goals of the
association. A standard for SQA arrangement is prearranged in the IEEE 94. It gives details and
templates on all activities, which have developed into part of the standard and which make sure
quality standard implementation.

PURPOSE

The purpose of a Software Quality Assurance Plan is to define the techniques, procedures,
and methodologies that are used to assure timely delivery of the software that meets
specified requirements within project resources. The plan identifies the documentation
governing the development, verification and validation use and maintenance of the
software. The plan lists the documents audited for accuracy and identifies the criteria by
which validation is confirmed.
STEPS
The documentation of SQA plan includes:
·         Project plan
·         Models of data, classes and objects, processes, design architecture
·         Software Requirement Specification
·         Test plans for testing SRS
·         User helps documentations, manuals, on line help, etc.
·         Review and audits

The SQA procedure is made up of numerous activities. Some are software specific, some are
organization specific and some are customer specific. It helps successful application of tools,
methods, test plan and standards towards the objective of software quality. It also includes
measures, measurements and matrices for construction a quality traditions in the organization

CONCEPTS AND DEFINITIONS

Software Quality Assurance (SQA) is defined as a planned and systematic approach to the
evaluation of the quality of and adherence to software product standards, processes, and
procedures. SQA includes the process of assuring that standards and procedures are established
and are followed throughout the software acquisition life cycle. Compliance with agreed-upon
standards and procedures is evaluated through process monitoring, product evaluation, and
audits. Software development and control processes should include quality assurance approval
points, where an SQA evaluation of the product may be done in relation to the applicable
standards.

STANDARDS AND PROCEDURES

Establishing standards and procedures for software development is critical, since these provide
the framework from which the software evolves. Standards are the established criteria to which
the software products are compared. Procedures are the established criteria to which
the development and control processes are compared. Standards and procedures establish the
prescribed methods for developing software; the SQA role is to ensure their existence and
adequacy. Proper documentation of standards and procedures is necessary since the SQA
activities of process monitoring, product evaluation, and auditing rely upon unequivocal
definitions to measure project compliance.

Types of standards include:

Documentation Standards specify form and content for planning, control, and product
documentation and provide consistency throughout a project.
Design Standards specify the form and content of the design product. They provide rules and
methods for translating the software requirements into the software design and for representing it
in the design documentation.
Code Standards specify the language in which the code is to be written and define any
restrictions on use of language features. They define legal language structures, style
conventions, rules for data structures and interfaces, and internal code documentation.
Procedures are explicit steps to be followed in carrying out a process. All processes should have
documented procedures .Examples of processes for which procedures are needed are
configuration management, nonconformance reporting and corrective action, testing, and formal
inspections.

SOFTWARE QUALITY ASSURANCE ACTIVITIES

Product evaluation and process monitoring are the SQA activities that assure the software
development and control processes described in the project's Management Plan are correctly
carried out and that the project's procedures and standards are followed. Products are monitored
for conformance to standards and processes are monitored for conformance to procedures.Audits
are a key technique used to perform product evaluation and process monitoring.Review of the
Management Plan should ensure that appropriateSQA approval points are built into these
processes.

SQA RELATIONSHIPS TO OTHER ASSURANCE ACTIVITIES

Some of the more important relationships of SQA to other management and assurance activities
are described below.
1. CONFIGURATION MANAGEMENT MONITORING

SQA assures that software Configuration Management (CM) activities are performed in
accordance with the CM plans, standards, and procedures. SQA reviews the CM plans for
compliance with software CM policies and requirements and provides follow-up for
nonconformances. SQA audits the CM functions for adherence to standards and procedures and
prepares reports of its findings.
The CM activities monitored and audited by SQA include baseline control, configuration
identification, configuration control, configuration status accounting, and configuration
authentication. SQA also monitors and audits the software library. SQA assures that:
Software configuration identification is consistent and accurate with respect to the numbering or
naming of computer programs, software modules, software units, and associated software
documents.
Configuration control is maintained such that the software configuration used in critical phases
of testing, acceptance, and delivery is compatible with the associated documentation.
Configuration status accounting is performed accurately including the recording and reporting of
data reflecting the software's configuration identification, proposed changes to the configuration
identification, and the implementation status of approved changes.
Software configuration authentication is established by a series of configuration reviews and
audits that exhibit the performance required by the software requirements specification and the
configuration of the software is accurately reflected in the software design documents.
Software development libraries provide for proper handling of software code, documentation,
media, and related data in their various forms and versions from the time of their initial approval
or acceptance until they have been incorporated into the final media.
Approved changes to baselined software are made properly and consistently in all products, and
no unauthorized changes are made.

2. VERIFICATION AND VALIDATION MONITORING

SQA assures Verification and Validation (V&V) activities by monitoring technical reviews,
inspections, and walkthroughs. The SQA role in formal testing is described in the next
section. The SQA role in reviews, inspections, and walkthroughs is to observe, participate as
needed, and verify that they were properly conducted and documented.SQA also ensures that any
actions required are assigned,documented, scheduled, and updated.

Formal software reviews should be conducted at the end of each phase of the life cycle to
identify problems and determine whether the interim product meets all applicable
requirements.Examples of formal reviews are the Preliminary Design Review (PDR), Critical
Design Review(CDR), and Test Readiness Review (TRR). A review looks at the overall picture
of the product being developed to see if it satisfies its requirements. Reviews are part of the
development process, designed to provide a ready/not-ready decision to begin the next phase. In
formal reviews, actual work done is compared with established standards. SQA's main objective
in reviews is to assure that the Management and Development Plans have been followed, and
that the product is ready to proceed with the next phase of development. Although the decision
to proceed is a management decision, SQA is responsible for advising management and
participating in the decision.
3. FORMAL TEST MONITORING

SQA assures that formal software testing, such as acceptance testing, is done in accordance with
plans and procedures.SQA reviews testing documentation for completeness and
adherence to standards. The documentation review includes test plans, test specifications, test
procedures, and test reports. SQA monitors testing and provides follow-up on nonconformances.
By test monitoring, SQA assures software completeness and readiness for delivery.

SOFTWARE QUALITY ASSURANCE DURING THE SOFTWARE

ACQUISITION LIFE CYCLE

In addition to the general activities described in subsections C and D, there are phase-specific
SQA activities that should be conducted during the Software Acquisition Life Cycle. At the
conclusion of each phase, SQA concurrence is a key element in the management decision to
initiate the following life cycle phase.Suggested activities for each phase are described below.

1. SOFTWARE CONCEPT AND INITIATION PHASE

SQA should be involved in both writing and reviewing the Management Plan in order to assure
that the processes, procedures, and standards identified in the plan are appropriate, clear,
specific, and auditable. During this phase, SQA also provides the QA section of the Management
Plan.

2. SOFTWARE REQUIREMENTS PHASE

During the software requirements phase, SQA assures that software requirements are complete,
testable, and properly expressed as functional, performance, and interface requirements.

3. SOFTWARE ARCHITECTURAL (PRELIMINARY) DESIGN PHASE

SQA activities during the architectural (preliminary) design phase include:

 Assuring adherence to approved design standards as designated in the Management Plan.

 Assuring all software requirements are allocated to software components.
 Assuring that a testing verification matrix exists and is kept up to date.
 Assuring the Interface Control Documents are in agreement with the standard in form and
content.
 Reviewing PDR documentation and assuring that all action items are resolved.
  Assuring the approved design is placed under configuration management.

4. SOFTWARE DETAILED DESIGN PHASE

SQA activities during the detailed design phase include:

 Assuring that approved design standards are followed.

 Assuring that allocated modules are included in the detailed design.
 Assuring that results of design inspections are included in the design.
 Reviewing CDR documentation and assuring that all action items are resolved.

5. SOFTWARE IMPLEMENTATION PHASE

SQA activities during the implementation phase include the audit of:

 Results of coding and design activities including the schedule contained in the Software
Development Plan.
 Status of all deliverable items.
 Configuration management activities and the software development library.
 Nonconformance reporting and corrective action system.

6. SOFTWARE INTEGRATION AND TEST PHASE

SQA activities during the integration and test phase include:

 Assuring readiness for testing of all deliverable items.
 Assuring that all tests are run according to test plans and procedures and that any
nonconformances are reported and resolved.
 Assuring that test reports are complete and correct.
 Certifying that testing is complete and software and documentation are ready for
delivery.

Participating in the Test Readiness Review and assuring all action items are completed.

7. SOFTWARE ACCEPTANCE AND DELIVERY PHASE

As a minimum, SQA activities during the software acceptance and delivery phase include
assuring the performance of a final configuration audit to demonstrate that all deliverable items
are ready for delivery.

8. SOFTWARE SUSTAINING ENGINEERING AND OPERATIONS PHASE

During this phase, there will be mini-development cycles to enhance or correct the software.
During these development cycles, SQA conducts the appropriate phase-specific activities
described above.
TECHNIQUES AND TOOLS

SQA should evaluate its needs for assurance tools versus those available off-the-shelf for
applicability to the specific project, and must develop the others it requires.Useful tools might
include audit and inspection checklists and automatic code standards analyzers.