Water Cooler SQA Plan

8/8/2019 Water Cooler SQA Plan

1/62

Watercooler

Submitted by:

Alvarez, Guillard

Dalangin, Cris

Lu, Pamela

Villamejor, Joey Nyl

Software QualityAssurance (SQA) Plan


2/62

P R E F A C E

This document contains the Software Quality Assurance Plan for the Watercooler Project.The activities and tasks outlined in this document are consistent with the existing Software

Development Plan and project documentation for the system.

The Watercooler Development Team assumes responsibility for the maintenance of this

document according to the needs of the Watercooler Project. Users of this document may

report deficiencies or corrections through a Document Change Request Form that can be

found at the end of the document.


3/62

S I G N A T U R E P A G E

Prepared By:

______________________________ ______________(Signature above printed name) (Date)

Reviewed By:



Approved By:



4/62

A M E N D M E N T H I S T O R Y

Version

Number

Description of Change Change

Request

Number

Approved By Date

Approved


5/62

T A B L E O F C O N T E N T S

1. Purpose ......................................................................................................................... 8

1.1. Scope ..................................................................................................................... 8

2. Reference Documents ................................................................................................... 9

3. Management .................................................................................................................. 9

3.1. Management Organization ...................................................................................... 9

3.1.1. The Watercooler Project Team ...................................................................... 10

3.1.2. The Assurance Management Team ............................................................... 11

3.2. Resources............................................................................................................. 11

3.2.1. Facilities and Equipment ................................................................................ 11

3.2.2. Personnel ...................................................................................................... 11

3.2.2.1. The Watercooler Project Team ................................................................... 11

3.2.2.2. The Assurance Management Team............................................................ 12

3.3. SQA Tasks............................................................................................................ 13

3.3.1. Evaluate the Overall Development Environment ............................................ 13

3.3.2. Evaluate the Requirements Analysis Phase ................................................... 13

3.3.3. Evaluate the Software Design and Development Process.............................. 14

3.3.4. Evaluate the Implementation and Testing Phase ........................................... 15

3.3.5. Evaluate the End-Item Delivery ...................................................................... 15

3.3.6. Product Assessments .................................................................................... 16

3.3.7. Process Assessments .................................................................................... 17

3.4. Roles and Responsibilities .................................................................................... 17

3.4.1. Quality Assurance Manager ........................................................................... 17

3.4.2. Quality Assurance Personnel ......................................................................... 17

4. Documentation ............................................................................................................. 18


6/62

4.1. Purpose ................................................................................................................ 18

4.2. Minimum Project Documentation .......................................................................... 18

5. Standards, Practices, Conventions, and Metrics .......................................................... 19

5.1. Purpose ................................................................................................................ 19

5.2. Software Quality Program ..................................................................................... 19

5.2.1. Standards, Practices, and Conventions ......................................................... 21

5.2.2. Metrics ........................................................................................................... 22

6. Software Reviews ........................................................................................................ 24

6.1. Purpose ................................................................................................................ 24

6.2. Minimum Software Reviews .................................................................................. 24

6.2.1. Software Specification Review (SSR) ............................................................ 24

6.2.2. Software Preliminary Design Review (PDR)................................................... 24

6.2.3. Software Critical Design Review (CDR) ......................................................... 25

6.2.4. Software Test Readiness Review (TRR) ........................................................ 25

6.2.5. Formal Qualification Review (FQR) ................................................................ 25

6.2.6. Production Readiness Review (PRR)............................................................. 25

6.2.7. Software Concept Review (SCR) ................................................................... 25

6.2.8. Acceptance Review (AR) ............................................................................... 25

6.2.9. Operational Readiness Review (ORR) ........................................................... 25

6.2.10. Peer Reviews ............................................................................................. 25

7. Software Testing .......................................................................................................... 26

8. Problem Reporting and Corrective Action .................................................................... 27

8.1. Internal Audit Report ............................................................................................. 27

8.2. Corrective Action Report ....................................................................................... 28

8.3. Preventive Action Report ...................................................................................... 28

8.4. Software Tool Evaluation Report ........................................................................... 29

8.5. Facilities Evaluation Report ................................................................................... 29

9. Tools, Techniques, and Methodologies ........................................................................ 29

9.1. Software Quality Tools .......................................................................................... 29


7/62

9.2. Project Tools ......................................................................................................... 29

9.3. Software Quality Techniques and Methodologies.................................................. 30

10. Media Control ........................................................................................................... 30

11. Supplier Control........................................................................................................ 31

12. Record Collection, Maintenance, and Retention ....................................................... 31

13. Training .................................................................................................................... 31

14. Risk Management .................................................................................................... 31

15. SQA Plan Change Procedure and History ................................................................ 32

Table of Appendices ........................................................................................................... 33

Appendix A List of Abbreviations and Acronyms ........................................................... 33

Appendix B Business Process / System Flowchart ....................................................... 34

Appendix C Sequence Diagrams .................................................................................. 37

Appendix D Test Procedures ........................................................................................ 42

Appendix E System Screenshots .................................................................................. 48

Appendix F Forms ........................................................................................................ 57


8/62

1. Purpose

The purpose of this Software Quality Assurance (SQA) Plan is to establish the goals,

processes, and responsibilities required to implement effective quality assurance functions

for the Watercooler project.

The Watercooler SQA Plan provides the framework necessary to ensure a consistent

approach to software quality assurance throughout the project life cycle. It defines the

approach that will be used by the Software Quality (SQ) personnel to monitor and assess

software development processes and products to provide objective insight into the maturity

and quality of the software. The systematic monitoring of Watercooler products, processes,

and services will be evaluated to ensure they meet requirements and comply with the

Watercooler Development Teams existing policies, standards, and procedures, as well as

applicable Institute of Electrical and Electronic Engineers (IEEE) standards.

1.1. Scope

This plan covers SQA activities throughout the lifecycle of the Watercooler project.

Watercooler offers a simple, easy-to-use and clutter-free interface. It will allow software

developers and other IT professionals to make use of tags to categorize topics. The usage of

tags will provide for easier searching of topics and will prevent the deep hierarchies ofcategories that usually add clutter to a forum. In addition, users will be allowed to follow any

tags they like. Users will be able to quickly check the threads that are most relevant to them

by following tags that interest them. Users will also be able to vote for or against any of the

posts. Post ratings will allow for the easy filtering of the most helpful answers.

