CBT

Project Name
Software Quality Assurance Plan

Version 1.0

June 11, 2018

Page 1
 CBT

Version History
Doc. Approved Approval
Date Change Description Modified By
Version By Date

11-June-2018 Draft 1.0  Document Saim Pervaiz

Created

Page 2
 CBT

Contents
Chapter 1: Document Information ............................................................................................................... 5
1.1 Scope: .................................................................................................................................................. 5
1.2 Purpose: .............................................................................................................................................. 5
1.3 System Overview................................................................................................................................. 5
1.4 Reference Document .......................................................................................................................... 6
1.5 Glossary and acronyms ....................................................................................................................... 6
Chapter 2: Structure and Management ........................................................................................................ 9
2.1 Structure ............................................................................................................................................. 9
2.2 Responsibilities ................................................................................................................................. 10
2.2.1 Product Owner ........................................................................................................................... 10
2.2.2 Scrum Master ............................................................................................................................. 10
2.2.3 Solution Architect ...................................................................................................................... 10
2.2.4 QA............................................................................................................................................... 10
2.2.5 Team Members (Developers, QA, DBA) ..................................................................................... 11
2.2.6 Program Manager ...................................................................................................................... 11
2.3 Software Project Management ......................................................................................................... 11
2.3.1 Project Initiation ........................................................................................................................ 11
2.3.2 Project Planning ......................................................................................................................... 12
2.3.1 Project Implementation ............................................................................................................. 13
2.3.1 Project Closing............................................................................................................................ 14
2.4 Story Points and Time Estimation ..................................................................................................... 14
Chapter 3: Standards and Conventions ...................................................................................................... 16
3.1 Documentation ................................................................................................................................. 16
3.2 Development..................................................................................................................................... 16
3.2.1 Development tools and Framework .......................................................................................... 16
3.2.2 Directory Structure .................................................................................................................... 16
3.2.3 PHP File Formatting ................................................................................................................... 17
3.2.4 Class Names ............................................................................................................................... 17
3.2.5 Method Names .......................................................................................................................... 18
3.2.6 Variable Names .......................................................................................................................... 18
3.2.7 Constants ................................................................................................................................... 19

Page 3
 CBT

3.2.8 Arrays ......................................................................................................................................... 19

3.2.9 Inline Documentation - Files ...................................................................................................... 19
3.3 Quality Assurance & Testing ............................................................................................................. 20
3.4 Database ........................................................................................................................................... 20
3.4.1 Tables ......................................................................................................................................... 21
3.4.2 Data entry .................................................................................................................................. 22
3.4.3 Views .......................................................................................................................................... 23
3.4.4 Index names ............................................................................................................................... 23
3.4.5 SQL ............................................................................................................................................. 23
3.4.6 PL/SQL ........................................................................................................................................ 24
Chapter 4: SQA Tasks & Metrics ................................................................................................................. 26
4.1 Task: Review Software Products ................................................................................................ 27
4.2 Task: Evaluate Software Tools ................................................................................................... 28
4.3 Task: Evaluate Software Products Review Process .................................................................... 29
4.4 Task: Evaluate Project Planning, Tracking and Oversight Processes ......................................... 31
4.5 Task: Evaluate System Requirements Analysis Process ............................................................. 33
4.6 Task: Evaluate Software Design Process .................................................................................... 34
4.7 Task: Evaluate Software Implementation, Unit and Component Testing Process .................... 36
4.8 Task: Evaluate System Qualification Testing Processes ............................................................. 37
4.9 Task: Evaluate the Corrective Action Process ............................................................................ 39
4.10 Task: Evaluate Deviations and Waivers...................................................................................... 40
4.11 Task: Evaluate Configuration Management Process ................................................................. 41

Page 4
 CBT

Chapter 1: Document Information

1.1 Scope:
This plan establishes the SQA activities to be performed throughout the life cycle of software
development of Project X. The document provides:

 A software life cycle perspective for the minimum required software assurance procedures that
contribute to quality software
 Basic procedures for establishing, operating and maintaining a software assurance program in
house or contracted
 Specific requirements for the umbrella process of software assurance and its disciplines of
software quality, software reliability, software safety, software verification and validation
 A common framework for consistent practices across ES projects

In this Standard the words ‘assure’ and ‘ensure’ have the following usages:

a) Assure is used when software assurance practitioners make certain that the specified software
assurance, management and engineering activities have been performed by others
b) Ensure is used when software assurance practitioners themselves perform the specified
software activities

The goal of the SQA is to verify that all software and documentation to be delivered meet all technical
requirements. The SQA procedures defined herein shall be used to examine all deliverable software and
documentation to determine compliance with technical and performance requirements.

1.2 Purpose:
The purpose of this plan is to define the Software Quality Assurance Plan (SQAP) for Nayatel- ES, SQA
tasks and responsibilities; provide reference documents and guidelines to perform the SQA activities;
provide the standards, practices and conventions used in carrying out SQA activities; and provide the
tools, techniques, and methodologies to support SQA activities, and SQA reporting.

• Establish a common framework, including generic quality procedures, for the software assurance
process in support of all life cycle processes, regardless of who performs them

• Establish and support the cooperation of various groups who are conducting different aspects of the
total software assurance process

• Define software assurance activities and tasks to meet the objectives of software assurance

1.3 System Overview

Figure below identifies the Configuration Items within each subsystem and highlights those to which this
SQA Plan applies.

Page 5
 CBT

SOFTWARE LIFECYCLE ACTIVITY

Project Planning and Oversight
Software Development Environment
System Requirements Analysis
System Design
Software Requirements Analysis
Software Design
Software Implementation and Unit Testing
Unit Integration and Testing
CI Qualification Testing
System Qualification Testing
Software Use Preparation
Software Transition Preparation

