Community Healthcare Scheduling

Software Quality Assurance Report

Name Student ID

Amarpreet Singh 40013505

Gurvinder Singh 40012931

Ramanjit Dhillon 40010613

Maryam Eftekhari 27734069

SUBMITTED TO:
Dr. Chun Wang

INSE6260 - Software Quality Assurance (Winter-2017)

Table of Contents
Software Quality Assurance Plan................................................................................................3
1.1 Scope........................................................................................................................ 3
1.2 Purpose..................................................................................................................... 3
1.3 Reference documents..................................................................................................4
1.4 Management..............................................................................................................4
1.4.1 Organization.......................................................................................................4
1.4.2 Tasks and Responsibilities....................................................................................5
1.5 Documentation........................................................................................................... 5
1.6 Standards, Practices, Conventions and Metrics...............................................................6
1.6.1 Standards............................................................................................................ 6
1.6.2 Best-practices......................................................................................................6
1.6.3 Metrics............................................................................................................... 7
1.7 Software Reviews and Audits.......................................................................................7
1.8 Test........................................................................................................................... 8
1.9 Problem reporting and corrective actions.......................................................................8
1.10 Tools, Techniques and Methodologies...........................................................................8
1.11 Media control.............................................................................................................9
1.12 Supplier control.......................................................................................................... 9
1.13 Record collection, Maintenance and Retention...............................................................9
1.14 Training..................................................................................................................... 9
1.15 Risk management.....................................................................................................10
1.16 Glossary:................................................................................................................. 10
1.17 SQAP change procedure and history...........................................................................10
1.18 References............................................................................................................... 11

Software Quality Assurance Plan

Page 2 of 11
 1.1 Scope

The scope of this document is to provide a framework for the software quality assurance.
Software quality assurance will be followed in each phase of the software development
lifecycle starting with analysis and design and till the time the project is delivered. Scope
should not prohibit adding additional content in the project rather it defines what is necessary
to be included and in what form. In order to stay on track we need a software quality
assurance plan for each phase of the project development.

1.2 Purpose

The main rationale for this document is to define the software quality assurance tools and
techniques that will be employed throughout the software development lifecycle. This plan
clarifies uniform and minimum requirements for the software quality assurance activity to
take place smoothly. Software quality assurance plan will ensure that standards are met
throughout the lifecycle. Software quality assurance plan will provide procedures to manage
deviations from the plan and record those deviations in a common repository. Once the
deviations are recorded, necessary actions could be taken.
Here, spectrum healthcare agency which provides services to its customers via its pool of
caregivers wants to go online with a scheduling algorithm that provides best service to the
customers while maximizing the revenue of the agency. We will be creating a system that will
take in account the bundle of requests and assign them to specialist and the backup nurses.
Here we will be using an iterative development model for developing the system with each
prototype evaluated by software quality assurance team (Maryam and Ramanjit) and the
software quality manager (Chun Wang).

