System Life Cycle

Analysis

During analysis, it is important to obtain a full and accurate picture of the working of the organisation. In many cases, systems are being developed to replace existing systems. There are several ways to obtain this information. Relying on one method alone is likely to lead to problems during development.

Questionnaire

Information gathered from questionnaires can be easy to process automatically, particularly if some form of direct data capture is used. Questions need to be well-designed and should not restrict the range of information that can be gathered.

Interview

Interviewing key personnel can be useful although it is time-consuming. It does allow for clarification of both questions and answers and may lead to reliable and useful information being gathered. It is important that the views of those who will be using the system are sought and not just the views of managers - who may use only part of the new system.

Document Inspection

Think again about the nature of an information system. Data are input, processed and stored so that valuable information can be output. Examining the current output documents and the uses made of them can help determine the nature of the system being developed.

Observation/Inspection

There is a subtle difference between these two activities. Inspection implies a more focused way of gathering information. In either case, the working of the current system, its problems and bottlenecks can be exposed using this method.

Design

During the design phase, the aim is to reach as full a description of the new system as possible. Hobby projects, like this web site, may seem easier to develop 'on the fly' or with minimal design work. The organic, 'as-you-go' approach will not stand up when time is money. Amateurs can afford to compromise when sorting a minor problem out would require more work than they care to put in. This will not stand up commercially. Adequate planning is the best way to ensure that a system is likely to meet its objectives.

Items Requiring Design

Output

Designers must consider what information is to be output, the format, frequency, volume and media to be used (screen, paper etc.).

Input

This can have a considerable effect on the efficiency of the system. It may also be a necessary limiting factor on some aspects of system functionality. The content and source of input, as well as the methods used, must be considered.

User Interface

All aspects of the interface should be considered, forms, dialogues, menus etc.

File Structures

There are many choices to be made here. Re-read the material for Module 2 to remind yourself of the aspects that need to be considered.

Processing

Consider the place of processing in an information system. It turns data into information, adding value. We have also seen with the sorting algorithms in Module 4 that the choice of algorithm can have a dramatic impact on system performance. Developing and testing algorithms in isolation can be a useful way to assess their usefulness in the system as a whole.

Other Aspects

Security, testing, operating system and modes of operation (eg batch, real-time) should also be considered and documented in this phase of development.

Prototyping

A prototype is a working model of the finished system without the functionality of the actual system. This can allow end-users to feed into the design process and allows developers to check that they are moving in the right direction. A prototype developed for this purpose may be developed simply to illustrate key features and might be discarded once used. This is called throwaway prototyping. Evolutionary prototyping involves developing the prototype into the finished system.

User Interface

A whole book could be written on the importance of this aspect of development. Lots of use feel inhibited by the user interface of the software that we use, applications software or even operating systems. Something as simple as being able to change the default location for a file dialogue box can have a dramatic effect on efficiency. The following questions are some of the areas to consider,

• Can you tell by looking at the screen which part of the program you are using?
• Are the objects spaced out to avoid clutter?
• Is the user given information about data formats for each field? (What problems can you foresee here?)
• Are the objects sequenced in a logical manner - how well do data entry screens match the sources from which data is input?
• How should colour be used?Are default values, lookups used where possible?
• Is there a good onscreen help facility? (Contextual Help?)
• Can entries be corrected?
• Point at which validation occurs?

Implementation

The implementation phase of the systems life cycle is when the new system begins to be used. It will involve hardware installation and configuration, setting up master files, changing office layouts and training users.There are different methods used to convert from one system to another.

• Direct Changeover - Start using the new system immediately.
• Parallel Conversion - Run both systems side-by-side for a period.
• Phased Conversion - Use only some aspects of the new system or use the new system for a small amount of data.
• Pilot Conversion  - Use the new system within only a small section of the organisation.

There are benefits and drawbacks to each of these methods. Draw up a table to describe the advantages and problems arising from each of the conversion methods.

