The system life cycle

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Systems Analysis: The system life cycle


The system life cycle is a term used to describe the stages in an IT project. It is the process by which an existing system is replaced with another. The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

In this report I will be researching at least 3 different SDLC models and indentifying my sources in a bibliography. Then I will decided on a model that I will go into greater detail buy indentifying the function and purpose of each stage in that model and how these are applied to developing system. Finally I will compare my chosen model to one of the other models that I have researched, highlighting any differences and clearly identifying any advantages and disadvantages of both models, explaining why I have chosen that particular model over the other models that are available.

I will use the internet and books to research this project. Given a formal report of my findings and referencing any quotations that I may used in my work.

1.0 The System Development Life Cycle (SDLC)

The systems development life cycle (SDLC) is a theoretical model that is used in project management to describe each of the stages that are involved within an information system development project, from the initial feasibility study through to the maintenance of the completed application.

A variety of system development life cycle methodologies have been developed to guide the processes involved, including the waterfall model: this was in fact the first model to be introduced in the project management development. From then on other models such as the Rapid application development (RAD) the fountain model, the spiral model, build and fix, and synchronize-and-stabilize. Frequently, several models are combined into a hybrid methodology. Documentation is a vital type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for precise types of projects, but in the final analysis, the most important factor for the accomplishment of a project may be how closely the particular plan was followed.

In general, each type of the system development life cycle follows the following steps:

  1. The system is evaluated. Deficiencies within the project are identified. This can be done by interviewing users of the system and consulting with support personnel.

  2. The new system requirements are clear to the creator. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement to the system.

  3. The proposed system is created. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.

  4. The new system is put into developed. The new components and programs are obtained and installed. Users of the system must be trained to use the system. All aspects of performance must be tested. If necessary, any adjustments must be made at part of the development.

  5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.

  6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

In the modern world of computing few people would stick to a strict method of their systems development life as most modern mythologies have as many modern methodology have out dated this sort of thinking. In most cases people will argue that SDLC in fact no longer applies to models such as Agile computing but in general the term is still widely used in technology circles. SDLC has practice advantages in the traditional models of software development that more often enough lends itself to a more structure environment. The disadvantages to using the SDLC methodology is when there is need for iterative development such as stakeholders need to review their status on a regular basis the software being designed. Instead of viewing SDLC from a strength or weakness perspective, it is far more important to take the best practices from the SDLC model and apply it to whatever may be most appropriate for the software being designed.

2.0 Spiral (SDLC)

Looking into further detail into different system development life cycle methodologies, the spiral model is a commonly used model throughout project management:-

The spiral model is a recent system development life cycle that has been proposed by Boehm. As the name suggests, the activities in this model can be organized into a spiral like figure. The spiral has many cycles within it which each contain separate areas of the system development life cycle. The radial dimension represents the increasing costs that are incurred in accomplishing the steps done so far and the angular dimension represents the progress made in completing each cycle of the spiral. Each cycle in the spiral begins with the classification of the objectives for that cycle and the different alternatives that are possible for achieving the objectives and the imposed limitations.

During the next step of the spiral life cycle model. The user has to evaluate these different alternatives based on the objectives and constraints. This will involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties and risks. This step may include more activities such as benchmarking, simulation and prototyping. After that the next step is to develop the software by keeping in mind the risks. Finally the next stage is planned out.

The next step is determined by remaining risks. For example, its performance or user-interface risks are considered more important than the program development risks. The next step may be evolutionary development that involves developing a more detailed prototype for resolving the risks. On the other hand, if the program development risks dominate and previous prototypes have resolved all the user-interface and performance risks; the next step will follow the basic waterfall approach.

The risk driven nature of the spiral model allows it to accommodate any mixture of specification-oriented, prototype-oriented, simulation-oriented or some other approach. An important feature of the model is that each cycle of the spiral is completed by a review, which covers all the products developed during that cycle, including plans for the next cycle. The spiral model works for developed as well as enhancement projects.

  • Quadrant 1: Determine objectives, alternatives, and constraints.

  • Quadrant 2: Evaluate alternatives, identify, and resolve risks.

  • Quadrant 3: Develop, verify, next-level product.

  • Quadrant 4: Plan next phases.

