Software Quality Assurance Plan

1. Introduction

This document explains the Software Quality Assurance Plan (SQAP) for MSE project of Lakshmikanth Ganti.  The project is to develop an application in Java that uses Molecular Dynamics Simulation techniques to simulate the interaction between the atoms in a group of water molecules.

1.1 Purpose

Software Quality Assurance Plan (SQAP) consists of those procedures, techniques and tools used to ensure that a product meets the requirements specified in software requirements specification.

1.2    Scope

The scope of this document is to outline all procedures, techniques and tools to be used for quality assurance of this project.

This plan:

·         Identifies the SQA responsibilities of the project developer and the SQA consultant

·         Lists the activities, processes, and work products that the SQA consultant will review and audit

·         Identifies the SQA work products

1.3    Reference Documents

·         Lecture notes, CIS 748 Software Management, Dr. Scott Deloach, Spring 2002

·         Lecture Notes, CIS 771 Software Specifications, Dr. John Hatcliff, Spring 2001

·         Software Engineering, Roger S. Pressman, 5th Ed.

·         IEEE Guide for Software Quality Assurance Planning, IEEE Std 730.1 – 1995.

·         IEEE Standard for Software Quality Assurance Plans, IEE Std 730 – 1998.

1.4    Overview of the Document

The rest of the document is organized as follows:

Management: A description of each major element of the organization and a description of the SQA tasks and their relationships

Documentation: Identification of the documents related to development, verification, validation, use and maintenance of the software.

SQAP Requirements: This section defines the SQA review, reporting, and auditing procedures used to ensure that software deliverables are developed in accordance with this plan and the project’s requirements.

Training: This section describes the training program for the developer.

 

2          Management

2.1 Organization

This tool is developed as an individual project as part of partial fulfillment of requirements for Masters in Software Engineering degree. Since there is only one member involved, it will be the sole responsibility of the developer to review the product’s usability, efficiency, reliability, and accuracy. The major professor will however conduct inspections, reviews, and walk-through on a regular basis. In addition a committee consisting of the major professor and two other faculty members will review the documents of each phase before every presentation. Major Professor's and the committee’s specifications and suggestions will be used in places where quality decisions need to out-weigh development schedule decisions.

2.2 Roles

·         The committee consists of Dr. Virgil Wallentine, Dr. Paul Smith and Dr.Mitch Nielsen.

·         Major Professor: Dr. Virgil Wallentine

·         Developer: Lakshmikanth Ganti.

2.3 Tasks and Responsibilities

The responsibilities of the developer are as follows:

·         Develop the requirement specification and cost estimation for the project

·         Develop the design plan and test plan for testing the tool

·         Implement and test the application and deliver the application along with the necessary documentation

·         Give a formal presentation to the committee on completion of the analysis, design and testing phases. The committee reviews the developer’s work and provides feedback/suggestions.

·         Planning, coordinating, testing and assessing all aspects of quality issues.

The responsibilities of the committee members are to:

·         Review the work performed by the developer

·         Provide feedback and advice

2.4 SQA Implementation in different phases

Quality assurance will be implemented through all the software life cycles of the tool’s development process, until the release of the software product. The following are the quality assurance tasks for each phase of the software development: 

Requirements phase:  When the SRS is being developed, the developer has to ensure that it elucidates the proposed functionality of the product and to keep refining the SRS until the requirements are clearly stated and understood.

Specification and Design phase: Due to the great importance for accuracy and completeness in these documents, weekly reviews shall be conducted between the developer and the professor to identify any defects and rectify them.

Implementation phase: The developer shall do code reviews when the construction phase of the Tool begins.

Software testing phase: The developer shall test each case. The final product shall be verified with the functionality of the software as specified in the Software Requirements Specification (SRS) for the Tool. 

Through all these phases of the software development, the following shall also be conducted to improve the software quality:

·         Develop and generate SQAP: Generate a finalized SQAP plan

·         Communication and Feedback: The developer is encouraged to freely express disagreements, suggestions and opinions about all aspects of the weekly process of software development.

