CSC/ECE 517 Fall 2012/ch2a 2w2 ab

From Expertiza_Wiki
Jump to navigation Jump to search

2w2. Waterfall model Describe what the waterfall model is. Describe the activities or steps that the waterfall model consists of. State and argue about the core principle behind using the waterfall model e.g. why it is good and why it is bad. What are the advantages and disadvantages of waterfall model?

The Waterfall Model

The linear sequential process of software development described by Winston W. Royce in 1970 <ref name = WikiRef/> is popularly known as the Waterfall Model of Software Development. Also referred to as the classic life cycle, the linear sequential model presents a systematic approach that is based on progression from one stage to another namely requirement analysis, design, implementation, testing and finally support<ref name = PressmanRef/>. Even after the adaptation of many new methodologies such as prototyping and agile, the classic approach presents a very strong case for scenarios where the requirements are fixed and generally helps in understanding the evolution of software engineering processes. The approach is very similar to one followed in many other engineering disciplines such as manufacturing and construction.


Phases

Analysis and Requirement Gathering

This is the first and foremost phase in the Waterfall model or Linear Sequential Model for Software Development. This phase includes meeting with the customer and gathering all requirements specific to the project. This can be considered as the most important phase of the model, because if there is any misinterpretation during this phase then it can lead to validation issues later. The gathered requirements have to be unambiguous. Gathering the correct requirements is very important so that the customer is satisfied with the final product that is built<ref name = AnalysisRef />. This stage basically deals with gathering both the functional and the non functional requirements of the project. Functional requirements are those requirements which are the actual features for which the project is being made. Non-functional requirements are those implicit requirements that all the projects are expected to have such as Scalability, Maintainability etc<ref name = PressmanRef/>. The Waterfall model works very closely with deliverables. Hence, the deliverables that this stage produces is Software requirement specification(SRS), Acceptance Test Plan and the System Test Plan. After the requirements are collected accurately, we move on to the next phase which is the Design phase.

Design


Designing a software is a process of deriving at the high level solution of the problem that the software aims to solve.The design considers the requirements gathered from in the Requirement analysis phase and build a solution based on the given constraints. The design encompasses the definition of the basic properties of the software solution such as data structures, software architecture, interface representations and algorithmic detail<ref name = PressmanRef/>. All the elements of the solution are described along with the relationship among them<ref name = WikiArRef/>. Software re-use decisions are also taken at this stage. If some components are eligible for reuse they must be described and incorporated in the design. The deliverable of this phase consists of the High Level Design Document (HLD), the Detailed Design Documents (DLD) along with unit test cases and integration tests. The HLD gives an overview of the system and its various components. A separate DLD is made for all such individual components detailing the design considerations for each. Test cases are also written in the design phase so that the verification and validation of the design can be done on the implementation of the solution.


Implementation


This is the third phase in the waterfall model. After we have a thorough design phase, we can go ahead with the implementation phase. In this phase the design is converted into machine readable form. Actual coding is done in this phase and Programs are created. If Design is done sufficiently then implementation can be done with a greater degree of accuracy. In this phase we divide the Software Module into individual units. A unit is a logically separable part of the software. In this phase, along with the code generation part, Unit testing of individual units is also carried out. Unit testing is performed by the developer itself <ref name = ImRef/>, as he is the best person who knows the code and can judge it whether it is meeting the specification or not. The deliverable that we get at the end of this phase is a Unit Tested Code.


Testing


Most of the unit testing is done by the programmers while coding their individual components. In the testing phase, the integration and system testing is carried out. The integration tests focus on the interoperability of the independently developed components of the software. The primary focus is on making sure that they are able to function together<ref name = PressmanRef/>. Once that is done, the system testing is carried out. The test cases and plans are based on the System Requirement Specification (SRS).Here the software is tested against the originally expected requirements and behaviors. Whenever an expectation is not met, a flaw is recorded. System testing includes the validation of the software based on parameters such as usability, security, accessibility and reliability<ref name = SysRef/>. The functional and non-functional requirements must be tested and the focus is on uncovering maximum numbers of errors and bugs before the system is handed over the customer.


Deployment and Support

This is the final phase of the Waterfall model. When we reach this phase, we already have a completely functioning and fully tested system on our hand. What needs to be done in this phase is that we need to install the system on the user’s environment. After it is successfully installed, we need to train the customer on how to use the system.<ref name = PressmanRef/> After the customer is satisfied with the system, we need to take the approval that the project is officially complete and it is meeting all the requirements that were made in the first phase of the model. In terms of deliverable for this phase, we have to generate a user manual for the user which he can refer if he has any problem understanding the system. This phase does not end here. If in future the customer has some problems with the system, then it is the responsibility of the developers to get the system up and running if it is down due to some errors. The errors can be introduced due to many reasons. Some of which can be exceptions in the embedded software, or changes in the external environment in which it was deployed or even if the customer wants some additional features in the system.


Advantages

  • As it is the most basic model for Software Development, it is very simple and easy to use<ref name = PressmanRef/>.
  • It follows a very disciplined approach.
  • It is easily manageable because, every phase is very well defined and each phase has a set of deliverables and a review process.
  • All the phases are completed one at a time and hence there is no confusion.
  • It is the best for smaller projects as the requirements are very well understood.
  • All the phases have a very clearly defined start and end points, thus the progress of the project can be conclusively identified.
  • As importance is given to the Requirement gathering and the Design phase even before writing a single line of code, there is a very low probability of wasting time and effort while coding<ref name = AdvRef/>.
  • As the first two phases end in the production of a formal specification, the waterfall model can aid efficient knowledge transfer when the team members are dispersed in different locations<ref name = AdvRef/>.

Disadvantages

  • Initially the customers are not very clear about the requirements for complex projects. The waterfall model does not have scope for the inclusion of new requirements once requirement phase is over.
  • It is not a very good model for long and ongoing projects.
  • In this model, we do not get the look and feel of the actual system, until very late in the life cycle.
  • High amount of risk and uncertainty is attached with this model.
  • Potential delay in identifying the risks which might lead to disastrous results later in the cycle.
  • Many a times, a feasible looking design on paper may turn out to be expensive or difficult in the implementation phase requiring a redesign and hence destroying the distinction between the different phases.<ref name = AdvRef/>
  • Time to market is very high as compared to other models for software development.
  • The waterfall model does not allow us to go back to a phase after its completion.<ref name = AnalysisRef/>
  • For contemporary projects, it is very difficult to follow a sequential flow in the software development process because of the dynamic nature of the requirements.

References

<references> <ref name = AnalysisRef> http://www.slideshare.net/BHARGAV_VISANI/waterfall-model </ref> <ref name = PressmanRef> Software Engineering, A Practitioner's Approach by Roger S. Pressman</ref> <ref name = WikiRef> http://en.wikipedia.org/wiki/Waterfall_model</ref> <ref name = WikiArRef> http://en.wikipedia.org/wiki/Software_architecture</ref> <ref name = ImRef> http://www.ianswer4u.com/2011/11/waterfall-model.html#axzz2ARy246Eu</ref> <ref name = SysRef> http://en.wikipedia.org/wiki/System_testing</ref> <ref name = AdvRef> http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/6118423</ref>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2a_2w2_ab&oldid=68638"