Although the spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, let's briefly address each one

Quadrant 1: Determine Objectives, Alternatives, and Constraints

Activities performed in this quadrant include:

Establish an understanding of the system or product objectives-namely performance, functionality, and ability to accommodate change. Investigate implementation alternatives-namely design, reuse, procure, and procure/ modify. Investigate constraints imposed on the alternatives-namely technology, cost, schedule, support, and risk. Once the system or product's objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate Alternatives, Identify, Resolve Risks

Engineering activities performed in this quadrant select an alternative approach that best satisfies technical, technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions.

The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is "operationally useful and robust enough to serve as a low-risk base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypes going toward the right (hand side of the graphic) . . . the option of writing specifications would be addressed but not exercised." This brings us to Quadrant 3.

Quadrant 3: Develop, Verify, Next-Level Product

If a determination is made that the previous prototyping efforts have resolved the activities to develop, verify, next-level product are performed. As a result, the basic "waterfall" approach may be employed-meaning concept of operations, design, development, integration, and test of the next system or product iteration. If appropriate, incremental development approaches may also be applicable.

Quadrant 4: Plan Next Phases

The spiral development model has one characteristic that is common to all models-the need for advanced technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, risk, of development efforts to date; resolves critical operational and/or technical issues and reviews plans and identifies to be resolved for the next iteration of the spiral.

Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths and decision considerations

2.1 Advantages and Disadvantages

When using the "Spiral" method there are many advantages and disadvantages. Listed below are some advantages when using a waterfall:-


  • Risk reductions mechanisms are in place

  • Supports iteration and reflects in real-world practices

  • Systematic approach to the information that is being processed

  • Changes made in one module with the spiral method will not have any other impact on another module.

  • Better understanding of the project in hand

  • Higher quality is delivered when the end result occurs

  • Supports dynamically changing requirements

On the other hand when using the "Spiral" method of (SDLC) there are disadvantages to take into consideration:-


  • Very complex and relatively difficult to follow precisely (restrictions)

  • Requires expertise when the risk evaluation and reductions procedures have to be analyse

  • Applicable to large systems only. No good for smaller systems

  • Requirements are not tested

  • Designs are not tested

  • Downfall of the defect cannot be avoided

  • Route cause analysis is fairly difficult to do

  • Expertise is required when using this method

3.0 Rapid application development (RAD)

Many developers think of rapid application development (RAD) as a way to deliver projects without having to spend time on planning or analysis. This is not the case at all. RAD is a development methodology-different from the waterfall approach but a methodology nonetheless. At one time, RAD was brand new and sexy, but it has been utilized successfully, and unsuccessfully, for a number of years now.

RAD features these overriding characteristics:

  • The focus is on delivering projects in small pieces. If you have a large project, you need to look at ways to break it into smaller projects, each of which can be planned and delivered individually. With a series of smaller projects, you can deliver each one more quickly and in a less structured manner.

  • Deliverables, including the final solution, are created using a repeating process of analysis, design, construction, and testing. Prototypes are created early and evolved to include more detail over time.

  • RAD emphasizes reuse. This includes the reuse of code, processes, templates, and tools. It is usually faster to assemble prebuilt components than to build everything from scratch.

With those characteristics in mind, let's take a look at the RAD life cycle.

Planning Just as with the waterfall methodology, you need to plan the work first. (And just as with the waterfall method, many people consider planning to be a part of the project management process). The key deliverables from this phase are a Project Definition that describes and defines the project, Project Management Procedures that describe the processes for managing issues, scope, risk, communication, quality, etc., and a Work plan that describes the activities needed to complete the project. Because the project is smaller, less time is required to plan the work.


You still need to capture the business requirements, but now there is a twist. Instead of spending the time to gather a precise set of detailed requirements, you first gather the requirements at a high level. Focus on the main features and functions to be delivered, as well as the overall batch and online processes. The requirements do not necessarily need to be formally approved by the customer, since the RAD approach allows them to change over time. However, it is still a good idea to make sure that you understand the requirements.

