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 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
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 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. 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 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 4.4 Documentation SPMP SQAP SRS
To document the agreed deliverables and dates. To document the quality activities 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 WORKING SOFTWARE USER MANUAL
To document how the software will be tested, and record the results. Working software fulfilling all functional and quality requirements
POST MORTEM REPORT
To document the description of Instructions for hands-on users of the software 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
4.6.3
4.6.4
4.6.5
4.6.6
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. 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. 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. 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. 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 notified 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 file 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
