9781780172453 developing information systems - bcsshop.bcs.org/resources/pdf/9781780172453.pdf ·...

DEVELOPING INFORMATION SYSTEMS

BCS, THE CHARTERED INSTITUTE FOR IT

BCS, The Chartered Institute for IT champions the global IT profession and the interests of individuals engaged in that profession for the benefit of all. We promote wider social and economic progress through the advancement of information technology science and practice. We bring together industry, academics, practitioners and government to share knowledge, promote new thinking, inform the design of new curricula, shape public policy and inform the public.

Our vision is to be a world-class organisation for IT. Our 70,000 strong membership includes practitioners, businesses, academics and students in the UK and internationally. We deliver a range of professional development tools for practitioners and employees. A leading IT qualification body, we offer a range of widely recognised qualifications.

Further InformationBCS, The Chartered Institute for IT,First Floor, Block D,North Star House, North Star Avenue,Swindon, SN2 1FA, United Kingdom.T +44 (0) 1793 417 424F +44 (0) 1793 417 444www.bcs.org/contact

http://shop.bcs.org/

http://shop.bcs.org/

DEVELOPING INFORMATION SYSTEMSPractical guidance for IT professionalsJames Cadle (editor)

© 2014 BCS Learning & Development Ltd

All rights reserved. Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted by the Copyright Designs and Patents Act 1988, no part of this publication may be reproduced, stored or transmitted in any form or by any means, except with the prior permission in writing of the publisher, or in the case of reprographic reproduction, in accordance with the terms of the licences issued by the Copyright Licensing Agency. Enquiries for permission to reproduce material outside those terms should be directed to the publisher.

All trade marks, registered names etc. acknowledged in this publication are the property of their respective owners. BCS and the BCS logo are the registered trade marks of the British Computer Society charity number 292786 (BCS).

Published by BCS Learning & Development Ltd, a wholly owned subsidiary of BCS The Chartered Institute for IT First Floor, Block D, North Star House, North Star Avenue, Swindon, SN2 1FA, UK.www.bcs.org

Paperback ISBN: 978-1-78017-245-3PDF ISBN: 978-1-78017-246-0ePUB ISBN: 978-1-78017-247-7Kindle ISBN: 978-1-78017-248-4

British Cataloguing in Publication Data.A CIP catalogue record for this book is available at the British Library.

Disclaimer:The views expressed in this book are of the author(s) and do not necessarily reflect the views of the Institute or BCS Learning & Development Ltd except where explicitly stated as such. Although every care has been taken by the authors and BCS Learning & Development Ltd in the preparation of the publication, no warranty is given by the authors or BCS Learning and Development Ltd as publisher as to the accuracy or completeness of the information contained within it and neither the authors nor BCS Learning & Development Ltd shall be responsible or liable for any loss or damage whatsoever arising by virtue of such information or any instructions or advice contained within this publication or by any of the aforementioned.

BCS books are available at special quantity discounts to use as premiums and sale promotions, or for use in corporate training programs. Please visit our Contact us page at www.bcs.org/contact.

Typeset by Lapiz Digital Services, Chennai, India.

iv

CONTENTS

List of figures and tables ixAuthors xiiForeword xivPreface xv

1. INTRODUCTION TO SYSTEMS DEVELOPMENT 1Contents of this chapter 1What is systems development 1Systems development and other disciplines 2Offshoring and outsourcing of systems development 4In the rest of this book 5

2. LIFECYCLE TYPES AND THEIR RATIONALES 8Contents of this chapter 8Introduction to system development lifecycles 8What we mean by ‘system development lifecycle’ 13Lifecycles based on the linear approach 17Lifecycles based on the evolutionary approach 23The impact of Agile 26Hybrid approaches 28Development approaches and methods 28How to choose an approach 32

3. ANALYSING THE BUSINESS NEED 35Contents of this chapter 35Introduction 35Business analysis 36The place of business analysis in the business development lifecycle 38Outcomes from business analysis 44Conclusion 45

4. MAKING A BUSINESS CASE 47Contents of this chapter 47The purpose of a business case 47The business case and the development lifecycle 47Feasibility checking 49Elements of a business case 50Identifying, evaluating and selecting options 51Cost–benefit analysis 52

v

CONTENTS

Risk analysis 53Impact analysis 56Investment appraisal techniques 56

5. REQUIREMENTS ENGINEERING 60Contents of this chapter 60Requirements engineering defined 60A framework for requirements engineering 61Roles in requirements engineering 62Requirements elicitation 64Business analysis techniques 68Requirements analysis 69Requirements validation 72Requirements documentation 73Requirements management 76Requirements engineering and Agile development 77Requirements engineering and off-the-shelf solutions 78

6. PROGRAMMING AND DEVELOPMENT APPROACHES 79Contents of this chapter 79Approaches to development 79Build or buy? 81Component-based development 88Development methodologies 92Software engineering paradigms 100The influence of technological advances 102

7. SYSTEM MODELLING TECHNIQUES 107Contents of this chapter 107What is modelling? 107Rationale for modelling 111Multiple models and views 114Pre-UML modelling technoques 115The unified modelling language (UML) 117Abstraction, levelling and scope 120Opaqueness of model elements 123Levels of models and model elements 125Cross-referencing models, facets, perspectives and traceability 131Documentation and specification within models 134Conclusion 137

8. SYSTEMS DESIGN – 1 139Contents of this chapter 139Objective of systems design 139Constraints upon systems design 142Systems design in the development lifecycle 146The scope of design 149Process design 163

vi

CONTENTS

9. SYSTEMS DESIGN – 2 173Contents of this chapter 173Data design 173Security and control design 186Logical and physical design 194Design patterns 196

10. SOLUTION-RELATED ARCHITECTURES 202Contents of this chapter 202Introduction 202Architecture patterns 203Communication and interoperation patterns 206Enterprise architecture 207Architecture principles 210Solution architecture 211Software architecture 214Stakeholders and roles in architecture 220Architecture management 222

