SDLC Puts This at the End of the Waterfall Process

¶ … operations, why now at this stage of the course? Why does the SDLC place operations last at the end of the 'waterfall' model of software design?

Why, only now, is there an emphasis on making a potential software system operational at the end of a course in software development -- shouldn't this crucial step come first? Isn't operations 'what it's all about,' the reason that software developers are hired by organizations in the first place? But any potential development system must always be able to walk before it can crawl -- and it must be certain that it is walking in the right direction? In other words, one must mind the steps of the software development Systems Development Life Cycle, to ensure that the software development takes place in a useful as well as technologically feasible fashion for the organization in question.

SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. Notice that there are three steps before implementation of the actual system occurs. If one were to focus on the system's operation first, this would only reinforce a common problem with many once-emerging and eventually discarded software design systems of the past -- they may have worked as systems, but they did not necessarily fit a particular organization's or group of user's stated needs. This is also why investigation as to how a system will be used, what management desires a software system to accomplish, and who will be the systems most likely user is so critical.

Always, investigation is a very crucial aspect of the software development cycle. Any glitch in the design phase could be very expensive when solving the later stage of the software development. Much care must be taken during this phase as the underpinnings of the logical system of the product are developed in this phase, long before actual operations. (Start vb dotnet.com "SDLC," 2004) After the first stage of investigation, one must also engage in analysis as to how best meet these functions through a budget, and design a system that meets these always by trouble-shooting all potential problems along the way, regarding potential faults.

Thus, the software concept must always identify and defines a need for the new system rather than merely assume a new system is always better. What system is needed and can such a system is created? Then comes the requirements analysis, where developers must again analyze the information needs of systems users so to create an architectural design or blueprint for the resultant coding of the new system. Another key aspect is the debugging of potential external or internal flaws to minimize system risks. Only after such appropriate system testing can one evaluates the system's actual functionality in relation to expected or intended functionality when putting the system into operations. (Webopedia, "SDLC," 2004)

Even after all of these steps are performed, inevitably the system will need maintenance. "Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period." (Start vb dotnet.com "SDLC," 2004)