The SPAMEX system. :: Computer Science

The SPAMEX system. 1. Introduction The SPAMEX system proposed by SCABB is outlined in the attached letter. I hope to suggest a suitable software process model for the development of the SPAMEX system in the following document. 2. The 'Waterfall' Model The waterfall model consists of several stages of the development life-cycle, each of which are completed in turn. The first stage in applying this model to the development of the SPAMEX system would be to document the system concept and identify the system requirements. After analysing these requirements, one would break the system into pieces, for example; TIP user interface, customer database etc. Each of these components (or subsystems) now require detailed design before the coding can take place. After each of the components has been tested and debugged individually, they can be integrated to form part of the whole SPAMEX system. The system as a whole can now be tested and deployed although requiring ongoing maintenance. The waterfall model was the first of its kind and is still widely used. It allows documented evidence of progress as each stage must be approved and 'signed off' before the next stage is undertaken. This should appeal to SCABB since they have access to these documents and can track the progress of the development of their software. It would also benefit the project manager, who would be able to ensure consistency in the quality of the software and manage accordingly his investments in time and money. The model also allows the various stages of the development to be overlapped in accordance with the wishes of SCABB. This is particularly useful in this case as the current brief presented by SCABB is not to the detail required by the developer. Further meetings between both parties would be essential and ongoing changes in requirements will be inevitable. However, such iterations are not possible without significant investments in time and money from both the developer and SCABB. As we can see, one of the main characteristics of the waterfall model is that commitments be made for each stage early on and each one must be completed and 'signed off' before the next is undertaken. Many problems may arise from this when applied to the SPAMEX system. For example, instability and other coding problems may not be discovered until the testing of the whole system. In such cases re-design may be required, which is very problematic because from the very beginning, this model assumes feasibility before implementation. The waterfall model works well when requirements are stable and well defined, the present SPAMEX brief is somewhat vague and specific details may only be attained through extensive client-developer interaction.