Scribd
Upload
197 views4 pages

Phase Two Software Quality Assurance Plan: 1. Purpose

This document outlines a Software Quality Assurance Plan (SQAP) for the development of an Internet Voting System Manager (IVSM). The plan identifies responsibilities, defines review and audit processes, and lists documentation that will be produced. Testing will occur at the unit, integration, and system levels to verify requirements. Problems will be reported to the developer's supervisor and addressed before formal presentations and submission of documentation.

Uploaded by

AB Gammer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
197 views4 pages

Phase Two Software Quality Assurance Plan: 1. Purpose

This document outlines a Software Quality Assurance Plan (SQAP) for the development of an Internet Voting System Manager (IVSM). The plan identifies responsibilities, defines review and audit processes, and lists documentation that will be produced. Testing will occur at the unit, integration, and system levels to verify requirements. Problems will be reported to the developer's supervisor and addressed before formal presentations and submission of documentation.

Uploaded by

AB Gammer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

Phase Two

Software Quality Assurance Plan


Yonghua Li
March 28, 2002
An important part of achieving quality is to plan for quality, that is, to plan those
activities that will help to achieve quality. The software quality assurance (SQA)
plan is to provide a guideline for activities that will ensure the quality of software.
I use the IEEE standard Std 730-1989 for developing the Software Quality
Assurance Plan (SQAP) of my project.

1. Purpose
This SQA plan covers the software requirement, design, and implementation
phases of the development of Internet Voting System Manager (IVSM). This
plan does not cover the Cryptix and the Cryptix software that will be used by
my project.

This SQAP provides a foundation for managing the IVSM software quality
assurance activities, and is based on project activities and work products as
documented in the project plan. This SQAP plan:

 Identifies the SQA responsibilities of the project developer and the


SQA consultant
 Defines how to review and audit the development of IVSM system.
 Lists the activities, processes, and work products that the SQA
consultant will review and audit
 Identifies the SQA work products

2. References
 Software Engineering, Roger S. Pressman
 Lecture Notes, CIS541 Software Engineering II, Dr. David Gustafson,
Spring 2001.
 Lecture Notes, CIS740 Advanced Software Engineering, Dr. David
Gustafson, Fall 1999.
 Lecture Notes, CIS748 Software Management, Dr. David Gustafson,
Summer 1998.
 IEEE Standard for Software Test Documentation, IEEE Std 829-1983
 IEEE Standard for Software Quality Assurance Plans, ANSI/IEEE Std
730-1989
 IEEE Guide for Software Quality Assurance Planning, DRAFT,
P730.2/D4
3. Management
Organization:
 The committee consists of Dr. Maria Zamfir-Bleyberg , Dr. William Hsu
and Dr. Gustafson
 Major Professor: Dr. Maria Zamfir-Bleyberg
 Developer: MSE student Yonghua Li.

Tasks:
 Develop the requirement specification, cost estimation for distributed
multiple sequence alignment system.
 Develop the design plan and test plan for distributed multiple sequence
alignment system.
 Implement and test the distributed multiple sequence alignment
system. Deliver the final version along with the documentation.
 On completion of the analysis, design and testing phases, the
developer gives a formal presentation to the committee. The
committee reviews the work performed by the developer and provides
feedback.

Responsibilities
 The developer will perform all software development tasks for internet
voting system manager under the supervision of the major professor.
 The committee will review the work performed by the developer and
provide feedback and advice.

4. Documentation

The following documents will be provided at the end of each phase.

Phase 1: Software Requirement


 Project Overview
 System Diagram
 Project Gantt Chart Timeline
 Cost Analysis
 System Requirements Specification (SRS)

Phase 2: Software Design


 Software Quality Assurance Plan (SQAP)
 Object Model
 Formal Specifications
 Test Plan
 Formal Technical Review (checklist)

Phase 3: Software Implementation


 User Manual
 Testing and Reliable Evaluation
 Project Evaluation

Appendix:
 Source Code

5. Standard, Practices, Conventions, and Metrics

Standards
Document Standards – MSE portfolio
Coding Standards - Java 1.2
Coding Documents - Java Documentation
Test Standards - IEEE Standard for Software Test Documentation

Metrics
LOC - line of code is used to measure the size of the software

6. Review and Audits


There will be three formal presentations prepared by the developer and
evaluated by the committee at the end of each phase (Requirement, Design,
and Implementation). In the preliminary design review at the end of design
phase, the technique adequacy of top-level design will be evaluated. All
documents pertaining to one specific phase will be presented at the review.
The evaluation is subject to be approved by the committee members. All
deficiencies or inconsistency must be rectified by the developer and
resubmitted to the committee members for approval.

7. Test, Tools, Techniques, and Methodologies


A Software Test Plan (STP) will be written to satisfy the software
requirements. The plan will provide management and the testing function with
an overview of the test activities, schedules and resources required to
perform testing. The plan will describe how the testing specifications found in
the following sections will be implemented.

Unit Test:
All code will be unit tested to ensure that the individual unit (class) performs
the required functions and outputs the proper results and data.

Integration Test:
There are two levels of integration testing. One level is the process of testing
a software capability. A second level of integration testing occurs when
sufficient modules have been integrated to demonstrate a scenario.

Java Virtual Machine will be used for this project during the implementation.
For measuring the size of the project, the function points analysis and
COCOMO II were used. The design of the project is object oriented. Rational-
Rose was used for making object diagram.

I will use the Cryptix framework to encrypt the communication between the
server and client.

8. Problem Reporting and Corrective Action


During the whole development process of the project, the developer can
report the problems to his major professor or his committee member. The
major professor or committee member gives their suggestions. In the three
presentations, the major professor or committee member also can ask
questions and give their advice. After presentation, the developer corrects his
mistakes.

9. Code control
N/A

10. Media control


N/A

11. Supplier control


The source code of the Cryptix and the Cryptix frameworks are from their
developer’s website. All these source code are reliable.

12. Records
All the documents of each phase will be posted on my personal website in the
CIS department. At the end of the phase III, the thesis composed of all the
documents of the project will be committed to the CIS department.

13. Training
CIS540 Software Engineering Project
CIS740 Software Engineering
CIS748 Software Management

14. Risk Management


The most important risk is that the Cryptix framework is from third party. We
do not know how well it works. I plan to run this system with boundary testing
cases first, then apply it to general running.

You might also like