An essay on the sdlc model


A system is a group of objects, people and processes that work together toward a particular set of goals. Systems have been developed even before the computer era mainly using ad hoc methods. With the advent of computing the systems development lifecycle (SDLC) was born which provided a structured way of developing systems. The SDLC is still an important tool in modern day information systems development. This paper will look at the general SDLC, its future and its continued contribution to information systems development that validates its relevance in this current information age

Systems development Life cycle is a logical methodology devised to develop information systems in a structured and methodical way. It involves the following phases: initiation/planning, requirements gathering/analysis, design, development; testing, operations/ maintenance and disposal. There are several versions of SDLC but all revolve around these phases which were originally modelled into the traditional/waterfall model in which used a sequential process where each phase was distinct and had to be completed before the next phase is started. And the output in each phase becomes the input for the next phase.

Basics of SDLC

According to Elliott & Strachan & Radford (2004) the SDLC originated in the 1960s that was used in developing large scale functional business systems where information systems activities revolved around heavy data processing and number crunching routines.

Taylor (2004) asserts that systems development life cycle focuses on realizing the product requirements. Indeed through the use of SDLC the objective is a resultant quality system that meets user expectations but furthermore is completed within time and budget constraints, works effectively and efficiently and is cost effective to maintain.

Details are available from,

There is a misconception on the term SDLC which some quarters refer to the traditional/ waterfall model as the SDLC, which is inaccurate. The SDLC is an umbrella term for the overall process of developing, implementing, and retiring information systems through a multiple step process from initiation, analysis, design, implementation, and maintenance to disposal, NIST Special Publication (SP) 800-64.

The role and nature of the SDLC

The SDLC provides structured system development methodologies that guide the systems development effort toward quality systems that meet the user requirements and are delivered within time and budget.

The traditional waterfall model has morphed into different methodologies that attempt to overcome some inherent weaknesses of this traditional model and other older models developed after the waterfall, which will be examined in the section below. This continued adaptation of the SDLC to meet current challenges in information systems development is expected to continue and is the crux of the validation of its continued relevance in information systems development.

Some of these newer models include Structured Systems Analysis and Design Method (SSADM), Rapid Application Development (RAD) Extreme Programming (XP) Spiral, Fountain, rapid prototyping, incremental, and synchronize and stabilize.

As noted in, SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results

Weaknesses of Waterfall/traditional SDLC:

The traditional waterfall model has several weaknesses by its very inherent nature and according to Larry Runge in a 1991 Information Center Quarterly article,

