The table of contents of this SQAP follow that of IEEE standard 730-1989.
Change History
Last modified on 03/01/2002 by Kamil Baranowski //changes made to reflect 206
This document describes the plan by which Lucky Strike Software will monitor the quality of the Sokoban software product to be developed and maintained.
See section 4.2
Lucky Strike Software will designate an individual "quality assurance leader," named in section 3.3.
QA tasks during CPE 206 include:
These tasks are detailed in this document. Note that testing is emphasized in CSc 206.
Each team member is responsible for the quality of his or her work. Each person should be sure their work conforms to the QA criteria provided on the course web page.
It is the quality assurance leader's responsibility to see to it that the tasks in 3.2 are done, and to ensure that the prescriptions in this document are followed, including scheduling the reviews specified. The QA leader is ultimately responsible for the quality of the deliverables.
The Quality Assurance leader for Lucky Strike Software is Kamil Baranowski.
All the documentation required for this project is described in the project plan (SPMP).
This section describes the standards, practices, conventions and metrics to be used for the CPE 206 project. These are intended not only to ensure quality for CPE 206 project, but also to obtain quantitative metric data on the SQA process itself. This data is to be used to help establish the key practices of a CMM level four organization.
Standards:
Practices:
1. Because delaying quality is expensive, engineers are strongly encouraged to apply quality precepts while they work, rather than as an afterthought. "If you don't have time to do it right in the first place, when are you going to find time to fix it after it breaks?"
2. QA is an important function in CPE 205 as part of the student course grade depends on the quality of the project deliverables. A cooperative, team-oriented attitude is crucial.
3. Even though the QA person is ultimately responsible for quality, the QA person is NOT expected to edit and rework every artifact that he receives. Each individual must produce quality work. The QA job is to assure that the product has achieved the required level of quality before it is delivered.
Conventions:
All written work will be evaluated
by the instructor using the Cal Poly WPE scoring guide.
Metrics:
Lucky Strike Software will gather the following metrics. The QA person is responsible for compiling and reporting them, but each person is responsible for gathering their own metrics.
Actual Lines of Code.
Actual Hours of effort (Summary of Individual hours, categorized by project
phase, as gathered from status reports during CPE 206. Also team total by
phase.)
|
Name |
Implementation / Integration Phase |
Test Phase |
Total |
|
Antony |
9.0 hrs |
19.0 hrs |
28.0 hrs |
|
Josh |
57.5 hrs |
16.0 hrs |
73.5 hrs |
|
Kamil |
10.5 hrs |
11.5 hrs |
22.0 hrs |
|
Kevin |
27.5 hrs |
0 hrs |
27.5 hrs |
|
Sean |
7.0 hrs |
19.5 hrs |
26.5 hrs |
|
Team Total |
111.5 hrs |
66.0 hrs |
177.5 hrs |
Number of issues reported from formal reviews: 14
Number of compile defects: 54
Number of test defects: 0
System Defects: 32
Integration Defects: 5
CPE 206 quality goals for delivered products are as follows.
Detected in final project submission:
· Requirements: no more than one minor defective detailed requirement per 100 requirements.
· Design: no more than one minor defect per five diagrams;
· Pseudocode: no more than two minor defects per thousand lines [Note: pseudocode is described in chapter 6]
· Code: no more than two minor defects per KLOC (thousand lines of non-commented code)
· The actual metric data from this project are to be reported in the final project submission.
The purpose of demos and reviews is to provide a means of focusing the attention of engineers on quality of the application as it develops.
Refer to the SPMP for the schedule of reviews and demos listed below.
User Interface Prototype
High Level Design
Software D-requirements
Detailed Design
Software C-requirements (emphasis on UI prototype)
Stage 1 Implementation
Stage 2 Implementation
Stage 3 Implementation
All artifacts in the project will undergo internal review.
The team will conduct a post-mortem review at the end of CPE 206 to gather the insights and lessons learned during the course.
Will be discussed at a later time.
SQA techniques include the application of standards, requirements tracing, FTR's and the verification of formal methods. The SQA tools consist of form templates and checklists. Form Templates are provided on the course web site. QA Criteria Checklists are provided on the course web site. In addition, the Braude textbook contains several checklists in the form of "One way to ..." figures. These checklists involve meeting and inspection procedures, for example.
Software requirements will be traced into Design and Code as described by Braude in section 3.1.
Source code control is a separate procedure that can be referenced through the MBS website.
http://latte.calpoly.edu/~kbaranow/cvs.html
The SQA records collected and archived shall include ...
The only SQA training planned is class lectures. If additional training seems necessary, describe it here.
SQA team members are encouraged to identify risks as early
as possible. The procedures for risk management are specified in section 3.3 of
the SPMP.