Life Cycle Maintenance

1.4 Reference Document

This document identifies the organizations and procedures to be used to perform activities related to
the [[Project Name]] SQA program as specified in IEEE STD 730-1998, IEEE Standard for Software Quality
Assurance Plans, reference and IEEE STD 730.1-1995, IEEE Guide for SQA Planning.

 IEEE 730-2002 IEEE Standard for Software Quality Assurance Plans

 ISO 9126-1: 2001 Software Engineering Product Quality Part 1: Quality Model
 ISO/IEC 12207:1995 Software life cycle processes
 ISO 9001: 2000 Quality systems –Model for quality assurance in design, development,
production, installation, and servicing
 ISO 90003:2000 Quality Management And Quality Assurance Standards - Part 3:
 Guidelines For The Application Of ANSI/ISO/ASQC 9001:1994
 To The Development, Supply, Installation And Maintenance Of Computer Software
 IEEE 610.12 IEEE Standard Glossary of Software Engineering Terminology

1.5 Glossary and acronyms

Audit An examination of a work product or set of work products performed by a group
independent from the developers to assess compliance with specifications,
standards, contractual agreements, or other criteria. [Based on IEEE 610.12,IEEE
Standard Glossary of Software Engineering Terminology].
Peer A review of a software work product, following defined procedures, by peers of the
Review producers of the product for the purpose of identifying defects and improvements. [SEI-
CMM Software Engineering Institute Capability Maturity Model ®].
Process A set of interrelated activities, which transform inputs into outputs.
[ISO/IEC 12207, Software life cycle processes]

Page 6
 CBT

Process Activities to assure that all processes involved with the project adhere to plans and
Assurance comply with the contract and/or any memorandum of agreement/understanding.
Product Activities to assure that all required plans are documented, and that the plans, software
Assurance products, and related documentation adhere to plans and comply with the contract
and/or any memorandum of agreement/understanding.
Review A process or meeting during which a software product or related documentation is
presented to project personnel, customers, managers, software assurance personnel,
users or user representatives, or other interested parties for comment or approval.
[IEEE 610.12, IEEE Standard Glossary of Software Engineering Terminology] Reviews
include, but are not limited to, requirements review, design review, code review and
test readiness review. Other types may include peer review and formal review.
Software The planned and systematic set of activities that ensure that software life cycle
Assurance processes and products conform to requirements, standards, and procedures. [IEEE
610.12, IEEE Standard Glossary of Software Engineering Terminology].
Software A record that provides objective evidence of the extent of the fulfillment of the
Assurance requirements for software quality, safety, reliability, verification and validation, and,
Record when present, IV&V. This includes documentation of the software assurance activities
and analyses results.
Software The period of time that begins when a software product is conceived and ends when
Lifecycle the software is no longer available for use. The software life cycle typically includes a
concept phase, requirements phase, design phase, implementation phase, test phase,
installation and checkout phase, operation and maintenance phase, and sometimes,
retirement phase. [IEEE 610.12, IEEE Standard Glossary of Software Engineering
Terminology]
Software A measure of software that combines the characteristics of low defect rates and high
Product user satisfaction.
Quality
Software The discipline of software quality is a planned and systematic set of activities to ensure
Quality quality is built into the software. It consists of software quality assurance, software
quality control, and software quality engineering. As an attribute, software quality is (1)
the degree to which a system, component, or process meets specified requirements; or
(2) the degree to which a system, component, or process meets customer or user needs
or expectations. [IEEE 610.12, IEEE Standard Glossary of Software Engineering
Terminology]
Software The function of software quality that assures that the standards, processes, and
Quality procedures are appropriate for the project and are correctly implemented.
Assurance
Software The function of software quality that checks that the project follows its standards,
Quality processes, and procedures, and that the project produces the required internal and
Control external (deliverable) products.
Software Metrics are quantitative values that measure the quality of software or the processes
Quality used to develop the software, or some attribute of the software related to the quality
Metrics (e.g., defect density).
Validation Validation Confirmation by examination and provision of objective evidence that the
particular requirements for a specific intended use are fulfilled. [ISO/IEC 12207,
Software life cycle processes] In other words, validation ensures that “you built the right
thing.”

Page 7
 CBT

Verification Confirmation by examination and provision of objective evidence that specified

requirements have been fulfilled. [ISO/IEC 12207, Software life cycle processes] In other
words, verification ensures that “you built it right.”
SDP Software Development Plan
PMP Project Management Plan

Page 8
 CBT

Chapter 2: Structure and Management

In describing the functional responsibilities, answers to these questions have been provided:

a. Who interacts with SQA?

b. Who has authority and delegates responsibilities of interacting functions?
c. What are the reporting relationships among the interacting elements identifying
independence/dependence?
d. Who has product release authority?
e. Who approves the SQA Plan?
f. What are the reporting lines for escalating conflicts and the method by which conflicts are to be
resolved among the elements?

2.1 Structure
Define Team composition for each project

Page 9
 CBT

2.2 Responsibilities
2.2.1 Product Owner
1. Requirement gathering from clients and writing user stories.
2. Maintain product backlog, prioritize projects and project requirements.
3. Assign projects to Scrum Masters.
4. Coordinate with Scrum Masters and Solution Architect.
5. Meeting with Scrum Masters to discuss requirements and timeline.
6. Re-prioritization of projects and project requirements after Scrum Masters’ discussion of story
points with his/her team.
7. Conduct design meeting, seeking consultancy from Solution Architect.
8. Make sure deployment of projects, their acceptance and track their use in organization.

