Classical Waterfall Model in Software Engineering

Definition

The clas­si­cal water­fall mod­el is the basic Soft­ware devel­op­ment life cycle model(SDLC). It was intro­duced by Win­ston Royce in 1970. This mod­el was pop­u­lar in the past, but it is no longer used. But it is very impor­tant to learn because oth­er Soft­ware Devel­op­ment Life Cycle mod­els are based on it.

Subscribe on YouTube

Get free tutorials, exam tips & updates.

Subscribe

Join WhatsApp Channel

Stay updated with instant alerts.

Follow

Free SSC Mock Tests

Boost your preparation with free practice tests.

Start Now

Govt Job Alerts

Get free daily updates on government jobs.

Get Alerts

The Clas­si­cal Water­fall mod­el and Water­fall mod­el are the same. This mod­el is named the “water­fall mod­el” because its dia­gram­mat­ic rep­re­sen­ta­tion resem­bles a cas­cade of waterfalls.

The flow of the clas­si­cal water­fall mod­el is sequen­tial and there is no over­lap between phas­es. Apart from that, we can go for­ward after com­plet­ing the pre­vi­ous phase. Once we com­plete the pre­vi­ous phase we can’t go on that phase Again. We have to go forward.

In sim­ple words, the out­put of the pre­vi­ous phase is the input of the next phase.

The clas­si­cal water­fall mod­el divides the life cycle into the fol­low­ing phas­es. As you can see below

Let’s have look at each phase in brief details

Fea­si­bil­i­ty study: The pur­pose of this phase is to deter­mine whether devel­op­ing the soft­ware is finan­cial­ly and tech­ni­cal­ly feasible.

Ini­tial­ly, the project man­ag­er or team leader tries to get a rough idea of what needs to be done. After that they study dif­fer­ent input and out­put data which is pro­duced by the sys­tem. And they also exam­ine what kind of pro­cess­ing is required on the data. After over­all under­stand­ing then they deter­mine the var­i­ous pos­si­ble strate­gies to solve the prob­lem. And choose the best strate­gies from pos­si­ble strategies.

Require­ments analy­sis and spec­i­fi­ca­tion: The goal of require­ments analy­sis and spec­i­fi­ca­tion is to know the exact require­ment of the client/Customer.

Basi­cal­ly, This phase con­sists of two phases.

1. Require­ments gath­er­ing and analy­sis: The goal of the require­ments gath­er­ing activ­i­ty is to gath­er all rel­e­vant infor­ma­tion about the prod­uct to be devel­oped from the cus­tomer. The require­ment analy­sis is start­ed by col­lect­ing all rel­e­vant data of the project from users and cus­tomers through dis­cus­sion. After all incon­sis­ten­cies, incon­sis­ten­cies, and incom­plete­ness have been resolved and all require­ments have been thor­ough­ly under­stood. The require­ment spec­i­fi­ca­tion can now begin.

2. Require­ment spec­i­fi­ca­tion:  In the require­ment spec­i­fi­ca­tion the user require­ments are sys­tem­at­i­cal­ly orga­nized in a soft­ware require­ment spec­i­fi­ca­tion doc­u­ment(SRS). This doc­u­men­t’s key com­po­nents are func­tion­al require­ments, non-func­tion­al require­ments, and the imple­men­ta­tion goal.

Design: The goal of the design phase is to trans­form the require­ments spec­i­fied in the SRS doc­u­ment into a struc­ture that is appro­pri­ate for imple­men­ta­tion in some pro­gram­ming languages.

Cod­ing and Unit test­ing: The goal of this phase is to con­vert the soft­ware design into source code by using any appro­pri­ate pro­gram­ming lan­guage. After each design mod­ule is cod­ed. We per­form unit test­ing that means we check each and every mod­ule is work­ing prop­er­ly or not.

Inte­gra­tion and Sys­tem test­ing: Inte­gra­tion as the name sug­gests in this phase we inte­grate dif­fer­ent mod­ules which were cod­ed and unit test­ed. In the process of inte­gra­tion and sys­tem test­ing, the mod­ules are inte­grat­ed in a planned man­ner. Final­ly, after all the mod­ules have been suc­cess­ful­ly inte­grat­ed and test­ed, the full work­ing sys­tem is obtained. Then we can per­form Sys­tem testing.

Basi­cal­ly Sys­tem test­ing con­sists of the fol­low­ing type of testing.

• Alpha test­ing: Alpha test­ing is test­ing which is per­formed by the Devel­op­ment team.
• Beta test­ing: Beta test­ing is test­ing which is per­formed by a friend­ly set of customers.
• Accep­tance test­ing: After deliv­er­ing the Software(product) then the cus­tomer per­formed the accep­tance test­ing to deter­mine  whether to accept the deliv­ered software(Product) or to reject it.

Main­te­nance: Main­te­nance is the most impor­tant phase of a soft­ware life cycle. The effort spent on main­te­nance is 60% of the total effort spent to devel­op a full software.

There are basi­cal­ly three types of maintenance :

• Cor­rec­tive Main­te­nance: Cor­rec­tive errors that were not dis­cov­ered dur­ing the prod­uct devel­op­ment phase. 
• Per­fec­tive Main­te­nance: This type of main­te­nance is car­ried out to improv­ing the func­tion­al­i­ties of the sys­tem based on the customer’s request.
• Adap­tive Main­te­nance: Adap­tive main­te­nance is usu­al­ly required for port­ing the soft­ware to work in a new envi­ron­ment such as work on a new com­put­er plat­form or with a new oper­at­ing system.

Advantages of Classical Waterfall Model

• Each phase of devel­op­ment must be com­plet­ed before mov­ing on to the next.
• This mod­el is sim­ple and is easy to understand.
• The mod­el’s stages/phases are clear­ly defined.
• It rein­forces good habits such as define-before-design and design-before-code.
• Suit­able for small­er projects with well-defined requirements.

Disadvantages of Classical Waterfall Model

• No feed­back path
• No over­lap­ping of phases
• It is dif­fi­cult to define all require­ments at the begin­ning of a project
• This mod­el is not suit­able for accom­mo­dat­ing any change
• It does not scale up well to large projects.
• Real projects are rarely sequential.