This project will cover the registration, login/logout, creation of threads, post questions,

follow tags, post ratings. It will be created in PHP and MySQL which will run on Apache

server.

The team will use the Agile software development which will be based on iterative and

incremental development and where requirements and solutions will evolve through

collaboration between self-organizing, cross-functional teams.

SQA activities will be done in all iterations. The SQA Team will be testing the system/module

in all iterations to ensure quality of the system.


9/62

2. Reference Documents

IEEE Standard for Software Quality Assurance Plans. Software Engineering

Standards Committee , September 2002.

Reaves, Michael J. Software Quality Assurance and Software Verification and

Validation Plan for Web Accessible Alumni Database. Jacksonville State University,

2003.

Defense Finance And Accounting Service, Program Quality Assurance Plan, May

2002.

Tom, Mochal, Integration testing will show you how well your modules get along,

Sept. 2001.

Applying Broadcasting/Multicasting/Secured Communication in Multi-Agent Systems

Software Quality Assurance Plan, 2003

IEEE Guide for Software Quality Assurance Planning

IEEE Standard for Software Quality Assurance Planning, IEEE Std 730.1-1995

3. Management

3.1. Management Organization

Watercooler efforts are supported by numerous entities, organizations and personnel.

Relevant entities/roles that are of interest and applicable to this SQA Plan and the software

assurance effort are described at a high level below.

Software Quality Assurance is responsible for ensuring compliance with SQA requirements

as delineated in this Software Quality Assurance Plan. The SQA organization assures the

quality of deliverable software and its documentation, non-deliverable software, and the

engineering processes used to produce software.

This section describes the functional groups that influence and control software quality.

SQAProject

Manager

Database

Administrator

Business

Analyst

Lead DesignerWeb

Developers

Tester


10/62

3.1.1. The Watercooler Project Team

The Watercooler Project Team is responsible for the management of project objectives

within the guidelines and controls prescribed by the Watercooler Project Plan.

The Project Manager is responsible for the following:

Implementing the quality program in accordance with the SQA Policy

Identifying the SQA activities to be performed by SQA

Reviewing and approving the Watercooler SQAP

Identifying and funding an individual or group independent from the project to perform

the SQA functions

Resolving and following-up on any quality issues raised by SQA

Identifying and ensuring the quality factors to be implemented in the system andsoftware

Identifying, developing and maintaining planning documents such as the Program

Management Plan, SDP, SCMP, Test Plans, and this SQAP

The Business Analyst responsible for the following:

Reviewing and commenting on the Watercooler SQAP

Implementing the quality program in accordance with this SQAP

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)

Implementing the software engineering practices, processes, and procedures as

defined in the Watercooler SDP and other projects planning documents

The Software Designer and Developer are responsible for the following:




design and development

Identifying, implementing, and evaluating the quality factors to be implemented in the

software

Implementing the software design/development practices, processes, and

procedures as defined in the Watercooler SDP and other projects planningdocuments


11/62

3.1.2. The Assurance Management Team

The Assurance Management Team provides mission assurance support to the project team.

The Assurance Management Team is responsible for the following:




test

Verifying the quality factors are implemented in the system, specifically software

Implementing the software test practices, processes, and procedures as defined in

the Watercooler SDP and other projects planning documents

3.2. Resources

3.2.1. Facilities and Equipment

SQA will have access to the facilities and equipment as described in the Watercooler SDP.

SQA will have access to computer resources to perform SQA functions such as process and

product evaluations and audits.

3.2.2. Personnel

3.2.2.1. The Watercooler Project Team

The Watercooler Project Team is responsible for management of project objectives within

the guidelines and controls prescribed by the Watercooler Project Plan. The Project

Manager (PM) is specifically responsible for the success of the Watercooler Project,

including but not limited to cost, schedule, and quality.

The Development Team comprises of one Project Manager (PM), one Business Analyst and

Developers, each specializing in a particular web component. Following a web framework

methodology, tasks will be split according to its requirements.

The PM will also be responsible for implementing and reviewing the SQA Plan. The PM will

coordinate regularly with the independent Quality Assurance Team with regards to quality

audits made to the system and will discuss with the project team members if there are issues

or discrepancies encountered during the audit process.

The senior programmer will be in charge of all backend logical processes. The Database

Administrator will focus on database design and structure and will constantly coordinate with


12/62

the senior programmer. The Lead Web Designer will be in charge of the general appearance

of the system. The tester will be in charge of all tests during the development process.

The Business Analyst will ensure that the project scope is clear and complete will be

responsible for defining and documenting the scope as part of the requirements gatheringtask.

3.2.2.2. The Assurance Management Team

The Assurance Management Team provides mission assurance support to the project team.

The team is comprised of Quality Assurance Manager (QAM) and Quality Assurance

Personnel (QAP).

The Quality Assurance Manager assigned to the project is responsible for supporting the

Project Manager in ensuring the quality of the product. The QAM provides Project

Management with visibility into the processes being used by the software development

teams and the quality of the products being built. The QAM maintains a level of

independence from the project and the software developers. Risk escalation begins at the

project level, and extends to the Assurance Management Team.

In support of software quality assurance activities, the QAM has assigned Quality Assurance

Personnel to coordinate and conduct the Quality Assurance (QA) activities for the project

and identify and document noncompliance issues

Quality Assurance Personnel Responsibilities include, but are not limited to:

Prepare and manage the project software system quality assurance plan

Create and keep a schedule of software quality assurance conducted activities

Lead process and product assessments, as depicted within this plan, using objective

standards

Interface with Safety, Reliability, and IV&V personnel on software system assurance

activities

Discover and document non-compliances, observations, and risks from all software

assurance related activities to the Systems Assurance Manager

Communication of results from assessments with crucial stakeholders

Ascertain resolution of non-compliances and escalate any issues that cannot be

decided within the project

Discover lessons learned that could improve processes for future projects.

Prepare and manage metrics


13/62

3.3. SQA Tasks

This section discusses the SQA tasks performed by the SQ Personnel during the

development and maintenance of the Watercooler project. These tasks are selected in

accordance to planned and contractual deliverables, the Software Management Plan (SMP)

and the Project Schedule set by the Watercooler Project team.

3.3.1. Evaluate the Overall Development Environment

The Software Development Environment (SDE) must have the necessary tools and facilities

