Title Page

Document Name: initial level business web based generalized accountancy system Software
Quality Assurance Plan (SQAP)
Publication Date: may 2014
Revision Date:
Contract Number:
Project Number:
Prepared by:
Approval: __________________________
Table of contents
List of Tables
1. OVERVIEW
1.1. Scope
2. REFERENCES
3. DEFINITIONS AND ACRONYMS
3.1. Definitions
3.2. Acronyms
4. SOFTWARE QUALITY ASSURANCE PLAN
4.1. Purpose
4.2. Reference documents
4.3. Management
4.4. Documentation
4.5. Standards, practices, conventions, and metrics
4.6. Review and audits
4.7. Test
4.8. Problem reporting and corrective action
4.9. Tools, techniques, and methodologies
4.10. Code control
4.11. Media control
4.12. Supplies control
4.13. Records collection, maintenance, and retention
4.14. Training
4.15. Risk management
ADDITIONAL MATERIAL










1. OVERVIEW

1.1 Scope
The use of this plan will help assure the following: (1) That software development, evaluation and
acceptance standards are developed, documented and followed. (2) That the results of software
quality reviews and audits will be given to appropriate management. This provides feedback as to
how well the development effort is conforming to various IEEE development standards. (3) That test
results adhere to acceptance standards.
2 Refrences

3 DEFINITIONS AND ACRONYMS
3.1 Definitions & Acronyms
IEEE Institute of Electrical and Electronics Engineers
SQAP software quality assurance plan
LOC line of code
SQA software quality assurance
SPM software project management
SQM software quality managment
4 SOFTWARE QUALITY ASSURANCE PLAN
4.1 Purpose
The purpose of this Software Quality Assurance Plan (SQAP) is to define the techniques,
procedures, and methodologies that will be used at the university by students for their final
year projects to assure timely delivery of the software that meets specified requirements
within project resources.
4.2 Refrence document

4.3 Management
4.3.1 Organization
This software is developed as a project as part of partial fulfillment
of requirements for BS in Software Engineering degree. Since there is only two
member involved, it will be the responsibility of the developer to review the
products 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 committees specifications and suggestions will be used in places
where quality decisions need to out-weigh development schedule decisions.
4.3.2 Roles
The committee consists of
Major Professor: Kaleem Shb
Developer: Nouman arshad and khizar abbas
4.3.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 software

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
developers 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
4.4 Documentation
SPMP To document the agreed deliverables and dates.
SQAP To document the quality activities
SRS To document the agreed requirements with the project supervisor; to
provide the basis for design; to provide the basis for system test.
SDD To document the design and design decisions in order to provide the basis
for implementation and unit test
STD To document how the software will be tested, and record the results.
WORKING
SOFTWARE
Working software fulfilling all functional and quality requirements
USER MANUAL To document the description of Instructions for hands-on users of the
software
POST MORTEM
REPORT
To describe the Individual Reflections on Degree Project

4.5 Standards, practices, conventions, and metrics
Document standards IEEE Portfolio

Coding standards .Net framework 4.5

Coding Documents standards .Net Documentation

Test Standards IEEE Standard for software test documentation

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

4.6 Review and audits
4.6.1 SQA Program Audits
This plans will specify that the evidence of work generated is adequate to
ensure compliance with project and requirements. Audits performed
shall include examination of both internal and external software
deliverables.


4.6.2 Scheduled Audits
SQA will generate and maintain an Audit Schedule. Audits will occur at
the end of each development phase as indicated . The results of audits
will be discussed with the individual most responsible for the production
of the deliverable.
4.6.3 Unscheduled Audits
SQA will perform random and unannounced audits to ensure the
corrective actions agreed to during the Scheduled Audits are being
followed. The results of audits will be discussed with the individual most
responsible for the production of the deliverable.
4.6.4 Audit Reports
Audit reports, and recommended corrective actions generated by SQA
will be brought to the attention of the individual most responsible for
producing the software deliverable. Corrective action will be
recommended and reviewed with the individual and SPM.
4.6.5 Project reviews
Formal Reviews
At least one week prior to delivery of documents to heads for a formal
review, SQA will review the Document List .This list identifies all the
documents and revision that will be submitted for the formal review.
SQA will review software related documents identified on this list to
ensure that the indicated revision is or will be available in time.
4.6.6 Informal Reviews
Design Walk-throughs
The SPM will ensure that a verifiable process is used to identify all
action items generated during this review process. SQA will audit this
process to ensure that all action items have been addressed.
Quality Reviews
These reviews will be conducted by SQA(teacher) prior to any baseline
release of executable code. This review ensures that:
(1) the code has been tested and meets module specifications, except as
noted
(2) that any changes to applicable software module design documents
have been identified
(3) that appropriate validation tests have been run
(4) that tool and techniques used to produce and validate the Software
Sub-System are identified and controlled.