Figure 1: Iterative Model [https://www.inflectra.com/Methodologies/Waterfall.aspx]

Keeping the requirements in our frame of reference while developing the project we will
create a system for spectrum healthcare that provides maximum customer satisfaction. In order
to accomplish this, our SQA team will be validating each and every document and piece of
code generated so that the software engineering team does not go off-track.

1.3 Reference documents

Product Request document: It is the initial software requirement document provided by Professor
Chun Wang.

Page 3 of 11
 Home healthcare scheduling model. It is the scheduling algorithm detailed by Professor Chun Wang.
Software Requirement Specifications document.
IEEE-STD-730-2002: It is the IEEE standard for quality assurance plans.

1.4 Management

1.4.1 Organization

The organization structure of the project is as displayed below. Here, Spectrum Healthcare
agency is our client and Professor Chung Wang is our Project Manager. Project Manager is
heading the SQA team and the Software Engineering team. SQA team is responsible for
making sure that the project meets the quality criteria while Software Engineering team is
responsible to developing the software product.

SQA Team
(Ramanjit Dhil on,
Spectrum Maryam)
Healthcare Project Manager
(Professor Chun (SQA Team)
Wang) Software
Engineering Team
(Gurvinder Singh,
Amarpreet Singh)
Fig. 2: Organizational structure.

1.4.2 Tasks and Responsibilities

The task and responsibility table below segregates the responsibilities for both SQA and
software Engineering team.

Page 4 of 11
Task Planned Task Planned Task Project SQA Software Comments
Start Date End Date Management Team Engineerin
g Team
Staffing Team 11-Jan-2017 18-Jan-2017 Yes SQA will not
be involved
here
Requirement 25-Jan-2017 8-Feb-2017 Yes SQA will not
Gathering be involved
here
Requirement 7-Feb-2017 14-Feb-2017 Yes Yes SQA will
Analysis provides its
inputs
regarding their
understanding
of
requirements
Develop SQA 18-Jan-2017 Continuous Yes SQA team will
Plan Process till be developing
Testing of this
software.
Develop SRS 25-Jan-2017 15-Feb-2017 Yes Yes SQA will verify
Plan if SRS
conforms to
requirements
Develop 15-March- 8-March- Yes Yes SQA will verify
Software 2017 2017 if SDS
Design conforms to
Specification SRS
Development 15-Feb-2017 28-March- Yes Yes SQA will verify
2017 if the product
conforms to
SRS
Final Project 22-March- 5-April-2017 Yes Yes SQA will
Report 2017 provide its
report
Project 5-April-2017 12-April-2017 Yes Yes SQA along
Presentation with Software
Engineering
team will
present their
work
Table 1

1.5 Documentation

In order to maintain the quality of the project over various lifecycle phases we will be
creating documentation and validating those documents for feasibility. Documentation is
required to maintain the quality of the software. The below is a preliminary list of document
that will be created:

Page 5 of 11
1. Software Requirement Specification: This document is submitted by our team on 15-Feb-2017.
2. Software design description (SDD): This document is under development and have to be submitted
by 8-March-2017.
3. Verification and validation plans: This document will be formed to validate and verify i.e analyse,
evaluate, review, inspect, assess, and test the software product that we will be forming. Its
development will be done during and after the development phase of project
4. Verification results report and validation results report: This report will be generated as per the
results analysed in Verification and Validation plan and thus will be created after that plan is fully
developed.
5. User Documentation: We will be updating this document during the development phase as per
validations applied in that phase.
6. Software configuration management plan (SCMP): Will be created after identification of changes.

1.6 Standards, Practices, Conventions and Metrics

1.6.1 Standards

We will be taking in consideration the best and industry certified standards for proceeding
with the development of the product. IEEE standards will be followed for documentation
purposes. Also, while coding and testing, we will make use of as many standard tools for eg:
Git as version control and Bugzilla for defect tracking.

1.) Documentation standards: We will be forming and updating all the required documents during each
phase of our product development. The standards that we will describe in these documents will help
us to reach our goal of making an running software as per the user requirements.
2.) Design standards: This part will involving generating and complying with various design diagrams
such as Conceptual model ER diagram, System architecture, Use case diagram and Activity diagrams.
This will help our team to have control over what we are developing.
3.) Coding standards: We wont be following any specific coding standards but yes our team will assure
that its is kept simple and easy to test with high readability(High Cohesion and Low Coupling).
4.) Commentary standards: We will be using simple natural language in formal form to mention our
comments for the code section that we require to so that later on updates and maintenance becomes
simpler.
5.) Testing standards and practices: Developers will be responsible for unit testing their code in our
project and at the same time SQA team will look into other aspects of testing such as checking the
compliance level of the final product with user requirements.
6.) Selected software quality assurance product and process metrics: Software quality of the product
will be assured in each build and is mentioned in details in section-1.6.2 and the process metrics part
is covered in section-1.6.3.

1.6.2 Best-practices

Software quality can only be assured by following best practices. We will be following some
of the best practices as described below:
Design Reviews
Code Reviews
Inspection

Page 6 of 11
 Daily status meetings
Code tested for security vulnerabilities.

1.6.3 Metrics

We will be using metrics at every lifecycle stage in order to ensure that project quality is not
getting compromised.
Some of the metrics that we will be using are Defect tracking metrics, Chidamber and
Kemerer metrics, non compliance items list and trends etc

1.7 Software Reviews and Audits

We will be performing reviews and audits after each phase of the lifecycle process. Reviews
done in time are very important to measure the progress of the project and to check if the
quality of the project is maintained.
This part of our SQA plan can be divided into different implementation phases:
1) Software specifications review (Requirement Phase):
i) In this phase SQA will be responsible for reviewing the requirements specification after the
completion of Software-Requirement-Specification document.
ii) The professor as the manager will provide his own reviews over that.
2) Architecture design review and Detailed design review (Design Phase):
i) Again the SQA will conduct the Architectural and Detailed design review for the project to
ensure that its going in the right direction.
ii) Further the manager i.e the professor will also provide his reviews after we submit the
necessary documentation for the same(SDS).
3) Verification and Validation (Implementation phase):
i) Verification and Validation will be conducted during and after the implementation
phase via audits by the SQA team.
4) Functional audit (Testing Phase):
i) Functional audits will be held in this stage to check the compliance level attained by the
development team as per the requirements.
ii) Verification and Validation will continue in this phase too.

5) Physical Audit (Project Completion Phase):

i) Professor will perform the managerial review to check the implementation of the SQA plan
for the project.
ii) Prototype will be demonstrated by our team and the manager will monitor its completion.
6) In-process Audits:
These involve :
Code versus design documentation
Interface specifications (hardware and software)
Design implementations versus functional requirements
Functional requirements versus test descriptions

Page 7 of 11
 and all of them have been inculcated in the above points from 1 to 5 i.e from Requirements
phase to Project Completion phase.
7) Managerial reviews: These are the reviews carried out by the project manager which is the professor
in our case. All the manager reviews have been inculcated in the above points from 1 to 5 i.e from
Requirements phase to Project Completion phase.
8) Software configuration management plan review (SCMPR): This part of the project will be
inculcated in the above points 3 and 4 i.e Verification and Validation and Functional Audit.
9) Post-implementation review: This part will be inculcated in above point 4 i.e the point after
implementation phase which is the Testing phase.

