Towards a Higher-Level Systems Development Life Cycle, with Universal Applications
William B. Moore, Ernest Nolan, Sharlett Gillard · 2006
The planning phase that precedes the traditional Systems Development Life Cycle (SDLC) is often ambiguous. It could be depicted as a cloud since in some texts it is referred to as a phase about which the system designer has neither knowledge nor control. Yet, from this ambiguity the system developer is presented with a problem statement or system that must be designed. The new paradigm in this article posits that this cloud or unknown process is actually a higher level SDLC. In addition, the paradigm challenges the linear structure of the SDLC. The proposed structure is universal in application and thus appropriate for any endeavor. Introduction It is currently common business practice to apply a traditional Systems Development Life Cycle (SDLC) to the systems analysis and design process. The traditional approach could be improved by 1) recognizing an informal planning phase as the first step in the process and by 2) dispelling the concept that the SDLC is linear in nature. In addition, the traditional approach is generally applied only to information technology (IT) applications; however, the structure of SDLC is actually universal in application. To provide a basis for discussion of the traditional Systems Development Life Cycle (SDLC), a generic six (6) step SDLC is provided. This will likewise provide a common point of comparison as the proposed paradigm is contrasted with a traditional approach. All system studies begin with the identification of a problem area or an idea for improvement. The level of detail generated by this informal planning stage varies from perhaps a simple verbal description with little or no investigation to a much more formal, written statement outlining the nature of the problem as well as guidelines for further investigation. In any case, this informal planning process results in a project being passed on to the systems study group for a formal investigation that usually follows a much more formal methodology as depicted by the Preliminary Investigation step in the SDLC of choice for the organization. According to Brugha (2001, pg. 95), ...the SDLC is, at the highest level, about a process of commitment to a systems project.... What the systems study team is given for formal investigation, however, varies significantly and in many cases lacks any formal definition. This lack of formal definition sometimes leads to a repeat of the planning stage during the formal investigation. There are problems with this approach: duplication of effort, inefficient utilization of resources, and often identification and study of an area completely different from the one intended by the originator. The result of the formal investigation is a written problem statement that may or may not reflect the intent of the originator and that may be turned over to another systems study team for further analysis. This process is covered by the System Study step in the SDLC. Since the scope of the project has not been formally set at this time, further study and analysis often leads to project drift. Nonetheless, this investigation usually results in formal recommendations being developed and presented to management for consideration. Depending on the response of management the project may then be approved and turned over to a systems development team for programming and implementation. Support and maintenance and documentation responsibilities are often scattered with no clear-cut ownership. Problems At least two problems are apparent with this traditional approach. First, it does not address the informal planning phase. So much ambiguity surrounds the initial planning phase preceding the SDLC that it is depicted as a cloud in some textbooks. In many cases the system study team has limited knowledge and no control over this important phase where problems are identified for study and ideas for improvement are generated; no guidelines apply during this phase, and the level of detail generated varies significantly from project to project; and there is no feedback loop to insure that the project undergoing formal study reflects the original intent of the originator of the project. …