Information Systems Management Information Systems Assignment

cHAPTER

7 An introduction to acquiring

and developing BIS

CHAPTER AT A GLANCE

MAIN TOPICS

■ How and why are information systems acquired? 264

■ Software acquisition and the systems development lifecycle 269

■ Bespoke development 274

■ Purchase of an off-the-shelf package 282

■ User developed software 285

CASE STUDIES

7.1 Lloyds Bank Insurance Services applies RAD 275

7.2 Use of waterfall v. agile methods at Mellon Financial 280

7.3 Lascelles Fine Foods 286

LEARNING OUTCOMES

After reading this chapter, you will be able to:

■ evaluate the different alternatives for acquiring BIS;

■ distinguish between the typical stages involved in building BIS;

■ explain the purpose of each stage in building a system;

■ select the best alternative type of approach or methodology for building a BIS.

MANAGEMENT ISSUES

Managers need to select the optimal method for introducing a new BIS once an opportunity is identifi ed. From a managerial perspective, this chapter addresses the following questions:

■ What are the alternatives for systems acquisition and how is the most suitable approach selected?

■ What alternative models are there for the different stages for introducing a BIS? Which is most appropriate?

■ Which activities need to occur at each stage for the project to be successful?

M07_BOCI6455_05_SE_C07.indd 263 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT264

This chapter provides the foundation for subsequent chapters in Part 2 by taking a broad look at the main activities involved in acquiring and building new business information systems. The word ‘acquire’ is used deliberately here, since ‘development’ implies the writing of bespoke software for a business information application. However, since many business applications can be purchased off the shelf without the need for any detailed design or programming activity, ‘acquisition’ more precisely defines the process we are going to outline here.

This chapter will start by reminding ourselves about the business rationale for information systems. We will then consider, in broad terms, alternative approaches to the acquisition of new computer-based information systems, ranging from creating new bespoke systems through to purchasing off-the-shelf applications.

BIS acquisition describes the method of obtaining an information system for a business. The main choices are off-the-shelf (packaged), bespoke (tailor-made) applications developed by an in-house IT department or a software house, and systems that are end- user-developed (i.e. by non-IS/IT professionals).

We will then review the traditional systems development lifecycle (SDLC), sometimes known as the ‘waterfall model’ of systems development within the specific context of bespoke software development. This defines the different SDLC stages involved in developing a new system. Any BIS project follows a logical series of development phases. Typical stages are: initiation, feasibility study, analysis of business requirements, systems design, system build and implementation and, finally, review and maintenance. The stages will be summarised in this chapter in preparation for a more detailed description in subsequent chapters. The analysis of bespoke software development will also incorporate some of the different methodologies for building systems such as rapid applications development (RAD).

From bespoke development, we will move on to consideration of factors affecting the acquisition of packaged software, and in particular software selection factors. We will also consider how the traditional systems development lifecycle applies to the purchase of packaged software and where the key differences lie when compared with bespoke software development.

Finally, while end-user computing is addressed in more detail (in Chapter 16), we will look briefly at user-developed applications where information systems are developed by IS users for their own or their department’s usage in the context of the steps of the SDLC that apply.

INTRODUCTION

BIS acquisition

The process of evaluating and implementation for a BIS.

Systems development lifecycle (SDLC)

Any information systems project follows a logical series of development phases. These are known as the systems development lifecycle.

SDLC stages

Initiation, feasibility study, analysis of business requirements, systems design, system build and implementation and, finally, review and maintenance.

HOW AND WHY ARE INFORMATION SYSTEMS ACQUIRED?

Organisations spend significant sums on information systems and it is important to understand the business context within which information systems are acquired. Earlier (in Chapters 1 and 2) we looked at a number of topics including:

■ the qualities of ‘good’ information to support effective decision making; ■ the business environment, both internal and external, and the ability of information

systems to impact positively on it; ■ the information needs of managers at different levels of an organisation and how this

results in different categories of business information system; ■ how BIS can produce a strategic advantage for an organisation.

Figure 7.1 demonstrates that an organisation’s information systems needs are driven by business strategies and policies which in turn are driven by both the internal and external business environment.

M07_BOCI6455_05_SE_C07.indd 264 30/09/14 7:20 AM

265ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

An organisation’s business strategy will determine where the business is going, and why. This in turns creates ‘demand’ for information and the applications software that can provide it. What remains is the need to acquire, implement and manage these solutions and this is the stimulus for the software acquisition process.

Whilst many texts deal admirably with the range of tools and techniques available to the systems analyst for bespoke systems development to meet these needs, there is a tendency to forget that bespoke development is only one method of software acquisition. In fact for many businesses, especially small and medium-sized enterprises, bespoke applications development is not a viable option because of the costs and practical difficulties involved. It is necessary, therefore, to begin by looking at the range of acquisition methods and consider which is most appropriate for the needs of a particular business.

There are three main methods for acquiring the information system necessary to support a particular business need. These are bespoke development, off-the-shelf software and end- user development. Figure 7.2 summarises these three alternatives.

Figure 7.1 Drivers for information systems acquisition

Business strategy and

policies

Information systems needs

Internal business

processes

External business

environment

Bespoke development is the term for when an information system is developed ‘from scratch’ by one or more information systems professionals to meet the business requirements of the application.

1. Bespoke development

Figure 7.2 An example of a typical evaluation of alternatives for BIS acquisition

Methods of BIS acquisition

User- developed O�-the-shelf

Tailored Standard

Bespoke development

In-house Outsourced

Bespoke development

An IS is developed ‘from scratch’ by an IS professional to suit the business requirements of the application.

M07_BOCI6455_05_SE_C07.indd 265 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT266

Here a new BIS will be developed from scratch by a team of information systems professionals. The IS professionals will either work for the business, in which case we refer to this as ‘in-house’ bespoke development, or for a third party such as a software house, in which case we say that the software development has been ‘outsourced’. Bespoke development has the benefit of producing software tailored to the precise requirements of the business. There is also the benefit that the creation of a bespoke information system may confer specific competitive advantage since competitor organisations do not have the same software solutions. On the downside, there are a number of difficulties:

■ Expense. Bespoke development is the most expensive way of developing new information systems.

■ Time. Bespoke development, especially when using formal structured development methodologies, is notorious for time overruns, with delays of months or years not uncommon.

■ Quality. Bespoke software is not usually free from bugs; software bugs can range from the trivial to the catastrophic, the latter often attributable to poor analysis of requirements.

2. Purchasing ‘off-the-shelf’ software

Off-the-shelf purchase of packaged software is an acquisition method that involves direct purchase of a pre-written application used by more than one company.

This type of software is pre-written and is available for a whole variety of hardware platforms from PCs to mainframes. Off-the-shelf software is written to offer a broad functionality that will suit a wide range of different businesses. This broad range of functions has the benefit of fitting the requirements of a large number of businesses. It also may offer too many features for any particular business, which may then feel that it is paying for things it will not use. At the same time, it may require businesses to process information in a particular way that is at odds with the way they normally do business. Alternatively, a certain off-the-shelf software package may not offer sufficient features. For example, a well-known accounting package in the UK only offered an eight-character code for the customer’s order number, though it would appear that some 50 per cent of UK companies use longer order number codes. The major benefit, however, of off-the- shelf software packages is their low cost when compared with acquiring bespoke software with the same level of functionality. In addition, because packaged software has been developed for a commercial market, it is less likely to suffer from the bugs that afflict bespoke software.

In a tailored off-the-shelf package, pre-written software is purchased from a supplier, but it is possible to configure it to be specific to the company by altering software code as required for the customer as well as enabling the customer to define (within the limits set by the package vendor) how the software will run using pre-written configuration parameters. A standard off-the-shelf package may be similarly configurable, whilst in a component off- the-shelf package, different modules may be purchased from different suppliers and built together. Visual Basic controls for graphing is a good example of a component that can be added to an off-the-shelf application.

Off-the-shelf purchase

An acquisition method that involves direct purchase of a pre- written application used by more than one company.

User-developed software

Software written by non-IS professionals, i.e. the business users.

User-developed software is software written by non-IS professionals, i.e. the business users. Senn (2004) estimated that 50 to 75 per cent of all computing applications will be classed

as end-user applications (as distinct from institutional applications) and that many of these systems will be developed by end-users (i.e. non-IT professionals).

3. User-developed software

M07_BOCI6455_05_SE_C07.indd 266 30/09/14 7:20 AM

267ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

Enterprise resource planning or institutional applications are those that affect general corporate activities, cut across more than one department or functional area, or systems that involve organisational data held in corporate databases. Examples include accounting systems, sales order processing systems and materials requirements planning.

End-user applications are more limited in scope. Applications may be departmental or personal in nature and are usually output- or report-oriented rather than input-driven. These applications may either be written by IT professionals or by the end-users themselves. If the latter is the case, they are often referred to as user-developed applications.

User-developed applications may be simple (e.g. a spreadsheet or a small PC database) or less commonly they may be more sophisticated (e.g. a production planning system based on sales forecast data from several branches of the same organisation). Such applications are typically for individual or departmental use, although in the case of the second example the system may have company-wide relevance. The main benefit of end-user-developed software is that it is normally used by those who develop it, and so the requirements are not subject to mistranslation or the provision of over-sophisticated solutions. The negative side to this is that in some cases inappropriate software development tools might be used (such as complicated spreadsheets instead of the construction of a database). A further significant concern with end-user development is that software may be riddled with bugs as a consequence of corner-cutting (poor or non-existent design, little or no testing, or no documentation). The end-user development approach is described in more detail later (in Chapter 16).

