Wall-e and 9 movie
-
Watch at least two of the following movies:
• Make a comprehensive reaction paper for the two movies in no less than
300 words each.
• Make a comparative ...
13 years ago
Friday, December 18, 2009
All things have a beginning, a 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. 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.
Why do companies 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-trained. 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.
Change is risky.
IT change is particularly risky!
Consider the sobering results obtained from a survey of over 14,000 organisations (OASIG study):
Therefore only between 1 in 5 and 1 in 10 of the IT projects in the survey were successful.
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 is 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.
The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
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.
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 is the problem.
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...
... New legislation insist that financial records are kept for this department ...
And so on.
Methods of defining a problem:
Once the problem definition stage is over, then if the decision is to carry on with the project the next phase is the '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 analyse that option in greater detail.
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:
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).
Having undertaken a thorough investigation and analysis phase, the next stage is to create the 'Requirements Document'
This document does not define the hardware or software design but rather seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:
1) An introduction.
Example:
The project has been developed in order to create a new invoicing system to replace the AIX400 computer system...
The introduction gives a broad description of the project and its aspirations.
2) Context
This section provides the background to the project.
Example:
The project was developed in light of the up-coming new regulations and also the increasing awareness that the existing system could no longer meet customer expectations ....
3) Specific Details required
Having provided a broad description and some context to the project, this section deals with specific things that need to be included in the system.
Example:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.
These specific requirements are all measurable. You should not have vague statements such as "The computer will run as fast as possible..." because you cannot know if 'as fast as possible' has been met when the system finally gets switched on.
Sometimes in a complicated project this section can be sub-divided into smaller sections such as:
And so on.
The Requirements Specification is the 'contract' between project managers and the client. It will be used at the testing stage to confirm that the system performs as the client expects.
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 :-
This is all about the nitty-gritty detail. Once again this phase is trying to define the system in ever greater detail.
Think of the advantages of this phase - if you were the software engineer which would you rather have given to you as a job on a Monday morning?:-
Useless specification ! :-
a) Create a big file on the hard disk that will store all the invoices.
or
Useful, specific details...
b) The invoice file shall include a data record consisting of:-
1. Customer ID (3 digit alpha code)
2. Invoice number (9 digit number)
3. Value of item (displayed as currency)
4. .... yet more detail....
If you were the poor engineer given specification (a) the chances are you would not know where to start as you are bound to get it wrong!
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.
Example:
The input form shall reject
- any number greater than 1000
- any number less than zero
- any text
The input form shall accept
- any customer id and password the database already recognises
- shall jump to a 'new customer' screen (see details *** ) if it does not recognise the customer id.
Can you see why having this detail in the design phase would be useful to the project team?
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.
Time to do the work!
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) : -
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.
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.
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 and the client review whether or not the project has been completed successfully.
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:
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.
As you may now realise, the System Life Cycle model has been developed to make it more likely that projects are completed as planned, within budget and on time. However, even with this rigorous process, there are no guarantees that a project will succeed.
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
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. 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.
Why do companies 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-trained. 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.
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.
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 is 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.
The SYSTEMS LIFE CYCLE is a term used to describe the stages in an IT project. These are:
- Definition of the problem
- Feasibility Study
- Investigation and Analysis
- Design
- Development (programming)
- Testing
- Implementation
- Evaluation
- Maintenance
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.
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 is the problem.
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...
... 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.
Once the problem definition stage is over, then if the decision is to carry on with the project the next phase is the '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 analyse that option in greater detail.
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).
Having undertaken a thorough investigation and analysis phase, the next stage is to create the 'Requirements Document'
This document does not define the hardware or software design but rather seeks to capture the essence of what needs to be done.
Some fairly standard headings within the document are:
1) An introduction.
Example:
The project has been developed in order to create a new invoicing system to replace the AIX400 computer system...
The introduction gives a broad description of the project and its aspirations.
2) Context
This section provides the background to the project.
Example:
The project was developed in light of the up-coming new regulations and also the increasing awareness that the existing system could no longer meet customer expectations ....
3) Specific Details required
Having provided a broad description and some context to the project, this section deals with specific things that need to be included in the system.
Example:
The system will be able to use a query to create a mail merged personalised letter.
The system must create an invoice in less than 3 seconds
The system will be able to print a management report onto A4 paper, portrait layout.
These specific requirements are all measurable. You should not have vague statements such as "The computer will run as fast as possible..." because you cannot know if 'as fast as possible' has been met when the system finally gets switched on.
Sometimes in a complicated project this section can be sub-divided into smaller sections such as:
- Its functions
- Its expected performance
- How it connects to other systems
- How it is going to be maintained, kept secure. Its expected reliability.
And so on.
The Requirements Specification is the 'contract' between project managers and the client. It will be used at the testing stage to confirm that the system performs as the client expects.
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
- Screen layouts
- 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.
This is all about the nitty-gritty detail. Once again this phase is trying to define the system in ever greater detail.
Think of the advantages of this phase - if you were the software engineer which would you rather have given to you as a job on a Monday morning?:-
Useless specification ! :-
a) Create a big file on the hard disk that will store all the invoices.
or
Useful, specific details...
b) The invoice file shall include a data record consisting of:-
1. Customer ID (3 digit alpha code)
2. Invoice number (9 digit number)
3. Value of item (displayed as currency)
4. .... yet more detail....
If you were the poor engineer given specification (a) the chances are you would not know where to start as you are bound to get it wrong!
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.
Example:
The input form shall reject
- any number greater than 1000
- any number less than zero
- any text
The input form shall accept
- any customer id and password the database already recognises
- shall jump to a 'new customer' screen (see details *** ) if it does not recognise the customer id.
Can you see why having this detail in the design phase would be useful to the project team?
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.
Time to do the work!
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.
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.
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.
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 and the client review whether or not the project has been completed successfully.
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.
As you may now realise, the System Life Cycle model has been developed to make it more likely that projects are completed as planned, within budget and on time. However, even with this rigorous process, there are no guarantees that a project will succeed.
http://www.teach-ict.com/as_a2/topics/system_life_cycle/slc/index.htm
0 Comments:
Subscribe to:
Post Comments (Atom)