11. QUALITY AND TESTING 225Contents of this chapter 225Introduction 225The quality triangle 226The definition of software quality 227The objectives and limitations of testing 228The static test stages of the ‘V’ model lifecycle 231The dynamic test stages of the ‘V’ model lifecycle 233Re-testing 235Regression testing 235Progression through the dynamic testing stages 236Testing in the lifecycle 237The test plan 239

12. IMPLEMENTATION AND CHANGEOVER 242Contents of this chapter 242Implementation in the lifecycle 242Planning for implementation and changeover 244File and data conversion or creation 245The principles and problems of data mapping 246Planning, testing and performing data conversion 247Migration of software modules 248Installation of hardware and infrastructure 249Supporting documentation 249Training 251System implementation 253The implementation plan 256

13. MAINTENANCE AND EVALUATION 258Contents of this chapter 258Introduction 258

vii

CONTENTS

Maintenance in the systems development lifecycle 258Maintenance categories 262Testing in the maintenance stage 263Evaluation 263The role and selection of metrics for evaluation 265

14. SOLUTION DEVELOPMENT TOOLS 269Contents of this chapter 269Introduction 269Typical tools functions and benefits 269Tools through solution lifecycles 272Conclusion 276

Glossary of terms and abbreviations 279Index 297

viii

LIST OF FIGURES AND TABLES

Figure 1.1 The main stages of systems development 1Figure 1.2 Systems development in a wider context 2Figure 2.1 The main stages of systems development 8Figure 2.2 Elements of the system development lifecycle 10Figure 2.3 The Waterfall lifecycle 18Figure 2.4 The ‘V’ model 19Figure 2.5 The extended ‘V’ model 20Figure 2.6 The Incremental lifecycle 22Figure 2.7 The Iterative lifecycle 24Figure 2.8 Boehm’s Spiral lifecycle 26Figure 2.9 Evolution of Agile 27Figure 3.1 POPIT™ model (© Assist Knowledge Development) 37Figure 3.2 The extended ‘V’ model 39Figure 3.3 Business analysis process model 40Figure 4.1 The business case in the lifecycle of an IT project 48Figure 4.2 Aspects of feasibility 49Figure 4.3 Option selection 51Figure 4.4 Categories of costs and benefits 53Figure 5.1 A framework for requirements engineering 61Figure 5.2 Roles in requirements engineering 62Figure 5.3 Contents of a requirements document 74Figure 5.4 Example of a user story from an inventory management

system 76Figure 5.5 Traceability 77Figure 6.1 Development approaches: schematic overview 80Figure 6.2 Advantages and disadvantages of the COTS approach 83Figure 6.3 Integrated components forming a sales order

processing solution 89Figure 6.4 Definition of the iOrders interface 90Figure 6.5 UML deployment diagram showing a component-based

solution 91Figure 6.6 Elements of a systems development methodology 92Figure 6.7 The MDA process 104Figure 7.1 The U curve 111Figure 7.2 The three-view model of a system 115Figure 7.3 Data flow diagram 116Figure 7.4 Entity relationship diagram (Everest’s ‘crows foot’ notation) 116Figure 7.5 Statechart (Harel) 117Figure 7.6 UML diagram types 117

ix


Figure 7.7 BookStack Mountain stock management system – use case diagram 118

Figure 7.8 Activity diagram for ‘record movement’ in use case 118Figure 7.9 Sequence diagram (incomplete) 119Figure 7.10 Class diagram used purely to model static data 119Figure 7.11 State machine for a BookStock instance 120Figure 7.12 Generalisation and specialisation in class diagram and

Barker Ellis ERD form 121Figure 7.13 Books composed of chapters (UML) 122Figure 7.14 BookStack Mountain – context diagram 124Figure 7.15 BookStack Mountain – system use case diagram 124Figure 7.16 The Functional model map and development activities 129Figure 7.17 Functional model map, populated with typical use

case types 130Figure 7.18 Functional model map, populated with diagram types

selected for a specific project 130Figure 7.19 CRUD matrix – mapping use cases to classes 133Figure 7.20 Functional model map, overlaid with traceability paths

from requirements to code 134Figure 7.21 Unified Process 4 + 1 architecture 136Figure 8.1 Objectives of systems design 140Figure 8.2 Constraints upon systems design 142Figure 8.3 The place of design in the Waterfall SDLC 147Figure 8.4 The place of design in the ‘V’ model SDLC 147Figure 8.5 The place of design in the Incremental SDLC 148Figure 8.6 The place of design in an Iterative SDLC 149Figure 8.7 Key elements of a computer system 150Figure 8.8 Use case diagram for a sales order processing system 151Figure 8.9 Stages during data input 154Figure 8.10 Simple module chart for a stand-alone system 164Figure 8.11 High-level design showing separate components and their

interfaces 165Figure 8.12 UML class diagram showing a detailed definition of an

interface 165Figure 8.13 Structure chart showing the de-composition of the

Place Order module 167Figure 8.14 Activity diagram specification of the Enter Customer

Details module 169Figure 8.15 Pseudocode specification of the Enter Customer Details

module 170Figure 8.16 Definition of an order object 170Figure 8.17 Class model showing abstraction (generalisation) and

polymorphism 171Figure 9.1 Spreadsheet showing un-normalised data 174Figure 9.2 Normalised data structures 175Figure 9.3 Example of a faceted code (UK vehicle registration

number) 177Figure 9.4 Example of a self-checking code 177Figure 9.5 Example of a hierarchical database structure 179Figure 9.6 Example of a network database structure 180

x


Figure 9.7 Example of a relational database structure 181Figure 9.8 Example of a result set from joining relations 181Figure 9.9 Example of an object database structure 183Figure 9.10 Example of a serial file organisation 184Figure 9.11 Example of a sequential file organisation 185Figure 9.12 Example of an index file 185Figure 9.13 UML state machine diagram showing the lifecycle for an