There are also a number of hybrid approaches to acquisition. A group of organisations in the same business or activity area may have information systems requirements that individually may be very expensive to develop. A solution may be for a bespoke system to be developed by a third party, which allows the development costs to be spread among all the organisations involved. Good examples here are a university student records system and various systems used in police forces across the UK.

Similarly, an off-the-shelf package may provide 80 per cent of the required features, but others may need to be added through some bespoke development by either IS/IT professionals or by end-users.

Enterprise application integration (EAI)

Software used to facilitate communications between business applications including data transfer and control.

The approaches to systems acquisition described above are not mutually exclusive to a given project or within an organisation. Where the software is generic to all businesses, as is the case with systems software and office productivity packages, off-the-shelf software will be purchased. Where the business has more specific needs and wishes to achieve a competitive advantage, bespoke and tailored approaches to acquisition will be used. With e-business systems there is often a need to integrate in-house legacy systems and systems purchased from different vendors. This uses a building block approach of different components including data sources that are integrated together. This is referred to as enterprise application integration (EAI), and achieving this is a significant challenge facing project managers and systems designers.

Hybrid approaches to systems acquisition

There are a number of factors that will influence the choice of acquisition method. Three critical ones are time, cost and quality considerations.

If an organisation has a pressing problem that requires a new information system quickly, it is probable that a package or tailored package will be sought. Similarly, an organisation that needs a ‘quality systems solution’ may well consider the packaged software route, especially if its requirements are straightforward.

Factors affecting software acquisition

M07_BOCI6455_05_SE_C07.indd 267 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT268

The different acquisition options have different strengths when considered in terms of the three critical criteria. Table 7.1 shows how the alternatives compare in terms of these three criteria. Quality of the delivered product is considered from two respects: the number of bugs or errors found and the suitability of the software in meeting the requirements of the business user. Note that good quality in terms of the number of bugs that typically occur for packaged software may coincide with poor quality in terms of the business fit.

The benefit of packaged software occurs because the cost of developing and debugging the software is shared between more than one company. This results in lower costs and fewer bugs than bespoke development for a single company. The use of packaged software by more than one company is also its greatest weakness, since its features must suit the typical company. As a consequence, it may not meet the needs of an individual company.

Other factors affecting software acquisition include the following:

■ Organisation size. A small or medium-sized business will inevitably have relatively limited resources for the purchasing of information systems and information technology (IS/IT). This suggests that there will be a tendency for such organisations to favour the purchase of off-the-shelf packages or possibly end-user applications development.

■ In-house IS/IT expertise. Where little in-house IS/IT expertise exists, either in the form of IS/IT professionals or experienced end-users, there will be a need to use third parties in the acquisition of new business information systems. These may include software vendors for off-the-shelf software packages, the use of consultants and/or software houses. Precisely what form of third party is used will depend on the other factors discussed here.

■ Complexity of the required information system. Where a business information system requirement is particularly complex, or for an unusual application not available as a packaged solution, it is possible that one may view bespoke software (either developed in-house or by a third party) as the only viable solution. However, complexity does not necessarily equate to ‘uniqueness’. For example, one could regard a materials requirements planning system or a complete accounting system as complex, but many packages exist for a variety of hardware platforms. Therefore, complexity is not necessarily an indicator that an off-the-shelf package should be ruled out.

■ Uniqueness of the business or business area to be supported. The higher the degree of uniqueness that exists in the area to be supported, the less likely it is that a suitable off-the-shelf package can be found. This is clearly an indicator, therefore, for bespoke development of some kind. As before, we must not confuse uniqueness with complexity. It may well be feasible for a non-IS/IT specialist to develop a solution using tools available to end-user developers. Of course, if the required system is complex and also carries a high degree of uniqueness, then bespoke development by IS/IT professionals is probably the best acquisition method.

■ IS/IT expertise among end-users. A certain degree of IS/IT literacy and expertise is necessary if end-users are to be able to develop information systems. In addition, such

Table 7.1 An evaluation of alternatives for BIS acquisition

acquisition option

Delivery time

Cost Quality: bugs

Quality: fits business needs

Bespoke in-house Poor Poor Poor Good

Bespoke software house Good Very poor Medium Medium End-user development Poor Medium Poor Good Tailored – off-the-shelf Good Good Good Medium

Standard – off-the-shelf Very good Very good Very good Poor

M07_BOCI6455_05_SE_C07.indd 268 30/09/14 7:20 AM

269ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

literacy is desirable when selecting suitable off-the-shelf packaged software, as it can help the business focus more clearly on its precise requirements from both a functional and a technological perspective. If an organisation has little end-user IS/IT expertise of its own, but has its own IS/IT department, it will be very much dependent on solutions provided by IS/IT professionals with or without third-party support.

■ Linkages with existing applications software. Where new business software needs to integrate very tightly with existing information systems, there is a higher probability that at least some bespoke development work will need to be done to integrate the two systems. Also, a high degree of integration may imply that the new information system has to be developed in a bespoke fashion in order to achieve the desired level of integration. Having said that, many software vendors supply packages for different business areas which integrate very well with each other.

By looking at combinations of the above, it is possible to come up with a ‘best-fit’ acquisition method. Figure 7.3 illustrates the relationship between the complexity of the required application (as driven by the business needs) and the uniqueness of the application under consideration. The reader should note that bespoke development may be performed either by in-house IS/IT specialists or by a third party.

Similar relationships can be established with other pairs of selection acquisition factors. For example, when comparing the expertise of end-users in developing applications with the complexity of the desired application, a relatively simple information system may need professional IT staff involvement if the end-users do not have sufficient IS/IT capability.

Figure 7.3 Application complexity versus uniqueness

O�-the-shelf package

O�-the-shelf package or

end-user-development

Bespoke development

Bespoke or end-user-development

High

Low

Complexity of application

Low HighUniqueness of desired application

SOFTWARE ACQUISITION AND THE SYSTEMS DEVELOPMENT LIFECYCLE

The systems development lifecycle (SDLC) model was developed and launched by the National Computing Centre in the UK in 1969. Until then, the emphasis in systems development was on programming. It was recognised, however, that many systems being developed at that time failed to meet user needs, because they were either functionally inadequate or too inflexible to meet changing business needs. The SDLC approach recognises that systems are developed in a series of steps or phases and that each phase needs to be completed before the next one commences. Recognition is also given to the fact that the programming activity (part of the build phase) should only commence once user requirements have been determined and the system design produced. Figure 7.4 illustrates the normal steps found in the systems development lifecycle.

Within the diagram it will be noted that in addition to the lifecycle phases, the concepts of project management and change management have been added. This reinforces the notion that information systems projects do not take place by chance, but that they must be managed carefully.

We will now summarise the basic steps that most systems development projects follow.

M07_BOCI6455_05_SE_C07.indd 269 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT270

Initiation phase

The startup phase in an IS development project. Its aims are to establish whether the project is feasible and then prepare to ensure the project is successful.

Initiation phase context

Input: creative thought and/or systematic evaluation of IS needs. Output: idea for initiation of a new information system.

Feasibility assessment

An activity at the start of a project to ensure that the project is a viable business proposition. The feasibility report analyses the need for and impact of the system and considers different alternatives for acquiring software.

Feasibility assessment context

Input: idea for initiation of a new information system. Output: feasibility report and recommendation to proceed.

The initiation phase is the initiation or startup phase and is the first phase in an information systems development project. Its aims are to establish whether the project is feasible and then prepare to ensure the project is successful. The initiation phase context is:

Input: creative thought and/or systematic evaluation of IS needs. Output: idea for initiation of a new information system.

The initiation phase contains the stimulus from which the need to develop a new BIS arises. This stimulus may come about as a result of some external event such as a change in legislation, or it may arise from a desire internally to develop an information system that better supports the business needs of the organisation. The source of this initiation process may be one of the following:

■ Managing director or other senior management. Systems initiated from this point are likely to have the support necessary for successful development.

■ Information systems department. A system may be initiated here as part of the organisation’s overall IS/IT strategy; to maximise the chances of success the system will still need high-level management support.

■ Functional business area. A system initiated here will be competing for attention with all other development projects then being undertaken; often an organisation will have a steering committee to decide on development priorities.

Initiation (Chapter 8)

Figure 7.4 The systems development lifecycle (SDLC)

Project and change

management

Initiation

Feasibility study

Requirement analysis

Kill

Maintain

Build

System designImplement

Feasibility assessment is the activity that occurs at the start of the project to ensure that the project is a viable business proposition. The feasibility report analyses the need for and impact of the system and considers different alternatives for acquiring software. The feasibility assessment context is:

Feasibility assessment (Chapter 8)

M07_BOCI6455_05_SE_C07.indd 270 30/09/14 7:20 AM

271ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

Input: idea for initiation of a new information system. Output: feasibility report and recommendation to proceed.

The feasibility assessment can be considered to be part of the initiation phase. It will establish whether a computer-based information system fits certain feasibility criteria. Three criteria are usually cited:

1. It must be established whether the information system is technically feasible. To be technically feasible, either the technology exists or it can be created to support the required system.

