Systems Development Life Cycle
Systems Development Life CycleSystemsDevelopmentLifeCycle is better known by its acronym of SDLC.
See computerworld article for an excellent description of the cradle (feasibility) through grave (post implementation support and eventual decommissioning) at http://www.computerworld.com/developmenttopics/development/story/0,10801,71151,00.html.
After ExtremeProgramming came out, the YagniPrinciple has resulted in a flood of TimeToMarket hello SoftwareIndustrialRevolution UserStories.
Also see AgileSoftwareDevelopment for the latest trends and a real-world case study.
The SDLC process was designed to ensure end-state solutions meet user requirements in support of business strategic goals and objectives. In addition, the SDLC also provides a detailed guide to help Program Managers with ALL aspects of IT system development, regardless of the system size and scope. The SDLC contains a comprehensive checklist of the rules and regulations governing IT systems, and is one way to ensure system developers comply with all applicable Government regulations, because the consequences of not doing so are high and wide ranging. This is especially true in the post 9/11 environment where larger amounts of information are considered sensitive in nature, and are shared among commercial, international, Federal, state, and local partners.
The seven-step process contains a procedural checklist and the systematic progression required to evolve an IT system from conception to disposition. The following descriptions briefly explain each of the seven phases of the SDLC:
1. Conceptual Planning. This phase is the first step of any system's life cycle. It is during this phase that a need to acquire or significantly enhance a system is identified, its feasibility and costs are assessed, and the risks and various project-planning approaches are defined. Roles and responsibilities for the Asset Manager, Sponsor's Representative, System Development Agent (SDA), System Support Agent (SSA), and other parties in SDLC policy are designated during this stage and updated throughout the system's life cycle.
2. Planning and Requirements Definition. This phase begins after the project has been defined and appropriate resources have been committed. The first portion of this phase involves collecting, defining and validating functional, support and training requirements. The second part is developing initial life cycle management plans, including project planning, project management, Configuration Management (CM), support, operations, and training management.
3. Design. During this phase, functional, support and training requirements are translated into preliminary and detailed designs. Decisions are made to address how the system will meet functional requirements. A preliminary (general) system design, emphasizing the functional features of the system, is produced as a high-level guide. Then a final (detailed) system design is produced that expands the design by specifying all the technical detail needed to develop the system.
4. Development and Testing. During this phase, systems are developed or acquired based on detailed design specifications. The system is validated through a sequence of unit, integration, performance, system, and acceptance testing. The objective is to ensure that the system functions as expected and that sponsor's requirements are satisfied. All system components, communications, applications, procedures, and associated documentation are eveloped/acquired, tested, and integrated. This phase requires strong user participation in order to verify thorough testing of all requirements and to meet all business needs.
5. Implementation. During this phase, the new or enhanced system is installed in the production environment, users are trained, data is converted (as needed), the system is turned over to the sponsor, and business processes are evaluated. This phase includes efforts required to implement, resolve system problems identified during the implementation process, and plan for sustainment.
6. Operations and Maintenance. The system becomes operational during this phase. The emphasis during this phase is to ensure that sponsor needs continue to be met and that the system continues to perform according to specifications. Routine hardware and software maintenance and upgrades are performed to ensure effective system operations. User training continues during this phase, as needed, to acquaint new users to the system or to introduce new features to current users. Additional user support is provided, as an ongoing activity, to help resolve reported problems.
7. Disposition. This phase represents the end of the system's life cycle. It provides for the systematic termination of a system to ensure that vital information is preserved for potential future access and/or reactivation. The system, when placed in the Disposition Phase, has been declared surplus and/or obsolete and has been scheduled for shutdown. The emphasis of this phase is to ensure that the system (e.g., equipment, parts, software, data, procedures, and documentation) is packaged and disposed of in accordance with appropriate regulations and requirements.
Each column in the graphic represents an individual phase. The documents in each phase are created and maintained throughout the rest of the development cycles until the final disposition of the project. Although this indicates the process is linear, it is not. It is iterative and once a project is deployed, the management of the project may return to requirements gathering to start all over again.
Avison and Fitzgerald in their book Information Systems Development: Methodologies, Techniques and Tools describe the SystemsDevelopmentLifeCycle:
This methodology has the following steps:
They go on to say:
The term 'life-cycle' indicates the iterative nature of the process...
This methodology, they say, was described completely in 1971 by Daniels and Yeates (Basic Training in Systems Analysis. 2nd ed., Pitman, London).
It has some interesting features that make it, to my mind, less abstract than the pure (and perhaps mythical) WaterfallModel. Each phase is considered in the context of the current system. The second stage is essential grounding for this. Here the systems analyst tries to see the problems and not just hear them. She tries to become the customer.
The next stage, 'Systems analysis', may go beyond what the customer knows. It explores the history of the system. It asks how and why is has developed this way. Should the procedures of today be automated, or should the system take a new direction?
There is a conspicuous lack of references to programming in this model. The idea, I think, is that certain problems are best fixed at the systems level. You don't always have to dive for the keyboard. Some other areas that the SDLC thinks important: Legal and social feasibility, the purchase and installation of hardware and software as an implementation consideration and the consideration of future scalability. All things I'm happy to see at least mentioned.
Hey, where's the "blame" stage? There is usually a blame stage. There is a Union Member.
EditText of this page
(last edited November 15, 2014)
or FindPage with title or text search