invoice object 191Figure 9.14 UML deployment diagram showing physical components 196Figure 10.1 Architecture domains in enterprise architecture 209Figure 10.2 Hierarchical domain services 212Figure 10.3 Solution scope – focus, breadth and depth 213Figure 10.4 Client-server patterns 215Figure 10.5 Three-tier software architecture with components shared

across clients 216Figure 10.6 N-tiered software architecture 218Figure 11.1 The quality triangle 226Figure 11.2 Static and dynamic testing in the ‘V’ model lifecycle 230Figure 11.3 Dynamic testing 233Figure 11.4 Testing in the lifecycle 238Figure 12.1 Implementation in the lifecycle 243Figure 12.2 Data creation and data conversion 245Figure 12.3 Data mapping 246Figure 12.4 Migration of software modules 248Figure 13.1 Maintenance in the Waterfall lifecycle 259Figure 13.2 ‘V’ model lifecycle 260Figure 13.3 The ‘b’ model of systems development 261Figure 13.4 Spiral lifecycle (Boehm) 262Figure 13.5 Extended ‘V’ model showing benefits realisation stage 266Figure 14.1 Areas covered by solution development tools 272

Table 4.1 Example of a payback calculation 57Table 4.2 Example of a discounted cash flow or net present value

calculation 58Table 6.1 Common defined (procedural) methodologies and

frameworks 95Table 6.2 Common Agile methodologies and frameworks 99Table 8.1 Common input technologies 156Table 8.2 Common output technologies 159Table 9.1 Common design patterns (after Gamma et al.) 198Table 10.1 Features of loose and tight coupling 205

xi

AUTHORS

Tahir AhmedTahir is a consultant and project manager with more than 30 years’ experience, working mainly with UK FTSE 100 companies. Since 2000, Tahir has worked as an independent consultant, typically leading major projects involving the senior management teams of organisations. He has extensive experience of successful project delivery and senior stakeholder management. Tahir has an MSc in Information Systems and is a full Member (MBCS) of BCS, The Chartered Institute for IT (BCS).

James Cadle (editor)James has been involved in the management services field since 1975 and in IT since 1981. He has been a systems analyst, business analyst, project manager, consultant and business manager and, since 1995, he has developed and presented training courses in his chosen fields. Not including the present text, he is the co-author of four books: Project Management for Information Systems (5th edition, 2008); Business Analysis (3rd edition, 2014); Business Analysis Techniques (2nd edition, 2014); and The Human Touch (2012). James is a Chartered Fellow (FBCS CITP) of BCS, a full Member of the Association for Project Management (MAPM) and a Fellow of the Royal Society of Arts (FRSA). James is an oral examiner for the BCS Diplomas in Business Analysis and Solution Development.

Julian CoxJulian is an experienced IT developer, consultant and training professional who specialises in system modelling and architectures. He has extensive experience of a variety of development lifecycles across the spectrum from traditional waterfall/linear approaches such as SSADM, through iterative and incremental approaches such as RUP to RAD and Agile approaches. Julian is a full Member (MBCS) of BCS, an oral examiner of the BCS International Diploma in Solution Development and a member of panels for the BCS Solution Development qualifications.

Lynda GirvanLynda has over 20 years’ experience in systems development as a consultant, professional trainer and practitioner in both private and public sector organisations. She has worked in enterprise and strategic modelling and analysis through to product level consultancy and coaching and has experience throughout the product development lifecycle. Lynda is a full Member (MBCS) of BCS, an oral examiner for the BCS International Diploma in Solution Development, a member of the technical and accreditation panels for the BCS Solution Development qualifications and lead examiner for the BCS Systems Development Essentials and Requirements Engineering qualifications. Lynda has spoken at numerous UK and US conferences in the public and private sectors on this topic.

xii

AUTHORS

Alan PaulAlan is Qualifications Director for Assist Knowledge Development and is a highly experienced IT professional whose management roles have included change management, programme and project management, strategy definition and service delivery. Project and programme management has covered the full development lifecycle of a number of multi-million-pound developments in the telecoms, financial services, retail and public sectors. Alan has extensive experience of leading large multi-disciplined teams, and in the procurement and management of third party suppliers, including external consultants. Alan contributed several chapters to Project Management for Information Systems (2nd edition, 1996).

Debra PaulDebra has over 30 years’ experience in the business analysis and IT field, as a consultant, manager and trainer, and is now Managing Director of Assist Knowledge Development Ltd. She has previously co-authored and edited three books in this field: Business Analysis (3rd edition, 2014); Business Analysis Techniques (2nd edition, 2014); and The Human Touch (2012). Debra is a Chartered Fellow (FBCS CITP) of BCS, a Fellow of the Royal Society of Arts (FRSA) and is the Chief Examiner for the BCS International Diploma in Business Analysis.

Peter ThompsonPeter has more than 20 years’ experience as a software development practitioner and manager covering all aspects of the systems development lifecycle. He has been the managing director of an independent software house and systems development manager for the UK’s largest independent recruitment agency. Peter is now a practising information systems consultant, specialising in the pragmatic application of best practice methods, and standards and combines this with a busy training schedule. Peter is a full Member (MBCS) of BCS, and is an oral examiner for the BCS’s International Diplomas in Business Analysis and Solution Development.

xiii

FOREWORD

In the rapidly evolving world of technological and business change it has never been more important to understand that high-quality information systems should be developed, acquired, customised and integrated in a consistent and best-practice way.

Getting the right balance between Agile development, linear development and solution procurement is key to this, and due consideration must also be given to the long-term maintenance and enhancement of any systems developed. This leads to the need to employ robust modelling, design, testing and implementation techniques and standards to support rigorous analysis coupled with architectural considerations.

The well respected authors of this book have excelled in their breadth of coverage of the various aspects of information-systems development, and their efforts have resulted in an excellent primer showing the interaction between the key information-systems disciplines, with many useful pointers to where readers can find more detail on any topics that they wish to explore further.

The book will be particularly useful for those studying for the range of BCS qualifications in the areas of systems and solution development, not least those who are sitting the core and specialist modules which lead to the BCS International Diploma in Solution Development, or those wishing to progress to full Chartered professional status.