2. To be economically feasible, an information system must generate more in the way of benefits than the cost needed to produce it. One of the problems here is that benefits are often difficult to quantify in monetary terms, while costs are far easier to estimate.

3. Assuming that a proposed information system is both technically and economic-ally feasible, an assessment must be made of whether the project is operationally and organisationally feasible. By operationally feasible, we mean that the system must be capable of performing within the required speed, volume, usability and reliability parameters. Also, to be feasible for the organisation, the proposed information system must either be capable of running alongside work patterns or existing work patterns must be capable of being adapted or re-engineered to run alongside the new information system. Organisational feasibility will involve a review of how the potential users’ skill sets and attitudes will affect the system.

Part of the feasibility process may be the invitation to tender for some or all of the information system elements. These may include application software, hardware, communications technology or systems software. Different alternatives from different vendors will then be assessed.

The output from this step (and, therefore, the input to the next step of the model) is a stage review and a feasibility report, which will recommend either that the project proceeds or that the project is reassessed in some way.

Systems analysis

The capture of the business requirements of a system from talking to or observing end- users and using other information sources such as existing system documentation. Defines what the system will do.

Systems analysis context

Input: terms of reference in feasibility report describing outline requirements. Output: detailed requirements specification summarising system functions. Supported by diagrams showing the information flow and processes that are required.

Systems analysis is the capture of the business requirements of a system from talking to or observing end-users and using other information sources such as existing system documentation. The systems analysis context is:

Input: terms of reference in feasibility report describing outline requirements. Output: detailed requirements specification summarising system functions. Supported by diagrams showing the information flow and processes that are required.

Once a proposed information system is agreed to be feasible, it is necessary to carry out the detailed work of assessing the precise requirements that the intended users have for the new system. Note that the systems analysis step is sometimes referred to as the ‘requirements determination’ step or the ‘systems study’ step. There are three main tasks within this phase.

First, it is necessary to gain an understanding of how the current information system (computerised or paper-based) works. Second, a diagrammatic model of the current system workings is produced to ensure that IT professionals and system users are in agreement. Finally, a set of requirements for the new information system is produced. The requirements specification will define:

■ the features that the new system is required to contain (for example, the ability for end- users to be able to design their own reports);

■ the scope of the system under consideration (for example, is the system intended for just one functional area of the business or is it to embrace all business activities?);

■ the intended users of the new system;

Systems analysis (Chapter 10)

M07_BOCI6455_05_SE_C07.indd 271 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT272

■ system performance standards, including response times, batch processing times (if required) and reliability needs;

■ environment requirements such as physical working environment, operating system and hardware on which the system will run.

In this last task, it may be desirable to produce another diagrammatic model, this time of the required information system.

If at any point it is discovered that the requirements of the system as articulated by the prospective users appear to be unfeasible in some way, it will be necessary to revisit the feasibility step and perform an additional analysis of the possible options.

The output from this step in the model will be a user requirements analysis document which details what the proposed system must do.

Systems design

Defines how the system will work in key areas of user interface, program modules, security and database structure and transactions.

Systems design context

Input: requirements specification. Output: detailed design specification.

System build

Describes the creation of software by programmers. It involves writing the software code (programming), building release versions of the software, constructing and populating the database and testing by programmers and end-users. Writing of documentation and training may also occur at this stage.

System build context

Input: requirements and design specification. Output: working software, user guides and system documentation.

The systems design phase defines how the system will work in key areas of user interface, program modules, security and database transactions. The systems design context is:

Input: requirements specification. Output: detailed design specification.

The input to this stage is a breakdown of the requirements that the proposed information system is to deliver. The task of the systems design stage is to convert those requirements into a number of design alternatives from which the best will be selected. The design step therefore deals with how the proposed information system will deliver what is required.

Some texts and methodologies make a distinction between ‘systems design’ and ‘detailed design’. Systems design is broader in scope and will deal with such matters as:

■ choosing an appropriate database management system; ■ establishing general systems security standards; ■ deciding on methods of system navigation (e.g. menu systems and graphical user

interfaces); ■ general standards for printed report production; ■ screen design standards for input and output; ■ data capture requirements; ■ data storage requirements.

Detailed design, on the other hand, will result in a blueprint for individual system modules which will be used in the system build phase that follows. Detailed design will further define some of the aspects of system design referred to above.

If at any point during the design step it becomes obvious that the requirements as presented in the analysis step do not have a design solution (e.g. because of conflicting or incomplete requirements), it will be necessary to revisit the analysis step and determine more precisely what the new information system is to do in those particular respects.

Systems design (Chapter 11)

System build is the creation of software by programmers. It involves writing the software code (programming), building release versions of the software, constructing and populating the database and testing by programmers and end-users. Writing of documentation and training may also occur at this stage. The system build context is:

Input: requirements and design specification. Output: working software, user guides and system documentation.

System build (Chapter 12)

M07_BOCI6455_05_SE_C07.indd 272 30/09/14 7:20 AM

273ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

The term ‘build’ is one that we shall be using in addition to the more usual and ambiguous term ‘implementation’ which is found in many texts and methodologies. This step embraces three substeps: physical database construction, programming and testing.

Physical database construction involves the conversion of the database design from the previous step into the required tables and indexes of a relational database. The programming substep involves the construction of computer code that will handle data capture, storage, processing and output. In addition, it will be necessary to program various other operational attributes of the required system (e.g. those that stem from control design). Alongside and subsequent to the programming substep, various forms of testing will take place.

The output from the build stage will be an information system that has been tested and is available for final data conversion or take-on and live operation.

If during the build phase it appears from testing that the system does not meet the original requirements as determined during the analysis step, then it will be necessary to revisit the design step to see whether any errors were made in interpreting the systems requirements. If the design brief was correctly interpreted but the system still contains errors in the delivery of the perceived requirements, it will be necessary to revisit the analysis to determine the systems requirements more precisely.

System implementation

Involves the transition or changeover from the old system to the new and the preparation for this such as making sure the hardware and network infrastructure for a new system are in place; testing of the system; and also human issues of how best to educate and train staff who will be using or affected by the new system.

System implementation context

Input: working system, not tested by users. Output: signed-off, operational information system installed in all locations.

System implementation covers practical issues such as making sure the hardware and network infrastructure for a new system are in place; testing of the system; and also human issues of how best to educate and train staff who will be using or affected by the new system. Implementation also involves the transition or change-over from the old system to the new. The system implementation context is:

Input: working system, not tested by users. Output: signed-off, operational information system installed in all locations.

This step in the waterfall model deals with preparing for and making the change from old to new information systems. As one might expect, the systems implementation step is fraught with difficulties. Here, it will be discovered whether all the previous steps have combined to deliver an information system that does what the users actually want and that also works properly. Data will be converted from old information systems or directly entered into the new database. Finally, the new system will become operational straightaway, or in phases, or after a period of parallel running. If errors are encountered at the live running stage it may be possible for the system to continue in operation while the errors are corrected. Alternatively, it may be necessary to suspend the operation of the new system while the most significant errors are fixed. Such error correction may require any of the previous steps to be revisited, depending on the nature and severity of the error(s).

It will be clear from this short discussion that the later in the systems development process errors are discovered, the higher is the cost of putting them right. The worst-case scenario is probably for a system to have reached the live running stage only for it to be discovered that the required system was never really feasible in the first place.

System implementation and changeover (Chapter 12)

Once an information system is operating under live running conditions, it will be inevitable that changes will be required over time. The maintenance phase involves two different types of maintenance. The first, known as ‘unproductive maintenance’, stems from errors or oversights in the original systems development which, while not preventing the system operating to an acceptable level, are still necessary to correct for it to conform with the original specification. The second form of maintenance involves the addition of new

Review and maintenance (Chapter 12)

M07_BOCI6455_05_SE_C07.indd 273 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT274

features and facilities that extend the scope and functionality of the information system. In the early days, these may take the form of ‘nice-to-haves’ or ‘bells and whistles’ which were not deemed to be essential to the system at changeover time. Over the longer term, the system will be adapted and modified to meet changing business requirements. An activity known as the post-implementation review should also be undertaken. This should take place about six months after the system changeover and should review what was planned for the information system against what actually happened. Lessons learned from this exercise will be extremely valuable when the next system is developed.

Post-implementation review

A meeting that occurs after a system is operational to review the success of the project and learn lessons for the future.

The evidence from project failures has implied that traditional structured methodologies such as the SDLC have a tendency to deliver systems that arrive too late and therefore no longer meet their original requirements. Traditional methods can fail in a number of ways:

■ A gap of understanding between users and developers. Users tend to know less about what is possible and practical from a technology perspective, while developers may be less aware of the underlying business decision-making issues which lie behind the systems development requirement.

■ Tendency of developers to isolate themselves from users. Historically, systems developers have been able to hide behind a wall of jargon, thus rendering the user community at an immediate disadvantage when discussing IS/IT issues. While some jargon may be necessary if points are to be made succinctly, it is often used to obscure poor progress with a particular development project. The tendency for isolation is enhanced by physical separation of some computer staff in their own air-conditioned computer rooms. Developers might argue in their defence that users also have their own domain- specific jargon which adds to the problem of deciphering requirements.

■ Quality measured by closeness of product to specification. This is a fundamental difficulty – the observation that ‘the system does exactly what the specification said it would do’ hides the fact that the system may still not deliver the information that the users need for decision-making purposes. The real focus should be on a comparison of the deliverables with the requirements, rather than of deliverables with a specification that was a reflection of a perceived need at a particular point in time.

