Pearson Education Limited 2003

Transcription

1 119

2 Activities There are no activities for this chapter. 120

3 Case Studies Case Study 7.1: Direct Line reviews systems (P. 291) 1. Summarise the different systems acquisition approaches used by Direct Line. 2. Explain the reasons given for these approaches. 3. What do you think made Direct Line break with tradition and purchase the Chordiant package. 1 Traditionally, Direct Line has used an in-house bespoke approach, but with the Chordiant System it has used a packaged software approach. 2. The speed at which Direct Line introduces new products means it needs a flexible product to accommodate this. It is implied that the in-house development is too slow to respond to these demands. 3. A lack of experience in e-commerce and CRM systems meant that in-house development would have taken too long to provide them with a competitive advantage. Case Study 7.2: Lascelles Fine Foods (P. 305) 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? The questions have been based around the case study Lascelles Fine Foods Limited (LFFL). This is a fictitious organisation and is not intended to bear any similarities to an existing company, past or present. 1. The recommended acquisition method must satisfy the main feasibility criteria (economic, technical, operational and organisational). LFFL has very little expertise in the acquisition of information systems. There are no IS/IT specialists within the business and there is little practical experience in the development of computerised information systems by end users. LFFL is also operating in a business with a relatively low level of uniqueness (i.e. the probability that a suitable information system can be purchased is quite high). Each of the alternative acquisition methods can be evaluated against the feasibility criteria outlined above. (a) Bespoke development. This can be done either internally (in which case, specialist staff will need to be hired), or contracted out to a third party (a software house). Each feasibility criterion will be taken in turn: Economic. This acquisition method is expensive, especially so for LFFL. Given the company s turnover, it is unlikely that the benefits to be gained outweigh the costs. 121

4 Technical. There is no doubt that a solution can be developed by employing the services of a software house. Similarly, specialist staff can be recruited by LFFL either on a permanent or contract basis. With either acquisition method, however, it will be necessary for the IS/IT personnel to acquaint themselves very quickly with the way in which LFFL operates. Organisational. It is very probable that a bespoke solution will fit in with the day-to-day practices within LFFL since the solution can be designed around them. Operational. Similarly, a bespoke solution can be designed so that it conforms to the required speed, volume, usability and reliability parameters. (b) End-user development. Economic. While end-user development is good for developing personal or departmental applications more cheaply than a normal bespoke solution, there is still the opportunity cost of the normal business activities that those personnel would normally carry out which must be undertaken by others. Technical. Within LFFL, there is currently insufficient expertise to deliver the required solution. Either it will need to employ additional staff with the necessary skills or train existing staff, or possibly both. In any event, costs will increase. Organisational. End-user developed solutions tend to be for personal or departmental use. It is possible, therefore, that this acquisition method may concentrate on local solutions at the expense of company-wide considerations. Operational. There is a risk that, unless the end-user developer is particularly skilled, a solution developed in this way will not have the required performance characteristics. (c) Purchase of an off-the-shelf package. Packages may come in standard or tailored form. While it may be useful to differentiate between them, the comments apply largely to both. Economic. This acquisition method is the cheapest for any level of technical complexity when compared with an equivalent solution acquired by one of the alternative methods. Technical. As mentioned above, there appears to be nothing so specialised or unique about LFFL s business that a packaged solution is incapable of dealing with. It may be that some tailoring is required, in which case a vendor must be sought who will customise their own software. Organisational. This is the greatest area of difficulty for this acquisition method. It may be that organisational practices will have to change to fit in with software if the required tailoring cannot be implemented. Operational. It is probable that off-the-shelf software will be written to conform to performance criteria that most organisations will find acceptable. The issue for LFFL is to assure itself that the selected solution conforms to its requirements. The key objective for this question is to get the students thinking logically about the problem by constructing a framework for analysing the issues. An additional feature that could be incorporated into the above is the criteria outlined in the section Factors affecting software acquisition in Chapter For this question, the students need to consider the relevant steps within the system s development lifecycle. At this stage, students will not have covered the more detailed aspects of 122