2.2.2 Scrum Master

1. Act as the interface between Product Owner and Team.
2. Institute Daily Scrum.
3. Do scheduling of project assigned by Product Owner.
4. Assign tasks to team.
5. Perform team evaluation.
6. Make burn-down chart based on sprints.
7. Play the role of mentor for the team.
8. Make a library of frequently used functions.
9. Responsible for intra-team conflict resolution.

2.2.3 Solution Architect

1. Offer consultation to Product Owner and Scrum Masters.
2. Fill in as a back-up Scrum Master.
3. Review code written by developers.
4. Assure framework and coding standards are being followed.
5. Conduct R&D to improve development.
6. Adapt and maintain a centralized development framework.

2.2.4 QA
1. Audit processes being followed by Scrum Master, Product Owner and Solution Architect.
2. Assuring quality of artifacts.
3. Assuring work is committed on SVN in the right locations.
4. QA consultancy to Testers.
5. Improve QA processes and introduce efficient tools.
6. Identifying, developing and maintaining planning documents such as the Program Management
Plan, reference (h), references (e) and (f), Test Plans, and this SQA Plan.

Page 10
 CBT

2.2.5 Team Members (Developers, QA, DBA)

1. Meet deadlines.
2. Good team player.
3. Follows instructions.
4. Volunteers for work.
5. Follows standards.

2.2.6 Program Manager

1. Establishing a quality program by committing the project to implement the Software
Engineering Process Policy.
2. Reviewing and approving the SQAP.
3. Resolving and following-up on any quality issues raised by SQA.
4. Identifying an individual or group independent from the project to audit and report on the
project’s SQA function.
5. Identifying the quality factors to be implemented in the system and software.

2.3 Software Project Management

2.3.1 Project Initiation

Page 11
 CBT

2.3.2 Project Planning

Page 12
 CBT

2.3.1 Project Implementation

Page 13
 CBT

2.3.1 Project Closing

2.4 Story Points and Time Estimation

Time Estimation is done as follows:

First estimation is rough and is done using poker cards in which every team member gives his/her own
estimate of how long the task will take to complete. This is called ‘Story Points’. If variation between
estimated times is high, a discussion is held to negotiate time and after team consent the cycle is
repeated.

Now on basis of revised time estimates achieved, the Product Owner can change the priority of tasks.

Page 14
 CBT

 Working Hours are calculated as below:

If Sprint Duration= 15 days, and Team Size= 4 members, then (15 * 4) = 60 days.

This means that from the Backlog, only that amount of tasks should be undertaken in sprints that equal
60 days. Ideally, 48 days of work should be selected for 60 days (to make room for slack).

2.5 Anatomy of Testing Iterations

Page 15
 CBT

Chapter 3: Standards and Conventions

Broadly:

 Agile Software Development Methodology will be used

 A move towards TRAC will be made to manage software projects
 Development will be done in Zend Framework 1

3.1 Documentation
Minimum documentation requirements which will be reviewed or audited are:

1. Software Requirements Specification document (IEEE 830)

2. Test Plan, Verification and Validation Plan (Test-cases) (IEEE 829, 1012)
3. Verification results report and Validation results report (Bug Reports)
4. User manual (IEEE 1063)
5. Project Schedule and Tracking Report
6. Daily Scrum task sheet
7. Sprint log
8. Lessons learned

3.2 Development
Coding Standards Check List:-

 Directory structure has been followed

 Class Naming is as per standards
 Method Naming is as per standards
 Variable Naming is as per standards
 Only BO (Business Object) is communicating with DBAL (Database Abstraction Layer)
 CodeGen has been used to generate DBAL ,BO and Data Mappers
 Zend Tool has been used to create every element
 Generic functions are in Util.php and have been added after consultation with Scrum Master
and JSA
 Any changes to data mappers are done after consultation with Scrum Master or JSA
 Code is committed to SVN

3.2.1 Development tools and Framework

 Zend Framework 1.11.11
 Zend Studio 9.0 with Zend tool properly configured and tested
 PHP 5.3 or greater

3.2.2 Directory Structure

Page 16
 CBT

3.2.3 PHP File Formatting

1. Never use the closing tag “?>” for files that contain only PHP code — this prevents trailing
whitespace from being included in the output

3.2.4 Class Names

 Map directly to the directories where they are stored

 Contain only alphanumeric characters; numbers are discouraged; underscores are permitted
only in place of the path separator
Example: Zend/Db/Table.php maps to Zend_Db_Table

Page 17
 CBT

 Multiple-word names: in general, each word contains a capitalized first letter, with the
remaining letters lowercase (Ex: Pdf); there are exceptions, as when a word is an acronym or
somehow non-standard (Ex: XmlRpc)

 Business class must end with “BO” indicating that its business object.

3.2.5 Method Names

1. Must always start with a lowercase letter, each new word must start with capital “camelCase”.

2. Should contain the Pattern name when practical:

3. For methods declared with a “private” or “protected” construct, the first character of the
variable name must be a single underscore (the only time an underscore is permitted in a
method name).

3.2.6 Variable Names

1. Can only contain alphanumeric characters; underscores are not permitted numbers are
discouraged.
2. Must always start with a lowercase letter and follow the “camelCase” formatting rules

1. For class member variables declared with a private or protected construct the first character of
the variable name must be a single underscore (the only time an underscore is permitted in a
variable name)

Page 18
 CBT

2. Should be explanatory and use enough language as is practical to enhance the

understandability of the code.

3.2.7 Constants
1. Can contain alphanumeric characters, underscores, and numbers

2. Must always use capitalized letters

