Traditional SDLC

What is meant by Traditional System Development Life Cycle?

Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. There are several Systems Development Life Cycle Models in existence. The oldest model, that was originally regarded as "the Systems Development Life Cycle" is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages generally follow the same basic steps but many different waterfall methodologies give the steps different names and the number of steps seems to vary between 4 and 7. There is no definitively correct Systems Development Life Cycle model, but the steps can be characterized and divided in several steps.

Phase1.Initiation/Planning

To generate a high-level view of the intended project and determine the goals of the project. The feasibility study is sometimes used to present the project to upper management in an attempt to gain funding. Projects are typically evaluated in three areas of feasibility: economical, operational, and technical. Furthermore, it is also used as a reference to keep the project on track and to evaluate the progress of the MIS team. The MIS is also a complement of those phases. This phase is also called the analysis phase.

As software is always of a large system (or business), work begins by establishing the requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when the software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.

Phase2.Requirements Gatherings and Analysis

The goal of systems analysis is to determine where the problem is in attempt to fix the system. This step involves breaking down the system in different pieces and drawing diagrams to analyze the situation. Analysts project goals, breaking down functions that need to be created, and attempt to engage users so that definite requirements can be defined.This process is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system.

It also includes the personnel assignments, costs, project schedule, target dates etc.... The requirement gathering process is intensified and focused specially on software. To understand the nature of the program(s) to be built, the system engineer or "Analyst" must understand the information domain for the software, as well as required function, behavior, performance and interfacing. The essential purpose of this phase is to find the need and to define the problem that needs to be solved.

Phase3.Design

In systems design functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. The output of this stage will describe the new system as a collection of modules or subsystems.In this phase, the software development process, the software's overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, the data structure design etc... Are all defined in this phase. A software development model is thus created. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Phase4.Build or Coding

Modular and subsystem programming code will be accomplished during this stage. This stage is intermingled with the next in that individual modules will need testing before integration to the main project. Planning in software life cycle involves setting goals, defining targets, establishing schedules, and estimating budgets for an entire software project.

The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like compilers, interpreters, debuggers etc... Are used to generate the code. Different high level programming languages like C, C++, Pascal, and Java are used for coding. With respect to the type of application, the right programming language is chosen.

Phase5.Testing

The code is tested at various levels in software testing. Unit, system and user acceptance testing are often performed. This is a grey area as many different opinions exist as to what the stages of testing are and how much if any iteration occurs. Iteration is not generally part of the waterfall model, but usually some occurs at this stage. These are the types of testing:

· Data set testing

· Unit testing

· System testing

· Integration testing

· Black box testing

· White box testing

· Module testing

· Regression testing

· Automation testing

· User acceptance testing

Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available. Some companies build their own testing tools that are tailor made for their own development operations.

Phase6.Operations and Maintenance

The deployment of the system includes changes and enhancements before the decommissioning or sunset of the system. Maintaining the system is an important aspect of SDLC. As key personnel change positions in the organization, new changes will be implemented, which will require system updates.The software will definitely undergo change once it is delivered to the customer. There can be many reasons for this change to occur. 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.

Features of the Traditional SDLC.

· Consulting in all phases of SDLC: Requirements Definition, Analysis, Design, Construction, Testing, Training, and Implementation

· Provide advice on certain methods and approaches to systems development (e.g. Waterfall, Iterative, Rapid Application Development, Structured, Object-Oriented, etc.)

· Teach how and when to integrate techniques to minimize risk

· Make best use of modeling and diagramming techniques

· Integration of project management techniques

· Increase likelihood that end-product matches requirements and meets goals

· Help establish SDLC best practices

· Help select software tools that fit in with practices and methods

What Are criticisms with the Traditional SDLC?

There are many criticisms put forward against SDLC, and those criticisms are being given in point forms.

· The SDLC Waterfall: Due to the waterfall nature of the SDLC, on some projects, the team has to go back and forth between requirements and design so many times that the project seems to be out of control.

· Increased development time in the whole system.

· Increased development cost in the whole system.

· Systems must be defined up front.

· Rigidity (Inflexibility).

· Hard to estimate costs, project overruns.

· User input is sometimes limited.

· Requirements Documentation Difficulty: Another problem, especially on complicated systems, is the difficulty of documentation requirements in a usable way.

· Scheduling and budgeting difficulties: For large-scale system, schedule and budgeting estimates are so approximate as to become nearly laughable.

· In the SDLC Model, while we are in the process of the system, we cannot go to the previous stage or phase.

· The main drawback that we can find in this type of SDLC, Lacking of time. In the sense, until the previous stage completes, the balance entire team has to wait for the completion of current stage. This will cause a waste in human resource.

· This type of SDLC is not flexible as in completion of a stage if we need we cannot come to a completed stage.

· Real projects rarely follow the sequential flow that the model proposes.

· At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model doesn’t accommodate this natural uncertainty very well.

· Assumptions made in the early phases no longer hold.

· Some of the early work is incomplete

· Something was overlooked or not completely understood.

· The customer satisfaction will get less as the competitive organizations outputs will be in high standards and when this organization cannot compete. Due to this the customers will lose the trust which they had on this organization and this will damage the organization’s reputation.

· If an organization has to invest money to create a System in the SDLC by borrowing or by using the money they had to invest in another firm they will be loosing that income or they will be paying interest without getting the output from this system due to the time frame.

· To overcome these problems we can use alternative methods on the development of a particular system.