1. 3.3.1

2. A brief look at the components that make up the system life cycle.

3. Large system development projects may involve a lot of people working over several months or years and on different parts of a project. This means they can’t be allowed to work in an ad-hoc, haphazard, fashion. The goals of a project must be thoroughly understood and formal procedures and methods must be applied to ensure projects are delivered on time and meet all requirements.

4. There are problems with working on a project if you don’t have a plan: – How can you produce a good project if you aren’t sure about the problem? – How can a project be built if it is not designed? – How can it be installed if it is not tested properly? – If a project leader leaves and someone takes over how can they effectively manage the project without knowing what work has been done and at what stage the project is at? – How can changes be made to a project if the documentation is incomplete?

5. The systems life cycle ensures that people are working in a very organised, methodical, manner. Each stage is composed of certain well-defined activities and responsibilities and each stage must be completed before they next stage begins. There are different models of the system life cycle but most contain 5-7 stages.

6. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

7. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

8. The feasibility study is the first stage of the system’s life cycle. When a problem is recognised and identified the feasibility study is initiated. The purpose of the feasibility study is to fully understand the problem and to work out if the problem is worth fixing.

10. This involves looking at: – whether the technology exists to implement the proposed system; or – whether this is a practical proposition;

11. This involves establishing the cost- effectiveness of the proposed system. If the benefits do not outweigh the cost then the project is not worth going ahead with.

12. This part of the feasibility study checks to see if the proposed system falls within legal guidelines. For example, would the new system contravene the data protection act?

13. This is concerned with whether the current work practices and procedures are adequate to support the new system. It is also concerned with social factors – How the organisational change will affect the working lives of those affected by the system.

14. This looks at how long the system will take to develop, or whether it can be done in a desired time-frame.

15. At the end of this stage a feasibility report is produced by a systems analyst. If the report concludes that the project should go ahead, and this is agreed by the senior managers, then a detailed requirements analysis will be produced.

16. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

17. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

18. This is a more detailed report which focuses on the current system and the requirements of the new proposed system. It is the systems analyst’s job to find out about current methods, user requirements and to assess the feasibility of a project.

19. Gathering details about the current system might involve: – Interviewing staff from different levels of the organisation from end users to senior managers. – Examining current business and systems documents and outputs. – Sending out questionnaires and analysing responses. – Observations of current procedures from different departments.

20. The analysis report will: – examine how data and information flows through an organisation. – explain what the proposed system will do (not how it will do it). – show detailed costs and benefits. – explain how the system will be implemented. – explain who the end users are, what information they will get and in what form.

21. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

22. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

23. The feasibility and the analysis stages are all about solving the problem. By the time these stages are complete the people working on the project will: – Understand the business and operations in detail – Understand the problem area in detail – Have agreed with the customer what they want the new system to do – Have outlined the solution

24. The design stage is about the creative solution to the problem. There might be multiple solutions or just one. In the event of multiple solutions further analysis might be required to work out which would be the best solution.

25. There should be a description of the overall design using diagrams and comments. The user interface should be designed. All reports and screens and navigation systems should be designed. Data validation rules and verification procedures should be specified.

26. Data volumes should be calculated and storage and back-up defined. Functional descriptions of all procedures, modules, functions etc should be produced. A complete test plan with the data to be used and predicted outputs should be done.

27. An effective design would allow you to give the design documentation to any programmer or builder of the system to recreate it exactly. The programmer/builder shouldn’t need any help other than what is within the design documentation.

28. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

29. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

30. During this process the project development team will use the design documentation to create the actual product. This stage should not be confused with the installation of the actual product which involves taking the finished product and installing it on the customer’s premises. This stage can only be successful if the design stage was carried out properly.

31. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

32. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

33. Testing should follow the test plan which was laid out in the design documentation and should always be carried out. The reasons: – A company needs to ensure their reputation for developing good systems is intact. – A good program will gain in popularity only if customers see it as a good program. – A bad system will mean that system will be avoided in the future and perhaps customers won’t pay for your services. – A system that causes accidents may lead to legal problems.

34. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

35. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

36. Once a system has been built and tested it needs to be installed in a way that ensures minimal disruption to the customer. Things that should be considered: – Staff training – can they use the system straight away? – How do you get all the current data on the old system onto the new system – how long will it take? Is it transferable in it’s current format? – The hardware/software for the new system must be in place. Any additional hardware/software required for the system will need to be bought and stored safely until it is needed.

37. That are four strategies that you could employ: StrategiesParallel runningPilot runningDirect changeoverPhased implementation

38. In this instance the old system runs along side the new system. This allows the new system to prove it works before shutting down the old system. It gives staff an opportunity to get used to the new system but it means doubling the work load as you have to input data into both systems. Once everything checks out…then the old system can be shut down.

39. This is similar to parallel running but with a difference. Instead of both systems running together at the same time, only a portion of the new system will be running in parallel. When one portion checks out ok then another portion of the new system is piloted. The term pilot running can also be used when a large organisation changes systems over time. – For example, a supermarket chain might install new checkout systems in a few branches to make sure it works before installing them in the remaining branches.

40. This is where you shut down the old system and start operating the new system straight away. Staff training needs to take place in advanced but overall workload shouldn’t be affected. The problem with this method is that if something goes wrong then the system will need to be fixed as soon as possible because you can’t fall back on the old system.

41. During a phased implementation, parts of the new system replace parts of the old system. Parts of the new system can then be used for staff training and can prove itself before the next part of the new system is installed. This method takes a long time compared to direct changeover.

42. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

43. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

44. During this process system documentation is created for the end user. These documents might inform the end user about: – Program specifications – What to do if the system crashes – Security details – How to use the system (user guide/manual) You could break this down into two types of documents: – User documentation – Technical documentation

45. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

46. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

47. Just because the system has been installed and is being used doesn’t mean that’s the end of the system life cycle. Some maintenance may be required for a range of different reasons.

48. User has discovered a bug in the system. The law has changed and the system no longer operates within the rules of the law. New technology has been released and the system could benefit from the technology. The customer needs added functionality which means further enhancements are required. The business has expanded and now needs to handle more data than its current system can cope with.

49. After the completion of any project it is important to evaluate it. This should be done for both the project development team and also the customer. The project development team need to know if they estimated costs and timings correctly. This will help them give more accurate estimates for future customers. The customer will want to know if it was worth going through the project and use their findings for future projects they may have.

50. There are various questions which you can ask: – Does the new system meet the system requirements? – Does the system contain bugs? – Does it crash? – Is the system making the employees more efficient? – Did the selling price pay for the work that was done? – Are employees confident in using the new system?

51. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

52. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

53. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

54. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

55. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

56. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

57. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance

58. Feasibility Study AnalysisDesign Implementation TestingInstallation Documentation Evaluation & Maintenance