3. Multi-word names: must separate each word with an underscore (Ex EMBED_SUPPRESS)

4. Must define as class members using the “const” construct

3.2.8 Arrays
1. Negative numbers are not allowed as indices

2. When declared with the array construct a trailing space must be added after each comma
delimiter for readability (Example: $anyArray = array(i, 2, ‘Zend’);)

3. For multi-line indexed arrays using the array construct each successive line must be padded with
spaces so that the beginning of each line aligns as shown:

4. When declared with the array construct the statement should be broken into multiple lines
each successive line must be padded with whitespace so that both the keys and the values are
aligned, as shown:

3.2.9 Inline Documentation - Files

Every file that contains PHP code must have a header block at the top of the file that contains short
description of the class.

Page 19
 CBT

3.3 Quality Assurance & Testing

1. Tester(s) will be assigned for the duration of the project to ensure that they have sufficient
domain knowledge and can capture all product requirements.
2. Developer will do unit testing of the code written by him/her.
3. Code cannot be changed by developer while testing is in progress.
4. In case developer fails to reproduce or understand a bug, (s)he will first ask QA Team. In case
confusion persists, Project Manager or Team Lead will be approached.
5. Any new requirement or change in requirement should be communicated with the developer as
well as the tester.
6. Test cases will be made in MS Excel.
7. Bug-tracking will be done on Bugzilla.
8. Front-end testing automation will be done using Selenium.
9. Back-end testing automation will be done using Oracle Code Tester.
10. SRS, Test Plan, Change Request templates to be followed as provided in SVN->Sops&Forms.
11. Severity and priority of bugs will be defined by QA team as follows:
 Blocker bugs are those which hamper testing a functionality
 Critical are those where functionality is not working at all
 Major is if functionality is not implemented completely or correctly
 Normal is if a part of requirement is incompletely or incorrectly implemented
 Enhancement is if QA suggests making the UI more friendly
12. Priority of bugs will not be generally assigned since every bug needs to be fixed before
developer can release the application for next testing iteration.
13. Any bug which is being reopened should be notified to Project Manager, when:
 A Critical/Blocker bug is reopened 1st time
 A Major bug is reopened 2nd time
 A Normal bug is reopened 3rd time

3.4 Database
Scripting Standard for DB v 1.0 is given below in detail.

Page 20
 CBT

3.4.1 Tables

Naming conventions

 Table names should be plural whereas field name should be singular.

 Table names should not contain spaces and/or underscores accept few (discussed in next point).
 Name backup table ending with ‘_BK’.
 Name temporary table ending with ‘_TMP’.
 Table used for importing data must have the name same as that of .csv or .xlx file and ending
with ‘_ipo’??
 Avoid using short names unless the name of table exceeds 20 char.

Example:

 ‘Employeeemailaddressdetails’ can be ‘EMPEMAILdetails’

 ‘Micronetbroadbandconnections’ can be ‘MBLconnections’

If the table name contains several words, only the last one should be plural:

Example:

 APPLICATIONS
 APPLICATIONFUNCTIONS
 APPLICATIONFUNCTIONROLES
 Tables should be made in the relevant schema, do not make table in your own schema.

Example

 ‘Personaldetails’ is related to HRMS so while creating table name it

‘HRMS.personaldetails’.

Table rights
 Developers will be given rights of
 Delete
 Update
 Insert
 Select

Without further grant option, only on ‘TESTUSER’.

 Testers will be given

 Update
 Insert
 Select

Without further grant option on their own user name.

Page 21
 CBT

Table structure
1. Do not allocate unnecessary field size to any column.
2. All tables must have operator and date-time column except temporary, backup and import
tables.
3. Fields in which it’s sure that only one character will come should be char type with length of 1.

Example

 Gender can be of char type with max length of 1 because we have to save only ‘M’ or ‘F’

Field Names

1. Keeping names short i.e. name must not exceed more than 15 char otherwise follow
abbreviations rule as described earlier.

Example

2. Name the foreign keys the same as primary key.

Example

 If ‘employeeid’ is used in XZY table as foreign key then it should be ‘empid’

Constraints
1. Constraint name should start with the table where it is used then column name and at the
appending with key value.

Example

 Foreign keys and Primary keys should end with ‘_FK’ and ‘_PK’.
 Sequences and triggers should end with ‘_SEQ’ and ‘_TRG’.

2. For sequences use even sequence numbers in Live DB and odd sequence numbers for Test DB.
3. Apply constraints on DB level as much as possible.

3.4.2 Data entry

Testers, DBAs and developers must use a specific keyword for entering data

Example

 If a tester has to enter any User ID than it must be like ‘test.empABC’

 For developer it can be ‘dev.empABC’

Page 22
 CBT

3.4.3 Views

1. View names are plural, field name is singular.

2. View names should not contain spaces or underscores accept ‘_V’ that will be applied at the end
of every view.
3. View name can go up to 30char including the key word.

3.4.4 Index names

Name the Primary Key index as <TableName>_columnname_ipk:

Example

 PATIENTS would have a primary key index called patients_name_ipk

 Name a Unique Index as <TableName>_column_iuk

Example

 PATIENTS should have a unique index called patients_columnname_iuk

3.4.5 SQL

CASE
Type all SQL statements in lowercase, being consistent with capitalization improves the caching of SQL
statements. A common variant is to put only SQL keywords in capitals. This is oracle standard and can be
obtained by selecting the query and striking CTRL+F7 in sql developer.

Example

SELECT
em_employee_id_pk,
em_employee,
ab_start_date
FROM
employees em,
absences ab
WHERE
em.employeename =’xyz’
absences.ab_employee_id=employees.em_employee_id_pk;
Always list tables in the FROM / WHERE clause in desired join order.

