Evaluation of System Development Methodology, Software Prototyping - Coursework Example

Somerville [1996 - Page 7] explains that successful software development, deployment, testing, deployment and maintenance are all built around four basic precepts: software specification, software development, software validation and software evolution.Somerville makes it abundantly clear that any specific methodology is as good as another, which implies that the methodology chosen would be the one that the development team is most comfortable with. That said, he insists it is borne in mind that realistic cost comparisons are not practical and that the whole software development t process is a highly complex one, with many component parts.1. The Waterfall approach.

This is where the requirements specification, design specification, test specification, implementation plan and maintenance plan are all produced in sequence as individual work products, and each is approved by the key stakeholders before the next is produced.2. Evolutionary Development. Here, the specification, development and testing stages are interleaved, beginning with the very rapid development of a prototype system from a very basic specification. This is what is usually meant by Rapid Application Development (RAD).

This prototype is then progressively defined with the aid of input from the intended users to produce a system that meets at least the initial business or scientific requirements of the latter. As an alternative, which will be particularly applicable to application domains such as financial services or online gaming, where close regulation will be expected. In such cases, a more structured approach must be used to produce a more robust and maintainable system. The outstanding problem here is that RAD often results in the poor recording of the development process, leading not only to problems with maintaining and enhancing the system, but also severe problems with regulators!3. Formal Transformation.

This approach is based on producing a system specification in the form of a rigorous mathematical proof, which results (or should result!) in what Somerville [1996 - Page 8] calls ‘correctness preservation’.  The intention is that the customer will be sure that the system meets the agreed specification.