Information System Development:Information systems development life-cycles

1.3 Information systems development life-cycles

1.3.1 Waterfall life-cycle

The waterfall life-cycle of systems development subdivides the process into formal stages where the output of one stage forms the input to the next. The deliverables cascade down the waterfall with a completed software system at the bottom. The first stage, the feasibility study, is concerned with defining the scope and purpose of the new system, considering a range of alternative solutions and investigating the impact of the new system on the organization. The decision point following the feasibility study is for management to sign off on a preferred solution.

In the requirements stage, the requirements are specified in logical form, that is, in terms of 'what' is required rather than 'how' it will be achieved technically. The requirements specification should be signed off by the business user - an agreement that the system, if built as specified, will meet the needs of the business.

Design is concerned with translating the requirements into a software system specification that can then be turned into a working system by systems developers (coding). Thorough testing is vital and is often done at three levels. The first level of testing is for the programmers to unit test the program modules. Once the programmers are satisfied with the individual modules, then the system can be put together for a systems test. The systems development staff develop a comprehensive test plan and devise test data and subject the system to exhaustive testing. This might include peak capacity testing to see how many transactions the system can manage simultaneously before performance degrades to an unacceptable level or the system fails entirely. The third level of testing is the user acceptance test. Once the development team is happy with the systems testing, then the system is handed over to the users who then conduct their own (and independent) test of the system. Once the system successfully passes user acceptance it can be transferred to live operations, where it will then be monitored and maintained as software errors ('bugs') and enhancements are identified.

1.3.2 Problems with the waterfall life-cycle

Taken at face value, the waterfall life-cycle shown in figure 1.1 is appealing for its orderly and systematic stepwise refinement of a complex problem into smaller and smaller problems.

Figure 1.1: The waterfall life-cycle for systems development

The waterfall life-cycle has roots in hardware and software engineering and although suitable for designed artefacts such as computer chips and bridges, it is less appropriate to human activity systems where the human and organizational factors are less easy to identify. (We would also argue that bridges and chips are human activity systems that can also suffer from a strict engineering-only approach.) For information systems with well-structured requirements, such as an airline reservations system, or applications with a safety critical aspect (for example, a nuclear reactor control system), then the formality of the life-cycle model, possibly combined with formal methods, may well be appropriate.

However, for many information systems development projects, the life-cycle approach has limitations: it is expensive, time-consuming, and inflexible. Perhaps the most significant limitation is that the life-cycle approach assumes that the requirements can be specified with reasonable completeness before design begins. Often, users do not know (or cannot articulate explicitly) the requirements until the finished system is in use. Further, requirements are not fixed - they change over time as the project unfolds and the environment changes. This makes the formulation of a complete and permanently correct specification of requirements an unrealistic goal. It is also difficult to separate out the specification of an information system from its implementation, that is, the 'what' and 'how' of IS development are closely related and difficult to separate. Knowledge of how to implement and what is technically feasible affects perceptions of what can be done in the user world.

The waterfall life-cycle prescribes clear communication points between users and developers (for example, sign off of specification, sign off of user acceptance test) but it does not promote a mutual process of learning and coordination. Furthermore, the formal products of IS development, such as the specification of requirements, are often meaningless to users (even if they had the time and the inclination to read them). Any change to requirements after the sign-off point will be expensive - it is estimated that requirements errors cost 200 times more to fix if not discovered prior to implementation. All of these problems result in an inflation of the maintenance activity as developers attempt to fit the information system to actual working practices based on real experience. As maintenance often comes from a different budget than the original development, many organizations significantly underestimate the true cost of IS development.

So, why is the waterfall life-cycle still used? A cynical view would be that it is used to provide milestones and frozen deliverables to keep managers happy and to give them the illusion that they are in control of the IS development process. A more balanced view suggests that the life-cycle approach may work well in certain circumstances. Where the requirements can be articulated clearly, as might be the case where an existing IS is being replaced and the developers have in-depth experience of the application domain, such as a payroll or inventory application, the waterfall life-cycle approach may well be appropriate.

1.3.3 Alternative life-cycles

The shortcomings of the waterfall life-cycle have led to more flexible approaches being explored. Altecrnatives to the waterfall approach include evolutionary development (figure 1.2b) and incremental development (figure 1.2c).

Evolutionary development

In evolutionary development, shown as figure 1.2b, the system is developed using a prototype and refined through user feedback of the system in use and changes in the application itself. The operational system is improved all the time through responses to this user feedback. Change is therefore seen as the norm and catered for - a sharp comparison to the waterfall life-cycle discussed earlier, where change could be very expensive to implement.

Figure 1.2: Life-cycles for systems development

Iterative (rapid) application development

The key objective of rapid application development (RAD) (figure 1.2c) is the delivery of working business applications in shorter timescales for less investment. With RAD the system is developed in chunks of functionality in accelerated and time-boxed cycles of development. RAD normally involves users and developers to jointly agree requirements in workshops. In particular, critical requirements (as against those 'nice to have') are identified. Different aspects of the system may be developed at different times, the most important usually being in the first time-box, and the overall system is therefore implemented incrementally in these chunks by small teams of users and developers. The assumptions underlying RAD include (adapted from Beynon-Davies et al., 2000):