Joins
1. Apply join at the end of SQL i.e. after applying all filters.
2. Also join in such a way that table with fewer values comes first; “deriving table should be the
one with fewer values”. (Apply join after all “where” clauses are written)
3. Further for further reference tips are provided in separate file.

Page 23
 CBT

3.4.6 PL/SQL
Use the following conventions as recommended by Oracle.

 Prefix scalar variable names with ‘v_’

 Prefix global variables (including host or bind variables) with ‘g_’
 Prefix constants with ‘c_’
 Prefix procedure or function call parameters (including sql*plus substitution parameters) with
‘p_’
 Prefix record collections with ‘r_’ (alternatively suffix with _record)
 Prefix %rowtype% collections with ‘rt_’ (alternatively suffix with _record_type)
 Prefix pl/sql tables with ‘t_’ (alternatively suffix with _table)
 Prefix table types with ‘tt_’ (alternatively suffix with _table_type)
 Suffix cursors with ‘_cursor’
 Prefix exceptions with ‘e_’.

Packages
Trigger names should be made up of the table name, an acronym representing the triggering action and
the suffix "_TRG". Name the package after what it is it should always be in upper case separated by ‘_’.
For example, if your package is related ‘evaluation of employee’ and performs functions like getting,
setting and updating etc. of records then the then it should look like “EMPEVALUATION_PKG”
Example
Table : APPLICATIONS
Action: BEFORE INSERT STATEMENT-LEVEL
Name : APPLICATION_BIS_TRG
Action: AFTER INSERT AND UPDATE ROW-LEVEL
Name : APPLICATION_AIUR_TRG

1. Write one package for each table - named TABLENAME_ PKG, put all other code that logically
belongs to the schema, but not to any particular table in a single Schema package
SCHEMANAME _PKG.
2. These should contain no code just wrappers that call procedures/functions in the other
packages.
3. A pl/sql function name like PAYROLL.TAX_RATE the word ‘PAYROLL’ could refer to either a
schema or a package name.

Procedures
1. Every procedure must be part of a package.

Page 24
 CBT

2. Naming should in such a way that first its functionality should be reflected. At the end
‘_PROC’ should be there.

Example

Package to get some value of customers can be ‘GETcustomerrecord_proc’

Page 25
 CBT

Chapter 4: SQA Tasks & Metrics

The scheduling of SQA tasks is driven by the software development schedule. Therefore, an SQA task is
performed in relationship to what software development activities are taking place. One or more SQA
tasks can be performed concurrently until a task is completed. A task is considered completed when the
required report e.g., SQA Reports, Process Audits Reports, etc. are satisfactorily completed or action
items have been closed. The following tasks, requiring coordination and cooperation with the project
team, shall be performed by SQA.

What to Audit?

Page 26
 CBT

4.1 Task: Review Software Products

SQA shall assist the project in identifying the standards or guidelines to be followed in developing the
software product.

SQA Plan SQA Progra Proje Sol. Scrum Devel Teste DBA Com
m Mgr. ct Archit Maste oper r ment
Mgr. ect r s
Develop/Document X X
SQA Plan
Review tailored SQA X X X X X X X X
Plan for projects’
characteristics
Approve SQA Plan X X X

Page 27
 CBT

4.2 Task: Evaluate Software Tools

SQA shall conduct evaluations of tools, both existing and planned, used for software development and
support. The tools are evaluated for adequacy by assessing whether they perform the functions for
which the tools are intended and for applicability by assessing whether the tool capabilities are needed
for the software development or support.

Evaluate Software Tools SQA Program Project Sol. Scrum Develo Comm
Mgr. Mgr. Architec Master pment ents
t Team

Evaluate tool as a X X X
continuous integration and
feedback mechanism (Trac)
Agile project management
software helps create
product and sprint backlog
and tracks velocity?
Digital cameras are used for
quickly capturing
whiteboard sessions?
Wiki allows stakeholders to
create, view, amend and
discuss project elements?
Resolve Audit Findings X X

Page 28
 CBT

4.3 Task: Evaluate Software Products Review Process

This SQA task assures that quality review processes are in place for all software products and that these
products have undergone software product evaluation, testing, and corrective action as required by the
standard. SQA shall check that software products that are ready for review are reviewed, verify results
are reported and issues or problems reported are resolved.

The results of this task shall be documented and any SQA recommendation for corrective action shall
require project management’s consent.

Issue Management SQA Program Projec Sol. Scrum Develo Comm

Mgr. t Mgr. Archite Master pment ents
ct Team

Design is reviewed before X

implementation phase?

SRS is reviewed when X

ready?

Code is reviewed once in X

a sprint at least?

DB design and X X
development is reviewed
once a sprint at least?

Are issues raised, X X X X

assessed and resolved in
a timely and efficient
manner?

Unit testing is done X X

before submitting module
for testing?
Functional testing bug X X
report is reviewed once in
a sprint at least?
Informal demo is given X X X X X
before release that shows
tested working software?
Users
Is user involvement X X X
adequate?
Development Approach
Is a recognized X X X
development method(s)

Page 29
 CBT

been followed?
If more than one method X X X
has been implemented,
does a documented
process exist for effective
integration between /
among methods?

Page 30
 CBT

4.4 Task: Evaluate Project Planning, Tracking and Oversight Processes

SQA shall evaluate that the project conducts the relevant activities stated in the Project plans. To verify
that these activities are performed as planned, SQA will audit the processes that define the activity. SQA
will use the audit checklists as guides for conducting the evaluation. Any recommended changes to
those plans will require update and approval by program management.