Training

Insufficient training can affect the cost/benefit outcome of a new system.

Types of Training

Specific training to each type of user - technical, managers, clerical staff

Cascade Model - extensive training for expert users who in turn cascade their knowledge in an ever-increasing pyramid to the whole of the intended user group. If the software is not bespoke and is widely used, specific courses and accreditation may be used.

Training may involve,

• Detailed manuals
• Online tutorials (additional software)
• Video
• Instructor-led course

What makes a good training session?

The instructor must

• Be able to communicate effectively with trainees, supporting them in practical tasks, explaining concepts and answering questions.
• Plan the use of the training environment.
• Structure sessions logically to allow trainees to develop and use skills.
• Provide training at a level appropriate to the trainees and be able to adapt methods as required.
• Use presentation techniques and equipment appropriate to the training.
• Demonstrate rather than explain how to use the software (do, don't tell).
• Employ strategies to ensure that trainees make adequate progress during the training session.

The trainee should receive materials, usually in the form of a training manual. This may contain exercises to be completed during the training session, but should also contain additional exercises where appropriate and act as a reference that trainees can use after the training has been completed.

Evaluation

Training sessions normally end with some form of evaluation. This allows the trainer to adapt the session and training materials to make it more effective.

(Anonymous) questionnaires are one of the best ways to receive and log feedback. These should,

• not take too long to complete
• allow trainees to answer open as well as closed questions
• focus on all aspects of the training, presentation and delivery
• be completed in such a way as to allow trainees to be honest

Good evaluation can make for more successful training in the future. Fishing for compliments or a rather vague feelgood factor (Did you enjoy the course?) does not provide the information required for improvement in training delivery over time.

Testing

Testing comes after implementation of a new system. It is important to ensure that the system meets its objectives.

Testing is described in the page on testing.

Evaluation & Maintenance

Evaluation

Sometimes called the Post-Implementation Review. 3-6 months after implementation. Focuses on,

• System performance compared to performance objectives
• Evaluation of each aspect of system
• Errors made during development
• Benefits or problems that were not anticipated

Why is it necessary to wait before undertaking this review? What will the waiting period allow users to do?

Maintenance

Maintenance is required to ensure that the system continues to meet its objectives. The following factors make this necessary,

• Errors in software
• Change in requirements over time
• Hardware advances
• Changes in legislation
• Perfective maintenance - improve performance without structural change (eg speed, format of output)
• Adaptive maintenance - changes to system to meet new needs (eg change in hardware, o/s)
• Corrective maintenance  - correcting errors that had not been detected previously (the Microsoft way!)

Maintainability is affected by;

• Good Program Design
• Well-structured programs separated into modules which include clear comments and variable names which are instantly comprehensible.
• Use of an appropriate high-level language ensuring a degree of independence from system hardware.
• Comprehensive system and program documentation.
• Records of maintenance work carried out (dates, times, details of work and who completed it)

'Laws' of software maintenance (Lehman & Belady 1985 paraphrased)

The Law of Continuing Change

Software becomes progressively less useful if it doesn't change as the environment in which it is used changes.

The Law of Increasing Complexity

The evolution of software in a changing world leads to ever-increasing complexity which, in turn, makes demands on hardware.

The Law of Large Program Evolution

In large systems, organisational factors tend to complicate system evolution. Changes have to be limited as implementation can be costly and impact across a wide and complex section of the organisation as a whole. Many aspects of the system (file sizes and attributes) will be determined by the way that the organisation is structured and not by the systems developer. Program evolution approaches self-regulation.

The Law of Organisational Stability

The rate of development of a system tends to be almost constant regardless of resources devoted to its development.

The Law of Conservation of Familiarity

Incremental change in each system release tends to be constant.

System Lifecycle - June 2011.pdf

System Development Life Cycle.ppt

Testing.ppt

Worksheet - System Development Life Cycle.pdf