5 analysis and design. However, it is still possible to come up with a broad explanation of what should be done. The decision to select an off-the-shelf package implies that the feasibility study has already been completed. The steps that the company needs to follow are: Analyse requirements. Fact-finding methods and documentation tools are examined in Chapter 11. The outcome from this process should be a requirements catalogue which contains the details of what the new system is to do. Design. This is dealt with in more detail in Chapter 12. The important point here is for students not to be distracted by looking at design activities such as program and database design, but to concentrate on identifying design elements that need to feature in the packages that are examined. Build. The build stage for LFFL will differ from a bespoke solution because there will be no programming activity. However, the testing and conversion phases will still be needed (although in the case of LFFL, conversion means converting paper based records into computerised ones). Of particular importance will be user acceptance testing to ensure that the software as selected meets LFFL s requirements. LFFL may seek to use external consultancy services to assist it in selecting the most appropriate software package. This is because it may be felt it currently has insufficient expertise within the business to make an informed decision about what software to purchase. Case Study 7.3: Lloyds Bank Insurance Services applies RAD (P. 309) 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? The following questions require students to analyse the case study in order to pick out the relevant points and make pertinent observations. A frequent difficulty is that although students are asked to work through the questions beforehand and present their answers in a tutorial or seminar, the preparatory work doesn t always seem to be done by the whole class! 1. Lloyds was faced with: a business opportunity that could be profitably exploited; the need for a telesales quotation system that worked first time and fulfilled user expectations; an immovable deadline by which the system must be up and running; no spare resource availability. Lloyds was attracted by RAD because: it had already identified a software house with the necessary skills this would help it to address the resource constraints; RAD promised a workable solution within a very short timescale; RAD also offered the flexibility needed for the software development, especially given the tight deadlines; 123

6 a development tool in the shape of Symantec offered the power needed to support the development. 2. Less of a disadvantage and more of a risk was the fact that MDA (the software house) had no experience of the Enterprise Developer product, although it was keen to gain experience. The danger was that the product would prove insufficiently capable in delivering the required solution There were also fears amongst the user team that they would not be able to cope with Windows and mouse driven systems. The short development time may have meant that users still lacked the necessary experience by the time the system was ready to be implemented. Against this, the point that RAD positively requires extensive user involvement in the development process helped to overcome these difficulties. 3. There are a number of reasons to believe that future projects will be successful: The project manager (Jacklin) was happy with the service offered by the software house for this project. There is no reason to suppose that its services would be unavailable next time. The system was developed and implemented on time, despite a change to the Oracle DBMS. LBIS is a market-oriented organisation that needs to react to business changes quickly and envisages the need for further development over the next 18 months. The system has a very short pay-back period an indication that the economic feasibility argument has already been won. 124

7 Exercises (PP ) Self-assessment exercises 1. Explain what the main similarities and differences are between bespoke development and end-user development. The answer should begin by explaining that both development methods are intended to produce solutions that are specific to the organisation developing them. The differences should include the scale of the development, the area of the organisation in which the application is likely to be used (departmental versus corporate) and the probable skill mix of the developer. 2. Why would a small business be more constrained in its choice of software acquisition method than a large one? The answer should look at the various aspects of feasibility related to alternative acquisition methods and how these relate to organisations of different sizes. It should also be pointed out that smaller organisations are likely to have less well-developed IS/IT skills amongst their personnel and this would reduce the options in relation to bespoke and end-user development. 3. What are the main differences between the analysis and design steps of the traditional waterfall model of systems development? The answer requires students to emphasise that analysis is fundamentally about what the proposed system is to do, whereas design is about how it is going to do it. The difference is also about identifying requirements on the one hand and solutions on the other. 4. What are the main components of the systems build stage? Students should be able to recall the three main components and say a little about each one. Programming. The design specifications are converted into program code using appropriate programming languages. Mention of 3 rd and 4 th generation languages is desirable. Testing. The programs that have been written need to be tested, both individually and together. It would be useful if students could identify alternative aspects of testing including module, subsystem, system, volume, performance and user-acceptance testing. Conversion. The emphasis here should be on methods of converting data from old manual or computer based systems to the formats required in the new system. It is not appropriate here to talk about cut-over methods, such as parallel running or pilot cut-over. 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. The danger here is of being drawn into the trap of treating end-user applications development in the same way as bespoke development by IS/IT professionals. In the case of the latter, the conventional approach is to follow each step of the model in a logical and systematic manner. In 125