needed for the smooth development flow of the Watercooler project. The SDE must contain,

but is not limited to, the following components:

Integrated Development Environment (IDE) An application that will be used by the

developers throughout the development phase. The IDE must be installed andconfigured with the needed plugins and extensions to support software development

needs such as source code editing/debugging and build automation.

Version Control System A system that allows developers to collaborate and to keep

track of all files and file changes in the project. This allows the developer to work on

the same files and to avoid accidentally overriding important changes made by

another developer.

Issue Tracking System A system which manages and keeps a list of software

issues (additional software features, bugs, etc.) that are raised for the project. This

helps the developer see pending issues and which of them have a higher priority, in

which case the developer must attend to it first.

Set of Coding Standards and Best Practices Set of coding rules to be followed by the

developers to ensure uniform coding. Following these standards reduces time and effort in

code reviews, and also allows easier maintenance of the project.

3.3.2. Evaluate the Requirements Analysis Phase

One of the key assurance activities for any project is the expert evaluation and assessment

of the requirements. Incorrect, ambiguous, and incomplete requirements have been shown

to be the major cause of system failures and accidents. Getting the requirements right is not

easy, but it is vital to the success of the project.

Requirements Analysis involves gathering information about the customer's needs and

defining, in the clearest possible terms, the problem that the product is expected to solve.

This analysis includes understanding the customer's business context and constraints, the

functions the product must perform, the performance levels it must adhere to, and the


14/62

external systems it must be compatible with. Techniques used to obtain this understanding

include customer interviews, use cases, and "shopping lists" of software features. The

results of the analysis are typically captured in a formal requirements specification, which

serves as input to the next step.

Requirement for this project is to have a forum for IT Professionals where they can ask

questions in terms of programming. Users should be able to post questions, answer

questions, follow threads of their interest, and post ratings. They should be able to register,

login and edit their profile in Watercooler.

Several techniques such as interviews, questionnaires, client documents and scenarios will

be used to elicit requirements.

System Requirements Document (SRD) will be tested to confirm that a system possessing

the characteristics defined in the SRD satisfies the URD within the effectiveness envelope.

Operational Analysis is the usual technique for SRD validation.

It is confirmed that the candidate requirements can be satisfied within the target or approved

capability, cost, timescale and risk envelope by feedback from SRD and solution option

development.

3.3.3. Evaluate the Software Design and Development Process

Preliminary design and development 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 and development must be such that the

coding of the computer program can be accomplished by someone other than the original

designer.

SQA shall perform the following:

Ensure 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

Ensure that action items resulting from reviews of the design are resolved in

accordance with these standards and procedures


15/62

Evaluate the method used for tracking and documenting the development of a

software unit in order 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

Ensure that the method used for tracking and documenting the development of a

software unit is implemented and is kept current

The results of this task shall be documented using the Process Audit Form described in

Section 8 and provided to project management. SQAs recommendation for corrective

action requires project managements disposition and will be processed in accordance with

the Corrective Action Process.

3.3.4. Evaluate the Implementation and Testing Phase

In the implementation, integration and testing phases, the separate modules developed are

then combined, while ensuring these modules work together to achieve the set software

functionalities. Software testing is done starting from the functionalities of the individual

modules, then moving up to the interfaces in between them, assuring that these modules

work together to complete the expected software functionality.

It must be ensured that the software integration process, and testing activities or procedures

are being accomplished in accordance with established software standards and procedures,

and the software design. Also, it must be documented and ensured 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.

When fixes are made, it must be made sure that the software integration and unit testing

procedures are re-executed to validate the correctness of the changes made to the source

code, and to check for the existence of child bugs, if any.

3.3.5. Evaluate the End-Item Delivery

End-item deliverables will include the following:

Software Version Description (SVD) this document identifies and describes a

software version of Watercooler. It is used to release, track and control Watercooler

builds.

User Manual this is a technical communication document intended to assist users

into using Watercooler.


16/62

Media Distribution List this is a list containing the names and addresses of the

organizations to which the end-item deliverables are to be given.

The SQA Personnel must make sure that the SVD and User Manual documents are the

correct version for Watercooler. Also, the Media Distribution List must contain the completelist of organizations, along with their correct and current addresses, where the end-item is to

be delivered.

3.3.6. Product Assessments

Software Development Folders

A software development folder or file is a physical or virtual container for software project

artifacts, including: requirements, plans, designs, source code, test plans and results,

problem reports, reviews, notes, and other artifacts of the development process.

The software development folder check off list requires the checking of requirements,

functionality, source code, libraries/directory, development methodologies, test data, test

analysis. Requirements indicate that there is matches between the requirements trace ability

matrix and the requirements addressed by this module. With functionality, it checks if a

design walk-through was conducted and if it there was a permission to start the program.

Source code of the unit should be included in the folder as well as the libraries and

directories. Test Analysis is also included to verify that the unit has been thoroughly tested.

Software configuration management

Software configuration management (SCM) process is the best solution to handle changes

in software projects. It identifies the functional and physical attributes of software at various

points in time, and performs systematic control of changes to the identified attributes for the

purpose of maintaining software integrity and traceability throughout the software

development life cycle. Configuration management practices include revision control and the

establishment of baselines. CVS will be used for version control.

Requirements Traceability

Traceability is identified through the use of a spreadsheet matrix which will tie individual

Contract End Item (CEI) Specifications, applicable Interface Controlled Description (ICD)s

and Software Requirements Document entries to lower level design and test specification

paragraphs or sections. These Traceability products are produced and maintained by SQA.


17/62

SQA is included in review process for all software document generation. During these

reviews, checklists and Traceability spreadsheets are used to ensure that requirements are

met by both the design and test functions.

3.3.7. Process AssessmentsListed below are the process assessments that will be conducted by SQ personnel.

Project Planning

Project Monitoring and Control

Software Reviews

Requirements Management

Software Configuration Management and Configuration Audits (FCA/PCA)

Test Management (Verification & Validation) Software Problem Reporting and Corrective Action

Risk Management

3.4. Roles and Responsibilities

This section describes the roles and responsibilities for each assurance personnel assigned

as Quality Assurance Manager and Quality Assurance Personnel for the Watercooler Project.

3.4.1. Quality Assurance Manager

The Quality Assurance (QA) Manager is responsible for developing the QA Plan and for

measuring, assessing, and reporting quality performance against objectives.

