The Software Quality Assurance Plan

1. Identify project objectives for this quarter based upon what is attainable and what is fundamental to the progress of the project. Use the requirements document to make these determinations.

2. • The QA group begins work on a System Test Plan.

   • The Applications group starts the high level design.
     The focus is on module identification, definition and interface issues.
     Where appropriate they will enlist the abilities of the other groups in the project. All groups work with the common goal of producing a design document.

3. A Peer Reviews take place on the Test Plan and the High Level Design.

4. • The QA group produces an Integration plan from the High Level Design.

   • The Applications group completes the design by doing a Low Level Design.

5. Peer Reviews then take place on the Design Document and the Integration Plan.

6. Prototyping takes place.
   • Requirements specification

   • Test Plan written

   • Test Plan PTR

   • Design

   • Design PTR

   • Coding

   • Coding PTR

   • Testing

   • Demo and Evaluation

7. Integration will be bottom up and will at this point be implemented.

8. Evaluation then takes place and the spiral continues.

Software Requirements Specification (SRS)

Distributed Network Manager Specification

• Document Overview
  • System Description

  • Operational Concept. This is an updated version of the description of how the customer will use your software contained in the proposal.

  • References. Include links to the SPP or Proposal, the SQA Plan, and the Configuration Management Plan. Include any other references or resources required for your project.
  Once a draft is available, analysis and description of the system is to proceed. The outcome of this labor is first a high level design and then a low level design.

  Software Design Document (SDD)

  The SDD translates the requirements from the SRS into the architectural and procedural detail necessary for implementation. Here is an outline of the SDD:
  • System Description. This section describes the overall system functions.
    • Major Software Functions. Describe, at a high level, the first level decomposition of the systems purpose.

    • System Constraints. Describe the factors in your development environment or customer requirements that limit your options in this development.

    • References. Include links to the SRS, or other documents that contain information that you referenced to come up with your design.

  • Architectural Design.

    • Data Flow Overview.

      Include an overview of the data flow diagrams (DFDs). This is a focus on data transformation.

    • Structure Chart.

      Show the structure chart resulting from your factoring of the DFD. How is your program broken down.

    • Interfaces.

      Show the package specifications for each of your modules. (A module is your ".h" file) Write a description of the general purpose of the the functions in the file. For each function write a description, and the purpose of the variables.

  • Procedural Design.
    • Include processing narratives for each function. Answer the question "What is expected from this function?"
      This is just an expansion, if possible, of the description given in the interface.

  • File Structures.
    • Include a description of each file, the access method used and a description of the logical records in the file. List the functions that reference these files.

  • Requirements Cross-Reference Matrix
    • Reference in a table what the design item is and where it came from in earlier documents.

    Design Item	Requirements Spec	Some other documents
    1.3 User Interface Style	1.2	----
    2.3 Config File	3.2	----

    This way we can track where requirements are coming from and how they are being implemented.

  Software Test Plan (STP)