Paul Turner FBCS CITPBCS Chief Examiner for Solution Development

xiv

PREFACE

The idea for this book came from a realisation that the existing texts on systems development, excellent though they are, have not been updated for some years and that IT professionals (and others) might benefit from a more up-to-date treatment of the subject. An obvious example is the way in which Agile approaches have gained considerable traction in the last decade.

The book has three main objectives:

y to review the way systems are developed, including the underlying philosophies, methods and techniques at the present time;

y to provide a broad overview of systems development for anyone beginning a career in software development or working in a related field;

y to provide people already working in systems development with usable advice on how to go about it.

Writing the book has been a genuine team effort between a group of people who have worked together for many years and have, between them, considerable experience of developing systems, training people in systems development, creating certifications in systems development and conducting examinations in the subject. I would like to take this opportunity to thank the team of authors for their hard work on the book, their friends and families for giving them their support, and the publishing team at BCS for helping us through the endeavour.

James CadleEditorApril 2014

xv

1 INTRODUCTION TO SYSTEMS DEVELOPMENT

James Cadle

CONTENTS OF THIS CHAPTER

This chapter covers the following topics:

y the purpose of systems development;

y the scope of systems development;

y the typical stages in the systems development process;

y the relationship of systems development to other disciplines, such as project management, business analysis and systems architecture;

y how offshoring and outsourcing influences systems development;

y a synopsis of the remaining chapters of this book.

WHAT IS SYSTEMS DEVELOPMENT?

Systems development is the process of taking a set of business requirements and, through a series of structured stages, translating these into an operational IT system. The stages vary according to the development approach being used – described more fully in Chapter 2, ‘Lifecycle types and their rationales’ – but typically would include the activities shown in Figure 1.1, including:

y a feasibility study, to see if the project is worthwhile;

y requirements engineering to analyse the business need and specify the users’ requirements;

y design of the system to meet the users’ needs;

y development of the software needed to meet the requirements;

y testing of the software;

y implementation of the solution.

Figure 1.1 The main stages of systems development

Feasibility studyRequirementsengineering

DesignDevelopment

(programming)Testing Implementation

1


Other activities may also be involved, such as the procurement and installation of the hardware on which the system will operate.

At one time, systems development was undertaken in a rather haphazard, ad hoc way, and the result depended to a large extent on the competence and enthusiasm of the individual developers. Today, the core importance of IT systems within most organisations means that more structured and manageable processes have been introduced, to reduce the unpredictable ‘human element’ and to make possible the construction of larger and more complex systems.

SYSTEMS DEVELOPMENT AND OTHER DISCIPLINES

Systems development does not take place in isolation; it is part of the intricately connected web of disciplines illustrated in Figure 1.2.

Figure 1.2 Systems development in a wider context

Projectmanagement

Servicemanagement

Qualitycontrol and

qualityassurance

Configurationmanagementand change

control

Testing Diagram © Assist KnowledgeDevelopment Ltd

Programming

Development(programming)

Testing Design

Requirementsengineering

Implementation

Systemsdevelopment

Feasibility study

Businessanalysis

Systemsarchitecture

2

INTRODUCTION TO SYSTEMS DEVELOPMENT

The relationship of systems development to other disciplines may be summarised as follows:

Project management If a systems development project is to be successful, technical expertise is not enough; effective project management is also required. The project manager plans the undertaking, mobilises the resources required and controls and coordinates the work. The project manager also ensures that the various stakeholders are kept onside and committed to the project’s success. Good project management frees the development team to concentrate on the difficult technical task of devising and implementing the solution.

Business analysis Business analysis is concerned with investigating the business situation and finding out what are the problems to be solved or opportunities to be exploited. It involves developing holistic solutions to business issues, which very often involve the use of IT in some way. Business analysts are also important for eliciting, documenting and managing the requirements for the new or enhanced IT systems and services.

Systems architecture Systems architects are concerned with developing an architecture for the organisation to support and coordinate its systems and provide a coherent platform for expansion and development.

Programming Although within the span of systems development, this is a specialist area which calls for high levels of technical expertise, not least in how to exploit to the full the possibilities offered by the hardware and software available.

Testing The tester’s role appears at first to be counter-productive in that he or she is trying to prove that the system does not work. This is an iterative process and, when the tester struggles to identify further defects in any version, it can be stated with some confidence that the system appears to be satisfactory. An important point to realise, though, is that no testing, however thorough, can deliver assurance that the software is one hundred per cent error-free.

Configuration As systems have become more complex, it has become even management and more important to know the latest version of the system, thechange control components it is made up of and how these relate to each

other. The discipline of managing these components is known as ‘configuration management’ and it is related to change control, which is a process for managing changes to a system or product in a controlled way.

Quality control and Quality control consists of the processes – for example, reviews quality assurance or code inspections – that are employed within a project team

to ensure that the delivered products meet their defined quality

3


4

criteria. Quality assurance is an external process that ensures that quality control is being exercised; it also puts in place things like standards to assist in quality control.

Service management Service management is concerned with managing and maintaining the services provided by IT systems. It includes, for example, such activities as facilities management – controlling the supporting IT infrastructure – and applications management – supporting and enhancing the applications once they have been delivered initially.

OFFSHORING AND OUTSOURCING OF SYSTEMS DEVELOPMENT

Two changes that have affected many organisations in recent years have been the offshoring and/or outsourcing of systems development work. These two practices are often referred to together but, in fact, they are separate and one does not necessarily imply the other:

y Offshoring involves using development resources in other countries, usually because high-quality resources can be secured for considerably less cost than in the organisation’s home country. For example, India has proved to be a popular place for organisations to establish their development centres because the country’s education system produces a large number of high quality IT graduates. Leading firms such as Tesco and HSBC have large development centres in India. More recently, development resources have also been found in ex-communist European countries, such as the Ukraine and the Baltic states.