Project Planning, Tracking SQA Program Projec Sol. Scrum Develo Comm
& Oversight (PPT&O) Mgr. t Mgr. Archite Master pment ents
Process ct Team
Daily scrum is conducted? X X

Current sprint progress can X X X

be seen any time?

Team acts when behind X X

schedule?

Develop SDP/PMP and X X

other project plans (Gantt
Chart, WBS, Resource
Usage)

Has a structured approach X X

been used to break work
effort into manageable
components?

Are team members X X

involved in the
development of activity &
task decomposition?

Teams are given choice to X

choose among Product
Backlog items to work on?
Sprint planning meeting is X X X
conducted between Scrum
Master (SM) and PO and
then SM and team?
Are individual tasks of X X X
reasonable duration (8–40
hrs.)?
Baseline Plan X X X
Does the detailed project X X X

Page 31
 CBT

plan identify individual

responsibilities for the next
4–6 weeks?
Current scope of the X X X
project is substantially
different than that
originally defined in the
approved project plan?
Resourcing
Is there a project X X
organization chart showing
the reporting relationships
and responsibilities for
each position?
Has allowance been made X X
for vacations, holidays,
training (learning time for
each team member), staff
promotions & staff
turnovers?

Page 32
 CBT

4.5 Task: Evaluate System Requirements Analysis Process

Requirements analysis establishes a common understanding of the customer’s requirements between
that customer and the software project team. SQA activities related to this are listed below:

a. Verify that the correct participants are involved in the system requirements analysis process to
identify all user needs.
b. Verify that requirements are reviewed to determine if they are feasible to implement, clearly
stated, and consistent.
c. Verify that changes to allocated requirements, work products and activities are identified,
reviewed, and tracked to closure.
d. Verify that the commitments resulting from allocated requirements are negotiated and agreed
upon by the affected groups.
e. Verify that commitments are documented, communicated, reviewed, and accepted.
f. Verify that allocated requirements identified as having potential problems are reviewed with the
group responsible for analyzing system requirements and documents, and that necessary
changes are made.
g. Verify that the agreed upon requirements are addressed in the SDP.

System Requirements SQA Program Project Sol. Scrum Develop Comm

Analysis Process Mgr. Mgr. Architec Master ment ents
t Team

Develop/document System X X X X
Requirements
Review System X X
Requirements
Approve System X X
Requirements
New requirement comes X X
through story points by
Product Owner
Review / Document changes X X X
in requirements
Evaluate/report System X
Requirements Analysis
Process

Resolve Audit Findings X X

Page 33
 CBT

4.6 Task: Evaluate Software Design Process

The purpose of the system design process is to develop decisions about the system’s behavioral design.
Based on the requirements identified in the previous phase, the software is partitioned into modules,
and the function(s) of each module and relationships among these modules are defined.

A goal of detailed design is to define logically how the software will satisfy the allocated requirements.
The level of detail of this design must be such that the coding can be accomplished by someone other
than the original designer. SQA activities are listed below:

SQA activities are listed below:

a. Verify that system design documents are prepared and kept current and consistent.
b. Verify that relevant documents are updated and based on approved requirements changes.
c. Verify that design walkthroughs (peer reviews) evaluate compliance of the design to the
requirements, identify defects in the design and evaluate and report design alternatives.
d. Participate in a sampled set of design walkthroughs and verify all walkthroughs are conducted.
e. Identify defects, verify resolution for previous identified defects, and verify change control
integrity.
f. Selectively review and audit the content of system design documents.
g. Identify lack of compliance with standards and determine corrective actions.
h. Determine whether the requirements and accompanying design and tools conform to
standards, and whether waivers are needed prior to continuing software development.
i. Review demonstration prototypes for compliance with requirements and standards.
j. Verify that the demonstration conforms to standards and procedures.
k. Review the status of design milestones.
System Design Process SQA Program Projec Sol. Scrum Develo Comm
Mgr. t Mgr. Archite Master pment ents
ct Team

Develop/document System X X X
Design
Review System Design X X X
Are object-based design X X
principles being
employed?
Are application interfaces X X X X X
designed in such a way as
to facilitate maintenance
and change?
Is an active data dictionary X
in place?
Has a set of data naming X X
conventions and/or
standards been

Page 34
 CBT

established?
Has the data model been X X
integrated with the other
user and system views of
the data?
Resolve Audit Findings X X
Approve System Design X X X X
Evaluate/report System X
Design Process

Page 35
 CBT

4.7 Task: Evaluate Software Implementation, Unit and Component Testing

Process
Software implementation or coding is the point in the software development cycle at which the design is
finally implemented. The process includes unit testing of the software code and then component
testing by the testers. SQA activities are listed below:

a. Verify that the coding process, associated code reviews, and software unit testing are conducted
in conformance with the standards and procedures established by the project.
b. Verify that action items resulting from reviews of the code are resolved in accordance with
these standards and procedures.
c. Verify that the SDF used for tracking and documenting the development of a software unit is
implemented and is kept current.
Software Implementation SQA Program Projec Sol. Scrum Develo Comm
& Unit Testing Process Mgr. t Mgr. Archite Master pment ents
ct Team
SRS followed while X X X X
development
Develop/fix code X X
Code review X X
Unit Test X X
Evaluate/report SW X
Implementation and Unit
Testing Process
Component Testing X X
DB Jobs X X
User Acceptance Testing X X X
Fix errors X
Regression Testing X X
Witness formal and X
acceptance-level
software testing
Resolve Audit Findings X X

Page 36
 CBT

4.8 Task: Evaluate System Qualification Testing Processes

