In its simplest form, an SDLC divides the software development process
into a number of clearly defined phases, each of which is further divided into steps. Progress through the steps is measured by the completion of forms and checklists. Because the phases were viewed as sequential steps, with the output from one phase becoming the input to the next, a traditional SDLC was often called “a waterfall.” And, like water flowing over a precipice, the underlying premise of the waterfall approach to system development was that all motion was forward.

Once a phase was completed, there was no returning to it.
Although a number of industry experts and major consulting firms
developed their own versions of the methodology, each with forms for every step of the process, there were many common elements. The forms varied; the philosophy did not. Use of an SDLC, the proponents claimed, would ensure that system development followed a common, sequential process with all critical information being properly documented.

1. The explicit guidelines allow the use of less-experienced staff forsystem development, as all steps are clearly outlined. Even juniorstaff members who have never managed a project can follow the“recipes” in the SDLC “cookbook” to produce adequate systems.Reliance on individual expertise is reduced. Use of an SDLC canhave the added benefit of providing training for junior staff, againbecause the sequence of steps and the tasks to be performed ineach step are clearly defined.
   
   
2. The methodology promotes consistency among projects, which canreduce the cost of ongoing support and allow staff to be transferredfrom one project to another. Although coding techniques are notspecified in a typical SDLC, the extensive documentation that isan inherent part of most methodologies simplifies ongoing maintenanceby reducing reliance on the original developers for explanationsof why the system was constructed as it was and whichfunctions are included in which program modules.

1. If followed slavishly, it can result in the generation of unnecessary documents. Many methodologies have forms for every possible scenario. Inexperienced staff may believe that all are required and may, for example, insist on three levels of customer sign-off when only one is needed. This can have the effect of complicating the process and extending the project schedule unnecessarily. To prevent this from occurring, most organizations view an SDLC as a set of guidelines and use only the steps and forms that apply to the specific size and type of project under development. Many even provide templates for their staff, outlining which steps are required for specific types and sizes of projects. An 18-month mainframe development project might require different processes than a two-week Web front end.
   
   
2.  It is difficult for the customer to identify all requirements early inthe project; however, the sequential “river of no return” approachdictates this. The philosophy of the SDLC means that there are noeasy ways to mitigate this problem and still remain true to themethodology.
   
   
3. The customer is involved only periodically, rather than being anactive participant throughout the project. This can result in misunderstandingson both sides: IT and the customer.
   
   
4. As a corollary to the previous two points, the waterfall approachis usually applied to large projects with long development cycles.The combination of incomplete specifications, infrequent communication,and long elapsed time increases the probability that thesystem will be “off track” when it is finally delivered. As highwayengineers know, an error of only a few degrees, if left uncorrectedfor thousands of miles, will result in the road going to the wrongdestination.
   
   
5. Similarly, the long development cycle increases the possibility thatby the time the system is delivered, business changes may haveinvalidated the initial design or that the project champions mayhave left the company or been reassigned, taking with them theimpetus for the project.