Chapter 1.7 Systems Development Life Cycle.
1.7 (a) System Lifecycle as an Iterative Process
When considering the systems development life cycle it is important to think of the different stages as a continually developing process rather than each stage being an end in itself.
When one of the stages is completed the following stages may mean that the previous ones may need to be considered again. If the problem definition agreed with the end user later proves to be impossible to implement then the problem will have to be redefined. If the required input proves to be not feasible then it may be necessary to alter the expected output. If, during the training of the staff, one of the input operators proves to be colour blind then the input screens may need to be altered in order to not have any clashes between red and green.
This reliance of each stage being on the following stages as well as the previous ones means that the process is said to be iterative.
1.7 (b) 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.
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.
1.7 (c) 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 to develop 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 then 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.
1.7 (d) Information Requirements of a System and Fact Finding
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.
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.
1.7 (e) 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 information.
· 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?
1.7 (f) Data structures, Input/Output, Processing
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.
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
· 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.
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.
An example of a Jackson diagram to show the solution to a simple problem.
A register is taken of the 25 students in a class. Each student can be either present or absent. It is necessary to print out the number of students who are present and the number absent.
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.
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.
1.7 (g) 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.
1.7 (h) 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 4 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. 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
· examples of output screens
· examples of valid input
· methods of input of data
· error messages and what to do when they appear
· How to install the system onto specific hardware
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.
1.7 (i) Testing and Implementation Planning
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.
1.7 (j) System Maintenance and the Software Life Span
Adaptive Maintenance: 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.
Corrective Maintenance: 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.
0 comments:
Post a Comment