What Is Sdlc And What Is It Used For?

SDLC is a detailed guideline for developing systems and software.

SDLC stands for System Development Life Cycle or Software Development Life Cycle. SDLC is a guideline

for developing systems/software that involves 10 Phases:

1. Initiation

2. System Concept Development

3. Planning

4. Requirements Analysis

5. Design

6. Development

7. Integration and Testing

8. Implementation

9. Operations and Maintenance

10. Disposition.

Why does anyone need such a long process for putting together a computer system or software program?

Can't you just decide to write a program and that's it? Unfortunately, no.

In the last 25 years the use of computers has exploded. Nowhere is this more evident than in the workplace. Even manufacturing facilities are run by computers. Can you just decide to slap some software program into a multi-million dollar manufacturing facility or financial institution and hope it works without a hitch? No one would want to take the chance. Do we have the hardware (computer CPUs, servers, wiring) to handle the system? Do our computers have enough memory? Will it interfere with other programs? Does it really do what it is supposed to do?

These kinds of questions are why the SDLC model was developed. SDLC is just what is says it is - the Life Cycle of the system/software. From the identification of a need for the system Initiation) to rolling it out to the user (Implementation) to de-supporting or no longer needing it (Disposition), there must be a clear plan or it can be an expensive mistake.

Each phase of the SDLC requires documentation, reporting, and approval. This assures that a project cannot get out of hand either by changing the direction or becoming a financial black hole. The project sponsors are aware at every step exactly what is going on and it is documented. This means no surprises when the system is rolled out to the user.

The Phases

Initiation - Initiation is where there is an identified need for a new system. For instance, a retailer of fine crystal glass is in need of a new system to handle inventory. They've decided that the old system of putting the inventory into a simple spreadsheet will no longer work. They want a system where they can track inventory, inventory cost, facilities cost, personnel, a customer database, can track trends in buying, identify inventory that is not moving well and price it to move, etc. In other words, they want to be able to know everything with a few clicks of the keyboard. A Project Manager is placed in charge and he/she will develop a Concept Proposal - which is a document identifying the problem and why the new system needs to be pursued. The document is presented to upper management who approves it and the project moves on to the next phase.

System Concept Development - This is where the first real look at what will be necessary takes place. Several reports can be created here.

- Feasibility Study (will it work?)

- Cost/Benefit Analysis (is the cost really worth it?)

- System Boundary (how far should the project go?)

- Risk Management (what will happen if we don't do it?)

These reports are then presented, again, to the powers that be and a decision is made whether or not to go ahead. They approve the funding. If they give their approval it's on to the next phase.

Planning Phase - Who is doing what, when, and how? What personnel are needed? Use existing personnel or hire consultants? New Hardware? Develop own software or buy it off the shelf? What are the Deliverables - such as completed software programming and documentation, user manual, training, testing plans, etc? A Planning document is submitted for approval.

Requirements Analysis - Documentation of requirements. What interfaces are required (will it run with Windows NT and Windows XP?). What is the functionality required - should it be run with the mouse or keyboard commands? What is the level of proficiency required by the user? Will a new room be needed for the servers or equipment? Requirements documentation is approved, then it's on to the Design phase.

Design Phase - Take those Requirements and develop detailed, workable specifications. This is where everything is put together and the actual design of the system is done. This is also where documentation such as the Maintenance Manual, Operations Manual, and Training Manual begin. This is also where some of the flaws in the original planning may appear and require some adjustment. Again, there is documentation and approval.

Development Phase - The system is built. The software, hardware, and testing occur during the Development Stage. This is also the phase where the bugs are worked out of the system. A contingency plan is also developed at this point. A contingency plan is an emergency management document. If the power goes out - what happens to the system? What is the back up? How fast can it be brought back up to speed? Again, documentation and approval (get used to this).

Integration and Testing Phase - This is the formal integration and testing of the system. Testing has been done on the development phase, but in the Integration and Testing Phase it is a formal, documented testing procedure, not only to assure that the system performs as designed, but testing the roll-out of the system. If there is already another system in place with data, how fast can that data be migrated into the new system and useable to the company? Usually, the system is rolled-out over a weekend so that if anything goes wrong, the old system is still active and available. Integration and Testing is vital to the decision to go "live" with the new system. If it fails testing, it cannot be

trusted to work. Approval of testing and test results is necessary before the project moves into implementation.

Implementation Phase - Everything is ready and it's time to go live. Training takes place, everyone who will use the system must be fully informed of the day it goes live, previous data is migrated, and the system is ready for use. After it goes live, the system is reviewed post-implementation to see how well it worked and how well did the project go. It's often known as a debriefing or lessons learned meeting. It is also where any problems that were not crucial to the implementation can be addressed and any necessary changes to the system documented for future versions.

Operations and Maintenance Phase - Hey, it's not over. Just like a car engine, maintenance and support are necessary. What happens if the system is based on Microsoft NT 4.0 and 2 years later Microsoft is no longer supporting NT 4.0? Or, a new e-mail program is put in place and it interferes with the system? Fixes are necessary and will occur. This is the day-to-day operation of the software. No one can just walk away once the software is rolled-out and say, "Whew, glad that's over." It's not over; it's just begun.

Disposition Phase - This is where the system has become obsolete. Perhaps a whole new system is coming in, or this system cannot keep up. Many programs and systems became obsolete with the Y2K problem or with upgrades of operating systems. Whatever the reason, putting the system to bed involves more than just shutting off the server. Often, the system may be kept going due to regulatory issues or because there are still projects using it. Even if the system will be shut down due to the development of a better system, disposition needs planning. A disposition plan, archiving of system documentation, archiving of data, even a plan for getting rid of the old equipment may be a part of the Disposition Phase.

This is a short description of SDLC and its phases. The important idea to take away from SDLC is that it involves planning, approval, testing, and documentation to assure that the system can, and will work as required.

Trending Now

© High Speed Ventures 2011