Summary

10.7 Summary

Software documentation is composed of management, development, test, and user documentation. It is intended to follow the evolution of the software as it progress through the SLC. Each SDLC phase has a product or products, which are the statements of the increasingly complete solution for the user's needs as development proceeds.

Documentation is like the markers along a highway. Looking ahead, it provides a trail to follow toward the destination. Looking back, it provides a record of the trip thus far. Each phase of the SDLC prepares the directions for the next phase in the form of some sort of documentation. These same documents are the record of what has happened during the phase itself.

The SDP is the document that lays out the management approach to the software project. In its most basic form, it will include the schedule and resource needs for the project. The methods, requirements levied on the producers, contracted requirements, and tools to be used for software CM should be defined and explained.

The SQSP addresses the activities to be performed on the project in support of the quest for quality software. All activities to be accomplished in the software quality area should receive the same personnel, resource, and schedule discussion as in the overall SDP. Whatever the format of the SQSP, it is very important that this document (or its information if in another document) be complete and approved by management and the developers.

The requirements document is the keystone of all software documentation. Preliminary and detailed design documents depict how each requirement will be approached and satisfied by the software. The preliminary design provides the initial breakdown of the requirements into functional groups for further design efforts. The detailed design is often called the build-to specification. It is the input to the programming staff for translation into the compiler language for implementation on the target computer. The final version of the detailed design is sometimes called the as-built document, since it describes the software as it actually was delivered.

Test documentation includes all test program documents from the overall test plan through the final test report.

User documentation tells the user how to make use of the software system. The user documentation may include the operators' instructions as well as strictly user-oriented information.

The larger the system, the more documentation is appropriate. Database design and interface design documents may be needed. Maintenance and training may deserve separate and extensive treatment. Finally, there may be a need for a separate operations manual.