3.4.2. Quality Assurance Personnel

Responsibilities include, but are not limited to:

Generate and maintain a schedule of quality assurance activities

Conduct process and product assessments

Interface with all personnel on quality assurance activities

Identify and document noncompliance

Communicate results from assessments with relevant stakeholders

Ensure resolution of noncompliance and escalate any issues that cannot be resolved

within the project

Identify lessons learned

Develop and maintain metrics


18/62

4. Documentation

4.1. Purpose

This section defines the required documentation for properly assessing the correctness of

the system. Essential documentations pertaining to requirements, development, verification,

validation and maintenance of the software that fall within the scope of this Software Quality

Plan shall be reviewed by the Software Quality Personnel.

4.2. Minimum Project Documentation

Project Plan. The Project Plan is the approved document that will be used as guide

for project execution and control. Scope, cost, resources, project milestones and

activities are all indicated in the Project Plan.

Configuration Management Plan. The Configuration Management Plans main

purpose is to maintain consistency in a software product by establishing change

control processes, identifying all aspects of configuration items and recording all

configuration baselines.

Risk Management Plan. The Risk Management Plan contains effective controls for

the identification and assessment of risks. The perceived risks, measures for

mitigation and treatment of risks, schedule for risk control implementation and the

responsible persons for these actions are all documented in the Risk Management

Plan.

Test Plan. The Test Plan includes the test strategies and test coverage that will be

carried out to ensure that the software meets its requirements. There are different

test plans depending on the types of test that will be carried out.

User Acceptance Test Plan. The User Acceptance Test Plan outlines the detailed

plan for user acceptance testing. This document will be used to record the clients

sign off of the documented scenarios.

System Training Plan. The Training Plan defines the support activities, schedules,curriculum, methods and tools, and equipment required for system training.

Software Maintenance Plan. The Software Maintenance Plan defines the support

environment, roles and responsibilities and scheduled activities to provide

maintenance personnel with information to effectively maintain the system.

Software Requirements Specifications. The Software Requirements Specifications

document contains the functional and non-functional requirements of the system. It

includes the complete description of the expected behaviour of the system.

Functional Specifications. The Function Specifications document details what the

finished product will do and how the user will interact with the system.


19/62

SQA Audit Checklist. The SQA Audit Checklist shall be used by the Quality

Assurance Team to verify the compliance of the Project Team with the project

processes and procedures.

Corrective Action Report. The Corrective Action Report comprises of any operation

or processing problems and the corrective actions taken to fix these problems.

Preventive Action Report. The Preventive Action Report details the actions done to

eliminate potential root causes of possible problems.

Software Users Manual. The Software Users Manual is a guide for usage of the

System. It contains details for doing certain functions using the system.

5. Standards, Practices, Conventions, and Metrics

5.1. Purpose

This section highlights the standards, practices, conventions, and metrics to be applied to

ensure a successful software quality program.

5.2. Software Quality Program

Software Quality Programs for the Watercooler project are governed by the policies

described in the ISO 9001:2008 standards. All software quality assurance staff members are

experienced in the ISO 9001:2008 standards and are applying generic and specific practicesfor Process and Product Quality Assurance (PPQA).

In accordance to ISO 9001:2008 standards, the process model for the Watercooler project

will involve continuous improvement by planning, implementing and monitoring project

aspects and repeatedly reviewing project procedures. The Watercooler project will focus on

the following four characteristics of Quality Management:


20/62

The Watercooler project will involve business planning, management planning, establishing

of parameters and procedures and training to ensure that the project will be in tune with the

focus of the projects quality program. In particular, involvement of the clients, the

management and staff will be important to the success of the implementation of the quality

program.

CustomerFocus

Quality

Culture

MeasurementAnalysis and

Improvement

ProcessImprovement


21/62

5.2.1. Standards, Practices, and Conventions

The following table lists all standards, practices, and conventions that will be used in

Watercooler project.

Standards /

Practices /

Conventions

Description Inspection Type

UML Notation The UML notation will be used for

design documents.

Document Inspection

Pseudocode Detailed Design documents will

follow the pseucode standard.

Document Inspection


22/62

Coding Standard Programs will have to follow the

coding standards. Different

programming languages will have

different coding standards.

Automated / Manual Code

Review

Unit Test Standard All programs will have to undergo

unit testing. Unit testing standards

will be documented and will have to

be followed.

Code Review

Usage of Wiki Practices, standards and pertinent

project information must be put in

the project wiki. All team members

must have access to the project

wiki.

Process Inspection

Bug Tracking Bugzilla will be used for Bug

Tracking.

Implementation Inspection

Best Practices for

Bug Reporting

All bug reports are expected to

have the following details:

Current behaviour of the

system

Expected behaviour of the

system

Screenshot

Replication Steps

Process Inspection

Email All members must follow the

standard for email communication.

Subject of the all email messages

must conform to the standard.

Process Inspection

Progress Reports The team must produce progress

reports at the end of each week.

Implementation Inspection

5.2.2. Metrics

The use of metrics provides an objective means of gauging whether the project is on track

with respect to its cost, scope, and quality of its product. Selection of the correct metrics and

monitoring them will aid in a more timely escalation and resolution of issues or misses, and

will prevent the team from reverting to fire-fighting as its means of addressing issues. The


23/62

fire-fighting approach is reactive, while the use of metrics to control and monitor the project

is a proactive approach well-intended to mitigate risks early on.

To establish the most appropriate quality metrics that will be used in the project, the

following activities will be performed by the Quality Assurance team:

The following standard metrics are the minimum planned metrics that will be collected,

reported, and maintained:

Project size (Planned vs Actual)

Development effort (Planned vs Actual)

Module completion rate (Planned vs Actual)

Code coverage of automated tests

Defect density

Number of defects categorized according to Priority, Severity

Number of defects categorized according to Type (Functional, User Interface,

Performance, Usability, etc.) Defect rejection rate

Defect removal rate

Defect leakage rate

Establish software quality requirements

Identify software quality metrics

implement software quality metrics

Analyze Results of metrics

Validate metrics


24/62

6. Software Reviews

6.1. Purpose

This section manages all software reviews that would be conducted by the SQA Team to

the system. The reviews would be mainly based from the Software Development Plan or

the Project Plan, which outlines the processes in the Systems Development Life Cycle, as

well as the scheduling, budget analysis, and other pertinent information that would prove