y Outsourcing means handing over the development work to specialist IT services firms and consultancies. An outsourcing contract may cover just development work or, often, the supplier takes complete responsibility for the organisation’s IT systems. Cost may be a driver here too, but often the desire to get control of a spiralling IT budget and to transfer responsibility and risk are also important considerations.

Of course, outsourcing and offshoring are sometimes combined, in that the outsourced supplier chooses to perform its development work overseas, for the reasons already mentioned.

In addition to the claimed benefits, there are of course possible downsides to both offshoring and outsourcing, for example:

y Offshoring: there can be delays and communication difficulties associated with working with developers who are a long way away, whose first language is not the same as the customer organisation and whose culture is very different. It could be argued, however, that this just reinforces the need for greater precision in the definition of business requirements, which is a good thing.

y Outsourcing: one of the chief dangers here is that the customer organisation loses direct control of systems that are critical to its business objectives. In addition, knowledge of these key systems now resides in the supplier organisation rather than being retained in-house.


IN THE REST OF THIS BOOK

The chapters that follow explore the elements – the frameworks and models, processes, procedures and techniques – of systems development in more detail, and here we provide a foretaste of what is to come.

Chapter 2: Lifecycle types and their rationales

A lifecycle provides a framework and structure for undertaking systems development. Over the years, different lifecycles have been developed and employed, ranging from the traditional, linear, step-by-step, ‘Waterfall’ approach to the currently-popular ‘Agile’ one. This chapter presents the different lifecycles and assesses their relative strengths and weaknesses.

Chapter 3: Analysing the business need

Before embarking on any system development project, business analysts should examine the real business need and evaluate the options available to meet it. This analysis should also consider the non-IT issues (changes to organisation structures, to business processes and to people’s jobs) that will have to be addressed if the system is to be implemented effectively and provide the expected business benefits.

Chapter 4: Making a business case

The business case is – or should be – an examination of the justification for undertaking a systems development project and a rigorous analysis of the costs, benefits, impacts and risks of the courses of action available. Assuming that the case is made initially, the business case should be revisited throughout the project’s lifecycle to ensure that it has not been invalidated by, for example, rises in costs or changes in the external environment.

Chapter 5: Requirements engineering

If a system is to be delivered that meets the needs of the organisation, it must be based on well-defined requirements – so that the developers know what is to be produced. Requirements engineering provides a framework and techniques for creating high-quality requirements as a basis for the development work.

Chapter 6: Programming and development approaches

A major decision to be made is whether, having defined the requirements, the solution should be built from scratch or whether a commercial, off-the-shelf (COTS) solution should be produced. Assuming that at least some development work is to be undertaken, this chapter reviews the different programming and development methods that could be employed.

Chapter 7: System modelling techniques

Most engineering disciplines make use of models to assist in the conceptualisation and specification of the solution. In the case of systems development, the product can be

5


specified in terms of the functional or processing aspects, the data requirements and the ‘dynamic’ or event-driven view. This chapter presents approaches to modelling from these three perspectives.

Chapters 8 and 9: System design

Design is the stage in the development process where decisions are made about how to meet the defined requirements using the hardware and software available. Both the functions/processing and the data need to be designed, and this often involves making compromises between what would be ideal and what is practical given the technology, time and resources available. These two chapters review the challenges of design and conclude with a discussion of the benefits of using defined design patterns to assist in the process.

Chapter 10: Solution-related architectures

Architecture in IT is similar to architecture in building in that it provides an overall framework and structure for the development of systems. This chapter explains the purpose and approach of architecture, the stakeholders involved and the role of such concepts as Service Oriented Architecture and Service Oriented Development.

Chapter 11: Quality and testing

Systems must not only be developed on time and within budget, but they must also achieve appropriate levels of quality. This chapter defines what is meant by the term ‘quality’ in the IT context and presents methods that can be used to assure software quality.

Chapter 12: Implementation and changeover

The introduction of systems into service is often a very challenging aspect of systems development involving, as it does, moving from manual or older systems to the new ones, training the staff, data conversion and so forth. This chapter reviews these issues and also considers the different approaches to implementation, for example as a ‘big bang’ or in a phased manner.

Chapter 13: Maintenance and evaluation

Surveys have shown that, in most cases, the majority of expenditure on IT systems occurs after they have been introduced into service – to fix problems, make enhancements, adapt to changes in other systems and so on. Although live operation follows systems development, this chapter explains the purpose of evaluation and maintenance and shows how decisions made during the development can assist, or hamper, the longevity of the systems.

Chapter 14: Solution development tools

Systems development can benefit hugely from the development team having at their disposal software support tools to help them do their work. These can range from tools to control the vast amount of documentation that is produced, to aids for the developers,

6


to tools to assist testing. This chapter looks at the pros and cons of software support tools and provides guidance on what to look for in a tool.

FURTHER READING

Cadle, J. and Yeates, D. (2008) Project management for information systems (5th edition). Pearson Prentice Hall, Harlow.

Paul, D., Yeates, D. and Cadle, J. (2014) Business analysis (3rd edition), BCS, Swindon.

Skidmore, S. and Eva, M. (2004) Introducing systems development. Palgrave Macmillan, Basingstoke.

Various authors (2002) Best practice for application management. OGC/TSO, London.

Yeates, D. and Wakefield, T. (2004) Systems analysis and design (2nd edition). FT Prentice Hall, Harlow.

7

INDEX

abstraction, modelling 108, 120–3

classification 120

composition 121–2

generalisation 121

idealisation 122–3

abstraction, OO design 171, 172

acceptance testing see user acceptance testing

access controls 193

activity sampling 67

adaptive maintenance 262

adaptive software development 99

Agile Alliance 97

12 underlying principles 97–8

Agile development approach

adjustment of requirements 77–8

documentation 135

methodologies 26–8, 98–100

testing 238

Agile Unified Process 100

analysis of business needs see business analysis

anti-malware software 193

Application Service Providers (ASPs) 103

architecture 202–3

communication 206–7