There is usually no need to make a build-or-buy decision. By utilizing the RAD approach, you should have already determined that the solution most likely would be assembled/built.

The first time through the analysis phase, you should still look ahead in the project to plan the approach for some of the later activities. Because a RAD project is smaller, you can probably bypass the high-level strategy documents and focus directly on the lower-level documents such as the Testing Plan, Training Plan, and Implementation Plan. If the project is small enough, the plans can be bypassed as well, with the lower-level activities discussed with the customer and placed directly into the Work plan.


Utilize the requirements you received in the previous step to build a high-level prototype of the application. The first time through, this may just be a series of screens that show how a business transaction is processed. There may not be any database calls or business logic programmed behind the screen shells. During this first pass, basic decisions also need to be made in terms of the technology and tools to utilize, since the prototype may lead directly to the solution. Remember that you want to maximize the amount of content being reused and keep new construction to a minimum.

Repeat analysis and prototyping as necessary When you've completed the initial prototype, you can use it to gather additional, more detailed business requirements from the customer. The thought here is that customers can better give requirements once they can start to see how the solution looks and feels. Once you get the modified set of requirements, you update the prototype to reflect the new set of requirements. When that prototype is completed, you take it back to the customer again to revalidate requirements.

Conclusion of prototyping

The project manager and customer need to agree on a fixed number of prototyping iterations or else this cyclical process could go on forever. Usually, three iterations is a good number. At that point, you will have two approaches to finish the project. First, if you developed the prototypes with the final solution in mind, you need to finish the design, programming, and testing of the solution using the prototype as the starting point. In fact, depending on how much business logic you put into the last prototype, you may find that your solution is close to being completed.

The other option is to throw away the prototype and begin developing the production application from scratch. If you take this approach, it is imperative that you don't spend much effort on the prototype itself.

In either case, the testing process still needs to be completed. The prototype may have taken you through unit and integration testing, but you still need to system test and gain user acceptance before the application can be implemented.


Normally, you do not prototype the implementation phase (although you may run a pilot test, which is different). So, the implementation phase proceeds similarly to the waterfall method.

4.0 Waterfall (SDLC) (Chosen model)

The waterfall lifecycle is the natural way of managing the development something innovative and complex. It, or something better, is particularly neccessary where the development is subject to a contracted project. Note innovative , for members of this class, writing a program to read a list of numbers, sort them, and print in descending order, contains neither novelty, complexity nor risk [or pick some program that you do think trivial!]. Hence, it requires little or no planning, analysis, design - over and above what can be done almost unconciously.

On the other hand, it is unlikely that a viable dissertation project could be completed without some form of planning and phasing of tasks.