• Iterative incremental development: an information system can be complete but it is never finished and must be allowed to evolve and adapt over time. Users cannot specify with absolute certainty what they want from an information system in advance and therefore an incremental and iterative approach is needed to explore the requirements as they unfold. RAD is a process of organizational learning through iteration of design, construction, testing, and evaluation of development artefacts

• Top down refinement: it is difficult for users to specify requirements accurately and in detail in advance; it is better to specify the requirements at a level that is appropriate to the stage of the development and to develop the detail as the project progresses through incremental development

• Active user involvement: the schism of the user/developer divide, which is structurally imposed in the waterfall life-cycle, leads to difficulties in requirements elicitation, ownership, and politics. In RAD the divide is broken down through co-located teams and joint application development workshops

• Small empowered teams: teams of four to eight are typical in RAD, promoting effective communications and empowered users. Small teams help reduce bureaucracy and enable quick and effective decision-making. The team is often supported by a facilitator and can benefit from extra-curricular team-building activities

• Frequent delivery of products: in RAD the delivery of working applications is constrained to shorter periods, such as 90 days - the aim is to deliver working product, not process

• Software development toolset: toolsets are available which allow developers to generate program code with graphical user interfaces from requirements specifications automatically, allowing them to provide the user with prototype applications quickly for evaluation. In RAD the application becomes its own self-documenting model, avoiding the tendency in the waterfall life-cycle to overwhelm the user with large amounts of paper-based documentation.

End-user development

A rather more radical approach to IS development is to hand over the development work to the users. The advantages are obvious, in particular, the users will know the requirements and once involved to the extent of developing the application, will have control over this aspect of their work, thus increasing job satisfaction. The approach has the potential of leading to more successful applications. Many of the limiting factors to end-user development are disappearing. Users use computer systems normally in their job, frequently on personal computers and use applications software, such as the Microsoft Office suite of word processor, spreadsheet and database, and other applications. Such software, particularly MS Excel and MS Access, can be used to develop quite sophisticated applications. Present-day users do not usually have the attitude that computers are nothing to do with them, which used to be commonplace. Further, there are software tools available which are designed to help less-experienced users carry out rudimentary system development for themselves.

1.3.4 Prototyping

Prototyping can be used in all three life-cycle models of figure 1.2. With the traditional waterfall life-cycle, prototypes can be generated in the requirements phase to test out the understanding of the user requirements. This gives the users an executable specification and gets round the problem of poor communications using formal paper-based specifications. It would seem far better to use a form of requirements specification that is similar to the final system. The prototype is typically to be thrown away - it is dispensed with prior to design. As a working system it might be inefficient, incomplete or inadequate in some other way.

In evolutionary development, the prototype evolves through a series of improvements until the users find a version acceptable. Even so, it might be operational fairly early on, but the prototype operational system develops further through incremental improvements and it may never reach a stage where it can be seen as the final version.

In RAD, the prototype typically becomes the final system or at least part of the final system as the time-box modules are implemented in turn. Nevertheless, it might also be thrown away in favour of a more robust design that follows the applicability of the prototype. Thus, to speak of prototyping as a life-cycle for IS development can be misleading.

1.3.5 Agile Development

Agile software development (ASD) encompasses approaches such as Extreme Programming (XP), Lean Development, and Scrum (Highsmith & Cockburn, 2001). As with rapid application development, the premise of ASD is that change is inevitable. Rather than treat the changes to requirements that arise as a project unfolds as an exception it is better to assume that requirements will change and to focus instead on reducing the cost of the associated rework. Extreme Programming encourages development teams to:

• Produce the first delivery in weeks - get feedback quickly and create credibility through an early win

• Go for simple solutions that can be changed easily and quickly

• Improve design quality so that subsequent versions cost less to build and implement

• Make testing an on-going activity so that errors are caught early.

ASD focuses on the 'keeping it real' through the creation of program code - code is less forgiving (it generally works or it doesn't) than requirement specifications and abstract designs. The Agile Software Manifesto (Highsmith & Cockburn, 2001) values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan.

The manifesto recognizes there is value in the terms on the right, but values the left (italicized terms) more highly. Typical cycles are of two to six weeks duration with Scrum working on 30-day cycles. The agile approach is feature led, rather than project plan driven, with features being prioritized dynamically as circumstances change. The focus on program code and speed has opened ASD up to the criticism of being a hackers' charter. A more balanced view is to see agile methods in a spectrum that ranges from hacking to development based around micro-milestone ironbound contracts (figure 1.3). The choice of where to position a project on the spectrum must take account of a broad range of factors such as the organization culture, the external environment, type of application, and the level of risk.

Figure 1.3: IS Development planning spectrum (adapted from Boehm, 2002)