Systems Life Cycle
INTRODUCTION
Systems are created to solve problems. One can think of the systems approach as an organized way of dealing with a problem. In this dynamic world, the subject System Analysis and Design mainly deals with the software development activities.
OBJECTIVES
After going through this unit, you should be able to:
- understand a system
- understand the different phases of system developments life cycle
- know the components of system analysis
- know the components of system designing
Defining a System
A collection of components that work together to realize some objective forms a system. Basically there are three major components in every system, namely input, processing and output.
In a system the different components are connected with each other and they are interdependent. For example, Human body represents a complete natural system. The objective of the system demands that some output is produced as a result of processing the suitable inputs.
SYSTEM DEVELOPMENT LIFE CYCLE
The Software Development Lifecycle (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.
Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.
In general, an SDLC methodology follows the following steps:
· The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
· The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
· The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
· The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
· 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.
· 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.
System Study
System study is the first stage of system development life cycle. This gives a clear picture of what actually the physical system is? In practice, the system study is done in two phases. In the first phase, the preliminary survey of the system is done which helps in identifying the scope of the system. The second phase of the system study is more detailed and in-depth study in which the identification of user’s requirement and the limitations and problems of the present system are studied. After completing the system study, a system proposal is prepared by the System Analyst (who studies the system) and placed before the user. The proposed system contains the findings of the present system and recommendations to overcome the limitations and problems of the present system in the light of the user’s requirements.
To describe the system study phase more analytically, we would say that system study phase passes through the following steps:
- problem identification and project initiation
- background analysis
- inference or findings
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 (very brief!) alternatives that a company could choose from:
1. Company does not change anything
a. Benefit: No disruption to the business. Least cost.
b. Performance: No change, system remains outdated. Process becomes increasingly less efficient.
2. Company makes alterations to half the system
a. Benefit: Best parts of the system are kept, whilst the least efficient parts are redesigned to improve performance.
b. Cost: Moderate, training moderate.
c. Performance improvement: 30%
3. Complete overhaul
a. Benefit: Reduces running costs for the company (more profitable).
b. Cost: High, given that new equipment / software will be required. Training for staff needed.
c. 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.
Investigation
The management has taken the decision to proceed with the project.
The next stage is called the 'Investigation and Analysis' phase.
First you investigate how the old system works and the problem(s) it is causing and then you analyze it to see how you can solve these problems.
During the investigation, you would use a variety of techniques to find out about how the current system works in great detail:
Questionnaires
With large groups of people, a
questionnaire is a quick and
simple way to gather information.
However the information gathered is limited
by the questions set by the systems analyst (people could have a lot of useful
information in their heads, but if the questionnaire doesn’t ask the right questions, they will not be able
to pass it on). Also many people do not take the time to fill in questionnaires seriously.
Interviews
The
systems analyst can interview key
people within the system to find out how it works.
Interviews allow lots of very detailed
information to be gathered, but they take a long time to do, so are not possible if large groups of people
are involved.
Observing people doing their job
This involves the systems analyst walking around the organization or business, watching how things work with his/her own eyes. Observation allows the systems analyst to gather first-hand, unbiased information. The downside to observation is that often people won't work the way they normally do if they know they are being watched.
During the investigation, you would use a variety of techniques to find out about how the current system works in great detail:
1. Following a paper trail through the system - finding out what happens to a document at each stage.
2. System diagrams: These show the relationships between the various systems in the company (or even outside if relevant) - how they interact, what depends on what and so on.
3. Data Flow Diagrams: Most systems deal with information in one way or another. What really matters is how the information flows through the system.
4. Process diagrams: People handle information in a specific way - they have a 'process'. For example, an employee makes an expense claim. First of all their manager counter-signs the claim. It then goes to the account manager who authorizes payment and so on. A process diagram will try to show these processes in action.
Analysis
The second stage of the 'investigation and analysis' stage is the analysis.
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.
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.
Design
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.
Development
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.
Testing
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.
Implementation
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:
Direct Changeover- Switch off the old system and switch on the new.
Parallel Running- You run the old and new system in parallel for a time.
Phased Implementation- You run only part of the new system
Direct Changeover
The old system is stopped completely, and the new system is started. All of the data that used to be input into the old system, now goes into the new one.
This is has its advantages...
Takes the minimal time and effort
The new system is up and running immediately
But there are also disadvantages...
If the new system fails, there is no back-up system, so data can be lost
Parallel Running
The
new system is started, but the old system is kept running in parallel (side-by-side) for a while. All of the
data that is input into the old system, is also input into the new one.
Eventually, the old system will be stopped, but only when the new system has
been proven to work.
This is has its advantages...
If anything goes wrong with the new system, the old system will act as a back-up.
The outputs from the old and new systems can be compared to check that the new system is running correctly
But there are also disadvantages...
Entering data into two systems, and running two systems together, takes a lot of extra time and effort
Phased Implementation
The new system is introduced in phases (stages, or steps), gradually replacing parts of the old system until eventually, the new system has taken over.
This is has its advantages..
Allows users to gradually get used to the new system
Staff training can be done in stages
But there are also disadvantages...
If a part of the new system fails, there is no back-up system, so data can be lost
Documentation
There are two types of documentation that should be produced when creating a new system:
1. User documentation
2. Technical documentation
User Documentation
The
user documentation is intended to help the users of the system. The users are usually non-technical people, who don't need to know how the system works.
They just need to know how to use it.
User documentation usually includes:
· List of minimum hardware and software required to use the system
· How to install the system
· How to start / stop the system
· How to use the features of the system
· Screenshots showing the system in typical use
· Example inputs and outputs
· Explanations of any error messages that might be shown
· A troubleshooting guide
Technical Documentation
The
technical documentation is intended to help the maintainers of the system (the people who need to keep the system
running smoothly, fix problems, etc.)
The maintainers are usually technical people,
who need to know exactly how the system
works.
Technical documentation usually includes:
· Details of the hardware and software required for the system
· Details of data structures (data types, field names, etc.)
· Details of expected inputs
· Details of validation checks
· Details of how data is processed
· Diagrams showing how data moves through the system
· Flowcharts describing how the system works
Evaluation
When
the systems analyst evaluates the new system, the following questions will be
asked:
Is the system...
...efficient?
Does it operate quickly, smoothly and with minimal waste?
Is the system saving time, and resources?
...easy to use?
Are all of the system's users able to use the system easily and effectively?
Can new staff understand and use the system with minimal training?
...appropriate?
Is the system suitable for the particular business / organization?
Does the system actually meet the needs of the business / organization?
How is a System Evaluated?
The systems analyst will use a number of techniques to evaluate the system...
1. Check against the Requirements Specification
If
you remember, earlier on in the Systems Analysis, the old system was analyzed, and a checklist of targets was drawn up for
the new system.
This list was called the Requirements Specification.
The systems analyst will use this document to check the new system. Going
through the requirements
one-by-one the analyst will check if they have been met.
2. Check the Users' Responses
It is essential to get feedback from the users of the system...
· Do they like it?
· Does it make their work easier?
· What, if anything, could be improved?
The systems analyst can get this feedback in the same way they collected information about the original system…
· Questionnaires
· Interviews
· Observations
Maintenance
Once the system has been installed and is up and running, there will be a need to keep maintaining it:
Over time, bugs will be discovered that weren't picked up in the testing. These will need to be fixed.
Staff or developers will identify parts of the system which could be tweaked to work more efficiently.
Larger changes might need to be made to the system. Perhaps extra functionality or maybe changes in working practices or the law might mean that parts of the system have to be altered.