contract 214

enterprise 207–10

ISO 42010 definition 202, 203, 223

management 222–4

patterns 203–6

principles 210–11

software 214–20

software tools 272–3

solution 211–14

stakeholders and roles 220–2

‘As-Is’ and ‘To-Be’ models 110

U-curve 110–11

attribute of an object, OO development 101

audit trail 193–4

bar codes 156

Barker Ellis data mode 121

benefits realisation 265, 266

benefits review 44, 265

bespoke solutions 81–2

‘big bang’ implementation 253–4

binary chop 184

black-box elements 123–4

black-box techniques 234–5

black- and white-box testing 125

‘b’ model of systems development 260–1

Boehm, Barry, Spiral model 25–6, 261–2

Box, George 108

break-even/payback analysis 56–7

business analysis 35–46

definition of 38

outcomes from 44–5

place in development lifecycle 38–44

rationale for 37

techniques 68–9

business analysts 63

business case 47–59

cost-benefit analysis 52–3

elements of 50–1

feasibility checking 49–50

impact analysis 56

investment appraisal techniques 56–9

in lifecycle of IT project 47–9

option selection 51–2

purpose of 47

risk analysis 53–6

business feasibility 41, 49

business logic layer 217

business modelling tools 272–3

business objectives 266

business and project risks 54–6

business use cases (BUCs) 129–30

CARE (computer-aided requirements engineering) 273, 276

‘cascade’ training 252–3

CASE (computer-aided software engineering) 92, 272, 276

CAST (computer-aided software testing) 275, 276

change control 76, 270

change elements 44–5

changeover

direct/ ‘big bang’ 253–4

parallel running 254–5

phased 255–6

pilot 255

see also implementation

check digit 177–8

class 170

classification, abstraction 120

class model 171

clerical controls 188–9

297

client-server patterns, architecture 215–18

closed source/shared source software 88

cloud computing 102–3

Cockburn’s use cases 126–8

code design 175–8

faceted codes 176–7

self-checking codes 177–8

sequential numbers 176

cohesion 205

commercial off-the-shelf (COTS) packages 83–7

communication/interoperation patterns 206–7

component-based software architecture 218–20

component-based software development 88–91

component design 168–9

component testing 234

composition, abstraction 121–2

conceptual models 122

configuration management 76, 271

confirmation testing (re-testing) 235

constraints on system design 142–6

context 10, 92–3

contextual models 122

control totals 188

corrective maintenance 262

cost-benefit analysis 52–3

COTS (commercial off-the-shelf solutions) 82

pros and cons of 83–7

coupling 204–5

cross-field validation 188

cross-referencing/linking 131–4, 270–1

CRUD matrix 132–3

Crystal clear 99

cutover see changeover

database management systems (DBMS) 178–86

hierarchical databases 178–9

network databases 179–80

object-oriented databases 182–3

physical files 183–6

relational databases 180–2

data controls 189–90

data conversion 247–8

data design 173–86

code deisgn 175–8

database management systems 178–86

normalisation 174–5

data flow diagrams 116

data input stages 153–5

data interchange, system to system 163

data item, OO development 101

data layer 217

data mapping 246–7

data migration 245–6

data models 122–3, 173–4

data protection legislation 145

DBMS see database management systems

default value 190

define requirements stage, role of business analyst 41–2

deliverables 12, 93

on demand software 102–3

Department of Defence Architecture Framework (DoDAF) 12, 210

design constraints 142–6

organisational constraints 144–6

project constraints 144

technical constraints 144–5

design patterns 196–200

design specification, static testing 231–2

design stage 9

role of business analysts 42–3

design use cases (DUCs) 129–30

developers 64

development (programming) stage 9

approaches 79–81

component-based 88–91

methodologies 92–100


diagrams and models 109–10

pre-UML 115–17

UML 117–20

direct files 186

direct implementation 253–4

discounted cash flow (DCF) method 57–8, 59

document analysis 67

documentation

COTS products 84

requirements 73–6

software generation of 272

support 249–51

using models 134–7

domain architects 220

domain experts 63

domains, architecture 208–9, 211–12

double-keying 187

DSDM (Dynamic Systems Development Method) 29–30, 99

dynamic testing 230

progression through stages 236–7

‘V’ model test stages 233–5

elicitation of requirements 64–7

qualitative techniques 65–6

quantitative techniques 66–7

encapsulation 101, 170

encryption 150, 193

enterprise architects 220

enterprise architecture (EA) 207–10

domains 208–9

frameworks 209–10

strategy vs. tactics 208

entity relationship diagrams (ERDs) 116

ETL (Extract, Transform and Load) 245–6

evaluation 263–7

benefits review 265

metrics for 265–8

post-implementation review 264–5

post-project review 264

of software tools 276–7

event modelling techniques 116–17

evolutionary lifecycle approaches 16, 23–6

iterative development 23–5

maintenance 261–2

Spiral model 25–6

strengths & weaknesses 16–17

existence checks 187

experience-based testing 235

extended ‘V’ model 20, 39, 266

Extreme programming (XP) 99

298

faceted codes 176–7

feasibility checking 49–50

feasibility study 9, 39–41

feature-driven development 99

file access/retrieval mechanisms 185–6

file organisation systems 183–5

sequential file organisation 184–5

serial file organisation 183–4

financial feasibility 41, 49

firewalls 193

focus groups 65

foreign key 181

functional fit 267

functional model map 128–31, 134, 219

functional requirements 68, 139, 140

functional specification, static testing 231

Gamma, Erich, design patterns 196–200

gap analysis 112

generalisation

abstraction 121

OO design 171, 172

general requirements 68

‘good’ requirements, features of 69–71

governance

enterprise architecture 210, 211

solution architecture 214

hardware installation 249

hash totals 189

hierarchical architecture 206

hierarchical client-server 216

hierarchical databases 178–9

hierarchical domain services 212

high-level system design 164–8

coupling and cohesion 168

programming constructs 167

stepwise refinement 166–7