Software integration and test activities combine individually developed components together in the
developing environment to verify that they work together to complete the software and system
functionality. In the integration and test phase of the development lifecycle, the testing focus shifts
from an individual component correctness to the proper operation of interfaces between components,
the flow of information through the system, and the satisfaction of system requirements. SQA activities
are listed below:

a. Verify that software test activities are identified, test environments have been defined, and
guidelines for testing have been designed. SQA will verify the software integration process,
software integration testing activities and the software performance testing activities are being
performed in accordance with the SDP, the software design, the plan for software testing, and
established software standards and procedures.
b. Verify that as many of the software integration tests as necessary and all of the software
performance tests are witnessed and that all discrepancies discovered during the tests are being
properly reported and the associated test reports are completed.
c. Verify that discrepancies discovered during software integration and performance tests are
identified, analyzed, documented, and corrected; software unit tests, and software integration
tests are re-executed as necessary to validate corrections made to the code; and the software
unit’s design, code, and test is updated based on the results of software integration testing,
software performance testing, and corrective action process.
d. Review the Software Test Plan and Software Test Descriptions for compliance with requirements
and standards.
Unit Integration and SQA Program Project Sol. Scrum Develo Comm
Testing Process Mgr. Mgr. Architec Master pment ents
t Team

Iterations doomed to fail X X

are terminated early?
Having fun while working, X
energy levels are high?
Overtime is rare and X X
happens voluntarily?
Integrate SW X X

Test Integrated SW X

Fix errors X

Evaluate/report Unit X X X
Integration and Testing
Process

Page 37
 CBT

Maintain the collection and X X

classification
of defects found
during/from software
assurance and
programmatic/project
formal and informal
reviews

Approve version release X

Evaluate/report End-item X
Delivery
Resolve Audit Findings X X

Track use of software X

New requirement is catered

by assigning more
resources or time?
Code has proper X X X
authentication?
Sprint backlog is updated X
daily?
Release backlog is updated? X X

Retrospective scrum is X X X X X
conducted?
Process is continuously X
improving?
Release is potentially X X X
shippable product?
Release items capture X X
product backlog
requirements?
Impediment List is X X X
maintained and discussed?

Page 38
 CBT

4.9 Task: Evaluate the Corrective Action Process

The corrective action process describes the steps for (1) problem identification and correction occurring
during software development to verify early detection of actual or potential problems, (2) reporting of
the problem to the proper authority, (3) analysis of the problem to propose corrective measures, (4)
timely and complete corrective action, and (5) the recording and follow-up of each problem's status.
Problems in this context include documentation errors, software errors, and noncompliance with
standards and procedures. SQA activities are listed below:

a. Periodically review the corrective action process and their results against the SCM Plan to assess
the effectiveness of the corrective action process.
b. Perform periodic analysis of all reported problems to identify trends that may disclose generic
problem areas. These analyses shall include the study of the causes, magnitude of impact,
frequency of occurrence, and preventive measures.
Corrective Action Process SQA Program Projec Sol. Scrum Develo Comm
Mgr. t Mgr. Archite Master pment ents
ct Team
Present the status and X X
quality of the
software at formal reviews

If not, have all project X X

delays been adequately
accounted for,
communicated to all
stakeholders and
adjustments made in
overall project schedule?

Are corrective actions taken X X X X

when actual results are
substantially different from
detailed project plan?
Describe

Corrective Action Process is X X X X

followed?
Evaluate/report Corrective X
Action Process

Resolve Audit Findings X X

Page 39
 CBT

4.10 Task: Evaluate Deviations and Waivers

SQA shall assist program or project management, with requests for deviations and waivers, if required,
and verify that the deviation or waiver request is documented, processed and approved by the Product
Owner.

Deviations & Waivers SQA Program Projec Sol. Scrum Develo Comm
Mgr. t Mgr. Archite Master pment ents
ct Team
Document deviations & X X
waivers
Recommend Approval X X X
Approve X

Evaluate/report Deviation X X
& Waiver Process

Resolve Audit Findings X X

Page 40
 CBT

4.11 Task: Evaluate Configuration Management Process

CM is the discipline that applies technical and administrative direction and surveillance to (1) identify
and document the functional and physical characteristics of CIs, (2) control the changes to CIs and their
related documentation, (3) record and report information needed to manage CIs effectively, including
the status of proposed changes and the implementation status of approved changes, and (4) audit the
CIs to verify conformance to specifications, interface control documents, and other contract
requirements. SQA activities are listed below:

a. Verify that configuration identification of documents, code, and computer data has established
standards for titling, naming and describing change status.
b. Verify configuration control of changes to baseline documents and software are being managed
in accordance with SCM requirements as stated in the SCM Plan.
c. Verify for document control that only approved, up-to-date documentation is provided for use
by project personnel and that the document distribution process results in receipt of correct
documentation.
d. Verify that the program support library is the single place of storage for the baseline version of
all software. Verify that the identification of all software includes the software name and a
unique version identifier. The evaluation shall also determine that control of access to software
products is being properly exercised and that unauthorized changes to master files cannot
occur.
Documentation SQA Program Projec Sol. Scrum Develo Comm
Mgr. t Mgr. Archite Master pment ents
ct Team
Initial Phase:

Project Plan (including X X X

WBS)
PMP provides a list of the X
references that were used
in preparation of this
document.
Design Phase:

Functional Requirements X
and
Database Specifications are
documented

Validation, Verification, X
and Testing Plan (initial) X

Project Plan (updated) X

Evaluation Phase:

Page 41
 CBT

Test Results and Evaluation X X

Reports

Project Plan (updated) X

Operation Phase:
Project Plan (updated) X
Document, track, and X X X X X
resolve problems
found with the
implementation of
software
life cycle processes

