|
|
Systems Development Life Cycle. 3.1.1 Problem Definition It is important from the outset to ensure that when a computer system is being designed all those that are involved are agreed about the aims of the system. There will normally be a person, or a company or organisation, that decides that a task would benefit from computerisation. This belief normally arises because there is a problem which cannot be solved by previously used methods or similar problems seem to have been solved by computerisation elsewhere. Unfortunately, the owner of the problem probably understands the problem itself quite well, but does not understand the consequences of using computers to try to solve the problem, or, indeed, whether such a solution is even possible. For this reason it is necessary for the organisation to employ a specialist who does understand computers and computerised solutions to problems. This is the systems analyst. Unfortunately, it is probable that the systems analyst is not expert in the area of the problem. The system analyst’s job is to solve the problem by planning and overseeing the introduction of computer technologies. The owner of the problem will be happy if the analyst can introduce a computer solution. The problem arises when the analyst, who doesn’t know very much about the business, solves the problem that they think needs solving, while the owner of the problem expects a very different problem to be solved. It seems obvious that if someone is doing something for someone else that they should make sure that they know what is required. If you are asked to answer questions 1 to 5 and you do 6 to 10 instead there is an obvious breakdown in communication, but this is what can happen if you only listen to the instruction, “Do the 5 questions”. The method most often used to overcome this problem is for there to be discussions between all the interested parties, and then for a list of objectives to be written up. The solution to the problem is the successful implementation of all the objectives. The different people involved then agree to the list of the objectives and the success, or otherwise, of the project depends on the completion of those objectives. The definition of the problem is the most important part of the analysis because if it is not done correctly the wrong problem may be solved. This is quite common and has led to many failed projects. 3.1.2 A Feasibility Study. When the organisation and the systems analyst have agreed the definition of the problem, a decision must be made about the value of continuing with the computerised solution. The organisation may be convinced that there is a problem to be solved, and that its solution will be worth the effort and the expense. However, the systems analyst is being paid to look at the problem, and its solution, from another point of view. The analyst is an expert in computer systems and what is possible with computer systems. This analyst must consider the problem from the point of view of the computerised part of the solution and make a report to the organisation saying whether the solution is possible and sensible. This report is called the feasibility study because it says whether the solution is feasible. The feasibility study will consider the problem, and the proposed solution, from a number of points of view. Is the solution technically possible? A car firm may decide that if robots are used on the production line to assemble the different parts of engines then quality of work may improve. However, if it is not possible to manufacture a robot arm of the correct dimensions to fit into the small areas under a car bonnet, it doesn’t matter how big an improvement there would be in the quality of the finished product, it would simply not be feasible. Is the solution economic to produce? Perhaps the robots exist that can be programmed to assemble this engine and the benefits will be worthwhile. However, if the cost of the robots and the program to control them is so great that it puts the car manufacturer out of business, the introduction of the robots is not feasible. Is the solution economic to run? It has been decided that there are tremendous benefits in producing a robot production line and the robots are very cheap to buy, but they have so many electric motors, and they are so slow at assembling the engines that it is cheaper to employ people to do the job. What is the effect on the human beings involved? If the car plant is the only major employer in the region, and the introduction will put much of the workforce out of work, then the employer may decide that the human cost is too great, certainly the Government would. Is the workforce skilled enough? It will be necessary to employ highly skilled technicians to look after the robots. If there are no workers with the necessary skills, then the computerisation is not feasible. What effect will there be on the customer? If the customer is likely to be impressed with the introduction of the new systems, it may be worth the expense. However, if the customer will notice no difference, what is the point? Will the introduction of the new systems be economically beneficial? Put bluntly, will the introduction of robots increase the profits made by the firm? If the feasibility study shows a positive result which is accepted by the company, the next stage will be for the analyst to collect as much information about the process as possible. 3.1.3 Information Requirements of a System and Fact Finding When a computer system is being designed, it is necessary to ensure that the designer of the system finds out as much as possible about the requirements of the system. We have already mentioned the importance of defining the problem but further difficulties can arise. Imagine an organisation that commissions an analyst to design a new payroll program. The analyst and the boss of the organisation agree that the software needs to be able to communicate with the relevant banks, and to deduct tax at source and other important details. The analyst designs the solution and the software is written. It is the best payroll program ever produced and is installed into the computer system ready to do the first monthly payroll. Unfortunately, many of the workforce are employed on a weekly basis. A simple question to one of those paid in this way would have highlighted this for the analyst and meant that the costly mistake was avoided. When a system’s requirements are being studied there is no room for errors caused by lack of information. The feasibility study has been accepted so the analyst now needs to collect as much information as possible. Obvious methods of collecting information are to ask different types of people. It may not be feasible to ask everyone in the organisation for their views, but a representative sample of workers, management, customers should be given the chance to supply information. After all, the part time worker on the production line probably knows more about the business than the analyst. There are three accepted methods of finding out people’s views: 1. By interview. Interviews are particularly important because they allow the interviewee to talk at length, and also to leave a prepared script. However, they are very time consuming and consequently restricting in the number of people whose views can be sought. Also, questionnaires are very difficult to design. Many people have difficulty completing them, particularly if the instructions are not very clear. 2. By using questionnaires. Questionnaires make it possible to find out the views of a large number of people very quickly, but because the questions are pre-determined the person who is supplying the answers may find difficulty in putting their point of view across. 3. A compromise is to hold a group meeting. This allows a number of people to discuss points and make their views known and yet cuts down on the amount of time spent in interviews getting the same answers over and over again. The problem with meetings is that one or two people tend to dominate, not allowing all the members of the group to give their opinions. Often the views of the people connected with the problem are clouded by years of familiarity, so it is important for the analyst to also gain first hand knowledge of any existing systems. One way to do this is to observe the current system in action. Care must be taken to take into account the fact that if the workers know that they are being observed it is unlikely that they will behave in their normal manner. This is the same effect as a television camera has on otherwise fairly sensible individuals. The second method is to collect printed documentation and study it in order to find out what data is required by the system and in what form information is output. 3.1.4 Requirements Specifications The planning of any system design must start by deciding what the requirements are of the system. A system may need to store data for future reference or processing. However, simply being aware that the system may need to store data is not enough. Decisions need to be made about the types of data to be held as this will dictate the form that the data will be stored in and the amount of storage space required for each set of data. Calculations as to the number of sets of data that are going to be held have to be made because the volume of storage will make some storage devices more sensible than others. Also, the volume of storage can affect the structures that will be used to store the data. Decisions need to be made about the relative importance of the different ways of accessing the data. Is it going to be necessary to access individual items of data or will all the data be accessed at the same time? Will the data be changed regularly or is it fairly static? When decisions are made as to the direction that a particular system is going to take, it is normal to produce a list of tasks that need to be carried out to complete the system. These tasks should be in a specific order. It would not make sense to consider inputting data into the system before designing the data structure into which the data is to be put. This list is called a priority list and it forms the basis of the system design. Each of the tasks that are in the list should then be considered separately to decide the important points about each one. An example would be that the file of information on stock being held in a business must allow for 1000 items (immediately putting a lower limit on the size of appropriate storage) for direct searching for information on a single item (means that some storage media are not suitable, and that some data structures cannot be used) another file, of manufacturers, to be accessed from each record in the stock file to facilitate reordering (forces one field to act as a link between the two files). Plenty of other facts must be considered and decisions made, but a set of constraints has already been placed on the design. This is known as the design specification and it should be agreed between the analyst and the organisation before the design is implemented. Often, the inputs and outputs to a system and the storage and processing that goes on in the system is such that, in order to understand it, the system needs to be divided up into a number of interconnected sections, or modules, each one being simple enough to be handled as an entity. A diagram can be drawn which shows all the sections and how they fit together. Such a diagram is called a Jackson diagram. Jackson diagrams: A Jackson diagram starts with the original problem as the highest level. The next, and subsequent, levels show how the problems in the previous levels are split up to form smaller, more manageable, problems. This continues until each of the blocks in the lowest levels are self contained, easily solvable problems. These individual problems can then be solved and combined according to the links that have been used. If the links between the different blocks are then used correctly, the result will be a solution to the original problem. Imagine a Jackson diagram as a method for showing the individual modules that go to make up a solution to a problem and the relationships between them. Original Problem Links Individual modules Final level The links between the modules can be conditional. For example if the result of a module was a mark out of 100, then there could be two possible print routines, one for failure if the mark was below a certain level, and one for pass if it was above the pass mark. Data flow diagrams: These are diagrams that are used to describe systems. Boxes are used to stand for input, processes, storage, and output. Arrows show the direction of communication around the system, and communications outside the system. As the name implies, these diagrams are used to show the directions of flow of data from one part of a system to another. Data flow diagrams can have complex shapes for the boxes that are used, but the important thing is not the shapes of the boxes, rather the logical train of thought that has been used to produce the diagram. Rectangular boxes, though not always used, are perfectly acceptable for all elements in a data flow diagram. Such diagrams are intended to show how the processes and the data interrelate, not the details of any of the programming logic. Note: A Systems Flowchart is another name for a data flow diagram. Students are expected to be able to follow the logic in a data flow diagram and, indeed, produce their own, but not until the A2 sections of the syllabus, where this topic will be picked up again. At this stage the analyst will also identify the hardware that will be necessary for the system to operate as the user requires, and the software characteristics that will need to be satisfied for the system to operate. 3.1.5 Design of Input, Output, and Data Structures Input Design All systems require input. The way that the data is input to the system depends on a number of factors. The data that is required. Is it graphical/textual/physical in nature? Is the data already in existence or does it need to be collected first? The hardware that is available. Is the data to be entered via a keyboard by an operator, or is there an automatic way to enter the data? The experience of the operator. The design of the user interface. This section relates back to section 1.2.3 which covered the different forms of software interface. The main task in input design is to design the interface with the outside world so that data can be passed to the system, both software and hardware. Diagrammatic depiction of the system processing is covered in section 3.1.4, above. It is not necessary to go into great detail about such diagrams, but students should be aware that they exist. Output Design The results that are produced by the system must be presented in a way that is appropriate for the application. If the system is designed to produce bank statements for customers, then it would not be sensible to have an audio output. Similarly, a burglar alarm system would not serve the purpose for which it had been designed if the output is a message on a computer screen saying that someone has broken in as there is probably no-one in the house to read it, which is why the alarm was needed in the first place. The decision about the type of output will depend greatly upon the same factors as the input, namely, the hardware available, the form that the output needs to be in, the experience of the operator, indeed, whether there will be an operator present. Equally important to giving enough information, is the danger of providing too much. In order for users to be able to understand the information presented, various tricks can be used. Information can be arranged on a monitor screen by always putting the same sort of information in the same place. The operator will then quickly become accustomed to the relative importance of different areas of the screen. Information can be colour coded. Important information may appear in red while that which is less important is in black. Notice that this implies some form of decision making on the part of the processor to determine what is important in the first place. It is also necessary to be very careful about choice of colours. People who are colour blind commonly find difficulty distinguishing between red and green, so choosing these colours to stand for information that is dangerously near a limit or at a safe level, could be disastrously wrong. Similarly, colour combinations have to be chosen carefully. Blue writing on a black background is almost impossible to see, as is yellow writing in some lighting conditions. Video reversal can be used to highlight a particular piece of information effectively. This is when the normal writing on the screen is black on a white background, but the piece that needs to stand out is shown as white on a black background. Very important pieces of information may be shown as a dialogue box obscuring the rest of the screen until it is dealt with. A printer may be reserved for special messages so that a hard copy of the information is preserved. Again, the fact that the information appears on that printer means that it has a particular importance. Information can be made to flash, or can be printed in a different size, anything that makes the operator’s eye go to that part of the screen. It is important not to put too much on a single screen. It is better to use several screens with the contents clearly shown. If more than one screen is used, it is important to be able to move both forwards and backwards through the screens easily. Data Structure Design The data used in a computer solution will need to be stored somewhere. The storage is not that important. What is important is getting it back again when it is needed. In section 1.4, the data structures array, queue, stack, linked list, tree, were described. When the solution is designed it is necessary to decide how access to the data will be handled and to choose an appropriate data structure. Questions on this part of the syllabus will tend to ask for the sort of choices that need to be made rather than any complex analysis of fitting a data structure to a given situation, though simple examples like modelling a queue at a check out till may be asked. 3.1.6 System Evaluation Any system must match certain criteria if it is to be considered successful. This does not only apply to a computer system but any system. For example, a car must satisfy various criteria before being able to be called a car it must move under its own power it must be possible to steer it it must have 3 or 4 wheels it must have seats. There would be many other facts which would have to be true before most of us would recognise that this system is a car. However, some assumptions have been made in just the four criteria mentioned here. A toy, radio controlled, car fits all these criteria, but it was not the sort of system that we had in mind when designing the criteria. Perhaps the second bullet point should have specified that it has to be controlled from within the car itself, or should there be a new criteria that gives a minimum size for the vehicle? When systems are being designed, this list of criteria, that the finished system must match, is of paramount importance. It must also be agreed between the designer of the system and the commissioner of the design, so that there will be no unfortunate misunderstandings. We can imagine a situation where the Ford motor company commission a new car design, only to find that it is 30 cms long when delivered. Note that these criteria are decided before the system is created. They are used to decide how well the system works. In other words, does it do what it is meant to? This question can only be answered if it is known what the system was meant to do in the first place. 3.1.7 Documentation The documentation of a system consists of all the text and graphics that explain how the system was produced, how it should be used, and how it can be maintained. Documentation is created at different stages in the life of a system and for different people to use. Some of the different types of documentation are met in this section and others will be encountered later in the course. Indeed, much of the project work that is done in module 5 consists of producing the documentation for a problem solution. Requirements Specification This is a list of the requirements of the customer for whom the system is being designed. It consists, largely, of the criteria that will be used for the evaluation of the finished system that were discussed in section 3.1.6. It is usual for the system analyst and the customer to sign the list of requirements so that there is no confusion when the work is finished. Design Specification Taking the requirements specification and working out the stages necessary to produce the required end product is known as the design specification. This will include the different stages, often shown in diagrammatic form as mentioned earlier in this chapter, and also the criteria for each stage of the solution. For example, one part of a solution may be the production of a file of data. The ways that this file of data relates to the other parts of the system, and the specification of the file (What is the key field? How many records will there be? What type of medium should it be stored on?) make up the design specification. Program Specifications These will include detailed algorithms showing the method of solution for some of the parts of the problem. These algorithms may well be in the form of flow diagrams or pseudo code. The language to be used, the data structures necessary, and details of any library routines to be used will also be in the program specification. Technical Documentation The technical documentation will include the program specifications, the coded program itself, details of hardware configurations. Generally, anything that will aid a technician in maintaining or updating a system. Indeed, technical documentation is otherwise known as maintenance documentation. This type of documentation is not intended to be accessible to the user of the system, who does not need any of these details to be able to use the system correctly. User Documentation This is the documentation for the person who will actually be using the system. It contains those details that are needed to make the system operate as it should. Items normally included in the user documentation will be how to install the system onto specific hardware methods of input of data examples of valid input examples of output screens error messages and what to do when they appear Some user documentation is part of the software and can be called up onto the screen when it is needed. This type of documentation is called on-screen help. 3.1.8 Testing and Implementation Planning Any system needs to be tested to ensure that it works. This seems to be a fairly obvious statement, but in reality such testing is impossible in all but the simplest of systems because it simply is not possible to test every conceivable input to, or logical construction in, the system. This difficulty means that testing that is to be done must be carefully planned and that it should relate directly to the criteria referred to earlier in this chapter. Specific types of testing have already been covered in 1.3.8. When the system has been completed it has to be implemented so that it is performing the tasks for which it was designed. Initially, this involves ensuring that the correct hardware is available arranging for staff to be trained in the use of the new system inputting the data to the data files, either manually or by downloading them from the original system. The system handover, itself can be done in a number of ways. Parallel running. Until the system can be considered fault free, the old and new systems are run side by side, both doing the same processing. This allows results to be compared to ensure that there is no problem with the new system. Such a system is ‘safe’ and also allows staff training to be carried out, but it is obviously very expensive because of the need to do everything twice. Parallel running is used in situations where the data is so valuable that there must be no possibility of failure. Pilot running. Key parts of the new system are run alongside the old system until it is considered that they have been fully tested. This is a compromise with the idea of parallel running, but it does not give a clear idea of the effects on the system of the large amounts of data that are going to be encountered in the full application. Big bang, or direct change. The old system is removed and the new system replaces it completely and immediately. Phasing. Parts of a system are replaced while the remaining parts are covered by the old system. This allows for some testing of the new system to be done, and for staff training to take place, but also allows for a back-up position if the new version does not work as anticipated. This topic is not fully expounded upon here, the candidate simply needing to understand that there are different methods of implementation and be able to outline some of the methods along the lines shown here. This topic will reappear for a fuller treatment in section 6.2.5. 3.1.9 System Maintenance and the Software Life Span Systems may be designed for a well defined purpose and may realise that purpose, hence they would be considered successful. However, the original reasons for a particular system to be created may change, the hardware may alter, the law governing a system may change. For many reasons the original system may no longer be satisfactory. One solution would be to produce a totally new system, another would be to adapt the present one so that it can be used in the new circumstances. This situation is reviewing the system and is the main reason for technical documentation. While the system is running it will need attention because of faults being discovered, this again needs a technician with a set of maintenance documentation. Computing and computer applications is a subject that changes so regularly through improvements in technology, new ideas, different legal frameworks trying to keep pace, that, in reality, a system should never be considered to be finished. Rather than being a linear process with a beginning, a middle and an end, it should be thought of as a circular process, continually returning to previous stages to fine tune them and take advantage of changing circumstances. |