useful during the review process.

The software items produced during the software life cycle process should be reviewed and

audited on a planned basis to determine the extent of progress and to evaluate the technical

adequacy of the work and its conformance to software requirements standards. Technical

reviews and audits should be conducted to evaluate the status and quality of the software

development effort. This ensures that the elements completely and correctly embody its

baseline specification.

6.2. Minimum Software Reviews

For each review, the Software Quality Assurance will assess the review products to assure

that review packages are being developed according to the specified criteria and that the

review content is complete, accurate, and of sufficient detail, and that Requests for Action

are captured, reviewed, and tracked to closure. In addition, the Software Quality Assurancewill assess the processes used to conduct the reviews to determine if appropriate personnel

are in attendance, correct information is presented, entry and exit criteria are met, and

appropriate documents are identified for update.

The following software reviews may be assessed by the Software Quality Assurance:

6.2.1. Software Specification Review (SSR)

The objective of the Software Specification Review (SSR) is to review the finalized Computer

Software Configuration Item requirements and operational concept. A successful SSR

shows that the SRS, IRS, and Operational Concept Document form a satisfactory basis for

proceeding into preliminary software design.

6.2.2. Software Preliminary Design Review (PDR)

The objective of the Software Preliminary Design Review (PDR) 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.


25/62

6.2.3. Software Critical Design Review (CDR)

The objective of the Software Critical Design Review (CDR) 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.2.4. Software Test Readiness Review (TRR)

The objective of the Software Test Readiness Review (TRR) is to determine whether the

software test procedures are complete and to assure that the developer is prepared for

formal Computer Software Configuration Item testing.

6.2.5. Formal Qualification Review (FQR)

The Formal Qualification Review (FQR) is 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.

6.2.6. Production Readiness Review (PRR)

The objective of the Production Readiness Review (PRR) is to determine the status of

completion of the specific actions which must be satisfactorily accomplished prior to

executing a production go-ahead decision.

6.2.7. Software Concept Review (SCR)

The Software Concept Review (SCR) is a buyer control gate which reviews and approvesthe recommended system concept configured to satisfy the system requirements document.

The SCR is the decision point to proceed with the development of the system specification.

6.2.8. Acceptance Review (AR)

The Acceptance Review (AR) is the specification compliance control gate or check point at

which adherence to expectations of the service or deliverables is verified. This may be

performed at any level of the system or process.

6.2.9. Operational Readiness Review (ORR)

The Operational Readiness Review (ORR) examines the actual system characteristics and

the procedures used in the system or end products operation and ensure that all system

and support hardware, software, personnel, procedures, and user documentation accurately

reflect the deployed state of the system.

6.2.10. Peer Reviews

A Peer Review is a review of a colleaguess work by another with similar knowledge or

experience in the same or a closely related field. This is a review of products or services,


26/62

following defined procedures, by peers for the purpose of identifying deficiencies and

improvements.

7. Software TestingThe testing activity for the Watercooler project will be divided into three parts, namely:

Unit-level testing This is to be done by the software developer in order to ensure

that his/her assigned module meets its design and runs as intended

Integration testing This is handled by the assigned software tester so that it is

assured that the software application meets the design expected when the individual

project modules are combined and tested in groups.

Performance testing This is also handled by the assigned software tester for him to

see if the application runs at an acceptable speed, and does not consume too much

system resources.

User acceptance testing (UAT) This is the part where the end users themselves will

be able to test the software application. This can be further divided into two parts,

namely:

o Alpha Testing tests are conducted in a test environment slightly controlled

by the development team

o Beta Testing tests are conducted in an uncontrolled test environmentThe general testing process flow diagram is shown below:


27/62

The SQ personnel will assure that the testing activity is implemented in accordance to the

Software Management Plan and/or Software Test Plan. They will also be monitoring the

testing efforts required to make sure that testing activity still follows the schedule. They will

assure that all constraints, assumptions made during the testing process, and the test results

are recorded accurately.

Lastly, they will review post-test documents such as test reports, test results, etc.

8. Problem Reporting and Corrective Action

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 Internal Audit Report, Corrective Action Report, Preventive Action

Report, Software Tool Evaluation Report, Facilities Evaluation Report, and monthly SQA

Status Report. Each of these forms and their uses are discussed in the following paragraph.

8.1. Internal Audit Report

The following are the pertinent information that should be included in the internal audit report:

Classification of findings. Impact on the quality of service, business risks and

impact on the integrity of the QMS must be considered when classifying all problems

found during the SQA activity. The following are the classifications that must be used:

o Minor - an isolated observed lapse in the fulfilment of a specified requirement

that has no significant impact on the achievement of customer satisfaction.

o Major - absence or total breakdown of the system to meet a specified

requirement of a clause of ISO 9001:2008, or other reference document

including regulatory requirements, causing significant business risk.

o Observation - activities that are moving towards a non-conformance; and

activities if addressed, would improve the present practices.

Non-conformances must be:

o Factual and objective.

o Give the clause of ISO 9001:2008

o Agreed with the Auditee

Formulation of corrective and preventive actions.

o Corrective actions - are actions taken to eliminate the root cause of an

existing non-conformity, or other undesirable condition to prevent recurrence.

o Preventive actions - are actions taken to eliminate the root cause of a

potential non-conformity or other undesirable condition to prevent itsoccurrence.


28/62

o Corrective and preventive actions must:

Address the non-conformance.

Address the root causes.

Be timely - with practical and realistic time frames for implementation.

Be monitored to assess their effectiveness.

(Please check Form-001: Internal Audit Report located in Appendix F.)

8.2. Corrective Action Report

The objective of a Corrective Action Report is to ensure all non-conformances identified

during the implementation of the management system are analyzed and actions formulated

to eliminate their root causes. This is to prevent recurrence. This covers formulation and

implementation of corrective actions for all types of non-conformances identified.

In the Corrective Action Report, all non-conformances should be identified during each

process in operations and details should be recorded. Non-conformances may be from the

voice of the customer (customer feedback) or voice of the system. Root causes of the non-

conformance should be analyzed and identified and result of analysis should be recorded in

the Corrective Action Report. The after, formulate and recommend actions to be taken.

Ensure time frames and responsibilities for actions are clearly defined.

The corrective action is considered effective if after one (1) month implementation and the

nonconformance did not recur.

The assigned person should monitor implementation of the recommended actions following