■ Long development times. A glance back at the previous section on the SDLC will reveal that the processes of analysis and design can be very laborious and time-consuming. Development times are not helped by the fact that an organisation may be facing rapidly changing business conditions and requirements may similarly be changing. There is a real risk of the ‘moving goal-posts’ syndrome causing havoc with a traditional approach to systems development.

■ Business needs change during the development process. This is alluded to above. A method is needed where successive iterations in the development process are possible so that the latest requirements can be incorporated.

■ What users get isn’t necessarily what they want. The first a user may see of a new information system is at the testing or training stage. At this point, it will be seen whether the system as delivered by the IS/IT professionals is what the user actually needs. An appropriate analogy here is the purchase of a house or car simply on the basis of discussions with an estate agent or a garage, rather than by actually visiting the house or driving the car. It is unlikely that something purchased in this way will result in a satisfied customer and there is no reason to suppose that information systems developed in a similar way will be any more successful.

BESPOKE DEVELOPMENT

M07_BOCI6455_05_SE_C07.indd 274 30/09/14 7:20 AM

275ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

Not only is there pressure from end-user management for faster systems development, IS/ IT departments themselves increasingly recognise the need to make more effective use of limited human resources within their departments while at the same time quickly delivering systems that confer business benefits. All this is in a climate of rapid business change and, therefore, rapidly changing information needs. Rapid applications development (RAD) is a possible solution to these problems and pressures. This uses prototyping to involve users and increase development speed.

Rapid applications development (RAD) is a method of developing information systems which uses prototyping to achieve user involvement and faster development.

Prototyping produces a preliminary version of part or a framework of all of an information system which can be reviewed by end-users. Prototyping is an iterative process where users suggest modifications before further prototypes and the final information system are built.

Case Study 7.1 illustrates the benefits that can be derived from an RAD approach. It also hints at some disadvantages, such as the lack of a methodology to support RAD which can lead to a casual approach to a project. A later section on the Dynamic Systems Development Methodology shows how this deficiency is being made good.

Rapid applications development (RAD)

A method of developing information systems which uses prototyping to achieve user involvement and faster development.

Prototyping

A prototype is a preliminary version of part of a framework of all of an information system which can be reviewed by end- users. Prototyping is an iterative process where users suggest modifications before further prototypes and the final information system is built.

When marketing people spot a business opportunity, it is often IT people who have to think and act the fastest.

Systems have to be put in place that meet the stipulated deadline, that work first time, and that fulfil the expectations of users. Otherwise the opportunity could be lost forever.

That was the situation facing the computer team at Lloyds Bank Insurance Services when a new product called MUDI (Mortgage Unemployment Disability Insurance) required a telesales quotation system that had to be fully operational by October 2nd.

Yet it was already mid-August when David Jacklin, IT Development Manager, LBIS, was informed of the need for a new application. It was a moment he remembers well. ‘I faced the classic dilemma of no available resource within my team and an immovable deadline’, he recalls.

However, in spite of that initial reaction and against some unexpected odds, the race against time was won. The insurance broker’s objective was achieved with the help of a hard-working software house, a development environment toolset, and a fast- track approach called RAD (Rapid Application Development). In fact, the entire development took just five weeks.

Reason for the urgency at the LBIS headquarters in Haywards Heath, West Sussex was a government decision to amend the rules relating to the payment of mortgage cover out of social security in the event of a house-owner being made redundant. This opened a new insurance window which the company was determined to exploit.

LBIS, a subsidiary of Lloyds Bank and Abbey Life, is a firm of independent brokers dealing in life assurance, pensions and general insurance. Annual turnover is £100  million and 800 people are employed at Haywards Heath and six

regional offices. A significant proportion of the company’s business is generated through a business unit called Lloyds Bank Insurance Direct.

This is essentially a telemarketing organisation based in Bournemouth. About 70 per cent of its business comes via branches of Lloyds Bank, where advisors take an enquirer’s details and ring LBID for a quote. The remaining 30 per cent is from people responding to direct mail of advertisements and telephoning in direct.

A simple version of MUDI was, in fact, available at the bank branches. But there were no facilities for accurate underwriting and anyone taking up the policy paid a straight £6.50 per £100 of cover (i.e. if the monthly mortgage payment was £300, the premium was £19.50). The new system would incorporate a complex screen replacing the existing simple paper form, providing the flexibility to quote premiums appropriate to the enquirer ranging from £4.40 to £9.40 per £100 of cover.

But first the new system had to be built. There already existed another application at Bournemouth – BIQS (Building Insurance Quotations Service) – but this ran under DOS, so what would almost certainly be a Windows system could not merely be tagged on.

Jacklin and his team had been looking at development toolsets and the RAD concept earlier in the summer. They had been particularly attracted by a RAD specialist, MDA Computing, and had already met the Croydon-based software house at the end of July.

Suddenly, with the new business-critical requirement looming, the need for RAD became urgent. ‘We had no hesitation going back to MDA. They obviously knew what they were talking about and we were in urgent need of a system’, says Jacklin.

Lloyds Bank Insurance Services applies RAD

CASE STUDY 7.1

➨

M07_BOCI6455_05_SE_C07.indd 275 30/09/14 7:20 AM

Some of the main attractions of RAD included the delivery of a workable first version within a very short time-scale, testing that is integrated within the development cycle, flexibility of the specification, and user involvement throughout the whole process.

Within days, Jacklin and his colleagues had agreed with MDA the RAD methods to be used. The software house underlined the need for an appropriate development environment, and recommended Enterprise Developer. This versatile toolset from Symantec had all the advanced features of a second generation client/server development system, and this was precisely what the LBIS team sought.

Such systems are repository-based and scaleable, and – specially important according to Jacklin – are driven by business rules so that future changes are easily made as business needs change. MDA evaluates every tool that comes on to the client/server market and felt that Enter-prise Developer offered the best set of second generation facilities.

Next step was a demonstration of the Symantec toolset at MDA, ‘The demo convinced us. We had looked at other development tools but they did not seem meaty enough for our needs. And although MDA had never built anything with Enterprise Developer they were clearly keen to do so.’ Following that demo and an agreement of project scope, work began on August 24th.

The key requirement was for a front-end system that would enable telesales staff at 30 screens to capture a caller’s details and generate an immediate MUDI quotation. The system would be in Windows 3.1 and GUI based, essentially a classic PC LAN application. It would run a Compaq server using Novell.

However, MDA’s first task was systems analysis. At the early stage, LBIS had not formulated all their needs – not even the design of the ‘forms’ that would appear on the screen. So MDA used RAD techniques to work out what the requirements would be, and spent three days at LBID in Bournemouth prototyping the forms on screen using Enterprise Developer. The software house also had to allay fears, among a user-team with little experience of Windows, about mouse-driven systems.

In order to get the project started, the use of a Watcom database was assumed. However, following discussions within LBIS, it was decided that for strategic and operational support reasons the use of Oracle was preferred.

MDA had to accommodate a new database in already tight development cycle. The ability to adapt to the fresh circumstances and still deliver the system on time was a big tribute to the software house’s RAD methods and the Symantec toolset. (In fact, there were minor compatibility

problems which disappeared when LBIS upgraded to Enterprise Developer 2.5 at the beginning of November.)

The system was delivered in the last week of September for final testing in readiness to go live the following Monday. By then, LBIS’s own technical team had adjusted the BIQS system so that the telesales people could flip to it from MUDI, depending on the caller’s needs, with a simple keyboard Alt/Tab depression.

On ‘live’ day, the telesales team processed 200 customer quotations with scarcely a hitch. Jacklin, MDA and Symantec had every right to feel pleased with themselves. A business need had demanded IT support, and that support was implemented on time.

Now the end-users, equipped with telephone headsets, enter personal details which affect ratings, such as sex, post code and occupation, on to a GUI screen. The quotation then appears on the same screen. There are five other, supporting screens labelled status, comments, letter print, rating and search for existing customer.

A happy Jacklin concludes, ‘Here was a software house that gave us what we needed. They were always confident they could do something with Enterprise Developer and within time. There was no slippage despite it being their first real use of the Symantec product and despite the change in database midway through. I think that says something for Enterprise Developer too. And we went live on the big day.

‘We like RAD and we shall use it again. In a market- oriented organisation like LBIS, we always have a need to react to business changes quickly, and I suspect that within 18 months we could need a system to handle all six of our insurance products.’

He adds, ‘The system has allowed LBIS to launch a more competitive product than would otherwise have been possible, and we have sold more than we would have done. It had to be in at the right time or we would have missed the boat. From a technical point of view, it forced us to go to Windows which was always our eventual intention. All this, and the system will pay for itself before Christmas!’

Source: www.dsdm.org

Since modern systems development using prototyping is an iterative approach, the sequential model defined in Figure 7.4 is a simplification of the actual process. Figure 7.5 gives a more realistic representation of systems development. It is apparent that all the phases within the SDLC are still present, but that the activities of analysis, design, test and review repeat within the prototyping phase.

QUESTIONS

1. Why and how did the company choose the RAD approach used for this project?

2. What disadvantages of the RAD method can you identify from the study?

3. Do you think that Lloyds can be confident that future RAD projects will be successful?

276 Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT

