Chapter 9 SQA Planning

8/11/2019 Chapter 9 SQA Planning

1/44

Chapter 9

FUNDAMENTALS OF SQAPLANNING


2/44

Objectives

Upon completing this chapter, you will be ableto: Define the benefits of SQA for projects specified Modify SQAP checklists for organization-specific projects Incorporate quality assurance with an overall organization Set the standards and procedures for the specific project

implement the SQAP to develop quality end product Develop an SQA plan that complies with the identified

goals.


3/44

BUILDING BLOCKS OF SOFTWAREQUALITY ASSURANCE

IEEE Guideline for Software Quality Assurance Planning[IEEE Std 730.1-1995] defines defines following building

blocks to develop software quality: Purpose Reference Documents Management Documentations Standards, Practices, Conventions, and Metrics

Review, and Audits Test Problem Reporting and Corrective Actions


4/44

BUILDING BLOCKS OF SOFTWAREQUALITY ASSURANCE (cont.)

Tools, techniques, and Methodologies Code Control Media Control

Supplier Control Records Collection, Maintenance, and Retention Training Risk Management


5/44

PURPOSE

This section identifies the specific purposeand scope of SQAP by: developing the names of software items

covered by SQAP and the use of software.

It shall answer for the questions like how issoftware to be used? How critical is this

software? Who does it apply to? Which portion of the software life cycle applies toeach of software items? Etc.


6/44

REFERENCE DOCUMENTS

This section will provide the complete listof document referenced to develop SQAP,e.g. Military, industry specific or corporatequality assurance standards and guidelines.


7/44

MANAGEMENT

This section with the major elements of theorganization that influences the quality ofsoftware, list of tasks covered by this planand specification of organizationresponsible for each task.

Therefore, IEEE has described this conceptto be incorporated in SQA planning-Organization, Tasks and Responsibilities


8/44

Organization This section of SQA plan will depict the

organizational structure by describing eachmajor elements of organization togetherwith the delegated responsibilities.

Project Manager

ManagementTeam

ArchitectureTeam

DevelopmentTeam

AssessmentTeam

Common Organisational Structure


9/44

Role and Responsibilities i) Project Manager:

Project manager is responsible for providingrequirements and directions, reporting bugs and issuesfound by himself and the supervisory committee.Project manager hosts status meeting time to time tocheck the status of project. Project manager is alsoresponsible for grading presentation.

ii) Management Team: Management team is responsible for planning the

effort, conducting the plan and adapting the plan tochanges in understanding of the requirements or thedesign.


10/44

iii) Architecture Team: Architecture team is responsible for the use case

modelers, and for achieving the system-wide qualities.

iv) Development Team: Development team is the most popular team, which is

responsible for quality of individual components,component development, testing and maintenance.

v) Assessment Team: Assessment team is responsible for quality of end

product with respect to the requirement and customerexpectation.

Role and Responsibilities


11/44

Tasks

This section of the plan should identify the planned major checkpoint to assure the

quality, the tasks to be performed withspecial emphasis on software qualityassurance activities and the relationship

between the tasks and the plannedcheckpoints.


12/44


13/44

iii) Architecture Team: It is responsible to resolve the design issues. Architecture team focuses on architecture properties,

architecture maintenance, multiple component issueresolution, performance tuning and qualityimprovements.

iv) Development Team: This team decides how a design or implementation

issues local to a single component is resolved. Itfocuses on critical design, implementation, test andmaintenance.

Associated Tasks


14/44


15/44

DOCUMENTATIONS

This is an important section of quality assurance plan as it identifies the the team, documentationsgoverning the development, verification andvalidation, use and maintenance of software.

The main emphasis of this section is on how thedocuments are to be checked for adequacy byidentifying the appropriate review or audits.

Minimum documents required to ensure that theimplementation of software satisfy requirements,may be listed as follows:


16/44

Software Requirement Specification (SRS)

ii) Software Design Description (SDD) iii) Software Verification and Validation Plan

(SVVP) iv) Software Verification and Validation Report

(SVVR) v) User Documentation (UD) vi) Software Configuration Management Plan

(SCMP) Other documentation such as Sw Dev Plan,

Standards and procedures, Sw ProjectManagement Plan and Sw Maintenance Manual


17/44

STANDARDS, PRACTICES,CONVENTIONS AND METRICS

This section will describe the standards, practices, conventions and metrics to beemployed by all associated with the projectincluding management and vendors.


18/44

REVIEWS AND AUDITS

To determine the extent of program of thesoftware developed during the software

development life cycle and to evaluate thetechnical adequacy of the work and itsconformance to software requirements, it is

necessary to review and audit the producton a planned basis.


19/44

i) Software Requirement Review: This review wil1 guarantee the technical feasibility,

adequacy, and completeness of the requirements as

outlined in SRS. It wil1 occur after the initialsubmission of the SRS. Software development team isresponsible to perform such type of review.

ii) Preliminary Design Review:

This is also known as top-level design review. Thisreview is to evaluate the technical adequacy of the preliminary design of the software as depicted in thesoftware architectural design description.

iii) Critical Design Review: The critical design review (CDR) is held to determine

the acceptability of the detailed software design asdepicted in the detailed software design description insatisfying the request in SRS.


20/44


21/44

vi) Physical Audits:

This audit is conducted to verify that the software andits documentation are internally consistent and areready for delivery.

vii) In-Process Audits: In-process audit verifies the consistency of the design

from the various aspects including code versus designdocumentation, interface specifications, designimplementation versus functional requirements andfunctional requirements versus test descriptions.

viii) Managerial Review: Managerial reviews assess the execution of all actions

with items identified in software quality assurance plans


22/44

ix) Software Configuration Management PlanReview: The adequacy and completeness of configuration

