System Development Life Cycle


 

Wolmer’s Trust High School for Girls

CAPE COMPUTER SCIENCE (UNIT 2)

 

Upper and Lower Six                                     Teacher:  Mrs. McCallum-Rodney

 

SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

 

INTRODUCTION

At some stage, most businesses will need a new computerised system to help them with their day to day tasks.

This could be a system to keep track of all the students' names, addresses, telephone numbers and grades, or it could be a new system for an online bank to let customers open a new account.

No matter what the system might be, if the organisation doesn't conduct a system life cycle, they are likely to find that their new system disappoints them and doesn't solve the original problem.

Analysts take a systematic approach to the analysis and design of information systems.  This is embodied in what we refer to as the System Development Life Cycle (SDLC).

 

PHASES IN THE SYSTEM DEVELOPMENT LIFE CYCLE

1.      Feasibility Study

2.      Identifying problems, opportunities, and objectives.

3.      Determining information requirements

4.      Analyzing system needs

5.      Designing the recommended system.

6.      Developing documenting software.

7.      Testing and maintaining the system.

8.      Implementing and evaluating the system.

 

 

1.      FEASIBILITY STUDY

During this stage, the company has to decide firstly whether there is a need for the system and secondly, if there is a need, can the cost of the system be justified against the benefits that it will bring.

Consider three imaginary alternatives that a company could choose from:

a) Company does not change anything

Benefit: No disruption to the business. Least cost.

Performance: No change, system remains outdated.  Process becomes increasingly less efficient.

b) Company makes alterations to half the system

Benefit: Best parts of the system are kept, whilst the least efficient parts are redesigned to improve performance.

Cost: Moderate, training moderate.

Performance improvement: 30%

c) Complete overhaul

Benefit: Reduces running costs for the company (more profitable).

Cost: High, given that new equipment / software will be required.  Training for staff needed.

Performance: 70% improvement over the old system in time.

As you can see, deciding on the best alternative is often not simple - management have to take many factors into account. There are often complicated relationships between cost, performance and benefit.

2.      IDENTIFYING PROBLEMS, OPPORTUNITIES AND OBJECTIVES

         This stage is critical to the success of the rest of the project, since no one wants to waste subsequent time addressing the wrong problem.

 

         The analyst will need to look honestly at what is occurring in a business.  So that problems can be pinpointed.  These problems will be brought up by others (such as organizational members), and they are the reason the analyst was called in.

         Opportunities are situations that the analyst believes can be improved upon through the use of computerized information systems. 

         Seizing opportunities may allow the business to gain a competitive edge or set industry standards.

         The analyst will have to first identify what the business is trying to do. 

         Then the analyst will be able to see if some aspect of information system application can help the business reach its objectives by addressing specific problems or opportunities.

 

3.      DETERMINING INFORMATION REQUIREMENTS

 An investigation on how the old system works and the problem(s) it is causing is done and then you analyse it to see how you can solve these problems.  The analyst must ask why the business uses the current system.   There may be good reasons for using the current method, and these should be considered when designing any system.

During the investigation, you would use a variety of techniques to find out about how the current system works in great detail:

- Questionnaires

- Interviews

- Observing people doing their job

- Following a paper trail through the system - finding out what happens to a document at each stage.

This phase focuses on determining the information requirement for the particular user involved.

Some of the tools used to define information requirements in a business are:

*      Sampling and investigating hard data.

*      Interviewing

*      Questionnaires

*      Observing decision makers’ behaviour and office environment

*      Prototyping (this will include some but not all features, one that, if successful, will eventually be part of the larger, final system that is delivered)

Analysts are trying to understand what information the users need to perform their jobs.

The systems analyst needs to know the details of current function

*      The who (the people who are involved)

*      The what (The business activities)

*      Where (the environment in which the work takes place)

*      When (the timing), and

*      How (how the current procedures are performed)

Once the investigation has been completed you will have a pretty good idea what is causing the problems with the current system and what the improved system should be able to do.

4.   ANALYSING THE SYSTEMS NEEDS

The analysis phase is where you look at alternative solutions which could be used to solve the problems.

Some of the solutions could include:

- adapt the current system. There are bound to be bits that are good with it so perhaps keep those and look at changing the things which aren't working

- buy an 'off-the-shelf' solution. Perhaps use it as it comes or pay to have parts of it adapted to suit your company

- create a bespoke system which will fit the company needs exactly. This is the most expensive solution.

Special tools and techniques help the analyst make requirements determinations.

·         One such tool is a Data Flow Diagram, to chart inputs, processes, and output of the business’ functions in a structured graphical form.

·         From the Data Flow Diagram, a Data Dictionary is developed that lists all of the data items used in the system, as well as their specifications – whether they are alphanumeric or text, how much space they take up when printed.

At this point of the SDLC, the systems analyst prepares a system proposal that summarizes

o        what has been found

o       provides cost/benefit analyses of alternatives

o       Makes recommendations on what should be done

 

5.   DESIGNING THE RECOMMMENDED SYSTEM

