Software Quality Assurance Plan
The table of contents of this SQAP follow that of IEEE standard 730-1989.
1. Purpose
This document describes the plan by which the CPE 308 project
will
produce a quality product.
2. Referenced documents
Project
Plan
3. Management
3.1 Organization
The team will designate an individual "quality assurance leader," named
in section 3.3.
3.2 Tasks
QA tasks during CPE 308 shall include
- informal, internal QA reviews
- formal
technical review meetings,
- requirements traceability
- verification (including testing),
- metrics collection and analysis
These tasks are detailed in this document. Note that testing is
emphasized
in CSC 206.
3.3 Responsibilities
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 team (insert
name
here) _ is (insert name
here)
.
4. Documentation
All the documentation required for this project is described in the
project
plan (SPMP).
5. Standards, practices, conventions and metrics
5.1 Purpose
This section describes the standards, practices, conventions and
metrics
to be used for the CPE 308 project. These are intended not only to
ensure
quality for CPE 308 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.
5.2 Standards
- The IEEE standards, with appropriate modifications, are to be
used for
documentation. In most cases teams should follow the templates
Dr.
Dalbey has prepared for major documents. Refer to the
Deliverables
list and the Team Management Resources.
- A Data Dictionary format
is prescribed.
- UML notation is recommended for class diagrams.
- Class Headers must follow javadoc standard.
- Detailed Designs must follow the class pseudocode standard.
- Java source code must adhere to the class coding standard.
- E-mail message "subject lines" must follow the guidelines in the
project
plan.
- A recommended Team Home Page template is provided.
5.3 Practices
- 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?"
- QA is an important function in CPE 308 as part of the student
course
grade
depends on the quality of the project deliverables. A
cooperative,
team-oriented attitude is crucial.
- Even though the QA person is ultimately responsible for quality,
the QA
person is NOT expected to edit and rework every artifact that s/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.
- Each deliverable has an associated QA checklist. It is the
QA person's responsibility to complete the checklist for each
deliverable before it is submitted. The QA person signs the
checklist to indicate their approval and certification that the item is
ready for delivery.
5.4 Conventions
- HTML is the preferred format for written documents.
- Guidelines for all written work are given in the syllabus.
5.5 Metrics
The team 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.
- Productivity Metrics (Size and Cost)
Actual Lines of Code. Use Dr. Dalbey's
Lines of Code Counter. Categorize by individual and team
total.
Actual Hours of effort (Summary of Individual hours, categorized by
project phase, as gathered from timecards. Also team total by phase.)
For
example:
| Name |
Analysis Phase |
Design Phase |
Implementation
Phase |
Total |
| Sue |
55.25 |
47.75 |
10.5 |
113.5 |
| Tom |
63.50 |
54.25 |
11.0 |
128.75 |
| Bill |
50.25 |
56.25 |
9.0 |
115.5 |
| Team Total |
179.00 |
158.25 |
20.5 |
357.75 |
- Quality Metrics
Number of issues reported from each formal review, categorized: severe,
minor, trivial.
Number of requirements defects reported by customer (SRS and UI
prototype).
Number of compile defects (by phase).
Number of defects in high level design deliverable reported by
instructor (diagrams and class skeletons).
Number of defects in detailed design (pseudocode) deliverable reported
by
instructor.
Number of test defects.
5.6 Goals
CPE 308 quality goals for delivered products are as follows.
[Note to the student: The quality targets used here are
based on historical data obtained from previous student teams on
similar projects. Based on previous team data, these targets are
aggressive but not unrealistic.]
- Formal Reviews: no more than three severe and five minor issues
per review.
- Requirements: no more than six defective requirements per
100 requirements.
- Design: no more than three defects per diagram.
- Design: no more than three defects per class skeleton.
- Pseudocode: no more than three defects per class.
- Compile: no more than fifty defects per KLOC (thousand lines of
code).
- Test: no more than fifty defects per KLOC (thousand lines of
code).
The actual metric data from this project
are to be reported in the final project submission.
6. Demos and Reviews
6.1 Purpose
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.
- Internal Reviews are a peer review by the QA leader or
another team
member of individual work products. Here is a recommended QA submittal
form. Each QA leader needs
to create and write the details of the procedure for internal reviews
for his/her team.
- Formal Technical Reviews (FTR)carry this out in a
scheduled,
formal,
and thorough manner with one other team. It is the QA leader's job to
make arrangements with another team. The FTR meeting must occur
during scheduled lab time. Refer to the FTR
procedures to see some guidelines for carrying out your FTR.
- Class Demos are an informal review carried out in front
of
the
entire class.
- Customer Demos are a formal presentation for approval of
the
customer.
6.2 Minimum requirements
Refer to the SPMP for the schedule of reviews and demos listed below.
The
instructor will assist in assigning teams to review each other.
Each
team needs to arrange a time with their reviewing team. The lab hour is
a time reserved when everyone can meet, so walkthroughs and FTR's
should
be carried out during lab.
6.2.1 Class Demos
User Interface Prototype
High Level Design
6.2.2 Walkthrough or Formal Technical Reviews
Software Requirements Specification
(Optional for Fall 2003)
Software Design
6.2.3 Customer Demos
UI prototype
Feasibility prototype
6.2.4 Internal Reviews
All artifacts in the project will undergo internal review.
6.2.5 Post mortem review
The team will conduct a post-mortem review at the end of CPE 308 to
gather
the insights and lessons learned during the course.
7. Test
Not required for CPE 308 Fall 2003.
Testing is a course topic in CSC 206. Therefore, only simple black box
testing will be performed in CPE 308. A test plan with test
specifications
will be written. Testing will be carried out by
developers in conjunction with Implementation and a Test Analysis
report
will be prepared.
8. Problem reporting & corrective action
Problem Reporting is a course topic in CSC 206. No formal problem
reporting
is required in CPE 308. If teams develop any problem reporting
procedures,
they should be described here.
9. Tools, techniques and methodologies
SQA techniques include the application of standards,
requirements
tracing, FTR's and software verification (testing).
The SQA tools consist of form templates and checklists.
- Form Templates are provided on the course web site.
- QA Criteria Checklists for each major deliverable are provided in
the deliverables
list.
9.1 Requirements Tracing
Each requirement in the specification is traced
to each module(s) in design and code that implements it. For CPE
308, create a table listing all the requirements (or numbers) on one
side and the corresponding module in the design along the other axis.
Reference: McConnell page 151.
10. Code control
Source code control is a course topic in CSC 206. No formal source code
control is required in CPE 308. If teams develop their own code control
procedures, they should be described here.
13. Records collection, maintenance &
retention
The SQA records collected and archived shall include ...
- Internal Review Forms
- FTR Review Summary Reports
- signed-off checklists for deliverables
- all anonymous feedback received
14. Training
The only SQA training planned is class lectures. If additional training
seems necessary, describe it here.
15. Risk Management
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.
Change History
Date
|
Author
|
Description
|
10/9/03
|
JD
|
Minor revisions for Fall 2003
|
Home