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.

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

  • Save
The Clas­si­cal water­fall model

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.

Leave a Comment

Share via
Copy link
Verified by MonsterInsights