The design is documented in a System Architecture Specification (SAS). In addition to the architecture design, this document details public-member definition of all objects; the development environment, including tool list and installation instructions; design notes; diagnostics for quality assurance procedures; and performance monitoring. The SAS and SRD documents are the only two documents that need to be maintained throughout the product lifecycle. It is the go-to document for a maintenance programmer.
Design documents are notorious for being out of date with the actual implementation. This is avoided by using the SAS for a high-level view of the design, which includes the architecture and a description of each object. Detailed designs of complex individual objects and sequence diagrams for object identification should be documented separately. Designers then can discard these documents after peer reviews and implementation are complete.
The architecture also should include a state diagram that details a brief description of operations visible to the user, including each associated object. When multiple programmers are involved with object assignments, create public members for the object interfaces for use by other team members.
The software baseline (or system services) portion of the application architecture and an object diagram should be the focus of the first SAS iteration. This design provides the software skeleton from which all object modules will derive services and execution. As changes to the SAS occur, each use-case-driven iteration starts with additions and modifications to the SAS document.
Implementation encompasses coding, unit testing, and test-case definition activities. As each iteration passes through the implementation phase, only code each object to support the current iteration. In this way, the designer can develop the use-case iterations and object refactoring as needed and keep complexity to a minimum.
During the test-case phase, developers should map each test case to the SRD use-case scenarios. Because the group may have to develop several test cases per iteration, it is critical that the test-case definitions be generated from analysis of the SRD use-case scenarios and the coding implementation. This has to be done during the implementation of the objects while all facets of the objects function are in the minds of the developers. Additional support or hooks may have to be added to appropriate modules and/or software baseline to support the execution of the use cases. At the end of the implementation phase, the complete test case portfolio forms the basis of the regression test used in test and verification.