defined time frames. Identify interfaces with other processes of the management system and

determine effects. If actions taken are effective (the same problem did not recur), formalize

the changes.

(Please check Form-002: Corrective Action Report located in Appendix F.)

8.3. Preventive Action Report

The objective of a Preventive Action Report is to ensure all potential conformances and

improvements identified during the implementation of the management system are analyzed

and actions formulated to eliminate their root causes. This is to prevent occurrence. This

procedure covers formulation and implementation of preventive actions for all types of

potential non-conformances and improvements identified.

In the Preventive Action Report, all potential non-conformances and/or improvements during

each process should be identified and details should be recorded. Suggestions for

improvements are encouraged from all employees. Improvement suggestions should be


29/62

justified in terms of costs involved and benefits to be derived. Root Causes of the potential

non-conformance should be analyze and identified. Results of the analysis should be

recorded in the Preventive Action Report. Then after, formulate and recommend actions.

Ensure time frames and responsibilities for actions are clearly defined. The report assists in

monitoring implementation of the recommended actions following defined time frames.

Identify interfaces with other processes of the management system and determine effects. If

actions taken are effective (the same problem did not recur), evaluate.

(Please check Form-003: Preventive Action Report located in Appendix F.)

8.4. Software Tool Evaluation Report

The Software Tool Evaluation Report provides the format for evaluating software tools.

(Please check Form-004: Software Tool Evaluation Report located in Appendix F.)

8.5. Facilities Evaluation Report

The Facilities Evaluation Report provides the format for evaluating existing and planned

Watercooler facilities.

(Please check Form-005: Facilities Evaluation Report located in Appendix F.)

9. Tools, Techniques, and Methodologies

9.1. Software Quality Tools

Listed below are the SQA tools used during the development of the Watercooler project:

Microsoft Office applications these will be used in creating the SQA documents

throughout the project

BugZilla - a Web-based general-purpose bugtracker and testing tool. This will be

used by the Watercooler project for tracking bugs/requests during development and

testing phase.

PHPUnit a unit-testing framework (based on Javas JUnit framework) used for PhP

applications. This can be intergrated to the IDE as an external tool.

9.2. Project Tools

The development team used Eclipse for PhP developers to be the IDE for the Watercooler

project. The IDE allows for faster development by providing the common needed tools that

maximizes the developers productivity, such as a good source code editor and a debugger.

Also, the IDE is configured so that the following will be integrated as well:


30/62

Concurrent Versioning System (CVS)

Apache Server

9.3. Software Quality Techniques and Methodologies

Every SQA meeting scheduled must include all members of the SQA team. If a member is

not able to attend the meeting, he/she must be notified by the QAM on what happened

during the course of the meeting.

Any enhancements or defects raised must be analyzed by the SQA team. The team must be

able to assign a priority level to the said enhancement or fix depending on its complexity and

the impact on the system.

The development team must always be aware of the priorities of the issues raised. All

high/critical priority issues must be addressed first.

After a defect has been fixed or an enhancement has been added, the development team

must notify the QAM at the next SQA review, in which case the changes will be noted.

If a bug has been fixed or a change has been made, the software tester must re-execute the

testing process to verify the correctness of the fix/change and to make sure no child bug has

been created in the process.

10. Media Control

Media control includes:

regularly scheduled backup of the media

labelled 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

adequate protection from unauthorized accessThe software media control methods and facilities are described in the Watercooler SCMP.

SQA will conduct ongoing evaluations of the software media control process to ensure that

the process of controlling the software media is effective and in compliance with the

Watercooler SCMP.


31/62

11. Supplier Control

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/vendor to describe then technical support, handling of user questions and

problems, and software product upgrades.

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

software is planned.

12. Record Collection, Maintenance, and Retention

SQ personnel will be in charge of the collection, maintenance and organization of alldocument assessments done during and after the project. Document records include

process/product assessment reports, preventive/correction action reports, the SQ Activity

Schedule, progress reports, etc. Keeping these records provides traceability of assessments

performed during and after the projects development.

13. Training

Software Quality personnel shall have fundamental knowledge in the following

areas/disciplines through prior experience, training, or certification in methodologies,

processes, and standards.

Software Quality Assurance

Audits and Reviews

Risk Management

Configuration Management

ISO 9001:2008

Appropriate training has been provided to the Quality Assurance Management team. It is,

however, the responsibility of the Quality Assurance Management team to keep their

knowledge up-to-date during the period when there are no available trainings.

14. Risk Management

Risk management is the identification, assessment, and prioritization of risks followed by

coordinated and economical application of resources to minimize, monitor, and control the

probability and/or impact of unfortunate events or to maximize the realization of opportunities.
http://en.wikipedia.org/wiki/Riskhttp://en.wikipedia.org/wiki/Risk


32/62

The strategies to manage risk include transferring the risk to another party, avoiding the risk,

reducing the negative effect of the risk, and accepting some or all of the consequences of a

particular risk.

Risk management includes the following activities:

Planning how risk will be managed in the particular project. Plan should include risk

management tasks, responsibilities, activities and budget.

Assigning a risk officer - a team member other than a project manager who is

responsible for foreseeing potential project problems.

Maintaining live project risk database. Each risk should have the following attributes:

opening date, title, short description, probability and importance. Optionally a risk

may have an assigned person responsible for its resolution and a date by which the

risk must be resolved.

Creating anonymous risk reporting channel. Each team member should have

possibility to report risk that he/she foresees in the project.

Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of

the mitigation plan is to describe how this particular risk will be handled what, when,

by who and how will it be done to avoid it or minimize consequences if it becomes a

liability

Summarizing planned and faced risks, effectiveness of mitigation activities, and effortspent for the risk management.

15. SQA Plan Change Procedure and History

SQ personnel will be in charge of the maintenance of this SQA plan. Changes in SQ

activities and other related processes must reflect on this plan. Also, the Record of Changes

must be updated upon applying these changes. Proposed changes shall be submitted to the

QAM along with supportive material justifying the proposed change.


33/62

Table of Appendices

Appendix A List of Abbreviations and Acronyms

Abbreviation/

Acronym

DEFINITION

AR Acceptance ReviewCEI Contract End ItemCDR Critical Design ReviewCVS Concurrent Versioning SystemFQR Formal Qualification ReviewICD Interface Controlled DescriptionIDE Integrated Development EnvironmentIRS Interface Requirements SpecificationISO International Organization for StandardizationORR Operational Readiness Review