management methods defined in software configurationmanagement plan will be evaluated through softwareconfiguration management plan review.

x) Post-Mortem Review: On the successful completion of project, the

development team will submit it to supervisingcommittee to be reviewed. Now the committee has todecide the approval of project. The project isconsidered as complete, when supervisory committeeapproves it.


23/44

TEST Software test plan will be developed by qualityassurance team to outline the test activities, schedule

and resources required for testing and how the test will be implemented.

The entire specific software tests and testing, which arenot addressed in SVVP, will be included in this section.

The testing process described in SQAP may be used toaddress the preparation and review of documentation

associated with the testing process, including test plans,test design and test case specification, etc.


24/44

PROBLEM REPORTING AND

CORRECTIVE ACTION This section deals with the responsibility of

SQA team to provide the continuous feedbackconcerning the problem status to managementand technical team, and describe the practicesand procedures to be followed for reporting,

tracking, and resolving problems identified.


25/44

The tasks performed during the problem reportingand corrective action may be listed as follows: .Identification of all development discrepancies and

submission to development team Validation check for the items submitted to team. Data base maintenance for all discrepancies found in

report. Documentation of system and process related problems

identified by SQA on report. Problem resolution by the end of working session.

Conducting meeting to handle any dispute among teamand relevant parties with manager as a mediator. Documentation and maintenance database for any

problem resolved by the team members.


26/44

TOOLS, TECHNIQUES AND

METHODS This section will describe the specific

software tolls, techniques and methodologies

to be used to support software qualityassurance activity.


27/44

Tools Numerous tools have been proposed in literature for

this purpose. Few of them may be listed as follows: Operating System Utilities - Simulators

Performance Monitor - Test Drivers Structure Analyzer - Code Analyzer Execution Analyzer - Test case Generator

Statistical Analysis Package - Rational Rose Enterprise

Static or Dynamic Test Tools


28/44

Techniques One of the technical and managerial procedures

used to evaluate and improve requirements isSQA technique, such as listed below:

Review of the use of standards Software Inspection Requirements Tracing Requirements and Design Verification Reliability Measurement and Assessments


29/44

CODE CONTROL

It is a way to protect or ensure the validityof completed code. Methods and facilities

used to maintain, store, secure anddocument controlled version of theidentified software during all phases of

software life cycle, will be discussed in thissection.


30/44

MEDIA CONTROL

In this section, methods and facilities will be usedto identify the media for each product anddocumentation required to store the media and to

protect these media from unauthorized access ordamage during the development life cycle.

This activity will assure the software storage andretrieval process, accessibility of software to thosewith the need of access, and controls environmentso that the physical media on which the softwareis stored do not degrade.


31/44

SUPPLIER CONTROL

This section will assure that the developedsoftware meets the established requirements

by assuring that the developer receives theadequate and complete requirements.


32/44

RECORDS COLLECTION,MAINTENANCE AND

RETENTION

All the projects artifacts will be stored inconfiguration management system.

A copy of each deliverable will be given to the project manager upon completion of the project.

This section deals with retaining, assembling,safeguarding, and maintaining the documentation.


33/44

TRAINING

This section deals with team trainingsession carried out whenever necessary to

familiarize the team members to new toolsor techniques. The technical manager may prepare this

training. Clients may also be trained after delivering

the software upon the client's request.


34/44

RISK MANAGEMENT

This section will deal with ensuring that any potentialrisks are identified and discussed fully in team meeting.

Risk Notification Procedure will record the risk thatarises throughout the duration of the project.

Risk management is responsible for identifying thelevel of risk associated with the possible failure of eachrequired task or the unavailability of each resource andwill quantify the magnitude of each identified risk.


35/44


36/44

Meta-checklist Examples

Purpose Intended use of the software covered by SQAP has been defined:

Scope of SQAP has been identified: Basic Objective of writing SQAP has been specified:

Software items covered by SQAP has been abbreviated:

Software life cycle development model used has been described:

The reasons for choosing supporting documents that form basisof SQAP has been presented:


37/44

Reference Documents All the documents that form the basis of SQAP has been

listed: These documents has been originated outside the project: The use of most current official version of document has

been ensured : All the standards, procedures and guidelines has been listed: Deviations from identified standards, procedures and

guidelines as been listed: Software deliverables requiring additional or rigorous

practices, procedures or guidelines has been identified:


38/44

Management

i) Organization An appropriate organizational structure has been presented: Each major elements of organization together with the

delegated responsibilities has described: The relationship among SQA organizational elements and

software development elements has been delineated andexplained:

A process to resolve all the conflicts has been followed:


39/44

ii) Tasks Major checkpoints to assure the quality has been identified: Tasks to be performed with special emphasis on software

quality assurance activities has been listed: The relationship between the tasks and planned checkpoints

has been established and shown: A workflow diagram has been designed for SQA activities:


40/44

iii) Responsibilities All the specific organizational elements responsible

for each tasks has been listed: Responsibilities of individuals have been identified

if two organizational elements are sharing theresponsibilities for task.


41/44

Documentation All the documents governing the development, verification and

validation, use and maintenance of software has been identified: An appropriate way to check for adequacy of documents has been

emphasized: Minimum documents required to ensure the implementation has

been identified: All required test documentation has been noted:


42/44


43/44

SUMMARY Software quality assurance is more about the

customer. Creating a product that has gone through proper

software testing is crucial to guaranteeingcustomer satisfaction.

Quality planning involves deciding on a suitabledevelopment process and setting target values forinternal attributes.

Quantitative targets are set for the internal qualityattributes identified in the quality model.


44/44

Below is the meta-checklist prepared toverify and ensure the quality of SQAP.

Chapter 9 SQA Planning

Documents

Transcript of Chapter 9 SQA Planning