4.12 PMI-ACP
Evaluate Software Tools SQA Program Project Sol. Scrum Develo Comm
Mgr. Mgr. Architec Master pment ents
t Team

Customer is satisfied X X X
through early and
continuous delivery of
software?
Changing requirements are X X
welcomed even late in
development?
Working software is
delivered frequently?
Face-to-face conversations
are preferred over email?
Constant pace is maintained
indefinitely by PO,
Development Team and
users?
Attention is given to agile
design and technical
excellence?
Frequent testing is done?
PO sits as a ‘proxy customer’
in team meetings to present
business side of the project?
Design is made keeping X
future changing

Page 42
 CBT

requirements in mind?
Code refactoring is done? X
SM includes clients in
meetings frequently?
Planned inspection is done X X
through: Sprint
retrospective, daily scrum,
sprint review and sprint
planning meetings?
Teams are working as self- X
organizing and cross-
functional units?
Product backlog created by
PO has shared
understanding and visibility?
SM assists PO with managing X X
the backlog?
Past performance is used to
define sprint goal and time
estimation?
Daily scrum covers the 3
basic questions?
In sprint review meeting, the
finished mini-project is
presented for viewing?
In sprint retrospective
meeting, Code Review and
Audit findings are
presented?
Product backlog is groomed X X
by adding more detail and
order to refine estimates?
Based on estimation by
development team, PO re-
prioritizes backlog?
Sprint backlog is highly
visible?
Sprint backlog is updated
only by development team
or SM?
PO gathers next iteration
story details while
development team is
working on a sprint?
Adequate and not too many X
items have been assigned

Page 43
 CBT

Priority 1?
When prioritization is
difficult, customer is asked
to provide MoSCoW (Must
have, Should have, Could
have, Would have) or 100-
point prioritization?
Product roadmap shows a
quick view of all products’
releases? (Trac)
Stories with residual risk
(risky items) are moved up
the queue by PO? (Enough
requirements gathered
about them?)
“Change for free” is given to
customer if he is engaged
with the team on every
iteration?
Waste doesn’t occur due to:
 Code waiting for
testing
 Specs waiting to be
developed
 Wait for prototyping
review
 Requirement defects
 Extensive software
bugs
Product Backlog doesn’t
have a long list of Work In
Progress (WIP)?
Enough work is in progress
such that bottlenecks in
processes that slow overall
workflow and mask
efficiency can be identified?
Is there a lot of scrap and
rework involved?
Sufficient work is occurring
such that people are not idle
or have slack?
How many Work Items move
from ‘To Do’ to ‘In Progress’
to ‘Done’ in a sprint?

Page 44
 CBT

Throughput of work is
improving? (Work delivered
is more than WIP)
For complex projects, the
plain vanilla version of
project is delivered first?
The gulf of evaluation is
reduced between client and
development team by
frequent meetings?
Customer is asked what their
top-priority features are.
For IKIWISI (I will Know It
When I See It) customer, to
understand true
requirements, demos and
feedback sessions are held
frequently?
PO readies wireframes and
mock-ups of user stories for
next sprint?
User stories are written such
that they are independent,
estimate able, valuable and
small.
The user story works end to
end (from interface to
database)?
Progress is made by
development team everyday
rather than changing all user
stories status to ‘Done’ on
last day of sprint?
How long is defect cycle
(from bug /defect reporting
to bug fixing)?
Is the work velocity
improving? (number of user
stories completed in a
sprint)
Screen designs are used as
agile models?
SM protects team members
from diversions and
interruptions?
Victories are celebrated?

Page 45
 CBT

SM performs coaching role?

SM directs activities and
presents clear picture of
what needs to be done?
SM challenges the team with
high-level goals?
Team holds themselves
mutually accountable for
outcome of the project?
Reporting is included in
standup meeting, not
problem solving?
Osmotic communication can
be seen happening?
Sprint planning is done such
that a package of minimally
marketable features (MMF)
is delivered at the end?
Upfront estimates are not
considered final estimates?
Estimation is not done by
the project manager?
Story-points time estimation
includes unit testing and
testing time?
Similarly sized user stories
that have been assigned
similar estimates are
comparable in size?
Size of project is determined
in story points?
Effort is calculated in
number of hours?
Effort is converted into a
schedule?
Prototype is created and
iteratively progressed from
there on with the client?
Adaptive Planning is done
before every iteration:
 Backlog
prioritization after
iteration
 Customer feedback
 Retrospectives
Planning is done not so

Page 46
 CBT

much that plans become

brittle and not so less that
rework is required?
Baseline plan of releases and
iterations is made early in
project lifecycle and
revisited as project
progresses?
PO comes to sprint planning
meeting with a freshly
prioritized backlog?
PO then describes the
backlog items they would
like developed in the sprint?
Team members select a set
of items they think are
achievable?
PO has final say on priority
of the sprint?
Development team has final
say on the amount of work
that can be accomplished in
the sprint?
Team breaks down selected
backlog items into
constituent parts to form
sprint backlog of action
items?
Are change requests being
received faster than they can
be processed? (Indicates
that we may not be
spending enough time
validating feature
requirements before
undertaking development)
Projects have small user
stories?
The cycle time for bug fixing
reduces over time?
Number of escaped defects
count reduces over time?
If project goes off track,
managers go back to non-
agile ways?
Source code control system
in in effect?

Page 47
 CBT

All people participate in the

retrospective and start early
in the meeting? If not, are
they motivated to?
Is any practice being met
with resistance? Is it a poor
fit for the environment or
highlighting an issue that
needs resolution?

Page 48