1.8 Test

This part will include all the test cases that were not included as a part of software validation
and verification plan (which mainly covers functional test cases).
So the scope of this phase can extend to
1) Making sure that the developers conducted proper unit test cases
2) User testing will be performed for the prototype before final release of the project.
It is better to get all the unit test cases documented so that they can be reviewed and updated.
Same thing also goes on with the user journeys tested by the user during user testing.
Thus we will create a separate document for this purpose after further team discussions.

1.9 Problem reporting and corrective actions

SQA is responsible to make sure that the problems identified in project reviews and audits are
taken care of. Also, SQA will follow up with the teams required to make the corrective
actions. If during the Project review and audit, any issue is identified then the SQA needs to
report that immediately so that corrective actions could be taken up as soon as possible. We
will also be generating reports to monitor the progress on the problems identified.

1.10 Tools, Techniques and Methodologies

The set of tools, techniques and methodologies followed to measure the software quality in an
efficient way defines the quality and standards of the software formed. We will be using code
review tools such as SVN or Git which which also act as a repository for our code and thus
will save us from any mishaps that can happen with the software or code.
We will also lay stress on problem tracking and will keep track of all the progresses and
issues faced during software generation.
Moving on to the methodologies we will follow ISO 9126 standards as our base to deliver the
best of software with maximum quality assurance. This standard will guide us towards
achieving the best with our
1) Functionalities,
2) Reliability,
3) Usability,
4) Efficiency,
5) Maintainability and
6) Portability

Page 8 of 11
 1.11 Media control

Health care is very sensitive field and it is necessary to safeguard the medical history of all the
patients. There must not be a leak in the system holding this type of information as the hacker
may change certain information about the patient which may cause life threatening situations
for the patients.
Therefore the software or servers used for this purpose must be reliable therefore we will be
saving our systems information on Microsoft SQL servers with encryption. This will protect
our system information from being accessed by any unauthorized personnel.
Through media control following properties will be inherited in our project:
Taking backup of data.
Providing Data Encryption.
Software code will be maintained on repository so that it can be saved from any kind of damages or
data losses.

1.12 Supplier control

It has to be made sure that the development team receives full set of requirements and that
there is no misconceptions between the client providing the requirement and the team
collecting it.
As in our case we are provided the requirements as our course project material so we can do
the following to ensure that our projects requirements are collected in an healthy manner:
1) Ask the project manager(Professor) who has the requirements in case of any doubts in the project
understandability.
2) Raise our team concerns if any to project manager as soon as possible to ensure that the delivery is
not delayed.
3) Update the project manager at regular intervals from time to time so that his reviews can be taken.

1.13 Record collection, Maintenance and Retention

Collection of records, maintenance and retention in a software project is very important for
structured evolution of a software.
All the three given attributes complement each other as proper retention of documented records
about the software and its functionalities helps in efficient maintenance of the software by
reducing the cost and effort involved with that.The documentation will also keep track of all the
recommendations made by the SQA and advance made corresponding them.
Thus this will help us ensure that Software Quality Assurance processes are followed
throughout the life cycle of the software.

1.14 Training

Our team will be brushing up their concepts in various domains as per the requirements of this
project. For this to be accomplished successfully we will be helping each other as per our own
field of domain and If required we will be taking expert guidance as well which may require
certain help from the professor or learning basics of few things from interactive websites such
as youtube.com.

Page 9 of 11
 1.15 Risk management

There can be a wide variety of risk involved in a software project. The effects of risk can be
anything from increase in production cost or development of poor quality software product to
not being able to meet the project deadlines. All these ill effects will be taken care off by this
section.
For Spectrum Health Care the SQA will review each of the potential risks involved with the
project and will take care of them though a structured approach such which involves:
1. Identifying the risk
2. Reducing the impact of the risk
3. Reducing the probability or likelihood of the risk
4. Risk monitoring

SQA will constantly monitor the risk management to ensure that the procedures provided by it
are followed throughout the lifecycle to avoid risk.

1.16 Glossary:

Term Meaning
Usability Degree to which the software under development and test is easy to use.
Maintainability Degree to which the software under development and test is easy to
maintain. This helps in isolating errors, defects and getting the exact root
cause.
Portability Degree to which the software under development and test is usable in
different computing environment.

1.17 SQAP change procedure and history

As discussed under section 2.12 documentation for SQA process plan will be maintained
throughout the life cycle of the project
Thus there exists a non deniable need to define that how really a change in SQAP itself will be
examined during the evolution of the project.
To start with a team meeting will be called as soon as someone wants to recommend certain
changes in the SQAP.
Then based on the mutual voting system we will decide that whether the recommended changes
in the SQAP will lead the project towards improvement or not.
Further based on the results of the vote we will perform changes in SQAP via formal formats, if
required.
Finally, all these changes and recommendations with its results will be documented from time
to time to maintain its history.

1.18 References

1. http://www.test-institute.org/What_Is_Software_Risk_And_Software_Risk_Management.php

Page 10 of 11
2. Lecture Notes INSE6260
3. IEEE Standard template for SQA plan (IEEE-STD-730-2002.pdf)

Page 11 of 11