Now that the business analyst has a clear idea of how the system should work, this next phase is when the system is designed.

Here are some of the decisions that are taken during the design phase:

  • The screen layout is designed

  • The error messages are written

  • The way that you will navigate from one page to another is defined

  • The menu buttons are chosen

  • The font style, size and colour are picked

  • How data will be dealt with is specified

  • What documents can be printed out

  • The hardware will be needed

It is during this phase that the requirements specification and the systems specification are written.

The requirements specification details how the system will work, how data will flow through it and what it will look like to the user.

The system specification details the hardware and software that will be needed to run the system.

 

6.   DEVELOPING AND DOCUMENTING SOFTWARE

 This phase is where the system starts to be written by the software programmers. They follow the requirements specification from the design stage and start to create the new system.

The main things that take place during this phase are:

  • The programmers write and test the code for the system  

  • A team ensure that the hardware and software required to run the new system are purchased and in place.  

  • A team of testers are assembled in readiness to test the new system. They start to write a test plan which details all of the tests that they will carry out.  

  • In this phase the analyst works with programmers to develop the original software that is needed. 

  • Some of the structured techniques for designing and documenting software include: 

    • Structured charts
    • Psuedocodes

 The systems analyst uses one or more of these devices to communicate to the programmer what need to be programmed.

  • The analyst also works with the user to develop effective documentation for software, including manual, online help, Web Site featuring Frequently Asked Question (FAQ), on “Read Me” files shipped with new software. 

  • Documentation tells users how to use the software and also what to do if software problems occur. 

  • Programmers have a key role in this phase because they design, code, and remove syntactical errors from computer programs. 

  • To ensure quality, a programmer may conduct either a design or a code walkthrough, explaining complex portions of the program to a team of other programmers (technical documentation). 

7.   TESTING AND MAINTAINING THE SYSTEM

Once the system has been coded, it needs to be thoroughly tested by a team of testers.

A test plan will have been written whilst the system is being developed.

The test plan will contain details of every single thing which needs to be tested. For example:

- The system opens and closes properly

- Work can be saved

- Work can be printed

- Data is saved to the correct place

- When you do something wrong, an error message appears

- Data which isn't allowed will be rejected e.g. if you are not allowed to enter an amount above £1,000 on the system then a value of 1,001 will not be allowed.

Before the information can be used, it must be tested.

It is way less costly to locate problems before the system is signed over to users.

Some of the testing is completed by programmers alone, some by systems analyst in conjunction with programmers.

Sample data and eventually actual data from the current system is used in testing the program.

Maintenance of the system and its documentation begins in this phase and is carried out routinely throughout the life of the information system.

 8.  IMPLEMENTING AND EVALUATING THE SYSTEM

The system has now been tested and everyone is happy that it is working correctly. It now needs to be installed so that staff can use it. There are three different ways that you can implement (install) a new system:

1) Switch off the old system and switch on the new.

Of course, this is the simplest scenario!  All the workers are waiting for the fabulous new system to come 'on -line' but as the minutes tick by, a new customer has just ordered a holiday / medical operation / flight / mortgage.

How do you deal with these last-minute (but vital) clients?

Answer: You must deal with last minute changes and accept that there may be some upheaval and mistakes made in the short term.

2) You run the old and new system in parallel for a time.

A popular method compared to the switch off / switch on approach. After all, the customer does not care what your IT system is made up of - they are only (rightly) concerned with their holiday / medical operation / mortgage etc being booked correctly.

And so, a popular method is to allow the old system to run alongside the new one. Then in the quiet period (say overnight) , the new system absorbs all the old system's information. By the next morning, the system is fully loaded and ready to go.

3) You run only part of the new system

This can be done by introducing the whole system to just a couple of branches and checking how it works and quickly fixing any bugs that are found. Once things are running smoothly the system will be introduced to the rest of the company.

Or it could be that just parts (modules) of the system are introduced at a time. As they are found to work, further parts are released.

Now that the system is up and running for real, it is important to evaluate it.

It is at this point two key questions are considered:

·         Does the finished system do what it is supposed to?

·         Does it solve the problem that was found in the first place?

These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.

For example:

·         Requirements specification states that the system should be able read the data file in less than 3 seconds. 

Question: Does the system meet this specification?

Answer: Yes, the data file is read in 2.8 seconds.

In a complicated project, there may be hundreds of requirements specified.  It could take many weeks to complete the evaluation phase.

The project manager has to review whether or not the project has been completed successfully.

If a company follows all of these stages in the correct order, then their new system should be successful and worth the investment of time and money.

CLASS ACTIVITIES

1.      A software company has just finished developing a new database system.  Before it can be handed over to the customer, the system will need to be tested.

a.       Explain why it is important that any system is thoroughly tested before release.

b.      Which document will need to be created for use during the testing phase?

2.      When testing a new system, it is important to use typical (normal), extreme and erroneous data.  What is meant by the term “erroneous data” and provide an example.

3.      Once a new system has been developed it will need to be fully tested using a range of data.  Explain what the term “extreme data” means and provide a relevant example.

Make a Free Website with Yola.