What is a Systems 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 LIFE CYCLE is a term used to describe the stages in an IT project. These are:
1.) Definition of the problem
Before a project can begin, there has to be a reason why it should take place. You have to define the problem that the system is meant to be overcome. This phase is called the 'Problem definition phase'. Some formal effort is made to define exactly what the problem is. For example the following statements may appear in the Problem Definition. The existing system cannot transfer data to the new invoice system, staff have to spend three hours loading information or new legislation insist that financial records are kept for this department and so on.
Methods of defining a problem:
-> Interview employees about their issues with the current system
-> Analysing the total costs of the current system
-> Key external factors that may point towards developing a new system.
-> Performance of the existing system.
2.) Feasibility Study
It is one thing to define the problem with an existing system. The next question is what are the alternatives - what are the broad avenues that may be taken? It is very rare that any company will have just one possible solution open to them.
This is the 'Feasibility Study Phase' of the Systems Life Cycle model.
In this phase, alternative solutions are examined. The costs Vs the benefits are compared in order to see which would best suit the company taking into consideration their requirements and the funds available. In order to arrive at a final decision, sometimes a trade-off has to be accepted e.g. less functionality for less cash.
Consider three imaginary (very brief!) 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 retained, whilst the least efficient aspects are redesigned to enhance performance.
Cost: Moderate, training moderate.
Performance improvement: 30%
c) Complete overhaul
Benefit: Reduces company cost base (more profitable).
Cost: High, given that new equipment / software will be required. Training for staff needed.
Performance: 70% improvement over the old system.
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. So at this point of the system life cycle, you know what the problem is and you are considering options. The various options are usually presented to management at this stage and it is up to them to make a decision as to how much cash they want to inject into the project. Once a decision has been made, the next phase is to analyze that option in greater detail.
3.) Investigation and Analysis
The management have taken the decision to proceed with the project. The next phase is called the 'Investigation and Analysis' phase. First you define how the old system works (investigation) and the problem(s) it is causing.
This is done by a variety of techniques that include:
-> Questionnaires and interviews
-> Observing people actually using the existing system
-> 'Paper trail' : Following information from the point it enters the system and observing what outputs are created at each point in the system.
-> Noting how / why the defined problem happens.
The investigation part confirms that the true cause of the problem has been correctly defined.
It also confirms that the project will overcome the problem. The next part is to carefully analyse how the existing system works: Not necessarily the hardware or software - but more about how information is handled and how people interact with it. As all this needs to be communicated efficiently to all concerned, a number of standard diagrams / methods are used.
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.
Data Flow Diagrams:
Most systems deal with information in one way or another. What really matters is how the information flows through the system. How does it branch and re-join. What outputs are created and so on.
The 'data flow' diagram seeks to show this movement through the system.
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 authorises payment and so on...This is 'process flow' in action.
Process diagrams try to show how people interact with the system - who and when (and why).
4.) Design
Now that the project manager and the client have agreed on the requirements (Requirements Specification), it is time to define how the project is going to be carried out.
This is the Design phase of the project.
In this phase the exact details are defined, for example:
-> The data inputs
-> The data outputs
-> Any documents that are printed out
-> What happens to the data as it flows through the system (procedures)
-> The structure of any files that store data.
-> How information is accessed and indexed or sorted.
-> The operating system to be used
-> The hardware to be used.
And so on ....
So the design phase is really useful for the IT programmers who have to create the system.
Another aspect of creating a system is how are you going to test it?
It is tempting to leave the testing considerations until after the system has been developed but for the people having to develop the system it is really useful to have a test procedure in place before even starting to write a line of code or to design the hardware. This is because you know how it will be tested and so it guides you towards a good design.
-> Prototyping
A 'prototype' is something that represents what you will finally create without having to worry about all the details - it captures the essential details to confirm that the design is likely to work. In software, the prototype is often written in a kind of shorthand English 'Read in the record'. The details do not matter at this stage, but a record must be 'read in'. In hardware, you can test the system on a much cheaper slow computer, knowing that you will be able to run much faster on the final design - but it proves that the system works in principle. The master document that is created in this phase is the 'Systems Requirement Document' In a way, this is the contract between the project managers and the development team.
5.) Development (programming)
Now that the client has agreed on what needs to be done (Requirements Specification), and the Analyst has defined precisely what needs to be done (Systems Requirement Document) - it is time for the project to be actually developed.
The development stage is about taking the design forward and putting it into practice
One thing to note though, is that there may be several teams involved at this stage - so it is sensible to break down the Systems Requirement document into chunks that each teams can develop. It is no use informing the hardware team of the software requirements or vice versa.
At this stage the following things may take place (depending on the how extensive the project is) :
-> The software developers write code
-> The hardware people develop equipment
-> The testing team develop test plans
-> The user-testing groups follow the test plans and check that the system works as expected. If not an error report is sent to the developers and corrections are made. The test is then performed again.
6.) Testing and Implementation
This is an interesting time.... the implementation stage has been reached. The system has been developed and tested. It is working correctly and doing everything that was agreed during the design stage. The business is waiting in eager anticipation for the new system to be handed over to them.
The key events in this stage are:
-> DATA CONVERSION
-> Data stored in files on the old system are now converted into the correct format for the new system.
-> SYSTEM CHANGE-OVER
-> Now it is time to switch off the old system and turn on the new.
-> It sounds simple, but most of the time it isn't!
What are the alternatives?
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 is the 'phased approach' to system testing. Imagine a system so sensitive to change that only a very careful change can be considered.
Example: A new air traffic control system.
Neither of the other two approaches would be suitable for such a critical system.
-> TRAINING
It is at the implementation stage that staff training takes place. Staff need to be shown how to use the new system and how to access help should they run into difficulties. There may be member of the development team on call for a short period of time or there may be a dedicated help line that staff can ring to get answers.
There will most definitely be a user manual to act as a source of reference.
7.) Evaluation
The implementation stage is over: The system is up and running, Staff are fully trained and bugs have been ironed out.
This new stage is called the 'Evaluation phase'
It is at this point two key questions are considered:
-> Does the finished solution meet its requirements?
-> Does it solve the problem?
These questions are answered by considering details written down in the original Requirements Specification and comparing it to the performance of the new system.
8.) Maintenance
The Evaluation stage is over and the system is running smoothly. However as time passes, it will no doubt need to be looked after.
This is the Maintenance phase of the Systems Life Cycle.
At this stage the following takes place:
-> Problems are cleared as they arise
-> Tweaks to the system are applied to improve performance
-> New circumstances might arise such as an office move. The system has to be moved.
-> Data is backed up and kept safe.
-> Printers, Monitors and other equipment are replaced as required.
This phase never really ends until the Life Cycle of the system is complete i.e. the system is switched off for the last time and a replacement system is introduced.
A Life Cycle Scenario in an Institution …
All things have a beginning, middle and an end. Just so, for an IT system. At some point in the past a wonderful new system was introduced into the company. Everyone was happy. Management could see their business improve. The workflow for employees was smoother and more productive. After the first few months of bedding in, the system worked well... and for a few years the system did everything it was meant to do.Time passed, people moved on, the company changed ... that wonderful system began to show its age... the new manufacturing system had problems exchanging data. Customer invoices no longer flowed effortlessly from their new system into your aging computers. Workers grew tired of using black screens with green text - even their home computers were more modern than this! It was time for a change. And so the life cycle of the system was complete.
Notice that the term 'life cycle' is used. This is because the process never really ends. Systems are created, they become mature, they grow old and are replaced by new ones. It is a cycle.
Why an Institution should consider a New System?
Why do institutions want to change their systems? After all, they have spent a fortune on developing their existing one. All the staff knows how to use it. The technicians know how to fix it. Management understands its capabilities.
As you can imagine, changing things is an expensive, risky undertaking. Staff will have to re-train. Equipment will have to be replaced. Offices may need to be re-wired causing disruption to every-day work.
Some of the reasons for introducing a new system may be:
1. The current system may no longer be suitable for its purpose.
Changes in the way work is carried out means the system is no longer suitable
Happily, the business has grown. Starting out with only ten staff a few short years ago, the system could easily cope with the workload. But now there are a thousand staff in many offices around the world. The system just can't cope
External influences. For example, new regulations have come along which insist that certain records are kept for years. The existing system was never designed for this.
2. Technological developments may have made the current system redundant or outdated.
Competitors are using more advanced systems that perhaps reduce their costs compared to yours, thus placing the company at a disadvantage.
Customers use more modern systems and insist that you upgrade yours to allow for easier data transfer.
The software supplier has warned that the version you are using will no longer be supported after next year. You have to plan for change.
3. The current system may be too inflexible or expensive to maintain.
A company has to to be able to cope with changing circumstances and this includes having the systems in place to deliver what the customer needs at the least internal cost.
For example, the customer has changed the way it sends data to its suppliers - you - and now your employees are having to manually type in invoices because the system cannot cope with the new format. Added costs, less profit, less competitive. Time for a new system.
Internal Factors
-> Reorganisation
When new departments are created or new managers appointed, new systems may be required to support new functionality or new ideas.
-> Users
People who use the systems on a regular basis can become frustrated or dissatisfied with their existing system. This can be due to a number of reasons e.g. constant errors, slowness of the system, inability to deal with new processes.
->New Initiatives
When new products are launched, new systems may be required to support them.
External Factors
-> Legislation
Governments may introduce new laws or requirements that must be complied with.
->Competition
A new market opportunity may be identified.
->Economics
A change in the economic climate may lead to organisational restructuring.
Why System Life Cycle is needed?
As was mentioned in the previous page - change is risky. IT change is particularly risky! Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):
-> 80-90% of systems fail to meet performance goals
-> 80% of systems are late and over budget
-> 40% of systems fail or are abandoned
-> Less than 40% of businesses fully address training and skills requirements
-> Less than 25% properly integrate business and technology objectives
-> Just 10-20% of businesses meet all their success criteria.
Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.These are the possible queries that will be raised up to achieve change. What could have been done better? What could reduce the chances of failure? As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximize the chances of a successful project. This method / model are called the SYSTEMS LIFE CYCLE.
It consists of a series of stages that take a project from its very first stages to the final outcome of a fully working, fully integrated system.
Considering now the University…
How do I know that the life cycle was developed specifically for the university? How do we know it meets our needs?
A life cycle is truly developed in our university by means of so many improvements in any department that optimizes processing methods to meet a certain goal of a task. As a result, this gives us all ease whenever we are going through these processes. The innovations in our university follows the stages of an IT project mentioned prior to this. Therefore it follows a cycle. And as of now, as we all know, there’s a lot more prospect projects that will come out from the brilliant ideas of many to solve existing constraints in the field of processes in this university.
Sources:
http://www.didcotgirls.oxon.sch.uk/depts/it/gcse/notes/effects/notes.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/the_systems_cycle.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/why_bother.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/what_prompts_a_new_system.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/definition_of_the_problem.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/feasibility_study.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/investigation_and_analysis.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/design.htm
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/development.htm
No comments:
Post a Comment