This diagram shows the deliverables that are due by each major party at the end of each development phase. Note that some of the phases that I'd defined earlier actually overlap in this document. That's because you want to get the Test Team involved as early as possible in the process, and want to keep everybody on the team busy. An assumption is also made here that the contracting team is made up of more than one person, at least one of which is a senior analyst who can design a detailed system implementation plan while the programmers do the coding.
Once a Functional System Design (FSD) is done, the QA team should be called in (preferably upon delivery of the FSD). They can use the information in the DFD and ERD diagrams to create a high-level test strategy, which is fleshed out into more detailed test plans upon the delivery of the System Technical Design (TSD). By the time the program is coded, all of the test scripts have been prepared.
Another note on concurrency: Understand that once the client has approved an FSD, the approval of the TSD is often a formality. Therefore, as each Module Design is completed, the work can be handed off to the programmers on the assumption that only minor changes to the design will be subsequently required, and the re-work will be quickly accomplished. This approach can shave literally months off of a development schedule. Ideally, the completion of the actual programming may lag the approval of the TSD by only a few weeks, the gain in time being used to provide additional unit testing or technical support to the Test Team. The bulk of the programming team may be moved to other projects at this time.
How it Works Glossary