(, the SDLC works very well for automating the activities of clerks and accountants but not as well for knowledge workers who drive the modern day organizations. Additionally the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance.

Other models stemming from the Waterfall:

As mentioned previously there are many other models that have been developed to cater for the weaknesses of the waterfall model. This paper will briefly look at three of them; Spiral, Rapid Prototyping and incremental.

Spiral: As a result of these weaknesses the spiral model was developed which emphasizes iterations of the phases with each phase producing an early prototype representing a part of the overall system. This helps in demonstrating a proof of concept early in development.

Rapid prototyping: The emphasis is on creating a prototype and is used in projects where the requirements are not very clear at the offset of the project. This would be used to generate more requirements from the end users. After requirements have been defined the prototype is discarded and the real product is then built.

Incremental: This model involves continuous user feedback and interactions resulting in a product that is much closer to user expectations .The development is built up from an initial prototype that is continuously being developed and tested. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.

The above details are available from;

The main model of the SDLC

As it had been mentioned before the SDLC consists of distinct and interdependent phases from initiation to disposal while not all methodologies will have the phases sequentially some will take on an iterative approach with overlapping phases. Each of these phases is described below:


This is also referred to as the conceptual stage where the initial ideas on the systems begin to take form .The purpose of the system is determined at this stage, mostly looking at the problem statement that also guides the scope of the system. In this phase the initial focus is on ensuring the intended system is in line with the business objectives and this is justified through a business case. The business case identifies the systems purpose, expected benefits and alternative solutions. On the approval of the business case a feasibility study is done to determine the systems viability system in terms of economical (cost benefits), operational/organizational or technical feasibility. It is also used as a reference to keep the project on track and to evaluate the progress of system development effort.

Requirements gathering and analysis:

The systems analysis stage determines where the problem is i.e. what needs to be done and not how. This is where as much information is gathered about the business domain and specifics of the problem at hand. The resultant requirements are the needs or conditions to be met by the system. In this stage the business users are engaged mostly using techniques such as interviews, questionnaires, observation, prototypes in gathering requirements. There are different types of requirements:

Functional Requirements:

These explain identify the necessary task, action or activity that must be accomplished by the system to address the problem.

Non-functional requirements:

These specify other non core requirements outside of the main tasks of the system but are also required for the systems operation e.g. security

Performance Requirements:

This refers to how well the system accomplishes its tasks. Performance is generally measured in terms of quantity, quality, coverage, timeliness or readiness.


This phase builds the architecture of the system the functions and operations are described in detail, including screen layouts, business rules, process diagrams and other documentation. Design starts with logical design which takes the requirements identified in the approved requirements specifications document and partitions the systems into conceptual components. Here the focus is on the problem domain without delving into the details of technology, platform or even performance. Each requirement is used to derive a set of one or more design elements and additional ones will be produced as a result of interviews, workshops, and/or prototype efforts.

The second stage in design is the detailed design phase which modifies the logical design to produce a more detailed design that includes technological choices, systems architecture and performance while still meeting the logical functionality defined.

The overall design describes the desired software features in detail including functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-relationship diagram with a full data dictionary. These design elements are intended to describe the software in sufficient detail that skilled programmers may develop the software with minimal additional input.


The development phase involves converting design specifications into executable programs. If the system being developed is computer software this is where the program code is developed. The individual components are developed and integrated .During this phase the test plans are completed and the conversion, implementation, and training plans and user, operator, and maintenance manuals are updated.


This is where various tests are conducted to ensure the system functions as expected and meets specified requirements .Two approaches can be used i.e. bottom up and top down. Bottom up involves testing smaller components first and progressively adding and testing additional components and systems. Top down tests major components and connections and progressively tests smaller components and connections.

There are various types of testing:

Acceptance Testing - End users perform acceptance tests to assess the overall functionality and interoperability of an application.

End-to-End Testing - End users and system technicians perform end-to-end tests to assess the interoperability of an application and other system components such as databases, hardware, software, or communication devices.

Functional Testing - End users perform functional tests to assess the operability of a program against predefined requirements. Functional tests include black box tests, which assess the operational functionality of a feature against predefined expectations, or white box tests, which assess the functionality of a feature's code.

Integration Testing - End users and system technicians perform integration tests to assess the interfaces of integrated software components.

Parallel Testing - End users perform parallel tests to compare the output of a new application against a similar, often the original, application.

Regression Testing - End users retest applications to assess functionality after programmers make code changes to previously tested applications.

Stress Testing - Technicians perform stress tests to assess the maximum limits of an application.

String Testing - Programmers perform string tests to assess the functionality of related code modules.

System Testing - Technicians perform system tests to assess the functionality of an entire system.

Unit Testing - Programmers perform unit tests to assess the functionality of small modules of code.

Details are available from,

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


In this phase, plans are developed for discarding system information, hardware, and software and making the transition to a new system. The information, hardware, and software may be moved to another system, archived, discarded, or destroyed. Especially the information in the system needs to be efficiently purged so that no traces could be retrieved later leading to unauthorized access.

Does Internet technology change the SDLC?

Internet technology has indeed changed the SDLC in terms of adopting the traditional SDLC to more versatile development frameworks suited for the fast paced internet environment. This environment is characterized by rapid changes that require systems to be delivered faster and become more flexible to adapt to the fast changing environment. This has created the need to have an SDLC that allows for rapid systems development that is flexible enough to cater for loosely defined requirements that would be subsequently defined through iterative processes and or prototyping techniques.

The internet has fuelled the rapid rate of change in environments where IS are employed, leading to a highly volatile IS environment. This problem is compounded by the fact that the interconnection enabled by the internet is causing increasingly complex and dynamic interlinked systems. Increasing IS environmental volatility leads to increasing user uncertainty concerning IS needs; this can have a very detrimental effect on the productive development of IS.

New variations of the SDLC meeting these new demands have been formed some of which have been mentioned earlier and include agile and iterative methodologies building upon the limited sequential traditional waterfall method. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method focus on limited project scopes and expanding or improving products by multiple iterations.

Both the agile and iterative methods have been developed as an attempt to adapt to the complex and dynamic and volatile IS environment resulting from the advent of the internet. The component object model /object oriented methodology is such an example of a methodology that came about as a result of the need of systems integration and the requisite flexibility through reuse which is synonymous with the internet. This model emphasizes the creation of classes that encapsulate both data and the algorithm that are used to manipulate the data. The object oriented classes are reusable across different applications and computer based system architectures.

The future of the SDLC

As it has already proven SDLC is here to stay what is expected in the future has already been seen from the past. Since the inception of the waterfall model in the 1960'swhere it was used in developing large scale functional business systems in the era of data processing, the SDLC has been adopted to the current dynamic and interconnected environment. One of the areas currently being examined as an enhancement to the SDLC is incorporating systems security. This would involve providing mechanisms that would address security more comprehensively than as the current way it is addressed as a non functional requirement. Three approaches have been proposed for this ( :

Top down:

In top down security requirements are added to the functional and non-functional requirements. These requirements can be derived from the Information Security policy, and meeting with security stakeholders. These policy statements are translated into requirements which drive the design, development and testing of the system. This may be done using security-centric use cases during the design of the system.

Testing and Validation Approach:

The testing and validation approach takes place at the end of the development lifecycle. Security systems testing, penetration testing, white and black box approaches can be used to validate the sufficiency of the system to meet the security goals.

Start in the middle approach

This approach uses source code analysis using peer review and automated source code analysis tools to identify security bugs in the code as it is being developed.

Apart from security there is a growing concern that there is a lack of understanding about the impact of IS and IT on employees and organizations which has led to the failure of many information systems. This seems to stem right from the SDLC methodologies that focus predominantly on technical issues. To meet this challenge proposals are being made to have more business led perspectives built into systems development methodologies.

Into the future we should expect newer frameworks continuing to be developed from the SDLC to meet new challenges arising from continued complexities and interdependencies of systems. This has already been alluded to by the rapid rise of the service oriented architecture that has seen systems from different vendors categorized as offering specific services and interlinked as one system.


The SDLC is an overall term for system development methodologies that range from the traditional waterfall model that is used in big and stable projects to the lighter agile methodologies that allow for rapid development. Although the traditional waterfall methodology is no longer used as much it still remains a reference point used in the various adaptations that will continue being developed to address system development challenges. As it has been seen in the advent of the internet systems will continue being more complicated courtesy of the need for integration to allow various systems to work together e.g. the service oriented architecture. This structured set of systems development frameworks will continue being used into the future albeit in different flavors complementing each other and meeting the demands of the changing environment. SDLC still remains valid and relevant in modern day systems development

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!