The waterfall model

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

(i)

The Waterfall Model is a sequential development process in which expansion occurs progressively though a series of phases. The stages involved are; Requirements definition, System and Software Design, Implementation and Unit testing, Integration and System Testing, and Operation and Maintenance.

The Requirements definition stage involves capturing all potential requirements of the systems which need to be developed. This is the stage where the end users needs are established.

The System and Software Design stage involves preparing system designs. The requirements given in the first stage are studied to prepare a system plan. The system designing assists in essential hardware and system requirements.

The next phase is Implementation and Unit Testing; this is where the actual coding starts. The system design is divided into units, and the coding takes place. Each unit is then developed and tested to see how well it functions. This unit testing checks to see whether the units meet the requirements from the first stage.

The Integration and System Testing stage is when the units are integrated into a complete system and tested to see if the units coordinate as one.

The Operations and Maintenance is the final and longest stage. This is when problems within the system, which are not found during the development and testing of the system, are fixed.

There are many disadvantages of the waterfall model when developing the CUSSMOS (City University Safety and Security Monitoring System). The main criticism of the waterfall model is that it is not practical, due to the fact that it doesn't allow you to go back a phase. End users will not always know the requirements for the system before seeing an actual functioning system. They may need to constantly add or remove functions from the system. The waterfall model requires you to create the whole system at once. However, the CUSSMOS system contains six main parts, which is difficult to create at once without making inevitable errors and having to go back a stage in the process.

The Waterfall model is suitable to use for small projects which don't have complex requirements. CUSSMOS is a complex system, it contains subsystems therefore has many requirements which may be subject to change. The waterfall model isn't flexible to deal with changes and therefore an unrealistic model to use. It does not take into account the structure of a system into subsystems. CUSSMOS is divided into large subsystems, which are not considered in this model.

In genuine projects, the development phases should overlap, but the Waterfall model doesn't accommodate for overlapping. The whole model must be completed till the last stage in order to make changes to previous phases, which is time consuming and costly.

CUSSMOS is a large system containing subsystems, the waterfall model assumes that the whole system is designed before anything is implemented and tested which is not the case with a large project like CUSSMOS.

With the Waterfall model, Peter Brown will only see the working system after the coding has been done. Therefore any unforeseen problems and changes will appear once the system has been built; consequently changes will have to been made at the end which will be time consuming.

Unit and System testing may be difficult for the sub system CUSSBASE as it will rely on CUSSARMO and CUSSTARD being implemented and fully tested before CUSSBASE can be tested.

(ii)

Incremental development model delivers software in increments; each increment is a working product and adds to the functionality of the previous increment. It's a scheduling and staging strategy, where various parts of the system are developed at different times.

The incremental development model is where the model is designed, implemented and tested incrementally. It allows the system to be developed and maintained when required.

An advantage of the incremental model to CUSSMOS is that a subsystem can be delivered to the end user once it is complete. This allows the end user to test it amongst a sample of staff and students, and if needed the subsystem can be debugged. For example, when the CUSSCard subsystem is developed, the end user can experiment with delivered increment to see if it's feasible, it doesn't have to rely on the whole system being developed. This model will save time as the system can be thoroughly tested in increments instead of as a whole.

Another advantage of this model for CUSSMOS is that the subsystems can be gradually introduced instead of the introduction of a completely new system all at once which can be difficult to put into practice. Peter Brown can introduce the CUSSCard and CUSSENSE subsystems and then introduce the others once they are developed.

The incremental model it structured wisely as it allows requirements to be added. It has a more manageable process in terms of allowing changes to be made during the development stage, and allowing subsystems to be tested while other increments are still being developed.