We have already mentioned that using the waterfall model: the project proceeds according to clearly defined phases; a preceeding phase must be completed before the next starts; phase completion is judged by the outcome of the phase matching the requirements defined by the previous phase. This is natural and logical - how rational and careful people proceed: `look before you leap'. Not that all software developers, or project students!, are rational and careful; and it is easy for the inexperienced to misjudge the levels of complexity, novelty or risk.

devoting time and space to a process which is known to be inadequate, there are three good reasons:

  • A good many software standards documents still assume a waterfall lifecycle.

  • Non-technical managers, and those responsible for external development projects, like (demand) such an approach.

  • An understanding of the waterfall process (and its inadequacies) is a prerequisite to study of alternative processes - which, in any case are often based on it.


The feasibility study is a vital part of a system development life cycle as this stage is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.

Requirement Analysis and Design

Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization that will be captured in as much detail as possible. Options for changing the business process may be considered once the study has been completed. The Design part of the SDLC comes in to separate parts, one consists of a high level such as what programs are needed and how are they going to interact. And a low-level design this consists of how the individual programs are going to work, how the interface is going to be designed. Basically the outcome of what are the interfaces are going to look like and finally the data design. For example what data will be required within the system? During these phases, the software's overall structure is defined and planned. Analysis and Design are a very crucial part within the whole development cycle. Any glitch that might be made in the design phase could be very expensive to solve in the later stage of the software development. Much care has to be taken into consideration during this specific phase.


In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, and Debuggers 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.


In this phase the system is tested. Normally programs are written as a series of individual modules, these subjects to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing).


Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. 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.

3.1 Advantages and Disadvantages of the waterfall method

When using the waterfall method there are many advantages and disadvantages. Listed below are some advantages when using a waterfall:-

  • Misinterpretations may arise early. Errors found during certain operations may cost a lot more money to fix. But are generally caught during the software requirements when using the review in the waterfall (SDLC)

  • Makes tasks more manageable

  • Offers opportunities to allow more control over the development process

  • Better than using the trial and error method

  • Provides standards for documentations

On the other hand when using the waterfall method of (SDLC) there are disadvantages to take into consideration:-

  • It may be difficult to completely define the requirements at the beginning of the project expect for well understood cases.

  • Related to the previous disadvantage: It is almost impossible to accommodate, at a late stage the changes to certain requirements.

  • It is virtually impossible to fit maintenance or reuse into this format.

  • There are massive delays involved in the documentation and review procedures. As a simple illustration.

  • Fails to see the bigger picture of strategic management

  • Unable to capture the needs of specific users

  • Too inflexible to cope with certain changes to the requirements

  • The documentation can be often to technical for certain users

5.0 Conclusion

After detailed research on different System development life cycle mythologies:-

  • Waterfall (SDCL)

  • RAD (SDCL)

  • Spiral (SDCL)

I have come to the conclusion that the waterfall model is what I consider to be the best model out of the three. It is the most powerful yet simple to use model with the unnecessary need of expertise.

Comparing the advantages and disadvantages against the spiral model in this instance:-

Advantages of the spiral (SDLC):-

  • Risk reductions mechanisms are in place

  • Supports iteration and reflects in real-world practices

  • Systematic approach to the information that is being processed

  • Changes made in one module with the spiral method will not have any other impact on another module.

  • Better understanding of the project in hand

  • Higher quality is delivered when the end result occurs

  • Supports dynamically changing requirements

Advantages of the waterfall (SDLC):-

  • Misinterpretations may arise early. Errors found during certain operations may cost a lot more money to fix. But are generally caught during the software requirements when using the review in the waterfall (SDLC)

  • Makes tasks more manageable

  • Offers opportunities to allow more control over the development process

  • Better than using the trial and error method

  • Provides standards for documentations

As shown in the advantages of using a waterfall model they are a lot more practical to a user then using a spiral model. As the spiral model is simply to complexes and needs to be worked with by a user that clearly shows expertise in that particular area that needs to be created. This would lead to extra costs to cover the work load and staffing costs to manage the increased workload. The spiral model is not designed for a small business either it would become useless in the long run as there are a lot of data inputs that need to be taken into consideration.

On the other hand the waterfall model is a system that can be used throughout small to large businesses without the need of extra staff and work load on the task at hand. The model is not over complicated and each stage in the life cycle straight forward to understand and complete:-

  • Feasibly

  • Design

  • Analysis

  • Implementation

  • Maintenance

Very simple but still has the same effect as the spiral model would have within an organisation

6.0 Bibliography

Title                  "RAD life cycle"
Author               unknown
Published          2006 approximately
Access Date     5th February 2010

URL                  ""
Title                  "system development cycle"
Author               "Wikipedia"
Published           2009 approximately
Access Date       10th February 2010

URL                  ""
Title                  "System development life cycle"
Author              " Russell Kay "
Published           2009 approximately
Access Date                   10th February 2010

URL                 ""
Title                  "Quick study system lifecycle"
Author              " Computer world "
Published          2009 approximately
Access Date    12th February 2010

URL                 '""
Title                  "Life cycle stages"
Author              "Unknown"
Published          2009 approximately
Access Date     14th February 2010

URL                  ""
Title                  "Design-methodology-and-system-lifecycle"
Author               "Unknown"
Published           2009 approximately
Access Date      14th February 2010