by Robin Beaumont
e-mail: robin@robinbt2.free-online.co.uk
This section aims to provide you with a number of skills (the 'be able to's' below) and relevant information (the 'know what's' below). Details are listed below. After you have completed the session you should come back to these points ticking off those you feel happy with.
|
Learning outcome |
Tick box |
|
Know what the traditional waterfall development method is |
q |
|
Know the advantages and disadvantages of the traditional waterfall approach |
q |
|
Know the two main types of prototyping |
q |
|
Be aware of the similarly between prototyping and the audit cycle |
q |
|
Know the advantages and disadvantages of the prototyping approach |
q |
This chapter describes the various and conflicting approaches taken to developing (possibly computerised) information systems (IS).
The traditional method of developing computer Information Systems (ISs) is often referred to as the waterfall approach. The key stages are shown below. An analyst (=modeller) would come along and possibly convert a narrative document written by yourself into a system design document (called amongst other things a system specification or software requirements specification SRS). Basically this would involve describing how a system (software and hardware) would need to be set-up to fulfil your requirements. You may have specified your requirements in the form of a list of functions you would want the IS to perform called a Functional Specification. The functional specification may adopt a three tier level of compliance:
She / he would make copious use of various diagrams such as flow diagrams (the precursor to dynamic modelling described in the next section), entity diagrams (the precursor to object models) and a data dictionary. By way of a technique known as Structured analysis and design. These documents would then be refined further and eventually translated into a particular programming language (COBOL, BASIC, FORTRAN etc.) to instruct the computer how to behave to imitate the specification. Once the system was up and running a Post Implementation Review (PIR) would be carried out. It is important to note that once the analysis process was completed there would be no further contact between the system developers and the purchaser until they received the system.
The above approach has a clear number of stages each with a deliverable. The progression from one stage to another is in one direction, always forward and never backwards. Finally there is a clear completion stage in the process. This system worked fine when:
The above description of how software may be developed is often called a software development life cycle. The method described above is often referred to as the waterfall lifecycle because of its uni-directional nature. The whole development process of analysis and design including or excluding software development, depending upon your viewpoint, is often referred to as systems modelling. This will be discussed in much greater detail in subsequent sections.
Just in case your thinking that there are only a few methods of developing systems you should note that James Martin 1990 (book 3; p. 450) describes in detail eight categories of software lifecycle, including all the analysis stages where appropriate.
1. From a clinicians or end users perspective list some of the advantages and disadvantages of the above waterfall lifecycle.
2. From a managers perspective list some of the advantages and disadvantages of the above waterfall lifecycle.
Problems with the above traditional method became increasingly acute as more complex software was developed for areas which had not traditionally been suitable for computer systems. Originally computer systems mimicked clerical operations such as invoicing and bookkeeping, with clearly defined procedural tasks and relatively simple data. Very different from the process of a patient moving through a hospital stay or a doctor caring for a long term patient with renal failure.
Specific problems associated with the traditional approach included:
The traditional waterfall approach incorporated a specific method of specifying the IS known as structured analysis and design which presented its own problems:
The central issue was the belief that it was possible to elucidate the true requirements from the stakeholders. However both the stakeholders and the analysts were equally unsuitable to specify the requirements. The stakeholders where usually the commissioners of the project who understood little of the realities of what would make a successful implementation. Similarly the analysts lacked domain expertise (i.e. in the Healthcare arena possessed no health care knowledge). Along with these conceptual problems there existed (and still exists) a over optimistic belief that requirements could be specified using the various analysis techniques around. A famous software book The mythical Man-Month, by Brooks (1975) breaks the seal on the mythical waterfall approach to systems design:
"In most projects the first system built is barely usable. It may be too slow, too big, awkward to use, or all the three. There is no alternative but to start again, smarting but smarter, and built a redesigned version in which these problems are solved….
The management question is, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to the customer. Seen this way, the answer is much clearer."
Quoted in Beyond Programming by Bruce Blum OUP 1996 p.253
Many different solutions to these problems have been offered. However we will concentrate on two, Prototyping and participative design methods. Prototyping will be considered in this section and participative design methods elsewhere in this chapter.
Suggest some solutions to the problems associated with the traditional waterfall approach.
Although there are several varieties of prototyping we will only consider two:
Incremental prototyping is a method of developing a computer system by a process of delivering a small but complete part of the system each time. Imagine building a kitchen by getting a new unit each month. Each prototype therefore provides more facilities than the previous version. By way of an example consider a maternity system. The system developers may decide upon the following delivery:
May '94 Patient Registration/ discharge facilities
Sept. '94 Basic reporting facilities
March '95 Clinical module
July '95 Clinical / audit report facilities
Nov. '95 Full reporting facilities and Casemix
Incremental prototyping therefore
works by delivering a completely finished small part of the system
each time until a complete system eventually emerges.
Nielsen 1993 (p94) describes this type of prototyping as vertical prototyping. You can see why by looking at the diagram below. The depth (height) represents the functionality of the IS and the width represents the breath of the system. Therefore an incremental prototype delivery represents a vertical slice.
This is in direct contrast to the process of evolutionary prototyping described below.
In this process the system designers create right from the start a mini system of the bare essential facilities required. Taking the same example as above:
May '94 Basic Patient Registration/ discharge, clinical and reporting facilities
Sept. '94 Evaluation and review of requirements
March '95 Second attempt
July '95 Evaluation and review of requirements
Nov. '95 Formal development of final system
Evolutionary prototyping is therefore the process of developing a computer system by a process of gradual refinement. Each refinement of the system contains a system specification and software development phase. In contrast to both the traditional waterfall approach and incremental prototyping, which required everyone to get everything right the first time this approach allows participants to reflect on lessons learned from the previous cycle(s). It is usual to go through three such cycles of gradual refinement. However there is nothing stopping a process of continual evolution which is often the case in many systems.
Nielsen 1993 (p94) describes this type of prototyping as Horizontal prototyping. You can see why by looking at the diagram below where he depth (height) represents the functionality of the IS and the width represents the breath of the system. Therefore an incremental prototype represents a horizontal slice
The diagram below shows the evolutionary software development lifecycle. Those of you who are familiar with the audit cycle will note immediate similarities, as will those of you who know the nursing process.
The diagram below shows the above lifecycle with three goes at development. This is based upon a project I was involved in called Prodigy, which was developing the prescribing aspect of GP computer systems.
Although this approach may seen radical it must be noted that the original article was published as long ago as 1988 by Boehm who described in depth such a process alongside examples of its use. Possibly this demonstrates just how far behind software development is in the health sector!
What additional resources may be required for the evolutionary prototyping approach over that for the traditional waterfall approach.
The main problems with evolutionary prototyping are due to poor management:
How might some of the above problems associated with evolutionary prototyping be solved.
A more detailed iterative prototyping development method which takes into account the above factors can be found in chapter 12 section 'Getting the users involved'.
This chapter introduced the various ways Information Systems (ISs) can be developed in contrast to the haphazard way most systems seem to have evolved. The traditional waterfall approach was described and evaluated alongside the more modern alternative of prototyping. An example of how evolutionary prototyping is being used in the health care arena was given. Iterative prototyping will be described in greater depth latter in the chapter.
The article about evolutionary prototyping:
Boehm Barry 1988 A spiral model of software development and enhancement. Computer 21, 5 61 - 72.
A book describing the various approaches taken to software design over the years :
Blum Bruce 1996 Beyond programming. OUP. Oxford.
Nielsen J 1993 Usability Engineering. Academic press London
Document info:
Robin Beaumont Tel:(UK) 0191 2731150 e-mail: robin@robinbt2.free-online.co.uk
Source: Laptop; C:\HIcourseweb new\chap12\s3\des1.doc 15/09/1999 11:26