M07_BOCI6455_05_SE_C07.indd 276 30/09/14 7:20 AM

Spiral model

An iterative systems development in which the stages of analysis, design, code and review repeat as new features.

Figure 7.5 The role of prototyping within the systems development lifecycle

Initiation Feasibility Analysis Initiation

Design

Prototyping

Test and review

Develop Implement Maintain

ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS 277

The spiral model is an iterative systems development model developed by Boehm (1988) which incorporates risk assessment.

The spiral model was developed in recognition of the fact that systems development projects tend to repeat the stages of analysis, design and code as part of the prototyping process. Each spiral consists of four main activities, as shown in Figure 7.6. The activities are:

1. Planning – setting project objectives, defining alternatives. 2. Risk analysis – analysis of alternatives and the identification and solution of risks. 3. Engineering – equivalent to the build phase of the SDLC with coding and testing. 4. Customer evaluation – testing of the product by customers.

It can be seen from Figure 7.6 that the model is closely related to RAD, since it implies iterative development with a review possible after each iteration or spiral, which corresponds to the production of one prototype or incremental version.

Before the first spiral starts the requirements plan is produced, so it can be seen that the spiral model does not detail the initiation and analysis phase of the SDLC, focusing on design and build.

Although the spiral model has not been applied widely in industry, proponents of this model argue that it includes the best features of both the classic SDLC and the prototyping approach. It also adds validation of requirements and design, together with risk analysis, which is often overlooked in RAD projects.

The spiral model

Whilst the spiral model may not have been widely adopted un industry and commerce, two of the more recent developments appear to be making some inroads into the commercial domain. Mary and Tom Poppendieck (2003) originally set out seven principles behind lean software development and provided 22 toolkits or best practice guides to underpin them. These principles have been refined and can now be summarised as follows:

■ Eliminate waste – this can be achieved by concentrating on the 20 per cent of the software features that deliver 80 per cent of the system’s value, reducing requirements

Agile and lean software development Lean software development

Lean software development is an approach to software development where software is developed and deployed in small and useful feature sets which work incrementally.

M07_BOCI6455_05_SE_C07.indd 277 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT278

churning (moving goalposts) by delaying detailed software specifications and ensuring that development processes allow organisational boundaries to be crossed easily by eliminating buffers between functional business areas.

■ Create knowledge – teams should adopt a scientific approach to selecting alternatives by establishing hypotheses, testing them and creating concise documentation; everyone should follow current best-known practice in standards while being actively encouraged to challenge and improve the standards; performance should become predictable through the development of an organisation’s capacity to respond to the future as it unfolds.

■ Build quality in – here, testing forms a key aspect of the approach by adopting a test- driven approach to software development where automated unit and user acceptance tests are built in.

■ Defer commitment – the key elements of this principle include the abolition of the idea that a complete system specification is a good way to start a systems development project; in addition, the system architecture should be able to support the addition of any feature at any time, options should be left open for as long as possible and irreversible decisions should be delayed to the ‘last responsible’ moment so that as much can be learned as possible before commitment.

■ Deliver fast – the objective here is to eliminate the buffers that slow things down by aggressively limiting the size of lists, queues and ‘things in process’ so that the organisation can limit the work it is undertaking to its capacity to deliver; it is claimed that rapid delivery, high quality and low cost are fully compatible and that companies can enjoy cost advantages and be more attuned to their customers’ needs when they compete on the basis of speed.

Figure 7.6 Boehm’s spiral model of systems development

REVIEW

Requirements plan Lifecycle plan

Development plan

Integration and test plan

Service Plan next phase

Determine objectives, alternatives, constraints

Proto- type 2

Risk analysis

Risk analysis

Risk analysis

Proto- type 3

Final proto- type

Evaluate alternatives; identify, resolve risks

Develop, verify next-level product

ModelsOperation concepts

Requirement validation

Acceptance test

Integration test

Unit test

Code

Detailed design

Product design

Design validation and verification

Simulations Benchmarks

M07_BOCI6455_05_SE_C07.indd 278 30/09/14 7:20 AM

279ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

■ Respect people – this principle enshrines the view that the most sustainable competitive advantage comes from having thinking and engaged people mutually committed to achieving a common goal.

■ Improve the system – here, measurement forms an important element including the measurement of process capability with cycle times and the measurement of team performance with delivered business value; in addition there should be a focus on the entire value stream from customer request to deployed software and the complete product should be delivered, not just the software.

In summary, the lean approach to software development emphasises what is essentially an incremental approach to software development where software is developed and deployed in small and useful feature sets which work incrementally. This ‘feedback-driven’ approach to software development is in contrast to the traditional waterfall model where software development proceeds in a series of discrete steps, each of which should be completed before the next one can proceed and where project plan is based on a series of forecasts about what is likely to happen at each stage of the development project.

If lean software development relates primarily to an overarching philosophy behind software development, then agile software development tends to relate more to the software engineering aspects of systems development. The term ‘agile methods’ has been around since 2001 and today encompasses a number of agile software development methods including:

■ Adaptive Software Development (ASD); ■ Agile Unified Process (AUP); ■ Scrum; ■ Dynamic Systems Development Methodology (DSDM).

DSDM is dealt with in more detail below. Of the other methods mentioned, it is worth discussing AUP in a little more detail. AUP is a simplified version of the Rational Unified Process (RUP). As with RUP, there are four phases in the development cycle:

1. Inception – this is where the initial scope of the project is identified including a potential architecture for the system, and the obtaining of initial project funding and stakeholder acceptance. A business case must be established along with an initial risk assessment and project description.

2. Elaboration – a model describing the business problems to be solved is developed alongside ‘use case’ descriptions (sequences of events that, taken together, lead to a system doing something useful).

3. Construction – the key task here is in building working software on a regular, incremental basis which meets the highest-priority needs of project stakeholders; the bulk of the coding takes place in this phase and in larger projects, several construction iterations may be developed in an effort to divide the project components as defined by the ‘use cases’ manageable segments that produce demonstrable prototypes.

4. Transition – finally, the software products move from the software development area to the end-user where activities such as training of the end-users and maintainers and beta  testing (see Chapter 12) of the system to validate it against the end-users’ expectations take place; the product is also checked against the quality criteria as set in the inception phase.

In summary, lean software development and agile methods are complementary and together they provide an alternative to the traditional waterfall model. Whilst it would be unwise to say that one approach is better than the other, it is fair to say that as organisations increasingly seek to compete using the speed with which they are able to respond to their customers, then the pressure to develop and implement software solutions rapidly in order to maintain competitive advantage may tip the balance towards more widespread adoption of these newer development methods.

M07_BOCI6455_05_SE_C07.indd 279 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT280

Dynamic Systems Development Methodology (DSDM)

A methodology that describes how RAD can be approached. The latest version is named DSDM Atern.

Mellon Financial’s shift to agile software development is part of an emerging trend. ‘Every investment bank and hedge fund I’ve spoken to is looking at agile’, says Sungard’s Chapman. A relatively new term, agile development is based on iterative development – developing software in small, manageable chunks that can be modified as requirements change, yet using a disciplined software delivery mechanism.

Historically, the software development approach used throughout Wall Street has been the ‘waterfall’ method, which calls for strict, lengthy analysis and documentation of requirements. For a one-year project, for example, three to six months might be spent on needs analysis. ‘The business people are expected to define 100 percent of their requirements up front before the project even starts’, Chapman says. ‘People get stuck in this analysis paralysis– they spend months and months trying to define what they want.’

Another three to six months can be devoted to soft-ware design, then the actual program finally is written. ‘Inevitably what happens is requirements change, integration becomes very difficult and all the risky software development happens at the end of the development effort’, Chapman explains. ‘The waterfall approach has a horrible track record of delivery.’

Agile software development is designed to deliver software more quickly yet maintain high quality. In agile methods, every two or four weeks, businesspeople get a small amount of code to review and the opportunity to change the requirements. ‘Imagine a hedge fund where traditionally a new credit derivatives trading system would take a year to build using the waterfall approach, with businesspeople writing six months’ worth of documentation versus using an agile approach, where some of the system is delivered in two weeks, and it’s OK if you change your mind’, Chapman says. ‘For the hedge funds particularly, agile is an extraordinarily good fit because the portfolio managers want to get things done quickly.’

But not every project lends itself to short iterations, Chapman concedes. ‘On Wall Street it’s not so easy because there are a lot of other systems you need to integrate with’, he says. ‘But I think there are parts of agile you can use on every project to improve it.’

Agile development has three levels: developer, project and enterprise. ‘Nobody on Wall Street is using agile at the enterprise level’, Chapman says. ‘A lot of education needs to take place within the banks – it’s going to take some time. But I think every project could gain some benefit from trying to break down the project into more-manageable chunks that can be delivered in a more iterative and agile way.’

Agile methods even improve software quality, Chapman contends, because they emphasize testing. Agile methods encourage developers to do their own testing, often requiring them to write the tests before they write any code and to develop automated testing routines for the programs they deliver.

‘Agile development approaches and CMMI are compliant with each other – you can use CMM and CMMI to make agile software development better’, Chapman adds. On the other hand, he asserts, trying to use CMM and CMMI on top of waterfall development approaches will just weigh projects down with bureaucracy and paperwork.

Source: www.wallstreetandtech.com/advancedtrading/ showArticle.jhtml?articleID=199601961&cid=RSSfeed_TechWeb accessed via www.computing.co.uk