holistic solution 211

hub-and-spoke architecture 206–7

human-computer interfaces

output user interfaces 162–3

user interface (UI) design 152–3

hybrid lifecycle approaches 28–32

IaaS (infrastructure as a service) 102

idealisation, abstraction 122–3

immediate and long-term costs 52–3

impact analysis 56

implementation 9–10, 242–57

data conversion 247–8

data mapping 246–7

documentation supporting 249–51

file and data conversion or creation 245–6

implementation in the lifecycle 242–4

implementation plan 256–7

installation of hardware and infrastructure 249

migration of software modules 248–9

planning for 244–5

role of business analysts 43

system implementation 253–6

training 251–3

Incremental lifecycle 21–3

and systems design 148–9

testing 238

Incremental processes, modelling 135–7

Infrastructure as a service (IaaS) 102

infrastructure installation 249

inheritance, OO design 172

input controls 187–8

input devices/technologies 156–7

input and output (I/O) design 150–63

input design 153–8

output design 158–63


input user-interfaces 157–8

intangible and tangible costs 52, 53, 54

integration testing 234

internal rate of return (IRR) 58, 59

interviews 65

investment appraisal techniques 56–9

iteration 167

iterative development 23–5

place of design 149

IT/IS change 44

Jackson Structured Programming (JSP) 96, 100

Kanban 99

key performance indicators (KPIs) 267

Lean Software Development (LSD) 31–2, 99

license issues 86, 87, 88, 103

lifecycles 8–34

Agile, impact of 26–8

choosing 32–3

evolutionary approach 23–6

hybrid approaches 28–32

linear approach 17–23

system development lifecycle 8–17

linear lifecycle approaches 15, 17–23

Incremental 21–3

strengths & weaknesses 15–16

‘V’ model 19–21

Waterfall 17–19

linking/cross-referencing 131–4, 270–1

links and cross-references 270–1

logical design 194–5

logical models 123

logical security 192–3

long-term and immediate costs 52–3

loose and tight coupling, component architecture 204–5

LSD (Lean Software Development) 31–2

maintenance 258–63

categories 262–3

regression testing 263

in system development lifecycle 258–62

maintenance agreements

COTS products 84

299

malware 193

management, requirements 62, 76–7

managers 63, 221–2

Manifesto for Agile development 97

manuals, operational 250

matrices 132–3

metrics for evaluation of project 265–7

Model Driven Architecture (MDA) 103–4

modelling 107–38

abstraction 120–3

cross-referencing and mapping 131–4

documentation 134–7

layers or levels of models 125–31

limitations 112–13

model element opaqueness 123–5

multiple views 114–15

pre-UML techniques 115–17

rationale 111–14

and traceability 131–2

UML 117–20

value of 113–14

modular architecture 204

module testing 234

MoSCoW prioritisation technique 71–2

multiple models and views 114–15

net present value (NPV) 58

network databases 179–80

non-functional requirements 68, 139, 140

normalisation 174–5

n-tiered software architecture 217–18

object-oriented database management systems (OODBMS) 182–3

object-oriented design 169–72

object-oriented development (OOD) 101

object-relational mapping 182

observations 65

OCR (Optical Character Recognition) 157

off-the-shelf solutions 78, 81, 82

pros and cons of 83–7

offshoring 4

OLAP (OnLine Analytical Processing) 163

OMR (Optical Mark Recognition) 157

online help 250

opaqueness of model elements 123–5

open source software 87–8

operational manuals 250

operations managers 221–2

optimisation 262

organisational constraints on system design 144–6

organisation change 45

output controls 188

output design 158–63

output user interfaces 162–3

output devices/technologies 159–62

outsourcing 4, 222

ownership issues 85–6

PaaS (platform as a service) 102

parallel running 254–5

payback/break-even analysis 56–7

people change 45

perfective maintenance (optimisation) 262

phased implementation 255–6

physical data design 195

physical files, database management 183–6

physical models 123

physical process design 195–6

physical security 192

pilot implementation 255

platform-agnostic (logical) design 194–5

Platform as a service (PaaS) 102

point-to-point architecture 206

policies, architecture 210–11

political constraints 144–5

polymorphism, OO design 171, 172

post-implementation review 264–5

post-implementation review, role of business analysts 43

post-project review 264

pre-numbering 188

pre-UML modelling techniques 115–17

preventative maintenance 263

primary key 181

prioritisation of requirements 71–2

process 11

defined processes 94–6

empirical processes 96–100

process change 44–5

process controls 190–1

process design 163–72

high-level design 164–8

object-oriented design 169–72

unit/component design 168–9

procurement 81

programming constructs 167

programming and development approaches 79–106

build vs. buy 81–8

component-based development 88–91

development approaches 79–81

methodologies 92–100

software engineering paradigms 100–2

technological advances, influence of 102–4

program specifications 168–9

static testing 232

project and business risks 54–6

project constraints 144

project management tools 273

project manager 63

project sponsor 63

prototyping 66

qualitative techniques 65–6

quality 225–8

of a COTS solution 83–4

definition of 227–8

quality triangle 226

of requirements, constraints on design 146

see also testing

quantitative techniques 66–7

questionnaires 66

300

range checks 188

Rapid Application Development (RAD) 97

Rational Unified process (RUP) 31, 136

ready-made solutions

COTS 82–7

Open Source software 87–8

record searching 67

regression testing 235–6, 263

relational databases 180–2

release management 275–6

reliability 267

remotely delivered training 252

requirements catalogue 74–5

requirements engineering 9, 60–78

and Agile development 77–8

analysis of requirements 69–72

business analysis techniques 68–9

definition 60–1


elicitation 64–7

framework for 61–2

management 76–7

and off-the-shelf solutions 78

roles in 62–4

tools 273

validation of requirements 72–3

requirements specification, static testing 231

reviews

evaluative 264–5

static testing 231–3

RFID (Radio Frequency IDentification) 157

risk analysis 53–6

roles 11–12, 93

in architecture 220