8 the case of the former, end-user developers are more likely to experiment and so the development process becomes more akin to iterative prototyping. In other words, the analysis and design and activities tend to become merged. It should also be pointed out by the student that the activities tend to be on a smaller scale with end-user development, with much shorter development times. 6. Briefly review the main advantages and disadvantages of bespoke development when compared with off-the-shelf packages. One of the best ways for the student to present this is in the form of a two-by-two matrix, showing acquisition method on one axis and advantages and disadvantages on the other. Alternatively, you may prefer your students to look at various factors such as acquisition time, quality, flexibility, maintainability and cost and compare each acquisition method against these criteria. 7. Identify the main stages involved in SSADM. Which stages of the traditional waterfall model do they relate to? This question is designed to reinforce the point that SSADM only relates to the analysis and design phases of this model. Students should identify the following main steps: stage 1 investigation of current environment; stage 2 business systems options; stage 3 definition of requirements; stage 4 technical system options; stage 5 logical design; stage 6 physical design. Stages 1 to 3 relate to the analysis phase, while stages 4 to 6 relate to systems design. 8. How does rapid applications development differ from SSADM as a means of producing quality software? The students attention needs to be drawn to the meaning of the term quality. In this context, an information system needs to deliver the correct information to those that need it, in the correct form and when it is required. For RAD, the emphasis needs to be placed on the iterative nature of the development process, with evolutionary prototyping and heavy user involvement being at its core. The thrust of RAD is to come up with software solutions that deliver information systems quickly and, therefore, are more likely to meet current business needs. SSADM, on the other hand, places an emphasis on a rigorous and systematic approach where each step must be completed and signed off before the next one can commence. The main objective then is to prevent errors later on in the systems development process by ensuring that each preceding step has been carried out correctly. 126

9 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. This question is asking students to reflect on whether or not a traditional approach to systems development (such as SSADM) is inevitably going to result in systems that take longer to develop (and are, therefore more expensive) than alternative methods. The question also points to the assertion that since business requirements change much more rapidly today, development methods which are more long-winded may result in systems developers solving what has become yesterday s problem rather that today s or tomorrow s. Students need to analyse whether or not methodologies such as SSADM inevitably result in longer development times or if they can be modified to compete with alternatives such as DSDM. It should also be remembered that RAD looks at the whole lifecycle of systems development, whereas many methods concentrate on analysis and design activities. With RAD, the distinction between analysis and design becomes blurred through the use of evolutionary prototyping. Not only is prototyping used as a means of refining further what users actually want from an information system, but it is also used to identify the design requirements (input, output, processing etc.). Finally, prototypes are developed and refined (using 4GLs and application generators) so that they are implementable as the finished solution. RAD is also characterised by the use of Timeboxes (typically 90 days) where system products are delivered to end users at the end of each Timebox. 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. This question requires two issues to be addressed. First, does an applications development backlog indeed exist, and if so, why? Secondly, are the kinds of applications developed by end users those which might otherwise be developed by information systems professionals? To take the first issue, it is generally accepted that there is a worldwide shortage of IS/IT professionals and this is reflected in high salary levels and rapid staff turnover. At the time of writing, an extensive amount of work is also going into millennium compliance projects. However, the applications development backlog is not just a recent phenomenon, having existed for several years as users expectations have risen and business information requirements developed. With respect to the second point, it is necessary to draw a distinction between company-wide information systems and those developed for personal and departmental use. The tendency is for organisations to concentrate systems developments on those applications that can be seen to benefit the organisation as a whole rather than a single functional area (or part of a functional area) within the business. Similarly, the launch and subsequent development of the PC and the 127