PDR Preliminary Design ReviewPM Project ManagerPPQA Process and Product Quality AssurancePRR Production Readiness ReviewQA Quality Assurance

QAM Quality Assurance ManagerQAP Quality Assurance PersonnelSCM Software Configurations Management

SCMP Software Configurations Management PlanSCR Software Concept ReviewSDP Software Development PlanSQA Software Quality Assurance

SQAP Software Quality Assurance PlanSRD System Requirements DocumentSRS Software Requirements SpecificationSSR Software Specification ReviewSVD Software Version DescriptionTRR Test Readiness ReviewUAT User Acceptance Testing


34/62

Appendix B Business Process / System Flowchart


35/62


36/62


37/62


38/62


39/62


40/62


41/62


42/62

Appendix D Test Procedures

Test Scenario: Verify system registration of new user

Test Case Definition: This test case verifies that the system registration allows for thecreation of new Watercooler users with access to the system.

Preconditions: Nil

Step Action Expected Results1. Click on the Loginlink. The System Login page must be

displayed. To the right, link and buttonfor sign-up/registration must bedisplayed.

2. Click on the Registerbutton. The Watercooler Sign Up page must bedisplayed.

3. Fill up the registration form, specifying

an unregistered Email. Click on theSign Upbutton.

The Acknowledgement page must be

displayed indicating a successfulregistration.

An email must be sent to the registeredemail address with an activation linkprovided.

4. In the registration confirmation email,click on the provided activation link.

The account is activated, and the useris automatically logged in toWatercooler.

Name of the logged in user must bedisplayed in the header.

Upon log in, the Followed Threadspage must be displayed.

Test Scenario: Verify profile update of existing user

Test Case Definition: This test case verifies that the system allows the registered user to

modify his/her account details.

Preconditions: User is logged in.

Step Action Expected Results1. Click on the header link with the users

name.

The User Profile > Info page must be

displayed with details shown as read-only.

2. Click on the Change Passwordlink. The Change Password page must bedisplayed with editable fields.

3. Enter the old and new passwords. Entered values must be masked. Copyor paste to and from the passwordfields must not be allowed.

4. Click on the Submitbutton. Password change must be stored intothe database in encrypted (not plaintext) format.

5. Click on the Edit Profilelink. The Edit Profile page must be displayedwith editable fields.


43/62

6. Modify the details displayed, specifyingvalues for all provided fields, then clickon the Submitbutton.

Changes to the fields must be storedinto the database.

Returning to the User Profile > Infopage must display the values asentered in the Edit Profile page.

7. Click on the Contact Settingslink. The Contact Settings page must bedisplayed with editable checkboxes.

8. Modify the details displayed such thatthere are some items checked andsome that are unchecked. Click on theSubmitbutton.

Changes to the fields must be storedinto the database.

9. Log out of Watercooler. The System Login page must bedisplayed.

10. Attempt to login using the originalpassword.

System error must be displayed sayinginvalid email or password has beenprovided.

11. Search for the Watercooler account toview the profile.

Displayed details must be according towhat was specified in the ContactSettings page.

Fields with the correspondingcheckbox marked must bedisplayed.

Fields with the correspondingcheckbox unmarked must behidden.

12. Attempt to login using the newpassword.

User must be successfully logged in tothe system.

Test Scenario: Verify creation of new threads and tags

Test Case Definition: This test case verifies that the registered user can create new

threads and tags.

Preconditions: User is logged in.

Step Action Expected Results1. Click on the Ask Now!link from the

header.The Ask Question page must bedisplayed.

2. Enter the Title, Messageand Tags,then click on the Submitbutton.

The page must refresh such that thecreated thread is displayed.

The Vote Up/Down icons must bedisabled for threads created by thelogged in user.

3. View the user profile, and go to theCreated Threadstab.

The thread created in the previous stepmust be included in the list.

4. Click on the Tagslink from the header. The tags used in the created threadmust be included in the list, under thecorresponding letter of the tags initialletter.


44/62

Test Scenario: Verify posting of a reply to forum threads

Test Case Definition: This test case verifies that the registered user can reply to existing

forum threads.

Preconditions:

- User is logged in.

- There must be forum threads already created.

Step Action Expected Results1. Click on the Forumlink from the

header.The Forum page must be displayedwith the threads sorted according to theDate Posted with the newest threaddisplayed first.

2. Click on the titleof one of the threads. The Thread page must be displayedwith the selected thread displayed.

3. Input values into the Post Replymemobox, then click on the Replybutton.

The page must be refreshed with theadded reply displayed as read-only.

4. Click on the Forumlink to return to the

Forum page.

The corresponding number of replies

for the selected thread must incrementby 1.

5. Click on the titlelink of the previouslyselected thread.

The Thread page must be displayedwith the selected thread displayed.

6. Click on the Quotelink of the thread orof any existing reply.

The page must be refreshed with thePost Replymemo box containing thequoted post.

7. Click on the Replybutton. The corresponding number of repliesfor the selected thread must incrementby 1.

Test Scenario: Verify voting up/down of an existing threadTest Case Definition: This test case verifies that the registered user can vote up/down an

existing thread.

Preconditions:


- There must be forum threads already created by another user.

Step Action Expected Results1. Click on the Forumlink from the



3. Click on the Vote Upicon. The voting icons must then be disabled.The Ratingvalue must then be updatedwith the recalculated value.

The Ratingvalue is the percentage ofvote ups over the total number of votes.

4. Click on the Forumlink to return to theForum page.

The corresponding rating of theselected thread must show the newlyrecalculated value.


45/62

Test Scenario: Verify flagging of forum posts

Test Case Definition: This test case verifies that the registered user can flag an existing

thread, and that the admin user can unflag or delete the flagged post.

Preconditions:


- There must be forum threads already created with replies.

Step Action Expected Results1. Login as a non-Admin user. Upon successful login, the Followed

Threads page must be displayed.2. Click on the Forumlink from the



4. Click on the Flaglink for the initial post. Upon confirming the action, the page

must be refreshed. A red flagged iconmust be displayed to indicate that thethread has been flagged.

An email notification containing a link tothe thread must then be sent to theAdmin user.

5. Click on the Forumlink to return to theForum page.

The flagged thread must then have ared flagged icon displayed.

