Systems development lifecycle

An Accounting Technician should be able to make a contribution to the process of developing information systems in their workplace. This is reflected in the syllabus for paper B3: Information Technology Processes which requires students to have an outline understanding of the systems development lifecycle.

There are a number of different ways of describing the various stages of the systems development lifecycle. The syllabus is not prescriptive about the exact format to be used in answering questions so candidates are not confined to a particular approach. However, the distinct stages set out below give a clear guide to knowledge required to be able to answer a question on this topic in the examination.

Justification

A systems project usually commences with the formal justification of the project. This is usually performed in the Feasibility Study and the results summarised in a Feasibility Report. This stage is concerned with defining the business benefits that will accrue from implementing a new system and comparing these benefits with the costs of delivering them. The costs usually consist of expenditure on hardware, software, training and operational costs, for example, stationery. The benefits are best expressed in financial terms (e.g., increased sales revenue, reduced costs) so that they can be directly compared with the costs of delivering the solution using a standard cost-benefit method such as Payback Period. It is possible that, as a result of the feasibilty study, it is decided to keep the existing system because the benefits of making changes are outweighed by the costs.

The justification stage should ensure that competing projects are allocated appropriate priority. Using a standard way of comparing project costs and benefits ensures that those projects that deliver the most benefit to the organisation are delivered first. Most organisations have limited resources and so these must be carefully allocated. Priority determined by business benefit is demonstrably better than selecting projects by enthusiasm, technical interest or the status of the project's proposer.

Investigation and analysis

These stages involve the investigation and critical appraisal of the current system and the requirements for its successor. This process will result in the specification of the requirements for the new system. This process is often termed Systems Analysis. The operation of the current system will be investigated and modelled. Many of the current processes will have to continue in the replacement system and so their functionality has to be defined and agreed. This is also the stage where users define the requirements of the proposed system and these are also modelled and summarised in a document often called the Functional or Systems Specification. Such specifications should be agreed by the user and so they should comprise products that users can understand and formally sign-off.

The investigation allows the system to be properly understood before it is amended. It allows the investigators (often called Systems Analysts) to understand the operations, requirements and fears of the users. Once the workings of the existing system have been documented, they can be analysed. This process examines why current methods are used, what alternatives might achieve the same, or better, results, what restricts the effectiveness of the system and what performance criteria are required from a system.

At the same time their increasing understanding of the business requirements will lead the users to become more confident about the skills and knowledge of the Systems Analyst. Hopefully respect and rapport will develop. The Systems Specification is written in business rather than technical terms which allows the user to sign off a systems requirement they understand and are confident will meet their needs.

Some textbooks may describe the above two separate stages - systems investigation (leading to a Requirements Analysis document) and systems specification (leading to a Requirements Specification document). Answering examination questions using this format is perfectly acceptable.

Design and development

The specification of the system requirement is turned into a physical system during these stages. This is often called Systems Design. The user models of the Functional Specification are refined into more detailed specifications for the systems developer. This first stage of refinement is often called Logical Design. Physical Design is concerned with specifying program designs, file layouts, input screens and output reports. It is the physical design that provides the blueprint for producing working software and the tasks of programming and program testing take place within this stage. The working system is usually tested by the Systems Analysts before it is released to the user to ensure that it meets the specification. This is usually called systems testing.

The design stage of the systems development lifecycle concentrates on turning the functional specification into a working system. Consequently developers can focus on producing quality software rather than still concerning themselves with the requirements of the user. This means that design does not have to take place at the user's site and may in fact be moved to an area of cheaper labour where programmer salaries are much lower.

Some textbooks may describe design and development in two or three stages (for example: Logical Design, Physical Design and Physical lmplementation). Students would not be penalised if they used this approach in answering questions.

Acceptance testing

This stage of the systems development lifecycle ensures that the design meets the specification of the user. On receipt of the system (after its successful systems test) the user must ensure that it does in fact meet their requirements and that it performs acceptably in the real environment. In this stage the user usually establishes a set of user acceptance tests to formally prove and accept the system. These tests are usually undertaken by user staff who not only check the functionality of the system but also ensure that the system is easy and logical to use. Users will also need to ensure that all cyclical functions (such as month and year-ends) work successfully.

A good example of a question on the systems development lifecycle can be found in the June 1998 examination.