·         Internal audits and evaluations: The Major professor and the committee are expected to do auditions and evaluations at the end of each phase in the project.

3          Documentation

In addition to this document, the essential documentation will include:

The Software Requirements Specification (SRS), which

·         Prescribes each of the essential requirements (functions, performances, design constraints and attributes) of the software and external interfaces

·         Objectively verifies achievement of each requirement by a prescribed method (e.g. Inspection, analysis, demonstration or test)

·         Facilitates traceability of requirements specification to product delivery.

·         Gives estimates of the cost/effort for developing the product including a project plan.

The Formal Specification Document, which gives the formal description of the product design specified in Object Constraint Language (OCL).

 

The Software Design Description (SDD)

·         Depicts how the software will be structured

·         Describes the components and sub-components of the software design, including various packages and frameworks, if any.

·         Gives an object model that is developed using Rational Rose highlighting the essential classes that would make up the product.

·         Gives a sample interaction diagram, showing the key interactions in the application. This should also be a part of the object model.

 

Software Test Plan: Describes the test cases that will be employed to test the product. 

 

Software User Manual (SUM)

·         Identify the required data and control inputs, input sequences, options, program limitations or other actions.

·         Identify all error messages and describe the associated corrective actions.

·         Describe a method for reporting user-identified errors.

·         Documented Source Code.

 

The following documents will be provided at the end of each phase by the developer:

Phase 1: Objectives

·         Project Overview

·         Requirements Specification

·         Cost analysis

·         Project plan

·         Software quality assurance plan

Phase 2: Architecture

·         Implementation Plan

·         Formal Requirement Specification

·         Architecture design

·         Test plan

Phase 3: Implementation

·         User Manual

·         Assessment Evaluation

·         Project Evaluation

·         References

·         Formal Technical Inspection Letters

Appendix

·         Source code

4          SQA Program Requirements

4.1 Standards

·         Document standards – MSE Portfolio

·         Coding standards – Java 1.4

·         Coding Documents standards – Java Documentation

·         Test Standards – IEEE Standard for software test documentation

4.2    Metrics

·         LOC  - lines of code is used to measure the size of the software

4.3    Software Documentation Audit

Quality Assurance for this project will include at least one review of all current work products in each stage of development (Requirement, Design, and Implementation). The reviews will assure that the established project processes and procedures are being followed effectively, and exposures and risks to the current project plan are identified and addressed.  The review process includes:

·         A formal presentation at the end of each development phase (Requirement, Design and Implementation). All current work products are presented to the committee members for review.

·         A managerial review by the advisor periodically to ensure the work generated is in compliance with project requirements.

·         Reviews by the committee after each presentation.

4.4    Requirements Traceability

The SRS will be used to check off the deliverables. The Project Review will ensure that each of the requirements mentioned in the SRS is met by the deliverables.

4.5    Software Development Process

The software development process involves three stages: 1) Requirements phase, 2) Design phase (this phase also involves the development of the product prototype and 3) Implementation and testing phase. During each phase, the Major Professor and the committee will review the deliverable documents. The developer would incorporate modifications suggested by the committee. This would ensure quality of the software product.

4.6    Project Reviews

The Committee will perform a review at the 3 stages of the project as described in the section above. This review will determine whether the requirements have been met for the deliverable, check that the product meets the requirements, ensure that the SQA plan has been adhered to, verify the performance of the software and ensure that acceptance testing is carried out. In addition the developer will conduct a Formal Technical Review after the design phase. A design checklist will be used and the developer will check to see whether his/her design meets the checklist criteria.

4.7    Testing and Quality Check

Testing will be carried out in accordance with the Software Testing Plan (STP). Testing documentation will be sufficient to demonstrate that testing objectives and software requirements have been met. Test results will be documented and discussed in the final phase of the project.

 

5          Training

The following courses taken by the developer at Kansas State University and Research experience under the guidance of Dr. Virgil Wallentine and Dr. Paul Smith will provide the required training.

·         CIS 540: Software Engineering –1

·         CIS 740: Software Engineering – 2

·         CIS 748: Software Management

·         CIS 771: Software Specification

·         CIS 625: Parallel Programming