6. Click on the titleof one of the threadsthat already have replies.

The Thread page must be displayedwith the selected thread displayed.

7. Click on the Flaglink for one of the

replies.

Upon confirming the action, the page

must be refreshed. A red flagged iconmust be displayed corresponding to theflagged reply.

An email notification containing a link tothe thread must then be sent to theAdmin user.

8. Log out from the system, then log in asan Admin user.

Upon successful login, the FollowedThreads page must be displayed.

9. Open email client to retrieve the emailnotifications. In one of the email

notifications for flagged posts, click onthe provided link.

The thread that had been flagged orcontaining a reply that had been

flagged must be displayed.

10. Click on the Unflaglink. The corresponding reply or threadbecomes unflagged.

11. Click on the Deletelink. The corresponding reply or thread mustthen be deleted.


46/62

Test Scenario: Verify user moderation by Admin user

Test Case Definition: This test case verifies that the Admin user can view the list of users,

and disable user accounts.

Preconditions: Nil

Step Action Expected Results

1. Log in as an Admin user. Upon successful login, the FollowedThreads page must be displayed.

For Admin users, there must be anothertab labelled Manage Accounts.

2. Click on the Manage Accountstab. The list of registered non-Admin usersmust be listed in the page.

3. For one of the existing user accountlisted, click on the Promotelink.

Upon confirmation, the page must berefreshed and the promoted user mustnot be in the list anymore.

4. Click on the Moderatorslink. The list of registered users with Admin

rights must be listed in the page.

The promoted user from the previousstep must be displayed in this list.

5. Click on the Userslink. The list of registered non-Admin usersmust be listed in the page.

6. Click on the Disablelink. Upon confirmation, the page must berefreshed. Instead of Disable, theremust be an Enable link displayed.

7. Log out of Watercooler. The System Login page must bedisplayed.

Test Scenario: Verify failed login of disabled accounts.

Test Case Definition: This test case verifies that a registered user that has been disabled

will not be allowed to log in to Watercooler.

Preconditions:

- User account that is disabled.

- Another user account that is still enabled.

Step Action Expected Results1. Log in using a disabled account. An error message must be displayed

indicating failed login.2. Log in using an enabled account. User must be successfully logged in.

By default, the Followed Threads pagemust be displayed.

Test Scenario: Verify following/unfollowing of threads/tags

Test Case Definition: This test case verifies that the registered user can perform the

following:

- Follow/unfollow an existing tag

- View followed threads

- View threads under an existing tag

Preconditions:

- User is logged in.- There must be forum threads already created.


47/62

Step Action Expected Results1. Click on the Tagslink from the header. The Tags page must be displayed with

the index at A by default.

Tags beginning with the letter A mustbe displayed.

2. Click on one of the index links. The page must be refreshed with thetags beginning with the selected indexdisplayed.

3. Click on the followlink beside a tag. The page must be refreshed. The tagmust then be displayed with an unfollowlink beside it.

4. Go to the User Profile > Users Tagspage.

The followed tag must be included inthe list of tags displayed.

The followed tag must also bedisplayed in the right-hand side under

the Followed Tagsheading.5. Go to the User Profile > Followed

Threads page.Forum threads having tags that theregistered user follows must bedisplayed.

6. Click on the Forumlink. The Forum page must be displayed.7. Click on one of the tag buttons. The Forum page must be refreshed

with the threads having the selected tagdisplayed.


48/62

Appendix E System Screenshots

Figure 1 - System Registration

Figure 2 - System Registration Acknowledgement

Figure 3 Activation of Account


49/62

Figure 4 - Terms of Service


50/62

Figure 5 - System Login Page

Figure 6 - User Profile Page


51/62

Figure 7 - Edit User Profile Page

Figure 8 - Change Contact Settings Page


52/62

Figure 9 - Change Password Page

Figure 10 - Followed Threads Page


53/62

Figure 11 - Followed Tags Page


54/62

Figure 12 - Forums Page


55/62

Figure 13 - Create Topic Page

Figure 14 - View Topic Page


56/62

Figure 15 - Manage Accounts

Figure 16 - Delete / Lock Threads


57/62

Appendix F Forms

This page was intentionally left blank.


58/62

FORM-001: INTERNAL AUDIT REPORT

Audit Date(s): IAR No.

Process:Department:

Details of Non-Conformance: Classification:

Major

Minor

Observation

ISO Clause:

Audited by: Date:

Noted by: Date:

Analysis of root causes:

Corrective Action:

References:

Target Close-Out Date:

Prepared by: Date:

Approved by: Date:

Preventive Action :

References:

Target Close-Out Date:

Prepared by: Date:

Approved by: Date:

Follow-up required? No Yes Date:

Follow-up Conducted by: Date:

Remarks:

Reviewed and confirmed effective by:

Remarks:

Close-Out Date:


59/62

FORM-002: CORRECTIVE ACTION REPORT

CAR No. : __________________

PROCESS: DEPARTMENT/SECTION:

DETAILS OF NON-CONFORMANCE:

REFERENCES:

REPORTED BY: DATE:

INVESTIGATION RESULTS/ROOT CAUSE ANALYSIS:

CONDUCTED BY: DATE:

CORRECTIVE ACTIONS: RESPONSIBILITY TIMEFRAME

Target Date for evaluation ofeffectiveness:

PREPARED BY: DATE:APPROVED BY: DATE:CONFIRMED EFFECTIVE BY: DATE:REMARKS:


60/62

FORM-003: PREVENTIVE ACTION REPORT

PAR No. : ______________

PROCESS: DEPARTMENT:

DETAILS OF POTENTIAL NON-CONFORMANCE/SUGGESTION:

REFERENCES/JUSTIFICATIONS:

REPORTED BY: DATE:

INVESTIGATION RESULTS/ROOT CAUSE ANALYSIS:

CONDUCTED BY: DATE:

PREVENTIVE ACTIONS: RESPONSIBILITY TIMEFRAME

Target Date for evaluation ofeffectiveness:

PREPARED BY: DATE:APPROVED BY: DATE:CONFIRMED EFFECTIVE BY: DATE:REMARKS:


61/62

FORM-004: SOFTWARE TOOL EVALUATION REPORT

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


62/62

FORM-005: FACILITIES EVALUATION REPORT

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

Date post:	09-Apr-2018
Category:	Documents
Upload:	bububear01
View:	224 times
Download:	0 times