requirements engineering 62–4

RUP (Rational Unified process) 31

SaaS (software as a service) 102, 103

scenarios 65–6

Schwaber, Ken 94

scope of design 149–63

scope of solution 213–14

breadth 213

depth 214

focus 213

Scrum 30, 99

SDLC see system development lifecycle

security 270

security and control design 186–94

clerical controls 188–9

data controls 189–90

input controls 187–8

output controls 188

process controls 190–1

security and audit 192–4

selection, programming construct 167

self-checking codes 177–8, 187

sequence, programming construct 167

sequential file organisation 184–5

sequential numbers, code design 176

serial file organisation 183–4

service level agreements (SLAs) 267

service management tools 276

service-oriented analysis 125

service-oriented architecture 207

service-oriented development (SOD) 101–2

shadowing 65

‘shared source’ software 88

SLAs (service level agreements) 267

SOD (service-oriented development) 101–2

software architects 220

software architecture 214–20

component-based 218–20

tiered 215–18

Software as a service (SaaS) 102

software development tools 274–5

software engineering, definition of 80

software engineering paradigms 100–2

software modules migration 248–9

software/system development methodologies (SDMs) 92–100

software tools

business modelling & architecture 272–3

functions and benefits 269–72

project management 273

release management 275–6

requirements engineering 273

service management 276

software development 274–5

system modelling 273–4

testing 275

solution architects 220

solution development tools 269–78

evaluation of 276–7

functions and benefits 269–72

pros and cons of adopting 277

terminology 276

through solution lifecycles 272–6

solution-related architectures 202–24

architecture patterns 203–6

communication patterns 206–7

enterprise architecture 207–10

management 222–4

principles 210–11

roles/stakeholders 220–2

software architecture 211–14

solution architecture 210–11

solution scope 213–14

special-purpose records 67

specification of software components 219

Spiral lifecycle model 25–6, 261–2

sponsor of project 63

spot checks 188

SSADM (Structured Systems Analysis and Design Method) 28–9, 95

SSM (Soft Systems Methodology) 95

stakeholders 145

architecture 221–2

standardisation 270

standards, constraints of 145

Statecharts, event modelling 117

static data model notations 115–16

static testing 230–3

301

stepwise refinement 166–7

storage 270

structured methods 96

structured programming (SP) 96, 100

Structured Systems Analysis and Design Method (SSADM) 28–9, 95

‘super-users’ 252–3

suppliers 222

surveys 66

system development lifecycle (SDLC) 8–34

Agile approaches 26–8

choice of 32–3

elements 10–13

evolutionary approaches 23–6

hybrid approaches 28–32

implementation in 242–4

linear approaches 17–23

maintenance 258–62

meaning of 13–17

position of systems design 146–9

stages of 9–10

system implementation 253–6

system interface layer 217

system lifecycle 14–15

system modelling techniques 107–38

abstraction 120–3

cross-referencing 131–4

documentation and specification 134–7

levels of models and model elements 125–31

modelling 111–14

multiple models and views 114–15

opaqueness of model elements 123–5

pre-UML modelling techniques 115–17

unified modelling language (UML) 117–20

system modelling tools 273–4

systems architecture 3

systems design 139–201

constraints upon 142–6

data design 173–86

design patterns 196–200

in development lifecycle 146–9

logical and physical design 194–6

objective of 139–42

process design 163–72

scope of design 149–63

security and control design 186–94

systems development 1–2

offshoring & outsourcing of 4

and other disciplines 2–4

systems development methodology (SDM) 92–4

defined processes 94–6

empirical process 96–100

system specification, modelling notation 134–6

system to system data interchange 163

system testing 234

system use cases (SUCs) 130–1

‘tailor-made’ (bespoke) solutions 81–2

tangible and intangible costs 52, 53, 54

technical constraints on system design 144–5

technical documentation 250

technical feasibility 41, 49

technical requirements 68

techniques 12–13, 94

technological advances 102–4

technology 80

test-driven development 99

testers 64

testing 9, 228–40

7 principles of 229

components 220

dynamic stages of ‘V’ model 233–5

in the lifecycle 237–9

objectives and limitations 228–31

progression through dynamic stages 236–7

regression 235–6, 263

re-testing 235


static and dynamic 230

static stages of ‘V’ model 231–3

test plans 239–40

tools 275

three-tiered software architecture 216

three-view model of a system 114–15

tiered/layered software architecture 206, 215–18

tight and loose coupling, component architecture 204–5

time value of money 57, 58, 59

touch screen technology 156

traceability 77, 271

training 251–3

COTS software products 84

training needs analysis (TNA) 251

train-the-trainer 252–3

‘try before you buy’ 84–5

two-tier, client-server 215

UAT (user acceptance testing) 43, 234, 236

U-curve process pattern 110–11

Unified Modelling Language (UML) 104, 117–20

events 120

functionality 118–19

static data 119

Unified Process 4 + 1 architecture 136–7

unique identifiers, data design 175, 176

unit/component design 168–9

unit testing 234

usability 267

usability checklist 152–3

use cases 126–7

design scope 127

goal level 127–8

usefulness of models 108–9

user acceptance testing (UAT) 43, 234, 236

‘user-friendly’ checklist 152–3

user guides 250


input UIs 156–7

output UIs 162–3

users 63, 222

user stories 76

validation of input data 187–8

validation of requirements 72–3

verification of input data 187

302

verification of requirements 72–3

version control 76, 270

views/viewpoints 110

visibility, data control 190

visual modelling 271

‘V’ model 19–21

dynamic test stages 233–5

extended ‘V’ model 20, 39, 266

maintenance 260

static test stages 231–3

and systems design 147–8

testing 238

voice recognition 157

Waterfall lifecycle 17–19


maintenance 259

systems design 146–7

testing 238

white-box techniques 235

white-box views 125

workshops 65

XP (Extreme programming) 99

303

9781780172453 developing information systems - bcsshop.bcs.org/resources/pdf/9781780172453.pdf ·...

Documents