10 associated software tools that can be used with it have created an opportunity for non-is/it personnel to develop applications using spreadsheets, databases and report generators. The argument is, therefore, not so much that end-user applications development is taking place instead of corporate development, but rather that end-user development is in addition to the corporate development work that would still take place. Rather like national health services, the demand for information systems is something of a bottomless pit however many resources are pumped in, demand is still greater. Self-help becomes the name of the game, and information systems are no different. 3. Do you think it is true that the existence of so many information systems problems attributed to the millennium bug is primarily a reflection of poor systems development techniques? In tackling this question, students need to look at the problem from an historical context. Many applications development problems stem from the use of six-figure dates with just two figures being used for the year portion. Originally, dates were coded in this way to save storage space. Here it is useful for students to remind themselves that computing power and capability increase by between 50 and 100% every year and that today s storage capacities and processing power are vastly higher that those of just 10 years ago. The authors of these legacy systems that are causing so much trouble generally did not envisage that programs written even 10 years ago would still be running at the end of the millennium. A further complication concerns some database management systems which even as recently as 1995 were not millennium compliant. This means that even if the databases were designed correctly to hold eight-digit dates, the underlying database management system was going to fail come the year

11 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? As with similar questions above, the three primary issues are: economic the ability of the two to finance IS/IT; capability the expertise within the organisations to make effective procurement decisions; complexity the degree of sophistication that the applications software needs in order to fulfil the organisation s requirements. With these and similar questions, it is advisable to ask students to give specific examples of cases from the computing press to illustrate their answers. 2. In what circumstances do you think that SSADM would be (a) appropriate and (b) inappropriate when carrying out systems analysis and design? This question requires students to think about traditional approaches to information systems development. SSADM is given as a methodology since it is one of the most popular ones used in the UK and is essential for many government sponsored systems development projects. Students should look at the following areas: Size of the proposed system. Very large or complex systems will require a rigorous approach to identifying requirements and design criteria. Such systems lend themselves to the more disciplined approach encouraged by SSADM. Smaller systems on the other hand may be developed using a cut-down version of the methodology where certain steps are omitted altogether. Proposed development method. If it is proposed that evolutionary prototyping is to be used for the development work, it may be difficult to fit this in with relatively rigid analysis and design methodology. On the other hand, the use of 3GLs, such as COBOL or PL1, rather that 4GLs or other application generators may encourage the use of more formal methodologies where the deliverables from the design stage provide an important input into the build stage of the project. Organisational structure and culture. The formal approach offered by SSADM may well be suited to some organisations where adherence to particular rules and procedures is important. The sense of order that SSADM imposes may well result in more effective systems development than the relatively informal and flexible approach offered by DSDM, for example. Stability of the business situation. Where the business requirements are unlikely to change over the course of the development project, SSADM can work satisfactorily. However, when the requirements are very fluid and likely to change, or where business needs are likely to change over the course of the project, it may be more appropriate to look for analysis and design methods that offer the degree of flexibility to cope more easily with change. Speed of development. This is related to the previous point insofar as solutions that are required quickly will require methods more closely related to RAD. It may be argued, 129

