Cost - gardeangie – This WordPress.com site is the bee's ...



IntroductionAll things have a beginning, middle and an end. And Information Technology (IT) is no different. Indeed it could be argued that IT sees more rapid change than many other technologies. Think how many 'upgrades' have happened with your favourite software.For instance, imagine you have been working at a company for a few years.Time passed, people moved on, the company changed ... that wonderful system began to show its age... Workers grew tired of using old CRT screens - even their home computers were more modern than this!It was time for a change.But change has to manage to avoid disruption, chaos and inefficiency. This is where 'System Life Cycle' comes in.What is a System?- a collection of related components that serve a common purpose. In the phrase ‘System Life Cycle’ a system is either a program or a collection or programs. Therefore, a system life cycle describes how programs are developed from an idea, to completed programs and then, to revised or discontinued programs.Why build new IT systems?New IT systems are being developed all the time in almost every type of organisation from a small shopkeeper who wants a custom built stock control system to the NHS who want a national database on which they can keep the medical records of every person in the UK.Here are a few other examples of IT systems:Banks - customer record systems, systems for ATM machines, systems for approving or rejecting mortgage applicationsHospitals - pharmacy systems for keeping track of drugs and creating printed prescriptions, appointment systems for outpatientsGovernment - online tax payment system, online census informationSupermarkets - stock control systems, payroll systems Problems with new IT systemschange is risky. Managing any change that involves IT systems is particularly risky!A survey of over 14,000 organisations showed that where new IT systems were being developed*80-90% of systems fail to meet performance goals80% of systems are late and over budget40% of systems fail or are abandonedJust 10-20% of businesses meet all their success criteria.Only a small minority of the IT projects in the survey were successful.As people have learnt from past mistakes, a model has been developed and refined over the years to try and maximise the chances of a successful project.This method / model is called the?SYSTEMS LIFE CYCLE.The System Life Cycle (SLC)The SYSTEM LIFE CYCLE is a process of stages which occur during the development of a new ICT system.If organization’s follow the stages of the SLC, they should be able to avoid many of the problems mentioned on the previous page.Initial StudyProgram DesignSADThe SLC consists of the following stages:Initial study DevelopmentSAD ReviewProgram DesignDevelopmentTestingTestingImplementationImplementationLive Running and MaintenanceLive Running and MaintenanceReviewAlthough all projects should start with the definition stage and end with the maintenance stage, the process is not always completely linear. After completion of one stage, it might be necessary to return to an earlier stage.1. Initial StudyThe system analyst must determine why?a new system is required.After all, if there isn't a problem to start with, why would an organization incur huge costs to develop a new one?the role of the analyst is to scope out the problem.The analyst has a number of methods available to do this :-Interviews with management to get their viewpointInterviews with staff to understand the limitations of the current systemAfter the study, the SA will produce a feasibility report. Once the system analyst is convinced that there is a problem which could be solved with a new IT system they have to determine whether it is feasible to actually go ahead and develop the system.Some of the questions that will need to be answered are:CostHow much would the new system cost to develop?BudgetWould there be enough money available in the budget to develop the system?TimeHow long would it take to make the system from start to finish?SkillsDoes the company have the skills in-house or would it need to go to a specialist software development firm?Hardware to developDoes the company have the necessary hardware to develop the system?Hardware to runWould new hardware be needed to run the system and if so how much would that cost?SoftwareDoes the company have the necessary software to develop the system?TrainingWhat would the training implications be once the system had been developed?Technical feasibilityAfter finding out what is required is it technically possible to create the systemThe system analysis will consider all of the answers from the feasibility study and come up with a number of alternative solutions to present to management. It is then the management's job to consider going ahead with the new project.Some possible solutions that might be suggested to management could be:a) Company does not change anythingb) Company makes alterations to half the systemc) Complete overhaulAs 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.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 investment they wish to put into the project.If the decision is made that it is worth developing a new system, the SLC will progress onto the next stage, System Analysis and Design. If management decides to stick with the current system, the SLC will stop here.2. System Analysis and Design2.1 Investigating the systemDuring this phase they will carry out very detailed investigations in order to fully understand the current system and the proposed new system.The current systemhow staff / customers interact with the current system i.e. how tasks are carried outhow other systems interact with the current systemwhat is good about the current systemwhat causes problems with the current systemwhich parts of the system are critical to the business?The proposed new systemwhat the new system is expected to be able to dohow the new system is expected to do thiswhat people want from the new systemwhich working methods from the old system should be incorporated into the new system2.2 Investigation methodsthe system analyst will do some or all of the following:Face-to-face InterviewsThe analyst will interview selected staff who use the current system in order to get a detailed overview of how things work.They will want to know what the main problems are and whether users have any suggestions on how to improve the way things work.ObservationThe analyst will observe users actually using the system. They will probably follow a complete process from start to finish and note down every interaction that happensQuestionnairesQuestionnaires enable the analyst to obtain the views of a large number of staff/ users. Questionnaires are also easier to analyze than face-to-face interviews but the trade-off is that they don't give as much detail.Examination of business documentsMost organization’s have business documents and written processes/ procedures relating to the current IT system. These documents detail how the system works and the processes which users should follow. The analyst will examine these documents in detail.Paper trailFollowing information from the point it enters the system and observing what outputs are created at each point in the system.2.3 DocumentationAll of the information obtained through interviews, questionnaires, observations and paper trails is carefully examined and analysed to determine the requirements for the new IT system.The findings are translated into a set of specific diagrams which represent how the system will work and the processes required.The main diagrams are:System diagramsThese 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 DiagramsMost 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 diagramsPeople 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).Once the diagrams have been completed, two key documents/ reports are produced:1. A full written analysis of the current system, the processes and the problem it causes2. Detailed user requirements for the new systemThese documents will be used by the system developers and so must be clearly written, broken down into relevant stages and contain all of the necessary details for them to create the new system.3. Program 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.The Senior Programmer will then produce the program specification for each of the programs. It is about planning the project in detail so that that system will meet user requirements.The following are tasks that must take place during this phase:Project planningProject planning is all about handling people: how many, where and when are they needed. There are a number of different project planning tools which will be used during this stage in order to effectively plan out the project, timescale and the resources required. System requirements specificationData capture methods for the systemData inputs to the systemData outputs from the systemData processing within the systemThe file structure for date storageThe user interface i.e. screen layouts, buttons, error messagesHow information is accessed and indexed or sorted.The operating system to be usedThe hardware to be used to run the new systemTesting documentationOnce the user requirements document and the system requirements specification have been written the analyst will know exactly what the system should be able to do.A test plan is written at this stage to test the key parts of the system once it has been developed.PrototypingA '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 mon methods: Jackson Structured Programming, Pseudocode, Flowchart, Structured Chart and Nassi Shneiderman diagrams4. DevelopmentOnce the design stage has been completed the software developers can begin to write the code and actually develop the new system.The developers will follow the system requirement specification exactly;They should not deviate from the specification in any way without consulting the analyst.During this stage some of the following are developed:the tables and data structuresvalidation routinesdata capture formsdata input formsautomated processing routines i.e. macrosqueriesthe user interface i.e. screen, buttons, help messagesprinting outputs5. TestingOnce the system has been developed it must be tested to ensure that it is working as expected.Testing TeamA team of testers will have been chosen to test the system. They are known as beta testers. Their role is to check that the system does everything exactly as specified in the system and user specification.Although this team will check if the system is user friendly that is not their main role. A separate team is usually appointed made up of front end users to 'user test' the system once it has been passed by the beta testers.Test PlanIn an ideal world a test plan will have been written during the design stage.The test plan is a detailed document which a team of testers must follow carefully. It will set out every single test they are to do on the system, what data they should enter and what result they should expect to obtain.For example one test might look something like this:Test no.Part of systemWhat is being testedTest dataExpected resultActual resultPass / Fail23Customer input formInput mask on postcode to check that numbers cannot be entered where letters should be.45CV523Fail - should not be able to enter postcode??The first five columns are already completed in the test plan. The final two columns are left blank for the testers to complete when they do to test the system.The testers follow the plan exactly. They enter the data just as it is shown in the plan and then they record what happened and whether the test passed or failed.If the test was passed they go onto the next test. If it failed they fill in a form to tell the developers that they need to look at that part of the system again.The testers normally take screen shots of every test to provide evidence of what they have done. These can be referred to by the developers if they cannot replicate the problem. They can also be used by an audit team at the end of the project to check that the testing was done properly.It is a very bad idea to have the person who codes the software to test it! This is because they know too much and so will tend to make assumptions about how real users will use their software.The best testers are those who know nothing about the system and will do things to the system the developer never imagined! Just like real users!Test SelectionIt is important to realise that with the best will in the world it is not possible to test every part of the system.Consider a system having 8 data inputs that can applied in any combination. The maths says that there are over 16 million possible combinations of just 8 inputs!So the skill of the testing team is to carefully select a?practical?number of tests that can be carried out in the time available and yet be confident that the system is working.This is why complicated software often has bugs even after being released. It is simply not practical to test everything.Test DataIt is important that any testing which checks the validation routines should include:Data that is within the normal range and will be acceptedData that is on the extreme limits of the range but should be accepted e.g. if the validation says that price <=?100 then ?100 should be tested as that is right at the outer limit.Data that should fail (erroneous data) should be tested. For the test mentioned previously, the test might be: enter ?100.01?Iteration or Looping Around.If an issue is found it may actually be a problem with the user requirement itself. It is quite common for the user requirement to not consider an unexpected situation.For instance, the document might state that the system is to be used by 10 people at the same time. But by the time testing is underway something changes in the company and now the system needs to deal with 20 people instead.In which case the client has to agree to change the user requirement document.Then testing continues with the modified user requirement document.Changing user requirements part way through a project causes delays and extra cost. It is often the most common reason a project fails especially on large projects.Testing is usually an 'iterative' process.6. Implementation?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. It covers:6.1 TrainingStaffs needs 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.6.2 User DocumentationUser documentation is provided to the user which gives an overview of how to use the system.Paper based user documents are usually in the form of a booklet or file.The typical format of a paper-based user document includesTable of contentsShort introduction or overview of the systemBrief technical details such as the hardware and software requirements to run the systemUser Guide : this is the bulk of the documentGlossary of technical termsTroubleshooting: usually a simple list of things to check before calling for further helpIndexUser documentation is often used during staff training sessions in order to familiarise the staff with both the system and the user documents.6.3 On-Screen DocumentationAs well as paper-based user documentation, many systems now also have on-screen documentation.On-screen documentation can take the form of:A help menuWeb pagesPopup help boxesPDF documentsFAQ sectionVideo tutorials6.4 Technical DocumentationTechnical documentation is created from the very first stages of the development phase as the original project team set down the details as they build the system.Typical content of technical documentation includesSource code with copious commentary explaining how that part of the code worksData structures used within the systemFile formats usedFile naming conventionValidation ranges for data inputMacro scripts, including comments to explain each stage of the macroInternal details of a database such as tables, relationships, records, queries usedNavigation layout such as a site map or link map of the systemOther technical details to help with maintenance includeTest logs and test resultsSecurity details of the systemHow to install the systemHow to backup and restore the systemA key decision is which method of the four different methods of installation will be chosen. These are:Direct methodThis is where the company literally switches off the old system and switches on the new one. This is probably the most straightforward method but is also probably the riskiest.Parallel methodThis is a more popular method than the previous one. With a parallel changeover the organisation runs both the old and new system in parallel for a time. Once the organisation is sure that the new system is working properly and that staff are ready to begin using it they will make the decision to completely change over. During a quiet period, perhaps during the night or at a weekend, the data is fully transferred from the old system which is then shut down.Phased methodThis is where the old system is still active but parts of the new system or modules are brought online, for example, perhaps just the data entry screens and the printing modules are made available but the 'back end' of the system remains the same. Once any problems are ironed out with the new modules then extra modules will be introduced. Effectively the installation happens in small chunks.Pilot methodThis is where the complete new system is installed and tested in a small number of departments or branches. They then use the system and report their feedback and any issues to the analyst. Once the organisation is confident that the system is working as expected, it will be rolled out across the whole organisation7. ?Live Running and MaintenanceThis is the stage where the system becomes functional in a live environment and is expected to be able to cope with any of the situations it is built to handle.There are three kinds of maintenance needed:Corrective maintenanceThis is where problems are identified with the system after installation. Perhaps an item on the template isn't printing out correctly or maybe one of the on-screen buttons isn't linking to the correct form.A fault report is raised and the developers fix the problem. It is then passed over to a team of testers who check that the fault has been fixed. Once it has been passed by the testers, the fix will be released to the live system.Corrective maintenance can also involve fixing hardware faults or replacing equipment as necessary.Adaptive maintenanceThis type of maintenance often occurs as a result of external influences or strategic changes within the company. For example, the Government recently changed the VAT rate from 17.5% to 20%. This change would have meant that many organisations had to make alterations to their systems. Perhaps a bank decides to offer a new mortgage product. This will have to be included in the system so that mortgage interest and payments can be calculated.?Perfective maintenanceThe system has been in place and running fine for a while. However, over time, the end user will often find tweaks or minor improvements which could be made to improve the way the system works. Perhaps a slightly different screen or data input form. These tweaks are not major enough to prompt a complete new system, so the maintenance team adapt the system to suit.?It is important to be aware that while the system remains in use the maintenance stage will be ongoing.As long as there is some alteration, all documentation related to the change must be updated.8. ReviewThe review should be carried out by a person who has not been involved in the design and development stages so as to ensure that the review will be carried out objectively. The content of the review will include:Objectives metCostPerformanceStandardsRecommendationsAfter the review, maintenance may be carried out to enhance the system or it may be decided that part or the whole of the system needs to be re-designed, and hence re-developed. If redesigning needs to be done, the initial study will come in again, thus calling into play the entire System Life Cycle once more.Resources:CS112 Program Design - Informatics ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download