Use of waterfall v. agile methods at Mellon Financial

CASE STUDY 7.2

QUESTIONS

1. What does the observation that ‘requirements change, integration becomes very difficult and all the risky software development happens at the end of the development effort’ suggest about the traditional waterfall approach to software development with respect to system design?

2. Do you think there are any dangers in trying to take short cuts around the traditional approach to systems design?

The ideas behind RAD have been around for several years, but a methodology that encapsulates its principles has only recently emerged. In the UK, an organisation known as the DSDM Consortium has put together a set of underlying principles. These are given in full below, together with a commentary provided by the consortium. In total, DSDM (Dynamic Systems Development Methodology) has nine key principles, as shown in the following box.

Dynamic Systems Development Methodology (DSDM)

M07_BOCI6455_05_SE_C07.indd 280 30/09/14 7:20 AM

The nine principles of the Dynamic Systems Development Methodology (DSDM) 1. Active user involvement is imperative. DSDM is a user-centred approach. If users are not closely involved

throughout the development life-cycle, delays will occur as decisions are made. Users no longer sit outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process.

2. DSDM teams must be empowered to make decisions. DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher level management.

3. The focus is on frequent delivery of products. A product-based approach is more flexible than an activity- based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products.

4. Fitness for business purpose is the essential criterion for acceptance of deliverables. The focus of DSDM is on delivering the business functionality at the required time. The system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, while losing sight of the fact that the requirements are often inaccurate and the previous deliverables are flawed.

5. Iterative and incremental development is necessary to converge on an accurate business solution. DSDM allows systems to evolve incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognises this and, by making it explicit, strengthens the use of iteration. When rework is not explicitly recognised in a development life-cycle, the return to previously ‘completed’ work is surrounded by controlling procedures which slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration.

6. All changes during development are reversible. Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made.

7. Requirements are baselined at a high level. Baselining high-level requirements means ‘freezing’ and agreeing the purpose and scope of the system at a level which allows for detailed investigation of what the requirements imply. Further baselines can be established later in the development.

8. Testing is integrated throughout the lifecycle. Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users to ensure that the development is moving forward; not only in the right business direction, but that it is technically sound. Early in DSDM, the testing focus is on understanding the business needs and priorities. Towards the end of a project, the focus is on assuring users and developers that the whole system operates effectively.

9. A collaborative and co-operative approach between all stakeholders is essential. The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the pre-contract phase and when the contracted work is carried out.

Source: www.dsdm.org

281ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

M07_BOCI6455_05_SE_C07.indd 281 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT282

Avison and Fitzgerald (2006) outline an approach to rapid applications development which embraces many of the principles outlined above. For them, the RAD approach:

■ is based on evolutionary prototyping rather than the traditional lifecycle approach; ■ identifies key users and involves them in workshops at the early stages of development; ■ obtains commitment from the business users; ■ requires the use of CASE (computer-aided software engineering) tools for system

building.

Typical RAD activities include:

■ joint requirements planning (JRP) to determine high-level management requirements; ■ joint applications design (JAD) using prototyping tools to explore processes, interfaces,

screens, reports, dialogues etc., which are then developed and modelled using entity modelling, dataflow diagrams, action diagrams and function decomposition diagrams;

■ transformation of user designs to detailed design and code generation, often with the assistance of CASE tools;

■ a cutover phase involving more testing, functional-level training, training for organisational change and adaptation, conversion, parallel running and, finally, live running.

The result of the rapid applications development approach should be new information systems that more closely meet the requirements of the intended users, not least because the requirements will not have changed significantly over a relatively short development timescale.

The following general points can be made regarding bespoke development:

■ Bespoke development is much more expensive than alternative software acquisition methods – the software that is produced is unique and must be tailored to the precise needs of the users.

■ The time taken to develop a new, bespoke computer-based information system is significantly longer than the period needed to purchase an off-the-shelf software package. That said ‘rapid applications development’ claims to reduce substantially the time taken to develop bespoke software.

■ There will be situations where bespoke development provides the only realistic way of producing the required software – high degrees of organisational or application uniqueness or the need to integrate a new information system very tightly with existing applications are common reasons for this.

PURCHASE OF AN OFF-THE-SHELF PACKAGE

The traditional waterfall or SDLC model as described above was discussed in the context of a system that is being acquired using a bespoke development approach. However, as we have seen, there are methods of information system acquisition that do not require the development of bespoke solutions. For packaged software, that application of the SDLC stages would typically be as follows.

■ Initiation. This step clearly applies regardless of the acquisition method: there must be some kind of stimulus which creates the notion that a computer-based information system is needed to respond to a business opportunity or problem.

■ Feasibility. Again, this step must be followed. Indeed, it is during the feasibility step that an investigation will be undertaken into the technical aspects of the required system and a make-or-buy decision will be made. A ‘buy’ decision indicates that a solution is probably available off the shelf; a ‘make’ decision indicates that a bespoke solution is probably required because of a combination of factors, as discussed above.

M07_BOCI6455_05_SE_C07.indd 282 30/09/14 7:20 AM

283ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

■ Analysis. This is as important a step in the acquisition of off-the-shelf software as it is in building bespoke software solutions. System requirements must be determined and catalogued so that they can be compared with the features offered by the package. Many packages can be configured in different ways to meet the different needs of customers. With complicated systems or those that offer a wide range of functionality, the configuration process can be a demanding one and may require actions by end-users, the organisation’s IS department, the package vendor or any combination of these. Part of the analysis exercise, therefore, will be to determine the extent to which a software package may be configured to meet the organisation’s needs.

■ Design. It is here that significant differences are found when compared with bespoke software design. An off-the-shelf package will have been designed with many different businesses in mind and will offer a range of features to satisfy most requirements. The ‘how’ aspect of software acquisition has, therefore, already been determined and the system subsequently built. The task for the purchaser of an off-the-shelf package is to compare the design features required (e.g. menu systems, database design or user interface design, ease and scope of configuration) against those offered by different packages.

■ Build. With an off-the-shelf package, the system has already been built by the vendor. As part of the feature set offered by a package, there may be an ability to customise aspects of the software product by setting certain parameters. For example, an accounting package may be set up either to interface with a sales order processing system from the same vendor, or to offer the ability to interface with a package offered by another supplier or with a bespoke system. There will also need to be a testing phase where all the relevant features of the package are run in a simulated live environment. This might, for example, be done in parallel with existing information processing activities.

■ Implementation/changeover. As with a bespoke software solution, data will have to be converted or entered from old computer- or paper-based information system. One of the benefits of purchasing off-the-shelf software is that the product should be free from major bugs and errors. The purchaser should be confident, therefore, that the software product will work as specified from the outset.

■ Maintenance and review. Maintenance and enhancements of the software will differ from those in a bespoke solution. Whereas bespoke software can be enhanced over time by the developer (either in-house or by a third party), an off-the-shelf package will differ in a number of ways. Enhancements to the package will normally be made available by the vendor as a new release. Sometimes it is possible for a business organisation to build its own enhancements or ‘add-ons’ to the package. There is a danger that such bespoke amendments to standard packages may be lost if the organisation buys a new release of the software. In addition, maintenance is usually covered by a separate maintenance agreement after the original guarantee period. There may be differential pricing depending on whether the maintenance agreement is to cover simply ‘bug fixing’ or whether it is to entitle the user to the latest version of the software at no or little additional cost. As with the bespoke solution, a post-implementation review should be undertaken.

There is no doubt that by following a structured sequence of steps when acquiring a software package the probability of a successful implementation will be increased. However, package selection and purchase is also governed by an additional set of software selection criteria. Sahay and Gupta (2003) have produced a comprehensive analysis of both primary and secondary drivers as they apply to software selection. Although they were

Software selection criteria for packaged software

M07_BOCI6455_05_SE_C07.indd 283 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT284

researching with particular reference to business supply chain solutions, their findings can be applied just as well in a generic way. Primary drivers are those that form a set of essential requirements, which, if not met, mean that the software solution will not be suitable for the organisation. These primary drivers, in descending order of importance are:

■ Features. This refers to the software features and functionality of the package under consideration. Aspects such as availability and functionality of modules, ability to integrate with existing applications, speed of operation when up and running, implementation time, portability of the package to other hardware platforms and operating system environments.

■ Technology. Here, the software acquisition team needs to consider the compatibility of the solution under consideration with existing hardware, operating systems, database management systems, Internet, networking and e-commerce setups. Sahay and Gupta also consider that a high level of technology support for business integration is essential.

■ Support and services. Of particular importance with packaged software is support for day-to-day operational requirements. This means that problems with any software module or group of modules must be dealt with by the software vendor through their technical maintenance function. Aspects such as pre-sales support (for example to assist with hardware and networking configuration before purchase and implementation), automated support (remote identification, diagnosis and fixing of software problems), software documentation, user guides and manuals and training are also important components of this driver. Version support is also an important consideration, since older versions of software will cease to be supported after a certain period of time.

■ Cost. Software vendors have different approaches to the pricing of their products. The organisation that is purchasing the software package will typically want to meet their qualitative and quantitative requirements as quickly as possible and at the lowest possible cost. Therefore, software vendors tend to offer the basic package and a low cost, but charge much higher sums for additional hardware, software modules or special equipment. The charging mechanisms also vary from vendor to vendor. Some will charge per module, others per user, and many a combination of the two. In addition, the purchaser will be expected to pay an annual maintenance fee (typically 20% of the purchase price), planning, implementation and installation costs, plus any upgrade costs when new versions of the software are released.