12 therefore, that SSADM is inappropriate because of the need to sign off each step in the development process. 3. In what circumstances do you think that rapid applications development would be (a) appropriate and (b) inappropriate when carrying out systems analysis and design? This question runs very much along the same lines as the previous one, since many of the issues are repeated. It may be desirable, therefore, to combine the two into a single question where both aspects can be analysed more efficiently. In addition to the above points, there are some additional ones. System quality: There is a danger of RAD being perceived as a quick and dirty approach to systems development. While this shouldn t be the case, there is a risk if all staff (end users and IS/IT professionals alike) are not committed to making RAD work. If full commitment does not exist, then an organisation may wish to consider a more traditional approach to system development. Staff expertise: To be effective, systems development staff need experience in running highly interactive development projects. There has been a tendency for IS/IT staff to speak the language of computing, while other staff speak the language of business. It is necessary, therefore, for staff to overcome the communications gap. Increasingly, it is staff with hybrid skills (i.e. both business and computing skills) who are able to overcome this gap and, arguably, play an important role in successful RAD projects. 4. 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? As discussed above, it is important for students to differentiate between the types of information likely to be developed by end users and IS/IT professionals. Many of these issues have been discussed in the analysis of Discussion question 2. However, this question goes further and is looking for analysis of the advantages and disadvantages of end-user development together with a look at how end user development can be managed effectively. Advantages of end-user development that are frequently cited include: Reduces (but may not eliminate) the need for professional analysts and programmers. Reduces communications overheads of users explaining requirements to IS professionals; also reduces risk of mistranslation of requirements. Frees IS professionals to concentrate on tasks requiring their expertise. Helps to reduce the applications development backlog associated with completely centralised systems development. Allows applications to be developed more quickly therefore the business can benefit more quickly (e.g. increased managerial effectiveness due to better decision making). Can encourage innovation and creativity in the use of IS/IT: removes bureaucratic barriers, resource constraints, time delays and political barriers. Allows end users to feel a greater degree of control over their working environment (and encourages greater IS/IT proficiency amongst end users). 130

13 However, there are also risks! These include: using inaccurate specifications or assumptions about organisation activities; applying incorrect formulas or models; using incomplete information; using outdated information; selecting untested or inappropriate software; failing to follow standards or guidelines; failing to test assumptions or models; corruption of centrally held data by up-loading erroneous data; hazards of insecure systems open to accidental and deliberate damage; hazards of truly personal systems which are unreadable, not documented and not transferable. One possible solution to the problems posed by uncontrolled end-user development is the information centre. The information centre concept was originally spread by IBM a facility which would focus on delivering systems directly to users systems and intended to be smaller, cheaper and less formal than specialist developed systems. There is a range of services and functions offered by a typical information centre: Software advice compatibility (hardware and software), package availability; Application development requires the skills of an analyst programmer; an emphasis on quick and dirty solutions; Hardware consultancy detailed specifications (possibly constrained by organisational hardware strategy); Training packages, general skills etc.; Data supply from central files and databases to the appropriate PC package (and possibly the other way); EUC management to prevent the development of applications in an uncontrolled manner (this could lead to excessive data redundancy, incompatible data formats, re-invention of the wheel, poor hardware and software acquisition, poor standards of data integrity). Finally, it is helpful to look at some recommendations which, if followed, can reduce the risks posed by end-user developed information systems: download data from the central database to the PC or workstation rather than re-key data as the data will already have been validated; avoid user data entry to central databases except via applications especially written for the purpose by the IS department; set out standards for EU developed systems which are rigidly enforced (including clear data definitions, validation rules, backup and recovery routines and security measures); document the application, especially why the application was developed; review and test user-developed software e.g. by IC personnel; train end users; facilitate communication between user e.g. through user groups, newsletters, briefings etc. 131

