Systems Development Lifecycle (1.2.a)
Problem Definition (1.2.b)
The systems analyst and the client must establish the problem to be solved. The client is an expert in the problem, whilst the systems analyst in an expert in what is possible. This is important because if a problem is not defined precisely and accurately, then the system that is developed may not solve the problem, or the client may be charged for developing extra features they do not want or need.
Feasibility Study (1.2.c)
The systems analyst needs to decide whether it is possible to solve the problem, using a system known as "TELOS":
- Technology: Is the technology available to solve the problem?
- Economy: Is the solution economically possible? Will the solution be economic to run? Will the solution improve profits?
- Legal: Is the solution within the law? For example, does it comply with the Data Protection Act?
- Operations: Is the solution operationally possible? Does the proposed system actually solve the problem? What will the effect on the customer be - does the problem really exist?
- Schedule: Can the solution be delivered within the time specified by the client?
Information Collection (1.2.d)
Once both the analyst and the client are convinced that a solution is possible and desirable, the analyst needs to collect information about the problem to understand the problem and the current solution better, and work out which areas need improving. There are several ways an analyst can gather information:
- Interviews: a small number of important people can be asked about the problems. Interviews are generally slow but it allows the analyst to ask more questions if something unplanned arises.
- Questionnaires: these allow the analyst to ask opinions of a large number of people quickly. However, questionnaires are very restrictive because the questions must be planned in advance.
- Meetings: meetings strike a balance between the speed in questionnaires, and the flexibility of interviews. They allow a large number of people to have their opinions taken quickly. However, a few powerful individuals can control the meeting, and make the result biased.
- Observation: observation is possibly the most accurate form of information collection, but it is also the most time consuming. The analyst simply observes use of the current system, making notes about what the current solution does well, and what needs improving.
- Documentation: the analyst collects all available documentation and studies it carefully. This will show how the system collects, processes, and presents data and information.
After all the information is collected, it needs to be analysed to decide what is relevant to the problem. The analyst will use both data flow diagrams and system flow charts to try and understand the current system. This allows the analyst to produce a requirements specification, which is a list of tasks the solution should complete. It is important to make sure that the client agrees with all the decisions made at this stage, because the outcomes will be used to decide whether the proposed solution satisfies the problem, and ultimately whether or not the analyst gets paid.
The analyst draws up a design specification. This includes key concepts and relationships between various parts of the proposed solution. Another data flow diagram and system flow chart will be drawn. These allow the analyst to work out the way that the data will be collected, stored, processed, and then presented to the user.
This is the stage where the software is actually programmed. The job will be passed to a specialist, who may be an expert on programming and methods of handling data, but will be following the instructions given by the analyst. If the solution is very complex, a team of programmers may work on the job, but this adds complexity. For example - programmers need to make sure they are using unique variable names. To help make things easier, the team follow a written set of rules - these rules will form the first of three pieces of documentation.
Once the solution has been produced (possibly by a specialist), it is evaluated by the analyst to decide whether or not it solves the initial problem, by testing it. Testing is covered in more depth in F452. The most important thing is to understand that the aim of the testing is so the analyst can prove to the client that the solution works - if it doesn't and the client subsequently rejects it, then the analyst doesn't get paid!
The analyst must create an installation strategy, explaining how to install the system into the business. This will include purchase of hardware, creation of data files, training of staff, and the consideration of future maintenance.
Two types of documentation are created (as well as the programmers documentation created during the implementation): technical documentation and user documentation.
Technical documentation is designed for somebody who is computer literate - normally the person or department responsible for maintaining and improving the system. The documentation will consist of things like lists of variable names. This is essential if more than one programmer works on the project, because they will need to use the same (or different, depending on the scenario) variables. The technical documentation will also include the full, annotated program code, including line-by-line explanations.
The user documentation gives the user basic instructions about how to use the system. It contains instructions relating to the users' view of the system, and no indications about the underlying software. It will generally include how to use and look after the hardware, input and output formats, and a list of error messages with advice. The user guide will include simple language, not computer jargon.
When the system is installed, it needs to be maintained. This might include updates to fix "bugs", add new features, or improve efficiency. Updates may also be made avalable to fix potential future bugs, for example the Y2K bug.
Waterfall & Spiral Models_ (1.2.l)_
The key difference between the waterfall model and the spiral model is that in the spiral model, after implementation and testing, the program is evolved into the next version, until a version is accepted as the final solution. With the waterfall model, the software is developed in a linear fashion, where each stage is iterated and checked, and then the analyst moves on.
The analyst creates prototypes so that s/he can show the client how parts the finished solution will work without developing the entire piece of software. More and more features are added to the prototype until eventually the prototype evolves into finished and complete software. This is very similar to the Rapid Application Development model of software development.