QATP.1.0
28 February 1997

Quality Plan


1.0. Introduction

1.1. Project Description. The purpose of this project is to construct a website for individuals interested in obtaining information on Software Project Management, specifically in the area of Risk Management. This project fulfills the team project requirements for George Mason Universityís Spring 1997 Software Systems Engineering 625 course taught by Professor Richard Bechtold.

1.2. Product Quality. Quality of agreed upon product (tech description)

1.3. Product Deliverables. The following constitutes the list of final product deliverables and associated quality requirements that are due to Professor Bechtold on April 28, 1997. Each deliverable will be submitted in both hard copy (paper) and electronic formats. For the sake of consistency and portability, electronic (delivery) file formats will be ASCII for text documents and TIF for any illustrative figures/graphics.

1.3.1. Compilable HTML and CGI source code that implements basic site and web page functionality;

1.3.2. HTML and CGI executable codes, plus any scripts required to establish site functionality using only the computer resources afforded to a standard GMU student account;

1.3.3. Userís manual, which includes description of user-accessible functions, description of web page organization and content, and web site installation and setup instructions;

1.3.4. Final version of all software project documents and plans;

1.3.4.1. Software Requirement Specifications;

1.3.4.2. Risk Mitigation plan;

1.3.4.3. Project Management plan;

1.3.4.4. Project Management schedule;

1.3.4.5. Quality Assurance/Test plan;

1.3.4.6. Configuration Management plan;

1.3.5. Contents of all web pages when baselined for customer delivery;

1.3.6. Description of the projectís software tool suite used in development, test, quality assurance, and configurtion management activities

1.4. Target Environment. Web site will be developed for installation, operation, and maintenance using the computer resources assigned to a standard GMU student account.

1.4.1. Connection to site will be accomplished through GMU network, using either GMUís Internet gateway or (modem) dial-up capability.

1.4.2. Storage space requirements for site (web page) contents and operating software is limited to 5 MB

1.5. Product Release and Delivery

2.0. Description of project

3.0. Documentation Structure and Production

4.0. Project Organization and Responsibilities

5.0. Codes of practice

6.0. Quality control

6.1. Special checking or design procedures. Not applicable for this project.

6.2. Procedural audits. TBD

6.3. Documentation audits.

6.3.1 Document audits are required when:

6.3.1.1. Final documents for a completed development phase are submitted for CM;

6.3.1.2. Final versions of project documents are delivered to CM for inclusion into the project baseline

6.3.2. All project team members will review documents for format and content (within their area of responsibility) within one week of submission date by originator.

6.3.3. Document any errors and recommended remedial actions IAW paragraph 3.XXX, and submit (electronic) copies to the document originator and QA.

6.3.4. QA will follow up on remedial actions/review reworked document prior to CM submission

6.4. Code inspections

6.5. Document reviews will be accomplished when original or updated project plans/documents listed in paragraph 1.3.4 will be entered into CM;

6.5.1. All project team members will review documents for format and content (within their area of responsibility) within one week of submission date by originator.

6.5.2. Document any errors and recommended remedial actions IAW paragraph 6.6.1, and submit (electronic) copies to the document originator and QA.

6.5.3. QA will follow up on recommended actions during the next review of the document in question.

6.6. Data Collection

6.6.1. Error Detection/Tracking. The following information is required for each error discovered during scheduled review, audit, or test. QA will supply items 6.2.1.1., 6.2.1.8, and 6.2.1.9; the remaining items will be supplied by the individual discovering the error.

6.6.1.1. Error Tracking Number

6.6.1.2. Error Name

6.6.1.3. Error Type

6.6.1.4. Short error description

6.6.1.5. Date error discovered

6.6.1.6. Name of person discovering error

6.6.1.7. Recommended remedial action

6.6.1.8. Date remedial action accomplished/reinspected

6.6.1.9. Date error closed

6.7. Required Quality Metrics

6.8. Required Process/Product data

7.0. Quality Assurance

7.1. Progress Reviews.

7.2. Program Plans and Reports.

7.3. Quality Audits

7.3.1. Audit responsibility

7.3.2. Audit schedule

8.0. Test Approach/Plan. The basic web site environment and its functionality are provided by using commercial off-the-shelf (COTS) software to generate the basic web page and user interfaces, while existing GMU network hardware/software provides two way web page-Internet connectivity. Custom scripts within the COTS software control applications to provide the functionalities outlined in the SRS. Therefore primary emphasis of the test program is to verify that web site connectivity and contents conform to the SRS requirements. The test program will be synchronized to the time-phased delivery of increased web site functionality, and will include regression testing to insure continued correct operation of previously delivered capability. The plan does not call for the specific testing of the COTS software or its capabilities. However, if the web site fails to meet SRS functionality requirements, tests would be conducted to eliminate the COTS software as a potential point of failure. Test plan updates will be made to reflect changes in project requirements.

8.1. Test Items. The test program will evaluate the following capabilities/functions:

8.1.1. Web site connectivity via GMU Network (Internet or dial up modem)

8.1.2. Web page content (information maintained on the MJY site pages)

8.1.2.1. Viewability using 7HTML or equivalent browsers

8.1.2.2. Ability to download information

8.1.3. Links to other sites

8.1.3.1. Number of links in each category

8.1.3.2. Link connectivity (ie, can you connect to specified link)

8.1.3.2. Content of each link site appropriate for each category

8.1.3.3. Content viewability

8.1.3.4. Ability to download web page information (if permitted by that site)

81.4. Site-specific web page (that is,

8.1.4. Chat room

8.1.4.1. Connectivity to chat room from web site

8.1.4.2. Identify room occupants

8.1.4.3. Update room occupant status (enter/depart)

8.1.4.4. Identify conference status (available/in-use)

8.1.4.5. Establish/terminate conference(s)

8.1.4.5. Add/drop conferees from an established conference

8.1.5. Non-functional items. Not applicable

8.2. Test strategy. Tests will be time phased to correspond to incremental delivery schedule. Tests will be conducted using computer equipment that is not physically connected to the GMU main campus network. Test will consist of connecting to the web site, through the GMU main campus network, using Internet or dial up modem lines. Once connected to the web site, each new web page on the MJY site will be checked for viewability (using specified browser) and (if applicable) the ability to download web page information. Each new link will be checked for physical connectivity, appropriateness to its assigned category, readibility, and ability to download the displayed information.

8.3. Pass/fail criteria for items under test

8.3.1.

--- Procedures and faciities to update test plan throughout project

---- what parts are updatable

---- procedures for update of test

---- available test case specifications

---- test deliverables

---- test tasks necessary to prepare and implement test activities

---- test responsibilities

---- test activities scheduling

---- contingency plans



Configuration Management


Software Project Management / Comments? / Back / Last Updated: April 7, 1997