■ Customisation. Each organisation that purchases a software package will have slightly different requirements. Some of these can be taken care of through con-figuration options within the standard software package. Other, more specialised, needs may possibly only be met through the provision of customised versions of the software. Some software vendors will offer customised versions, while others will not. Customisation can make a software package a better fit with business needs, but the costs can be high. In particular, it must be remembered that any customisation will have to re-applied in subsequent software releases, at extra cost.

The secondary drivers identified by Sahay and Gupta (2003) are those requirements that are less important and non-essential in nature, but which add value to the customer. These drivers will differ in importance from purchaser to purchaser, and some may be as important as the primary drivers for some purchasers.

■ Vendor strength. When purchasing a software package from a vendor, it is important to know how strong the vendor is in terms of their financial position, number and quality of their personnel, the vendor’s understanding of the business and market in which the purchaser operates and the vendor’s experience in this area. Lack of vendor support when problems arise and insufficient product development can leave the purchaser at a considerable operational and competitive disadvantage.

M07_BOCI6455_05_SE_C07.indd 284 30/09/14 7:20 AM

285ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

USER-DEVELOPED APPLICATIONS

User-developed applications (software) ‘should’ be developed in line with the steps normally covered during the bespoke development process. The main difference is that end-user-developed applications are usually on a much smaller scale than those developed for corporate use. However, many of the tools and techniques associated with large-scale corporate bespoke development still have a role, albeit a more limited one, in end-user- developed information systems. As before, each step in the waterfall model will be discussed separately. The advantages and disadvantages of end-user development are described in detail later (in Chapter 16).

■ Initiation. The stimulus for end-user information system development will typically come from a personal or departmental requirement which can be satisfied by employing easy-to-use end-user development tools. Such systems may be standalone with no linkages to any other end-user or corporate system, or they may use databases and database extracts from corporate information systems (perhaps with additional database tables created by the user) and manipulate the data in order to produce information not previously made available. In the latter case, the data may already exist in the corporate database, but the processing necessary to produce the information has not been included as a core part of the application.

■ Feasibility. Part of the feasibility exercise is for the user to be sure that the necessary and appropriate end-user development tools exist or can be acquired in order to proceed with the development. A second aspect is an analysis of the cost involved in end-user- developed software: while an end-user is producing software, their ‘normal’ tasks either remain undone or have to be done by someone else. Therefore, end-user applications development needs to be justified on economic grounds.

■ Analysis. One of the benefits is that an end-user need not present information systems requirements to an IS/IT specialist for subsequent development. This therefore reduces the risk of mistranslating information systems requirements and increases the probability that the developed system is what the user actually wants. The end-user may still find it useful

User-developed software

Software written by non- IS professionals, i.e. the business users.

■ Vendor vision. This is linked with the previous driver insofar as the prospective package purchaser will be interested in how the vendor intends to improve the software product and expand the market for it. In some cases, vendor and purchaser will work closely together in order to develop the product further: the vendor ends up with a superior product, while the purchaser may be able to negotiate a lower purchase price.

■ Industries covered. Some vendors will focus on a very narrow market segment while others will aim their products at a wider audience. This could be of particular importance to an organisation that operates in many markets and that needs a software package that will operate across a number of sectors.

