effectiveness of the site in fulfilling its purpose must be evaluated in the same way as any other IT investment, to ensure that business requirements are being met and
problems are identified.
132
Discovering Information Systems
Section IV
11. IS Planning and Acquisition
11.8 Exercises
11.8.1 Value chain
For each stage of the (primary) value chain, how could IS be used to cut costs or add value to business activities?
11.8.2 Software acquisition options
The different software acquisition options available to organisations include in-house
development, commercial packages, outsourcing and end-user development. Compare these
three approaches in terms of each of the following factors:
• Cost control: how well can costs be estimated at the start of a project, and how successfully can budgets be enforced?
• Availability of expertise: how likely are you to run into difficulties if the project turns out to be more complex than was initially envisaged?
• Quality of the final system: can you be sure that the final system will meet your requirements, and will do the job without errors?
• Documentation and training: will these be available when the system is first used, and at later stages if required (e.g. for new staff)
• Maintenance: how easy will it be to make changes to the system in five years time?
In ten years time? What if you need to integrate other systems with this one?
Discovering Information Systems
133
12. System Development
Section IV
12. System Development
This chapter will provide you with an overview of the systems development process. First we describe in detail the traditional Systems Development Life Cycle (SDLC), encompassing the stages through which each system should pass, from the initial survey to hand-over of the completed system.
Pressure for rapid development and future maintainability of systems has resulted in a number of alternative approaches to systems development, ranging from development by end-users, to the incorporation of formal methods to improve the quality and efficiency of the development process.
12.1 Systems Development Life Cycle (SDLC)
Systems development could be seen as the simple process of writing programs to solve the needs of the user. Unfortunately the user knows what he wants but has no technical expertise while the programmer understands the computer but not the user environment. This
communication gap between the customer and the service provider must be handled by an
intermediary, the systems analyst. Broadly speaking therefore the systems analyst translates user’s needs into detailed specifications for implementation by the programmer.
Over the years the software manufacturing process has become more formalised:
“The basic idea of the systems development life cycle is that there is a well
defined process by which an application is conceived, developed and
implemented. The life cycle gives structure to a creative process. In order to
manage and control the development effort, it is necessary to know what should
have been done, what has been done, and what has yet to be accomplished. The
phases in the systems development life cycle provide a basis for management
and control because they define segments of the workflow which can be
identified for managerial purposes and specify the documents or other
deliverables to be produced in each phase.” [Davis and Olson, 1985]
The number of stages and names to describe those stages differ slightly between
organisations; but the SDLC normally covers the activities shown in figure 12-1, each with a primary purpose.
12.1.1 Preliminary Investigation
The preliminary investigation is carried out to determine the scope and objectives of the new system and to investigate whether there is a feasible solution. New applications normally originate from end-user requests and are weighed against the other requests for IS resources before approval to develop the system is granted. At this stage an analyst or small project team is authorised to investigate the real potential of the new application. During this brief study the analyst must investigate the problem and the existing system sufficiently to be able to identify the true extent and purpose of the new application.
In order to ensure that the new system would be of greater benefit to the organisation than 134
Discovering Information Systems
Section IV
12. System Development
other competing requests for proposals, a feasibility study must be performed covering the following three major areas:
• Economic feasibility to measure the costs and benefits of the new system.
• Technical feasibility to ensure that the organisation has sufficient hardware, software and personnel resources to develop and support the proposed system.
• Operational feasibility, the willingness and ability of management, users and
Information Systems staff in the organisation to build and use the proposed system.
PRELIMINARY INVESTIGATION
Understand the problem and test for feasibility
ANALYSIS
Investigation to determine what the user requires and
identify the most cost-effective solution
DESIGN
Develop specification of how the new system will run
BUILDING
Build or program the new system
IMPLEMENTATION
Convert to the new system
MAINTENANCE
Ongoing enhancement and support of the new system
Figure 12-1: Systems Development Process
Issues such as the size and complexity of the new system and the skills and availability of user and IS staff, will determine the level of potential risk to the organisation in developing the system.
The output from this preliminary investigation is a statement of scope and objectives (often termed the project charter) together with a feasibility report. This document is submitted to management where a decision is made as to whether or not the development project should
continue.
12.1.2 Systems Analysis
In this stage the analyst investigates the needs of the user and develops a conceptual solution to the problem. One human failing we all tend to exhibit is to rush into proposing solutions Discovering Information Systems
135
12. System Development
Section IV
before we fully understand the problem we are trying to solve. It is therefore important for the analyst to develop a broad, conceptual solution to the problem (what needs to be done) prior to launching into the detailed physical design where we specify how the system will work.
In the past analysis tended to be very much a pragmatic affair with success more dependent on the experience and capabilities of the analyst than on any formalised approach. The
analysis phase should include the following discrete steps:
• Understand how the existing system operates. This information can be obtained by observing people at work, interviewing users, and studying procedure manuals and other
supporting documentation, questionnaires and visits to other organisations.
• Document the current physical system. A major problem in the past was how to record all the detail about the system. Most of it could be found only in the analyst’s head or draft notes. Here the basic tools of structured systems analysis such as the data flow diagram (DFD), the entity relationship diagram (ERD) and data dictionary (DD) can be used to
represent graphically and record the data and procedures. We will discuss these later in the chapter.
• Define the problem areas. These may include such issues as poor response times in the existing system, poor presentation of current information, high costs or weak controls in the current system, waste and sometimes duplication.
• Identify new requirements. The analyst must attempt to identify new user requirements and look for new and improved procedures that can be incorporated into the system.
• Identify possible solutions. Having derived objectives for the new system from the previous stage, the analyst now develops a conceptual model of the new system in
conjunction with the user. This may involve the investigation of alternative physical
designs, such as whether to remain with the existing manual system, or to choose a
centralised or decentralised approach to the application.
• The culmination of the analysis stage is the preparation of the formal user requirement specification (URS) that incorporates a logical model of a system that will meet the user’s requirements. A large proportion of the functional description and data specifications is best communicated from the analysis stage to the design stage through the graphic and
electronic output from the structured tools used in the analysis process (data flow
diagrams, entity relationship models, decision trees and the data dictionary).
• Again management is required to review the status of the project and to make its go/no-go decision.
12.1.3 Systems Design
The analysis stage of the SDLC has clearly identified what must be done in order to meet the user’s requirements. One important decision that must be taken at this point is whether to
“make or buy” the new software application. In the past, most large organisations developed their own applications as no two organisations were exactly alike, and they could afford the 136
Discovering Information Systems
Section IV
12. System Development
investment in systems developed around their user’s needs.
Today the picture is changing as custom-built software is becoming very expensive to
develop and even more so to maintain. Computer applications are large, complex and
integrated and many businesses have become non-competitive because of their inability to develop systems that adequately support their business activities.
On the reverse side, packages (pre-written software applications) are becoming more common and can be customised to meet the needs of each organisation. With major benefits in terms of speed of installation, cost, low maintenance and low risk, more and more
companies are switching to packaged applications software. It is at this stage in the SDLC that the “make or buy” decision must be taken. We have analysed our user’s requirements and can use these as selection criteria in searching for an appropriate package to purchase and install.
Where there is no suitable package available we can still look to other innovative ways of obtaining the software, such as hiring contract staff or appointing a software house to build the system for us. Purchasing pre-written software will obviously mean the detailed systems design, coding and testing phases of the project are bypassed, depending on the need for customisation of the final system. In later courses we will look at the package selection process in more detail.
The objective of the design stage is to determine exactly how the new system will work, and to communicate this information in a document referred to as the detailed systems
specification. If we take the analogy of an architect building a house, in the analysis stage he has determined the feasibility of the project and identified the owner’s requirements in terms of the positioning of the house on the plot, size and architectural style, number of rooms and so on. The architect may even have built a small model to demonstrate the look and feel of the new dwelling. Once the owner is happy that the proposed house meets his requirements, the architect must communicate the detailed design to the builders. This would entail the drawing of a detailed plan of the house, specifying exactly how every part of the building is
constructed and defining dimensions, materials, construction techniques etc.
We need to go through the same process when designing computer systems. This includes the design of:
• the technical platform on which the software will run. The new application may need
new hardware, operating systems software and network connections
• output reports and enquiry screens
• input forms and data capture procedures
• physical file and database layouts
• description of the workings of each program module
• new clerical processes and procedures that will be required to interface with the new system.
Whereas in the analysis stage the emphasis was on identifying the user’s needs with little concern for the way the computer would be used, the design stage also requires user
involvement for the approval of detailed design, but the physical constraints imposed by the Discovering Information Systems
137
12. System Development
Section IV
computer are also of major importance. Gane and Sarson [1979] define the objectives of
structured design as follows:
“The most important objective of design, of course, is to deliver the functions required by the user. If the logical model calls for the production of pay cheques and the design does not produce pay cheques, or does not produce them correctly, then the design is a failure. But given that many correct designs are possible, there are three main objectives which the
designer has to bear in mind while evolving and evaluating a design:
• Performance. How fast the design will be able to do the user’s work given a particular hardware resource.
• Control. The extent to which the design is secure against human errors, machine malfunction, or deliberate mischief.
• Changeability. The ease with which the design allows the system to be changed to, for example, meet the user’s needs to have different transaction types processed.
The output from systems design is a detailed design specification incorporating technical, input, output, data and process specifications. In the past, much of the information was communicated in written form which was difficult to understand and often ambiguous.
Imagine the builder having to construct a house from a written description. Like the output from analysis we have a number of innovative tools to help users and developers understand and communicate the workings of the system. These include data models and data
dictionaries, screen and report layouts, structure charts and pseudo-code. We will look at most of these later in this chapter.
12.1.4 Systems Build
In this stage we program the new system. If the system has been purchased “off-the shelf”, this phase would consist of the customisation of the system. The success of the
implementation stage is heavily reliant on the previous stages. If the analysis stage was poorly enacted, the system may not be what the user requires. Poor design will make it difficult for the programmer to construct the system, and it may be inefficient and difficult to maintain.
However, if the required effort and expertise is invested in analysis and design, there will be a precise specification of what to build available to the IS programmers and technical staff.
Unlike the previous stages, the programming stage can be undertaken as a number of separate tasks, performed in parallel. Programmers can code, data base administrators set up the
database, hardware suppliers install and test networks and equipment, and we can begin to train the end-users to prepare them for the implementation phase. With so much happening, and with the need for some tasks to be completed before others begin, the analyst must
develop a detailed project implementation plan to ensure tasks are scheduled and delays are quickly identified and addressed. Programming includes the following steps:
• database construction
• program coding and testing
138
Discovering Information Systems
Section IV
12. System Development
• systems testing to check the system can handle expected loads and meets physical
performance criteria
• finalise manual procedures
12.1.5 Systems Implementation
This entails the transition of the completed system into the operational environment, and includes the following tasks (some of which will already have been started in earlier phases):
• installation and testing of any new hardware, systems software and network
infrastructure
• train users and operations staff
• transfer data (data conversion)from the manual or old system to the new database
where necessary
• perform acceptance testing. This requires careful planning to ensure all data flows,
error procedures, interfaces, controls and manual procedures are tested
• complete project documentation
The change over carries some risk, as failure of the new system may result in the organisation being unable to do business, There are a number of approaches to converting from the old system to the new. The least risky is to run the new system in parallel with the old until the new system is stable. There is obviously a cost to running both systems. Another approach is to convert one part of the organisation at a time (for example one branch office at a time).
This method (known as the pilot method) reduces risk and allows the development team to
focus on one area. This approach can cause some integration problems as part of the
organisation is running on the old system and part on the new. A similar approach is the phased implementation method where organisations convert to a large system one step at a time. For example they may start with the stock system, then implement debtors and finally the order entry system. Some organisations use the big bang approach and just switch over from the old to the new system. This option is obviously high risk as there is no system to fall back on in an emergency.
When the new system has been in operation for a few months, a post-implementation audit should be carried out. This audit must ascertain whether the project has achieved the initial objectives specified in terms of:
• meeting initial scope and objectives
• anticipated costs and benefits to the organisation
• user satisfaction with the new system
• performance (response/turnaround time, reliability)
• adherence to standards
• quality of final product
• project performance in terms of cost and time.
This exercise will help to highlight problems that require maintenance of the new system and Discovering Information Systems
139
12. System Development
Section IV
provide valuable feedback to IS management and project teams to assist in future
development exercises.
12.1.6 Maintenance
Finally resources will be required to maintain and enhance the system over its operational life which can vary between 4 and 10 years. There is normally a formal hand-over of the system from the project team to the maintenance team. This will ensure that there is a defined time when the project is completed and that all the required documentation is produced. There are many systems in existence that are still supported by the original developer; and all
knowledge of the system exists only in that individual’s head. The problem is that when this person leaves (or worse gets run over by a bus), there is no one with any knowledge of the system and the organisation is at risk.
Research has shown that this is the most expensive stage of the life cycle as program bugs (as a result of poor design or bad coding and testing) or enhancements (poor analysis of user’s requirements or changes to the business) require continual analysis and programming effort.
The following table summarises the important tasks in the six stages of the SDLC and
highlights the main deliverables from each task.
Stage
Tasks
Deliverables
Preliminary
Problem Definition
Project Charter
Investigation
Scope and Objectives
Feasibility Study
Data Gathering
Risk Assessment
Feasibility Analysis
Systems Analysis
Data Gathering
User Requirements
Systems Modelling
Specification
User Requirements
Definition
Systems Design
Make or Buy Decision
Detailed Systems
Physical Systems Design
Specification
Technical Design
Systems Build
Programming and testing
Production System
Platform Implementation
Systems
User Training
Live System
Implementation
Data Conversion
Systems Conversion
Post-Implementation Review
Systems
Fix system “bugs”
Working System
Maintenance
System enhancement
Figure 12-2: SDLC Tasks
12.2 Development of Structured Methodologies
New and innovative systems development techniques are frequently proposed by researchers 140
Discovering Information Systems
Section IV
12. System Development
and practitioners and, over time, these formal methods have replaced the traditional pragmatic approach to developing computer systems.
12.2.1 Structured Programming.
In the 1960’s, the major concern in IS development environments was the efficient utilisation of expensive computer hardware. Programs were written in low level languages with little or no support documentation and, over time, the code became almost impossible for
maintenance programmers to understand and fix. So arose the need to introduce a set of
standard rules and procedures for writing programs, often referred to as structured
programming. Some of the key techniques in the structured programming approach include:
• a limited set of simple control structures (to control branching and looping)
• standard naming conventions for data and procedures
• self documenting programs.
Structured programming techniques ensured that programs were easier to write and test and much easier to maintain.
12.2.2 Structured Design.
In the mid 1970s the focus in systems development moved from program coding to systems
design. Computer applications were becoming more complex with the introduction of large
on-line, integrated systems.
IS researchers, and in particular Larry Constantine, studied the problems of program size and complexity, and determined that, as a problem grew in size, so there was a more than
proportional growth in the complexity of the problem and therefore in programming time. He advocated that all systems should be made up of small modules each no longer than fifty lines of program code.
Fragmenting a problem into a number of modules can be done in many ways; and he urged
that the best technique would be to segment the program by function (task) with each module being as functionally independent of other modules as possible. This would ensure that
changes to one program module were unlikely to affect other modules.
This technique was known as structured design; and a graphical representation of the modules and their relationships known as a structure chart, was developed to assist in the process.
12.2.3 Structured Analysis.
In the late 1970s the focus in systems development moved again, this time to the analysis stage. IS professionals had formalised the design and coding of computer software but had neglected the most important development issue – what are the user’s real requirements.
Written specifications were the main source of communication throughout the project. In the same way that architects would never attempt to describe a building in a letter, so analysts needed tools and techniques which could be used to define and communicate the user’s
Discovering Information Systems
141
12. System Development
Section IV
requirements to the systems design stage. These structured tools and techniques included:
• Data Flow Diagrams (DFD). These diagrams are used to show how data flows between the various processes in the system. DFD’s are an excellent communication tool as they
are simple enough for users to understand and yet detailed enough to form the basis for the systems design process. A number of DFD techniques has been developed since the
original work