CS 305 Software
Document Version: 1.0.1, Jan. 27, 1998.
Document Maintained by: Darrah Chavey.
This document was modified by Kunal Mittal on Jan 21st. 2000 (to edit links
Changes from Previous Versions: V. 1.0.
Document purpose: This document provides links to the
documents used in this course, the "general course documents",
which define the standards for the course (processes, document
standards, change standards, etc.), and the project documents
(specifications, design, test plans, code, etc.).
General Course Documents:
- The Process Description (sorry link not available) document
describes the overall procedures of how teams function, preparation for the
weekly inspections, course evaluation, etc.
- The Waterfall Model (sorry link not available)document describes,
for the purposes of this course, how the various phases of the software process
are defined, and what is to be achieved at each stage of the process.
- The Document Standards (sorry link not available)specifies
the formats required of the documents throughout the course.
- The Change Control Standards (sorry link not available)specifies
how changes will be made to documents after their initial approval, who is
responsible for the changes, how they are approved, who is informed of them,
Project Specific Documents
For more details on the meanings of the documents below, see the Waterfall
Model document mentioned earlier. For the list of who is on which team, and
who has which responsibilities on these teams, see the Teams
link. Note that the actual team assignments are subject to change in the event
that someone drops the course. The documents that should be produced for our
particular software project are:
- The Requirements Document, which describes
in a general manner the goals and desirable functions of the software program
to be produced. This is written for the eventual user of the product.
- The Specifications Document, which gives
precise details of what the product is supposed to do. This is written for
the programmers who have to implement the program. It specifies the functionality
of the program, but not the interface details.
- The User Interface Specification, which
gives detailed specifics for what the interface should look like and how it
should behave. This includes sample screen shots, etc.
- The Systems Analysis (sorry link not available) document,
which gives a visual description of how data flows through the program components.
- The Architectural Design document, which
gives specifications for the objects in the program, how modules are decomposed,
what methods are needed for each object, and how these objects will achieve
the program functionality required.
- The Module Design documents, a collection of
the interface specifications for each object module in the system. These are
fully usable Java interface documents.
- The Module Testing documents, a collection
of code units used to test each of the modules. These are compilable modules
even in the absence of code from the module implementation phase.
- The Module Code (sorry link not available) document is a collection
of links to the source code for each of the individual modules.
- The User Documentation is the final
documentation for the client who will be using this program.
- The Integration Testing document includes
both the plan for how modules will be combined and tested, i.e. in which order
are they expected to be integrated, and the code units used to test these
module combinations and the combined program.