■ Other drivers. Included under this broad heading are such factors as ease of use, versatility, flexibility, responsiveness, error handling and security issues. Some of these factors may be such that they appear as primary drivers (e.g. as a feature of the software product.

These drivers, both primary and secondary, will ultimately have their expression in the set of software requirements and desirable design features as noted in the analysis and design elements of the SDLC. In addition factors such as cost and functionality may also be a feature of the feasibility study – i.e. can a package be purchased that meets the organisation’s economic, technical, operational and organisational feasibility constraints?

M07_BOCI6455_05_SE_C07.indd 285 30/09/14 7:20 AM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT286

to apply some of the tools associated with the analysis phase such as those discussed later (in Chapter 10) , although clearly they will be used on a much smaller scale.

■ Design. End-user-developed software has a tendency to be developed more on a ‘trial and error’ basis than through the use of formal design techniques. When it works well, this can result in the faster development of applications software. The downside is that poor design may result in a system that at best does not work quite as it should and at worst a system that actually results in incorrect information being produced. Incorrect information can have various results, ranging from short-term irritation to corporate decision-making errors with large financial consequences. One of the most useful tools in end-user design is entity relationship modelling, which should be used in conjunction with logical and physical database design. The probability is that if the database design and associated data validation rules are correct, then the system is more likely to produce the information that is required.

■ Build. Recent improvements in the availability of inexpensive development tools such as Visual Basic for the PC have made it much easier for the end-user developer to build systems without recourse to difficult programming techniques. As end-user development is now much easier than it was previously, emphasis can be placed on the functionality which the system is to offer. Also, development times are speeded up, and this provides for the effective use of iterative prototyping in this step.

■ Implementation/changeover. This step is less critical than for company-wide information systems. Data are either locally generated or extracted from central databases, where it can be assumed that the data are validated and verified as correct. In fact, the term ‘changeover’ is probably not a good one in this context – ‘live running’ may be a better one. It is quite possible that an end-user-developed system is capable of producing useful information even before it becomes a ‘live’ product. A risk is that end-user-developed software may not have been tested sufficiently thoroughly and this raises an important question of the management of such software. We will deal with this later (in Chapter 16).

■ Maintenance and review. All software has to be maintained in some way. In many respects, the maintenance of end-user-developed software is more problematic than for other forms of software acquisition. This is because end-user-developed systems are often not documented and they may employ obscure techniques in their construction.

End-user development is discussed in more detail later (in Chapter 16).

Lascelles Fine Foods (LFFL) is a fictitious example of a long-established company operating in the food industry. The company has its administrative headquarters in Ashville and manufactures on an adjacent site. All customer deliveries are from the Ashville-based warehouse. In addition, LFFL purchases finished and semi-finished food products from other manufacturers which it then finishes before resale.

The company has enjoyed steady growth in recent years and is now seek- ing to capitalise on the current fashion for quality and healthy food products. LFFL’s

turnover is £16 million with net profitability of 6.3 per cent of turnover. It is hoping to gain a competitive edge by providing quality food products which meet all present and antici- pated quality standards and to this end will be applying for BS5750 accreditation within the next six months. It is hoping to increase turno- ver by 10 per cent per year after inflation over the next five years and increase net profitability to 9 per cent of turnover over the same period.

LFFL’s main operations are divided into four main areas:

■ sales and marketing; ■ warehousing and distribution;

Lascelles Fine Foods

CASE STUDY 7.3

So ur

ce : T

hi nk

st oc

k ph

ot os

M07_BOCI6455_05_SE_C07.indd 286 30/09/14 7:20 AM

287ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

➨

■ issuing raw materials to manufacturing in response to submitted requisition forms;

■ receiving finished products from manufacturing and any unused raw materials.

Information about quantities of finished goods and raw materials in stock is recorded in a card file, which has to be searched manually for the appropriate entry when updating is required.

Manufacturing Manufacturing ranges in complexity from simple repackaging of bulk-purchased materials to complex mixing and cooking activities.

Recipes are recorded on 7″ by 5″ cards and include details of the required ingredients as well as the processing which is to take place.

Finance LFFL’s finance department is divided into three areas:

■ accounts payable – when LFFL makes purchases, suppliers will invoice them; LFFL uses a manual purchase ledger to manage these accounts;

■ financial accounting – management of all monies flowing in and out of the company together with compliance with legal accounting requirements;

■ management accounting – internal accounting information necessary to manage the business more effectively.

The accounts receivable area is handled by the account handlers who use a manual sales ledger and make a weekly return to the finance department on the state of their customers’ accounts.

Specific business issues There are a number of specific issues which relate to the activities of each department. These are detailed below.

Sales

■ The status of an order cannot easily be determined without pestering the warehouse.

■ Many customer complaints occur due to delivery of wrong products, orders delivered too late, incomplete orders and faulty products.

■ Warehousing does not deliver the most important orders first – small orders are often given priority over larger orders from major retailers.

■ Orders often cannot be delivered on time because manufacturing produces too late and in insufficient quantity.

Warehousing and distribution

■ Many items have a limited shelf life – warehousing often fails to rotate the stock properly.

■ Actual stock levels are rarely in step with the recorded stock levels – this may be due to pilfering, poor update of stock records or both.

■ manufacturing; ■ finance.

All information recording and internal communication is paper based and relies on a range of preprinted documents which are then used as appropriate.

The sales department LFFL has a diverse customer base, ranging from small health food shops to major supermarket chains. Orders can be one of two types: standard orders placed in advance for delivery in a specific week or priority orders placed for immediate delivery.

Orders are placed either directly through sales office ‘account handlers’ or through field sales persons (each customer has one sales person). Each customer is allocated an account handler who acts as the main liaison point within LFFL. Besides receiving orders, the account handler is responsible for cash collection, ensuring satisfactory progress of the order and handling day-to-day queries. Customers are also placed into sales categories based on geographic location, volume of business and type of customer (e.g. specialist store vs supermarket chain). The sales director is apt to change his mind about which category a customer is in and which category means what.

Order processing Once an order is taken, it is recorded on a preprinted order form. One copy is retained by the sales department and two copies are sent to warehousing and distribution.

Warehousing and distribution sort all order forms into date order. When an order is due to be delivered, products are picked from the warehouse and loaded into the appropriate vehicle.

When an order is delivered, it is accompanied by a consignment note and an invoice. The customer is required to check the delivery against the invoice and note any errors on the consignment note. The delivery driver returns with a signed copy of the consignment note and if any errors are noted a corrected invoice is sent to the customer.

Warehousing and distribution LFFL stores finished products, bought-in products and raw materials in the warehouse. The warehouse is divided into three areas:

■ the general zone, comprising a high-rise bulk storage area with a floor-level picking area;

■ the cool zone, comprising low-level storage at 2 to 4°C; ■ the frozen zone, with temperatures held to –18°C. ■ In addition to their role in the order processing cycle,

other activities are also performed: ■ internal warehouse movements from high-rise locations

to ground-level areas and vice versa; ■ receiving products and raw materials from suppliers

and returned products from customers;

M07_BOCI6455_05_SE_C07.indd 287 30/09/14 7:20 AM

Future plans

The managing director, Clive Moor, has indicated that he would like to replace the existing paper-based systems with ‘computers of some kind’. With such a move, he is hoping to improve on the communication of information at all levels in the organisation. However, Mr Moor knows little about computer hardware or applications software except that it seems to cost rather a lot.

In order to proceed with the computerisation programme, Mr Moor has asked the following senior managers to produce a plan:

■ Paula Barlow – finance director; ■ Terry Watson – sales and marketing director; ■ Peter Jackson – manufacturing operations director; ■ Frances Clarke – warehousing and distribution director.

However, these directors have varying degrees of enthusiasm for the project, together with a desire to minimise the risk of damage or exposure within their own departments. One of the key decisions which must be made will be how LFFL acquires the necessary applications software. One option will be to hire relevant IT staff and build bespoke applications, while another will be to purchase off- the-shelf packages. Yet another option will be for end-users to develop their own applications. This last option may prove awkward, since there is very little IT expertise among the end-users.

■ The sales department often accepts priority orders for products which are not in stock.

■ Manufacturing bypasses the normal requisition procedures and simply takes raw materials as required – it also often fails to return unused materials to warehousing.

Finance

■ The sales returns from the account handlers are often incomplete.

■ There are several bad debts which cannot be recovered – this is attributed to poor credit control procedures.

■ Management accounting is very difficult due to a general lack of accurate information from other departments.

■ Financial accounts are often published late due to lack of accurate information.

Manufacturing

■ Warehousing is slow to respond to requests for raw materials, thus necessitating correct procedures being bypassed (especially when the sales department is applying pressure).

■ Lack of accurate forecasting makes it difficult for production to be planned ahead and adequate supplies of raw materials to be secured.

General

■ There is a rapid turnover of staff, especially in the sales area where the pressure from customers can be in-tense. In addition, field sales personnel are apt to make promises which cannot be kept and new sales personnel are often thrown in at the deep end with little formal training for their jobs.

■ There is a high level of sickness in the warehousing and distribution area, due mainly to inadequate provision of lifting equipment.

■ There is a perceived lack of management and technical support which has resulted in a general lowering of morale.

QUESTIONS

1. Which method(s) of business systems software acquisition would you recommend to LFFL? Explain and justify your answer.

2. Assuming that LFFL decides to go down the route of purchasing off-the-shelf packages, what steps do you recommend it takes to ensure that the applications which are selected meet their requirements?

1. Acquisition refers to the approach for sourcing BIS. Alternative acquisition methods include:

■ off-the-shelf – purchased from a software vendor; ■ bespoke – ‘built from scratch’; ■ end-user-developed – self-explanatory.

Complex and organisation-wide BIS such as e-business systems often require hybrid sourcing approaches and enterprise applications integration of different components from different vendors.

2. A useful model for the stages of a BIS acquisition project is the systems development lifecycle model (SDLC). The stages described in later sections of Part 2 are:

■ initiation – identification of opportunity or problem to be solved by BIS; ■ feasibility – assessing cost–benefit and acquisition alternatives;

SUMMARY

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT288

M07_BOCI6455_05_SE_C07.indd 288 30/09/14 7:20 AM

289ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

■ analysis – assessing the user and business requirements; ■ design – producing a specification for the approach of producing a structure for the BIS; ■ build – coding, documenting, data migration, testing; ■ implementation – installation, testing, changeover; ■ maintenance and review – live system review and update.

3. End-user development tends to neglect the feasibility, analysis, design and testing phases. The design and build phases are relatively insignificant for off-the-shelf acquisition.

4. The classic SDLC model of system acquisition has experienced problems of insufficient user involvement – leading to poor delivery of business-user requirements and a protracted lifecycle which may also result in loss of competitive advantage or budget overruns.

5. RAD and prototyping approaches encapsulated in lean and agile approaches to software development and as illustrated in the Dynamic Systems Development Methodology (DSDM) are aimed at solving the problems of the stage models. The key characteristics of this approach are an iterative approach with frequent delivery of prototypes coupled with user involvement throughout the project.

1. Explain what the main similarities and differences are between bespoke development and end-user development.

2. Why would a small business be more constrained in its choice of software acquisition method than a large one?

3. What are the main differences between the analysis and design steps of the traditional waterfall model of systems development?

4. What are the main components of the system build stage?

5. Explain how the application of the waterfall model differs between (a) the purchase of an off-the-shelf package and (b) an end-user-developed application.

6. Briefly review the main advantages and disadvantages of bespoke development when compared with off-the-shelf packages.

EXERCISES

Self-assessment exercises

Discussion questions

1. ‘The rise of rapid applications development is mainly a response to the failure of traditional systems development methodologies to deliver the right system at the right price and at the right time.’ Discuss.

2. ‘End-user applications development would be far less popular if central IS/IT departments did not have such a large applications development backlog.’ Discuss.

Essay questions

1. What do you believe to be the main differences between large and small organisations in deciding the best approach for information systems acquisition?

M07_BOCI6455_05_SE_C07.indd 289 30/09/14 7:20 AM

Examination questions

1. Explain the terms ‘bespoke development’, ‘off-the-shelf package’ and ‘end-user computing’. Illustrate your answer with some of the reasons cited in favour of each of these methods of application software acquisition.

2. Give three advantages usually associated with prototyping.

3. During a bespoke development project, the systems development lifecycle will include a number of steps from requirements analysis, design and system. Which of these steps is relevant to an off-the-shelf system? Which activities might be involved?

4. Explain how the spiral model of systems development which can be applied to RAD differs from the traditional waterfall model. Which do you believe represents the best method of developing information systems?

Avison, D.E. and Fitzgerald, G. (2006) Information Systems Development: Methodologies, Techniques and Tools, 4th edition, Blackwell, Oxford

Boehm, B. (1988) ‘A spiral model of software development and enhancement’, IEEE Computer, 21, 5, May, 61–72

Poppendieck, M. and Poppendieck, T. (2009) Leading Lean Software Development, Addison- Wesley, Upper Saddle River, NJ

Sahay, B.S. and Gupta, A.K. (2003) ‘Development of software selection criteria for supply chain solutions’, Industrial Management and Data Systems 103, 2, 97–110

Senn, J. (2004) Information Technology: Principles, Practices and Opportunities, 3rd edition, Prentice-Hall, Englewood cliffs, NJ

References

Further reading

Curtis, G. and Cobham, D. (2008), Business Information Systems: Analysis, Design and Practice, 6th edition, Financial Times Prentice Hall, Harlow.

Kendall, K.E. and Kendall, J.E. (2013) Systems Analysis and Design, 9th edition, Prentice-Hall, Englewood cliffs, NJ.

Martin, R.C. (2011) Agile Software Development: Principles, Patterns and Practices, Prentice- Hall, Upper Saddle River, NJ.

Poppendieck, M. and Poppendieck, T. (2009) Leading Lean Software Development, Addison- Wesley, Upper Saddle River, NJ.

Tudor, D.J. and Tudor, I.J. (2010) The DSDM Atern Student Workbook, galatea Training Services, Rochdale.

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT290

2. In what circumstances do you think that rapid applications development would be (a) appropriate and (b) inappropriate when carrying out systems analysis and design?

3. Is the end-user development approach to business software development something which you think should be encouraged, or do you believe that applications software for business is best left to information systems professionals?

4. Compare and contrast the traditional waterfall model with lean and agile approaches to software development with particular emphasis on the ability to deliver business value.

M07_BOCI6455_05_SE_C07.indd 290 30/09/14 7:20 AM

Web links

www.sei.cmu.edu carnegie Mellon Software Engineering Institute.

www.computerweekly.com Computer Weekly is a good source of case studies of different acquisitions approaches and problems of project management.

www.yourdon.com Ed Yourdon’s web site is a good collection of up-to-date papers about problems of information systems development from one of the gurus of software development.

www.research.ibm.com/journal The IBM Systems Journal and the Journal of Research and Development have many cases and articles on analysis and design related to e-business concepts such as knowledge management and security.

291ChaPter 7 AN INTRODUcTION TO AcqUIRINg AND DEVELOPINg BIS

M07_BOCI6455_05_SE_C07.indd 291 30/09/14 7:20 AM