14 Examination questions These examination questions are of the short answer form. As such, they are designed to encourage recall of essential concepts. For applied questions, please see the questions above that are associated with the LFFL case study. 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. The students should present an answer along the following lines. Bespoke development occurs when either in-house IS/IT staff or a third party such as a software house develop applications software for a business. The software is tailored to the organisation s specific requirements. Bespoke solutions are required where packaged software cannot be procured which offers the necessary functionality and/or would require changes in working practices that are unacceptable to the organisation. An off-the-shelf package is a software product that has been written by a company with the intention of selling it to many customers. Benefits include the ability to purchase sophisticated software solutions at a much lower cost than bespoke development, the increased probability that the software will be free from bugs when implemented, and access to upgraded versions of the software in return for an annual maintenance charge. End-user computing occurs when non-it professionals develop software solutions themselves, often using PC-based tools such as spreadsheet, database and report generator packages. These applications are usually for personal and departmental use, although, in the case of small businesses, the software may have organisation-wide use. The benefits include the ability to produce tailored solutions without the expense of using IS/IT personnel, the freeing up of IS/IT professionals to concentrate on developing corporate information systems and also the sense of ownership that comes from having developed software oneself. 2. Give three advantages usually associated with prototyping. In answering this question, the student would be expected to do more than just produce a list of points. Each advantage should come with an explanation. For example: Throwaway prototyping where the prototype is developed during the early stages of the requirements process can be used to elicit knowledge about what the intended users of the information system want. It is argued that by working through sample screens and reports, both user and analyst can gain a better and quicker understanding of the users requirements. Evolutionary prototyping has the benefit of helping to develop information systems more quickly than traditional structured methods because the analysis, design and build processes are encapsulated into a single iterative process. This in turn means that the risk of developing solutions that do not meet business requirements is reduced, and faster development means that business benefits can accrue more quickly. 132

15 Finally, regardless of which approach is taken, a very important aspect of prototyping is that extensive interaction between user and developer occurs. This means a reduced risk of mistranslation of users requirements, improved communication between technical and business personnel and a greater sense of ownership of the completed system by the user community. 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? This question is asking students to differentiate between the activities appropriate to purchasing a package as distinct from developing a bespoke solution. One approach is for students to look at each stage and identify the activities to be undertaken and the detail which is required: Initiation. This will happen regardless of acquisition method. Feasibility. One of the outcomes of this stage will be a make or buy decision. Buying a package implies that the bespoke solution has been dismissed either because of cost or other considerations. It will still be necessary to scrutinise the proposed package solution under the economic, technical, organisational and operational feasibility criteria. Analysis. Regardless of acquisition method, user requirements will still need to be determined. However, an option open to the procurers at this stage is to identify alternative packages and use the information gained from reviewing them to come up with a more informed decision about the real user requirements. It is still appropriate to carry out fact-finding and documentation exercises and a requirements catalogue still needs to be produced. Design. Whereas a bespoke solution (developed using traditional methods) will require all aspects of the system designed, the purchase of an off-the-shelf package will examine the design features that need to exist within the purchased software. For example, certain reports may need to be produced and certain information about the business stored. In addition, the package must have the right look and feel so that the intended users will not be deterred from using the system. Build. Unless the package is to be tailored in some way, there will be no programming involved during this stage. With respect to testing, the intending purchaser will still have to be satisfied that the package will deliver the right level of performance and capacity to cope with the expected volume of transactions. While module, subsystem and system testing will have been performed by the vendor, the purchaser must still be sure that the package will work within their organisation. User acceptance testing is also required. Finally, data will still need to be converted from existing manual or computerised systems. This means that the purchaser may need special data entry screens or conversion programs to be written to convert data to the required format and structure. Implementation. A package solution will still need implementing. The changeover method (parallel running, pilot etc.) will still need to be selected. A difference here, though, is that, while a bespoke development can be maintained by the IS/IT staff if corrections are required, there is no such flexibility with the package solution. It is unlikely that the package vendor will amend the software if it does not seem to do exactly what it was thought it would do. Post-implementation review. This has benefits, regardless of the software acquisition method. There are still lessons to be learned for future projects. It is also worth reflecting on whether or not the package solution has delivered the benefits that were envisaged, or if a bespoke solution would have been better. 133

16 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? Students should identify the iterative nature of the spiral model when analysis, design and build can be repeated, distinct from the linear nature of the traditional approach. The spiral model or any other iterative approach has the following advantages: meets business requirements of end users better through greater user involvement via prototyping; errors more likely to have been identified during prototyping and removed; usually faster and therefore less costly than other methods. 134