4.7 Test
4.7.1 Software Testing
A Software Test Plan (STP) will be written to satisfy the requirements
found in the Detailed Description of the Software Development Process
for Software Requirements Phase .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.
4.7.2 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.
Unit testing is typically white box testing and may require the use of
software stubs and symbolic debuggers. This testing helps ensure proper
operation of a module because tests are generated with knowledge of the
internal workings of the module.
4.7.3 Integration Test
There are two levels of integration testing. One level is the process of
testing a software capability e.g. being able to send a message . During
this level, each module is treated as a black box, while conflicts between
functions or classes and between software and appropriate hardware are
resolved. A second level of integration testing occurs when sufficient
modules have been integrated to demonstrate a scenario e.g. the ability to
queue and receive commands.
4.7.4 System Testing
System testing begins when software has been integrated .The purpose of
system testing is to identify the operational envelope of the project. SPM
will ensure that the results of the stress tests are addressed where the
results show that the operating envelope does not meet requirements
identified in the Software Test Requirements Document .
4.7.5 Validation Testing
Validation testing begins when software has been integrated that enables
validation of the requirements identified in the Software Validation Test
Specification and System Acceptance Test Specification. The purpose of
validation testing is to ensure that the software system meets the
interface requirements allocated to software as identified by the
requirements Traceability method.
4.8 Problem reporting and corrective action
Document problems:
Non compliance with other project documents.
Non compliance with the ESA standard
Incompleteness.
Errors.
Code problems:
Lack of functionality.
Wrong functionality.
Non compliance with coding or commentary standards.
These are the procedures to be followed when a problem is detected:
Problem reporting procedure:
When a problem is detected, the person who discovered the error is responsible for
reporting it to the PM and QAM. When a problem is discovered during a review, the
member of the SQA team present is responsible.
Problem solving procedure
The SQA team appoints the team leader of the corresponding CI team to solve the all
reported error. He is then responsible for solving the problem.
When the problem is solved the SQA team is notied to check whether the made
changes solve the problem.
When the problem cannot be solved, or cannot be solved within a reasonable
amount of time a meeting is set up with the PM, the QAM and the team leader of the
responsible team. During this meeting a decision will be made about further dealing
with the problem.
4.9 Tools, techniques, and methodologies
Visual studio 2012
c# and asp.net using jquery , sql and ajax.
Waterfall model
Sql server 2008r2
4.10 Code control
Documents are available to all people who are authorized to access them and to no one
else.
All versions of a document are available.
No le is unnecessarily locked.
Name conventions are consequentially used.
4.11 Media control
The SQA team checks if the procedures and standards as described are handled properly.
This is done in reviews and random checks .Problems are reported to the developers
back
4.12 Supplies control
The software tools that will be used for development of the program code (such
as Visual studio 2010-12 etc.) are available to all project members
All external software components in the program code, that have an unreliable
source, will be tested according to the [ESA] standards

4.13 Records collection, maintenance, and retention
Minutes of meetings are added after the members of the meeting255 have
approved them.
Minutes are delivered 3 workdays after the meeting at the latest
These documents will be kept throughout the duration of this project.
4.14 Training
The following courses taken by the developer at gc University and Research experience
under the guidance of professors


Software Engineering 1

Software Engineering 2

Software Management

Software Specification


4.15 Risk management
Budget may over runs
Time may over runs
Complexity management is done
Verification risks
Validation risks
Risk management is done by making a risk management strategy, all the
diliverables are delivered on time and done with in limits constraints so that
project may not overruns time and budget.complexcity is managed by
providing easy and simple interface of account boc to the user.


5 ADDITIONAL MATERIAL