700-word proposal memo (double-spaced and in APA format) $10 (No plagiarism)

yuvi123

JosephS.ValacichJoeyF.George-ModernSystemsAnalysisandDesign-Pearson2020.pdf

Home >Computer Science homework help >700-word proposal memo (double-spaced and in APA format) $10 (No plagiarism)

GLOBAL EDITION

GLOBAL EDITION GLO

B A

L E D

IT IO

This is a special edition of an established title widely used by colleges and universities throughout the world. Pearson published this exclusive edition for the benefit of students outside the United States and Canada. If you purchased this book within the United States or Canada, you should be aware that it has been imported without the approval of the Publisher or Author.

Modern Systems Analysis and Design presents the skills, techniques, tools, and perspectives that students need to successfully develop information systems. Its expansive coverage of tools and systems development methodologies is structured along the systems development life cycle, providing students with a strong conceptual and systematic framework.

Central to the book’s approach is the theme that systems development is a practical field and a profession, always rooted in an organizational basis. Focusing on the role, responsibilities, and mind-set of the systems analyst and the systems project manager, the coverage also encompasses skills such as systems documentation, project management, team management, and a variety of systems development and acquisition strategies.

The ninth edition also includes the following features to prepare students for the modern systems development environment.

• NEW—This edition’s expanded coverage includes a new section on Scrum and an updated section on information systems security.

• UPDATED—Screen captures familiarize students with the latest versions of programming environments, Internet development environments, and user interface designs.

• Three illustrative cases, each spread across several chapters, illustrate key aspects of systems development and bring chapter concepts to life.

• UPDATED—Review Questions and Problems and Exercises test students’ understanding, and Field Exercises help them explore systems analysis and design in organizations.

Modern Systems Analysis and Design

M o dern System

s A nalysis and D

esign V alacich • G

eo rge

N IN

T H

E D

IT IO

NINTH EDITION

Joseph S. Valacich Joey F. George

CVR_VALA1629_09_GE_CVR.indd 1 08/04/20 5:58 PM

Modern Systems Analysis and Design Joseph S. Valacich University of Arizona

Joey F. George Iowa State University

N I N T H

E D I T I O N

G L O B A L

E D I T I O N

Harlow, England • London • New York • Boston • San Francisco • Toronto • Sydney • Dubai • Singapore • Hong Kong Tokyo • Seoul • Taipei • New Delhi • Cape Town • São Paulo • Mexico City • Madrid • Amsterdam • Munich • Paris • Milan

A01_VALA1629_09_GE_FM.indd 1 15/04/2020 11:21

Please contact https://support.pearson.com/getsupport/s/contactsupport with any queries on this content.

Microsoft and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published as part of the services for any purpose. All such documents and related graphics are provided “as is” without warranty of any kind. Microsoft and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all warranties and conditions of merchantability, whether express, implied or statutory, fitness for a particular purpose, title and non-infringement. In no event shall Microsoft and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from the services.

The documents and related graphics contained herein could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Microsoft and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time. Partial screen shots may be viewed in full within the software version specified.

Microsoft® and Windows® are registered trademarks of the Microsoft Corporation in the U.S.A. and other countries. This book is not sponsored or endorsed by or affiliated with the Microsoft Corporation.

Pearson Education Limited KAO Two KAO Park Hockham Way Harlow Essex CM17 9SR United Kingdom

and Associated Companies throughout the world

Visit us on the World Wide Web at: www.pearsonglobaleditions.com

The rights of Joseph S. Valacich and Joey F. George to be identified as the authors of this work have been asserted by them in accordance with the Copyright, Designs and Patents Act 1988.

Authorized adaptation from the United States edition, entitled Modern Systems Analysis and Design, 9th Edition, ISBN 978-0-13-517275-9 by Joseph S. Valacich and Joey F. George, published by Pearson Education © 2020.

Acknowledgments of third-party content appear on the appropriate page within the text.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a license permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, Saffron House, 6–10 Kirby Street, London EC1N 8TS.

All trademarks used herein are the property of their respective owners. The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners. For information regarding permissions, request forms, and the appropriate contacts within the Pearson Education Global Rights and Permissions department, please visit www.pearsoned.com/permissions/.

This eBook is a standalone product and may or may not include all assets that were part of the print version. It also does not provide access to other Pearson digital products like MyLab and Mastering. The publisher reserves the right to remove any material in this eBook at any time.

ISBN 10: 1-292-35162-4 ISBN 13: 978-1-292-35162-9 eBook ISBN 13: 978-1-292-35163-6

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library

Cover image: Ashalatha/Shutterstock eBook formatted by SPi Global

A01_VALA1629_09_GE_FM_CR_page.indd 2 20/04/2020 21:44

https://support.pearson.com/getsupport/s/contactsupport

http://www.pearsonglobaleditions.com

http://www.pearsoned.com/permissions/

To my mother, Mary Valacich. You are the best! —Joe

To my parents, John and Loree George. —Joey

A01_VALA1629_09_GE_FM.indd 3 15/04/2020 11:21

This page intentionally left blank

A01_THOM6233_05_SE_WALK.indd 9 1/13/17 6:50 PM

Preface 19

PART ONE Foundations for Systems Development 25

1 The Systems Development Environment 27 2 The Origins of Software 47 3 Managing the Information Systems Project 64

Appendix: Object-Oriented Analysis and Design: Project Management 98

PART TWO Planning 107

4 Identifying and Selecting Systems Development Projects 109 5 Initiating and Planning Systems Development Projects 133

PART THREE Analysis 167

6 Determining System Requirements 169 7 Structuring System Process Requirements 203

Appendix 7A: Object-Oriented Analysis and Design: Use Cases 237

Appendix 7B: Object-Oriented Analysis and Design: Activity Diagrams 252

Appendix 7C: Business Process Modeling 257

8 Structuring System Data Requirements 266 Appendix: Object-Oriented Analysis and Design: Object Modeling–Class

Diagrams 301

PART FOUR Design 319

9 Designing Databases 321 10 Designing Forms and Reports 363 11 Designing Interfaces and Dialogues 391 12 Designing Distributed and Internet Systems 427

PART FIVE Implementation and Maintenance 461

13 System Implementation 463 14 Maintaining Information Systems 495

GLOSSARY OF TERMS 513

GLOSSARY OF ACRONYMS 520

INDEX 521

Brief Contents

A01_VALA1629_09_GE_FM.indd 5 15/04/2020 11:21

This page intentionally left blank

A01_THOM6233_05_SE_WALK.indd 9 1/13/17 6:50 PM

Preface 19

PART ONE Foundations for Systems Development

AN OVERVIEW OF PART ONE 26

1 The Systems Development Environment 27 Learning Objectives 27

Introduction 27

A Modern Approach to Systems Analysis and Design 29

Developing Information Systems and the Systems Development Life Cycle 30

The Heart of the Systems Development Process 35 The Traditional Waterfall SDLC 36

Agile Methodologies 38 eXtreme Programming 39 Scrum 40 Agile in Practice 41

Object-Oriented Analysis and Design 42

Our Approach to Systems Development 44

Summary 45

Key Terms 45

Review Questions 45

Problems and Exercises 46

Field Exercises 46

References 46

2 The Origins of Software 47 Learning Objectives 47

Introduction 47

Systems Acquisition 47 Outsourcing 48 Sources of Software 49 Choosing Off-the-Shelf Software 55 Validating Purchased Software Information 57

Reuse 58

Summary 60

Key Terms 61

Review Questions 61

Contents

A01_VALA1629_09_GE_FM.indd 7 15/04/2020 11:21

8 CONTENTS

Problems and Exercises 61

Field Exercises 61

References 62

BEC CASE: THE ORIGINS OF SOFTWARE 63 Case Questions 63

3 Managing the Information Systems Project 64 Learning Objectives 64

Introduction 64

Pine Valley Furniture Company Background 64

Managing the Information Systems Project 66 Initiating a Project 70 Planning the Project 72 Executing the Project 79 Closing Down the Project 82

Representing and Scheduling Project Plans 83 Representing Project Plans 85 Calculating Expected Time Durations Using PERT 85 Constructing a Gantt Chart and Network Diagram at Pine Valley Furniture 86

Using Project Management Software 89 Establishing a Project Start Date 90 Entering Tasks and Assigning Task Relationships 90 Selecting a Scheduling Method to Review Project Reports 91

Summary 93

Key Terms 93

Review Questions 94

Problems and Exercises 94

Field Exercises 96

References 96

Appendix: Object-Oriented Analysis and Design: Project Management 98 Learning Objectives 98 Unique Characteristics of an OOSAD Project 98 Define the System as a Set of Components 98

Complete Hard Problems First 98 Using Iterations to Manage the Project 100 Don’t Plan Too Much Up Front 100 How Many and How Long Are Iterations? 102 Project Activity Focus Changes Over the Life of a Project 102

Summary 104

Review Question 104

Problems and Exercises 104

BEC CASE: MANAGING THE INFORMATION SYSTEMS PROJECT 105 Case Questions 105

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 8 15/04/2020 11:21

CONTENTS 9

PART TWO Planning

AN OVERVIEW OF PART TWO 108

4 Identifying and Selecting Systems Development Projects 109 Learning Objectives 109

Introduction 109

Identifying and Selecting Systems Development Projects 110 The Process of Identifying and Selecting IS Development Projects 111 Deliverables and Outcomes 115

Corporate and Information Systems Planning 116 Corporate Strategic Planning 117 Information Systems Planning 119

Electronic Commerce Applications: Identifying and Selecting Systems Development Projects 126

Internet Basics 126 Pine Valley Furniture WebStore 127

Summary 128

Key Terms 128

Review Questions 129

Problems and Exercises 129

Field Exercises 130

References 130

BEC CASE: IDENTIFYING AND SELECTING SYSTEMS DEVELOPMENT PROJECTS 132 Case Questions 132

5 Initiating and Planning Systems Development Projects 133 Learning Objectives 133

Introduction 133

Initiating and Planning Systems Development Projects 133

The Process of Initiating and Planning is Development Projects 134 Deliverables and Outcomes 135

Assessing Project Feasibility 136 Assessing Economic Feasibility 137 Assessing Technical Feasibility 145 Assessing Other Feasibility Concerns 148

Building and Reviewing the Baseline Project Plan 149 Building the Baseline Project Plan 149 Reviewing the Baseline Project Plan 154

Electronic Commerce Applications: Initiating and Planning Systems Development Projects 159 Initiating and Planning Systems Development Projects for Pine Valley Furniture’s WebStore 159

Summary 161

Key Terms 161

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 9 15/04/2020 11:21

10 CONTENTS

Review Questions 162

Problems and Exercises 162

Field Exercises 163

References 163

BEC CASE: INITIATING AND PLANNING SYSTEMS DEVELOPMENT PROJECTS 165 Case Questions 165

PART THREE Analysis

AN OVERVIEW OF PART THREE 168

6 Determining System Requirements 169 Learning Objectives 169

Introduction 169

Performing Requirements Determination 169 The Process of Determining Requirements 170 Deliverables and Outcomes 171

Traditional Methods for Determining Requirements 172 Interviewing and Listening 172 Interviewing Groups 176 Directly Observing Users 177 Analyzing Procedures and Other Documents 178

Contemporary Methods for Determining System Requirements 183

Joint Application Design 184 Using Prototyping During Requirements Determination 186

Radical Methods for Determining System Requirements 188 Identifying Processes to Reengineer 189 Disruptive Technologies 190

Requirements Determination Using Agile Methodologies 191 Continual User Involvement 191 Agile Usage-Centered Design 192 The Planning Game from eXtreme Programming 192

Electronic Commerce Applications: Determining System Requirements 194

Determining System Requirements for Pine Valley Furniture’s WebStore 195

Summary 197

Key Terms 198

Review Questions 198

Problems and Exercises 199

Field Exercises 199

References 200

BEC CASE: DETERMINING SYSTEM REQUIREMENTS 201 Case Questions 202

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 10 15/04/2020 11:21

CONTENTS 11

7 Structuring System Process Requirements 203 Learning Objectives 203

Introduction 203

Process Modeling 203 Modeling a System’s Process for Structured Analysis 204 Deliverables and Outcomes 204

Data Flow Diagramming Mechanics 205 Definitions and Symbols 205 Developing DFDs: An Example 207 Data Flow Diagramming Rules 210 Decomposition of DFDs 211 Balancing DFDs 214

An Example DFD 216

Using Data Flow Diagramming in the Analysis Process 219 Guidelines for Drawing DFDs 219 Using DFDs as Analysis Tools 221 Using DFDs in Business Process Reengineering 222

Modeling Logic with Decision Tables 223

Electronic Commerce Application: Process Modeling Using Data Flow Diagrams 227 Process Modeling for Pine Valley Furniture’s WebStore 227

Summary 229

Key Terms 229

Review Questions 230

Problems and Exercises 230

Field Exercises 236

References 236

Appendix 7A: Object-Oriented Analysis and Design: Use Cases 237 Learning Objectives 237 Introduction 237 Use Cases 237

What Is a Use Case? 237 Use Case Diagrams 238 Definitions and Symbols 239

Written Use Cases 242 Level 243 The Rest of the Template 243

Electronic Commerce Application: Process Modeling Using Use Cases 245 Writing Use Cases for Pine Valley Furniture’s WebStore 247

Summary 250

Key Terms 250

Review Questions 250

Problems and Exercises 250

Field Exercise 251

References 251

Hoosier Burger

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 11 15/04/2020 11:21

12 CONTENTS

Appendix 7B: Object-Oriented Analysis and Design: Activity Diagrams 252 Learning Objectives 252 Introduction 252 When to Use an Activity Diagram 255 Problems and Exercises 255 Reference 256

Appendix 7C: Business Process Modeling 257 Learning Objective 257 Introduction 257 Basic Notation 257 Business Process Example 261 Summary 262 Key Terms 262 Review Questions 262 Problems and Exercises 262 Field Exercises 263 References 263

BEC CASE: STRUCTURING SYSTEM PROCESS REQUIREMENTS 264 Case Questions 265

8 Structuring System Data Requirements 266 Learning Objectives 266

Introduction 266

Conceptual Data Modeling 267 The Conceptual Data Modeling Process 268 Deliverables and Outcomes 269

Gathering Information for Conceptual Data Modeling 270

Introduction to E-R Modeling 272 Entities 272 Attributes 274 Candidate Keys and Identifiers 275 Other Attribute Types 276 Relationships 277

Conceptual Data Modeling and the E-R Model 278 Degree of a Relationship 279 Cardinalities in Relationships 281 Naming and Defining Relationships 282 Associative Entities 283 Summary of Conceptual Data Modeling with E-R Diagrams 285

Representing Supertypes and Subtypes 285

Business Rules 286 Domains 287 Triggering Operations 289

A01_VALA1629_09_GE_FM.indd 12 15/04/2020 11:21

CONTENTS 13

Role of Packaged Conceptual Data Models: Database Patterns 290 Universal Data Models 290 Industry-Specific Data Models 290 Benefits of Database Patterns and Packaged Data Models 290

Electronic Commerce Application: Conceptual Data Modeling 291 Conceptual Data Modeling for Pine Valley Furniture’s WebStore 291

Summary 295

Key Terms 295

Review Questions 296

Problems and Exercises 297

Field Exercises 299

References 300

Appendix: Object-Oriented Analysis and Design: Object Modeling—Class Diagrams 301 Learning Objectives 301 Introduction 301 Representing Objects and Classes 301 Types of Operations 302 Representing Associations 303 Representing Associative Classes 305 Representing Stereotypes for Attributes 306 Representing Generalization 306 Representing Aggregation 309 An Example of Conceptual Data Modeling at Hoosier Burger 310

Summary 313

Key Terms 313

Review Questions 314

Problems and Exercises 314

References 315

BEC CASE: STRUCTURING SYSTEM DATA REQUIREMENTS 316 Case Questions 317

PART FOUR Design

AN OVERVIEW OF PART FOUR 320

9 Designing Databases 321 Learning Objectives 321

Introduction 321

Database Design 321 The Process of Database Design 322 Deliverables and Outcomes 324 The Relational Database Model 327 Well-Structured Relations 327

PINE VALLEY FURNITURE

Hoosier Burger

A01_VALA1629_09_GE_FM.indd 13 15/04/2020 11:21

14 CONTENTS

Normalization 328 Rules of Normalization 329 Functional Dependence and Primary Keys 329 Second Normal Form 330 Third Normal Form 330

Transforming E-R Diagrams into Relations 331 Represent Entities 332 Represent Relationships 332 Summary of Transforming E-R Diagrams to Relations 336

Merging Relations 336 An Example of Merging Relations 336 View Integration Problems 337

Logical Database Design for Hoosier Burger 338

Physical File and Database Design 341 Designing Fields 341 Choosing Data Types 342 Controlling Data Integrity 343 Designing Physical Tables 344 Arranging Table Rows 347 Designing Controls for Files 351

Physical Database Design for Hoosier Burger 352

Electronic Commerce Application: Designing Databases 353 Designing Databases for Pine Valley Furniture’s WebStore 354

Summary 356

Key Terms 357

Review Questions 358

Problems and Exercises 358

Field Exercises 359

References 360

BEC CASE: DESIGNING DATABASES 361 Case Questions 362

10 Designing Forms and Reports 363 Learning Objectives 363

Introduction 363

Designing Forms and Reports 363 The Process of Designing Forms and Reports 365 Deliverables and Outcomes 366

Formatting Forms and Reports 370 General Formatting Guidelines 370 Highlighting Information 372 Color versus No Color 374 Displaying Text 375 Designing Tables and Lists 375 Paper versus Electronic Reports 379

Hoosier Burger

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 14 15/04/2020 11:21

CONTENTS 15

Assessing Usability 381 Usability Success Factors 381 Measures of Usability 382

Electronic Commerce Applications: Designing Forms and Reports for Pine Valley Furniture’s WebStore 383

General Guidelines 383 Designing Forms and Reports at Pine Valley Furniture 383 Lightweight Graphics 384 Forms and Data Integrity Rules 384 Stylesheet-Based HTML 385

Summary 385

Key Terms 385

Review Questions 386

Problems and Exercises 386

Field Exercises 387

References 387

BEC CASE: DESIGNING FORMS AND REPORTS 389 Case Questions 389

11 Designing Interfaces and Dialogues 391 Learning Objectives 391

Introduction 391

Designing Interfaces and Dialogues 391 The Process of Designing Interfaces and Dialogues 391 Deliverables and Outcomes 392

Interaction Methods and Devices 392 Methods of Interacting 392 Hardware Options for System Interaction 400

Designing Interfaces 402 Designing Layouts 402 Structuring Data Entry 405 Controlling Data Input 407 Providing Feedback 408 Providing Help 410

Designing Dialogues 412 Designing the Dialogue Sequence 413 Building Prototypes and Assessing Usability 415

Designing Interfaces and Dialogues in Graphical Environments 417 Graphical Interface Design Issues 417 Dialogue Design Issues in a Graphical Environment 419

Electronic Commerce Application: Designing Interfaces and Dialogues for Pine Valley Furniture’s WebStore 419

General Guidelines 420 Designing Interfaces and Dialogues at Pine Valley Furniture 421 Menu-Driven Navigation with Cookie Crumbs 421

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 15 15/04/2020 11:21

16 CONTENTS

Summary 422

Key Terms 422

Review Questions 423

Problems and Exercises 423

Field Exercises 424

References 424

BEC CASE: DESIGNING INTERFACES AND DIALOGUES 425 Case Questions 426

12 Designing Distributed and Internet Systems 427 Learning Objectives 427

Introduction 427

Designing Distributed and Internet Systems 427 The Process of Designing Distributed and Internet Systems 427 Deliverables and Outcomes 428

Designing LAN and Client/Server Systems 429 Designing Systems for LANs 429 Designing Systems for a Client/Server Architecture 431

Cloud Computing 435 What Is Cloud Computing? 435 Managing the Cloud 439 Service-Oriented Architecture 442 Web Services 443

Designing Internet Systems 444 Internet Design Fundamentals 445 Site Consistency 446 Design Issues Related to Site Management 448

Electronic Commerce Application: Designing a Distributed Advertisement Server for Pine Valley Furniture’s WebStore 451

Advertising on Pine Valley Furniture’s WebStore 451 Designing the Advertising Component 452 Designing the Management Reporting Component 453

Summary 454

Key Terms 454

Review Questions 456

Problems and Exercises 456

Field Exercises 457

References 458

BEC CASE: DESIGNING DISTRIBUTED AND INTERNET SYSTEMS 459 Case Questions 459

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 16 15/04/2020 11:21

CONTENTS 17

PART FIVE Implementation and Maintenance

AN OVERVIEW OF PART FIVE 462

13 System Implementation 463 Learning Objectives 463

Introduction 463

System Implementation 464 Coding, Testing, and Installation Processes 465 Deliverables and Outcomes from Coding, Testing, and Installation 465 Deliverables and Outcomes from Documenting the System, Training Users, and Supporting

Users 466

Software Application Testing 467 Seven Different Types of Tests 468 The Testing Process 470 Combining Coding and Testing 472 Acceptance Testing by Users 473

Installation 474 Direct Installation 474 Parallel Installation 474 Single-Location Installation 475 Phased Installation 476 Planning Installation 476

Documenting the System 477 User Documentation 478

Training and Supporting Users 479 Training Information Systems Users 480 Supporting Information Systems Users 481

Organizational Issues in Systems Implementation 482 Why Implementation Sometimes Fails 483 Security Issues 485

Electronic Commerce Application: System Implementation and Operation for Pine Valley Furniture’s WebStore 487

Developing Test Cases for the WebStore 487 Alpha and Beta Testing the WebStore 488 WebStore Installation 489

Project Closedown 489

Summary 490

Key Terms 490

Review Questions 491

Problems and Exercises 492

Field Exercises 492

References 493

BEC CASE: SYSTEM IMPLEMENTATION 494 Case Questions 494

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 17 15/04/2020 11:21

18 CONTENTS

14 Maintaining Information Systems 495 Learning Objectives 495

Introduction 495

Maintaining Information Systems 495 The Process of Maintaining Information Systems 496 Deliverables and Outcomes 497

Conducting Systems Maintenance 498 Types of Maintenance 498 The Cost of Maintenance 499 Managing Maintenance 501 Role of Automated Development Tools in Maintenance 506

Website Maintenance 506

Electronic Commerce Application: Maintaining an Information System for Pine Valley Furniture’s WebStore 508

Maintaining Pine Valley Furniture’s WebStore 508 Cannot Find Server 508

Summary 509

Key Terms 510

Review Questions 510

Problems and Exercises 511

Field Exercises 511

References 511

GLOSSARY OF TERMS 513

GLOSSARY OF ACRONYMS 520

INDEX 521

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 18 15/04/2020 11:21

Preface DESCRIPTION Modern Systems Analysis and Design, Ninth Edition, covers the concepts, skills, meth- odologies, techniques, tools, and perspectives essential for systems analysts to suc- cessfully develop information systems. The primary target audience is upper-division undergraduates in a management information systems (MIS) or computer informa- tion systems curriculum; a secondary target audience is MIS majors in MBA and MS programs. Although not explicitly written for the junior college and professional de- velopment markets, this book can also be used by these programs.

We have over 60 years of combined teaching experience in systems analysis and design and have used that experience to create this newest edition of Modern Systems Analysis and Design. We provide a clear presentation of the concepts, skills, and tech- niques that students need to become effective systems analysts who work with others to create information systems for businesses. We use the systems development life cycle (SDLC) model as an organizing tool throughout the book to provide students with a strong conceptual and systematic framework. The SDLC in this edition has five phases and a circular design.

With this text, we assume that students have taken an introductory course on computer systems and have experience designing programs in at least one program- ming language. We review basic system principles for those students who have not been exposed to the material on which systems development methods are based. We also assume that students have a solid background in computing literacy and a general understanding of the core elements of a business, including basic terms as- sociated with the production, marketing, finance, and accounting functions.

NEW TO THE NINTH EDITION The following features are new to the Ninth Edition:

• New material. To keep up with the changing environment for systems develop- ment, Chapter 1 has undergone a thorough revision, with a renewed focus on agile methodologies. While the book has long included material on eXtreme Programming, we now also include a section on Scrum.

• Updated content. Throughout the book, the content in each chapter has been updated where appropriate. We have expanded our coverage of multiple topics in Chapter 2. Another example of an updated chapter is Chapter 13, where we have updated and extended the section on information systems security. Chapter 13 also includes new examples of systems implementation failure. All screenshots come from current versions of leading software prod- ucts. We have also made a special effort to update our reference lists, purging out-of-date material and including current references. Throughout the book figures, tables, and related content have been updated and refreshed.

• Dropped material. In our efforts to keep the book current and to streamline it, the coverage of some things was dropped from this edition. Chapters 1, 6 and 7 no longer include computer assisted systems engineering (CASE) tools. We also made some changes in the appendices to Chapter 7. We deleted the appendix on UML sequential diagrams. Appendix 7A is still about use cases,

A01_VALA1629_09_GE_FM.indd 19 15/04/2020 11:21

20 PREFACE

and Appendix 7B is still about activity diagrams, but Appendix 7C is now about Business Process Management Notation.

• Organization. We have retained the organization of the book first introduced in the Sixth Edition, with the only change being the deletion of the former Appendix 7C. We have 14 chapters and 5 appendices. The first appendix fol- lows Chapter 1. Three appendices follow Chapter 7. The fifth appendix follows Chapter 8. This streamlined organization worked well in the Sixth, Seventh and Eighth Editions, so we decided to continue with it and improve on it.

• Approach to presentation of object-oriented material. We generally retain our approach to object-orientation (OO) from the last edition. Brief appendices related to the object-oriented approach continue to appear immediately after related chapters. The OO appendices appear as follows: Chapter 3 features a special OO section on IS project management. Chapter 7 now has two OO appendices: one on use cases and one about activity diagrams. (The third appendix to Chapter 7 is about Business Process Management Notation, which is not part of UML, although it is governed by the Object Management Group (OMG).) Chapter 8 has a special section on object-oriented database design. The rationale for this organization is the same as in the past: to cleanly separate out structured and object-oriented approaches so that instructors not teaching OO can bypass it. On the other hand, instructors who want to expose their students to object-orientation can now do so with minimal effort devoted to finding the relevant OO material.

• Updated illustrations of technology. Screen captures have been updated through- out the text to show examples using the latest versions of programming and Internet development environments (including the latest versions of .NET, Visio, and Microsoft Office) and user interface designs. Many references to Websites are provided for students to stay current with technology trends that affect the analysis and design of information systems.

Themes of Modern Systems Analysis and Design

1. Systems development is firmly rooted in an organizational context. The suc- cessful systems analyst requires a broad understanding of organizations, orga- nizational culture, and organizational operations.

2. Systems development is a practical field. Coverage of current practices as well as accepted concepts and principles is essential in a textbook.

3. Systems development is a profession. Standards of practice, a sense of con- tinuing personal development, ethics, and a respect for and collaboration with the work of others are general themes in the textbook.

4. Systems development has significantly changed with the explosive growth in databases, data-driven systems architectures, the Internet, and agile method- ologies. Systems development and database management can be and should be taught in a highly coordinated fashion. The text is compatible with the Hoffer, Ramesh, and Topi database text, Modern Database Management, Thir- teenth Edition, also published by Pearson. The proper linking of these two textbooks is a strategic opportunity to meet the needs of the IS academic field.

5. Success in systems analysis and design requires not only skills in methodolo- gies and techniques, but also project management skills for managing time, resources, and risks. Thus, learning systems analysis and design requires a thorough understanding of the process as well as the techniques and deliver- ables of the profession.

A01_VALA1629_09_GE_FM.indd 20 15/04/2020 11:21

PREFACE 21

Given these themes, this textbook emphasizes the following:

• A business, rather than a technology, perspective;

• The role, responsibilities, and mind-set of the systems analyst as well as the systems project manager, rather than those of the programmer or business manager; and

• The methods and principles of systems development, rather than the spe- cific tools or tool-related skills of the field.

DISTINCTIVE FEATURES The following are some of the distinctive features of Modern Systems Analysis and Design:

1. This book is organized in parallel to the Hoffer, Ramesh, and Topi database text, Modern Database Management, Thirteenth Edition (2019), which will fa- cilitate consistency of frameworks, definitions, methods, examples, and no- tations to better support systems analysis and design and database courses adopting both texts. Even with the strategic compatibilities between this text and Modern Database Management, each of these books is designed to stand alone as a market leader.

2. The grounding of systems development in the typical architecture for systems in modern organizations, including database management and Web-based systems.

3. A clear linkage of all dimensions of systems description and modeling— process, decision, and data modeling—into a comprehensive and compatible set of systems analysis and design approaches. Such a broad coverage is nec- essary so that students understand the advanced capabilities of the many sys- tems development methodologies and tools that are automatically generating a large percentage of code from design specifications.

4. Extensive coverage of oral and written communication skills, including systems documentation, project management, team management, and a va- riety of systems development and acquisition strategies (e.g., life cycle, pro- totyping, object orientation, Joint Application Development [ JAD], systems re- engineering, and agile methodologies).

5. Consideration of standards for the methodologies of systems analysis and the platforms on which systems are designed.

6. Discussion of systems development and implementation within the context of change management, conversion strategies, and organizational factors in systems acceptance.

7. Careful attention to human factors in systems design that emphasize usability in both character-based and graphical user interface situations.

8. Visual development products are illustrated and the current limitations tech- nologies are highlighted.

9. The text includes a separate chapter on systems maintenance. Given the type of job many graduates first accept and the large installed base of systems, this chapter covers an important and often neglected topic in systems analysis and design texts.

PEDAGOGICAL FEATURES The pedagogical features of Modern Systems Analysis and Design reinforce and apply the key content of the book.

A01_VALA1629_09_GE_FM.indd 21 15/04/2020 11:21

22 PREFACE

Three Illustrative Fictional Cases The text features three fictional cases, described in the following text.

Pine Valley Furniture (PVF): In addition to demonstrating an electronic business- to-consumer shopping Website, several other systems development activities from PVF are used to illustrate key points. PVF is introduced in Chapter 3 and revisited throughout the book. As key systems development life cycle concepts are presented, they are applied and illustrated with this descriptive case. For example, in Chapter 5 we explore how PVF plans a development project for a customer tracking system. A margin icon identifies the location of the case segments.

Hoosier Burger (HB): This second illustrative case is introduced in Chapter 7 and revisited throughout the book. HB is a fictional fast-food restaurant in Bloomington, Indiana. We use this case to illustrate how analysts would develop and implement an auto- mated food-ordering system. A margin icon identifies the location of the case segments.

Petrie Electronics: This fictional retail electronics company is used as an extended project case at the end of 12 of the 14 chapters, beginning with Chapter 2. Designed to bring the chapter concepts to life, this case illustrates how a company initiates, plans, models, designs, and implements a customer loyalty system. Discussion ques- tions are included to promote critical thinking and class participation. Suggested solutions to the discussion questions are provided in the Instructor’s Manual.

End-of-Chapter Material We developed an extensive selection of end-of-chapter materials that are designed to accommodate various learning and teaching styles.

• Chapter Summary. Reviews the major topics of the chapter and previews the connection of the current chapter with future ones.

• Key Terms. Designed as a self-test feature, students match each key term in the chapter with a definition.

• Review Questions. Test students’ understanding of key concepts.

• Problems and Exercises. Test students’ analytical skills and require them to apply key concepts.

• Field Exercises. Give students the opportunity to explore the practice of systems analysis and design in organizations.

• Margin Term Definitions. Each key term and its definition appear in the margin. Glossaries of terms and acronyms appear at the back of the book.

• References. References are located at the end of each chapter. The total number of references in this text amounts to over 100 books, journals, and Websites that can provide students and faculty with additional coverage of topics.

USING THIS TEXT As stated earlier, this book is intended for mainstream systems analysis and design courses. It may be used in a one-semester course on systems analysis and design or over two quarters (first in a systems analysis and then in a systems design course). Because this book text parallels Modern Database Management, chapters from this book and from Modern Database Management can be used in various sequences suit- able for your curriculum. The book will be adopted typically in business schools or departments, not in computer science programs. Applied computer science or com- puter technology programs may also adopt the book.

The typical faculty member who will find this book most interesting is someone who

• has a practical, rather than technical or theoretical, orientation;

• has an understanding of databases and the systems that use databases; and

• uses practical projects and exercises in their courses.

Hoosier Burger

PINE VALLEY FURNITURE

A01_VALA1629_09_GE_FM.indd 22 15/04/2020 11:21

PREFACE 23

More specifically, academic programs that are trying to better relate their sys- tems analysis and design and database courses as part of a comprehensive under- standing of systems development will be especially attracted to this book.

The outline of the book generally follows the systems development life cycle, which allows for a logical progression of topics; however, it emphasizes that vari- ous approaches (e.g., prototyping and iterative development) are also used, so what appears to be a logical progression often is a more cyclic process. Part One provides an overview of systems development and previews the remainder of the book. Part One also introduces students to the many sources of software that they can draw on to build their systems and to manage projects. The remaining four parts provide thorough coverage of the five phases of a generic systems develop- ment life cycle, interspersing coverage of alternatives to the SDLC as appropriate. Some chapters may be skipped depending on the orientation of the instructor or the students’ background. For example, Chapter 3 (Managing the Information Systems Project) can be skipped or quickly reviewed if students have completed a course on project management. Chapter 4 (Identifying and Selecting Systems Development Projects) can be skipped if the instructor wants to emphasize sys- tems development once projects are identified or if there are fewer than 15 weeks available for the course. Chapters 8 (Structuring System Data Requirements) and 9 (Designing Databases) can be skipped or quickly scanned (as a refresher) if stu- dents have already had a thorough coverage of these topics in a previous database or data structures course. The sections on object orientation in Chapters 3, 7, and 8 can be skipped if faculty wish to avoid object-oriented topics. Finally, Chapter 14 (Maintaining Information Systems) can be skipped if these topics are beyond the scope of your course.

Because the material is presented within the flow of a systems development project, it is not recommended that you attempt to use the chapters out of sequence, with a few exceptions: Chapter 9 (Designing Databases) can be taught after Chapters 10 (Designing Forms and Reports) and 11 (Designing Inferfaces and Dialogues), but Chapters 10 and 11 should be taught in sequence.

THE SUPPLEMENT PACKAGE: HTTP://WWW.PEARSONGLOBALEDITIONS.COM A comprehensive and flexible technology support package is available to enhance the teaching and learning experience. All instructor supplements are available on the text Website: http://www.pearsonglobaleditions.com.

Instructor Resources At the Instructor Resource Center, www.pearsonglobaleditions.com, instructors can easily register to gain access to a variety of instructor resources available with this text in downloadable format. If assistance is needed, our dedicated technical support team is ready to help with the media supplements that accompany this text. Visit http://support.pearson.com/getsupport for answers to frequently asked questions and toll-free user support phone numbers.

The following supplements are available with this text:

• Instructor’s Manual

• Test Bank

• TestGen® Computerized Test Bank

• PowerPoint Presentation

A01_VALA1629_09_GE_FM.indd 23 15/04/2020 11:21

HTTP://WWW.PEARSONGLOBALEDITIONS.COM

http://www.pearsonglobaleditions.com

http://support.pearson.com/getsupport

24 PREFACE

ACKNOWLEDGMENTS The authors have been blessed by considerable assistance from many people on all aspects of preparation of this text and its supplements. We are, of course, respon- sible for what eventually appears between the covers, but the insights, corrections, contributions, and prodding of others have greatly improved our manuscript. Over the years, dozens of people have reviewed the various editions of this textbook. Their contributions have stimulated us, frequently prompting us to include new topics and innovative pedagogy. We greatly appreciate the efforts of the many faculty and prac- ticing systems analysts who have reviewed this text.

We extend a special note of thanks to Jeremy Alexander, who was instrumental in conceptualizing and writing the PVF WebStore feature that appears in Chapters 4 through 14. The addition of this feature has helped make those chapters more mod- ern and innovative.

We also wish to thank Atish Sinha of the University of Wisconsin–Milwaukee for writing the original version of some of the object-oriented analysis and design material. Dr. Sinha, who has been teaching this topic for several years to both under- graduates and MBA students, executed a challenging assignment with creativity and cooperation.

We are also indebted to our undergraduate and MBA students, who have given us many helpful comments as they worked with drafts of this text, and our thanks go to Fred McFadden (University of Colorado, Colorado Springs), Mary Prescott (University of South Florida), Ramesh Venkataraman (Indiana University), and Heikki Topi (Bentley University) for their assistance in coordinating this text with its companion book, Modern Database Management, also by Pearson Education.

Finally, we have been fortunate to work with a large number of creative and insightful people at Pearson, who have added much to the development, format, and production of this text. We have been thoroughly impressed with their commitment to this text and to the IS education market. These people include: Samantha Lewis (Executive Portfolio Manager), Madeline Houpt (Portfolio Management Assistant), Faraz Sharique Ali (Content Producer) at Pearson, and Freddie Domini and Sindhuja Vadlamani (Full-Service Project Management) at Pearson CSC.

The writing of this text has involved thousands of hours of time from the au- thors and from all of the people listed previously. Although our names will be visibly associated with this book, we know that much of the credit goes to the individuals and organizations listed here for any success it might achieve. It is important for the reader to recognize all the individuals and organizations that have been committed to the preparation and production of this book.

Joseph S. Valacich, Tucson, Arizona Joey F. George, Ames, Iowa

GLOBAL EDITION ACKNOWLEDGMENTS Pearson would like to thank the following people for their work on the Global Edition:

Contributors Sahil Raj, Punjabi University

Reviewers Muhammad Shakaib Akram, University of Essex Nash Milic, American University of Sharjah Upasana Singh, University of KwaZulu-Natal Petter Terenius, Lancaster University and University of Borås Yuen Yee Yen, Multimedia University

A01_VALA1629_09_GE_FM.indd 24 15/04/2020 11:21

Chapter 1 The Systems Development Environment

Chapter 2 The Origins of Software

Foundations for Systems Development

Chapter 3 Managing the Information Systems Project

PA RT O N E

M01A_VALA1629_09_GE_P01.indd 25 08/04/2020 16:33

You are beginning a journey that will enable you to build on every aspect of your education and experience. Becoming a systems analyst is not a goal; it is a path to a rich and diverse career that will allow you to exercise and continue to develop a wide range of talents. We hope that this introductory part of the text helps open your mind to the opportunities of the systems analysis and design field and to the engaging nature of systems work.

Chapter 1 shows you what systems analysis and design is all about and how it has evolved over the past several decades. As businesses and systems have become more sophisticated and more complex, there has been an increasing emphasis on speed in systems analysis and design. Systems development began as an art, but most businesspeople soon realized this was not a tenable long- term solution to developing systems to support business processes. Systems development became more structured and more like engineering, and managers stressed the importance of planning, project management, and docu- mentation. The focus of systems analysis and design has shifted to agile development. The evolution of systems analysis and design and the current focus on agility are explained in Chapter 1. It is also important, however, that you remember that systems analysis and design exists within a multifaceted organizational context that involves other organizational members and external parties. Understanding systems development requires an under- standing not only of each technique, tool, and method, but also of how these elements complement and support each other within an organizational setting.

As you read this book, you’ll also discover that the systems analysis and design field is constantly adapting to new situations due to a strong commitment to constant improvement. Our goal in this book is to provide you with a mosaic of the skills needed to work effectively in any environment where you may find yourself, armed with

OVERVIEW

the knowledge to determine the best practices for that situation and argue for them effectively.

Chapter 2 presents an introduction to the many sources from which software and software components can be obtained. Back when systems analysis and design was an art, all systems were written from scratch by in-house experts. Businesses had little choice. Now in-house devel- opment is much rarer, so it becomes crucial that systems analysts understand the software industry and the many different sources of software. Chapter 2 provides an initial map of the software industry landscape and explains most of the many choices available to systems analysts.

Chapter 3 addresses a fundamental characteristic of life as a systems analyst: working within the framework of projects with constrained resources. All systems-related work demands attention to deadlines, working within bud- gets, and coordinating the work of various people. The very nature of the systems development life cycle (SDLC) implies a systematic approach to a project, which is a group of related activities leading to a final deliverable. Projects must be planned, started, executed, and completed. The planned work of the project must be represented so that all interested parties can review and understand it. In your job as a systems analyst, you will have to work within the schedule and other project plans, and thus it is important to understand the management process controlling your work.

Finally, Part I introduces the Petrie Electronics case. The Petrie case helps demonstrate how what you learn in each chapter might fit into a practical organizational situa- tion. The case begins after Chapter 2; the remaining book chapters through Chapter 13 each have an associated case installment. The first section introduces the company and its existing information systems. This introduction provides insights into Petrie, which will help you understand the company more completely when we look at the require- ments and design for new systems in later case sections.

PART ONE

Foundations for Systems Development

M01A_VALA1629_09_GE_P01.indd 26 08/04/2020 16:33

connecting organizations with their partners and their customers. The overwhelming majority of business use of the Web is business-to-business applications. These applica- tions run the gamut of everything businesses do, including transmitting orders and payments to suppliers, fulfilling orders and collecting payments from customers, maintain- ing business relationships, and establishing electronic mar- ketplaces where businesses can shop online for the best deals on resources they need for assembling their prod- ucts and services. Regardless of the technology involved, understanding the business and how it functions is the key to successful systems analysis and design, even in the fast- paced, technology-driven environment that organizations find themselves in today.

With the challenges and opportunities of dealing with rapid advances in technology, it is difficult to imagine a more exciting career choice than information technology (IT), and systems analysis and design is a big part of the IT landscape. Furthermore, analyzing and designing informa- tion systems will give you the chance to understand organi- zations at a depth and breadth that might take many more years to accomplish in other careers.

An important (but not the only) result of systems anal- ysis and design is application software, software designed to support a specific organizational function or process, such as inventory management, payroll, or market analysis. In addition to application software, the total information sys- tem includes the hardware and systems software on which the application software runs, documentation and training materials, the specific job roles associated with the overall system, controls, and the people who use the software along with their work methods. Although we will address all of

The world runs on information systems. Information sys- tems form the foundation for every major organizational activity and industry, from retail to healthcare to manufac- turing to logistics. Systems consist of computer hardware, software, networks, and the people who oversee their oper- ation and the people who use them. Information systems analysis and design is the complex, challenging, and stimulating organizational process that a team of business and systems professionals uses to develop and maintain information systems. Although advances in information technology continually give us new capabilities, the analy- sis and design of information systems is driven from an organizational perspective. An organization might consist of a whole enterprise, specific departments, or individual work groups. Organizations can respond to and antici- pate problems and opportunities through innovative use of information technology. Information systems analysis and design is therefore an organizational improvement process. Systems are built and rebuilt for organizational benefits. Benefits result from adding value during the pro- cess of creating, producing, and supporting the organiza- tion’s products and services. Thus the analysis and design of information systems is based on your understanding of the organization’s objectives, structure, and processes, as well as your knowledge of how to exploit information technology for advantage.

Information systems support almost everything organizations do, whether the systems are developed for internal use, for exchanges with business partners, or for interactions with customers. Networks, especially the Internet—especially the World Wide Web—are crucial for

1.3 describe the agile methodologies, eXtreme Pro- gramming, and Scrum; and

1.4 explain object-oriented analysis and design and the Rational Unified Process (RUP).

Learning Objectives After studying this chapter, you should be able to

1.1 define information systems analysis and design;

1.2 describe the information systems development life cycle (SDLC);

The Systems Development Environment1

Introduction

M01B_VALA1629_09_GE_C01.indd 27 08/04/2020 16:33

28 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

you begin your career in systems development, you will most likely begin as a systems analyst or as a business analyst. The primary role of a systems analyst is to study the problems and needs of an organization in order to determine how people, methods, and information technology can best be combined to bring about improvements in the organization. A systems analyst helps system users and other business managers define their requirements for new or enhanced information services. As such, a sys- tems analyst is an agent of change and innovation.

In the rest of this chapter, we will examine the systems approach to analysis and design. You will learn how systems analysis and design has changed over the decades as computing has become more central to business. You will learn about the systems development life cycle, which provides the basic overall structure of the systems devel- opment process and of this book. This chapter ends with a discussion of some of the methodologies, techniques, and tools created to support the systems development process. We consider both the structured and the agile approaches to systems analysis and design.

A MODERN APPROACH TO SYSTEMS ANALYSIS AND DESIGN The analysis and design of computer-based information systems began in the 1950s. Since then, the development environment has changed dramatically, driven by orga- nizational needs as well as by rapid changes in the technological capabilities of com- puters. In the 1950s, development focused on the processes the software performed. Because computer power was a critical resource, efficiency of processing became the main goal. Computers were large, expensive, and not very reliable. Emphasis was placed on automating existing processes, such as purchasing or payroll, often within single departments. All applications had to be developed in machine language or assembly language, and they had to be developed from scratch because there was no software industry. Because computers were so expensive, computer memory was also at a premium, so system developers conserved as much memory as possible for data storage.

The first procedural, or third-generation, computer programming languages did not become available until the beginning of the 1960s. Computers were still large and expensive, but the 1960s saw important breakthroughs in technology that enabled the development of smaller, faster, less expensive computers—minicomputers—and the beginnings of the software industry. Most organizations still developed their applica- tions from scratch using their in-house development staff. Systems development was more an art than a science. This view of systems development began to change in the 1970s, however, as organizations started to realize how expensive it was to develop customized information systems for every application. Systems development came to be more disciplined as many people worked to make it more like engineering. Early database management systems, using hierarchical and network models, helped bring discipline to the storage and retrieval of data. The development of database manage- ment systems helped shift the focus of systems development from processes first to data first.

The 1980s were marked by major breakthroughs in computing in organizations, as microcomputers became key organizational tools. The software industry expanded greatly as more and more people began to write off-the-shelf software for microcom- puters. Developers began to write more and more applications in fourth-generation languages, which, unlike procedural languages, instructed a computer on what to do instead of how to do it. Computer-aided software engineering (CASE) tools were developed to make systems developers’ work easier and more consistent. As computers continued to get smaller, faster, and cheaper, and as the operating systems for comput- ers moved away from line prompt interfaces to windows- and icon-based interfaces, organizations moved to applications with more graphics. Organizations developed

Systems analyst The organizational role most respon- sible for the analysis and design of infor- mation systems.

these various dimensions of the overall system, we will emphasize application software development—your primary responsibility as a systems analyst.

In the early years of computing, analysis and design was considered an art or a craft. Rapid growth in the need for systems in the 1970s resulted in a highly structured approach to systems analysis and design. While the structured approach is still in use, current approaches focus on rapid and constant software delivery, managed by small teams of talented developers. This approach, called agile development, has become standard for most organizations that develop systems. In fact, 94% of companies report that they practice agile in their systems development efforts (VersionOne, 2017). Our goal is to help you develop the knowledge and skills needed to understand and follow structured and agile processes. Central to analysis and design (and to this book) are various methodologies, techniques, and tools that have been developed, tested, and widely used over the years to assist people like you during systems analysis and design.

Methodologies are comprehensive, multiple-step approaches to systems develop- ment that will guide your work and influence the quality of your final product—the information system. A methodology adopted by an organization will be consistent with its general management style (e.g., an organization’s orientation toward consensus management will influence its choice of systems development methodology). Most methodologies incorporate several development techniques.

Techniques are particular processes that you, as an analyst, will follow to help ensure that your work is well thought out, complete, and comprehensible to others on your project team. Techniques provide support for a wide range of tasks, includ- ing gathering information to determine what your system should do, planning and managing the activities in a systems development project, diagramming the system’s logic, and designing the system’s interface and outputs.

Tools are typically computer programs that make it easy to use and benefit from techniques and to faithfully follow the guidelines of the overall development method- ology. To be effective, techniques and tools must both be consistent with an organiza- tion’s systems development methodology. Techniques and tools must make it easy for systems developers to conduct the steps called for in the methodology. These three elements—methodologies, techniques, and tools—work together to form an organi- zational approach to systems analysis and design (see Figure 1-1).

Although many people in organizations are responsible for systems analysis and design, in most organizations the systems analyst has the primary responsibility. When

Application software Computer software designed to support organizational functions or processes.

FIGURE 1-1 An organizational approach to systems analysis and design is driven by method- ologies, techniques, and tools.

(Sources: Top: Monkey Business Images/Shutterstock; Left: Benchart/ Shutterstock; Right: Lifestyle Graphic/ Shutterstock)

Methodologies Tools

Techniques

Information systems analysis and design The complex organizational process whereby computer-based information systems are developed and maintained.

M01B_VALA1629_09_GE_C01.indd 28 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 29

Systems analyst The organizational role most respon- sible for the analysis and design of infor- mation systems.

M01B_VALA1629_09_GE_C01.indd 29 08/04/2020 16:33

30 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

less software in-house and bought relatively more from software vendors. The systems developer’s job went through a transition from builder to integrator.

The systems development environment of the late 1990s focused on systems integration. Developers used visual programming environments, such as Visual Basic, to design the user interfaces for systems that run on client/server platforms. The data- base, which may be relational or object-oriented, and which may have been developed using software from firms such as Oracle, resided on the server. In many cases, the application logic resided on the same server. Alternatively, an organization may have decided to purchase its entire enterprise-wide system from companies such as SAP AG or Oracle. Enterprise-wide systems are large, complex systems that consist of a series of independent system modules. Developers assemble systems by choosing and implementing specific modules. Starting in the middle years of the 1990s, more and more systems development efforts focused on the Internet, especially the Web.

Today there is continued focus on developing systems for the Internet and for firms’ intranets and extranets. More and more, systems implementation involves a three-tier design, with the database on one server, the application on a second server, and client logic located on user machines. Another important development is the move to wireless system components. Wireless devices can access Web-based applications from almost anywhere. Finally, the trend continues toward assembling systems from programs and components purchased off the shelf. In many cases, organizations do not develop the application in-house. They don’t even run the application in-house, choos- ing instead to use the application on a per-use basis by accessing it through the cloud.

DEVELOPING INFORMATION SYSTEMS AND THE SYSTEMS DEVELOPMENT LIFE CYCLE Whether they rely on structured or agile approaches, or on a hybrid, most organizations find it beneficial to use a standard set of steps, called a systems development methodology, to develop and support their information systems. Like many processes, the development of information systems often follows a life cycle. For example, a commercial product fol- lows a life cycle in that it is created, tested, and introduced to the market. Its sales increase, peak, and decline. Finally, the product is removed from the market and replaced by something else. The systems development life cycle (SDLC) is a common methodology for systems development in many organizations; it features several phases that mark the progress of the systems analysis and design effort. Every text book author and information systems development organization uses a slightly different life-cycle model, with anywhere from 3 to almost 20 identifiable phases.

The life cycle can be thought of as a circular process in which the end of the useful life of one system leads to the beginning of another project that will develop a new version or replace an existing system altogether (see Figure 1-2). At first glance, the life cycle appears to be a sequentially ordered set of phases, but it is not. The specific steps and their sequence are meant to be adapted as required for a project, consistent with management approaches. For example, in any given SDLC phase, the project can return to an earlier phase if necessary. Similarly, if a commercial product does not perform well just after its introduction, it may be temporarily removed from the market and improved before being reintroduced. In the SDLC, it is also possible to complete some activities in one phase in parallel with some activities of another phase. Sometimes the life cycle is iterative; that is, phases are repeated as required until an acceptable system is found. Some people consider the life cycle to be a spiral, in which we constantly cycle through the phases at different levels of detail (see Figure 1-3). However conceived, the systems development life cycle used in an orga- nization is an orderly set of activities conducted and planned for each development project. The skills required of a systems analyst apply to all life-cycle models. Software is the most obvious end product of the life cycle; other essential outputs include docu- mentation about the system and how it was developed, as well as training for users.

Systems development methodology A standard process followed in an orga- nization to conduct all the steps neces- sary to analyze, design, implement, and maintain information systems.

Systems development life cycle (SDLC) The traditional methodology used to develop, maintain, and replace informa- tion systems.

M01B_VALA1629_09_GE_C01.indd 30 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 31

Every medium-to-large corporation and every custom software producer will have its own specific life cycle or systems development methodology in place (see Figure 1-4). Even if a particular methodology does not look like a cycle, and Figure 1-4 does not, you will probably discover that many of the SDLC steps are performed and SDLC techniques and tools are used. Learning about systems analysis and design from the life-cycle approach will serve you well no matter which systems development methodology you use.

When you begin your first job, you will likely spend several weeks or months learning your organization’s SDLC and its associated methodologies, techniques, and tools. In order to make this book as general as possible, we follow a generic life-cycle model, as described in more detail in Figure 1-5. Notice that our model is circular. We use this SDLC as one example of a methodology but, more important, as a way to arrange the topics of systems analysis and design. Thus, what you learn in this book, you can apply to almost any life cycle you might follow, regardless of the approach it is based on. As we describe this SDLC throughout the book, you will see that each phase has specific outcomes and deliverables that feed important information to other phases. At the end of each phase, a systems development project reaches a milestone and, as deliverables are produced, they are often reviewed by parties outside the proj- ect team. In the rest of this section, we provide a brief overview of each SDLC phase. At the end of the section, we summarize this discussion in a table that lists the main deliverables or outputs from each SDLC phase.

FIGURE 1-2 Systems development life cycle

DesignImplementation

Planning

Maintenance Analysis

FIGURE 1-3 Evolutionary model

Design Implementation

Planning

Maintenance

Go/No Go Axis

Analysis

M01B_VALA1629_09_GE_C01.indd 31 08/04/2020 16:33

32 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

The first phase in the SDLC is planning. In this phase, someone identifies the need for a new or enhanced system. In larger organizations, this recognition may be part of a corporate and systems planning process. Information needs of the organiza- tion as a whole are examined, and projects to meet these needs are proactively identi- fied. The organization’s information system needs may result from requests to deal with problems in current procedures, from the desire to perform additional tasks, or

Planning The first phase of the SDLC in which an organization’s total information system needs are identified, analyzed, prioritized, and arranged.

FIGURE 1-4 U.S. Department of Justice’s systems development life cycle

(Source: Diagram based on http://www .justice.gov/archive/jmd/irm/lifecycle/ch1 .htm#para1.2

Top to bottom: Haveseen/Shutterstock; Phovoir/Shutterstock; Bedrin/ Shutterstock; Pressmaster/Shutterstock; Tiago Jorge da Silva Estima/ Shutterstock; Sozaijiten /Pearson Education; DDekk/Shutterstock; Rtguest/Shutterstock; Michaeljung/ Shutterstock; AleksaStudio/ Shutterstock)

Disposition

Operation and Maintenance

Implementation

Integration and Test

Development

Design

Requirements Analysis

Planning

System Concept Development

Initiation

FIGURE 1-5 SDLC-based guide to this book

DesignImplementation

Chapters 9–12Chapter 13

Planning

Chapters 4–5

MaintenanceChapter 14 Analysis Chapters 6–8

M01B_VALA1629_09_GE_C01.indd 32 08/04/2020 16:33

http://www.justice.gov/archive/jmd/irm/lifecycle/ch1.htm#para1.2

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 33

from the realization that information technology could be used to capitalize on an existing opportunity. These needs can then be prioritized and translated into a plan for the information systems department, including a schedule for developing new major systems. In smaller organizations (as well as in large ones), determination of which systems to develop may be affected by ad hoc user requests submitted as the need for new or enhanced systems arises, as well as from a formalized information planning process. In either case, during project identification and selection, an orga- nization determines whether resources should be devoted to the development or enhancement of each information system under consideration. The outcome of the project identification and selection process is a determination of which systems devel- opment projects should be undertaken by the organization, at least in terms of an initial study.

Two additional major activities are also performed during the planning phase: the formal, yet still preliminary, investigation of the system problem or opportunity at hand, and the presentation of reasons why the system should or should not be devel- oped by the organization. A critical step at this point is determining the scope of the proposed system. The project leader and initial team of systems analysts also produce a specific plan for the proposed project the team will follow using the remaining SDLC steps. This baseline project plan customizes the standardized SDLC and specifies the time and resources needed for its execution. The formal definition of a project is based on the likelihood that the organization’s information systems department is able to develop a system that will solve the problem or exploit the opportunity and determine whether the costs of developing the system outweigh the benefits it could provide. The final presentation of the business case for proceeding with the subse- quent project phases is usually made by the project leader and other team members to someone in management or to a special management committee with the job of deciding which projects the organization will undertake.

The second phase in the SDLC is analysis. During this phase, the analyst thor- oughly studies the organization’s current procedures and the information systems used to perform organizational tasks. Analysis has two subphases. The first is require- ments determination. In this subphase, analysts work with users to determine what the users want from a proposed system. The requirements determination process usually involves a careful study of any current systems, manual and computerized, that might be replaced or enhanced as part of the project. In the second part of analysis, analysts study the requirements and structure them according to their interrelationships and eliminate any redundancies. The output of the analysis phase is a description of (but not a detailed design for) the alternative solution recommended by the analysis team. Once the recommendation is accepted by those with funding authority, the analysts can begin to make plans to acquire any hardware and system software necessary to build or operate the system as proposed.

The third phase in the SDLC is design. During design, analysts convert the description of the recommended alternative solution into logical and then physical system specifications. Analysts aid in the design of all aspects of the system, from input and output screens to reports, databases, and computer processes. That part of the design process that is independent of any specific hardware or software platform is referred to as logical design. Theoretically, the system could be implemented on any hardware and systems software. The idea is to make sure that the system functions as intended. Logical design concentrates on the business aspects of the system and tends to be oriented to a high level of specificity.

In a traditional structured approach, once the overall high-level design of the system is worked out, the analysts begin turning logical specifications into physical ones. This process is referred to as physical design. As part of physical design, analysts design the various parts of the system to perform the physical operations necessary to facilitate data capture, processing, and information output. This can be done in many ways, from creating a working model of the system to be implemented to writing detailed specifica- tions describing all the different parts of the system and how they should be built. In

Analysis The second phase of the SDLC in which system requirements are studied and structured.

Design The third phase of the SDLC in which the description of the recommended solution is converted into logical and then physical system specifications.

Logical design The part of the design phase of the SDLC in which all functional features of the system chosen for development in analysis are described independently of any computer platform.

Physical design The part of the design phase of the SDLC in which the logical specifications of the system from logical design are transformed into technology-specific details from which all programming and system construction can be accomplished.

M01B_VALA1629_09_GE_C01.indd 33 08/04/2020 16:33

34 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

many cases, the working model becomes the basis for the actual system to be used. During physical design, the analyst team must determine many of the physical details necessary to build the final system, from the programming language the system will be written in, to the database system that will store the data, to the hardware platform on which the system will run. Often the choices of language, database, and platform are already decided by the organization or by the client, and at this point these information technologies must be taken into account in the physical design of the system. In a structured approach, the final product of the design phase is the physical system speci- fications in a form ready to be turned over to programmers and other system builders for construction. In an agile approach, which you will read more about in the following sections, logical and physical design become part of the same iterative process, and detailed specifications are replaced with multiple working releases of the software.

The fourth phase in the SDLC is implementation. In a structured process, the physical system specifications, whether in the form of a detailed model or as detailed written specifications, are turned over to programmers as the first part of the imple- mentation phase. During implementation, analysts turn system specifications into a working system that is tested and then put into use. Implementation includes coding, testing, and installation. During coding, programmers write the programs that make up the system. During testing, programmers and analysts test individual programs and the entire system in order to find and correct errors. Following an agile approach, programs are tested as soon as they are written, leading to functional software in a short period of time. During installation, the new system becomes part of the daily activities of the organization. Application software is installed, or loaded, on existing or new hardware, and users are introduced to the new system and trained. Testing and installation should be planned for as early as the project initiation and planning phase; both testing and installation require extensive analysis in order to develop exactly the right approach.

Implementation activities also include initial user support such as the finaliza- tion of documentation, training programs, and ongoing user assistance. Note that documentation and training programs are finalized during implementation; docu- mentation is produced throughout the life cycle, and training (and education) occurs from the inception of a project. Implementation can continue for as long as the system exists because ongoing user support is also part of implementation. Despite the best efforts of analysts, managers, and programmers, however, installation is not always a simple process. Many well-designed systems have failed because the installation pro- cess was faulty. Even a well-designed system can fail if implementation is not well man- aged. Because the project team usually manages implementation, we stress implementation issues throughout this book.

The fifth and final phase in the SDLC is maintenance. When a system (includ- ing its training, documentation, and support) is operating in an organization, users sometimes find problems with how it works and often think of better ways to perform its functions. Also, the organization’s needs with respect to the system change over time. In maintenance, programmers make the changes that users ask for and modify the system to reflect evolving business conditions. These changes are necessary to keep the system running and useful. In a sense, maintenance is not a separate phase but a repetition of the other life-cycle phases required to study and implement the needed changes. One might think of maintenance as an overlay on the life cycle rather than as a separate phase. The amount of time and effort devoted to maintenance depends a great deal on the performance of the previous phases of the life cycle. There inevi- tably comes a time, however, when an information system is no longer performing as desired, when maintenance costs become prohibitive, or when an organization’s needs have changed substantially. Such problems indicate that it is time to begin designing the system’s replacement, thereby completing the loop and starting the life cycle over again. Often the distinction between major maintenance and new development is not clear, which is another reason maintenance often resembles the life cycle itself.

The SDLC is a highly linked set of phases whose products feed the activities in subsequent phases. Table 1-1 summarizes the outputs or products of each phase based

Implementation The fourth phase of the SDLC, in which the information system is coded, tested, installed, and supported in the organization.

Maintenance The final phase of the SDLC, in which an information system is systematically repaired and improved.

M01B_VALA1629_09_GE_C01.indd 34 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 35

on the in-text descriptions. The chapters on the SDLC phases will elaborate on the products of each phase as well as on how the products are developed.

Throughout the SDLC, the systems development project itself must be carefully planned and managed. The larger the systems project, the greater the need for project management. Several project management techniques have been developed over the past decades, and many have been made more useful through automation. Chapter 3 contains a more detailed treatment of project planning and management techniques. Next, we will discuss some of the criticisms of the SDLC and present alternatives devel- oped to address those criticisms.

THE HEART OF THE SYSTEMS DEVELOPMENT PROCESS The SDLC provides a convenient way to think about the processes involved in systems development and the organization of this book. The different phases are clearly defined, their relationships to one another are well specified, and the sequencing of phases from one to the next, from beginning to end, has a compel- ling logic. In many ways, though, the SDLC is fiction. Although almost all systems development projects adhere to some type of life cycle, the exact location of activi- ties and the specific sequencing of steps can vary greatly from one project to the next. Current practice combines the activities traditionally thought of as belonging to analysis, design, and implementation into a single process. Instead of systems requirements being produced in analysis, systems specifications being created in design, and coding and testing being done at the beginning of implementation, current practice combines all of these activities into a single analysis–design–code– test process (Figure 1-6). These activities are the heart of systems development, as we suggest in Figure 1-7. This combination of activities is typical of current prac- tices in agile methodologies. Two well-known instances of agile methodologies are eXtreme Programming and Scrum, although there are other variations. We will introduce you to agile, eXtreme Programming, and Scrum, but first it is important that you learn about the problems with the traditional SDLC. You will read about these problems next. Then you will read about the agile approach, eXtreme Pro- gramming, and Scrum.

Phase Products, Outputs, or Deliverables

Planning Priorities for systems and projects; an architecture for data, networks, and selection hardware, and information systems management are the result of associated systems

Detailed steps, or work plan, for project Specification of system scope and planning and high-level system require-

ments or features Assignment of team members and other resources System justification or business case

Analysis Description of current system and where problems or opportunities exist, with a general recommendation on how to fix, enhance, or replace cur- rent system

Explanation of alternative systems and justification for chosen alternative Design Functional, detailed specifications of all system elements (data, processes,

inputs, and outputs) Technical, detailed specifications of all system elements (programs, files,

network, system software, etc.) Acquisition plan for new technology

Implementation Code, documentation, training procedures, and support capabilities Maintenance New versions or releases of software with associated updates to documen-

tation, training, and support

TABLE 1-1 Products of SDLC Phases

M01B_VALA1629_09_GE_C01.indd 35 08/04/2020 16:33

36 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

The Traditional Waterfall SDLC

There are several criticisms of the traditional life-cycle approach to systems develop- ment; one relates to the way the life cycle is organized. To better understand these criticisms, it is best to see the form in which the life cycle has traditionally been por- trayed, the so-called waterfall (Figure 1-8). Note how the flow of the project begins in the planning phase and from there runs “downhill” to each subsequent phase, just like a stream that runs off a cliff. Although the original developer of the waterfall model, W. W. Royce, called for feedback between phases in the waterfall, this feedback came to be ignored in implementation (Martin, 1999). It became too tempting to ignore the need for feedback and to treat each phase as complete unto itself, never to be revisited once finished.

Traditionally, one phase ended and another began once a milestone had been reached. The milestone usually took the form of some deliverable or prespecified output from the phase. For example, the design deliverable is the set of detailed

FIGURE 1-6 Analysis–design–code–test loop

Code

Analysis

DesignTest

FIGURE 1-7 Heart of systems development

DesignImplementation

Planning

Maintenance Analysis

M01B_VALA1629_09_GE_C01.indd 36 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 37

physical design specifications. Once the milestone had been reached and the new phase initiated, it became difficult to go back. Even though business conditions con- tinued to change during the development process and analysts were pressured by users and others to alter the design to match changing conditions, it was necessary for the analysts to freeze the design at a particular point and go forward. The enor- mous amount of effort and time necessary to implement a specific design meant that it would be very expensive to make changes in a system once it was developed. The traditional waterfall life cycle, then, had the property of locking users into require- ments that had been previously determined, even though those requirements might have changed.

Yet another criticism of the traditional waterfall SDLC is that the role of system users or customers was narrowly defined (Kay, 2002). User roles were often rel- egated to the requirements determination or analysis phases of the project, where it was assumed that all of the requirements could be specified in advance. Such an assumption, coupled with limited user involvement, reinforced the tendency of the waterfall model to lock in requirements too early, even after business conditions had changed.

In addition, under the traditional waterfall approach, nebulous and intangible processes such as analysis and design are given hard-and-fast dates for completion, and success is overwhelmingly measured by whether those dates are met. The focus on milestone deadlines, instead of on obtaining and interpreting feedback from the development process, leads to too little focus on doing good analysis and design. The focus on deadlines leads to systems that do not match users’ needs and that require extensive maintenance, unnecessarily increasing development costs. Finding and fix- ing a software problem after the delivery of the system is often far more expensive than finding and fixing it during analysis and design (Griss, 2003). The result of focusing on deadlines rather than on good practice is unnecessary rework and maintenance effort, both of which are expensive. According to some estimates, maintenance costs account for 40 to 70 percent of systems development costs (Dorfman and Thayer, 1997). Given these problems, people working in systems development began to look for better ways to conduct systems analysis and design.

FIGURE 1-8 Traditional waterfall SDLC

Maintenance

Planning

Analysis

Physical Design

Implementation

Logical Design

M01B_VALA1629_09_GE_C01.indd 37 08/04/2020 16:33

38 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

AGILE METHODOLOGIES Many approaches to systems analysis and design have been developed over the years. In February 2001, many of the proponents of these alternative approaches met in Utah (U.S.) and reached a consensus on several of the underlying principles their various approaches contained. This consensus turned into a document they called “The Agile Manifesto” (Table 1-2). According to Fowler (2003), the agile methodologies share three key principles: (1) a focus on adaptive rather than predictive methodologies, (2) a focus on people rather than roles, and (3) a focus on self-adaptive processes.

The agile methodologies group argues that software development method- ologies adapted from engineering generally do not fit with real-world software development (Fowler, 2003). In engineering disciplines, such as civil engineering, requirements tend to be well understood. Once the creative and difficult work of design is completed, construction becomes very predictable. In addition, construction may account for as much as 90 percent of the total project effort. For software, on the other hand, requirements are rarely well understood, and they change continually during the lifetime of the project. Construction may account for as little as 15 percent of the total project effort, with design constituting as much as 50 percent. Applying techniques that work well for predictable, stable projects, such as bridge building, tend

The Manifesto for Agile Software Development

Seventeen anarchists agree: We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value: ❍❍ Individuals and interactions over processes and tools. ❍❍ Working software over comprehensive documentation. ❍❍ Customer collaboration over contract negotiation. ❍❍ Responding to change over following a plan.

That is, while we value the items on the right, we value the items on the left more. We follow the following principles:

❍❍ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

❍❍ Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

❍❍ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

❍❍ Businesspeople and developers work together daily throughout the project. ❍❍ Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

❍❍ The most efficient and effective method of conveying information to and within a develop- ment team is face-to-face conversation.

❍❍ Working software is the primary measure of progress. ❍❍ Continuous attention to technical excellence and good design enhances agility. ❍❍ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

❍❍ Simplicity—the art of maximizing the amount of work not done—is essential. ❍❍ The best architectures, requirements, and designs emerge from self-organizing teams. ❍❍ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

—Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas (www.agileAlliance.org)

TABLE 1-2 The Agile Manifesto

M01B_VALA1629_09_GE_C01.indd 38 08/04/2020 16:33

http://www.agileAlliance.org

http://agilemanifesto.org/

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 39

not to work well for fluid, design-heavy projects such as writing software, say the agile methodology proponents. What is needed are methodologies that embrace change and that are able to deal with a lack of predictability. One mechanism for dealing with a lack of predictability, which all agile methodologies share, is iterative development (Martin, 1999). Iterative development focuses on the frequent production of working versions of a system that have a subset of the total number of required features. Itera- tive development provides feedback to customers and developers alike.

The agile methodologies’ focus on people is an emphasis on individuals rather than on the roles that people perform (Fowler, 2003). The roles that people fill, of sys- tems analyst or tester or manager, are not as important as the individuals who fill those roles. Fowler argues that the application of engineering principles to systems develop- ment has resulted in a view of people as interchangeable units instead of a view of people as talented individuals, each bringing something unique to the development team.

The agile methodologies promote a self-adaptive software development pro- cess. As software is developed, the process used to develop it should be refined and improved. Development teams can do this through a review process, often associated with the completion of iterations. The implication is that, as processes are adapted, one would not expect to find a single monolithic methodology within a given corpora- tion or enterprise. Instead, one would find many variations of the methodology, each of which reflects the particular talents and experience of the team using it.

Agile methodologies are not for every project. Fowler (2003) recommends an agile or adaptive process if your project involves

• unpredictable or dynamic requirements, • responsible and motivated developers, and • customers who understand the process and will get involved.

A more engineering-oriented, predictable process may be called for if the devel- opment team exceeds 100 people or if the project is operating under a fixed-price or fixed-scope contract. In fact, whether a systems development project is organized in terms of agile or more traditional methodologies depends on many different con- siderations. If a project is considered to be high-risk and highly complex, and has a development team made up of hundreds of people, then more traditional methods will apply. Less risky, smaller, and simpler development efforts lend themselves more to agile methods. Other determining factors include organizational practice and stan- dards, and the extent to which different parts of the system will be contracted out to others for development. Obviously, the larger the proportion of the system that will be outsourced, the more detailed the design specifications will need to be so that subcon- tractors can understand what is needed. Although not universally agreed upon, the key differences between these development approaches are listed in Table 1-3, which is based on work by Boehm and Turner (2004). These differences can be used to help determine which development approach would work best for a particular project.

Many different individual methodologies come under the umbrella of agile methodologies. Fowler (2003) lists the Crystal family of methodologies, Adaptive Soft- ware Development, Scrum, Feature Driven Development, and others as agile method- ologies. eXtreme Programming is discussed next, followed by a discussion of Scrum.

eXtreme Programming

eXtreme Programming is an approach to software development put together by Beck and Andres (2004). It is distinguished by its short cycles, incremental plan- ning approach, focus on automated tests written by programmers and customers to monitor the development process, and reliance on an evolutionary approach to development that lasts throughout the lifetime of the system. Key emphases of eXtreme Programming are its use of two-person programming teams, described later, and having a customer on-site during the development process. The relevant parts of eXtreme Programming that relate to design specifications are (1) how planning,

M01B_VALA1629_09_GE_C01.indd 39 08/04/2020 16:33

40 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

analysis, design, and construction are all fused into a single phase of activity; and (2) its unique way of capturing and presenting system requirements and design specifica- tions. With eXtreme Programming, all phases of the life cycle converge into a series of activities based on the basic processes of coding, testing, listening, and designing.

Under this approach, coding and testing are intimately related parts of the same process. The programmers who write the code also develop the tests. The emphasis is on testing those things that can break or go wrong, not on testing everything. Code is tested very soon after it is written. The overall philosophy behind eXtreme Program- ming is that the code will be integrated into the system it is being developed for and tested within a few hours after it has been written. If all the tests run successfully, then development proceeds. If not, the code is reworked until the tests are successful.

Another part of eXtreme Programming that makes the code-and-test process work more smoothly is the practice of pair programming. All coding and testing is done by two people working together to write code and develop tests. Beck says that pair programming is not one person typing while the other one watches; rather, the two programmers work together on the problem they are trying to solve, exchanging information and insight and sharing skills. Compared to traditional coding practices, the advantages of pair programming include: (1) more (and better) communication among developers, (2) higher levels of productivity, (3) higher-quality code, and (4) reinforcement of the other practices in eXtreme Programming, such as the code-and- test discipline (Beck & Andres, 2004). Although the eXtreme Programming process has its advantages, just as with any other approach to systems development, it is not for everyone and is not applicable to every project.

Scrum

Scrum originated in 1995 and was developed by Jeff Sutherland and Ken Schwaber (Schwaber & Sutherland, 2011). It has become the most popular methodology for agile, with 58 percent of companies reporting using it (VersionOne, 2017). The second

Factor Agile Methods Traditional Methods

Size Well matched to small products and teams. Reliance on tacit knowledge limits scalability.

Methods evolved to handle large products and teams. Hard to tailor down to small projects.

Criticality Untested on safety-critical products. Potential difficulties with simple design and lack of documentation.

Methods evolved to handle highly critical products. Hard to tailor down to products that are not critical.

Dynamism Simple design and continuous refac- toring are excellent for highly dynamic environments but a source of potentially expensive rework for highly stable environments.

Detailed plans and Big Design Up Front, excellent for highly stable environment but a source of expen- sive rework for highly dynamic environments.

Personnel Requires continuous presence of a critical mass of scarce experts. Risky to use non-agile people.

Needs a critical mass of scarce experts during project definition but can work with fewer later in the project, unless the environment is highly dynamic.

Culture Thrives in a culture where people feel comfortable and empowered by having many degrees of freedom (thriving on chaos).

Thrives in a culture where people feel comfortable and empowered by having their roles defined by clear practices and procedures (thriving on order).

(Source: Boehm, Barry; Turner, Richard, Balancing Agility and Discipline: A Guide for the Per- plexed, 1st Ed., © 2004. Reprinted and electronically reproduced by permission of Pearson Education, Inc. New York, NY.)

TABLE 1-3 Five Critical Factors That Distinguish Agile and Traditional Approaches to Systems Development

M01B_VALA1629_09_GE_C01.indd 40 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 41

most popular methodology is a blend of Scrum and eXtreme Programming, used by 10 percent of companies. Scrum represents a framework that includes Scrum teams and their associated roles, events, artifacts, and rules. Each team consists of three roles: the product owner, the development team, and the Scrum master. The owner is essentially accountable for the product and the work that produces it. The develop- ment team is small, within the preferred range of three to nine. The Scrum master is there to teach and enforce the rules.

Scrum is designed for speed and for multiple functional product releases. The primary unit is the Sprint, which typically runs for two weeks to a month. Each Sprint is a complete project in and of itself. It starts with an eight-hour sprint planning meeting, which focuses on two questions: What will need to be delivered by the end of the sprint, and how will the team accomplish that work? The Sprint Goal provides guidance for the team for the duration of the sprint. During the sprint, there is a Daily Standup, a 15-minute meeting held to essentially evaluate what progress has been made within the last 24 hours and what still needs to be done. At the end of the sprint, there are two other meetings: the Sprint Review (four hours) and the Sprint Retrospective (three hours). While the review focuses on the product, what has been accomplished, and what needs to be done in the next sprint, the Retrospective is broader. It also focuses on the performance of the team and how it can improve in the next sprint. There are three primary artifacts in the Scrum process. The first is the Product Backlog. This is an ordered list of everything that might be included in the product, in other words, a list of potential requirements. The list includes “all features, functions, requirements, enhancements and fixes” (Schwaber & Sutherland, 2011, p. 12) that make up all the changes to be made to the product. The Sprint Backlog is a subset of the Product Backlog, consisting of only those items to be addressed in a particular sprint. Finally, the Increment is the sum of all the Product Backlog items completed during a sprint. Each Increment must be in complete enough form to be usable, whether or not the Product Owner decides to release it. It is called an Increment because it represents an increment of total functionality for the product. Each Increment is thoroughly tested, not only as a standalone, but in conjunction with all prior Increments.

Agile in Practice

Several studies have investigated agile methods in practice. A survey of over 100 agile projects found three primary critical success factors for agile development (Chow & Cao, 2008). The first is delivery strategy, which refers to the continuous delivery of working software in short time scales. The second is following agile software engineer- ing practices. That means managers and programmers must continually focus on tech- nical excellence and simple design. The third critical success factor is team capability, which refers to the agile principle of building projects around motivated individuals.

Another study found that, once implemented, agile methods can lead to improved job satisfaction and productivity on the part of programmers (Dyba & Dingsoyr, 2008). They can also lead to increased customer satisfaction, even though the role of on-site customer representative can be tiring and so not sustainable for very long. Agile methods tend to work best in small projects. In some instances, it may make sense to combine them with traditional development methods.

The best programmers for agile methods have faith in their own abilities and good interpersonal skills and trust. To succeed, agile teams need to balance a high level of individual autonomy with a high level of team responsibility and corporate responsibility. However, high levels of team autonomy are a two-edged sword. On the one hand, highly autonomous teams tend to be more efficient. They are able to take actions that reduce the time, cost, and resources needed to develop a system. In fact, agile projects undertaken by efficient teams tended to come in on time, on budget, and with the needed software functionality. On the other hand, highly autonomous teams also have more ability to say no to new user demands. Users may not be entirely happy with the resulting system if too many of their demands are declined.

M01B_VALA1629_09_GE_C01.indd 41 08/04/2020 16:33

42 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

A detailed study of one agile development effort showed that some of the key principles of agile development had to be modified to help ensure success (Fruhling & DeVreede, 2006). For example, in the agile project studied, pair programming was not always used, especially when resources were needed elsewhere. Second, the process of writing the test case first and then the code was followed until the system became too complex. Third, the customer was not located in the same place as the programmers. Instead, the customer stayed in contact through regular meetings and continual e-mail and phone communication. Even with these modifications, the resulting system was considered a success—fewer than 10 updates were issued because of errors and none were issued because of implementing the wrong functionalities. Working together, the users and developers were able to clarify system requirements and create a user interface that was easy to learn and use.

In conclusion, agile development offers managers and programmers more choice in their efforts to produce good systems that come in on time and at or under budget. Agile methods are an integral methodology for systems analysis and design. Over time, we will come to understand them better, as well as how best to use them for the benefit of developers and users.

OBJECT-ORIENTED ANALYSIS AND DESIGN There is no question that object-oriented analysis and design (OOAD) is the standard for systems development (we elaborate on this approach later throughout the book). OOAD is often called the third approach to systems development, after the process- oriented and data-oriented approaches. The object-oriented approach combines data and processes (called methods) into single entities called objects. Objects usually cor- respond to the real things an information system deals with, such as customers, sup- pliers, contracts, and rental agreements. Putting data and processes together in one place recognizes the fact that there are a limited number of operations for any given data structure, and the object-oriented approach makes sense even though typical systems development keeps data and processes independent of each other. The goal of OOAD is to make systems elements more reusable, thus improving system quality and the productivity of systems analysis and design.

Another key idea behind object orientation is inheritance. Objects are organized into object classes, which are groups of objects sharing structural and behavioral characteristics. Inheritance allows the creation of new classes that share some of the characteristics of existing classes. For example, from a class of objects called “person,” you can use inheritance to define another class of objects called “customer.” Objects of the class “customer” would share certain characteristics with objects of the class “person”: They would both have names, addresses, phone numbers, and so on. Because “person” is the more general class and “customer” is more specific, every customer is a person but not every person is a customer.

As you might expect, a computer programming language is required that can create and manipulate objects and classes of objects in order to create object-oriented information systems. Several object-oriented programming languages have been cre- ated (e.g., C++, Python, and Java). In fact, object-oriented languages were developed first, and object-oriented analysis and design techniques followed. In general, the primary task of object-oriented analysis is identifying objects and defining their struc- ture and behavior and their relationships. The primary tasks of object-oriented design are modeling the details of the objects’ behavior and communication with other objects so that system requirements are met, and re-examining and redefining objects to better take advantage of inheritance and other benefits of object orientation.

The object-oriented approach to systems development shares the iterative devel- opment approach of the agile methodologies. Some say that the current focus on agility in systems development is nothing more than the mainstream acceptance of object-oriented approaches that have been germinating for years, so this similarity

Object-oriented analysis and design (OOAD) Systems development methodologies and techniques based on objects rather than data or processes.

Object A structure that encapsulates (or packages) attributes and methods that operate on those attributes. An object is an abstraction of a real-world thing in which data and processes are placed together to model the structure and behavior of the real-world object.

Inheritance The property that occurs when entity types or object classes are arranged in a hierarchy and each entity type or object class assumes the attributes and methods of its ancestors, that is, those higher up in the hierarchy. Inheritance allows new but related classes to be derived from existing classes.

Object class A logical grouping of objects that have the same (or similar) attributes and behaviors (methods).

M01B_VALA1629_09_GE_C01.indd 42 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 43

should come as no surprise (Fowler, 2003). One of the most popular realizations of the iterative approach for object-oriented development is the Rational Unified Process (RUP), which is based on an iterative, incremental approach to systems devel- opment. RUP has four phases: inception, elaboration, construction, and transition (see Figure 1-9).

In the inception phase, analysts define the scope, determine the feasibility of the project, understand user requirements, and prepare a software development plan. In the elaboration phase, analysts detail user requirements and develop a baseline archi- tecture. Analysis and design activities constitute the bulk of the elaboration phase. In the construction phase, the software is actually coded, tested, and documented. In the transition phase, the system is deployed, and the users are trained and supported. As is evident from Figure 1-9, the construction phase is generally the longest and the most resource intensive. The elaboration phase is also long, but less resource intensive. The transition phase is resource intensive but short. The inception phase is short and the least resource intensive. The areas of the rectangles in Figure 1-9 provide an estimate of the overall resources allocated to each phase.

Each phase can be further divided into iterations. The software is developed incrementally as a series of iterations. The inception phase will generally entail a single iteration. The scope and feasibility of the project is determined at this stage. The elaboration phase may have one or two iterations and is generally considered the most critical of the four phases (Kruchten, 2000). The elaboration phase is mainly about systems analysis and design, although other activities are also involved. At the end of the elaboration phase, the architecture of the project should have been developed. The architecture includes a vision of the product, an executable demonstration of the critical pieces, a detailed glossary and a preliminary user manual, a detailed construc- tion plan, and a revised estimate of planned expenditures.

Although the construction phase mainly involves coding, which is accomplished in several iterations, revised user requirements could require analysis and design. The components are developed or purchased and used in the code. As each executable is completed, it is tested and integrated. At the end of the construction phase, a beta version of the project is released that should have operational capabilities. The transi- tion phase entails correcting problems, beta testing, user training, and conversion of

Rational Unified Process (RUP) An object-oriented systems development methodology. RUP establishes four phases of development: inception, elaboration, construction, and transition. Each phase is organized into a number of separate iterations.

FIGURE 1-9 Phases of OOAD-based development

Resource

Time

Inception Elaboration Construction Transition

M01B_VALA1629_09_GE_C01.indd 43 08/04/2020 16:33

44 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

the product. The transition phase is complete when the project objectives meet the acceptance criteria. Once acceptance criteria have been met, the product can then be released for distribution.

OUR APPROACH TO SYSTEMS DEVELOPMENT Much of the criticism of the SDLC has been based on abuses of the life-cycle perspec- tive, both real and imagined. One of the criticisms based in reality is that reliance on the life-cycle approach forced intangible and dynamic processes, such as analysis and design, into timed phases that were doomed to fail (Martin, 1999). Developing software is not like building a bridge, and the same types of engineering processes cannot always be applied (Fowler, 2003), even though viewing software development as a science rather than an art has no doubt resulted in vast improvements in the process and the resulting products. Another criticism with its basis in fact is that life-cycle reliance has resulted in massive amounts of process and documentation, much of which seems to exist for its own sake. Too much process and documenta- tion does slow down development, hence the streamlining that underlies the agile methodologies and the admonition from agile developers that source code is enough documentation. A criticism of the SDLC that is based more on fiction is that all ver- sions of the SDLC are waterfall-like, with no feedback between steps. Another false criticism is that a life-cycle approach necessarily limits the involvement of users in the earliest stages of the process. Yet agile methodologies advocate an analysis–design– code–test sequence that is a cycle (Figure 1-6), and users can be and are involved in every step of this cycle; thus, cycles in and of themselves do not necessarily limit user involvement.

Despite the criticisms of a life-cycle approach to systems analysis and design, the view of systems analysis and design taking place in a cycle continues to be pervasive, and, we think, true as well. There are many types of cycles, from the waterfall to the analysis–design–code–test cycle, and they all capture the iterative nature of systems development. The waterfall approach may be losing its relevance, but the cycle in Figure 1-6 is gaining in popularity, and the analysis–design–code–test cycle is embed- ded in a larger organizational cycle. Although we typically use the terms systems analysis and design and systems development interchangeably, perhaps it is better to think about systems analysis and design as being the cycle in Figure 1-6 and systems development as being the larger cycle in Figure 1-2. The analysis–design–code–test cycle largely ignores the organizational planning that precedes it and the organizational instal- lation and systems maintenance that follow, yet they are all important aspects of the larger systems development effort. And to us, the best, clearest way to think about both efforts is in terms of cycles.

Therefore, in this book you will see Figure 1-2 at the beginning of almost every chapter. We will use our SDLC as an organizing principle in this book, with activities and processes arranged according to whether they fit under the category of planning, analysis, design, implementation, or maintenance. To some extent, we will artificially separate activities and processes so that each one can be individually studied and understood. Once individual components are clearly understood, it is easier to see how they fit with other components, and eventually it becomes easy to see the whole. Just as we may artificially separate activities and processes, we may also construct arti- ficial boundaries between phases of the SDLC. Our imposition of boundaries should never be interpreted as hard-and-fast divisions. In practice, as we have seen with the agile methodologies and in the introduction to OOAD, phases and parts of phases may be combined for speed, understanding, and efficiency. Our intent is to introduce the pieces in a logical manner, so that you can understand all the pieces and how to assemble them in the best way for your systems development purposes. Yet the over- all structure of the cycle, of iteration, remains throughout. Think of the cycle as an organizing and guiding principle.

M01B_VALA1629_09_GE_C01.indd 44 08/04/2020 16:33

CHAPTER 1 ThE SySTEmS DEvElopmEnT EnvironmEnT 45

SUMMARY This chapter introduced you to information systems analy- sis and design, the complex organizational process whereby computer-based information systems are developed and maintained. You read about how systems analysis and design in organizations has changed over the past several decades. You also learned about the basic framework that guides systems analysis and design—the systems development life cycle (SDLC), with its five major phases: planning, analysis, design, implementation, and maintenance. The SDLC life

cycle has had its share of criticism, which you read about. Agile methodologies have been developed to address those criticisms. Two of the most well-known methodologies that follow the agile perspective are eXtreme Programming and Scrum. You were also briefly introduced to object-oriented analysis and design. All these approaches share the underly- ing idea of iteration, as manifested in the systems develop- ment life cycle and the analysis–design–code–test cycle of the agile methodologies.

Match each of the key terms above with the definition that best fits it.

KEY TERMS

1.1 Analysis 1.2 Application software 1.3 Design 1.4 Implementation 1.5 Information systems analysis and

design 1.6 Inheritance

1.7 Logical design 1.8 Maintenance 1.9 Object 1.10 Object class 1.11 Object-oriented analysis and design

(OOAD) 1.12 Physical design

1.13 Planning 1.14 Rational Unified Process

(RUP) 1.15 Systems analyst 1.16 Systems development life cycle

(SDLC) 1.17 Systems development methodology

REVIEW QUESTIONS

1.18 Describe the role of the systems analyst in information sys- tems development.

1.19 What is application software? How does it differ from soft- ware in general (such as games)?

1.20 Compare and contrast logical and physical design.

1.21 In the 1980s, the software market—not just the market for software used in organizations—grew very rapidly. What was the reason for this?

____ The complex organizational process whereby computer- based information systems are developed and maintained.

____ Computer software designed to support organizational functions or processes.

____ The organizational role most responsible for the analysis and design of information systems.

____ A standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems.

____ The traditional methodology used to develop, maintain, and replace information systems.

____ The first phase of the SDLC, in which an organization’s total information system needs are identified, analyzed, prioritized, and arranged.

____ The second phase of the SDLC, in which system requirements are studied and structured.

____ The third phase of the SDLC, in which the description of the recommended solution is converted into logical and then physical system specifications.

____ The part of the design phase of the SDLC in which all func- tional features of the system chosen for development are described independently of any computer platform.

____ The part of the design phase of the SDLC in which the logical specifications of the system from logical design are

transformed into technology-specific details from which all programming and system construction can be accomplished.

____ The fourth phase of the SDLC, in which the information system is coded, tested, installed, and supported in the organization.

____ The final phase of the SDLC, in which an information sys- tem is systematically repaired and improved.

____ Systems development methodologies and techniques based on objects rather than data or processes.

____ A structure that encapsulates (or packages) attributes and the methods that operate on those attributes. It is an abstraction of a real-world thing in which data and processes are placed together to model the structure and behavior of the real- world object.

____ The property that occurs when entity types or object classes are arranged in a hierarchy and each entity type or object class assumes the attributes and methods of its ancestors— that is, those higher up in the hierarchy. The property allows new but related classes to be derived from existing classes.

____ A logical grouping of objects that have the same (or similar) attributes and behaviors (methods).

____ An object-oriented systems development methodology. This methodology establishes four phases of development, each of which is organized into a number of separate iterations: inception, elaboration, construction, and transition.

M01B_VALA1629_09_GE_C01.indd 45 08/04/2020 16:33

46 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Beck, K., & Andres, C. (2004). eXtreme Programming eXplained. Upper Saddle River, NJ: Addison-Wesley.

Boehm, B., & Turner, R. (2004). Balancing agility and discipline. Boston: Addison-Wesley.

Chow, T. & Cao, D-B. (2008). A survey study of critical success factors in agile software projects. The Journal of Systems and Software, 81, 961–971.

Dorfman, M., & Thayer, R. M. (eds). (1997). Software engineering. Los Alamitos, CA: IEEE Computer Society Press.

Dyba, T. & Dingsoyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50, 833–859.

Fowler, M. (2003, December). The new methodologies. Retrieved February 3, 2009 from http://martinfowler.com/articles/ newMethodology.html.

Fruhling, A. & De Vreede, G. J. (2006). Field experiences with eXtreme Programming: Developing an emergency response system. Journal of MIS, 22(4), 39–68.

Griss, M. (2003). Ranking IT productivity improvement strategies. Accessed February 3, 2009 from http://martin.griss.com/ pub/WPGRISS01.pdf.

Kay, R. (2002, May 14). QuickStudy: System Development Life Cycle. Computerworld. Retrieved February 3, 2009 from http://www.computerworld.com.

Kruchten, P. (2000). From waterfall to iterative lifecycle—A Tough transition for project managers (Rational Software White Paper TP-173 5/00). Retrieved February 3, 2009 from http://www .ibm.com/developerworks/rational.

Martin, R. C. (1999). Iterative and Incremental Development I. Retrieved October 12, 2012 from http://www.objectmentor .com/resources/ articles/IIDI.pdf.

Schwaber, K. & Sutherland, J. (2011). The scrum guide. Accessed at http://www.scrum.org/scrumguides, 1/12/12.

VersionOne. 2017. 11th Annual State of Agile Report. Retrieved March 13, 2018 from http://www.versionone.com/ resources/.

REFERENCES

PROBLEMS AND EXERCISES 1.28 Business and systems have become more sophisticated and

more complex, and there has been an increasing emphasis on speed in systems analysis and design. What is your opin- ion on this? Why might speed be such an important aspect of systems development?

1.29 Methodology, techniques, and tools form a relationship and work together to create an organizational approach to sys- tems analysis and design. How does this relationship work? What do the three terms mean, what do they include, and how are they related to each other?

1.30 What are the similarities and differences between Micro- soft’s Security Development Lifecycle (SDL) and the SDLC? Do you think that the SDLC could be improved using some of the features of the SDL, and if so, which ones and why?

1.31 The proponents of agile methodologies claim that the tradi- tional SDLC suffers from a lack of predictability, or rather that development according to SDLC tries to predict a system’s needs. How do agile methodologies approach this problem?

1.32 RUP has four phases. How do these relate—if at all—to the steps in the SDLC?

FIELD EXERCISES 1.33 Tax authorities are usually highly dependent on information

systems. Take a look at the Website of your country’s tax authority. What kind of functionality does their information systems seem to have? Make a list of the various functions you find, such as online declaration of income.

1.34 Locate job ads relating to the IT field. Try to figure out which ones relate to the various phases of the SDLC. Is there a particularly large number of work opportunities relating to a certain phase of the SDLC?

1.35 Look at the ads again. Do these ads have some things in common, either in terms of job descriptions or in how the ads are written? Judging from the job ads alone, is there a certain place where you would prefer to work?

1.36 MetaCase’s MetaEdit+ and IBM’s Rational Rose are two CASE tools that are commonly referred to. Oracle Designer

and Microsoft Visual Studio are also CASE tools, but they are limited to—and aimed at—their respective programming languages. See if you can find an organization that works with one of these CASE tools and interview one of its person- nel. Why did they choose a certain CASE tool over another? What do they think about the future of CASE tools?

1.37 The major sources for IT-related news are the media pub- lished by the International Data Group (IDG). During your course on systems analysis and design, follow some of IDG’s magazines or newsletters. Make a portfolio of feature articles you find especially interesting. Try to look for news items relating to information systems and information systems development. Even if you read up on other things, such as game development, try to see how this activity is actually based on a sound foundation in one of the systems develop- ment methodologies.

1.22 According to Fowler, what are the three guiding principles for the agile methodologies, as expressed in The Agile Manifesto?

1.23 What is eXtreme Programming?

1.24 What is RUP?

1.25 Which part of the SDLC is called the heart of the system development process?

1.26 In object-oriented analysis and design, two important terms are “object” and “inheritance.” What do they refer to?

1.27 Describe the advantages of pair programming over tradi- tional coding practice.

M01B_VALA1629_09_GE_C01.indd 46 08/04/2020 16:33

http://martinfowler.com/articles/newMethodology.html

http://martin.griss.com/pub/WPGRISS01.pdf

http://www.computerworld.com

http://www.ibm.com/developerworks/rational

http://www.objectmentor.com/resources/articles/IIDI.pdf

http://www.scrum.org/scrumguides

http://www.versionone.com/resources

http://martinfowler.com/articles/newMethodology.html

http://martin.griss.com/pub/WPGRISS01.pdf

http://www.ibm.com/developerworks/rational

http://www.objectmentor.com/resources/articles/IIDI.pdf

http://www.versionone.com/resources

is outsourcing, in which all or part of an organization’s information systems, their development, and their main- tenance are given over to another organization. You will then read about six different sources of software: (1) infor- mation technology services firms, (2) packaged software providers, (3) vendors of enterprise-wide solution software, (4) cloud computing, (5) open-source software, and (6) the organization itself when it develops software in-house. You will learn about criteria to evaluate software from these different sources. The chapter closes with a discussion of reuse and its impact on software development.

SYSTEMS ACQUISITION Although there will always be some debate about when and where the first administrative information system was developed, there is general agreement that the first such system in the United Kingdom was developed at J. Lyons & Sons. In the United States, the first administrative infor- mation system was General Electric’s (GE) payroll system, which was developed in 1954 (Computer History Museum, 2003). At that time, and for many years afterward, obtain- ing an information system meant one thing only: in-house development. The software industry did not even come into existence until a decade after GE’s payroll system was implemented.

Since GE’s payroll system was built, in-house devel- opment has become a progressively smaller piece of all the systems development work that takes place in and for organizations. Internal corporate information systems departments now spend a smaller and smaller proportion of their time and effort on developing systems from scratch.

As you learned in Chapter 1, there was a time, not too long ago, when no systems analysts and no symbolic com- puter programming languages existed. Yet people still wrote and programmed applications for computers. Even though today’s systems analyst has dozens of program- ming languages and development tools to work with, you could easily argue that systems development is even more difficult now than it was years ago. Then, as well as even more recently, certain issues were decided for you: If you wanted to write application software, you did it in-house, and you wrote the software from scratch. Today there are many different sources of software, and many of you read- ing this book will end up working for firms that produce software, rather than in the information systems depart- ment of a corporation. But for those of you who do go on to work in a corporate information systems department, the focus is no longer exclusively on in-house develop- ment. Instead, the focus will be on where to obtain the many pieces and components that you will combine into the application system you have been asked to create. You and your peers will still write code, mainly to make all the different pieces work together, but more and more of your application software will be written by someone else. Even though you will not write the code, you will still use the basic structure and processes of the systems analy- sis and design life cycle to build the application systems your organization demands. The organizational process of systems development remains the focus for the rest of the book, but first you need to know more about where software originates in today’s development environment.

In this chapter, you will learn about the various sources of software for organizations. The first source considered

2.3 discuss how to evaluate off-the-shelf software; and

2.4 explain reuse and its role in software development.

Learning Objectives After studying this chapter, you should be able to

2.1 explain outsourcing;

2.2 describe six different sources of software;

The Origins of Software2

Introduction

M02_VALA1629_09_GE_C02.indd 47 08/04/2020 16:34

48 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Companies continue to spend relatively little time and money on traditional software development and maintenance. Instead, they invest in packaged software, open-source software, and outsourced services. Organizations today have many choices when seek- ing an information system. We will start with a discussion of outsourcing development and operation and then move on to a presentation on the sources of software.

Outsourcing

If one organization develops or runs a computer application for another organiza- tion, that practice is called outsourcing. Outsourcing includes a spectrum of working arrangements. At one extreme is having a firm develop and run your application on its computers—all you do is supply input and take output. A common example of such an arrangement is a company that runs payroll applications for clients so that clients do not have to develop an independent in-house payroll system. Instead, they simply pro- vide employee payroll information to the company, and, for a fee, the company returns completed paychecks, payroll accounting reports, and tax and other statements for employees. For many organizations, payroll is a very cost-effective operation when out- sourced in this way. Another example of outsourcing would be if you hired a company to run your applications at your site on your computers. In some cases, an organization employing such an arrangement will dissolve some or all of its information systems (IS) unit and fire all of its IS employees. Often the company brought in to run the organi- zation’s computing will rehire many of the organization’s original IS unit employees.

Outsourcing is big business. Some organizations outsource the information tech- nology (IT) development of many of their IT functions at a cost of billions of dollars. Most organizations outsource at least some aspect of their information systems activi- ties. Global outsourcing revenues in 2017 were estimated at $88.9 billion USD, with $64.3 billion USD due to IT outsourcing (Statistica, 2018). Individual outsourcing vendors, such as HPE, IBM, and Accenture, typically sign large contracts for their services. These vendors have multiple outsourcing contracts in place with many dif- ferent firms all over the world.

Why would an organization outsource its information systems operations? As we saw in the payroll example, outsourcing may be cost-effective. If a company special- izes in running payroll for other companies, it can leverage the economies of scale it achieves from running one stable computer application for many organizations into very low prices. Outsourcing also provides a way for firms to leapfrog their current position in information systems and to turn over development and operations to out- side staff who possess knowledge and skills not found internally (Ketler & Willems, 1999). Other reasons for outsourcing include

• freeing up internal resources, • increasing the revenue potential of the organization, • reducing time to market, • increasing process efficiencies, and • outsourcing noncore activities.

An organization may move to outsourcing and dissolve its entire information processing unit for political reasons as well, such as overcoming operating problems the organization faces in its information systems unit. For example, the City of Grand Rapids, Michigan, hired an outside firm to run its computing center 50 years ago in order to better manage its computing center employees. Union contracts and civil service constraints then in force made it difficult to fire people, so the City brought in a facilities management organization to run its computing operations, and it was able to get rid of problem employees at the same time. As mentioned earlier, another reason for total outsourcing is that an organization’s management may feel its core mission does not involve managing an information systems unit and that it might achieve more effective computing by turning over all its operations to a more experi- enced, computer-oriented company.

Outsourcing The practice of turning over responsibil- ity for some or all of an organization’s information systems applications and operations to an outside firm.

M02_VALA1629_09_GE_C02.indd 48 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 49

Although you have most likely heard about outsourcing in terms of IT jobs from all over the world going to India, it turns out that the global outsourcing marketplace is much more complicated. According to a 2017 report by ATKearney (2017), India is the number one outsourcing nation, while China is close behind, and Malaysia is third. Despite much turmoil in the overall outsourcing market over the years, the top three rankings have not changed since ATKearney’s first report on outsourcing in 2003. Not all of the 2017 top 10 outsourcing countries are located in Asia. Although seven are in Asia, three are in Latin America (Brazil, Chile, and Colombia). Even the United States is an outsourcing nation, number 22 on the ATKearney list. In fact, Indian outsourcing firms, such as Wipro, Infosys, and Tata Consulting, operate offices in the United States. As Indian firms have become so successful at offshoring, and as currencies have fluctuated, it has become more expensive for firms to contract with Indian companies, so many firms have started to look elsewhere. Many U.S. firms have turned to what is called nearshoring, or contracting with companies in Latin American countries. Many of these countries are no more than one time zone away, and they maintain some of the labor cost advantages that are eroding in India (King, 2008a). Mexico, number 13 on the list, is increasingly seen as a complement to India and other offshore locations. It is also becoming more common for firms to distribute their outsourcing work across vendors in several countries at the same time.

Analysts need to be aware of outsourcing as an alternative. When generating alternative system development strategies for a system, as an analyst you should consult organizations in your area that provide outsourcing services. It may well be that at least one such organization has already developed and is running an application very close to what your users are asking for. Perhaps outsourcing the replacement system should be one of your alternatives. Knowing what your system requirements are before you consider outsourcing means that you can carefully assess how well the suppliers of outsourcing services can respond to your needs. However, should you decide not to consider outsourcing, you need to determine whether some software components of your replacement system should be purchased and not built in-house.

Sources of Software

We can group the sources of software into six major categories: information technol- ogy services firms, packaged software producers, enterprise-wide solutions, cloud com- puting vendors, open-source software, and in-house developers (Figure 2-1). These various sources represent points along a continuum of options, with many hybrid combinations along the way.

Information Technology Services Firms If a company needs an information sys- tem but does not have the expertise or the personnel to develop the system in-house, and a suitable off-the-shelf system is not available, the company will likely consult an information technology services firm. IT services firms help companies develop cus- tom information systems for internal use, or they develop, host, and run applications for customers, or they provide other services. Note in Table 2-1 that many of the lead- ing software companies in the world specialize in IT services, which includes custom systems development. These firms employ people with expertise in the development of information systems. Their consultants may also have expertise in a given business area. For example, consultants who work with banks understand financial institutions as well as information systems. Consultants use many of the same methodologies, techniques, and tools that companies use to develop systems in-house.

It may surprise you to see IBM listed as a top global software producer; some people still think of it as primarily a hardware company. Yet IBM has been moving away from a reliance on hardware development for many years. IBM long ago solidi- fied its move into services and consulting. IBM is also well known for its development of Web server and middleware software. Other leading IT services firms include tra- ditional consulting firms, such as Computer Sciences Corp., Accenture, and HPE

M02_VALA1629_09_GE_C02.indd 49 08/04/2020 16:34

50 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

(Hewlett-Packard Enterprise). HPE, another company formerly focused on hardware, has also made the transition to an IT services firm.

Packaged Software Producers The growth of the software industry has been phenomenal since its beginnings in the mid-1960s. Some of the largest computer com- panies in the world are companies that produce software exclusively. A good example is Microsoft, probably the best-known software company in the world. The majority of Microsoft’s revenue comes from its software sales, mostly of its Windows operating

FIGURE 2-1 Sources of application software

(Sources: Middle: Pixachi/Shutterstock, Clockwise starting with upper left: Kamira/Shutterstock; Amit John/ Pearson India Education Services Pvt. Ltd; Dmitry Kalinovsky/Shutterstock; 1000 Words/Shutterstock; Aa Amie/ Shutterstock; Le Do/Shutterstock)

Cloud Computing IT Services Firms

Packaged Software Providers

In-House

Open Source

ERP Providers

Specialization Example Firms or Websites

IT Services Accenture Computer Sciences Corporation (CSC)

IBM

HPE

Packaged Software Providers Intuit Microsoft

Oracle

SAP AG

Symantec

Enterprise Software Solutions Oracle SAP AG

Cloud Computing Amazon.com Google

IBM

Microsoft

Salesforce.com

Open Source SourceForge.net

TABLE 2-1 Leading Software Firms and Their Development Specializations

M02_VALA1629_09_GE_C02.indd 50 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 51

systems and its personal productivity software, the Microsoft Office Suite. Also listed in Table 2-1, Oracle is exclusively a software company known primarily for its database software, but Oracle also makes enterprise systems. Another company on the list, SAP, is also a software-focused company that develops enterprise-wide system solutions. You will read more about Oracle and SAP shortly, in the section on enterprise systems.

Software companies develop what are sometimes called prepackaged or off-the- shelf systems. Microsoft’s Word (Figure 2-2) and Intuit’s Quicken, QuickBooks, and TurboTax are popular examples of such software. The packaged software development industry serves many market segments. Their software offerings range from general, broad-based packages, such as productivity tools, to very narrow, niche packages, such as software to help manage a day care center. Software companies develop software to run on many different computer platforms, from microcomputers to large main- frames. The companies range in size from just a few people to thousands of employees.

Software companies consult with system users after the initial software design has been completed and an early version of the system has been built. The systems are then tested in actual organizations to determine whether there are any problems or if any improvements can be made. Until testing is completed, the system is not offered for sale to the public.

Some off-the-shelf software systems cannot be modified to meet the specific, individual needs of a particular organization. Such application systems are sometimes

FIGURE 2-2 A document created in Microsoft’s Word

(Source: Microsoft Corporation.)

M02_VALA1629_09_GE_C02.indd 51 08/04/2020 16:34

52 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

called turnkey systems. The producer of a turnkey system will make changes to the software only when a substantial number of users ask for a specific change. However, other off-the-shelf application software can be modified or extended, by the producer or by the user, to more closely fit the needs of the organization. Even though many organizations perform similar functions, no two organizations do the same thing in quite the same way. A turnkey system may be good enough for a certain level of per- formance, but it will never perfectly match the way a given organization does business. A reasonable estimate is that off-the-shelf software can at best meet 70 percent of an organization’s needs. Thus, even in the best case, 30 percent of the software system does not match the organization’s specifications.

Enterprise Solutions Software As mentioned in Chapter 1, many firms have chosen complete software solutions, called enterprise solutions or enterprise resource planning (ERP) systems, to support their operations and business processes. These ERP software solutions consist of a series of integrated modules. Each module supports an individual, traditional business function, such as accounting, distribution, manu- facturing, or human resources. The difference between the modules and traditional approaches is that the modules are integrated to focus on business processes rather than on business functional areas. For example, a series of modules will support the entire order entry process, from receiving an order, to adjusting inventory, to shipping, to billing, to after-the-sale service. The traditional approach would use different systems in different functional areas of the business, such as a billing system in accounting and an inventory system in the warehouse. Using enterprise software solutions, a firm can integrate all parts of a business process in a unified information system. All aspects of a single transaction occur seamlessly within a single information system, rather than as a series of disjointed, separate systems focused on business functional areas.

The benefits of the enterprise solutions approach include a single repository of data for all aspects of a business process and the flexibility of the modules. A single repository ensures more consistent and accurate data, as well as less maintenance. The modules are flexible because additional modules can be added as needed once the basic system is in place. Added modules are immediately integrated into the existing system. However, there are disadvantages to enterprise solutions software. The systems are very complex, so implementation can take a long time to complete. Organizations typically do not have the necessary expertise in-house to implement the systems, so they must rely on consultants or employees of the software vendor, which can be very expensive. In some cases, organizations must change how they do business in order to benefit from a migration to enterprise solutions.

Several major vendors provide enterprise solution software. The best known is probably SAP AG, the German firm mentioned earlier, known for its flagship prod- uct R/3. SAP AG was founded in 1972, but most of its growth has occurred since 1992. Since 2010, SAP has been one of the largest suppliers of software in the world. Another major vendor of enterprise solutions is Oracle Corp., a U.S.-based firm, per- haps better known for its database software. Oracle captured a large share of the ERP market through its own financial systems and through the acquisition of other ERP vendors. At the end of 2004, Oracle acquired PeopleSoft, Inc., a U.S. firm founded in 1987. PeopleSoft began with enterprise solutions that focused on human resources management and expanded to cover financials, materials management, distribution, and manufacturing before Oracle acquired them. Global revenues for ERP software was $82.2 billion USD in 2016, with the top 10 firms accounting for 28.5 percent of the market (Pang, 2017). SAP controlled the largest single slice of the market, at 7 percent. ERP revenues are expected to hit $84.7 billion USD by 2021.

Cloud Computing Another method for organizations to obtain applications is to rent them or license them from third-party providers who run the applications at remote sites. Users have access to the applications through the Internet or through vir- tual private networks. The application provider buys, installs, maintains, and upgrades

Enterprise resource planning (ERP) systems A system that integrates individual tra- ditional business functions into a series of modules so that a single transaction occurs seamlessly within a single infor- mation system rather than several sepa- rate systems.

M02_VALA1629_09_GE_C02.indd 52 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 53

the applications. Users pay on a per-use basis or they license the software, typically month to month. Although this practice has been known by many different names over the years, today it is part of cloud computing. Cloud computing refers to the provision of applications or related services over the Internet, where customers do not have to invest in the hardware and software resources needed to run and main- tain the applications. You may have seen the Internet referred to as a cloud in other contexts, which comes from how the Internet is depicted on computer network dia- grams. A well-known example of cloud computing is Google Docs, Sheets, and Slides, where users can share and create documents, spreadsheets, and presentations, respec- tively (Figure 2-3). Another well-known example is Salesforce.com, which provides customer relationship management software online. Cloud computing encompasses many areas of technology, including software as a service (often referred to as SaaS), which includes Salesforce.com, and hardware as a service, which includes Amazon Web Services and allows companies to order server capacity and storage on demand.

The global market for public cloud computing was estimated at $209.2 billion USD in 2016, and it is projected to grow to $383.3 billion USD by 2020 (Gartner, 2017). The software as a service sector accounts for about 20 percent of the total. The com- panies most likely to profit immediately from the growth in cloud computing are those that can quickly adjust their product lines to meet the needs of cloud computing. These include such well-known names as IBM, which has built multiple cloud comput- ing centers worldwide; Microsoft, whose Azure platform supports the development and operation of business applications and consumer services on its own servers; and Amazon.com, which provides storage and capacity from its own servers to customers.

Cloud computing The provision of computing resources, including applications, over the Internet, so customers do not have to invest in the computing infrastructure needed to run and maintain the resources.

FIGURE 2-3 A presentation edited in Google Slides

(Source: Reprinted by permission from Joey F. George.)

M02_VALA1629_09_GE_C02.indd 53 08/04/2020 16:34

54 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Taking the cloud computing route has its advantages. The top three reasons for choosing to go with cloud computing, all of which result in benefits for the company, are (1) freeing internal IT staff, (2) gaining access to applications faster than via inter- nal development, and (3) achieving lower-cost access to corporate-quality applications. Especially appealing is the ability to gain access to large and complex systems without having to go through the expensive and time-consuming process of implementing the systems themselves in-house. Getting your computing through a cloud also makes it easier to walk away from an unsatisfactory systems solution. Other reasons include cost effectiveness, speed to market, and better performance (Moyle & Kelley, 2011).

IT managers do have some concerns about cloud computing, however. The pri- mary concern is over security. Concerns over security are based on storing company data on machines that one does not own and that others can access. In fact, the top two reasons for not using cloud services are concerns about unauthorized access to proprietary information and unauthorized access to customer information (Moyle & Kelley, 2011). Another concern is reliability. Some warn that the cloud is actually a network of networks, and as such, it is vulnerable to unexpected risks due to its com- plexity (kfc, 2012). Still another concern is compliance with government regulations, such as the Sarbanes-Oxley Act. Experts recommend a three-step process for secure migration to the cloud (Moyle & Kelley, 2011). First, have the company’s security experts involved early in the migration process, so that a vendor who understands the company’s security and regulatory requirements can be selected. Second, set realistic security requirements. Make sure the requirements are clearly spelled out as part of the bidding process. Third, do an honest risk assessment. Determine which data will be migrated and pay attention to how it will be managed by the cloud vendor. Once migration has occurred, it is important for companies to continue to monitor their data and systems and actively work with the vendor to maintain security.

Open-Source Software Open-source software is unlike the other types of software you have read about so far. Open-source software is different because it is freely avail- able, not just the final product but the source code itself. It is also different because it is developed by a community of interested people instead of by employees of a par- ticular company. Open-source software performs the same functions as commercial software, such as operating systems, e-mail, database systems, Web browsers, and so on. Some of the most well-known and popular open-source software names are Linux, an operating system; mySQL, a database system; and Firefox, a Web browser. Open source also applies to software components and objects. Open source is developed and main- tained by communities of people, and sometimes these communities can be very large. Developers often use common Web resources, such as SourceForge.net, to organize their activities. As of March 2018, SourceForge.net hosted over 500,000 projects and 33 million monthly users. There is no question that the open-source movement would not be having the success it enjoys without the availability of the Internet for providing access and organizing development activities.

If the software is free, you might wonder how anybody makes any money by devel- oping open-source software. Companies and individuals can make money with open source in two primary ways: (1) by providing maintenance and other services or (2) by providing one version of the software free and selling a more fully featured version. Some open-source solutions have more of an impact on the software industry than oth- ers. Linux, for example, has been very successful in the server software market, where it is estimated to have as much as 30 percent of the market share (Netcraft, 2017).

In-House Development We have talked about several different types of external organizations that serve as sources of software, but in-house development remains an option. In-house development has become a progressively smaller piece of all systems development work that takes place in and for organizations. As you read earlier in this chapter, internal corporate information systems departments now spend a smaller and smaller proportion of their time and effort on developing systems from scratch.

M02_VALA1629_09_GE_C02.indd 54 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 55

In-house development can lead to a larger maintenance burden than other develop- ment methods, such as packaged applications. A study by Banker, Davis, and Slaughter (1998) found that using a code generator as the basis for in-house development was related to an increase in maintenance hours, whereas using packaged applications was associated with a decrease in maintenance effort.

Of course, in-house development need not entail development of all of the soft- ware that will constitute the total system. Hybrid solutions involving some purchased and some in-house software components are common. If you choose to acquire soft- ware from outside sources, this choice is made at the end of the analysis phase. The choice between a package and an external supplier will be determined by your needs, not by what the supplier has to sell. As we will discuss, the results of your analysis study will define the type of product you want to buy and will make working with an external supplier much easier, more productive, and worthwhile. Table 2-2 compares the six different software sources discussed in this section.

Choosing Off-the-Shelf Software

Once you have decided to purchase off-the-shelf software rather than write some or all of the software for your new system, how do you decide what to buy? There are several criteria to consider, and special criteria may arise with each potential software purchase. For each criterion, an explicit comparison should be made between the software package and the process of developing the same application in-house. The most common criteria include the following:

• Cost • Functionality • Vendor support • Viability of vendor • Flexibility • Documentation • Response time • Ease of installation

These criteria are presented in no particular order. The relative importance of the criteria will vary from project to project and from organization to organization. If you

Producers When to Go to This Type of Organization for Software

Internal Staffing Requirements

IT services firms When task requires custom sup- port and system can’t be built internally or system needs to be sourced

Internal staff may be needed, depending on application

Packaged software producers

When supported task is generic Some IS and user staff to define requirements and evaluate packages

Enterprise-wide solu- tions vendors

For complete systems that cross functional boundaries

Some internal staff necessary but mostly need consultants

Cloud computing For instant access to an applica- tion; when supported task is generic

Few; frees up staff for other IT work

Open-source software When supported task is generic but cost is an issue

Some IS and user staff to define requirements and evaluate packages

In-house developers When resources and staff are available and system must be built from scratch

Internal staff necessary though staff size may vary

TABLE 2-2 Comparison of Six Different Sources of Software Components

M02_VALA1629_09_GE_C02.indd 55 08/04/2020 16:34

56 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

had to choose two criteria that would always be among the most important, those two would probably be vendor viability and vendor support. You do not want to get involved with a vendor that might not be in business tomorrow. Similarly, you do not want to license software from a vendor with a reputation for poor support. How you rank the importance of the remaining criteria will very much depend on the specific situation in which you find yourself.

Cost involves comparing the cost of developing the same system in-house with the cost of purchasing or licensing the software package. You should include a comparison of the cost of purchasing vendor upgrades or annual license fees with the costs you would incur to maintain your own software. Costs for purchasing and developing in- house can be compared based on economic feasibility measures (e.g., a present value can be calculated for the cash flow associated with each alternative).

Functionality refers to the tasks the software can perform and the mandatory, essential, and desired system features. Can the software package perform all or just some of the tasks your users need? If only some, can it perform the necessary core tasks? Note that meeting user requirements occurs at the end of the analysis phase because you cannot evaluate packaged software until user requirements have been gathered and structured. Purchasing application software is not a substitute for con- ducting the systems analysis phase; rather, purchasing software is part of one design strategy for acquiring the system identified during analysis.

As we said earlier, vendor support refers to whether vendor can provide support, and how much it can provide. Support occurs in the form of assistance with install- ing the software, training user and systems staff on the software, and providing help as problems arise after installation. Recently, many software companies have signifi- cantly reduced the amount of free support they will provide customers, so the cost to use telephone, on-site, fax, or computer bulletin-board support facilities should be considered. Related to support is the vendor’s viability. You do not want to get stuck with software developed by a vendor that might go out of business soon. This latter point should not be minimized. The software industry is quite dynamic, and innova- tive application software is created by entrepreneurs working from home offices—the classic cottage industry. Such organizations, even with outstanding software, often do not have the resources or business management ability to stay in business very long. Further, competitive moves by major software firms can render the products of smaller firms outdated or incompatible with operating systems. One software firm we talked to while developing this book was struggling to survive, just trying to make its software work on any supposedly Windows PC (given the infinite combination of video boards, monitors, BIOS chips, and other components). Keeping up with hardware and system software changes may be more than a small firm can handle, and good off-the-shelf application software can be lost.

Flexibility refers to how easy it is for you, or the vendor, to customize the software. If the software is not very flexible, your users may have to adapt the way they work to fit the software. Are they likely to adapt in this manner? Purchased software can be modi- fied in several ways. Sometimes the vendor will be willing to make custom changes for you, if you are willing to pay for the redesign and programming. Some vendors design the software for customization. For example, the software may include several different ways of processing data and, at installation time, the customer chooses which to initiate. Also, displays and reports may be easily redesigned if these modules are written in a fourth-generation language. Reports, forms, and displays may be easily customized using a process whereby your company name and chosen titles for reports, displays, forms, column headings, and so forth are selected from a table of parameters you provide. You may want to employ some of these same customization techniques for systems developed in-house so that the software can be easily adapted for different business units, product lines, or departments.

Documentation includes the user’s manual as well as technical documentation. How understandable and up-to-date is the documentation? What is the cost for mul- tiple copies, if required? Response time refers to how long it takes the software package

M02_VALA1629_09_GE_C02.indd 56 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 57

to respond to the user’s requests in an interactive session. Another measure of time would be how long it takes the software to complete running a job. Finally, ease of installation is a measure of the difficulty of loading the software and making it operational.

Of course, the criteria for software acquisition will vary with the type of system you are acquiring. For example, if you are thinking about licensing an ERP system, you will certainly take all of the prior criteria into account, but you will also want to investi- gate criteria that are specific to ERP systems. Verville, Bernadas, and Halingten (2005) studied organizations that had acquired ERP systems to discover what the critical fac- tors were for success. They found 10 success factors, with 5 related to the acquisition process and 5 related to the people in the process. They found the acquisition process had to be highly planned and structured, and it had to be rigorous. For the process to be successful, nothing could be overlooked during planning. It was important that two of the five success factors related to the process were completed before ERP vendors were contacted. These two factors were determining all of the system requirements and establishing the selection and evaluation criteria. They helped the organizations compose clear descriptions of their needs and evaluate bids from vendors. The fifth process-related criterion was obtaining accurate information. Information sources needed to be verified and cross-validated.

The other five success factors dealt with the people involved in the acquisition process. The first factor was clear and unambiguous authority. The person in charge of the process needed to be objective and a strong leader. Second, the composition of the acquisition team was important. The team needed to be diverse, with each mem- ber having a particular skill set that was complementary to those of the other team members. Third, it was considered important to approach the relationship with the vendor as a partnership, as opposed to an adversarial or neutral relationship. Given the complexity and cost of ERP systems, members of the acquiring organization would be working with the vendors for several years, so a comfortable working relationship was essential. Fourth, future users of the ERP system were active participants in the acquisition process. Lastly, the fifth success factor related to people in the process was user buy-in. In the companies studied, user buy-in often translated into user accep- tance of the system and even enthusiasm and excitement about it.

Validating Purchased Software Information

One way to get all of the information you want about a software package is to collect it from the vendor. Some of this information may be contained in the software docu- mentation and technical marketing literature. Other information can be provided upon request. For example, you can send prospective vendors a questionnaire, asking specific questions about their packages. This may be part of a request for proposal (RFP) or a request for quote (RFQ) process your organization requires when major purchases are made. Space does not permit us to discuss the topic of RFPs and RFQs here; you may wish to refer to purchasing and marketing texts if you are unfamiliar with such processes (additional references about RFPs and RFQs are found at the end of this chapter).

There is, of course, no replacement for actually using the software yourself and running it through a series of tests based on your software selection criteria. Remem- ber to test not only the software, but also the documentation, training materials, and even the technical support facilities. One requirement you can place on prospective software vendors as part of the bidding process is that they install (free or at an agreed- upon cost) their software for a limited amount of time on your computers. This way you can determine how their software works in your environment, not in some opti- mized environment they have for demonstration purposes.

One of the most reliable and insightful sources is other users of the software. Vendors will usually provide a list of customers (remember, they will naturally tell you about satisfied customers, so you may have to probe for a cross section of customers)

Request for proposal (RFP) A document provided to vendors that asks them to propose hardware and sys- tem software that will meet the require- ments of a new system.

M02_VALA1629_09_GE_C02.indd 57 08/04/2020 16:34

58 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

and people who are willing to be contacted by prospective customers. And here is where your personal network of contacts, developed through professional groups, college friends, trade associations, or local business clubs, can be a resource; do not hesitate to find some contacts on your own. Such current or former customers can provide a depth of insight on the use of a package at their organizations.

To gain a range of opinions about possible packages, you can use independent software testing and abstracting services that periodically evaluate software and collect user opinions. Such surveys are available for a fee either as subscription services or on demand (two popular services are Auerbach Publishers and DataPro); occasion- ally, unbiased surveys appear in trade publications. Often, however, articles in trade publications, even software reviews, are actually seeded by the software manufacturer and are not unbiased.

If you are comparing several software packages, you can assign scores for each package on each criterion and compare the scores using the quantitative method we demonstrate in Chapter 4 for comparing alternative system design strategies.

REUSE Reuse is the use of previously written software resources in new applications. Because so many bits and pieces of applications are relatively generic across applications, it seems intuitive that great savings can be achieved in many areas if those generic bits and pieces do not have to be written anew each time they are needed. Reuse should increase programmer productivity because being able to use existing soft- ware for some functions means they can perform more work in the same amount of time. Reuse should also decrease development time, minimizing schedule overruns. Because existing pieces of software have already been tested, reusing them should also result in higher-quality software with lower defect rates, decreasing maintenance costs.

Although reuse can conceivably apply to many different aspects of software, typi- cally it is most commonly applied to two different development technologies: object- oriented and component-based development. You were briefly introduced to object-oriented development in Chapter 1. Following is a brief introduction to object- oriented development. For example, consider an object class created to model an employee. The Employee object class would contain both the data about employees and the instructions necessary for calculating payroll for a variety of job types. The object class could be used in any application that dealt with employees, but if changes had to be made in calculating payroll for different types of employees, the changes would have to be made only to the object class and not to the various applications that used it. By definition, using the Employee object class in more than one application constitutes reuse.

Component-based development is similar to object-oriented development in that the focus is on creating general-purpose pieces of software that can be used interchangeably in many different programs. Components can be as small as objects or as large as pieces of software that handle single business functions, such as currency conversion. The idea behind component-based development is the assembly of an application from many different components at many different levels of complexity and size. Many vendors are working on developing libraries of components that can be retrieved and assembled, as needed, into desired applications.

Reuse has become a standard part of corporate systems development. However, for reuse to work in an organizational setting, many different issues must be addressed. The most important factors related to successful reuse include knowledge of the domain in which reuse is to occur, customer support, the commitment and under- standing of senior management, sound organizational processes, and skilled and expe- rienced developers (Bombonatti, Goulao, & Moreira, 2017). These same factors can be associated with reuse failure, if developers lack the appropriate domain knowledge, if senior management does not promote reuse, if there are no organization wide reuse

Reuse The use of previously written software resources, especially objects and com- ponents, in new applications.

M02_VALA1629_09_GE_C02.indd 58 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 59

standards, and if developers are resistant to reuse or lack the skills to make it success- ful. Royce (1998) argues that, due to the considerable costs of developing a reusable component, most organizations cannot compete economically with established com- mercial organizations that focus on selling components as their main line of business. Success depends on being able to leverage the cost of components across a large user and project base (Figure 2-4).

When an organization’s management decides to pursue reuse as a strategy, it is important for the organization to match its approach to reuse with its strategic busi- ness goals (Griss, 2003). The benefits of reuse grow as more corporate experience is gained from it, but so do the costs and the amount of resources necessary for reuse to work well. Software reuse has three basic steps: abstraction, storage, and recontextual- ization (Grinter, 2001). Abstraction involves the design of a reusable piece of software, starting from existing software assets or from scratch. Storage involves making software assets available for others to use. Although it sounds like a simple problem, storage can actually be very challenging. The problem is not simply putting software assets on a shelf; the problem is correctly labeling and cataloging assets so that others can find the ones they want to use. Once an asset has been found, recontextualization becomes important. This involves making the reusable asset understandable to developers who want to use it in their systems. Software is complex, and a software asset developed for a particular system under system-specific circumstances may not at all be the asset it appears to be. What appears to be a generic asset called “customer” may actually be something quite different, depending on the context in which it was developed. It may often appear to be easier to simply build your own assets rather than invest the time and energy it takes to establish a good understanding of software someone else has developed. A key part of a reuse strategy, as mentioned previously, is establishing rewards, incentives, and organizational support for reuse to help make it more worth- while than developing your own assets.

According to Griss (2003), an organization can take one of four approaches to reuse (Table 2-3). The ad hoc approach to reuse is not really an approach at all, at least from an official organizational perspective. With this approach, individuals are free to find or develop reusable assets on their own, and there are few, if any, organizational rewards for reusing assets. Storage is not an issue, because individuals keep track of and distribute their own software assets. For such an ad hoc, individually driven approach, it is difficult to measure any potential benefits to the company.

Another approach to reuse is facilitated reuse. With this approach, developers are not required to practice reuse, but they are encouraged to do so. The organization makes available some tools and techniques that enable the development and sharing

FIGURE 2-4 Investments necessary to achieve reus- able components

(Source: Royce, Walker, Software Project Management: A Unified Framework, 1st ed., ©1998. Reprinted and Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey.)

Development Cost and Schedule Resources

Number of Projects Using Reusable Assets

Many-project solution: High value per unit investment

5-project solution: 125% more cost and 150% more time

2-project solution: 50% more cost and 100% more time

1-project solution

M02_VALA1629_09_GE_C02.indd 59 08/04/2020 16:34

60 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

of reusable assets, and one or more employees may be assigned the role of evangelist to publicize and promote the program. Very little is done to track the quality and use of reusable assets, however, and the overall corporate investment is small.

Managed reuse is a more structured, and more expensive, mode of managing soft- ware reuse. With managed reuse, the development, sharing, and adoption of reusable assets is mandated. The organization establishes processes and policies for ensuring that reuse is practiced and that the results are measured. The organization also estab- lishes policies and procedures for ensuring the quality of its reusable assets. The focus is on identifying existing assets that can be potentially reused from various sources, including from utility asset libraries that come with operating systems, from companies that sell assets, from the open-source community, from internal repositories, from scouring existing legacy code, and so on.

The most expensive and extensive approach to reuse is designed reuse. In addi- tion to mandating reuse and measuring its effectiveness, the designed reuse approach takes the extra step of mandating that assets be designed for reuse as they are being designed for specific applications. The focus is more on developing reusable assets than on finding existing assets that might be candidates for reuse. A corporate reuse office may be established to monitor and manage the overall methodology. Under such an approach, as much as 90 percent of software assets may be reused across dif- ferent applications.

Each approach to reuse has its advantages and disadvantages. No single approach is a silver bullet that will solve the reuse puzzle for all organizations and for all situa- tions. Successful reuse requires an understanding of how reuse fits within larger orga- nizational goals and strategies, as well as an understanding of the social and technical world into which the reusable assets must fit.

Approach Reuse Level Cost Policies and Procedures

Ad hoc None to low Low None. Facilitated Low Low Developers are encouraged to reuse but are

not required to do so. Managed Moderate Moderate Development, sharing, and adoption of

reusable assets are mandated; organiza- tional policies are established for docu- mentation, packaging, and certification.

Designed High High Reuse is mandated; policies are put in place so that reuse effectiveness can be mea- sured; code must be designed for reuse during initial development, regardless of the application it is originally designed for; there may be a corporate office for reuse.

(Source: Based on Griss, 2003.)

TABLE 2-3 Four Approaches to Reuse

SUMMARY As a systems analyst, you must be aware of where you can obtain software that meets some or all of an organiza- tion’s needs. You can obtain application (and system) software from information technology services firms, packaged software providers, vendors of enterprise- wide solution software, cloud computing vendors, and open-source software providers, as well as from inter- nal systems development resources, including the reuse of existing software components. You can even hire an

organization to handle all of your systems development needs, which is called outsourcing. You must also know the criteria to use when choosing among off-the-shelf software products. These criteria include cost, func- tionality, vendor support, vendor viability, flexibility, documentation, response time, and ease of installation. Requests for proposals are one way you can collect more information about system software, its performance, and its costs.

M02_VALA1629_09_GE_C02.indd 60 08/04/2020 16:34

CHAPTER 2 The OriginS Of SOfTware 61

KEY TERMS

2.1 Cloud computing 2.2 Enterprise resource planning

(ERP) systems

2.3 Outsourcing 2.4 Request for proposal (RFP)

2.5 Reuse

REVIEW QUESTIONS 2.6 What is outsourcing? Identify two outsourcing arrange-

ments. Identify two reasons for outsourcing.

2.7 List the six sources of software used by organizations.

2.8 Why would an analyst need to have an awareness of out- sourcing as an alternative to handling IT services in-house?

2.9 Why would an organization outsource information systems operations?

2.10 Briefly explain why systems development is more difficult now than it was in the past.

2.11 What are enterprise resource planning systems? How do they differ from traditional approaches? Identify three enterprise resource planning system vendors.

2.12 List the various development specializations and provide an example from the leading software firms for each.

PROBLEMS AND EXERCISES 2.13 Research how cloud computing can be used as a PaaS.

2.14 Search the Internet for reasons for outsourcing other than those listed in this chapter. Explain each of these reasons.

2.15 An organization that deals with a large amount of data wants to implement a database management system (DBMS) to properly store and manage it. This organization has short- listed Oracle, MySQL, and Microsoft SQL Server as the top

DBMS tools available in the market. List the features pro- vided by these DBMS tools.

2.16 Suppose you are an IT manager at your institute. List any two open-source software packages besides Microsoft Office that can be used for routine work in your office. Download both and test them out to decide which one is better suited to your work requirements.

FIELD EXERCISES 2.17 Interview businesspeople who participate in the purchase

of off-the-shelf software in their organizations. Review with them the criteria for selecting off-the-shelf software pre- sented in this chapter. Have them prioritize the list of cri- teria as they are used in their organization and provide an explanation of the rationale for the ranking of each crite- rion. Ask them to list and describe any other criteria that are used in their organization.

2.18 Obtain copies of actual RFPs used for information systems developments and/or purchases. If possible, obtain RFPs

from public and private organizations. Find out how they are used. What are the major components of these proposals? Do these proposals seem to be useful? Why or why not? How and why do RFPs from public and private organizations differ?

2.19 Contact an organization that has implemented or is imple- menting an integrated ERP application. Why did it choose this design strategy? How has it managed this development project differently from prior large projects? What organi- zational changes have occurred due to this design strategy? How long did the implementation last, and why?

Match each of the key terms above with the definition that best fits it.

____The practice of turning over responsibility for some or all of an organization’s information systems applications and operations to an outside firm.

____A system that integrates individual traditional business func- tions into a series of modules so that a single transaction occurs seamlessly within a single information system, rather than several separate systems.

____A document that is provided to vendors to ask them to propose hardware and system software that will meet the requirements of your new system.

____The use of previously written software resources, especially objects and components, in new applications.

____The provision of computing resources, including applica- tions, over the Internet so customers do not have to invest in the computing infrastructure needed to run and maintain computing resources.

M02_VALA1629_09_GE_C02.indd 61 08/04/2020 16:34

62 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

ATKearney. (2017). The widening impact of automation. Retrieved March 26, 2018 from http://www.atkearney.com/ documents/20152/793366/The+Widening+Impact+of+ Automation.pdf/.

Banker, R. D., Davis, G. B., & Slaughter, S. A. (1998). Software development practices, software complexity, and software maintenance performance: A field study. Management Science, 44(4), 433–50.

Bombonatti, D., Goulao, M., & Moreira, A. (2017). Synergies and tradeoffs in software reuse–A systematic mapping study. Software: Practice and Experience, 47, 943–957.

Computer History Museum. (2003). Timeline of computer his- tory. Retrieved February 14, 2009 from http://www.com- puterhistory.org.

Gartner. (2017). Gartner says worldwide public cloud service mar- ket to grow 18 percent in 2017. Accessed March 26, 2018 from http://www.gartner.com.

Grinter, R. E. (2001). From local to global coordination: Lessons from software reuse. In C. A. Ellis (Ed.), Group’01: Proceedings of the 2001 International ACM SIGGROUP Conference on Support- ing Group Work (pp. 144–53). Boulder, CO: Association for Computing Machinery.

Griss, M. (2003). Reuse comes in several flavors [Flashline white paper]. Retrieved February 10, 2009 from http://www.flash- line.com.

Ketler, K., & Willems, J. R. (1999). A study of the outsourcing decision: Preliminary results. In Proceedings of the 1999 ACM SIGCPR Conference on Computer Personnel Research (pp. 182–89). Boulder, CO: Association for Computing Machinery.

kfc. (2012). The hidden risk of a meltdown in the cloud.” Technology Review. Retrieved April 17, 2012 from http://www. technologyreview.com/printer_friendly_blog.aspx?id=27642.

King, R. (2008a, April 7). The new economics of outsourcing. BusinessWeek. Retrieved August 25, 2012 from http://www. businessweek.com/stories/2008-04-07/the-new-economics- ofoutsourcingbusinessweek-business-news-stock-market-and- financial-advice.

Moyle, E., & Kelley, D. (2011). Cloud security: Understand the risks before you make the move. InformationWeek Analytics. Retrieved April 14, 2012 from http://analytics.information- week.com.

Netcraft. (2017). September 2017 Web Server Survey. Retrieved March 30, 2018 from http://news.netcraft.com/ archives/2017/09/11/september-2017-web-server-survey. html.

Pang, A. (2017). Top 10 ERP software vendors and market fore- cast 2016-2021. Retrieved March 26, 2018 from http://www. appsruntheworld.com.

Royce, W. (1998). Software project management: A unified framework. Boston: Addison-Wesley.

Statistica. (2018). Global outsourcing industry revenue from 2010 to 2017, by service type (in billion U.S. dollars). Retrieved March 26, 2018 from http://www.statista.com/statistics/189800/ global-outsourcing-industry-revenue-by-service-type/.

Verville, J., Bernadas, C., & Halingten, A. (2005). So you’re thinking of buying an ERP? Ten critical factors for success- ful acquisition. Journal of Enterprise Information Management, 18(6), 665–77.

REFERENCES

M02_VALA1629_09_GE_C02.indd 62 08/04/2020 16:34

http://www.atkearney.com/documents/20152/793366/The+Widening+Impact+of+Automation.pdf

http://www.computerhistory.org

http://www.gartner.com

http://www.flashline.com

http://www.technologyreview.com/printer_friendly_blog.aspx?id=27642

http://www.businessweek.com/stories/2008-04-07/the-new-economics-of-outsourcing-businessweek-business-news-stock-market-and-financial-advice

http://analytics.information-week.com

http://news.netcraft.com/archives/2017/09/11/september-2017-web-server-survey.html

http://www.appsruntheworld.com

http://www.statista.com/statistics/189800/global-outsourcing-industry-revenue-by-service-type

http://www.atkearney.com/documents/20152/793366/The+Widening+Impact+of+Automation.pdf

http://www.technologyreview.com/printer_friendly_blog.aspx?id=27642

http://www.businessweek.com/stories/2008-04-07/the-new-economics-of-outsourcing-businessweek-business-news-stock-market-and-financial-advice

http://news.netcraft.com/archives/2017/09/11/september-2017-web-server-survey.html

http://www.appsruntheworld.com

http://www.statista.com/statistics/189800/global-outsourcing-industry-revenue-by-service-type

CHAPTER 2 The OriginS Of SOfTware 63

Just then, as Jim was trying to decide if he needed a big- ger TV, Ella Whinston, the CEO at Petrie, walked into his office. “How’s it going, Jim? Joe keeping you busy?” Joe was Joe Swanson, Jim’s boss, the director of IT. Joe was away for the week, at a meeting in Tucson, Arizona. Jim quickly pulled his feet off his desk.

“Hi, Ella. Oh, yeah, Joe keeps me busy. I’ve got to get through the entire corporate strategic IT plan before he gets back—he’s going to quiz me—and then there’s the new help desk training we’re going to start next week.”

“I didn’t know we had a strategic IT plan,” Ella teased. “Anyway, what I came in here for is to give you some good news. I want you to be the project manager for a project that’s crucial to our corporate survival.”

“Me?” Jim said, “But I just got here.” “Who better than you? You have a different perspective,

new ideas. You aren’t chained down by the past and by the Petrie way of doing things, like the rest of us. Not that it matters, since you don’t have a choice. Joe and I both agree that you’re the best person for the job.”

“So,” Jim asked, “what’s the project about?” “Well,” Ella began, “the executive team has decided that

the number one priority we have right now is to not only survive but to thrive and prosper, and the way to do that is to develop closer relationships with our customers. The person on the executive team who’s even more excited about this than me is John Smith, head of marketing. We want to attract new customers, like all of our competitors. But also like our competitors, we want to keep our custom- ers for life, kind of like a frequent-flier program, but better. Better for us and for our loyal customers. And we want to reward most the customers who spend the most. We’re call- ing the project ‘No Customer Escapes.’”

“I hope that’s only an internal name,” Jim joked. “Seri- ously, I can see how something like this would be good for Petrie, and I can see how IT would play an important, no, crucial role in making something like this happen. So, what’s the next step in getting the project approved?”

PETRIE ELECTRONICS

Chapter 2: The Origins of Software

Jim Watanabe looked around his new office. He couldn’t believe that he was the assistant director of information technology at Petrie Electronics, his favorite consumer elec- tronics retail store. He always bought his new DVDs and video games for his Xbox 360 at Petrie. In fact, he bought his Blu-ray player and his Xbox 360 at Petrie, along with his surround sound system and his 40-inch flat-screen HD LED TV. And now he worked there, too. The employee discount was a nice perk1 of his new job, but he was also glad that his technical and people skills were finally recognized by the people at Petrie. He worked for five years at Broadway Entertainment Company as a senior systems analyst, and it was clear that he was not going to be promoted there. He was really glad he posted his résumé on Monster.com and that now he had a bigger salary and a great job with more responsibility at Petrie. Petrie Electronics started as a single electronics store in 1984 in San Diego, California. The store was started by Jacob Rosenstein in a strip mall. It was named after Rob Petrie, the TV writer played by Dick Van Dyke in the TV show of the same name. Rosenstein always liked that show. When he had grown the store to a chain of 13 locations in Southern California, the business became too much for Rosenstein to handle. He sold out in 1992, for a handsome profit, to the Matsutoya Corporation, a huge Japanese con- glomerate that saw the chain of stores as a place to sell its many consumer electronics goods in the United States.

Matsutoya aggressively expanded the chain to 218 stores nationwide by the time they sold it in 2002, for a handsome profit, to Sam and Harry’s, a maker and seller of ice cream. Sam and Harry’s was looking for a way to diversify and invest the considerable cash they made creating and sell- ing ice cream, with flavors named after actors and actresses, like their best-selling Lime Neeson and Jim Carrey-mel. Sam and Harry’s brought in professional management to run the chain, and since they bought it, they had added 15 more stores, including 1 in Mexico and 3 in Canada. Even though they originally wanted to move the headquarters to their home-base state of Delaware, Sam and Harry decided to keep Petrie headquartered in San Diego.

The company had made some smart moves and had done well, Jim knew, but he also knew that competition was fierce. Petrie competitors included big electronics retail chains like BestBuy. In California, Fry’s was a ferocious competitor. Other major players in the arena included the electronics departments of huge chains like Walmart and Target and online vendors like Amazon.com. Jim knew that part of his job in IT was to help the company grow and prosper and beat the competition—or at least survive.

Case Questions

2.20 How do information systems projects get started in organizations?

2.21 How are organizational information systems related to company strategy? How does strategy affect the information systems a company develops and uses?

2.22 Research customer loyalty programs in retail firms. How common are they? What are their primary features?

2.23 What do you think Jim’s next step would be? Why? 2.24 Why would a systems analyst new to a company be a

good choice to lead an important systems develop- ment effort?1perquisite

M02_VALA1629_09_GE_C02.indd 63 08/04/2020 16:34

by global outsourcing partners that must be integrated into an organization’s existing portfolio of applications is now common practice (Fuller et al., 2018; Gold, 2016; Martinelli, et al., 2017). Working with vendors to supply applications, with customers or suppliers to integrate sys- tems, or with a broader and more diverse user community requires that project managers be highly skilled. Conse- quently, it is important that you gain an understanding of the project management process; this will become a critical skill for your future success.

In this chapter, we focus on the systems analyst’s role in managing information systems projects and will refer to this role as the project manager. The first section will provide the background for Pine Valley Furniture (PVF), a manufactur- ing company that we will visit throughout the remainder of the book. We will then provide you with an understanding of the project manager’s role and the project management pro- cess. The discussion then turns to techniques for reporting project plans using Gantt charts and network diagrams. The chapter will conclude with a discussion of the use of commer- cially available project management software that can be used to assist with a wide variety of project management activities.

PINE VALLEY FURNITURE COMPANY BACKGROUND PVF manufactures high-quality wood furniture and dis- tributes it to retail stores throughout the United States. Its product lines include dinette sets, stereo cabinets, wall

In Chapters 1 and 2, we introduced the five phases of the systems development life cycle (SDLC) and explained how an information systems project moves through those five phases, in some cases repeatedly. In this chapter, we focus on the systems analyst’s role as project manager of an information systems project. Throughout the SDLC, the project manager is responsible for initiating, planning, executing, and closing down the systems development project. Project management is arguably the most impor- tant aspect of an information systems development proj- ect. Effective project management helps to ensure that systems development projects meet customer expectations and are delivered within budget and time constraints.

Today, there is a shift in the types of projects most firms are undertaking, which makes project management much more difficult and even more critical to project suc- cess (Fuller, Valacich, George, & Schneider, 2018; Galin, 2018; Keane, 2017). For example, in the past, organiza- tions focused much of their development on very large, custom-designed, stand-alone applications. Today, much of the systems development effort in organizations focuses on implementing packaged software such as enterprise resource planning (ERP) and data warehousing systems. Existing legacy applications are also being modified so that business-to-business transactions can occur seamlessly over the Internet. New Web-based interfaces are being added to existing legacy systems so that a broader range of users, often distributed globally, can access corporate information and systems. Additionally, software developed

Introduction

3.3 explain how commercial project management soft- ware packages can be used to assist in represent- ing and managing project schedules.

Learning Objectives After studying this chapter, you should be able to

3.1 explain the process of managing an information systems project, including project initiation, project planning, project execution, and project closedown;

3.2 describe how to represent and schedule project plans using Gantt charts and network diagrams; and

Managing the Information Systems Project3

M03_VALA1629_09_GE_C03.indd 64 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 65

units, living room furniture, and bedroom furniture. In the early 1990s, PVF’s founder, Alex Schuster, started to make and sell custom furniture in his garage. Alex managed invoices and kept track of customers by using file folders and a filing cabinet. By 1994, business expanded and Alex had to rent a warehouse and hire a part-time bookkeeper. PVF’s product line had multiplied, sales volume had doubled, and staff had increased to 50 employees. By 2000, PVF moved into its third and present location. Due to the added complexity of the company’s operations, Alex reorganized the company into the following functional areas:

• Manufacturing, which was further subdivided into three separate functions— Fabrication, Assembling, and Finishing

• Sales • Orders • Accounting • Purchasing

Alex and the heads of the functional areas established manual information sys- tems, such as accounting ledgers and file folders, which worked well for a time. Even- tually, however, PVF selected and installed a network server to automate invoicing, accounts receivable, and inventory control applications.

When the applications were first computerized, each separate application had its own individual data files tailored to the needs of each functional area. As is typical in such situations, the applications closely resembled the manual systems on which they were based. Three computer applications at PVF are depicted in Figure 3-1: order filling, invoicing, and payroll. In the late 2000s, PVF formed a task force to study the possibility of moving to a database approach. After a preliminary study, manage- ment decided to convert its information systems to such an approach. The company upgraded its network server and implemented a centralized database management system. Today, PVF has successfully deployed an integrated, company-wide database and has converted its applications to work with the database. However, PVF is continu- ing to grow at a rapid rate, putting pressure on its current application systems.

PINE VALLEY FURNITURE

FIGURE 3-1 Three computer applications at PVF: order filling, invoicing, and payroll

(Hoffer, Jeffrey A.; Venkataraman, Ramesh; Topi, Heikki, Modern Database Management, 11th Ed., ©2016, p. 8. Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Payroll System

Invoicing System

Order Filling System

Program A

Program B

Program C

Program A

Program B

Program A

Program B

Accounting DepartmentOrders Department Payroll Department

Customer Master

File

Inventory Pricing

File

Inventory Master

File

Customer Master

File

Back Order File

Employee Master

File

M03_VALA1629_09_GE_C03.indd 65 08/04/2020 16:35

66 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

The computer-based applications at PVF support its business processes. When customers order furniture, their orders must be processed appropriately: Furniture must be built and shipped to the right customer and the right invoice mailed to the right address. Employees have to be paid for their work. Given these tasks, most of PVF’s computer-based applications are located in the accounting and financial areas. The applications include order filling, invoicing, accounts receivable, inventory con- trol, accounts payable, payroll, and general ledger. At one time, each application had its own data files. For example, there was a customer master file, an inventory master file, a back-order file, an inventory pricing file, and an employee master file. The order filling system used data from three files: customer master, inventory master, and back order. Today, however, all systems are designed and integrated through a company-wide database in which data are organized around entities, or subjects, such as customers, invoices, and orders.

PVF, like many firms, decided to develop its application software in-house; that is, it hired staff and bought the computer hardware and software necessary to build application software suited to its own needs. (Other methods used to obtain appli- cation software were discussed in Chapter 2.) Although PVF continues to grow at a rapid rate, market conditions are becoming extremely competitive, especially with the advent of the Internet and the Web. Let’s see how a project manager plays a key role in developing a new information system for PVF.

MANAGING THE INFORMATION SYSTEMS PROJECT Project management is an important aspect of the development of information sys- tems and a critical skill for a systems analyst. The focus of project management is to ensure that systems development projects meet customer expectations and are deliv- ered within budget and time constraints.

The project manager is a systems analyst with a diverse set of skills—management, leadership, technical, conflict management, and customer relationship—who is responsible for initiating, planning, executing, and closing down a project. As a proj- ect manager, your environment is one of continual change and problem solving. In some organizations, the project manager is a very experienced systems analyst, whereas in others, both junior and senior analysts are expected to take on this role, manag- ing parts of a project or actively supporting a more senior colleague who assumes the project manager role. Understanding the project management process is a critical skill for your future success.

Creating and implementing successful projects requires managing the resources, activities, and tasks needed to complete the information systems project. A project is a planned undertaking of a series of related activities to reach an objective that has a beginning and an end. The first question you might ask yourself is “Where do projects come from?” and, after considering all the different things that you could be asked to work on within an organization, “How do I know which projects to work on?” The ways in which each organization answers these questions vary.

In the rest of this section, we describe the process followed by Juanita Lopez and Chris Martin during the development of PVF’s Purchasing Fulfillment System. Juanita works in the Order department, and Chris is a systems analyst.

Juanita observed problems with the way orders were processed and reported: Sales growth had increased the workload for the Manufacturing department, and the current systems no longer adequately supported the tracking of orders. It was becom- ing more difficult to track orders and get the right furniture and invoice to the right customers. Juanita contacted Chris, and together they developed a system that cor- rected these Order department problems.

The first deliverable, or end product, produced by Chris and Juanita was a Sys- tem Service Request (SSR), a standard form PVF uses for requesting systems develop- ment work. Figure 3-2 shows an SSR for a purchasing fulfillment system. The form

Project manager A systems analyst with a diverse set of skills—management, leadership, techni- cal, conflict management, and customer relationship—who is responsible for ini- tiating, planning, executing, and closing down a project.

Project A planned undertaking of related activities to reach an objective that has a beginning and an end.

PINE VALLEY FURNITURE

Deliverable An end product of an SDLC phase.

M03_VALA1629_09_GE_C03.indd 66 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 67

includes the name and contact information of the person requesting the system, a statement of the problem, and the name and contact information of the liaison and sponsor.

This request was then evaluated by the Systems Priority Board of PVF. Because all organizations have limited time and resources, not all requests can be approved. The board evaluates development requests in relation to the business problems or opportunities the system will solve or create; it also considers how the proposed project fits within the organization’s information systems architecture and long-range development plans. The review board selects those projects that best meet overall organizational objectives (we learn more about organizational objectives in Chap- ter 4.) In the case of the Purchasing Fulfillment System request, the board found merit in the request and approved a more detailed feasibility study. A feasibility study, which is conducted by the project manager, involves determining if the infor- mation system makes sense for the organization from an economic and operational standpoint. The study takes place before the system is constructed. Figure 3-3 is a graphical view of the steps followed during the project initiation of the Purchasing Fulfillment System.

In summary, systems development projects are undertaken for two primary rea- sons: to take advantage of business opportunities and to solve business problems. Taking advantage of an opportunity might mean providing an innovative service to customers through the creation of a new system. For example, PVF may want to create a Website so that customers can easily access its catalog and place orders at any time.

Feasibility study A study that determines if the proposed information system makes sense for the organization from an economic and operational standpoint.

FIGURE 3-2 System Service Request for the Pur- chasing Fulfillment System with name and contact information of the person requesting the system, a statement of the problem, and the name and contact information of the liaison and sponsor

Pine Valley Furniture System Service Request

REQUESTED BY

DEPARTMENT

LOC ATION

CON TACT

TYPE OF REQUEST

PROBLEM STATEMENT

URGENCY

DATEJuanita Lopez

Purchasing, Manufacturing Support

Headquarters, 1-322

Tel: 4-3267 FAX: 4-3270 e-mail: jlopez

October 1, 2020

[

[ [

]

] ]

[

[ [

]

] ]

New System

System Enhancement System Error Correction

Immediate – Operations are impaired or opportunity lost Problems exist, but can be worked around Business losses can be tolerated until new system installed

Sales growth at PVF has caused greater volume of work for the manufacturing support unit within Purchasing. Further, more concentration on customer service has reduced manufacturing lead times, which puts more pressure on purchasing activities. In addition, cost-cutting measures force Purchasing to be more aggressive in negotiating terms with vendors, improving delivery times, and lowering our investments in inventory. The current modest systems support for Manufacturing/Purchasing is not responsive to these new business conditions. Data are not available, information cannot be summarized, supplier orders cannot be adequately tracked, and commodity buying is not well supported. PVF is spending too much on raw materials and not being responsive to manufacturing needs.

SERVICE REQUEST

I request a thorough analysis of our current operations with the intent to design and build a completely new information system. This system should handle all purchasing transactions, support display and reporting of critical purchasing data, and assist purchasing agents in commodity buying.

IS LIAISON

SPONSOR

TO BE COMPLETED BY SYSTEMS PRIORITY BOARD [

[ [ [

]

] ] ]

Request approved

Recommend revision Suggest user development Reject for reason

Assigned to Start date

Chris Martin (Tel: 4-6204 FAX: 4-6200 e-mail: cmartin)

Sal Divario, Director, Purchasing

M03_VALA1629_09_GE_C03.indd 67 08/04/2020 16:35

68 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Solving a business problem could involve modifying the way an existing system pro- cesses data so that more accurate or timely information is provided to users. For example, a company such as PVF may create a password-protected intranet site that contains important announcements and budget information. Of course, projects are not always initiated for the aforementioned rational reasons (taking advantage of business opportunities or solving business problems). For example, in some instances, organizations and governments undertake projects to spend resources, to attain or pad budgets, to keep people busy, or to help train people and develop their skills. Our focus in this chapter is not on how and why organizations identify projects but on the management of projects once they have been identified.

Once a potential project has been identified, an organization must determine the resources required for its completion. This is done by analyzing the scope of the project and determining the probability of successful completion. After getting this information, the organization can then determine whether taking advantage of an opportunity or solving a particular problem is feasible within time and resource constraints. If deemed feasible, a more detailed project analysis is then conducted. As you will see, the ability to determine the size, scope, and resource requirements of a project is just one of the many skills that a project manager must possess. A project manager is often thought of as a juggler keeping aloft many balls, which reflect the various aspects of a project’s development, as depicted in Figure 3-4.

To successfully orchestrate the construction of a complex information sys- tem, a project manager must have interpersonal, leadership, and technical skills. Table 3-1 lists the project manager’s common skills and activities. Note that many of the skills are related to personnel or general management, not simply technical skills. Table 3-1 shows that not only does an effective project manager have varied skills, but he or she is also the most instrumental person to the successful comple- tion of any project.

FIGURE 3-3 A graphical view of the five steps followed during the project initiation of the Purchasing Fulfillment System

(Sources: Top to bottom: ProStockStudio/ Shutterstock; Sheff/Shutterstock; Wavebreakmedia/Shutterstock; Rob Marmion/123RF; wavebreakmedia/ Shutterstock)

1. Juanita observed problems with the existing purchasing system.

2. Juanita contacted Chris within the IS development group to initiate a System Service Request.

3. SSR was reviewed and approved by Systems Priority Board.

4. Steering committee was assigned to oversee project.

5. Detailed project plan was developed and executed.

M03_VALA1629_09_GE_C03.indd 68 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 69

FIGURE 3-4 A project manager juggles numerous activities

(Source: Media Bakery13/Shutterstock)

Customer and Management Expectations

Technological Change

Documentation and

Communication

Contractors and Vendors

Managing People

Methodologies and Tools

Time and Resource

Constraints

Systems Development

Life Cycle

Organizational Change and Complexity

The Art of

Project Management

Activity Description Skill

Leadership Influencing the activities of others toward the attainment of a common goal through the use of intelligence, personality, and abilities

Communication; liaison between management, users, and developers; assigning activities; monitoring progress

Management Getting projects completed through the effec- tive utilization of resources

Defining and sequencing activities; communicating expectations; assigning resources to activities; monitoring outcomes

Customer relations Working closely with customers to ensure that project deliverables meet expectations

Interpreting system requests and specifications; site preparation and user training; contact point for customers

Technical problem solving

Designing and sequencing activities to attain project goals

Interpreting system requests and specifications; defining activities and their sequence; making trade-offs between alternative solutions; designing solutions to problems

Conflict management Managing conflict within a project team to assure that conflict is not too high or too low

Problem solving; smoothing out personality differences; compromising; goal setting

Team management Managing the project team for effective team performance

Communication within and between teams; peer evaluations; conflict resolution; team building; self-management

Risk and change management

Identifying, assessing, and managing the risks and day-to-day changes that occur during a project

Environmental scanning; risk and opportunity iden- tification and assessment; forecasting; resource redeployment

TABLE 3-1 Common Activities and Skills of a Project Manager

M03_VALA1629_09_GE_C03.indd 69 08/04/2020 16:35

70 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

The remainder of this chapter will focus on the project management process, which involves four phases:

1. Initiating the project 2. Planning the project 3. Executing the project 4. Closing down the project

Several activities must be performed during each of these four phases. Following this formal project management process greatly increases the likelihood of project success.

Initiating a Project

During project initiation, the project manager performs several activities to assess the size, scope, and complexity of the project and to establish procedures to support subsequent activities. Depending on the project, some initiation activities may be unnecessary and some may be very involved. The types of activities you will perform when initiating a project are summarized in Figure 3-5 and described next.

1. Establishing the project initiation team. This activity involves organizing an initial core of project team members to assist in accomplishing the project initiation activities (Chua et al., 2012; Fuller et al, 2018; Verma, 1996; 1997). For example, during the Purchasing Fulfillment System project at PVF, Chris Martin was assigned to support the Purchasing department. It is a PVF policy that all initiation teams consist of at least one user representative, in this case Juanita Lopez, and one member of the information systems (IS) development group. Therefore, the project initiation team consisted of Chris and Juanita; Chris was the project manager.

2. Establishing a relationship with the customer. A thorough understanding of your cus- tomer builds stronger partnerships and higher levels of trust. At PVF, manage- ment has tried to foster strong working relationships between business units (like Purchasing) and the IS development group by assigning a specific individual to work as a liaison between both groups. Because Chris had been assigned to the Purchasing unit for some time, he was already aware of some of the problems with the existing purchasing systems. PVF’s policy of assigning specific individuals to each business unit helped to ensure that both Chris and Juanita were comfortable working together prior to the initiation of the project. Many organizations use a similar mechanism for establishing relationships with customers.

3. Establishing the project initiation plan. This step defines the activities required to organize the initiation team while it is working to define the goals and scope of the project (Abdel-Hamid, Sengupta, & Swett, 1999; Fuller et al., 2018). Chris’s role was to help Juanita translate her business requirements into a written request for an improved information system. This required the collection, analysis, organiza- tion, and transformation of a lot of information. Because Chris and Juanita were already familiar with each other and their roles within a development project, they

Project management A controlled process of initiating, plan- ning, executing, and closing down a project.

Project initiation The first phase of the project manage- ment process in which activities are performed to assess the size, scope, and complexity of the project and to estab- lish procedures to support later project activities.

PINE VALLEY FURNITURE

FIGURE 3-5 Six project initiation activities

Project Initiation

1. Establishing the Project Initiation Team

2. Establishing a Relationship with the Customer

3. Establishing the Project Initiation Plan

4. Establishing Management Procedures

5. Establishing the Project Management Environment and Project Workbook

6. Developing the Project Charter

M03_VALA1629_09_GE_C03.indd 70 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 71

next needed to define when and how they would communicate, define deliver- ables and project steps, and set deadlines. Their initiation plan included agendas for several meetings. These steps eventually led to the creation of their SSR form.

4. Establishing management procedures. Successful projects require the development of effective management procedures (Fuller et al., 2018). Within PVF, many of these management procedures had been established as standard operating procedures by the Systems Priority Board and the IS development group. For example, all project development work is charged back to the functional unit requesting the work. In other organizations, each project may have unique procedures tailored to its needs. Yet, in general, when establishing procedures, you are concerned with developing team communication and reporting procedures, job assignments and roles, project change procedures, and determining how project funding and billing will be handled. It was fortunate for Chris and Juanita that most of these procedures were already established at PVF, allowing them to move on to other project activities.

5. Establishing the project management environment and project workbook. The focus of this activity is to collect and organize the tools that you will use while managing the project and to construct the project workbook (Fuller et al., 2018). Diagrams, charts, and system descriptions provide much of the project workbook contents. Thus, the project workbook serves as a repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards established by the project team (Dinsmore & Cabanis-Brewin, 2006; Rettig, 1990). The project workbook is an online repository of all project-related documents that is accessible by all team members. This repository is useful for project audits, orientation of new team members, communication with management and customers, identifying future projects, and performing post-project reviews. The establishment and diligent capturing of all relevant project information in the workbook are two of the most important activities you will perform as project manager.

Figure 3-6 shows the online project workbook for the Purchasing Fulfillment System. The project workbook can be as simple as a shared online directory (e.g., using Dropbox, iCloud, SharePoint, etc.), or can be an elaborate with password

Project workbook An online repository for all project- related documents that is used for performing project audits, orienting new team members, communicating with management and customers, identifying future projects, and performing post- project reviews.

FIGURE 3-6 The project workbook for the Purchasing Fulfillment System project contains nine key elements

(Source: A-R-T/Shutterstock)

Pine Valley Furniture Information Systems Development Group Project: Purchasing Fulfillment System

1. 2. 3. 4. 5. 6. 7. 8. 9.

Project overview Initiation plan and SSR Project scope and risks Management procedures Data descriptions Process descriptions Team correspondence Project charter Project schedule

Logged in: Chris Martin

M03_VALA1629_09_GE_C03.indd 71 08/04/2020 16:35

72 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

protection and security levels. The best feature of having your project workbook online is that it enables project members and customers to review a project’s status and all related information continually.

6. Developing the project charter. The project charter is a short (typically one page), high-level document prepared for the customer that describes what the project will deliver and outlines many of the key elements of the project (Fuller et al., 2018). A project charter can vary in the amount of detail it contains, but it often includes the following elements:

• Project title and date of authorization • Project manager name and contact information • Customer name and contact information • Projected start and completion dates • Key stakeholders, project role, and responsibilities • Project objectives and description • Key assumptions or approach • Signature section for key stakeholders

The project charter ensures that both you and your customer gain a common understanding of the project. It is also a very useful communication tool; it helps to announce to the organization that a particular project has been chosen for develop- ment. A sample project charter is shown in Figure 3-7.

Project initiation is complete once these six activities have been performed. Before moving on to the next phase of the project, the work performed during project initiation is reviewed at a meeting attended by management, customers, and project team members. An outcome of this meeting is a decision to continue, modify, or abandon the project. In the case of the Purchasing Fulfillment System project at PVF, the board accepted the SSR and selected a project steering committee to monitor project progress and to provide guidance to the team members during subsequent activities. If the scope of the project is modified, it may be necessary to return to proj- ect initiation activities and collect additional information. Once a decision is made to continue the project, a much more detailed project plan is developed during the project planning phase.

Planning the Project

The next step in the project management process is project planning. Research has found a positive relationship between effective project planning and positive project outcomes (Fuller et al., 2018; Guinan, Cooprider, & Faraj, 1998; Keane, 2017). Project planning involves defining clear, discrete activities and the work needed to complete each activity within a single project. It often requires you to make numerous assump- tions about the availability of resources such as hardware, software, and personnel. It is much easier to plan nearer-term activities than those occurring in the future. In actual fact, you often have to construct longer-term plans that are more general in scope and nearer-term plans that are more detailed. The repetitive nature of the project management process requires that plans be constantly monitored throughout the project and periodically updated (usually after each phase), based upon the most recent information.

Figure 3-8 illustrates the principle that nearer-term plans are typically more specific and firmer than longer-term plans. For example, it is virtually impossible to rigorously plan activities late in the project without first completing the earlier activi- ties. Also, the outcome of activities performed earlier in the project is likely to affect later activities. This means that it is very difficult, and very likely inefficient, to try to plan detailed solutions for activities that will occur far into the future.

As with the project initiation process, varied and numerous activities must be performed during project planning. For example, during the Purchasing Fulfillment

Project charter A short document prepared for the customer during project initiation that describes what the project will deliver and outlines generally at a high level all work required to complete the project.

Project planning The second phase of the project management process that focuses on defining clear, discrete activities and the work needed to complete each activity within a single project.

PINE VALLEY FURNITURE

M03_VALA1629_09_GE_C03.indd 72 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 73

Pine Valley Furniture Prepared: November 2, 2020

Project Charter

Project Name: Customer Tracking System Project Manager: Jim Woo ([email protected])

Customer: Marketing

Project Sponsor: Jackie Judson ([email protected])

Project Start/End (projected): 10/2/20–2/1/21

Project Overview:

This project will implement a customer tracking system for the marketing department. The purpose of this system is to automate the … to save employee time, reduce errors, have more timely information ….

Objectives: • Minimize data entry errors • Provide more timely information • …

Key Assumptions:

• System will be built in house • Interface will be a Web browser • System will access customer database • …

Stakeholders and Responsibilities:

Stakeholder Role Responsibility Signatures Jackie Judson VP Marketing Project Vision, Resources Jackie Judson Alex Datta CIO Monitoring, Resources Alex Datta Jim Woo Project Manager Planning, Monitoring,

Executing Project Jim Woo

James Jordan Director of Sales System Functionality James Jordan Mary Shide VP Human Resources Staff Assignments Mary Shide

FIGURE 3-7 A Project Charter for a Proposed Information Systems Project

FIGURE 3-8 Level of project planning detail should be high in the short term, with less detail as time goes on

1 Week Out

Low

Medium

High

1 Month Out

6 Months Out

Planning Horizon

P la

n n

in g

D e ta

M03_VALA1629_09_GE_C03.indd 73 08/04/2020 16:35

mailto:[email protected]

74 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

System project, Chris and Juanita developed a 10-page plan. However, project plans for very large systems may be several hundred pages in length. The types of activities that you can perform during project planning are summarized in Figure 3-9 and are described in the following list:

1. Describing project scope, alternatives, and feasibility. The purpose of this activity is to understand the content and complexity of the project. Within PVF’s systems development methodology, one of the first meetings must focus on defining a project’s scope. Although project scope information was not included in the SSR developed by Chris and Juanita, it was important that both shared the same vision for the project before moving too far along. During this activity, you should reach agreement on the following questions:

• What problem or opportunity does the project address? • What are the quantifiable results to be achieved? • What needs to be done? • How will success be measured? • How will we know when we are finished?

After defining the scope of the project, your next objective is to identify and document general alternative solutions for the current business problem or opportunity. You must then assess the feasibility of each alternative solution and choose which to consider during subsequent SDLC phases. In some instances, off-the-shelf software can be found. It is also important that any unique problems, constraints, and assumptions about the project be clearly stated.

2. Dividing the project into manageable tasks. This is a critical activity during the proj- ect planning process. Here, you must divide the entire project into manageable tasks and then logically order them to ensure a smooth evolution between tasks. The definition of tasks and their sequence is referred to as the work breakdown structure (Fuller et al., 2018; PMBOK, 2017; Project Management Institute, 2002). Some tasks may be performed in parallel, whereas others must follow one another sequentially. Task sequence depends on which tasks produce deliverables needed in other tasks, when critical resources are available, the constraints placed on the project by the client, and the process outlined in the SDLC.

For example, suppose that you are working on a new development project and need to collect system requirements by interviewing users of the new system and reviewing reports they currently use to do their job. A work breakdown for these activities is represented in a Gantt chart in Figure 3-10. A Gantt chart is a

Gantt chart A graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion.

Work breakdown structure The process of dividing the project into manageable tasks and logically order- ing them to ensure a smooth evolution between tasks.

FIGURE 3-9 Ten project planning activities

Project Planning

1. Describing Project Scope, Alternatives, and Feasibility

2. Dividing the Project into Manageable Tasks

3. Estimating Resources and Creating a Resource Plan

4. Developing a Preliminary Schedule

5. Developing a Communication Plan

6. Determining Project Standards and Procedures

7. Identifying and Assessing Risk

8. Creating a Preliminary Budget

9. Developing a Project Scope Statement

10. Setting a Baseline Project Plan

M03_VALA1629_09_GE_C03.indd 74 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 75

graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion. Different colors, shades, or shapes can be used to highlight each kind of task. For example, those activities on the critical path (defined later) may be in red and a summary task could have a special bar. Note that the black horizontal bars—rows 1, 2, and 6 in Figure 3-10— represent summary tasks. Planned versus actual times or progress for an activity can be compared by parallel bars of different colors, shades, or shapes. Gantt charts do not (typically) show how tasks must be ordered (precedence), but simply show when an activity should begin and end. In Figure 3-10, the task duration is shown in the second column by days, “d,” and necessary prior tasks are noted in the third column as predecessors. Most project management software tools sup- port a broad range of task durations, including minutes, hours, days, weeks, and months. As you will learn in later chapters, the SDLC consists of several phases that you will need to break down into activities. Creating a work breakdown struc- ture requires that you decompose phases into activities—summary tasks—and activities into specific tasks. For example, Figure 3-10 shows that the activity Inter- viewing consists of three tasks: design interview form, schedule appointments, and conduct interviews.

Defining tasks in too much detail will make the management of the project unnecessarily complex. You will develop the skill of discovering the optimal level of detail for representing tasks through experience. For example, it may be very difficult to list tasks that require less than one hour of time to complete in a final work breakdown structure. Alternatively, choosing tasks that are too large in scope (e.g., several weeks long) will not provide you with a clear sense of the status of the project or of the interdependencies between tasks. What are the characteristics of a “task”? A task

• can be done by one person or a well-defined group, • has a single and identifiable deliverable (the task is, however, the process of

creating the deliverable), • has a known method or technique, • has well-accepted predecessor and successor steps, and • is measurable so that the percentage completed can be determined.

3. Estimating resources and creating a resource plan. The goal of this activity is to estimate resource requirements for each project activity and to use this information to

FIGURE 3-10 Gantt chart showing project tasks, duration times for those tasks, and predecessors

(Source: Microsoft Corporation.)

M03_VALA1629_09_GE_C03.indd 75 08/04/2020 16:35

76 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

create a project resource plan. The resource plan helps assemble and deploy resources in the most effective manner. For example, you would not want to bring additional programmers onto the project at a rate faster than you could prepare work for them. Project managers use a variety of tools to assist in making estimates of project size and costs. The most widely used method is called COCOMO (COnstructive COst MOdel), which uses parameters that were derived from prior projects of differing complexity (Boehm & Turner, 2000; Boehm, 2017; Moody et al., 2018). COCOMO uses these different parameters to predict human resource requirements for basic, intermediate, and very complex systems.

People are the most important, and expensive, part of project resource plan- ning. Project time estimates for task completion and overall system quality are significantly influenced by the assignment of people to tasks. It is important to give people tasks that allow them to learn new skills. It is equally important to make sure that project members are not “in over their heads” or working on a task that is not well suited to their skills. Resource estimates may need to be revised based upon the skills of the actual person (or people) assigned to a particular activity. Figure 3-11 indicates the relative programming speed versus the relative programming quality of three programmers. The figure suggests that Carl should not be assigned tasks in which completion time is critical and that Brenda should be assigned tasks in which high quality is most vital.

One approach to assigning tasks is to assign a single task type (or only a few task types) to each worker for the duration of the project. For example, you could assign one worker to create all computer displays and another to create all system reports. Such specialization ensures that both workers become efficient at their own particular tasks. A worker may become bored if the task is too specialized or is long in duration, so you could assign workers to a wider variety of tasks. However, this approach may lead to lowered task efficiency. A middle ground would be to make assignments with a balance of both specialization and task variety. Assign- ments depend on the size of the development project and the skills of the project team. Regardless of the manner in which you assign tasks, make sure that each team member works only on one task at a time. Exceptions to this rule can occur when a task occupies only a small portion of a team member’s time (e.g., testing the programs developed by another team member) or during an emergency.

4. Developing a preliminary schedule. During this activity, you use the information on tasks and resource availability to assign time estimates to each activity in the work breakdown structure. These time estimates will enable you to create target starting and ending dates for the project. Target dates can be revisited and modified until a schedule is produced that is acceptable to the customer. Determining an accept- able schedule may require that you find additional or different resources or that the scope of the project be changed. The schedule may be represented as a Gantt chart, as illustrated in Figure 3-10, or as a network diagram, as illustrated in Figure 3-12. A network diagram is a graphical depiction of project tasks and their

COCOMO The Constructive Cost Model (COCOMO) is an automated software estimation model that uses historical project data and current as well as future project characteristics to estimate proj- ect costs.

Network diagram A diagram that depicts project tasks and their interrelationships.

FIGURE 3-11 Trade-offs between program code quality versus the speed of programming

Low

High

Time of Programming a Task

Brenda

Adam Carl

Q u al

ity o

f W

o rk

LongShort

M03_VALA1629_09_GE_C03.indd 76 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 77

interrelationships. As with a Gantt chart, each type of task can be highlighted by different features on the network diagram. The distinguishing feature of a network diagram is that the ordering of tasks is shown by connecting tasks—depicted as rectangles or ovals—with their predecessor and successor tasks. However, the rela- tive size of a node (representing a task) or a gap between nodes does not imply the task’s duration. Only the individual task items are drawn on a network diagram, which is why the summary tasks 1, 2, and 6—the black bars—from Figure 3-10 are not shown in Figure 3-12. We describe both of these charts later in this chapter.

5. Developing a communication plan. The goal of this activity is to outline the communica- tion procedures among management, project team members, and the customer. The communication plan includes when and how written and oral reports will be provided by the team, how team members will coordinate work, what messages will be sent to announce the project to interested parties, and what kinds of information will be shared with vendors and external contractors involved with the project. It is important that free and open communication occur among all parties with respect to proprietary information and confidentiality with the customer (Fuller et al., 2018; Gold, 2016; Kettelhut, 1991; Keane, 2017; Martinelli, et al., 2017; Verma, 1996). When developing a communication plan, numerous questions must be answered in order to assure that the plan is comprehensive and complete, including the following:

• Who are the stakeholders for this project? • What information does each stakeholder need? • When, and at what interval, does this information need to be produced? • What sources will be used to gather and generate this information? • Who will collect, store, and verify the accuracy of this information? • Who will organize and package this information into a document? • Who will be the contact person for each stakeholder should any questions arise? • What format will be used to package this information? • What communication medium will be most effective for delivering this infor-

mation to the stakeholder?

Once these questions are answered for each stakeholder, a comprehensive communication plan can be developed. In this plan, a summary of communica- tion documents, work assignments, schedules, and distribution methods will be outlined. Additionally, a project communication matrix can be developed that provides a summary of the overall communication plan (see Figure 3-13). This

FIGURE 3-12 A network diagram illustrates tasks with rectangles (or ovals) and the relation- ships and sequences of those activities with arrows

(Source: Microsoft Corporation.)

M03_VALA1629_09_GE_C03.indd 77 08/04/2020 16:35

78 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

matrix can be easily shared among team members, and verified by stakeholders outside the project team, so that the right people are getting the right information at the right time, and in the right format.

6. Determining project standards and procedures. During this activity, you will specify how various deliverables are produced and tested by you and your project team. For example, the team must decide which tools to use, how the standard SDLC might be modified, which SDLC methods will be used, documentation styles (e.g., type fonts and margins for user manuals), how team members will report the status of their assigned activities, and terminology. Setting project standards and proce- dures for work acceptance is a way to ensure the development of a high-quality system. Also, it is much easier to train new team members when clear standards are in place. Organizational standards for project management and conduct make the determination of individual project standards easier and the interchange or sharing of personnel among different projects feasible.

7. Identifying and assessing risk. The goal of this activity is to identify sources of project risk and to estimate the consequences of those risks (Fuller et al., 2018; Kendrick, 2015). Risks might arise from the use of new technology, prospective users’ resis- tance to change, availability of critical resources, competitive reactions or changes in regulatory actions due to the construction of a system, or team member inexpe- rience with technology or the business area. You should continually try to identify and assess project risk.

The identification of project risk is required to develop PVF’s new Purchas- ing Fulfillment System. Chris and Juanita met to identify and describe possible negative outcomes of the project and their probabilities of occurrence. Although we list the identification of risks and the outline of project scope as two discrete activities, they are highly related and often concurrently discussed.

8. Creating a preliminary budget. During this phase, you need to create a preliminary budget that outlines the planned expenses and revenues associated with your project. The project justification will demonstrate that the benefits are worth these costs. Figure 3-14 shows a cost-benefit analysis for a new development project. This analysis shows net present value calculations of the project’s benefits and costs as well as a return on investment and cash flow analysis. We discuss project budgets fully in Chapter 5.

9. Developing a Project Scope Statement. An important activity that occurs near the end of the project planning phase is the development of the Project Scope Statement. Developed primarily for the customer, this document outlines work that will be done and clearly describes what the project will deliver. The Project Scope Statement is useful to make

FIGURE 3-13 The project communication matrix provides a high-level summary of the communication plan

Stakeholder

Team Members

Management Supervisor

User Group

Internal IT Sta

IT Manager

Contract Programmers

Training Subcontractor

Document

Project Status Report

Software Specifications

Implementation and Training Plan

Format

Project Intranet

Hard Copy

E-Mail

Hard Copy

E-Mail/Project Intranet

Hard Copy

Team Contact

Juan Kim

James Kim

Jackie James

Juan Jeremy

Jordan Kim

Jordan James

Date Due

First Monday of Month

October 1, 2020

January 7, 2021

M03_VALA1629_09_GE_C03.indd 78 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 79

FIGURE 3-14 (Source: Microsoft Corporation.)

sure that you, the customer, and other project team members have a clear understand- ing of the intended project size, duration, and outcomes.

10. Setting a Baseline Project Plan. Once all of the prior project planning activities have been completed, you will be able to develop a Baseline Project Plan. This baseline plan provides an estimate of the project’s tasks and resource requirements and is used to guide the next project phase—execution. As new information is acquired during project execution, the baseline plan will continue to be updated.

At the end of the project planning phase, a review of the Baseline Project Plan is conducted to double-check all information in the plan. As with the project initiation phase, it may be necessary to modify the plan, which means returning to prior proj- ect planning activities before proceeding. As with the Purchasing Fulfillment System project, you may submit the plan and make a brief presentation to the project steering committee at this time. The committee can endorse the plan, ask for modifications, or determine that it is not wise to continue the project as currently outlined.

Executing the Project

Project execution puts the Baseline Project Plan into action. Within the context of the SDLC, project execution occurs primarily during the analysis, design, and implemen- tation phases. During the development of the Purchasing Fulfillment System, Chris Martin was responsible for five key activities during project execution. These activities are summarized in Figure 3-15 and described in the remainder of this section:

1. Executing the Baseline Project Plan. As project manager, you oversee the execution of the baseline plan. This means that you initiate the execution of project activities, acquire and assign resources, orient and train new team members, keep the proj- ect on schedule, and ensure the quality of project deliverables. This is a formidable

Project execution The third phase of the project manage- ment process in which the plans created in the prior phases (project initiation and planning) are put into action.

M03_VALA1629_09_GE_C03.indd 79 08/04/2020 16:35

80 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

task, but a task made much easier through the use of sound project management techniques. For example, as tasks are completed during a project, they can be “marked” as completed on the project schedule. In Figure 3-16, tasks 3 and 7 are marked as completed by showing 100 percent in the “% Complete” column; task 8 is marked as being partially completed. Members of the project team will come and go. You are responsible for initiating new team members by providing them with the resources they need and helping them assimilate into the team. You may want to plan social events, regular team project status meetings, team-level reviews of project deliverables, and other group events to mold the group into an effective team.

2. Monitoring project progress against the Baseline Project Plan. While you execute the Baseline Project Plan, you should monitor your progress. If the project gets ahead of (or behind) schedule, you may have to adjust resources, activi- ties, and budgets. Monitoring project activities can result in modifications to the current plan. Measuring the time and effort expended on each activity will help you improve the accuracy of estimations for future projects. It is possible, with project schedule charts such as Gantt charts, to show progress against a plan, and it is easy with network diagrams to understand the ramifi- cations of delays in an activity. Monitoring progress also means that the team leader must evaluate and appraise each team member, occasionally change work assignments or request changes in personnel, and provide feedback to the employee’s supervisor.

FIGURE 3-15 Five project execution activities

Project Execution

1. Executing the Baseline Project Plan

2. Monitoring Project Progress against the Baseline Project Plan

3. Managing Changes to the Baseline Project Plan

4. Maintaining the Project Workbook

5. Communicating the Project Status

FIGURE 3-16 Gantt chart with tasks 3 and 7 completed, and task 8 partially completed

(Source: Microsoft Corporation.)

M03_VALA1629_09_GE_C03.indd 80 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 81

3. Managing changes to the Baseline Project Plan. You will encounter pressure to make changes to the baseline plan. At PVF, policies dictate that only approved changes to the project specification can be made and all changes must be reflected in the baseline plan and project workbook, including all charts. For example, if Juanita suggests a significant change to the existing design of the Purchasing Fulfillment System, a formal change request must be approved by the steering committee. The request should explain why changes are desired and describe all possible effects on prior and subsequent activities, project resources, and the overall project schedule. Chris would have to help Juanita develop such a request. This information allows the project steering committee to more easily evaluate the costs and benefits of a significant midcourse change.

In addition to changes occurring through formal request, changes may also occur from events outside your control. In fact, numerous events may initiate a change to the Baseline Project Plan, including the following possibilities:

• A slipped completion date for an activity • A bungled activity that must be redone • The identification of a new activity that becomes evident later in the project • An unforeseen change in personnel due to sickness, resignation, or termination

When an event occurs that delays the completion of an activity, you typically have two choices: devise a way to get back on schedule, or revise the plan. Devising a way to get back on schedule is the preferred approach because no changes to the plan will have to be made. The ability to head off and smoothly work around problems is a critical skill that you need to master.

As you will see later in this chapter, project schedule charts are very helpful in assessing the impact of change. Using such charts, you can quickly see if the completion time of other activities will be affected by changes in the duration of a given activity or if the whole project completion date will change. Often you will have to find a way to rearrange the activities because the ultimate project comple- tion date may be rather fixed. There may be a penalty to the organization (even legal action) if the expected completion date is not met.

4. Maintaining the project workbook. As in all project phases, maintaining complete records of all project events is necessary. The workbook provides the documenta- tion new team members require to assimilate project tasks quickly. It explains why design decisions were made and is a primary source of information for producing all project reports.

5. Communicating the project status. The project manager is responsible for keeping all stakeholders—system developers, managers, and customers—abreast of the project status. In other words, communicating the project status focuses on the execution of the project communication plan and the response to any ad hoc infor- mation requests by stakeholders. A broad variety of methods can be used to distrib- ute information, each with strengths and weaknesses. Some methods are easier for the information sender, but more difficult or less convenient for the receiver. With the maturing digital networks and the Internet, more and more digital communi- cation is being exchanged. Procedures for communicating project activities vary from formal meetings to informal hallway discussions. Some procedures are useful for informing others of the project’s status, others are better for resolving issues, and still others are better for keeping permanent records of information and events. Two types of information are routinely exchanged throughout the project: work results—the outcomes of the various tasks and activities that are performed to complete the project—and the project plan—the formal comprehensive docu- ment that is used to execute the project; it contains numerous items including the project charter, project schedule, budgets, and risk plan. Table 3-2 lists numerous communication procedures, their level of formality, and their most likely use. Whichever procedure you use, frequent communication helps to ensure project success (Fuller et al., 2018; Kettelhut, 1991; Martinelli, et al., 2017; Verma, 1996).

M03_VALA1629_09_GE_C03.indd 81 08/04/2020 16:35

82 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

This section outlined your role as the project manager during the execution of the Baseline Project Plan. The ease with which the project can be managed is signifi- cantly influenced by the quality of prior project phases. If you develop a high-quality project plan, it is much more likely that the project will be successfully executed. The next section describes your role during project closedown, the final phase of the project management process.

Closing Down the Project

The focus of project closedown is to bring the project to an end. Projects can con- clude with a natural or unnatural termination. A natural termination occurs when the requirements of the project have been met—the project has been completed and is a success. An unnatural termination occurs when the project is stopped before completion (Fuller et al., 2017; Keil et al., 2000). Several events can cause an unnatu- ral termination of a project. For example, it may be learned that the assumption used to guide the project proved to be false, that the performance of the systems or devel- opment group was somehow inadequate, or that the requirements are no longer relevant or valid in the customer’s business environment. The most likely reasons for the unnatural termination of a project relate to running out of time or money, or both. Regardless of the project termination outcome, several activities must be per- formed: closing down the project, conducting post-project reviews, and closing the customer contract. Within the context of the SDLC, project closedown occurs after the implementation phase. The system maintenance phase typically represents an ongoing series of projects, each of which must be individually managed. Figure 3-17 summarizes the project closedown activities that are described more fully in the remainder of this section:

1. Closing down the project. During closedown, you perform several diverse activities. For example, if you have several team members working with you, project comple- tion may signify job and assignment changes for some members. You will likely be required to assess each team member and provide an appraisal for personnel files and salary determination. You may also want to provide career advice to team members, write letters to superiors praising special accomplishments of team members, and send thank-you letters to those who helped but were not team mem- bers. As project manager, you must be prepared to handle possible negative per- sonnel issues such as job termination, especially if the project was not successful.

Project closedown The final phase of the project manage- ment process that focuses on bringing a project to an end.

FIGURE 3-17 Three project closedown activities

Project Closedown

1. Closing Down the Project

2. Conducting Postproject Reviews

3. Closing the Customer Contract

Procedure Formality Use

Project workbook High Inform Permanent record

Meetings Medium to high Resolve issues Seminars and workshops Low to medium Inform Project newsletters Medium to high Inform Status reports High Inform Specification documents High Inform

Permanent record Minutes of meetings High Inform

Permanent record Bulletin boards Low Inform Memos Medium to high Inform Brown bag lunches Low Inform Hallway discussions Low Inform

Resolve issues

TABLE 3-2 Project Team Communication Methods

M03_VALA1629_09_GE_C03.indd 82 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 83

When closing down the project, it is also important to notify all interested parties that the project has been completed and to finalize all project documentation and financial records so that a final review of the project can be conducted. You should also celebrate the accomplishments of the team. Some teams will hold a party, and each team member may receive memorabilia (e.g., a T-shirt with “I survived the X project”). The goal is to celebrate the team’s effort to bring a difficult task to a successful conclusion.

2. Conducting postproject reviews. Once you have closed down the project, final reviews of the project should be conducted with management and customers. The objec- tive of these reviews is to determine the strengths and weaknesses of project deliv- erables, the processes used to create them, and the project management process. It is important that everyone understands what went right and what went wrong in order to improve the process for the next project. Remember, the systems devel- opment methodology adopted by an organization is a living guideline that must undergo continual improvement.

3. Closing the customer contract. The focus of this final activity is to ensure that all con- tractual terms of the project have been met. A project governed by a contractual agreement is typically not completed until agreed to by both parties, often in writing. Thus, it is imperative that you gain agreement from your customer that all contractual obligations have been met and that further work is either their responsibility or covered under another SSR or contract.

Closedown is a very important activity. A project is not complete until it is closed, and it is at closedown that projects are deemed a success or failure. Completion also signifies the chance to begin a new project and to apply what you have learned. Now that you have an understanding of the project management process, the next sec- tion describes specific techniques used in systems development for representing and scheduling activities and resources.

REPRESENTING AND SCHEDULING PROJECT PLANS A project manager has a wide variety of techniques available for depicting and docu- menting project plans. These planning documents can take the form of graphical or textual reports, although graphical reports have become most popular for depict- ing project plans. The most commonly used methods are Gantt charts and network diagrams. Because Gantt charts do not (typically) show how tasks must be ordered (precedence) but simply show when a task should begin and when it should end, they are often more useful for depicting relatively simple projects or subparts of a larger project, showing the activities of a single worker, or monitoring the progress of activi- ties compared to scheduled completion dates (Figure 3-18). Recall that a network diagram shows the ordering of activities by connecting a task to its predecessor and successor tasks. Sometimes a network diagram is preferable; other times a Gantt chart more easily shows certain aspects of a project. Here are the key differences between these two charts:

• Gantt charts visually show the duration of tasks, whereas a network diagram visu- ally shows the sequence dependencies between tasks.

• Gantt charts visually show the time overlap of tasks, whereas a network dia- gram does not show time overlap but does show which tasks could be done in parallel.

• Some forms of Gantt charts can visually show slack time available within an earli- est start and latest finish duration. A network diagram shows this by data within activity rectangles.

Project managers also use textual reports that depict resource utilization by task, complexity of the project, and cost distributions to control activities. For example,

M03_VALA1629_09_GE_C03.indd 83 08/04/2020 16:35

84 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

FIGURE 3-18 Graphical diagrams that depict project plans (a) A Gantt chart (b) A network diagram

(Source: Microsoft Corporation.)

Figure 3-19 shows a screen from Microsoft Project that summarizes all project activi- ties, their durations in weeks, and their scheduled starting and ending dates. Most project managers use computer-based systems to help develop their graphical and textual reports. Later in this chapter, we discuss these automated systems in more detail.

A project manager will periodically review the status of all ongoing project task activities to assess whether the activities will be completed early, on time, or late. If early or late, the duration of the activity, depicted in column 2 of Figure 3-19, can be updated. Once changed, the scheduled start and finish times of all subsequent tasks will also change. Making such a change will also alter a Gantt chart or network diagram used to represent the project tasks. The ability to easily make changes to a project is a very powerful feature of most project management environments. It enables the project manager to determine easily how changes in task duration affect the project completion date. It is also useful for examining the

M03_VALA1629_09_GE_C03.indd 84 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 85

FIGURE 3-19 A screen from Microsoft Project that summarizes all project activities, their durations in weeks, and their scheduled starting and ending dates

(Source: Microsoft Corporation.)

impact of “what if” scenarios of adding or reducing resources, such as personnel, for an activity.

Representing Project Plans

Project scheduling and management require that time, costs, and resources be controlled. Resources are any person, group of people, piece of equipment, or material used in accomplishing an activity. Network diagramming is a critical path scheduling technique used for controlling resources. A critical path refers to a sequence of task activities whose order and durations directly affect the completion date of a project. A network diagram is one of the most widely used and best-known scheduling methods. You would use a network diagram when tasks

• are well defined and have a clear beginning and end point, • can be worked on independently of other tasks, • are ordered, and • serve the purpose of the project.

A major strength of network diagramming is its ability to represent how comple- tion times vary for activities. Because of this, it is more often used than Gantt charts to manage projects such as information systems development, where variability in the duration of activities is the norm. Network diagrams are composed of circles or rect- angles representing activities and connecting arrows showing required work flows, as illustrated in Figure 3-20.

Calculating Expected Time Durations Using PERT

One of the most difficult and most error-prone activities when constructing a project schedule is the determination of the time duration for each task within a work break- down structure. It is particularly problematic to make these estimates when there is a high degree of complexity and uncertainty about a task. PERT (Program Evaluation Review Technique) is a technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected time for a particular task. This technique can help you to obtain a better time estimate when there is some uncertainty as to how much time a task will require to be completed.

Resources Any person, group of people, piece of equipment, or material used in accom- plishing an activity.

Critical path scheduling A scheduling technique whose order and duration of a sequence of task activities directly affect the completion date of a project.

PERT (Program Evaluation Review Technique) A technique that uses optimistic, pes- simistic, and realistic time estimates to calculate the expected time for a par- ticular task.

M03_VALA1629_09_GE_C03.indd 85 08/04/2020 16:35

86 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

FIGURE 3-20 A network diagram showing activities (represented by circles) and sequence of those activities (represented by arrows) Design

System

Write Programs

Test Programs

Write Documentation

Install System

B C

The optimistic (o) and pessimistic (p) times reflect the minimum and maximum possible periods of time for an activity to be completed. The realistic (r) time, or most likely time, reflects the project manager’s “best guess” of the amount of time the activity actually will require for completion. Once each of these estimates is made for an activ- ity, an expected time (ET) can be calculated. Because the expected completion time should be closest to the realistic (r) time, it is typically weighted four times more than the optimistic (o) and pessimistic (p) times. Once you add these values together, it must be divided by six to determine the ET This equation is shown in the following formula:

ET = o4rp

6 where

ET = expected time for the completion for an activity o = optimistic completion time for an activity r = realistic completion time for an activity p = pessimistic completion time for an activity

For example, suppose that your instructor asked you to calculate an expected time for the completion of an upcoming programming assignment. For this assign- ment, you estimate an optimistic time of two hours, a pessimistic time of eight hours, and a most likely time of six hours. Using PERT, the expected time for completing this assignment is 5.67 hours. Commercial project management software such as Microsoft Project assists you in using PERT to make expected time calculations. Additionally, many commercial tools allow you to customize the weighting of optimistic, pessimistic, and realistic completion times.

Constructing a Gantt Chart and Network Diagram at Pine Valley Furniture

Although PVF has historically been a manufacturing company, it has recently entered the direct sales market for selected target markets. One of the fastest growing of these markets is economically priced furniture suitable for college students. Management has requested that a new Sales Promotion Tracking System (SPTS) be developed. This project has already successfully moved through project initiation and is currently in the detailed project plan- ning stage, which corresponds to the SDLC phase of project initiation and planning. The SPTS will be used to track purchases by college students for the next fall semester. Students typically purchase low-priced beds, bookcases, desks, tables, chairs, and dressers. Because PVF does not normally stock a large quantity of lower-priced items, management feels that a tracking system will help provide information about the college-student market that can be used for follow-up sales promotions (e.g., a midterm futon sale).

The project is to design, develop, and implement this information system before the start of the fall term in order to collect sales data at the next major buying period. This deadline gives the project team 24 weeks to develop and implement the system. The Systems Priority Board at PVF wants to make a decision this week based on the feasibility of completing the project within the 24-week deadline. Using PVF’s project

PINE VALLEY FURNITURE

M03_VALA1629_09_GE_C03.indd 86 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 87

FIGURE 3-21 Estimated time calculations for the SPTS project

ACTIVITY

1. Requirements Collection

2. Screen Design

3. Report Design

4. Database Design

5. User Documentation

6. Programming

7. Testing

8. Installation

TIME ESTIMATE (in weeks)

EXPECTED TIME (ET) o + 4r + p

5.5

planning methodology, the project manager, Jim Woo, knows that the next step is to construct a Gantt chart and network diagram of the project to represent the Baseline Project Plan so that he can use these charts to estimate the likelihood of completing the project within 24 weeks. A major activity of project planning focuses on dividing the project into manageable activities, estimating times for each, and sequencing their order. Here are the steps Jim followed to do this:

1. Identify each activity to be completed in the project. After discussing the new SPTS with PVF’s management, sales, and development staff, Jim identified the following major activities for the project:

• Requirements collection • Screen design • Report design • Database construction • User documentation creation • Software programming • System testing • System installation

2. Determine time estimates and calculate the expected completion time for each activity. After identifying the major project activities, Jim established optimistic, realistic, and pessimistic time estimates for each activity. These numbers were then used to calculate the expected completion times for all project activities, as described previously using PERT. Figure 3-21 shows the estimated time calculations for each activity of the SPTS project.

3. Determine the sequence of the activities and precedence relationships among all activities by constructing a Gantt chart and network diagram. This step helps you to understand how various activities are related. Jim starts by determining the order in which activities should take place. The results of this analysis for the SPTS project are shown in Figure 3-22. The first row of this figure shows that no activities precede requirements

FIGURE 3-22 Sequence of activities within the SPTS project

ACTIVITY 1. Requirements Collection 2. Screen Design 3. Report Design 4. Database Design 5. User Documentation 6. Programming 7. Testing 8. Installation

PRECEDING ACTIVITY

— 1 1

2,3 4 4 6

5,7

ACTIVITY 1. Requirements Collection 2. Screen Design 3. Report Design 4. Database Design 5. User Documentation 6. Programming 7. Testing 8. Installation

PRECEDING ACTIVITY

— 1 1

2,3 4 4 6

5,7

M03_VALA1629_09_GE_C03.indd 87 08/04/2020 16:35

88 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

FIGURE 3-23 Gantt chart that illustrates the sequence and duration of each activity of the SPTS project

(Source: Microsoft Corporation.)

collection. Row 2 shows that screen design must be preceded by requirements col- lection. Row 4 shows that both screen and report design must precede database construction. Thus, activities may be preceded by zero, one, or more activities.

Using the estimated time and activity sequencing information from Figures 3-21 and 3-22, Jim can now construct a Gantt chart and network diagram of the project’s activities. To construct the Gantt chart, a horizontal bar is drawn for each activity that reflects its sequence and duration, as shown in Figure 3-23. The Gantt chart may not, however, show direct interrelationships between activities. For example, the fact that the database design activity begins right after the screen design and report design bars finish does not imply that these two activities must finish before database design can begin. To show such precedence relationships, a network diagram must be used. The Gantt chart in Figure 3-23 does, however, show precedence relationships.

Network diagrams have two major components: arrows and nodes. Arrows reflect the sequence of activities, whereas nodes reflect activities that consume time and resources. A network diagram for the SPTS project is shown in Figure 3-24. This diagram has eight nodes labeled 1 through 8.

4. Determine the critical path. The critical path of a network diagram is represented by the sequence of connected activities that produce the longest overall time period. All nodes and activities within this sequence are referred to as being “on” the critical path. The critical path represents the shortest time in which a project can be completed. In other words, any activity on the critical path that is delayed in completion delays the entire project. Nodes not on the critical path, however, can be delayed (for some amount of time) without delaying the final completion of the project. Nodes not on the critical path contain slack time and allow the project manager some flexibility in scheduling.

Figure 3-25 shows the network diagram that Jim constructed to determine the critical path and expected completion time for the SPTS project. To determine the critical path, Jim calculated the earliest and latest expected completion time for each activity. He found each activity’s earliest expected completion time (TE) by summing the estimated time (ET) for each activity from left to right (i.e., in precedence order), starting at activity 1 and working toward activity 8. In this case, TE for activity 8 is equal to 22 weeks. If two or more activities precede an activity, the largest expected completion time of these activities is used in calculating the new activity’s expected completion time. For example, because activity 8 is preceded by both activities 5 and

Slack time The amount of time that an activity can be delayed without delaying the project.

Critical path The shortest time in which a project can be completed.

M03_VALA1629_09_GE_C03.indd 88 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 89

FIGURE 3-24 A network diagram that illustrates the activities (circles) and the sequence (arrows) of those activitiesRequirements

Collection Database

Design

Screen Design Installation

User Documentation

Report Design Programming Testing

FIGURE 3-25 A network diagram for the SPTS project showing estimated times for each activ- ity and the earliest and latest expected completion time for each activity

TE = 11 TL = 11

TE = 5 TL = 5

ET = 6 ET = 5 ET = 3

ET = 2

ET = 6 ET = 5.5 ET = 1

ET = 5

TE = 18.5 TL = 21

TE = 22 TL = 22

TE = 21 TL = 21

TE = 18 TL = 18

TE = 13 TL = 13

Critical Path Noncritical Path

5 82

3 6

7, the largest expected completion time between 5 and 7 is 21, so TE for activity 8 is 21 + 1, or 22. The earliest expected completion time for the last activity of the project represents the amount of time the project should take to complete. Because the time of each activity can vary, however, the projected completion time represents only an estimate. The project may in fact require more or less time for completion.

The latest expected completion time (TL) refers to the time in which an activity can be completed without delaying the project. To find the values for each activity’s TL, Jim started at activity 8 and set TL equal to the final TE (22 weeks). Next, he worked right to left toward activity 1 and subtracted the expected time for each activity. The slack time for each activity is equal to the difference between its latest and earliest expected completion times (TL - TE). Figure 3-26 shows the slack time calculations for all activities of the SPTS project. All activities with a slack time equal to zero are on the critical path. Thus, all activities except activity 5 are on the critical path. Part of the diagram in Figure 3-25 shows two critical paths, between activities 1-2-4 and 1-3-4, because both of these parallel activities have zero slack.

In addition to the possibility of having multiple critical paths, there are actually two possible types of slack. Free slack refers to the amount of time a task can be delayed without delaying the early start of any immediately following tasks. Total slack refers to the amount of time a task can be delayed without delaying the completion of the proj- ect. Understanding free and total slack allows the project manager to better identify where trade-offs can be made if changes to the project schedule need to be made. For more information on understanding slack and how it can be used to manage tasks see Information Systems Project Management by Fuller et al. (2018).

USING PROJECT MANAGEMENT SOFTWARE A wide variety of automated project management tools is available to help you manage a development project. New versions of these tools are continuously being developed and released by software vendors. Most of the available tools have a set of common features that include the ability to define and order tasks, assign resources to tasks, and easily modify tasks and resources. Project management tools are available to run on a wide range of personal computers (PCs), notebooks, and tablets running on the

M03_VALA1629_09_GE_C03.indd 89 08/04/2020 16:35

90 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Web via a browser or locally on Windows-, Mac OS X- or Linux-based systems. These systems vary in the number of simultaneous users and projects supported, as well as system usability, and, of course, cost. Prices for these systems can range from free, to a few hundred dollars for PC or Web–based systems (e.g., Microsoft Project), to more than $20,000 for large-scale, multiproject enterprise-focused systems. Some popular tools include OpenProject, Bugzilla, Jira, and eGroupware; each can be downloaded from the product’s own Website. Free to use public domain and shareware systems can be found by searching the Web or by visiting popular downloading sites (see www.download.com). Because these systems are continuously changing, you should comparison shop before choosing a particular package.

We now illustrate the types of activities you would perform when using project management software. Microsoft Project is a project management system that has received consistently high marks in computer publication reviews (see www.microsoft. com and search for “project”—also, if you search the Web, there are many very useful tutorials for improving your Microsoft Project skills). When using this system to man- age a project, you need to perform at least the following activities:

• Establish a project starting or ending date. • Enter tasks and assign task relationships. • Select a scheduling method to review project reports.

Establishing a Project Start Date

Defining the general project information includes obtaining the name of the project and the project manager, and the starting or ending date of the project. Starting and ending dates are used to schedule future activities or backdate others (see the fol- lowing) based on their duration and relationships with other activities. An example from Microsoft Project of the data entry screen for establishing a project starting or ending date is shown in Figure 3-27. This screen shows PVF’s Purchasing Fulfillment System project. Here, the starting date for the project is Monday, November 2, 2020.

Entering Tasks and Assigning Task Relationships

The next step in defining a project is to define project tasks and their relationships. For the Purchasing Fulfillment System project, Chris defined 11 tasks to be completed when he performed the initial system analysis activities for the project (task 1—Start Analysis Phase—is a summary task that is used to group related tasks). The task entry screen, shown in Figure 3-28, is similar to a financial spreadsheet program. The user moves the cursor to a cell with arrow keys or the mouse and then simply enters a textual Name and a numeric Duration for each activity. Scheduled Start and Sched- uled Finish are automatically entered based on the project start date and duration. To set an activity relationship, the ID number (or numbers) of the activity that must be completed before the start of the current activity is entered into the Predecessors column. Additional codes under this column make the precedence relationships more

PINE VALLEY FURNITURE

FIGURE 3-26 Activity slack time calculations for the SPTS project; all activities except num- ber 5 are on the critical path

TEACTIVITY

1 2 3 4 5 6 7 8

5 11 11 13

18.5 18 21 22

TL 5

11 11 13 21 18 21 22

TL – TE SLACK

0 0 0 0

2.5 0 0 0

ON CRITICAL PATH

M03_VALA1629_09_GE_C03.indd 90 08/04/2020 16:35

http://www.download.com

http://www.microsoft.com

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 91

FIGURE 3-27 Establishing a project starting date in Microsoft Project

(Source: Microsoft Corporation.)

precise. For example, consider the Predecessor column for ID 6. The entry in this cell says that activity 6 cannot start until one day before the finish of activity 5. (Microsoft Project provides many different options for precedence and delays, as demonstrated in this example, but discussion of these is beyond the scope of our coverage.) The project management software uses this information to construct Gantt charts, network diagrams, and other project-related reports.

Selecting a Scheduling Method to Review Project Reports

Once information about all the activities for a project has been entered, it is very easy to review the information in a variety of graphical and textual formats using displays or printed reports. For example, Figure 3-28 shows the project information in a Gantt chart screen, whereas Figure 3-29 shows the project information in a network diagram. You can easily change how you view the information by making a selection from the View menu shown in Figure 3-29.

FIGURE 3-28 Entering tasks and assigning task rela- tionships in Microsoft Project

(Source: Microsoft Corporation.)

M03_VALA1629_09_GE_C03.indd 91 08/04/2020 16:35

92 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

FIGURE 3-30 Gantt chart showing progress of activities (right frame) versus planned activities (left frame)

(Source: Microsoft Corporation.)

As mentioned earlier, interim project reports to management will often compare actual progress with plans. Figure 3-30 illustrates how Microsoft Project shows progress with a solid line within the activity bar. In this figure, task 2 has been completed and task 3 is almost completed (at 75 percent), but there remains a small percentage of work, as shown by the incomplete solid lines within the bar for this task. Assuming that this screen represents the status of the project on Monday, November 16, 2020, the third activity is approximately on schedule, but the second activity is behind its expected completion date. Tabular reports can summarize the same information.

This brief introduction to project management software has only scratched the surface to show you the power and the features of these systems. Other features that are widely available and especially useful for multiperson projects relate to resource usage and utilization. Resource-related features enable you to define characteristics such as standard costing rates and daily availability via a calendar that records holidays, working hours, and vacations. These features are particularly useful for billing and estimating project costs. Often, resources are shared across multiple projects, which could significantly affect a project’s schedule.

Depending on how projects are billed within an organization, assigning and billing resources to tasks can be a very time-consuming activity for most project managers. The features provided in these powerful tools can greatly ease the plan- ning and managing of projects so that project and management resources are effectively utilized.

FIGURE 3-29 Viewing project information as a network diagram in Microsoft Project

(Source: Microsoft Corporation.)

M03_VALA1629_09_GE_C03.indd 92 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 93

SUMMARY The focus of this chapter was on managing information systems projects and the role of the project manager in this process. A project manager has both technical and manage- rial skills and is ultimately responsible for determining the size, scope, and resource requirements for a project. Once a project is deemed feasible by an organization, the proj- ect manager ensures that the project meets the customer’s needs and is delivered within budget and time constraints. To manage the project, the project manager must execute four primary activities: project initiation, project planning, project execution, and project closedown. The focus of project initiation is on assessing the size, scope, and com- plexity of a project and on establishing procedures to sup- port later project activities. The focus of project planning is on defining clear, discrete activities and the work needed to complete each activity. The focus of project execution is on putting the plans developed in project initiation and planning into action. Project closedown focuses on bring- ing the project to an end.

Gantt charts and network diagrams are powerful graphical techniques used in planning and controlling projects. Both Gantt charts and network diagram schedul- ing techniques require that a project have activities that

can be defined as having a clear beginning and end, can be worked on independently of other activities, are ordered, and are such that their completion signifies the end of the project. Gantt charts use horizontal bars to represent the beginning, duration, and ending of an activity. Network diagramming is a critical path scheduling method that shows the interrelationships among activities. Critical path scheduling refers to planning methods whereby the order and duration of the project’s activities directly affect the completion date of the project. These charts show when activities can begin and end, which activities cannot be delayed without delaying the whole project, how much slack time each activity has, and progress against planned activities. A network diagram’s ability to use probability esti- mates in determining critical paths and deadlines makes it a widely used technique for very complex projects.

A wide variety of automated tools for assisting the project manager is available. Most tools have a set of com- mon features, including the ability to define and order tasks, assign resources to tasks, and modify tasks and resources. Systems vary regarding the number of activities supported, the complexity of relationships, processing and storage requirements, and cost.

KEY TERMS 3.1 COCOMO 3.2 Critical path 3.3 Critical path scheduling 3.4 Deliverable 3.5 Feasibility study 3.6 Gantt chart 3.7 Network diagram

3.8 PERT (Program Evaluation Review Technique)

3.9 Project 3.10 Project charter 3.11 Project closedown 3.12 Project execution 3.13 Project initiation

3.14 Project management 3.15 Project manager 3.16 Project planning 3.17 Project workbook 3.18 Resources 3.19 Slack time 3.20 Work breakdown structure

Match each of the key terms above with the definition that best fits it.

____ A systems analyst with a diverse set of skills—management, leadership, technical, conflict management, and customer relationship—who is responsible for initiating, planning, executing, and closing down a project.

____ A planned undertaking of related activities to reach an objective that has a beginning and an end.

____ An end product of an SDLC phase.

____ A study that determines if the proposed information system makes sense for the organization from an economic and operational standpoint.

____ A controlled process of initiating, planning, executing, and closing down a project.

____ The first phase of the project management process in which activities are performed to assess the size, scope, and com- plexity of the project and to establish procedures to support later project activities.

____ An online repository for all project-related documents that is used for performing project audits, orienting new team members, communicating with management and custom- ers, identifying future projects, and performing post-project reviews.

____ The second phase of the project management process that focuses on defining clear, discrete activities and the work needed to complete each activity within a single project.

____ The process of dividing the project into manageable tasks and logically ordering them to ensure a smooth evolution between tasks.

____ A graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion.

____ A diagram that depicts project tasks and their interrelationships.

M03_VALA1629_09_GE_C03.indd 93 08/04/2020 16:35

94 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

PROBLEMS AND EXERCISES

3.34 Why are longer-term plans typically more general than nearer-term plans in planning a project?

3.35 Which is the most error-prone activity in the construction of a project schedule? Using which technique can a project manager remove that error, and how?

3.36 Search the Web for recent reviews of project management software. Which packages seem to be most popular? What are the relative strengths and weaknesses of each software package? What advice would you give to someone intend- ing to buy project management software for his or her PC? Why?

3.37 Suppose that you have been contracted by a jewelry store to manage a project to create a new inventory tracking system. Describe your initial approach to the project. What should your first activity be? What information would you need? To whom might you need to speak?

3.38 Can a project have two critical paths? Why or why not? Give a brief example to illustrate your point.

3.39 Calculate the expected times for the following activities:

Tail Event

(i)

Head Event

(j)

Optimistic Time (to)

Most Likely

Time (tm)

Pessimistic Time (tp)

Expected Time

A B 1 1 7 A C 1 4 7 A D 2 2 8 B E 1 1 1 C E 2 5 14 D F 2 5 8 E F 3 6 15

____ The third phase of the project management process in which the plans created in the prior phases are put into action.

____ The final phase of the project management process that focuses on bringing a project to an end.

____ Any person, group of people, piece of equipment, or mate- rial used in accomplishing an activity.

____ A scheduling technique whose order and duration of a sequence of task activities directly affect the completion date of a project.

____ The shortest time in which a project can be completed.

____ The amount of time that an activity can be delayed without delaying the entire project.

____ A technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected completion for a particular task.

____ An automated software estimation model that uses historical project data and current as well as future project character- istics to estimate project costs.

____ A short document prepared for the customer during proj- ect initiation that describes what the project will deliver and outlines, generally at a high level, all work required to complete the project.

REVIEW QUESTIONS 3.21 Contrast the following terms:

a. Critical path scheduling, Gantt, network diagramming, slack time

b. Project, project management, project manager c. Project initiation, project planning, project execution,

project closedown d. Project workbook, resources, work breakdown structure

3.22 Discuss why systems analysts need to understand the project management process in today’s business environment.

3.23 List and describe the common skills and activities of a project manager. Which skill do you think is most important? Why?

3.24 In which phase of project planning is COCOMO applied, and why? Discuss the importance of this phase in project planning.

3.25 Discuss the role of the project scope statement and baseline project plan in the project planning phase.

3.26 Describe the activities performed by the project manager during project execution.

3.27 List various project team communication methods and describe an example of the type of information that might be shared among team members using each method.

3.28 Describe the activities performed by the project manager during project closedown.

3.29 Describe the different time estimates in PERT, and how the expected time can be calculated with them.

3.30 Describe the steps involved in making a Gantt chart.

3.31 How do nodes give the project manager flexibility in scheduling?

3.32 In which phase of the SDLC does project planning typically occur? In which phase does project management occur?

3.33 What are some reasons why one activity may have to precede another activity before the second activity can begin? In other words, what causes precedence relationships between project activities?

M03_VALA1629_09_GE_C03.indd 94 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 95

3.40 A project has been defined to contain the following list of activities along with their required times for completion.

Activity No. Immediate Activity Time (weeks) Predecessors 1 Collect requirements 3 2 Analyze processes 2 1 3 Analyze data 2 2 4 Design processes 6 2 5 Design data 3 3 6 Design screens 2 3,4 7 Design reports 4 4,5 8 Program 5 6,7 9 Test and document 7 7

10 Install 2 8,9

a. Draw a network diagram for the activities. b. Calculate the earliest expected completion time. c. Show the critical path. d. What would happen if activity 6 were revised to take six

weeks instead of two weeks?

3.41 Construct a Gantt chart for the project defined in Problem and Exercise 3.40.

3.42 Look again at the activities outlined in Problem and Exer- cise 3.40. Assume that your team is in its first week of the project and has discovered that each of the activity dura- tion estimates is wrong. Activity 2 will take only two weeks to complete. Activities 4 and 7 will each take three times longer than anticipated. All other activities will take twice as long to complete as previously estimated. In addition, a new activity, number 11, has been added. It will take one week to complete, and its immediate predecessors are activities 10 and 9. Adjust the network diagram and recalculate the earliest expected completion times.

3.43 Construct a Gantt chart and network diagram for a project you are or will be involved in. Choose a project of sufficient depth from work, home, or school. Identify the activities to be completed, determine the sequence of the activities, and construct a diagram reflecting the starting times, ending times, durations, and precedence (network diagram only) relationships among all activities. For your network diagram, use the procedure in this chapter to determine time esti- mates for each activity and calculate the expected time for each activity. Now determine the critical path and the early and late starting and finishing times for each activity. Which activities have slack time?

3.44 For the project you described in Problem and Exercise 3.43, assume that the worst has happened. A key team member has dropped out of the project and has been assigned to another project in another part of the country. The remain- ing team members are having personality clashes. Key deliverables for the project are now due much earlier than expected. In addition, you have just determined that a key

phase in the early life of the project will now take much longer than you had originally expected. To make matters worse, your boss absolutely will not accept that this project cannot be completed by this new deadline. What will you do to account for these project changes and problems? Begin by reconstructing your Gantt chart and network diagram and determining a strategy for dealing with the specific changes and problems just described. If new resources are needed to meet the new deadline, outline the rationale that you will use to convince your boss that these additional resources are critical to the success of the project.

3.45 Assume that you have a project with seven activities labeled A–G (below). Derive the earliest completion time (or early finish—EF), latest completion time (or late finish—LF), and slack for each of the following tasks (begin at time = 0). Which tasks are on the critical path? Draw a Gantt chart for these tasks.

Activity Preceding Event

Expected Duration

EF LF Slack Critical Path?

A — 5 B A 3 C A 4 D C 6 E B, C 4 F D 1 G D, E, F 5

3.46 Draw a network diagram for the tasks shown in Problem and Exercise 3.45. Highlight the critical path.

3.47 Assume you have a project with 10 activities labeled A–J, as shown. Derive the earliest completion time (or early finish— EF), latest completion time (or late finish—LF), and slack for each of the following tasks (begin at time = 0). Which tasks are on the critical path? Highlight the critical path on your network diagram.

Activity Preceding Event

Expected Duration

EF LF Slack Critical Path?

A — 4 B A 5 C A 6 D A 7 E A, D 6 F C, E 5 G D, E 4 H E 3 I F, G 4 J H, I 5

3.48 Draw a Gantt chart for the tasks shown in Problem and Exer- cise 3.47.

M03_VALA1629_09_GE_C03.indd 95 08/04/2020 16:35

96 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

Abdel-Hamid, T. K., Sengupta, K., and Swett, C. (1999). The impact of goals on software project management: An experi- mental investigation. MIS Quarterly, 23(4), 531–55.

Boehm, B. W. (2017). Software cost estimation meets software diversity. In Proceedings of the 2017 IEEE/ACM 39th Interna- tional Conference on Software Engineering Companion (ICSE-C) (pp. 495–496). doi: 10.1109/ICSE-C.2017.159.

Boehm, B. W., & Turner, R. (2000). Software cost estimation with COCOMO II. Upper Saddle River, NJ: Prentice Hall.

Chua, C., Lim, W. K., Soh, C., and Sia, S. K. (2012). Enacting clan control in complex IT projects: A social capital perspective. MIS Quarterly, 35(2), 577–600.

REFERENCES

3.49 Assume you have a project with 12 activities labeled A–L as shown.

Activity Preceded by Duration (weeks) A — 10 B A 9 C A 7 D B 6 E B 12 F C 6 G C 8 H F 8 I D 4 J G, H 11 K E 5 L I 7

a. Draw a network diagram for the activities. b. Calculate the early start time and early finish time. c. Calculate the late start time and late finish time. d. Show the critical path. e. Draw a Gantt chart.

3.50 Make a list of the tasks that you performed when design- ing your schedule of classes for this term. Develop a table showing each task, its duration, preceding event(s), and expected duration. Develop a network diagram for these tasks. Highlight the critical path on your network diagram.

3.51 Fully decompose a project you’ve done in another course (e.g., a semester project or term paper). Discuss the level of detail where you stopped decomposing and explain why.

3.52 Create a work breakdown structure based on the decomposi- tion you carried out for Problem and Exercise 3.51.

3.53 Working in a small group, pick a project (it could be any- thing, such as planning a party, writing a group term paper, developing a database application, etc.) and then write the various tasks that need to be done to accomplish the project on Post-it Notes (one task per Post-it Note). Then use the Post-it Notes to create a work breakdown structure (WBS) for the project. Was it complete? Add missing tasks if neces- sary. Were some tasks at a lower level in the WBS than oth- ers? What was the most difficult part of doing this?

FIELD EXERCISES 3.54 Suppose you have been appointed as a project manager to

develop an information system for bike-sharing in your insti- tute. It has launched this initiative to implement sustainable transport and reduce pollution. Prepare a project charter as shown in Figure 3-7. Consult your course instructor and list the roles and responsibilities of stakeholders in this project.

3.55 Identify the person who manages an information systems project in your institute. Describe the key documents listed in Figure 3-6 to them. Determine the extent to which each of these key documents is part of that person’s project work- book when they develop a new information system. If they describe a new key document, add it to the list. Determine the significance of all the documents listed.

3.56 Identify someone who manages an information systems project (or other team-based project) in an organization. Describe to him or her each of the project team communi- cation methods listed in Table 3-2. Determine which types of communication methods are used for team communication and describe which he or she feels are best for communicat- ing various types of information.

3.57 Identify someone who manages an information systems project in an organization. Describe to him or her each of the project execution elements in Figure 3-13. Determine the extent to which each of these elements is part of that person’s project execution process. If that person does not

perform some of these activities, or if he or she cannot spend much time on any of these activities, determine what barriers or reasons prevent performing all project execution activities.

3.58 Interview a sample of project managers. Divide your sample into two small subsamples: one for managers of informa- tion systems projects and one for managers of other types of projects. Ask each respondent to identify personal lead- ership attributes that contribute to successful project man- agement and explain why these are important. Summarize your results. What seem to be the attributes most often cited as leading to successful project management, regardless of the type of project? Are there any consistent differences between the responses in the two subsamples? If so, what are these differences? Do they make sense to you? If there are no apparent differences between the responses of the two subsamples, why not? Are there no differences in the skill sets necessary for managing information systems projects versus managing other types of projects?

3.59 Observe a real information systems project team in action for an extended period of time. Keep a notebook as you watch individual members performing their individual tasks, as you review the project management techniques used by the team’s leader, and as you sit in on some of their meet- ings. What seem to be the team’s strengths and weaknesses? What are some areas in which the team can improve?

M03_VALA1629_09_GE_C03.indd 96 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 97

Dinsmore, P. C., & Cabanis-Brewin, J. (2006). The AMA handbook of project management (Vol. 1). New York: American Manage- ment Association.

Fuller, M. A., Valacich, J. S., George, J. F., & Schneider, C. (2018). Information systems project management. Prospect Press: Burl- ington, VT.

Galin, D. (2018). Software quality. Hoboken, NJ: Wiley-IEEE Com- puter Society Press.

George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object- oriented analysis and design (2nd ed.). Upper Saddle River, NJ: Prentice Hall.

Gold, T. (2016). Ethics in IT outsourcing. Boca Raton: CRC Press. Guinan, P. J., Cooprider, J. G., & Faraj, S. (1998). Enabling soft-

ware development team performance during requirements definition: A behavioral versus technical approach. Informa- tion Systems Research, 9(2), 101–25.

Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern database man- agement (12th ed.). New York: Pearson Education.

Keane, T. (2017). Project management: Proven principles in agile proj- ect management for successful managers and businesses. Author.

Keil, M., Tan, B. C. Y., Wei, K. K., Saarinen, T., Tuunainen, V., and Wassenaar, A. (2000). A cross-cultural study on escalation of commitment behavior in software projects. MIS Quarterly, 24(2), 631–64.

Kendrick, T. (2015). Identifying and managing project risk: Essential tools for failure-proofing your project. New York: American Man- agement Association.

Kettelhut, M. C. (1991). Avoiding group-induced errors in systems development. Journal of Systems Management, 42(12), 13–17.

Moody, T., Provine, R., Todd, S., Tyler, N., Ryan, T. R., and Valerdi, R. (2018). Early life cycle cost estimation: Fiscal stewardship with engineered resilient systems.” In A. Madni, B. Boehm, R. Ghanem, D. Erwin, and M. Wheaton (Eds.), Disciplinary convergence in systems engineering research. Cham, Switzerland: Springer.

Martinelli, R.J., Waddell, J.M., and T.J. Rahschulte. (2017). Proj- ects Without Boundaries: Successfully Leading Teams and Managing Projects in a Virtual World. Hoboken, NJ: Wiley.

PMBOK. (2017). A guide to the project management body of knowl- edge (6th ed.). Newtown Square, PA: Project Management Institute.

Project Management Institute. (2002). Work breakdown structures. Newton Square, PA: Project Management Institute.

Rettig, M. (1990). Software Teams. Communications of the ACM, 33(10), 23–27.

Royce, W. (1998). Software project management. Boston: Addison-Wesley.

Verma, V. K. (1996). Human resource skills for the project manager: The Human Aspects of Project Management. Newton Square, PA: Project Management Institute.

Verma, V. K. (1997). Managing the project team. Newton Square, PA: Project Management Institute.

M03_VALA1629_09_GE_C03.indd 97 08/04/2020 16:35

not be a subsystem that spans “horizontally” throughout the entire system because these horizontal slices typically do not focus on a specific system feature, nor are they typi- cally good for demonstration to users. Basically, each verti- cal slice represents a use case of the system (see Chapter 7 for more information on use case diagrams). Also, note in Figure 3-32 that project management and planning is an activity that continues throughout the life of the project.

One outcome of defining the overall system as a collection of components is the likelihood that the com- ponents constructed earlier in the project will require greater rework than those developed later in the project. For example, during the early stages of the project, miss- ing components or a lack of understanding of key archi- tectural features will require that components developed early in the project be modified substantially as the proj- ect moves forward in order to integrate these components into a single comprehensive system successfully. This means that rework is a natural part of an OOSAD project and that one should not be overly concerned when this occurs. It is simply a characteristic of the iterative and incremental development process of OOSAD.

Complete Hard Problems First

Another characteristic of the OOSAD approach is that it tackles the hard problems first. In classic structured sys- tems development, a hard problem, such as choosing the physical implementation environment, is addressed late in the development process. As a result, following a classic sys- tems development approach tends to result in putting off

In this chapter, we have described how projects are man- aged when using a structured development approach. These concepts and techniques are very robust to a broad range of projects and development approaches. However, when developing a system using a more iterative design approach—such as prototyping or object-oriented analysis and design—there are some additional issues to consider. In this section, we will discuss some unique characteristics of these types of projects (see Fuller et al., 2018; Galin, 2018; George, Batra, Valacich, & Hoffer, 2007; Keane, 2017; Martinelli, et al., 2017.)

When a system is developed using an iterative approach, it means that, over the duration of the project, a portion of the final system is constructed during each itera- tion phase. In this way, the system evolves incrementally so that by the last iteration of the project, the entire system is completed (see Figure 3-31). In order for the system to evolve in this manner, the project manager must under- stand several unique characteristics of an OOSAD project.

DEFINE THE SYSTEM AS A SET OF COMPONENTS In order to manage the project as a series of iterations, the project manager must subdivide the overall system into a set of components; when combined, this set will yield the entire system (see Figure 3-32). Each of these separate sys- tem components is often referred to as a “vertical slice” of the overall system; this is a key feature of the system that can be demonstrated to users. Alternatively, each slice should

Unique Characteristics of an OOSAD Project

Learning Objectives After studying this section, you should be able to

3A.1 describe the unique characteristics of an OOSAD project.

object-oriented analysis and Design

Appendix

Project Management

M03_VALA1629_09_GE_C03.indd 98 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 99

FIGURE 3-32 Object-oriented development projects are developed using ongoing management and evolving system functionality

Iterations

S lic

Start of Project End of Project

1 2 3 4 5 6

C o

m p

o n en

t 1

C o

m p

o n en

t 2

C o

m p

o n en

t 3

C o

m p

o n en

t 4

C o

m p

o n en

t 5

C o

m p

o n en

t 6

C o

m p

o n en

t 7

C o

m p

o n en

t 8

C o

m p

o n en

t 9

C o

m p

o n en

t 1 0

C o

m p

o n en

t 1 1

C o

m p

o n en

t 1 2

C o

m p

o n en

t -1

C o

m p

o n en

Ongoing Project Management and Planning

FIGURE 3-31 During the OOSAD process, the system evolves incrementally over the life of the project

Evolving Prototypes

Start of Project End of Project

Completed System

Iteration 1 Iteration 2 Iteration

making some of the key systems architectural decisions until late in the project. This approach is sometimes problematic because such decisions often determine whether a project is a success or a failure. On the other hand, addressing hard problems as early as possible allows the difficult problems to be examined before substantial resources have been expended. This mitigates project risk.

In addition, completing the harder problems associated with the systems archi- tecture as early as possible helps in completing all subsequent components because most will build upon these basic architectural capabilities. (With some projects, the hardest components depend upon simpler components. In these cases, one must complete the simpler slices first before moving to the harder ones. Nonetheless, focus should be placed on the hard problems as soon as possible.) From a project planning perspective, this means that there is a natural progression and ordering of components over the life of the project. The initial iteration or two must focus on the system architecture such as the database or networking infrastructure. Once

M03_VALA1629_09_GE_C03.indd 99 08/04/2020 16:35

100 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

the architecture is completed, core system capabilities, such as creating and deleting records, are implemented. After the core system components are completed, detailed system features are implemented that help to fine-tune key system capabilities. During the final iteration phases, the primary focus is on activities that bring the project to a close (e.g., interface refinement, user manuals, and training; see Figure 3-33).

Using Iterations to Manage the Project

During each project iteration, all systems development life-cycle activities are per- formed (see Figure 3-34). This means that each project iteration has management and planning, analysis, design, and implementation and operation activities. For each iteration, the inputs to the process are the allocated project components—vertical slices or use cases—to perform during this iteration and the results from the prior iteration. The results of this iteration are then used as inputs to the next iteration. For example, as components are designed and implemented, much is learned about how subsequent components will need to be implemented. The learning that occurs dur- ing each iteration helps the project manager gain a better understanding about how subsequent components will be designed, what problems might occur, what resources are needed, and how long and complex a component will be to complete. As a result, most experienced project managers believe that it is a mistake to make project plans too detailed early in the project when much is still unknown.

Don’t Plan Too Much Up Front

During each iteration, more and more will be learned about how subsequent com- ponents will need to be designed, how long each might take to complete, and so on. Therefore, it is a mistake to make highly detailed plans far into the future because it is likely that these plans will be wrong. In OOSAD, as each iteration is completed, the goal is to learn more about the system being constructed, the capabilities of the devel- opment team, the complexity of the development environment, and so on. As this

FIGURE 3-33 The focus and ordering of system components change over the life of the project Start of Project

Focus

End of Project

1 2 3 4 5 6

C o

m p

o n en

t 1

C o

m p

o n en

t 2

C o

m p

o n en

t 3

C o

m p

o n en

t 4

C o

m p

o n en

t 5

C o

m p

o n en

t 6

C o

m p

o n en

t 7

C o

m p

o n en

t 8

C o

m p

o n en

t 9

C o

m p

o n en

t 1 0

C o

m p

o n en

t 1 1

C o

m p

o n en

t 1 2

Architecture Core Features Detailed Features Completion

Iterations

Ongoing Project Management and Planning

C o

m p

o n en

t -1

C o

m p

o n en

M03_VALA1629_09_GE_C03.indd 100 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 101

FIGURE 3-34 The workflow of an iteration

(Source: Based on Royce, 1998; George et al., 2007.)

Results Supplied to

Next Iteration

Allocated Project Activities

(Components)

Management and Planning

Analysis

Design

Implementations and Operations

Results from Prior Iteration

understanding is gained over the course of the project, the project manager is able to make better and better predictions and plans. As a result, making highly detailed plans for all project iterations is likely to result in a big waste of time. The project manager should be concerned only with making highly detailed plans for the next iteration or two. As the project manager learns over the course of the project, he or she will be able to continually refine schedules, time estimates, and resource requirements with better and better estimates (see Figure 3-35).

FIGURE 3-35 Planning estimation improves over time

(Source: Based on Royce, 1998; George et al., 2007.)

TransitionConstructionElaborationInception

E st

im at

io n E

rr o

rs O

ve r

T im

Time

Underestimated

Overestimated

X/4

M03_VALA1629_09_GE_C03.indd 101 08/04/2020 16:35

102 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

How Many and How Long Are Iterations?

One question that many people have when first experiencing OOSAD has to do with the number and duration of iterations. Iterations are designed to be a fixed length of time, typically from two to eight weeks, but they can be as short as one week (especially for smaller projects). During a single iteration, multiple components (use cases) can be completed. However, it is important not to try to pack the development of too many components into a single iteration. Experience has shown that having more iterations with fewer components to be completed is better than having only a few iterations with many components needing to be completed. It is only by iterating—completing a full systems development cycle—that significant learning can occur to help the project manager better plan subsequent iterations.

The inception phase generally will entail one iteration, but it is not uncommon for this to require two or more iterations in large, complex projects. Likewise, elabora- tion often is completed in one or two iterations, but again system complexity and size can influence this. Construction can range from two to several iterations, and transi- tion typically occurs over one or two iterations. Thus, experienced OOSAD project managers typically use from six to nine iterations when designing and constructing a system (see Figure 3-36). Note that all completed components are integrated into a comprehensive system at the conclusion of each iteration. During the first iteration, it is likely that simple component prototypes, such as file opening, closing, and saving, will be created. However, as the project progresses, the prototypes become increas- ingly sophisticated until the entire system is completed (see Figure 3-37).

Project Activity Focus Changes Over the Life of a Project

Over the life of a project, the project manager moves from iteration to iteration, beginning with inception and ending with the transition phase. Additionally, dur- ing all project iterations, the manager engages in all phases of the systems develop- ment cycle. However, the level of activity in each phase changes over the life of the

FIGURE 3-36 An OOSAD project typically has six to nine iterations

Inception (1–2 iterations)

6–9 Iterations

Elaboration (2–3 iterations)

Construction (3–5 iterations)

Transition (1–2 iterations)

Management and Planning

Analysis

Design

Implementation

Operation

M03_VALA1629_09_GE_C03.indd 102 08/04/2020 16:35

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 103

FIGURE 3-37 As the project evolves, system function- ality evolves

(Source: Based on Royce, 1998; George et al., 2007.)

Component Prototypes

Integrated Component

Alpha Release Beta Release

Iterations

Start of Project End of Project

1 2 3 4 5 6 7 8

100

Inception Elaboration Construction Transition

P er

ce n t

C o

m p

le te

project (see Figure 3-38). For example, throughout the life of the project, manage- ment and planning are an ongoing and important part of the project. Additionally, during inception the primary focus is analysis, during elaboration the primary focus is design, during construction the primary focus is implementation, and during transi- tion the primary focus is making the system operational. In sum, although all project life-cycle activities are employed during every project iteration, the mix and focus of these activities change over time.

FIGURE 3-38 The level and focus of activity across the systems development process change from the start to the end of the project

Inception (1–2 iterations)

Elaboration (2–3 iterations)

Construction (3–5 iterations)

Transition (1–2 iterations)

Management and Planning

Analysis

Design

Implementation

Operation

Start of Project End of Project

M03_VALA1629_09_GE_C03.indd 103 08/04/2020 16:35

104 PART I FOUNDATIONS FOR SYSTEMS DEVELOPMENT

SUMMARY When managing an OOSAD project, the project manager must define the project as a set of components. Once defined, these components can be analyzed and ordered so that the most difficult components are implemented first. An OOSAD project is managed by a series of itera- tions, and each iteration contains all phases of the systems development cycle. Over each iteration, more and more of the system is created (component by component), and more and more is learned about the system being con- structed, the capabilities of the development team, and

the complexity of the development environment. As this learning increases over time, the project manager is better able to plan project activities more accurately. Therefore, it is not good practice to plan long-range activities in great detail; detailed planning should occur only for the current and subsequent iteration. Most projects have six to nine iterations, but large projects could have several more. An iteration is a fixed time period, usually about two weeks, but it can be shorter or longer depending upon the character- istics of the project.

REVIEW QUESTION 3.60 Describe the unique characteristics of OOSAD proj-

ects that have ramifications for how these projects are managed.

PROBLEMS AND EXERCISES 3.61 Why should project managers complete hard problems

first in an OOSAD project? 3.62 Why is planning too much up front a mistake in an

OOSAD project?

M03_VALA1629_09_GE_C03.indd 104 08/04/2020 16:35

PETRIE ELECTRONICS

Chapter 3: Managing the Information Systems Project

Jim Watanabe, assistant director of information technology at Petrie Electronics, a Southern California-based electron- ics retail store, walked into his building’s conference room. It was early in the morning for Jim, but the meeting was important. Ella Whinston, the COO, had called the meet- ing. On the agenda was the proposed customer relation- ship project Ella told Jim about earlier in the week. She had asked Jim to be the project manager. If the project was approved by Petrie IS steering committee, it would be Jim’s first big project to manage at Petrie. He was excited about getting started.

“Hi Jim,” said Ella Whinston. With Ella was a man Jim did not know. “Jim, this is Bob Petroski. I know that the customer loyalty project has not been officially approved yet, but I am certain it will be. I’d like for Bob to be on your team, to represent me.”

Jim and Bob shook hands. “Nice to meet you, Jim. I’m looking forward to working with you.”

“And Bob knows how important this project is to me,” Ella said, “so I expect him to keep me informed about your progress.” Ella smiled.

Great, Jim thought, more pressure. That’s all I need. Just then, John Smith, the head of marketing, walked into

the conference room. With him was a young woman Jim recognized, but he wasn’t sure from where.

“Jim,” John said, “Let me introduce you to Sally Fukuyama. She is the assistant director of marketing. She will be repre- senting marketing, and me, on your ‘No Employee Escapes’ project. Assuming it gets official approval, of course.”

CHAPTER 3 ManagIng the InforMatIon SySteMS Project 105

“Hi, Jim,” Sally said, “I have a lot of ideas about what we can do. Even though I still have my regular job to worry about, I’m excited about working on this project.”

“Who else do you think should be on your team?” Ella asked.

“I’d like to bring in Sanjay Agarwal from IT,” Jim said. “He is in charge of systems integration in the IT depart- ment and reports to me. In addition to me and Sanjay and Sally and Bob, I think we should also have a store manager on the team. I’d like to suggest Juanita Lopez, the manager of the store in Irvine, California. She is really busy, but I think we have to have a store manager on the team.”

“Irvine?” Ella asked. “That’s one of our top stores. Juan- ita should have a lot of insight into the issues related to keeping customers, if she is managing the Irvine store. And you are right, she is going to be very busy.”

Case Questions

3.63 What qualities might Jim possess that would make him a successful project manager?

3.64 How do you think Jim should respond to Ella’s implied pressure about the importance of the project to her?

3.65 What strategies might Jim employ to deal with a very busy team member such as Juanita Lopez?

3.66 What should Jim do next to complete the project initiation?

3.67 List five team communication methods that Jim might use throughout this project. What are some pros and cons of each?

M03_VALA1629_09_GE_C03.indd 105 08/04/2020 16:35

This page intentionally left blank

A01_THOM6233_05_SE_WALK.indd 9 1/13/17 6:50 PM

Chapter 4 Identifying and Selecting Systems Development Projects

Planning

Chapter 5 Initiating and Planning Systems Development Projects

PA RT T W O

107

M04A_VALA1629_09_GE_P02.indd 107 08/04/2020 16:36

108

The demand for new or replacement systems exceeds the ability and resources of most organizations to conduct sys- tems development projects either by themselves or with consultants. This means that organizations must set pri- orities and a direction for systems development that will yield development projects with the greatest net benefits. As a systems analyst, you must analyze user information requirements, and you must also help make the business case—or justify why the system should be built and the development project conducted.

The reason for any new or improved information system (IS) is to add value to the organization. As sys- tems analysts, we must choose to use systems development resources to build the mix of systems that add the great- est value to the organization. How can we determine the business value of systems and identify those applications that provide the most critical gains? Part Two addresses this topic, the first phase of the systems development life cycle (SDLC), which we call planning. Business value comes from supporting the most critical business goals and helping the organization deliver on its business strat- egy. All systems, whether supporting operational or stra- tegic functions, must be linked to business goals. The two chapters in this part of the book show how to make this linkage.

The source of systems projects is either initiatives from IS planning (proactive identification of systems) or requests from users or IS professionals (reactions to problems or opportunities) for new or enhanced systems. In Chapter 4, we outline the linkages among corporate planning, IS planning, and the identification and selec- tion of projects. We do not include IS planning as part of the SDLC, but the results of IS planning greatly influ- ence the birth and conduct of systems projects. Chapter 4 makes a strong argument that IS planning not only pro- vides insights into choosing which systems an organiza- tion needs, but also describes the strategies necessary for evaluating the viability of any potential systems project.

A more frequent source of project identification originates from system service requests (SSRs) from business managers and IS professionals, usually for very focused systems or incremental improvements in existing

OVERVIEW

systems. Business managers request a new or replacement system when they believe that improved information ser- vices will help them do their jobs. IS professionals may request system updates when technological changes make current system implementations obsolete or when the performance of an existing system needs improvement. In either case, the request for service must be understood by management, and a justification for the system and associated project must be developed.

We continue with the Petrie Electronics case follow- ing Chapter 4. In this case, we show how an idea for a new IS project was stimulated by a synergy between corporate strategic planning and the creativity of an individual busi- ness manager.

Chapter 5 focuses on what happens after a project has been identified and selected: the next step in making the business case, initiating and planning the proposed system request. This plan develops a better understand- ing of the scope of the potential system change and the nature of the needed system features. From this prelimi- nary understanding of system requirements, a project plan is developed that shows both the detailed steps and resources needed in order to conduct the analysis phase of the life cycle and the more general steps for subsequent phases. The feasibility and potential risks of the requested system are also outlined, and an economic cost–benefit analysis is conducted to show the potential impact of the system change. In addition to the economic feasibility or justification of the system, technical, organizational, political, legal, scheduling, and other feasibilities are assessed. Potential risks—unwanted outcomes—and plans for dealing with these possibilities are identified. Project initiation and planning end when a formal proposal for the systems development project is completed and sub- mitted for approval to the person who must commit the resources to systems development. If approved, the proj- ect moves into the analysis phase of the SDLC.

We illustrate a typical project initiation and planning phase in a Petrie Electronics case following Chapter 5. In this case, we show how the company developed its project scope statement and addressed various aspects of the project’s initiation and planning stage.

PART TWO

Planning

M04A_VALA1629_09_GE_P02.indd 108 08/04/2020 16:36

109

Identifying and Selecting Systems Development Projects4

and what data, where there are overlaps or inconsistencies, and the accuracy of the information. The reason that per- sonal and departmental systems and databases abound is that users are either unaware of the information that exists in corporate databases or they cannot easily get at it, so they create and maintain their own information and systems. Intelligent identification and selection of system projects, for both new and replacement systems, is a critical step in gaining control of systems and data. It is the hope of many chief information officers (CIOs) that with the advent of ERP systems, improved system integration, and the rapid deployment of corporate Internet solutions, these islands will be reduced or eliminated (Harvard Business Review, 2011; Luftman, 2011; Newbold & Azua, 2007; Sanders, 2017; Weill & Ross, 2009).

The acquisition, development, and maintenance of information systems consume substantial resources for most organizations. This suggests that organizations can benefit from following a formal process for identifying and select- ing projects. The first phase of the systems development life cycle—project identification and selection—deals with this issue. In the next section, you will learn about a general method for identifying and selecting projects and the deliv- erables and outcomes from this process. This is followed by brief descriptions of corporate strategic planning and information systems planning, two activities that can greatly improve the project identification and selection process.

The scope of information systems today is the whole enterprise. Managers, knowledge workers, and all other organizational members expect to easily access and retrieve information, regardless of its location. Nonin- tegrated systems used in the past—often referred to as “islands of information”—are being replaced with coop- erative, integrated enterprise systems that can easily sup- port information sharing. Although the goal of building bridges between these “islands” will take some time to achieve, it represents a clear direction for information sys- tems development. The use of enterprise resource plan- ning (ERP) systems from companies such as SAP (www. sap.com) and Oracle (www.oracle.com), has enabled the linking of these “islands” in many organizations. Addition- ally, as the use of the Internet continues to evolve to sup- port business activities, systems integration has become a paramount concern of organizations (Bass, Weber, & Zhu, 2015; Burd, 2015; Luftman, 2011; Westerman, Bonnet, & McAfee, 2014; Weill & Ross, 2009; Windpassinger, 2017).

Obtaining integrated, enterprise-wide computing presents significant challenges for both corporate and information systems management. For example, given the proliferation of personal and departmental computing wherein disparate systems and databases have been created, how can the organization possibly control and maintain all of these systems and data? In many cases they simply can- not; it is nearly impossible to track who has which systems

4.3 describe the three classes of Internet electronic commerce applications: business-to-consumer, business-to-employee, and business-to-business.

Learning Objectives After studying this chapter, you should be able to

4.1 describe the project identification and selection process;

4.2 describe the corporate strategic planning and information systems planning process; and

Introduction

M04B_VALA1629_09_GE_C04.indd 109 08/04/2020 16:37

http://www.sap.com

http://www.oracle.com

110 PART II PLANNING

IDENTIFYING AND SELECTING SYSTEMS DEVELOPMENT PROJECTS The first phase of the SDLC is planning, consisting of project identification and selec- tion, and project initiation and planning (see Figure 4-1). During project identifica- tion and selection, a senior manager, a business group, an IS manager, or a steering committee identifies and assesses all possible systems development projects that an organization unit could undertake. Next, those projects deemed most likely to yield significant organizational benefits, given available resources, are selected for subse- quent development activities. Organizations vary in their approach to identifying and selecting projects. In some organizations, project identification and selection is a very formal process in which projects are outcomes of a larger overall planning process. For example, a large organization may follow a formal project identification process whereby a proposed project is rigorously compared with all competing projects. Alter- natively, a small organization may use informal project selection processes that allow the highest-ranking IS manager to independently select projects or allow individual business units to decide on projects after agreeing to provide project funding.

Information systems development requests come from a variety of sources. One source is requests by managers and business units for replacing or extending an exist- ing system to gain needed information or to provide a new service to customers. Another source for requests is IS managers who want to make a system more efficient and less costly to operate, or want to move it to a new operating environment. A final source of projects is a formal planning group that identifies projects for improvement to help the organization meet its corporate objectives (e.g., a new system to provide better customer service). Regardless of how a given organization actually executes the project identification and selection process, a common sequence of activities occurs. In the following sections, we describe a general process for identifying and selecting projects and producing the deliverables and outcomes of this process.

FIGURE 4-1 Systems development life cycle with project identification and selection highlighted

DesignImplementation

Maintenance Analysis

Planning

Project Identification and Selection Project Initiation and Planning

M04B_VALA1629_09_GE_C04.indd 110 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 111

The Process of Identifying and Selecting IS Development Projects

Project identification and selection consists of three primary activities:

1. Identifying potential development projects 2. Classifying and ranking IS development projects 3. Selecting IS development projects

Each of these steps is described below:

1. Identifying potential development projects. Organizations vary as to how they identify projects. This process can be performed by

• a key member of top management, either the CEO of a small or medium-sized organization or a senior executive in a larger organization;

• a steering committee, composed of a cross section of managers with an inter- est in systems;

• user departments, in which either the head of the requesting unit or a commit- tee from the requesting department decides which projects to submit (often you, as a systems analyst, will help users prepare such requests); or

• the development group or a senior IS manager.

All methods of identification have been found to have strengths and weak- nesses. Research has found, for example, that projects identified by top man- agement more often have a strategic organizational focus. Alternatively, projects identified by steering committees more often reflect the diversity of the commit- tee and therefore have a cross-functional focus. Projects identified by individual departments or business units most often have a narrow, tactical focus. Finally, a dominant characteristic of projects identified by the development group is the ease with which existing hardware and systems will integrate with the proposed project. Other factors, such as project cost, duration, complexity, and risk, are also influenced by the source of a given project. Characteristics of each selection method are briefly summarized in Table 4-1. In addition to who makes the deci- sion, characteristics specific to the organization—such as the level of firm diversi- fication, level of vertical integration, or extent of growth opportunities—can also influence any investment or project selection decision (Dewan & Min, 1998; Fuller, Valacich, George, & Schneider, 2018; Harvard Business Review, 2011; Luftman, 2011; Thomas & Fernandez, 2008; Weill & Ross, 2009).

Selection Method Characteristics

Top Management Greater strategic focus Largest project size Longest project duration Enterprise-wide consideration

Steering Committee Cross-functional focus Greater organizational change Formal cost–benefit analysis Larger and riskier projects

Functional Area Narrow, nonstrategic focus Faster development Fewer users, management layers, and business functions involved

Development Group Integration with existing systems focus Fewer development delays Less concern with cost–benefit analysis

(Source: Based on Fuller et al., 2018; McKeen et al., 1994; GAO, 2000.)

TABLE 4-1 Characteristics of Alternative Methods for Making Information Systems Identification and Selection Decisions

M04B_VALA1629_09_GE_C04.indd 111 08/04/2020 16:37

112 PART II PLANNING

Of all the possible project sources, those identified by top management and steering committees most often reflect the broader needs of the organization. This occurs because top management and steering committees are likely to have a broader understanding of overall business objectives and constraints. Projects identified by top management or by a diverse steering committee are therefore referred to as coming from a top-down source.

Projects identified by a functional manager, business unit, or by the informa- tion systems development group are often designed for a particular business need within a given business unit. In other words, these projects may not reflect the overall objectives of the organization. This does not mean that projects identified by individual managers, business units, or the IS development group are deficient, only that they may not consider broader organizational issues. Project initiatives stemming from managers, business units, or the development group are gener- ally referred to as coming from a bottom-up source. These are the types of projects in which you, as a systems analyst, will have the earliest role in the life cycle as part of your ongoing support of users. You will help user managers provide the description of information needs and the reasons for doing the project that will be evaluated in selecting, among all submitted projects, which ones will be approved to move into the project initiation and planning phase of the SDLC.

In sum, projects are identified by both top-down and bottom-up initiatives. The formality of the process of identifying and selecting projects can vary substan- tially across organizations. Also, because limited resources preclude the develop- ment of all proposed systems, most organizations have a process of classifying and ranking the merit of each project. Those projects deemed inconsistent with overall organizational objectives, redundant in functionality to some existing system, or unnecessary will thus be removed from consideration. This topic is discussed next.

2. Classifying and ranking IS development projects. The second major activity in the proj- ect identification and selection process focuses on assessing the relative merit of potential projects. As with the project identification process, classifying and rank- ing projects can be performed by top managers, a steering committee, business units, or the IS development group. Additionally, the criteria used when assigning the relative merit of a given project can vary. Commonly used criteria for assessing projects are summarized in Table 4-2. In any given organization, one or several criteria might be used during the classifying and ranking process.

As with the project identification and selection process, the actual criteria used to assess projects will vary by organization. If, for example, an organization uses a steering committee, it may choose to meet monthly or quarterly to review projects and use a wide variety of evaluation criteria. At these meetings, new proj- ect requests will be reviewed relative to projects already identified, and ongoing projects are monitored. The relative ratings of projects are used to guide the final activity of this identification process—project selection.

Evaluation Criteria Description

Value Chain Analysis Extent to which activities add value and costs when developing products and/or services

Strategic Alignment Extent to which the project is viewed as helping the organization achieve its strategic objectives and long-term goals

Potential Benefits Extent to which the project is viewed as improving profits, customer service, and so forth, and the duration of these benefits

Resource Availability Amount and type of resources the project requires and their availability

Project Size/Duration Number of individuals and the length of time needed to complete the project

Technical Difficulty/Risks Level of technical difficulty to successfully complete the project within given time and resource constraints

TABLE 4-2 Possible Evaluation Criteria When Classifying and Ranking Projects

M04B_VALA1629_09_GE_C04.indd 112 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 113

An important project evaluation method that is widely used for assessing information systems development projects is called value chain analysis ( Culbreth, 2017; Foss & Saebi, 2015; Porter, 1985; Van den Berg & Pietersma, 2015). Value chain analysis is the process of analyzing an organization’s activities for making products and/or services to determine where value is added and costs are incurred. Once an organization gains a clear understanding of its value chain, improvements in the organization’s operations and performance can be achieved. Information systems projects providing the greatest benefit to the value chain will be given priority over those with fewer benefits.

As you might have guessed, information systems have become one of the primary ways for organizations to make changes and improvements in their value chains. Many organizations, for example, are using the Internet to exchange important business information with suppliers and customers, such as orders, invoices, and receipts. To conduct a value chain analysis for an organization, think about an organization as a big input/output process (see Figure 4-2). At one end are the inputs to the organization, for example, supplies that are purchased. Within the organizations, those supplies and resources are integrated in some way to produce products and services. At the other end are the outputs, which repre- sent the products and services that are marketed, sold, and then distributed to customers. In value chain analysis, you must first understand each activity, func- tion, and process where value is or should be added. Next, determine the costs (and the factors that drive costs or cause them to fluctuate) within each of the areas. After understanding your value chain and costs, you can benchmark (com- pare) your value chain and associated costs with those of other organizations, preferably your competitors. By making these comparisons, you can identify priori- ties for applying information systems projects.

3. Selecting IS development projects. The final activity in the project identification and selection process is the actual selection of projects for further development. Proj- ect selection is a process of considering both short- and long-term projects and selecting those most likely to achieve business objectives. Additionally, as business conditions change over time, the relative importance of any single project may substantially change. Thus, the identification and selection of projects is a very important and ongoing activity.

Numerous factors must be considered when making project selection deci- sions. Figure 4-3 shows that a selection decision requires that the perceived needs of the organization, existing systems and ongoing projects, resource availability, evaluation criteria, current business conditions, and the perspectives of the deci- sion makers will all play a role in project selection decisions. Numerous outcomes can occur from this decision process. Of course, projects can be accepted or rejected. Acceptance of a project usually means that funding to conduct the next phase of the SDLC has been approved. Rejection means that the project will no longer be considered for development. However, projects may also be condition- ally accepted; they may be accepted pending the approval or availability of needed resources or the demonstration that a particularly difficult aspect of the system can be developed. Projects may also be returned to the original requesters, who are told to develop or purchase the requested system. Finally, the requesters of a project may be asked to modify and resubmit their request after making suggested changes or clarifications.

Value chain analysis Analyzing an organization’s activities to determine where value is added to products and/or services and the costs incurred for doing so; it usually also includes a comparison with the activities, added value, and costs of other organizations for the purpose of making improvements in the organiza- tion’s operations and performance.

FIGURE 4-2 Organizations can be thought of as a value chain, transforming raw materials into products for customers

(Sources: Left to right: Bram van Broekhoven/Shutterstock; Alexey Fursov/Shutterstock; Hacohob/Shutter- stock; Syda Productions/Shutterstock)

Transform Raw Materials into

Products

Storage and Distribution of Products

Marketing, Sales, and

Customer Support

M04B_VALA1629_09_GE_C04.indd 113 08/04/2020 16:37

114 PART II PLANNING

One method for deciding among different projects, or when considering alter- native designs for a given system, is illustrated in Figure 4-4. For example, suppose that, for a given system that has been identified and selected, there are three alterna- tive designs that could be pursued—A, B, or C. Let’s also suppose that early planning meetings identified three key system requirements and four key constraints that could be used to help make a decision on which alternative to pursue. In the left column of Figure 4-4, three system requirements and four constraints are listed. Because not all requirements and constraints are of equal importance, they are weighted based on their relative importance. In other words, you do not have to weight requirements and constraints equally; it is certainly possible to make requirements more or less important than constraints. Weights are arrived at in discussions among the analysis team, users, and sometimes managers. Weights tend to be fairly subjective and, for that reason, should be determined through a process of open discussion to reveal underlying assumptions, followed by an attempt to reach consensus among stakehold- ers. Notice that the total of the weights for both the requirements and constraints is 100 percent.

FIGURE 4-3 Project selection decisions must consider numerous factors and can have numerous outcomes

Existing and Available

Resources

Perceived and Real Needs

List of Potential and Ongoing

Projects

Current Organizational Environment

Evaluation Criteria

Project Selection Decision

Decision Outcome

• Accept Project • Reject Project • Delay Project • Refocus Project • End-User Development • Proof of Concept

FIGURE 4-4 Alternative projects and system design decisions can be assisted using weighted multicriteria analysis

Criteria Weight Alternative A Alternative B Alternative C

Rating Score Rating Score Rating Score

Requirements

Real-time data entry 18 5 90 5 90 5 90

Automatic reorder 18 1 18 5 90 5 90

Real-time data query 4 1 14 5 70 5 70

50 122 250 250

Constraints

Developer costs 15 4 60 5 75 3 45

Hardware costs 15 4 60 4 60 3 45

Operating costs 15 5 75 1 15 5 75

Ease of training 5 5 25 3 15 3 15

50 220 165 180

Total 100 342 415 430

M04B_VALA1629_09_GE_C04.indd 114 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 115

Next, each requirement and constraint is rated on a scale of 1 to 5. A rating of 1 indicates that the alternative does not meet the requirement very well or that the alternative violates the constraint. A rating of 5 indicates that the alternative meets or exceeds the requirement or clearly abides by the constraint. Ratings are even more subjective than weights and should also be determined through open discussion among users, analysts, and managers. For each requirement and constraint, a score is calculated by multiplying the rating for each requirement and each constraint by its weight. The final step is to add the weighted scores for each alternative. Notice that we have included three sets of totals: for requirements, for constraints, and overall totals. If you look at the totals for requirements, alternative B or C is the best choice because both meet or exceed all requirements. However, if you look only at con- straints, alternative A is the best choice because it does not violate any constraints. When we combine the totals for requirements and constraints, we see that the best choice is alternative C. Whether alternative C is actually chosen for development, how- ever, is another issue. The decision makers may choose alternative A, knowing that it does not meet two key requirements, because it has the lowest cost. In short, what may appear to be the best choice for a systems development project may not always be the one that ends up being developed. By conducting a thorough analysis, organizations can greatly improve their decision-making performance.

Deliverables and Outcomes

The primary deliverable from the first part of the planning phase is a schedule of spe- cific IS development projects, coming from both top-down and bottom-up sources, to move into the next part of the planning phase—project initiation and planning (see Figure 4-5). An outcome of this phase is the assurance that careful consideration was given to project selection, with a clear understanding of how each project can help the organization reach its objectives. Due to the principle of incremental commitment, a selected project does not necessarily result in a working system. After each subsequent SDLC phase, you, other members of the project team, and organizational officials will reassess your project to determine whether the business conditions have changed or whether a more detailed understanding of a system’s costs, benefits, and risks would suggest that the project is not as worthy as previously thought.

Many organizations have found that in order to make good project selection decisions, a clear understanding of overall organizational business strategy and objec- tives is required. This means that a clear understanding of the business and the desired role of information systems in achieving organizational goals is a precondition to

Incremental commitment A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of the project is rejustified.

FIGURE 4-5 Information systems development projects come from both top-down and bottom-up initiatives

Top Down

Bottom Up

Schedule of Projects 1. ... 2. ... 3. ...

Evaluate, Prioritize, and

Schedule Projects

Sources of Potential Projects

Project Identification and Selection

Project Initiation and Planning

• Top Management • Steering Committee

• User Departments • Development Group

M04B_VALA1629_09_GE_C04.indd 115 08/04/2020 16:37

116 PART II PLANNING

improving the identification and selection process. In the next section, we provide a brief overview of the process many organizations follow—involving corporate strategic planning and information systems planning—when setting their business strategy and objectives and when defining the role of information systems in their plans.

CORPORATE AND INFORMATION SYSTEMS PLANNING Although there are numerous motivations for carefully planning the identification and selection of projects (see Atkinson, 1990; Dyche, 2015; Harvard Business Review, 2011; Luftman, 2011; Weill & Ross, 2009; Windpassinger, 2017), organizations have not traditionally used a systematic planning process when determining how to allo- cate IS resources. Instead, projects have often resulted from attempts to solve iso- lated organizational problems. In effect, organizations have asked the question: “What procedure (application program) is required to solve this particular problem as it exists today?” The difficulty with this approach is that the required organizational procedures are likely to change over time as the environment changes. For example, a company may decide to change its method of billing customers or a university may change its procedure for registering students. When such changes occur, it is usually necessary to again modify existing information systems.

In contrast, planning-based approaches essentially ask the question: “What infor- mation (or data) requirements will satisfy the decision-making needs or business pro- cesses of the enterprise today and well into the future?” A major advantage of this approach is that an organization’s informational needs are less likely to change (or will change more slowly) than its business processes. For example, unless an organi- zation fundamentally changes its business, its underlying data structures may remain reasonably stable for more than 10 years. However, the procedures used to access and process the data may change many times during that period. Thus, the challenge of most organizations is to design comprehensive information models containing data that are relatively independent from the languages and programs used to access, cre- ate, and update them.

To benefit from a planning-based approach for identifying and selecting proj- ects, an organization must analyze its information needs and plan its projects carefully. Without careful planning, organizations may construct databases and systems that support individual processes but do not provide a resource that can be easily shared throughout the organization. Further, as business processes change, lack of data and systems integration will hamper the speed at which the organization can effectively make business strategy or process changes.

The need for improved information systems project identification and selection is readily apparent when we consider factors such as the following:

1. The cost of information systems has risen steadily and approaches 40 percent of total expenses in some organizations.

2. Many systems cannot handle applications that cross organizational boundaries. 3. Many systems often do not address the critical problems of the business as a whole

or support strategic applications. 4. Data redundancy is often out of control, and users may have little confidence in

the quality of data. 5. Systems maintenance costs are out of control as old, poorly planned systems must

constantly be revised. 6. Application backlogs often extend three years or more, and frustrated end users

are forced to create (or purchase) their own systems, often creating redundant databases and incompatible systems in the process.

Careful planning and selection of projects alone will certainly not solve all of these problems. We believe, however, that a disciplined approach, driven by top man- agement commitment, is a prerequisite for most effectively applying information

M04B_VALA1629_09_GE_C04.indd 116 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 117

systems in order to reach organizational objectives. The focus of this section is to provide you with a clear understanding of how specific development projects with a broader organizational focus can be identified and selected. Specifically, we describe corporate strategic planning and information systems planning, two processes that can significantly improve the quality of project identification and selection decisions. This section also outlines the types of information about business direction and general systems requirements that can influence selection decisions and guide the direction of approved projects.

Corporate Strategic Planning

A prerequisite for making effective project selection decisions is to gain a clear idea of where an organization is, its vision of where it wants to be in the future, and how to make the transition to its desired future state. Figure 4-6 represents this as a three-step process. The first step focuses on gaining an understanding of the current enterprise. In other words, if you don’t know where you are, it is impossible to tell where you are going. Next, top management must determine where it wants the enterprise to be in the future. Finally, after gaining an understanding of the current and future enter- prise, a strategic plan can be developed to guide this transition. The process of devel- oping and refining models of the current and future enterprise as well as a transition strategy is often referred to as corporate strategic planning. During corporate strategic planning, executives typically develop a mission statement, statements of future corpo- rate objectives, and strategies designed to help the organization reach its objectives.

All successful organizations have a mission. The mission statement of a company typically states in very simple terms what business the company is in. For example, the mission statement for Pine Valley Furniture (PVF) is shown in Figure 4-7. After review- ing PVF’s mission statement, it becomes clear that it is in the business of constructing and selling high-quality wood furniture to the general public, businesses, and institu- tions such as universities and hospitals. It is also clear that PVF is not in the business of fabricating steel file cabinets or selling its products through wholesale distributors. Based on this mission statement, you could conclude that PVF does not need a retail sales information system; instead, a high-quality human resource information system would be consistent with its goal.

After defining its mission, an organization can then define its objectives. Objective statements refer to “broad and timeless” goals for the organization. These goals can be expressed as a series of statements that are either qualitative or quantita- tive but that typically do not contain details likely to change substantially over time. Objectives are often referred to as critical success factors. Here, we will simply use the term objectives. The objectives for PVF are shown in Figure 4-8, with most relating to

Corporate strategic planning An ongoing process that defines the mission, objectives, and strategies of an organization.

Mission statement A statement that makes it clear what business a company is in.

Objective statements A series of statements that express an organization’s qualitative and quantita- tive goals for reaching a desired future position.

FIGURE 4-6 Corporate strategic planning is a three-step process

Current Enterprise

Future Enterprise

Strategic Plan

Step 1

Step 2

Step 3

FIGURE 4-7 Mission statement (Pine Valley Furniture)

Pine Valley Furniture Corporate Mission Statement

We are in the business of designing, fabricating, and selling to retail stores high-quality wood furniture for household, o�ce, and institutional use. We value quality in our products and in our relationships with customers and suppliers. We consider our employees our most critical resource.

M04B_VALA1629_09_GE_C04.indd 117 08/04/2020 16:37

118 PART II PLANNING

some aspect of the organizational mission. For example, the second objective relates to how PVF views its relationships with customers. This goal would suggest that PVF might want to invest in a Web-based order tracking system that would contribute to high-quality customer service. Once a company has defined its mission and objectives, a competitive strategy can be formulated.

A competitive strategy is the method by which an organization attempts to achieve its mission and objectives. In essence, the strategy is an organization’s game plan for playing in the competitive business world. In his classic book on competitive strategy, Michael Porter, 1980 defined three generic strategies—low-cost producer, product differentiation, and product focus or niche—for reaching corporate objec- tives (see Table 4-3). These generic strategies allow you to more easily compare two companies in the same industry that may not employ the same competitive strategy. In addition, organizations employing different competitive strategies often have dif- ferent informational needs to aid decision making. For example, Rolls-Royce and Kia Motors are two car lines with different strategies: One is a high-prestige line in the ultra-luxury niche, whereas the other is a relatively low-priced line for the general auto- mobile market. Rolls-Royce may build information systems to collect and analyze

Competitive strategy The method by which an organization attempts to achieve its mission and objectives.

FIGURE 4-8 Statement of corporate objectives (Pine Valley Furniture)

Pine Valley Furniture Statement of Objectives

PVF will strive to increase market share and profitability (prime objective).

PVF will be considered a market leader in customer service.

PVF will be innovative in the use of technology to help bring new products to market faster than our competition.

PVF will employ the fewest number of the highest-quality people necessary to accomplish our prime objective.

PVF will create an environment that values diversity in gender, race, values, and culture among employees, suppliers, and customers.

Strategy Description

Low-Cost Producer This strategy reflects competing in an industry on the basis of product or service cost to the consumer. For example, in the automobile industry, the South Korean–produced Hyundai is a product line that competes on the basis of low cost.

Product Differentiation This competitive strategy reflects capitalizing on a key product criterion requested by the market (for example, high quality, style, performance, roominess). In the automobile industry, many manufacturers are trying to differentiate their products on the basis of quality (e.g., “At Ford, quality is job one.”).

Product Focus or Niche This strategy is similar to both the low-cost and differentiation strategies but with a much narrower market focus. For example, a niche market in the automobile industry is the convertible sports car market. Within this market, some manufacturers may employ a low-cost strategy and others may employ a differen- tiation strategy based on performance or style.

TABLE 4-3 Generic Competitive Strategies

M04B_VALA1629_09_GE_C04.indd 118 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 119

information on customer satisfaction to help manage a key company objective. Alternatively, Kia may build systems to track plant and material utilization in order to manage activities related to its low-cost strategy.

To effectively deploy resources such as the creation of a marketing and sales organization or to build the most effective information systems, an organization must clearly understand its mission, objectives, and strategy. A lack of understanding will make it impossible to know which activities are essential to achieving business objec- tives. From an information systems development perspective, by understanding which activities are most critical for achieving business objectives, an organization has a much greater chance to identify those activities that need to be supported by informa- tion systems. In other words, it is only through the clear understanding of the organizational mission, objectives, and strategies that IS development projects should be identified and selected. The process of planning how information systems can be employed to assist organiza- tions to reach their objectives is the focus of the next section.

Information Systems Planning

The second planning process that can play a significant role in the quality of project identification and selection decisions is called information systems planning (ISP). ISP is an orderly means of assessing the information needs of an organization and defining the information systems, databases, and technologies that will best satisfy those needs (Amrollahi, Ghapanchi, & Talaei & Khoei, 2014; Carlson, Gardner, & Ruth, 1989; Cas- sidy, 2005; Luftman, 2011; Parker & Benson, 1989; Segars & Grover, 1999; Weill & Ross, 2009; Windpassinger, 2017). This means that during ISP you (or, more likely, senior IS managers responsible for the IS plan) must model current and future organization informational needs and develop strategies and project plans to migrate the current information systems and technologies to their desired future state. ISP is a top-down process that takes into account the outside forces—industry, economic, relative size, geographic region, and so on—that are critical to the success of the firm. This means that ISP must look at information systems and technologies in terms of how they help the business achieve its objectives as defined during corporate strategic planning.

The three key activities of this modeling process are represented in Figure 4-9. Like corporate strategic planning, ISP is a three-step process in which the first step is to assess current IS-related assets—human resources, data, processes, and technologies. Next,

Information systems planning (ISP) An orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs.

FIGURE 4-9 Information systems planning is a three-step process

Current Situation: • listing of manual and automated processes • listing of manual and automated data • technology inventory • human resources inventory

Future Situation: • blueprints of manual and automated processes • blueprints of manual and automated data • technology blueprints • human resources blueprints

Schedule of Projects:

Step 1

Step 2

Step 3

M04B_VALA1629_09_GE_C04.indd 119 08/04/2020 16:37

120 PART II PLANNING

target blueprints of these resources are developed. These blueprints reflect the desired future state of resources needed by the organization to reach its objectives as defined during strategic planning. Finally, a series of scheduled projects is defined to help move the organization from its current to its future desired state. (Of course, scheduled projects from the ISP process are just one source for projects. Others include bottom-up requests from managers and business units, such as the SSR in Figure 3-2.)

For example, a project may focus on reconfiguration of a telecommunications net- work to speed data communications or it may restructure work and data flows between business areas. Projects can include not only the development of new information systems or the modification of existing ones, but also the acquisition and management of new systems, technologies, and platforms. These three activities parallel those of corporate strategic planning, and this relationship is shown in Figure 4-10. Numerous methodologies such as Business Systems Planning (BSP) and Information Engineering (IE) have been developed to support the ISP process (see Amrollahi et al., 2014; Segars & Grover, 1999); most contain the following three key activities:

1. Describe the current situation. The most widely used approach for describing the current organizational situation is generically referred to as top-down planning. Top-down planning attempts to gain a broad understanding of the informational needs of the entire organization. The approach begins by conducting an extensive analysis of the organization’s mission, objectives, and strategy and determining the information requirements needed to meet each objective. This approach to ISP implies by its name a high-level organizational perspective with active involvement of top-level management. The top-down approach to ISP has several advantages over other planning approaches, which are summarized in Table 4-4.

In contrast to the top-down planning approach, a bottom-up planning approach requires the identification of business problems and opportunities that are used to define projects. Using the bottom-up approach for creating IS plans can be faster and less costly than using the top-down approach; it also has the advantage of identifying pressing organizational problems. Yet, the bottom-up approach often fails to view the informational needs of the entire organization. This can result in the creation of disparate information systems and databases that are redundant or not easily integrated without substantial rework.

Top-down planning A generic ISP methodology that attempts to gain a broad understanding of the information systems needs of the entire organization.

Bottom-up planning A generic information systems planning methodology that identifies and defines IS development projects based upon solving operational business problems or taking advantage of some business opportunities.

FIGURE 4-10 Parallel activities of corporate strategic planning and information systems planning

Current Situation: • listing of manual and automated processes • listing of manual and automated data • technology inventory • human resources inventory

Future Situation: • blueprints of manual and automated processes • blueprints of manual and automated data • technology blueprints • human resources blueprints

Schedule of Projects:

Corporate Strategic Planning Information Systems Planning

Current Enterprise

Future Enterprise

Strategic Plan

M04B_VALA1629_09_GE_C04.indd 120 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 121

PINE VALLEY FURNITURE

Advantage Description

Broader Perspective If not viewed from the top, information systems may be implemented without first understanding the business from general management’s viewpoint.

Improved Integration If not viewed from the top, totally new management information systems may be implemented rather than planning how to evolve existing systems.

Improved Management Support If not viewed from the top, planners may lack sufficient management acceptance of the role of information systems in helping them achieve business objectives.

Better Understanding If not viewed from the top, planners may lack the understanding necessary to implement information systems across the entire business rather than simply to individual operating units.

(Source: Based on IBM, 1982; Slater, 2002; Overby, 2008.)

TABLE 4-4 Advantages to the Top-Down Planning Approach Over Other Planning Approaches

The process of describing the current situation begins by selecting a plan- ning team that includes executives chartered to model the existing situation. To gain this understanding, the team will need to review corporate documents; interview managers, executives, and customers; and conduct detailed reviews of competitors, markets, products, and finances. The type of information that must be collected to represent the current situation includes the identification of all organizational locations, units, functions, processes, data (or data entities), and information systems.

Within PVF, for example, organizational locations would consist of a list of all geographic areas in which the organization operates (e.g., the locations of the home and branch offices). Organizational units represent a list of people or business units that operate within the organization. Thus, organizational units would include vice president of manufacturing, sales manager, salesperson, and clerk. Functions are cross-organizational collections of activities used to perform day-to-day business operations. Examples of business functions might include research and develop- ment, employee development, purchasing, and sales. Processes represent a list of manual or automated procedures designed to support business functions. Exam- ples of business processes might include payroll processing, customer billing, and product shipping. Data entities represent a list of the information items generated, updated, deleted, or used within business processes. Information systems represent automated and nonautomated systems used to transform data into information to support business processes. For example, Figure 4-11 shows portions of the business functions, data entities, and information systems of PVF. Once high-level informa- tion is collected, each item can typically be decomposed into smaller units as more detailed planning is performed. Figure 4-12 shows the decomposition of several of PVF’s high-level business functions into more detailed supporting functions.

FIGURE 4-11 Information systems planning information (Pine Valley Furniture)

FUNCTIONS: DATA ENTITIES: INFORMATION SYSTEMS: business planning customer payroll processing product development product accounts payable marketing and sales vendor accounts receivable production operations raw material time card processing finance and accounting order inventory management human resources invoice …

… equipment …

M04B_VALA1629_09_GE_C04.indd 121 08/04/2020 16:37

122 PART II PLANNING

After creating these lists, a series of matrices can be developed to cross refer- ence various elements of the organization. The types of matrices typically devel- oped include the following:

• Location-to-Function: This matrix identifies which business functions are being performed at various organizational locations.

• Location-to-Unit: This matrix identifies which organizational units are located in or interact with a specific business location.

• Unit-to-Function: This matrix identifies the relationships between organiza- tional entities and each business function.

• Function-to-Objective: This matrix identifies which functions are essential or desirable in achieving each organizational objective.

• Function-to-Process: This matrix identifies which processes are used to support each business function.

• Function-to-Data Entity: This matrix identifies which business functions utilize which data entities.

• Process-to-Data Entity: This matrix identifies which data are captured, used, updated, or deleted within each process.

• Process-to-Information System: This matrix identifies which information sys- tems are used to support each process.

• Data Entity-to-Information System: This matrix identifies which data are cre- ated, updated, accessed, or deleted in each system.

• Information System-to-Objective: This matrix identifies which information systems support each business objective as identified during organizational planning.

FIGURE 4-12 Functional decomposition of information systems planning information (Pine Valley Furniture)

(Source: Microsoft Corporation.)

M04B_VALA1629_09_GE_C04.indd 122 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 123

FIGURE 4-13 Data Entity-to-Function matrix (Pine Valley Furniture)

Marketing and Sales

Marketing Research

Order Fulfillment

Distribution

Production Operation

Production Scheduling

Fabrication

Assembly

Finishing

Finance and Accounting

Capital Budgeting

Accounts Receivable

Accounts Payable

...

Customer Product Vendor Raw Material

Order Work Center

Equipment Employees Invoice Work Order

...

Different matrices will have different relationships depending on what is being represented. For example, Figure 4-13 shows a portion of the Data Entity-to- Function matrix for PVF. The “X” in various cells of the matrix represents which business functions utilize which data entities. A more detailed picture of data utilization would be shown in the Process-to-Data Entity matrix (not shown here), in which the cells would be coded as “C” for the associated process that creates or captures data for the associated data entity, “R” for retrieve (or used), “U” for update, and “D” for delete. This means that different matrices can have different relationships depending on what is being represented. Because of this flexibility and ease of representing information, analysts use a broad range of matrices to gain a clear understanding of an organization’s current situation and to plan for its future (Kerr, 1990; Venkatraman, 2017). A primer on using matrices for ISP is provided in Figure 4-14.

2. Describing the target situation, trends, and constraints. After describing the current situation, the next step in the ISP process is to define the target situation that reflects the desired future state of the organization. This means that the tar- get situation consists of the desired state of the locations, units, functions, pro- cesses, data, and IS (see Figure 4-9). For example, if a desired future state of the organization is to have several new branch offices or a new product line that requires several new employee positions, functions, processes, and data, then most lists and matrices will need to be updated to reflect this vision. The target situation must be developed in light of technology and business trends, in addi- tion to organizational constraints. This means that lists of business trends and constraints should also be constructed in order to help ensure that the target situation reflects these issues.

In summary, to create the target situation, planners must first edit their initial lists and record the desired locations, units, functions, processes, data, and information systems within the constraints and trends of the organization environment (e.g., time, resources, technological evolution, competition, and so on). Next, matrices are updated to relate information in a manner consistent with the desired future state. Planners then focus on the differences between the current and future lists and matrices to identify projects and transition strategies.

M04B_VALA1629_09_GE_C04.indd 123 08/04/2020 16:37

124 PART II PLANNING

FIGURE 4-14 Making sense out of planning matrices

During the information systems planning process, before individual projects are identified and selected, a great deal of “behind the scenes” analysis takes place. During this planning period, which can span from six months to a year, IS planning team members develop and analyze numerous matrices like those described in the associated text. Matrices are developed to represent the current and the future views of the organization. Matrices of the “current” situation are called “as is” matrices. In other words, they describe the world “as” it currently “is.” Matrices of the target or “future” situation are called “to be” matrices. Contrasting the current and future views provides insights into the relationships existing in important business information, and most important, forms the basis for the identification and selection of specific development projects. Many CASE tools provide features that will help you make sense out of these matrices in at least three ways:

Management of Information. A big part of working with complex matrices is managing the information. Using the dictionary features of the CASE tool repository, terms (such as business functions and process and data entities) can be defined or modified in a single location. All planners will therefore have the most recent information. Matrix Construction. The reporting system within the CASE repository allows matrix reports to be easily produced. Because planning information can be changed at any time by many team members, an easy method to record changes and produce the most up-to-date reports is invaluable to the planning process. Matrix Analysis. Possibly the most important feature CASE tools provide to planners is the ability to perform complex analyses within and across matrices. This analysis is often referred to as a nity clustering. A�nity refers to the extent to which information holds things in common. Thus, a�nity clustering is the process of arranging matrix information so that clusters of information with some predetermined level or type of a�nity are placed next to each other on a matrix report. For example, an a�nity clustering of a Process-to-Data Entity matrix would create roughly a block diagonal matrix with processes that use similar data entities appearing in adjacent rows and data entities used in common by the same processes grouped into adjacent columns. This general form of analysis can be used by planners to identify items that often appear together (or should!). Such information can be used by planners to most e�ectively group and relate information (e.g., data to processes, functions to locations, and so on). For example, those data entities used by a common set of processes are candidates for a specific database. And those business processes that relate to a strategically important objective will likely receive more attention when managers from those areas request system changes.

3. Developing a transition strategy and plans. Once the creation of the current and target situations is complete, a detailed transition strategy and plan are developed by the IS planning team. This plan should be very comprehensive, reflecting broad, long-range issues in addition to providing sufficient detail to guide all levels of management concerning what needs to be done, how, when, and by whom in the organization. The components of a typical information systems plan are out- lined in Figure 4-15.

The IS plan is typically a very comprehensive document that looks at both short- and long-term organizational development needs. The short- and long-term developmental needs identified in the plan are typically expressed as a series of proj- ects (see Figure 4-16). Projects from the long-term plan tend to build a foundation for later projects (such as transforming databases from old technology into newer technology). Projects from the short-term plan consist of specific steps to fill the gap between current and desired systems or respond to dynamic business conditions. The top-down (or plan-driven) projects join a set of bottom-up or needs-driven projects submitted as system service requests from managers to form the short-term systems development plan. Collectively, the short- and long-term projects set clear

Affinity clustering The process of arranging planning matrix information so that clusters of information with a predetermined level or type of affinity are placed next to each other on a matrix report.

M04B_VALA1629_09_GE_C04.indd 124 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 125

directions for the project selection process. The short-term plan includes not only those projects identified from the planning process but also those selected from among bottom-up requests. The overall IS plan may also influence all develop- ment projects. For example, the IS mission and IS constraints may cause projects to choose certain technologies or emphasize certain application features as systems are designed.

In this section, we outlined a general process for developing an IS plan. ISP is a detailed process and an integral part of deciding how to best deploy information systems and technologies to help reach organizational goals. It is beyond the scope of this chapter, however, to extensively discuss ISP, yet it should be clear from our dis- cussion that planning-based project identification and selection will yield substantial benefits to an organization. It is probably also clear to you that, as a systems analyst, you are not usually involved in IS planning because this process requires senior IS and corporate management participation. On the other hand, the results of IS planning, such as planning matrices like that in Figure 4-13, can be a source of very valuable information as you identify and justify projects.

FIGURE 4-15 Outline of an information systems plan

II.

III.

IV.

VI.

VII.

Organizational Mission, Objectives, and Strategy Briefly describes the mission, objectives, and strategy of the organization. The current and future views of the company are also briefly presented (i.e., where we are, where we want to be). Informational Inventory This section provides a summary of the various business processes, functions, data entities, and information needs of the enterprise. This inventory will view both current and future needs. Mission and Objectives of IS Description of the primary role IS will play in the organization to transform the enterprise from its current to future state. While it may later be revised, it represents the current best estimate of the overall role for IS within the organization. This role may be as a necessary cost, an investment, or a strategic advantage, for example. Constraints on IS Development Briefly describes limitations imposed by technology and current level of resources within the company—financial, technological, and personnel. Overall Systems Needs and Long-Range IS Strategies Presents a summary of the overall systems needed within the company and the set of long-range (2–5 years) strategies chosen by the IS department to fill the needs. The Short-Term Plan Shows a detailed inventory of present projects and systems and a detailed plan of projects to be developed or advanced during the current year. These projects may be the result of the long-range IS strategies or of requests from managers that have already been approved and are in some stage of the life cycle. Conclusions Contains likely but not-yet-certain events that may a�ect the plan, an inventory of business change elements as presently known, and a description of their estimated impact on the plan.

FIGURE 4-16 Systems development projects flow from the information systems plan

Information Systems Plan: Organizational Mission Informational Inventory Mission and Objectives of IS Constraints Long-Range IS Strategies Short-Term Plan Conclusions

Project 5 Project 4

Project 3 Project 2

Project 1 I. II. III. IV. V. VI. VII.

M04B_VALA1629_09_GE_C04.indd 125 08/04/2020 16:37

126 PART II PLANNING

ELECTRONIC COMMERCE APPLICATIONS: IDENTIFYING AND SELECTING SYSTEMS DEVELOPMENT PROJECTS Identifying and selecting systems development projects for an Internet-based elec- tronic commerce application is no different from the process followed for more traditional applications. Nonetheless, there are some special considerations when developing an Internet-based application. In this section, we highlight some of those issues that relate directly to the process of identifying and selecting Internet-related systems development projects.

Internet Basics

The name Internet is derived from the concept of “internetworking”; that is, con- necting host computers and their networks to form an even larger, global network. And that is essentially what the Internet is—a large, worldwide network of networks that use a common protocol to communicate with each other. The Internet stands as the most prominent representation of global networking. The interconnected net- works include large and small computers, tablets, and smartphones. Additionally, the emergence of the Internet-of-Things (IoT), which refers to a broad class of physical objects that feature an Internet address and connectivity that communicate between these objects and other Internet-enabled devices and systems, is a rapidly emerging area. IoT devices include things like wearables (e.g., fitness trackers), connected cars (e.g., Tesla), industrial devices (e.g., machine monitoring), smart cities (e.g., real-time parking space finder app, traffic lights) and smart home devices (e.g., Amazon Echo). Using the Internet to support day-to-day government, business, and consumer activi- ties is broadly referred to as electronic commerce (EC). There are a broad range of EC business models, including:

• Business-to-Business (B2B) • Business-to-Consumer (B2C) • Consumer-to-Consumer (C2C) • Consumer-to-Business (C2B) • Business-to-Government (B2G) • Government-to-Business (G2B) • Government-to-Citizen (G2C) • Thing-to-Thing (T2T)

For example, when a business sells its products (i.e., as a supplier) to another business, it demonstrates a B2B business model; when a business sells a product to a final customer it demonstrates a B2C business model. The government is also playing an increasingly larger role in various EC business models. Lastly, with the addition of IoT all the traditional suppliers and consumers of physical products and information are benefiting from the Internet age, which is often called the Internet of “Everything” (see Figure 4-17).

When developing any type of EC application, developers need to consider vari- ous factors to create a system with high usability. For example, will the user typically be on a desktop, notebook, tablet or smartphone? Will the connectivity supporting the application be using Wi-Fi or a cellular (smartphone) network? One of the first steps when developing an Internet-EC application is to gain a clear understanding of various unknowns that developers have to discern in order to build a useful system. Table 4-5 lists a sample of such unknowns. These unknowns may result in making trade-offs based on a careful analysis of who the users are likely to be, where they are likely to be located, the devices they are using, and how they are likely to be connected

Internet A large, worldwide network of networks that use a common protocol to communicate with each other.

Internet-of-Things (IoT) A broad class of physical objects that feature an Internet address and connectivity that communicate between these objects and other Internet- enabled devices and systems.

Electronic commerce (EC) Internet-based communication to support day-to-day government, business, and consumer activities.

M04B_VALA1629_09_GE_C04.indd 126 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 127

to the Internet. Even with all these difficulties to contend with, there is no shortage of Internet EC applications springing up all across the world. One company that has decided to get onto the Web with its own EC site is PVF.

Pine Valley Furniture WebStore

The board of directors of PVF has requested that a project team be created to explore the opportunity to develop an EC system. Specifically, market research has found that there is a good opportunity for online furniture purchases, especially in the following areas:

• Corporate furniture • Home office furniture • Student furniture

The board wants to incorporate all three target markets into its long-term EC plan, but wants to initially focus on the corporate furniture buying system. Board mem- bers feel that this segment has the greatest potential to provide an adequate return on investment and would be a good building block for moving into the customer-based markets. Because the corporate furniture buying system will be specifically targeted to the business furniture market, it will be easier to define the system’s operational requirements. Additionally, this EC system should integrate nicely with two currently existing systems: Purchasing Fulfillment and Customer Tracking. Together, these attri- butes make it an ideal candidate for initiating PVF’s Web strategy. Throughout the remainder of the book, we will follow the evolution of the WebStore project until it becomes operational for PVF.

FIGURE 4-17 The Internet of everything.Government

ConsumersBusiness

Internet of Things

User • Concern: Who is the user? • Example: Where is the user located? What is the user’s expertise or

education? What are the user’s expectations? Connection Speed • Concern: What is the speed of the connection and what information

can be effectively transported? • Example: Wi-Fi, cellular

Access Method • Concern: What is the connection device? ? • Example: Web browser, tablet, smartphone, smart watch

TABLE 4-5 Unknowns That Must Be Dealt with When Designing and Building Internet Applications

PINE VALLEY FURNITURE

M04B_VALA1629_09_GE_C04.indd 127 08/04/2020 16:37

128 PART II PLANNING

KEY TERMS

4.1 Affinity clustering 4.2 Bottom-up planning 4.3 Competitive strategy 4.4 Corporate strategic planning 4.5 Electronic commerce (EC)

4.6 Incremental commitment 4.7 Information systems

planning (ISP) 4.8 Internet 4.9 Internet-of-Things (IoT)

4.10 Mission statement 4.11 Objective statements 4.12 Top-down planning 4.13 Value chain analysis

Match each of the key terms above with the definition that best fits it.

SUMMARY In this chapter, we described the first major activity of the planning phase of the SDLC—project identification and selection. Project identification and selection consists of three primary activities: identifying potential develop- ment projects, classifying and ranking projects, and select- ing projects for development. A variety of organizational members or units can be assigned to perform this process, including top management, a diverse steering committee, business units and functional managers, the development group, or the most senior IS executive. Potential projects can be evaluated and selected using a broad range of cri- teria such as value chain analysis, alignment with busi- ness strategy, potential benefits, resource availability and requirements, and risks.

The quality of the project identification and selection process can be improved if decisions are guided by corpo- rate strategic planning and ISP. Corporate strategic plan- ning is the process of identifying the mission, objectives, and strategies of an organization. Crucial in this process is selecting a competitive strategy that states how the organi- zation plans to achieve its objectives.

ISP is an orderly means for assessing the informa- tion needs of an organization and defining the systems and databases that will best satisfy those needs. ISP is a top-down process that takes into account outside forces that drive the business and the factors critical to the suc- cess of the firm. ISP evaluates the current inventory of systems and the desired future state of the organization and its system and then determines which projects are

needed to transform systems to meet the future needs of the organization.

Corporate and IS planning are highly interrelated. Conceptually, these relationships can be viewed via various matrices that show how organizational objectives, locations, units, functions, processes, data entities, and systems relate to one another. Selected projects will be those viewed to be most important in supporting the organizational strategy.

The Internet is a global network consisting of thou- sands of interconnected individual networks that communi- cate with each other using a common protocol. Electronic commerce (EC) refers to the use of the Internet to support day-to-day governmental, business, and consumer activities. Business-to-consumer EC refers to transactions between individual consumers and businesses. In this rapidly grow- ing and evolving area, there are many other business models that include business-to-business EC, government- to-business EC, and thing-to-thing EC to name a few.

The focus of this chapter was to provide you with a clearer understanding of how organizations identify and select projects. Improved project identification and selec- tion is needed for the following reasons: the cost of infor- mation systems is rising rapidly, systems cannot handle applications that cross organizational boundaries, systems often do not address critical organizational objectives, data redundancy is often out of control, and system main- tenance costs continue to rise. Thus, effective project iden- tification and selection is essential if organizations are to realize the greatest benefits from information systems.

____ An orderly means of assessing the information needs of an organization and defining the systems, databases, and tech- nologies that will best satisfy those needs.

____ A generic ISP methodology that identifies and defines IS development projects based upon solving operational business problems or taking advantage of some business opportunities.

____ A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of the project is rejustified.

____ A generic ISP methodology that attempts to gain a broad understanding of the information system needs of the entire organization.

____ A series of statements that express an organization’s qualitative and quantitative goals for reaching a desired future position.

____ A broad class of physical objects that feature an Inter- net address and connectivity that communicate between these objects and other Internet-enabled devices and systems.

____ The method by which an organization attempts to achieve its mission and objectives.

____ The process of arranging planning matrix information so the clusters of information with a predetermined level or type of affinity are placed next to each other on a matrix report.

____ A large, worldwide network of networks that use a common protocol to communicate with each other.

M04B_VALA1629_09_GE_C04.indd 128 08/04/2020 16:37

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 129

REVIEW QUESTIONS 4.14 Define the following terms:

a. Functional decomposition b. Incremental commitment c. Corporate strategic planning d. Information systems planning

4.15 Describe the project identification and selection process.

4.16 Describe several project evaluation criteria.

4.17 Describe what is meant by the planning-based approach, and how organizations benefit from this approach.

4.18 Discuss different decision outcomes that can emerge from the project selection decision process.

4.19 Describe the steps involved in corporate strategic planning.

4.20 What are the main components of a typical information systems plan?

4.21 Describe what is meant by ISP and the steps involved in the process.

4.22 What are the advantages and disadvantages of the bottom-up planning approach?

4.23 Briefly describe nine planning matrices that are used in ISP and project identification and selection.

4.24 Describe the type of information that must be collected to represent current information system situations.

PROBLEMS AND EXERCISES 4.25 Name three business organizations that attempt to achieve

their missions and objectives through the product differen- tiation competitive strategy.

4.26 With regard to your response to the previous question, describe the key product criterion that is being used by each business organization.

4.27 Why do you think value chain analysis is considered an important project evaluation method for assessing informa- tion systems development projects? To execute value chain analysis properly, what should be done first? What are the implications of not doing so?

4.28 Select an organization that has a well-defined mission state- ment. Construct objective statements for that organization, and make sure that the statements express either quantita- tive or qualitative goals that can be achieved over time.

4.29 Describe the different factors needed for improved informa- tion system project identification and selection.

4.30 Why do you think that parallel activities between corporate strategic planning and information systems planning should be established?

4.31 Suppose you are considering alternative designs for a given system in order to make a project decision. There are four alternative designs that could be pursued (A, B, C, and D). The total scores for requirements and con- straints for each alternative are total score for requirements: A = 220, B = 150, C = 200, and D = 220, and total score for constraints: A = 200, B = 150, C = 230, and D = 150.

Using weighted multicriteria analysis, which alternative is the best? Explain your answer and show your work.

4.32 Timberline Technology manufactures membrane circuits in its Northern California plant. In addition, all circuit design and research and development work occur at this site. All finance, accounting, and human resource functions are headquartered at the parent company in the upper Midwest. Sales take place through six sales representatives located in various cities across the country. Information systems for payroll processing, accounts payable, and accounts receiv- able are located at the parent office while systems for inven- tory management and computer-integrated manufacturing are at the California plant. As best you can, list the locations, units, functions, processes, data entities, and information systems for this company.

4.33 For each of the following categories, create the most plausi- ble planning matrices for Timberline Technology, described in Problem and Exercise 4.32: Function-to-Data Entity, Process-to-Data Entity, Process-to-Information System, Data Entity-to-Information System. What other information sys- tems not listed is Timberline likely to need?

4.34 The owners of Timberline Technology (described in Prob- lem and Exercise 4.32) are considering adding a plant in Montana and one in Arizona and six more sales representa- tives at various sites across the country. Update the matri- ces from Problem and Exercise 4.33 so that the matrices account for these changes.

____ Internet-based communication to support day-to-day govern- ment, business, and consumer activities.

____ Analyzing an organization’s activities to determine where value is added to products and/or services and the costs incurred for doing so.

____ An ongoing process that defines the mission, objectives, and strategies of an organization.

____ A statement that makes it clear what business a company is in.

M04B_VALA1629_09_GE_C04.indd 129 08/04/2020 16:37

130 PART II PLANNING

Amrollahi, A., Ghapanchi, A. H., & Talaei-Khoei, A. (2014). Three decades of research on strategic information system plan development. Communications of the Association for Information Systems, 34(84). Retrieved March 22, 2018 from http://aisel. aisnet.org/cais/vol34/iss1/84.

Atkinson, R. A. (1990). The motivations for strategic planning. Journal of Information Systems Management, 7(4), 53–56.

Bass, L., Weber, I., & Zhu, L. (2015). Dev ops: A software architect’s perspective. New York: Addison-Wesley Professional.

Burd, S. D. (2015). Systems Architecture (7th Ed.). Boston, MA: Course Technology.

Carlson, C. K., Gardner, E. P. & Ruth, S. R. (1989). Technology- driven long-range planning. Journal of Information Systems Management. 6(3), 24–29.

Cassidy, A. (2005). A practical guide to information systems strategic planning. London: CRC Press.

Culbreth, D.N. (2017). Dynamic value chains: Visualizing and opti- mizing your business. Business Visualization and Optimization. Denver, CO.

Dewan, S., Michael, S. C., & Min, C. K. (1998). Firm characteristics and investments in information technology: Scale and scope effects. Information Systems Research, 9(3), 219–232.

Dyche, J. (2015). The new IT: How technology leaders are enabling business strategy in the digital age. NY: McGraw Hill.

Foss, N.J., & T. Saebi (eds). 2015. Business Model Innovation: The Organizational Dimension. Oxford, UK: Oxford University Press.

Fuller, M. A., Valacich, J. S., George, J. F., & Schneider, C. (2018). Information systems project management. Burlington, VT: Pros- pect Press.

GAO. (2000). Information technology investment management: A framework for assessing and improving process maturity. U.S. Government Accountability Office. Retrieved March 22, 2018 from http://www.gao.gov/special.pubs/ai10123.pdf.

Harvard Business Review. (2011). Aligning technology with strategy. Boston, MA: Harvard Business Review Press.

IBM. (1982). Business systems planning. In J. D. Couger, M. A. Colter, and R. W. Knapp (eds.), Advanced system development/ Feasibility techniques (pp. 236–314). New York: Wiley.

Kerr, J. (1990). The power of information systems planning. Data- base Programming & Design, 3(12), 60–66.

Luftman, J. N. (2011). Managing the Information Technology Resource. 3rd Edition. Amazon Digital Services.

McKeen, J. D., Guimaraes, T., & Wetherbe, J. C. (1994). “A Com- parative Analysis of MIS Project Selection Mechanisms.” Data Base 25(2): 43–59.

Newbold, D. L., & Azua, M. C. (2007). A model for CIO-led inno- vation. IBM Systems Journal, 46(4), 629–37.

Overby, S. (2008). How to Get Real About Strategic Planning. CIO Magazine. Retrieved June 24, 2018 from https://www. cio.com/article/2437070/leadership-management/how-to- get-real-about-strategic-planning.html.

REFERENCES

FIELD EXERCISES 4.35 Take a look at your institute’s mission statement and objec-

tives. You can go to its Website and download the latest stra- tegic plan document. Alternatively, stop by your institute’s office for planning and budgeting and get a copy of the latest strategic planning document. After all these years, do you think the institute has accomplished all its goals? What strategy type they did use to accomplish their objectives?

4.36 Go to a restaurant and obtain a copy of their strategic plan- ning document. Their strategic planning could be part of the restaurant chain’s overall planning. Describe their com- petitive strategies in detail. Do they have a good competitive analysis? How do they construct their competitive strategies? From what you have learned from Table 4-3 in this chapter, do you agree with their approach? Explain why.

4.37 Choose an organization that you have contact with, perhaps your employer or university. Follow the “Outline of an infor- mation systems plan” shown in Figure 4-15 and complete a short information systems plan for the organization you chose. Write at least a brief paragraph for each of the seven categories in the outline. If IS personnel and managers are available, interview them to obtain information you need. Present your mock plan to the organization’s IS manager and ask for feedback on whether or not your plan fits the IS reality for that organization.

4.38 Interview a senior executive in a business organization. The chosen business organization could be quite big or relatively small. Do they follow the process of identifying and selecting an IS development project as described in this textbook? Discuss how potential development projects are identified. How are these classified and ranked?

4.39 Write separate mission statements that you believe would describe Microsoft, Apple, and Facebook. Compare your mission statements with the real mission statements of these companies. Their mission statements can typically be found in their annual reports. Were your mission statements com- parable to the real mission statements? Why or why not? What differences and similarities are there among these three mission statements? What information systems are necessary to help these companies deliver on their mission statements?

4.40 Choose a business organization you are familiar with, per- haps one that you have had training in or have worked at before. Assess their information systems planning. Do they follow the three-step process described in the textbook? List some of their projects that flow from their information sys- tems plan. Identify which projects align well with it.

M04B_VALA1629_09_GE_C04.indd 130 08/04/2020 16:37

http://aisel.aisnet.org/cais/vol34/iss1/84

http://www.gao.gov/special.pubs/ai10123.pdf

https://www.cio.com/article/2437070/leadership-management/how-to-get-real-about-strategic-planning.html

http://aisel.aisnet.org/cais/vol34/iss1/84

https://www.cio.com/article/2437070/leadership-management/how-to-get-real-about-strategic-planning.html

CHAPTER 4 IDentIfyIng anD SelectIng SyStemS DeveloPment ProjectS 131

Parker, M. M., & R. J. Benson. (1989). Enterprisewide information management: State-of-the-art strategic planning. Journal of Information Systems Management, 6 (Summer), 14–23.

Porter, M. (1980). Competitive strategy: Techniques for analyzing industries and competitors. New York: Free Press.

Porter, M. (1985). Competitive advantage. New York: Free Press. Sanders, N. R. (2017). Supply chain management. Hoboken, NJ:

Wiley. Segars, A. H., & Grover, V. (1999). Profiles of strategic informa-

tion systems planning. Information Systems Planning, 10(3), 199–232.

Slater, D. (2002). Mistakes: Strategic Planning Don’ts (and Do’s). CIO Magazine. Retrieved June 24, 2018. https://www.cio. com/article/2440785/project-management/mistakes– strategic-planning-don-ts--and-dos-.html.

Thomas, G., & Fernandez, W. (2008). Success in IT projects: A matter of definition? International Journal of Project Manage- ment, 26(7), 733–42.

Van den Berg, G., & Pietersma, P. (2015). 25 need-to-know management models. Upper Saddle River, NJ: FT Press.

Venkatraman, V. (2017). The digital matrix: New rules for business transformation through technology. Vancouver, Canada: Life Tree Media.

Weill, P., & Ross, J. W. (2009). IT savvy: What top executives must know to go from pain to gain. Boston, MA: Harvard Business Review Press.

Westerman, G., Bonnet, D., & McAfee, A. (2014). Leading digital: Turning technology into business transformation. Boston, MA: Harvard Business Review Press.

Windpassinger, N. (2017). Internet of things: Digitize or die: Trans- form your organization. Embrace the digital revolution. Rise above the competition. Amazon Digital Services.

M04B_VALA1629_09_GE_C04.indd 131 08/04/2020 16:37

https://www.cio.com/article/2440785/project-management/mistakes%E2%80%93strategic-planning-don-ts-and-dos-.html

132 PART II PLANNING

PETRIE ELECTRONICS

plan the annual stockholders’ meeting. “Better not let the steering committee meeting run too long,” he thought. “I’ve got more important things to do today.”

Next to arrive was John Smith, the head of marketing. John, who was also a member of the steering committee, had been with Petrie for most of his career. He had been with the company longer than anyone else on the steering committee.

Just then, Jim Watanabe came speeding into the confer- ence room. He almost ran into John Smith as he sailed into the room. It looked like he was about to drop his tablet and spill his coffee on Smith. Choi chuckled again.

“Welcome, everyone,” Choi said. “I think we are all here. You all have copies of the agenda for this morning’s meet- ing. Let’s get started.”

“Sorry to interrupt, JK,” Ella said. “Bob Petroski is not here yet. He will be presenting the proposal on the cus- tomer loyalty system project. I don’t know where he is. Maybe he got held up in traffic.”

“The customer loyalty system discussion is the last item we will discuss today, so we can go ahead with the rest of the agenda. Bob does not need to be here for anything except that discussion,” Choi explained.

Choi looked around the table once more. “OK, then, let’s get started. Let’s try to keep to the agenda as much as possible. And let’s watch the clock. I know we are all busy, but I have a very important meeting this afternoon. Julie, see if you can locate Bob.”

Case Questions

4.41 What is an IS steering committee? What are its ma- jor functions? Typically, who serves on such a com- mittee? Why do these committees exist?

4.42 Where do ideas for new information systems origi- nate in organizations?

4.43 What criteria are typically used to determine which new information systems projects to develop? What arguments might Bob Petroski make for developing the proposed customer loyalty system?

4.44 Look at Figure 4-4. What kind of information would you need to put together a table like Figure 4-4 to present to the steering committee? How much of that information is objective? Subjective? Justify your answer.

Chapter 4: Identifying and Selecting Systems Development Projects

J. K. Choi, chief financial officer for Petrie Electronics, came early to the quarterly IS Steering Committee meet- ing. Choi, who was the chair of the committee, took his seat at the head of the big table in the corporate confer- ence room. He opened the cover on his tablet PC and looked at the agenda for the day’s meeting. There were only a few proposed systems projects to consider today. He was familiar with the details of most of them. He briefly looked over the paperwork for each request. He didn’t really think there was anything too controversial to be con- sidered today. Most of the requests were pretty routine and involved upgrades to existing systems. The one totally new system being proposed for development was a customer loyalty system, referred to internally as “No Customer Escapes.”

Choi chuckled at the name as he read through the pro- posal documents. “This is something we have needed for some time,” he thought.

After about 15 minutes, his administrative assistant, Julie, came in. “Am I late or are you early?” she asked.

“No, you’re not late,” Choi said. “I wanted to come in a little early and look over the proposals. I wasn’t able to spend as much time on these yesterday as I wanted.”

As Julie was about to respond, the other members of the committee started to arrive. First was Ella Whinston, the chief operating officer. Choi knew that Ella was the champion for the customer loyalty project. She had talked about it for years now, it seemed to Choi. One of her peo- ple would make the presentation in support of the system. Choi knew she had buy-in on the project from most of the other members of the c-suite. He also knew that Joe Swanson, Petrie director of IT, supported the project. Joe was away, but his assistant director, Jim Watanabe, would attend the meeting in his place. Ella had already let it be known that she expected Jim to be the project man- ager for the customer loyalty system project. Jim had just joined the company, but he had five years of experience at Broadway Entertainment Company before its spectacu- lar collapse. “Good thing I unloaded all that BEC stock I owned before the company went under,” Choi thought. That reminded him of the meeting he had later today to

M04B_VALA1629_09_GE_C04.indd 132 08/04/2020 16:37

During the first phase of the systems development life cycle (SDLC) planning, two primary activities are per- formed. The first, project identification and selection, focuses on the activities during which the need for a new or enhanced system is recognized. This activity does not deal with a specific project but rather identifies the port- folio of projects to be undertaken by the organization. Thus, project identification and selection is often thought of as a “preproject” step in the life cycle. This recogni- tion of potential projects may come as part of a larger planning process, information systems planning, or from requests from managers and business units. Regardless of how a project is identified and selected, the next step is to conduct a more detailed assessment during project initiating and planning. This assessment does not focus on how the proposed system will operate but rather on understanding the scope of a proposed project and its feasibility of completion given the available resources. It is crucial that organizations understand whether resources should be devoted to a project; otherwise, very expen- sive mistakes can be made (Fuller, Valacich, George, & Schneider, 2018; Laplante, 2006; Nash, 2008). Thus, the focus of this chapter is on this process. Project initiation and planning is where projects are accepted for develop- ment, rejected, or redirected. This is also where you, as a systems analyst, begin to play a major role in the systems development process.

In the next section, the project initiation and plan- ning process is briefly reviewed. Numerous techniques for assessing project feasibility are then described. We then

discuss the process of building the Baseline Project Plan, which organizes the information uncovered during feasi- bility analysis. Once this plan is developed, a formal review of the project can be conducted. Yet, before the project can evolve to the next phase of the systems development life cycle—analysis—the project plan must be reviewed and accepted. In the final major section of the chapter, we pro- vide an overview of the project review process.

INITIATING AND PLANNING SYSTEMS DEVELOPMENT PROJECTS A key consideration when conducting project initiation and planning (PIP) is deciding when PIP ends and when analysis, the next phase of the SDLC, begins. This is a con- cern because many activities performed during PIP could also be completed during analysis. Pressman (2014) speaks of three important questions that must be considered when making this decision on the division between PIP and analysis:

1. How much effort should be expended on the project initiation and planning process?

2. Who is responsible for performing the project initia- tion and planning process?

3. Why is project initiation and planning such a challeng- ing activity?

Finding an answer to the first question, how much effort should be expended on the PIP process, is often dif- ficult. Practical experience has found, however, that the

5.3 describe the activities needed to build and review the baseline project plan; and

5.4 describe the activities and participant roles within a structured walk-through.

Learning Objectives After studying this chapter, you should be able to

5.1 describe the steps involved in the project initiation and planning process;

5.2 list and describe various methods for assessing project feasibility;

Initiating and Planning Systems Development Projects5

Introduction

133

M05_VALA1629_09_GE_C05.indd 133 08/04/2020 16:38

134 PART II PLANNING

time and effort spent on initiation and planning activities easily pay for themselves later in the project. Proper and insightful project planning, including determining project scope as well as identifying project activities, can easily reduce time in later project phases. For example, a careful feasibility analysis that leads to deciding that a project is not worth pursuing can save a considerable expenditure of resources. The actual amount of time expended will be affected by the size and complexity of the project as well as by the experience of your organization in building similar systems. A rule of thumb is that between 10 and 20 percent of the entire development effort should be expended on the PIP study. Thus, you should not be reluctant to spend considerable time in PIP in order to fully understand the motivation for the requested system.

For the second question, who is responsible for performing PIP, most organiza- tions assign an experienced systems analyst, or a team of analysts for large projects, to perform PIP. The analyst will work with the proposed customers (managers and users) of the system and other technical development staff in preparing the final plan. Experienced analysts working with customers who fully understand their information services needs should be able to perform PIP without the detailed analysis typical of the analysis phase of the life cycle. Less experienced analysts with customers who only vaguely understand their needs will likely expend more effort during PIP in order to be certain that the project scope and work plan are feasible.

As to the third question, PIP is viewed as a challenging activity because the objec- tive of the PIP study is to transform a vague system request document into a tangible project description. This is an open-ended process. The analyst must clearly under- stand the motivation for and objectives of the proposed system. Therefore, effective communication among the systems analyst, users, and management is crucial to the creation of a meaningful project plan. Getting all parties to agree on the direction of a project may be difficult for cross-department projects where different parties have different business objectives. Thus, more complex organizational settings for projects will result in more time required for analysis of the current and proposed systems during PIP.

In the remainder of this chapter, we will describe the necessary activities used to answer these questions. In the next section, we will revisit the project initiation and planning activities originally outlined in Chapter 3 in the section on “Managing the Information Systems Project.” This is followed by a brief description of the deliverables and outcomes from this process.

THE PROCESS OF INITIATING AND PLANNING IS DEVELOPMENT PROJECTS As its name implies, two major activities occur during project initiation and planning (Figure 5-1). Because the steps of the project initiation and planning process were explained in Chapter 3, our primary focus in this chapter is to describe several tech- niques that are used when performing this process. Therefore, we will only briefly review the PIP process.

Project initiation focuses on activities designed to assist in organizing a team to conduct project planning. During initiation, one or more analysts are assigned to work with a customer—that is, a member of the business group that requested or will be affected by the project—to establish work standards and communication procedures. Examples of the types of activities performed are shown in Table 5-1. Depending upon the size, scope, and complexity of the project, some project initiation activities may be unnecessary or may be very involved. Also, many organizations have established procedures for assisting with common initiation activities. One key activity of project initiation is the development of the project charter (defined in Chapter 3).

Project planning, the second activity within PIP, is distinct from general informa- tion systems planning, which focuses on assessing the information systems needs of

M05_VALA1629_09_GE_C05.indd 134 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 135

the entire organization (discussed in Chapter 4). Project planning is the process of defining clear, discrete activities and the work needed to complete each activity within a single project. The objective of the project planning process is the devel- opment of a Baseline Project Plan (BPP) and the Project Scope Statement (PSS) (Morris & Sember, 2008). The BPP becomes the foundation for the remainder of the development project. The PSS produced by the team clearly outlines the objectives and constraints of the project for the customer. As with the project initiation process, the size, scope, and complexity of a project will dictate the comprehensiveness of the project planning process and resulting documents. Further, numerous assumptions about resource availability and potential problems will have to be made. Analysis of these assumptions and system costs and benefits forms a business case. The range of activities performed during project planning is listed in Table 5-2.

Deliverables and Outcomes

The major outcomes and deliverables from the project initiation and planning phase are the Baseline Project Plan and the Project Scope Statement. The Baseline Project Plan (BPP) contains all information collected and analyzed during project initiation and planning. The plan reflects the best estimate of the project’s scope, benefits, costs, risks, and resource requirements given the current understanding of the project. The

Business case The justification for an information sys- tem, presented in terms of the tangible and intangible economic benefits and costs and the technical and organiza- tional feasibility of the proposed system.

Baseline Project Plan (BPP) A major outcome and deliverable from the project initiation and planning phase that contains the best estimate of a proj- ect’s scope, benefits, costs, risks, and resource requirements.

FIGURE 5-1 Systems development life cycle with project initiation and planning highlighted

DesignImplementation

Maintenance Analysis

Project Identification and Selection Project Initiation and Planning

Planning

• Establishing the Project Initiation Team • Establishing a Relationship with the Customer • Establishing the Project Initiation Plan • Establishing Management Procedures • Establishing the Project Management Environment and Project Workbook • Developing the Project Charter

TABLE 5-1 Elements of Project Initiation

M05_VALA1629_09_GE_C05.indd 135 08/04/2020 16:38

136 PART II PLANNING

BPP specifies detailed project activities for the next life-cycle phase—analysis—and less detail for subsequent project phases (because these depend on the results of the analysis phase). Similarly, benefits, costs, risks, and resource requirements will become more specific and quantifiable as the project progresses. The BPP is used by the project selection committee to help decide whether the project should be accepted, redirected, or canceled. If selected, the BPP becomes the foundation document for all subsequent SDLC activities; however, it is also expected to evolve as the project evolves. That is, as new information is learned during subsequent SDLC phases, the baseline plan will be updated. Later in this chapter we describe how to construct the BPP.

The Project Scope Statement (PSS) is a short document prepared for the cus- tomer that describes what the project will deliver and outlines all work required to complete the project. The PSS ensures that both you and your customer gain a com- mon understanding of the project. It is also a very useful communication tool. The PSS is a very easy document to create because it typically consists of a high-level sum- mary of the BPP information (described later). Depending upon your relationship with your customer, the role of the PSS may vary. At one extreme, the PSS can be used as the basis of a formal contractual agreement outlining firm deadlines, costs, and specifications. At the other extreme, the PSS can simply be used as a communication vehicle to outline the current best estimates of what the project will deliver, when it will be completed, and the resources it may consume. A contract programming or consulting firm, for example, may establish a very formal relationship with a customer and use a PSS that is extensive and formal. Alternatively, an internal development group may develop a PSS that is only one to two pages in length and is intended to inform customers rather than to set contractual obligations and deadlines.

ASSESSING PROJECT FEASIBILITY All projects are feasible given unlimited resources and infinite time (Pressman, 2014). Unfortunately, most projects must be developed within tight budgetary and time con- straints. This means that assessing project feasibility is a required activity for all infor- mation systems projects and is a potentially large undertaking. It requires that you, as a systems analyst, evaluate a wide range of factors. Typically, the relative importance of these factors will vary from project to project. Although the specifics of a given project will dictate which factors are most important, most feasibility factors are represented by the following categories:

• Economic • Technical • Operational • Scheduling • Legal and contractual • Political

Project Scope Statement (PSS) A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project.

• Describing the Project Scope, Alternatives, and Feasibility • Dividing the Project into Manageable Tasks • Estimating Resources and Creating a Resource Plan • Developing a Preliminary Schedule • Developing a Communication Plan • Determining Project Standards and Procedures • Identifying and Assessing Risk • Creating a Preliminary Budget • Developing the Project Scope Statement • Setting a Baseline Project Plan

TABLE 5-2 Elements of Project Planning

M05_VALA1629_09_GE_C05.indd 136 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 137

Together, the culmination of these feasibility analyses forms the business case that justifies the expenditure of resources on the project. In the remainder of this section, we will examine various feasibility issues. We begin by looking at issues related to economic feasibility and then demonstrate techniques for conducting this analy- sis. This is followed by a discussion of techniques for assessing technical project risk. Finally, issues not directly associated with economic and technical feasibility, but no less important to ensuring project success, are discussed.

To help you better understand the feasibility assessment process, we will examine a project at Pine Valley Furniture (PVF). For this project, a System Service Request (SSR) was submitted by PVF’s Vice President of Marketing Jackie Judson to develop a Customer Tracking System (CTS) (Figure 5-2). Jackie feels that this system would allow PVF’s marketing group to better track customer purchase activ- ity and sales trends. She also feels that, if constructed, the CTS would provide many tangible and intangible benefits to PVF. This project was selected by PVF’s Systems Priority Board for a project initiation and planning study. During project initiation, Senior Systems Analyst Jim Woo was assigned to work with Jackie to initiate and plan the project. At this point in the project, all project initiation activities have been completed. Jackie and Jim are now focusing on project planning activities in order to complete the BPP.

Assessing Economic Feasibility

The purpose of assessing economic feasibility is to identify the financial benefits and costs associated with the development project (Laplante, 2006; Shim & Henteleff, 1994). Economic feasibility is often referred to as cost–benefit analysis. During project initiation and planning, it will be impossible for you to precisely define all benefits and costs related to a particular project. Yet it is important that you spend adequate time identifying and quantifying these items or it will be impossible for you to conduct an adequate economic analysis and make meaningful comparisons between rival proj- ects. Here we will describe typical benefits and costs resulting from the development of an information system and provide several useful worksheets for recording costs and benefits. Additionally, several common techniques for making cost–benefit cal- culations are presented. These worksheets and techniques are used after each SDLC phase as the project is reviewed in order to decide whether to continue, redirect, or kill a project.

Determining Project Benefits An information system can provide many bene- fits to an organization. For example, a new or renovated information system can automate monotonous jobs and reduce errors; provide innovative services to customers and suppliers; and improve organizational efficiency, speed, flexibility, and morale. In general, the benefits can be viewed as being both tangible and intangible. Tangible benefits refer to items that can be measured in dollars and with certainty. Examples of tangible benefits might include reduced personnel expenses, lower transaction costs, or higher profit margins. It is important to note that not all tangi- ble benefits can be easily quantified. For example, a tangible benefit that allows a company to perform a task in 50 percent of the time may be difficult to quantify in terms of hard dollar savings. Most tangible benefits will fit within the following categories:

• Cost reduction and avoidance • Error reduction • Increased flexibility • Increased speed of activity • Improvement of management planning and control • Opening new markets and increasing sales opportunities

Economic feasibility A process of identifying the financial benefits and costs associated with a development project.

Tangible benefit A benefit derived from the creation of an information system that can be measured in dollars and with certainty.

PINE VALLEY FURNITURE

M05_VALA1629_09_GE_C05.indd 137 08/04/2020 16:38

138 PART II PLANNING

FIGURE 5-2 System Service Request for Customer Tracking System (Pine Valley Furniture)

Sales growth at PVF has caused a greater volume of work for the marketing department. This volume of work has greatly increased the volume and complexity of the data we need to deal with and understand. We are currently using manual methods and a complex PC-based electronic spreadsheet to track and forecast customer buying patterns. This method of analysis has many problems: (1) we are slow to catch buying trends as there is often a week or more delay before data can be taken from the point-of-sales system and manually enter it into our spreadsheet; (2) the process of manual data entry is prone to errors (which makes the results of our subsequent analysis suspect); and (3) the volume of data and the complexity of analyses conducted in the system seem to be overwhelming our current system—sometimes the program starts recalculating and never returns, while for others it returns information that we know cannot be correct.

SERVICE REQUEST

I request a thorough analysis of our current method of tracking and analysis of customer purchasing activity with the intent to design and build a completely new information system. This system should handle all customer purchasing activity, support display and reporting of critical sales information, and assist marketing personnel in understanding the increasingly complex and competitive business environment. I feel that such a system will improve the competitiveness of PVF, particularly in our ability to better serve our customers.

IS LIAISON

SPONSOR

Pine Valley Furniture System Service Request

REQUESTED BY

DEPARTMENT

LOCATION

CONTACT

TYPE OF REQUEST

PROBLEM STATEMENT

URGENCY

DATE:Jackie Judson

Marketing

Headquarters, 570c

Tel: 4-3290 FAX: 4-3270 E-Mail: jjudson

August 20, 2020

[ [ [

] ] ]

[ [ [

] ] ]

New System System Enhancement System Error Correction

Immediate: Operations are impaired or opportunity lost Problems exist, but can be worked around Business losses can be tolerated until new system installed

Jim Woo, 4-6207 FAX: 4-6200 E-Mail: jwoo

Jackie Judson, Vice President, Marketing

TO BE COMPLETED BY SYSTEMS PRIORITY BOARD [

[ [ [

]

] ] ]

Request approved

Recommend revision Suggest user development Reject for reason

Assigned to Start date

M05_VALA1629_09_GE_C05.indd 138 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 139

Within the CTS at PVF, Jim and Jackie identified several tangible benefits, which are summarized on the tangible benefits worksheet shown in Figure 5-3. Jackie and Jim had to establish the values in Figure 5-3 after collecting information from users of the current customer tracking system. They first interviewed the person respon- sible for collecting, entering, and analyzing the accuracy of the current customer tracking data. This person estimated that 25 percent of her time was spent correcting data entry errors. Given that this person’s salary is $100,000, Jackie and Jim estimated an error-reduction benefit of $25,000. Jackie and Jim also interviewed managers who used the current customer tracking reports. Using this information they were able to estimate other tangible benefits. They learned that cost-reduction or avoidance benefits could be gained due to better inventory management. Also, increased flex- ibility would likely occur from a reduction in the time normally taken to manually reorganize data for different purposes. Further, improvements in management plan- ning or control should result from a broader range of analyses in the new system. Overall, this analysis forecasts that benefits from the system would be approximately $500,000 per year.

Jim and Jackie also identified several intangible benefits of the system. Although these benefits could not be quantified, they will still be described in the final BPP. Intangible benefits refer to items that cannot be easily measured in dollars or with certainty. Intangible benefits may have direct organizational benefits, such as the improvement of employee morale, or they may have broader societal implications, such as the reduction of waste creation or resource consumption. Potential tangible benefits may have to be considered intangible during project initiation and planning because you may not be able to quantify them in dollars or with certainty at this stage in the life cycle. During later stages, such intangibles can become tangible benefits as you better understand the ramifications of the system you are designing. In this case, the BPP is updated and the business case revised to justify continuation of the project to the next phase. Table 5-3 lists numerous intangible benefits often associated with the development of an information system. Actual benefits will vary from system to system. After determining project benefits, project costs must be identified.

Determining Project Costs Similar to benefits, an information system can have both tangible and intangible costs. Tangible costs refer to items that you can easily measure in dollars and with certainty. From an IS development perspective, tangible costs include items such as hardware costs, labor costs, and operational costs including employee training and building renovations. Alternatively, intangible costs are items that you cannot easily measure in terms of dollars or with certainty. Intangible costs

Intangible benefit A benefit derived from the creation of an information system that cannot be easily measured in dollars or with certainty.

FIGURE 5-3 Tangible benefits for Customer Tracking System (Pine Valley Furniture)TANGIBLE BENEFITS WORKSHEET

Customer TrackingSystem Project

Year 1 through 5

A. Cost reduction or avoidance $ 45,000

B. Error reduction 25,000

C. Increased flexibility 75,000

D. Increased speed of activity 105,000

E. Improvement in management planning or control 250,000

F. Other

TOTAL tangible benefits

$500,000

Tangible cost A cost associated with an information system that can be measured in dollars and with certainty.

Intangible cost A cost associated with an information system that cannot be easily measured in terms of dollars or with certainty.

M05_VALA1629_09_GE_C05.indd 139 08/04/2020 16:38

140 PART II PLANNING

can include loss of customer goodwill, employee morale, or operational inefficiency. Table 5-4 provides a summary of common costs associated with the development and operation of an information system. Predicting the costs associated with the develop- ment of an information system is an inexact science. IS researchers, however, have identified several guidelines for improving the cost-estimating process (see Table 5-5). Both underestimating and overestimating costs are problems you must avoid (Laplante, 2006; Lederer & Prasad, 1992; Nash, 2008; White & Lui, 2005). Underes- timation results in cost overruns, whereas overestimation results in unnecessary alloca- tion of resources that might be better utilized.

• Competitive necessity • More timely information • Improved organizational planning • Increased organizational flexibility • Promotion of organizational learning and

understanding • Availability of new, better, or more

information • Ability to investigate more alternatives • Faster decision making

• More confidence in decision quality • Improved processing efficiency • Improved asset utilization • Improved resource control • Increased accuracy in clerical operations • Improved work process that can improve

employee morale or customer satisfaction • Positive impacts on society • Improved social responsibility • Better usage of resources (“greener”)

TABLE 5-3 Intangible Benefits from the Development of an Information System

(Source: Based on Parker & Benson, 1988; Brynjolfsson & Yang, 1997; Keen, 2003; Cresswell, 2004.)

Type of Cost Examples Type of Cost Examples

Procurement Hardware, software, facilities infrastructure

Management and staff Consulting and services

Project Infrastructure replacement/ improvements

Project personnel Training Development activities Services and procurement Organizational disruptions Management and staff

Start-Up Initial operating costs Management and staff Personnel recruiting

Operating Infrastructure replacement/ improvements

System maintenance Management and staff User training and support

TABLE 5-4 Possible Information Systems Costs

(Source: Based on King & Schrems, 1978; Sonje, 2008.)

1. Have clear guidelines for creating estimates. 2. Use experienced developers and/or project managers for making estimates. 3. Develop a culture where all project participants are responsible for defining accurate

estimates. 4. Use historical data to help in establishing better estimates of costs, risks, schedules, and

resources. 5. Update estimates as the project progresses. 6. Monitor progress and record discrepancies to improve future estimates.

TABLE 5-5 Guidelines for Better Cost Estimating

(Source: Based on Lederer & Prasad, 1992; Hubbard, 2007; Sonje, 2008.)

M05_VALA1629_09_GE_C05.indd 140 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 141

One goal of a cost–benefit analysis is to accurately determine the total cost of ownership (TCO) for an investment (Nash, 2008). TCO is focused on understanding not only the total cost of acquisition but also all costs associated with ongoing use and maintenance of a system. Consequently, besides tangible and intangible costs, you can distinguish IS-related development costs as either one-time or recurring (the same is true for benefits, although we do not discuss this difference for benefits). One-time costs refer to those associated with project initiation and development and the start-up of the system. These costs typically encompass activities such as systems development, new hardware and software purchases, user training, site preparation, and data or system conversion. When conducting an economic cost–benefit analysis, a worksheet should be created for capturing these expenses. For very large projects, one-time costs may be staged over one or more years. In these cases, a separate one-time cost worksheet should be created for each year. This separation will make it easier to per- form present value calculations (described later). Recurring costs refer to those costs resulting from the ongoing evolution and use of the system. Examples of these costs typically include the following:

• Application software maintenance • Incremental data storage expenses • Incremental communications • New software and hardware leases • Supplies and other expenses (e.g., paper, forms, data center personnel)

Both one-time and recurring costs can consist of items that are fixed or variable in nature. Fixed costs are costs that are billed or incurred at a regular interval and usually at a fixed rate (a facility lease payment). Variable costs are items that vary in relation to usage (long-distance phone charges).

During the process of determining project costs, Jim and Jackie identified both one-time and recurring costs for the project. These costs are summarized in Figures 5-4 and 5-5. These figures show that this project will incur a one-time cost of $425,000 and a recurring cost of $285,000 per year. One-time costs were established by discussing the system with Jim’s boss, who felt that the system would require approxi- mately four months to develop (at $100,000 per month). To effectively run the new system, the marketing department would need to upgrade at least five of its current workstations (at $3,000 each). Additionally, software licenses for each workstation (at $1,000 each) and modest user training fees (ten users at $500 each) would be necessary.

total cost of ownership (TCO) The cost of owning and operating a sys- tem, including the total cost of acquisi- tion, as well as all costs associated with its ongoing use and maintenance.

One-time cost A cost associated with project start-up and development or system start-up.

Recurring cost A cost resulting from the ongoing evolu- tion and use of a system.

FIGURE 5-4 One-time costs for Customer Tracking System (Pine Valley Furniture)

ONE-TIME COSTS WORKSHEET Customer Tracking System Project

Year 0

A. Development costs $400,000

B. New hardware 15,000

C. New (purchased) software, if any 1. Packaged applications software 5,000 2. Other 0

D. User training 5,000

E. Site preparation 0

F. Other 0

TOTAL one-time costs $425,000

M05_VALA1629_09_GE_C05.indd 141 08/04/2020 16:38

142 PART II PLANNING

As you can see from Figure 5-5, Jim and Jackie believe the proposed system will be highly dynamic and will require, on average, five months of annual maintenance, primarily for enhancements as users expect more from the system. Other ongoing expenses such as increased data storage, communications equipment, and supplies should also be expected. You should now have an understanding of the types of ben- efit and cost categories associated with an information systems project. It should be clear that there are many potential benefits and costs associated with a given project. Additionally, because the development and useful life of a system may span several years, these benefits and costs must be normalized into present-day values in order to perform meaningful cost–benefit comparisons. In the next section, we address the relationship between time and money.

The Time Value of Money Most techniques used to determine economic feasi- bility encompass the concept of the time value of money (TVM), which reflects the notion that money available today is worth more than the same amount tomorrow. As previously discussed, the development of an information system has both one- time and recurring costs. Furthermore, benefits from systems development will likely occur sometime in the future. Because many projects may be competing for the same investment dollars and may have different useful life expectancies, all costs and ben- efits must be viewed in relation to their present value when comparing investment options.

A simple example will help in understanding the TVM. Suppose you want to buy a used car from an acquaintance and she asks that you make three payments of $1,500 for three years, beginning next year, for a total of $4,500. If she would agree to a single lump-sum payment at the time of sale (and if you had the money!), what amount do you think she would agree to? Should the single payment be $4,500? Should it be more or less? To answer this question, we must consider the time value of money. Most of us would gladly accept $4,500 today rather than three payments of $1,500, because a dollar today (or $4,500 for that matter) is worth more than a dollar tomorrow or next year, given that money can be invested. The rate at which money can be bor- rowed or invested is referred to as the cost of capital, and is called the discount rate for TVM calculations. Let’s suppose that the seller could put the money received for the sale of the car in the bank and receive a 10 percent return on her investment. A simple formula can be used when figuring out the present value of the three $1,500 payments:

PVn = Y * 1

(1 i)n

Time value of money (TVM) The concept that money available today is worth more than the same amount tomorrow.

Discount rate The rate of return used to compute the present value of future cash flows.

Present value The current value of a future cash flow.

FIGURE 5-5 Recurring costs for Customer Tracking System (Pine Valley Furniture) RECURRING COSTS WORKSHEET

Customer Tracking System Project

Year 1 through 5

$280,000

1,000

2,000 0

2,000

$285,000

A. Application software maintenance

B. Incremental data storage required: 20 GB $50 (estimated cost/GB = $50)

C. Incremental communications (lines, messages, . . .)

D. New software or hardware leases

E. Supplies

F. Other

TOTAL recurring costs

M05_VALA1629_09_GE_C05.indd 142 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 143

where PVn is the present value of Y dollars n years from now when i is the discount rate.

From our example, the present value of the three payments of $1,500 can be calculated as

PV1 = 1500 * 1

(1 .10)1 = 1500 * .9091 = 1363.65

PV2 = 1500 * 1

(1 .10)2 = 1500 * .8264 = 1239.60

PV3 = 1500 * 1

(1 .10)3 = 1500 * .7513 = 1126.95

where PV1, PV2, and PV3 reflect the present value of each $1,500 payment in years 1, 2, and 3, respectively.

To calculate the net present value (NPV) of the three $1,500 payments, simply add the present values calculated previously (NPV = PV1 = PV2 = PV3 = 1363.65 = 1239.60 = 1126.95 = $3,730.20). In other words, the seller could accept a lump- sum payment of $3,730.20 as equivalent to the three payments of $1,500, given a discount rate of 10 percent.

Given that we now know the relationship between time and money, the next step in performing the economic analysis is to create a summary worksheet reflecting the pres- ent values of all benefits and costs as well as all pertinent analyses. Due to the fast pace of the business world, PVF’s System Priority Board feels that the useful life of many informa- tion systems may not exceed five years. Therefore, all cost–benefit analysis calculations will be made using a five-year time horizon as the upper boundary on all time-related analyses. In addition, the management of PVF has set its cost of capital to be 12 percent (i.e., PVF’s discount rate). The worksheet constructed by Jim is shown in Figure 5-6.

FIGURE 5-6 Summary spreadsheet reflecting the present value calculations of all benefits and costs for the Customer Tracking System (Pine Valley Furniture)

(Source: Microsoft Corporation.)

M05_VALA1629_09_GE_C05.indd 143 08/04/2020 16:38

144 PART II PLANNING

Cell H11 of the worksheet displayed in Figure 5-6 summarizes the NPV of the total tangible benefits from the project. Cell H19 summarizes the NPV of the total costs from the project. The NPV for the project ($35,003) shows that, overall, benefits from the project exceed costs (see cell H22).

The overall return on investment (ROI) for the project is also shown on the worksheet in cell H25. Because alternative projects will likely have different benefit and cost values and, possibly, different life expectancies, the overall ROI value is very useful for making project comparisons on an economic basis. Of course, this example shows ROI for the overall project; an ROI analysis could be calculated for each year of the project.

The last analysis shown in Figure 5-6 is a break-even analysis. The objective of the break-even analysis is to discover at what point (if ever) benefits equal costs (i.e., when breakeven occurs). To conduct this analysis, the NPV of the yearly cash flows are determined. Here, the yearly cash flows are calculated by subtracting both the one-time cost and the present values of the recurring costs from the present value of the yearly benefits. The overall NPV of the cash flow reflects the total cash flows for all preceding years. Examination of line 30 of the worksheet shows that breakeven occurs between years 2 and 3. Because year 3 is the first in which the overall NPV cash flow figure is nonnegative, the identification of what point during the year breakeven occurs can be derived as follows:

Break@Even Ratio = Yearly NPV Cash Flow @ Overall NPV Cash Flow

Yearly NPV Cash Flow

Using data from Figure 5-6,

Break@Even Ratio = 15,3039139

15,303 = .403

Therefore, project breakeven occurs at approximately 2.4 years. A graphical representation of this analysis is shown in Figure 5-7. Using the information from the economic analysis, PVF’s Systems Priority Board will be in a much better position to understand the potential economic impact of the CTS. It should be clear from this analysis that, without such information, it would be virtually impossible to know the cost–benefits of a proposed system and impossible to make an informed decision regarding approval or rejection of the service request.

You can use many techniques to compute a project’s economic feasibility. Because most information systems have a useful life of more than one year and will provide

Break-even analysis A type of cost–benefit analysis to iden- tify at what point (if ever) benefits equal costs.

FIGURE 5-7 Break-even analysis for Customer Tracking System (Pine Valley Furniture)

2,000

1,500

1,000

500

Year

Project break-even point

0 1 2 3 4 5

Benefits

Costs

D o

lla rs

(i n t

h o

u sa

n d

M05_VALA1629_09_GE_C05.indd 144 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 145

benefits and incur expenses for more than one year, most techniques for analyzing economic feasibility employ the concept of the TVM. Some of these cost– benefit analysis techniques are quite simple, whereas others are more sophisticated. Table 5-6 describes three commonly used techniques for conducting economic feasibility analy- sis. For a more detailed discussion of TVM or cost–benefit analysis techniques in general, the interested reader is encouraged to review an introductory finance or managerial accounting textbook.

A systems project, to be approved for continuation, may not have to achieve breakeven or have an ROI above some organizational threshold, as estimated dur- ing project initiation and planning. Because you may not be able to quantify many benefits or costs at this point in a project, such financial hurdles for a project may be unattainable. In this case, simply doing as thorough an economic analysis as possible, including producing a long list of intangibles, may be sufficient for the project to progress. One other option is to run the type of economic analysis shown in Figure 5-7 using pessimistic, optimistic, and expected benefit and cost estimates during project initiation and planning. This range of possible outcomes, along with the list of intan- gible benefits and the support of the requesting business unit, will often be enough to allow the project to continue to the analysis phase. You must, however, be as precise as you can with the economic analysis, especially when investment capital is scarce. In this case, it may be necessary to conduct some typical analysis phase activities during project initiation and planning in order to clearly identify inefficiencies and shortcom- ings with the existing system and to explain how a new system will overcome these problems. Thus, building the economic case for a systems project is an open-ended activity; how much analysis is needed depends on the particular project, stakeholders, and business conditions. Also, conducting economic feasibility analyses for new types of information systems is often very difficult.

Assessing Technical Feasibility

The purpose of assessing technical feasibility is to gain an understanding of the orga- nization’s ability to construct the proposed system. This analysis should include an assessment of the development group’s understanding of the possible target hardware, software, and operating environments to be used, as well as system size, complexity, and the group’s experience with similar systems. In this section, we will discuss a framework you can use for assessing the technical feasibility of a project in which a level of project risk can be determined after answering a few fundamental questions.

It is important to note that all projects have risk and that risk is not necessarily something to avoid. Yet it is also true that, because organizations typically expect a greater return on their investment for riskier projects, understanding the sources and types of technical risks proves to be a valuable tool when you assess a project. Also, risks need to be managed in order to be minimized; you should, therefore, identify

Technical feasibility A process of assessing the development organization’s ability to construct a pro- posed system.

Analysis Technique Description

Net Present Value (NPV) NPV uses a discount rate determined from the company’s cost of capital to establish the present value of a project. The discount rate is used to determine the present value of both cash receipts and outlays.

Return on Investment (ROI) ROI is the ratio of the net cash receipts of the project divided by the cash outlays of the project. Trade-off analysis can be made among projects competing for investment by comparing their representative ROI ratios.

Break-Even Analysis (BEA) BEA finds the amount of time required for the cumulative cash flow from a project to equal its initial and ongoing investment.

TABLE 5-6 Commonly Used Economic Cost–Benefit Analysis Techniques

M05_VALA1629_09_GE_C05.indd 145 08/04/2020 16:38

146 PART II PLANNING

potential risks as early as possible in a project. The potential consequences of not assessing and managing risks can include the following:

• Failure to attain expected benefits from the project • Inaccurate project cost estimates • Inaccurate project duration estimates • Failure to achieve adequate system performance levels • Failure to adequately integrate the new system with existing hardware, software,

or organizational procedures

You can manage risk on a project by changing the project plan to avoid risky fac- tors, assigning project team members to carefully manage the risky aspects, and set- ting up monitoring methods to determine whether or not potential risk is, in fact, materializing.

The amount of technical risk associated with a given project is contingent on four primary factors: project size, project structure, the development group’s experi- ence with the application and technology area, and the user group’s experience with systems development projects and the application area (see also Kirsch, 2000). Aspects of each of these risk areas are summarized in Table 5-7. When using these factors for conducting a technical risk assessment, four general rules emerge:

1. Large projects are riskier than small projects. Project size, of course, relates to the relative project size with which the development group typically works. A “small” project for one development group may be relatively “large” for another. The types of factors that influence project size are listed in Table 5-7.

2. A system in which the requirements are easily obtained and highly structured will be less risky than one in which requirements are messy, ill-structured, ill-defined, or subject to the judgment of an individual. For example, the development of a payroll system has requirements that may be easy to obtain due to legal reporting requirements and standard accounting procedures. On the other hand, the development of an executive support system would need to be customized to the particular execu- tive decision style and critical success factors of the organization, thus making its development more risky (see Table 5-7).

Risk Factor Examples

Project Size Number of members on the project team Project duration time Number of organizational departments involved in project Size of programming effort (e.g., hours, function points) Number of outsourcing partners

Project Structure New system or renovation of existing system(s) Organizational, procedural, structural, or personnel changes

resulting from system User perceptions and willingness to participate in effort Management commitment to system Amount of user information in system development effort

Development Group Familiarity with target hardware, software development environ- ment, tools, and operating system

Familiarity with proposed application area Familiarity with building similar systems of similar size

User Group Familiarity with information systems development process Familiarity with proposed application area Familiarity with using similar systems

TABLE 5-7 Project Risk Assessment Factors

(Source: Based on Applegate, Austin, & Soule, 2009; Fuller et al., 2018.)

M05_VALA1629_09_GE_C05.indd 146 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 147

3. The development of a system employing commonly used or standard technology will be less risky than one employing novel or nonstandard technology. A project has a greater like- lihood of experiencing unforeseen technical problems when the development group lacks knowledge related to an aspect of the technology environment. A less risky approach is to use standard development tools and hardware environments. It is not uncommon for experienced system developers to talk of the difficulty of using leading-edge (or in their words, bleeding-edge) technology (see Table 5-7).

4. A project is less risky when the user group is familiar with the systems development pro- cess and application area than if the user group is unfamiliar with them. Successful IS projects require active involvement and cooperation between the user and devel- opment groups. Users familiar with the application area and the systems develop- ment process are more likely to understand the need for their involvement and how this involvement can influence the success of the project (see Table 5-7).

A project with high risk may still be conducted. Many organizations look at risk as a portfolio issue: Considering all projects, it is okay to have a reasonable percent- age of high-, medium-, and low-risk projects. Given that some high-risk projects will get into trouble, an organization cannot afford to have too many of these. Having too many low-risk projects may not be aggressive enough to make major breakthroughs in innovative uses of systems. Each organization must decide on its acceptable mix of projects of varying risk.

A matrix for assessing the relative risks related to the general rules just described is shown in Figure 5-8. Using the risk factor rules to assess the technical risk level of the CTS, Jim and Jackie concluded the following about their project:

1. The project is a relatively small project for PVF’s development organization. The basic data for the system are readily available, so the creation of the system will not be a large undertaking.

2. The requirements for the project are highly structured and easily obtainable. In fact, an existing spreadsheet-based system is available for analysts to examine and study.

3. The development group is familiar with the technology that will likely be used to construct the system because the system will simply extend current system capabilities.

4. The user group is familiar with the application area because they are already using the PC-based spreadsheet system described in Figure 5-3.

Given this risk assessment, Jim and Jackie mapped their information into the risk framework of Figure 5-8. They concluded that this project should be viewed as hav- ing “very low” technical risk (cell 4 of the figure). Although this method is useful for

FIGURE 5-8 Effects of degree of project structure, project size, and familiarity with applica- tion area on project implementation risk

(Source: Based on Applegate, Austin, & Soule, 2009; Fuller et al., 2018.)

High Familiarity with Technology or Application Area

Low Familiarity with Technology or Application Area

Large Project

Small Project

Large Project

Small Project

Low Structure High Structure (1)

Low risk (very susceptible

to mismanagement) (3)

Very low risk (very susceptible

to mismanagement)

(5) Very high risk

(7) High risk

(2) Low risk

(4) Very low risk

(6) Medium risk

(8) Medium-low risk

PINE VALLEY FURNITURE

M05_VALA1629_09_GE_C05.indd 147 08/04/2020 16:38

148 PART II PLANNING

gaining an understanding of technical feasibility, numerous other issues can influence the success of the project. These nonfinancial and nontechnical issues are described in the following section.

Assessing Other Feasibility Concerns

In this section, we will briefly conclude our discussion of project feasibility issues by reviewing other forms of feasibility that you may need to consider when formulating the business case for a system during project planning.

Assessing Operational Feasibility The first relates to examining the likelihood that the project will attain its desired objectives, called operational feasibility. Its pur- pose is to gain an understanding of the degree to which the proposed system will likely solve the business problems or take advantage of the opportunities outlined in the System Service Request or project identification study. For a project motivated from information systems planning, operational feasibility includes justifying the project on the basis of being consistent with or necessary for accomplishing the information sys- tems plan. In fact, the business case for any project can be enhanced by showing a link to the business or information systems plan. Your assessment of operational feasibility should also include an analysis of how the proposed system will affect organizational structures and procedures. Systems that have substantial and widespread impact on an organization’s structure or procedures are typically riskier projects to undertake. Thus, it is important for you to have a clear understanding of how an information system will fit into the current day-to-day operations of the organization.

Assessing Schedule Feasibility Another feasibility concern relates to project duration and is referred to as assessing schedule feasibility. The purpose of assessing schedule feasibility is for you, as a systems analyst, to gain an understanding of the likelihood that all potential time frames and completion date schedules can be met and that meeting these dates will be sufficient for dealing with the needs of the orga- nization. For example, a system may have to be operational by a government-imposed deadline, by a particular point in the business cycle (such as the beginning of the season when new products are introduced), or at least by the time a competitor is expected to introduce a similar system. Further, detailed activities may only be feasible if resources are available when called for in the schedule. For example, the schedule should not call for system testing during rushed business periods or for key project meetings during annual vacation or holiday periods. The schedule of activities pro- duced during project initiation and planning will be very precise and detailed for the analysis phase. The estimated activities and associated times for activities after the analysis phase are typically not as detailed (e.g., it will take two weeks to program the payroll report module) but are rather at the life-cycle-phase level (e.g., it will take six weeks for physical design, four months for programming, and so on). This means that assessing schedule feasibility during project initiation and planning is more of a “rough-cut” analysis of whether the system can be completed within the constraints of the business opportunity or the desires of the users. While assessing schedule fea- sibility you should also evaluate scheduling trade-offs. For example, factors such as project team size, availability of key personnel, subcontracting or outsourcing activi- ties, and changes in development environments may all be considered as having a possible impact on the eventual schedule. As with all forms of feasibility, schedule feasibility will be reassessed after each phase when you can specify with greater cer- tainty the details of each step for the next phase.

Assessing Legal and Contractual Feasibility A third concern relates to assessing legal and contractual feasibility issues. In this area, you need to gain an understanding of any potential legal ramifications due to the construction of the system. Possible considerations might include copyright or nondisclosure infringements, labor laws,

Operational feasibility The process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities.

Legal and contractual feasibility The process of assessing potential legal and contractual ramifications due to the construction of a system.

Schedule feasibility The process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change.

M05_VALA1629_09_GE_C05.indd 148 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 149

antitrust legislation (which might limit the creation of systems to share data with other organizations), foreign trade regulations (e.g., some countries limit access to employee data by foreign corporations), and financial reporting standards, as well as current or pending contractual obligations. Contractual obligations may involve ownership of software used in joint ventures, license agreements for use of hardware or software, nondisclosure agreements with partners, or elements of a labor agreement (e.g., a union agreement may preclude certain compensation or work-monitoring capabilities a user may want in a system). A common situation is that development of a new appli- cation system for use on new computers may require new or expanded, and more costly, system software licenses. Typically, legal and contractual feasibility is a greater consideration if your organization has historically used an outside organization for specific systems or services that you now are considering handling yourself. In this case, ownership of program source code by another party may make it difficult to extend an existing system or link a new system with an existing purchased system.

Assessing Political Feasibility A final feasibility concern focuses on assessing political feasibility in which you attempt to gain an understanding of how key stake- holders within the organization view the proposed system. Because an information system may affect the distribution of information within the organization, and thus the distribution of power, the construction of an information system can have political ramifications. Those stakeholders not supporting the project may take steps to block, disrupt, or change the intended focus of the project.

In summary, depending upon the given situation, numerous feasibility issues must be considered when planning a project. This analysis should consider economic, technical, operational, schedule, legal, contractual, and political issues related to the project. In addition to these considerations, project selection by an organization may be influenced by issues beyond those discussed here. For example, projects may be selected for construction despite high project costs and high technical risk if the sys- tem is viewed as a strategic necessity; that is, the organization views the project as being critical to the organization’s survival. Alternatively, projects may be selected because they are deemed to require few resources and have little risk. Projects may also be selected due to the power or persuasiveness of the manager proposing the system. This means that project selection may be influenced by factors beyond those discussed here and beyond items that can be analyzed. Understanding the reality that projects may be selected based on factors beyond analysis, your role as a systems analyst is to provide a thorough examination of the items that can be assessed. Your analysis will ensure that a project review committee has as much information as possible when making project approval decisions. In the next section, we discuss how project plans are typically reviewed.

BUILDING AND REVIEWING THE BASELINE PROJECT PLAN All the information collected during project initiation and planning is collected and organized into a document called the Baseline Project Plan. Once the BPP is com- pleted, a formal review of the project can be conducted with project clients and other interested parties. This presentation, a walk-through, is discussed later in this chapter. The focus of this review is to verify all information and assumptions in the baseline plan before moving ahead with the project.

Building the Baseline Project Plan

As mentioned previously, the project size and organizational standards will dictate the comprehensiveness of the project initiation and planning process as well as the BPP. Yet most experienced systems builders have found project planning and a clear project

Political feasibility The process of evaluating how key stakeholders within the organization view the proposed system.

M05_VALA1629_09_GE_C05.indd 149 08/04/2020 16:38

150 PART II PLANNING

plan to be invaluable to project success. An outline of a BPP is provided in Figure 5-9, which shows that it contains four major sections:

1. Introduction 2. System Description 3. Feasibility Assessment 4. Management Issues

The Introduction Section of the Baseline Project Plan The purpose of the Introduction is to provide a brief overview of the entire document and outline a

FIGURE 5-9 Outline of a Baseline Project Plan

1.0

2.0

3.0

4.0

Introduction A.

System Description A. B.

Feasibility Assessment A.

Management Issues A.

BASELINE PROJECT PLAN REPORT

Project Overview—Provides an executive summary that specifies the project’s scope, feasibility, justification, resource requirements, and schedules. Additionally, a brief statement of the problem, the environment in which the system is to be implemented, and constraints that a ect the project are provided. Recommendation—Provides a summary of important findings from the planning process and recommendations for subsequent activities.

Alternatives—Provides a brief presentation of alternative system configurations. System Description—Provides a description of the selected configuration and a narrative of input information, tasks performed, and resultant information.

Economic Analysis—Provides an economic justification for the system using cost-benefit analysis. Technical Analysis—Provides a discussion of relevant technical risk factors and an overall risk rating of the project. Operational Analysis—Provides an analysis of how the proposed system solves business problems or takes advantage of business opportunities in addition to an assessment of how current day-to-day activities will be changed by the system. Legal and Contractual Analysis—Provides a description of any legal or contractual risks related to the project (e.g., copyright or nondisclosure issues, data capture or transferring, and so on). Political Analysis—Provides a description of how key stakeholders within the organization view the proposed system. Schedules, Time Line, and Resource Analysis—Provides a description of potential time frame and completion date scenarios using various resource allocation schemes.

Team Configuration and Management—Provides a description of the team member roles and reporting relationships. Communication Plan—Provides a description of the communication procedures to be followed by management, team members, and the customer. Project Standards and Procedures—Provides a description of how deliverables will be evaluated and accepted by the customer. Other Project-Specific Topics—Provides a description of any other relevant issues related to the project uncovered during planning.

M05_VALA1629_09_GE_C05.indd 150 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 151

recommended course of action for the project. The entire Introduction section is often limited to only a few pages. Although the Introduction section is sequenced as the first section of the BPP, it is often the final section to be written. It is only after performing most of the project planning activities that a clear overview and recom- mendation can be created. One activity that should be performed initially is the defi- nition of project scope.

When defining scope for the CTS within PVF, Jim Woo first needed to gain a clear understanding of the project’s objectives. To do this, Jim briefly interviewed Jackie Judson and several of her colleagues to gain a clear idea of their needs. He also spent a few hours reviewing the existing system’s functionality, processes, and data use requirements for performing customer tracking activities. These activities provided him with the information needed to define the project scope and to identify possible alternative solutions. Alternative system solutions can relate to different system scopes, platforms for deployment, or approaches to acquiring the system. We elaborate on the idea of alternative solutions, called design strategies, when we discuss the analysis phase of the life cycle. During project initiation and planning, the most crucial element of the design strategy is the system’s scope. In sum, a determination of scope will depend on the following factors:

• Which organizational units (business functions and divisions) might be affected by or use the proposed system or system change?

• With which current systems might the proposed system need to interact or be consistent, or which current systems might be changed due to a replacement system?

• Who inside and outside the requesting organization (or the organization as a whole) might care about the proposed system?

• What range of potential system capabilities will be considered?

The Project Scope Statement for the CTS project is shown in Figure 5-10. For the CTS, project scope was defined using only textual information. It is

not uncommon, however, to define project scope using diagrams such as data flow diagrams and entity-relationship models. For example, Figure 5-11 shows a context- level data flow diagram used to define system scope for PVF’s Purchasing Fulfillment System. The other items in the Introduction section of the BPP are simply executive summaries of the other sections of the document.

The System Description Section of the Baseline Project Plan The second section of the BPP is the System Description, which contains an outline of possible alternative solutions in addition to the one deemed most appropriate for the given situation. Note that this description is at a very high level and mostly narrative in form. The following examples demonstrate that alternatives may be stated simply:

1. Web-based online system 2. Mainframe with central database 3. Local area network with decentralized databases 4. Batch data input with online retrieval 5. Purchasing of a prewritten package

If the project is approved for construction or purchase, you will need to collect and structure information in a more detailed and rigorous manner during the analy- sis phase and evaluate in greater depth these and other alternative directions for the system. At this point in the project, your objective is only to identify the most obvious alternative solutions.

When Jim and Jackie were considering system alternatives for the CTS, they focused on two primary issues. First, they discussed how the system would be acquired and considered three options: purchase the system if one could be found that met PVF’s needs, outsource the development of the system to an outside orga- nization, or build the system within PVF. The second issue focused on defining the

PINE VALLEY FURNITURE

M05_VALA1629_09_GE_C05.indd 151 08/04/2020 16:38

152 PART II PLANNING

comprehensiveness of the system’s functionality. To complete this task, Jim asked Jackie to write a series of statements listing the types of tasks that she envisioned mar- keting personnel would be able to accomplish when using the CTS. This list of statements became the basis of the system description and was instrumental in help- ing them make their acquisition decision. After considering the unique needs of the marketing group, both decided that the best decision was to build the system within PVF.

FIGURE 5-10 Project Scope Statement for the Customer Tracking Systems (Pine Valley Furniture)

General Project Information

Problem/Opportunity Statement:

Project Objectives:

Project Description:

Business Benefits:

Project Deliverables:

Estimated Project Duration:

Project Name: Sponsor: Project Manager:

Customer Tracking System Jackie Judson, VP Marketing Jim Woo

Pine Valley Furniture Project Scope Statement

Sales growth has outpaced the Marketing department’s ability to accurately track and forecast customer buying trends. An improved method for performing this process must be found in order to reach company objectives.

To enable the Marketing department to accurately track and forecast customer buying patterns in order to better serve customers with the best mix of products. This will also enable PVF to identify the proper application of production and material resources.

A new information system will be constructed that will collect all customer purchasing activity, support display and reporting of sales information, aggregate data, and show trends in order to assist marketing personnel in understanding dynamic market conditions. The project will follow PVF’s systems development life cycle.

Improved understanding of customer buying patterns Improved utilization of marketing and sales personnel Improved utilization of production and materials

Customer tracking system analysis and design Customer tracking system programs Customer tracking documentation Training procedures

5 months

Prepared by: Jim Woo Date: September 10, 2020

M05_VALA1629_09_GE_C05.indd 152 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 153

The Feasibility Assessment Section of the Baseline Project Plan In the third section, Feasibility Assessment, issues related to project costs and benefits, technical difficulties, and other such concerns are outlined. This is also the section where high- level project schedules are specified using network diagrams and Gantt charts. Recall from Chapter 3 that this process is referred to as a work breakdown structure. During project initiation and planning, task and activity estimates are not generally detailed. An accurate work breakdown can be done only for the next one or two life-cycle activities. After defining the primary tasks for the project, an estimate of the resource requirements can be made. As with defining tasks and activities, this activity is pri- marily concerned with gaining rough estimates of the human resource requirements because people are the most expensive resource element. Once you define the major tasks and resource requirements, a preliminary schedule can be developed. Defining an acceptable schedule may require that you find additional or different resources or that you change the scope of the project. The greatest amount of project planning effort is typically expended on these Feasibility Assessment activities.

The Management Issues Section of the Baseline Project Plan The final sec- tion, Management Issues, outlines a number of managerial concerns related to the proj- ect. This will be a very short section if the proposed project is going to be conducted exactly as prescribed by the organization’s standard systems development methodol- ogy. Most projects, however, have some unique characteristics that require minor to major deviation from the standard methodology. In the Team Configuration and Management portion, you identify the types of people to work on the project, who will be responsible for which tasks, and how work will be supervised and reviewed (Figure 5-12). In the Communications Plan portion, you explain how the user will be kept informed about project progress (such as periodic review meetings or even a newsletter) and what mechanisms will be used to foster sharing of ideas among team members, such as some form of computer-based conference facility (Figure 5-13). An example of the type of information contained in the Project Standards and Pro- cedures portion would be procedures for submitting and approving project change requests and any other issues deemed important for the project’s success.

You should now have a feel for how a BPP is constructed and the types of information it contains. Its creation is not meant to be a project in and of itself, but rather a step in the overall systems development process. Developing the BPP has two primary objectives. First, it helps to ensure that the customer and development group share a common understanding of the project. Second, it helps to provide the sponsor- ing organization with a clear idea of the scope, benefits, and duration of the project.

FIGURE 5-11 Context-level data flow diagram show- ing project scope for Purchasing Fulfill- ment System (Pine Valley Furniture)

Price & Terms Quotes

Shipment

Request for Quotes

Order

Supplier Material Evaluation

Material Specifications

Production Schedules

Production Capacities

Material Availability

Supplier Material Specifications

Purchasing Fulfillment

System

Suppliers

Engineering Production Schedulers

M05_VALA1629_09_GE_C05.indd 153 08/04/2020 16:38

154 PART II PLANNING

Project: WebStore

Prepared by: Juan Gonzales

Legend:

P = Primary

S = SupportManager: Juan Gonzales

Page: 1 of 1

Responsibility Matrix Task ID Task Jordan James Jackie Jeremy Kim Juan

A Collect Requirements P S S

B Develop Data Model P S S

C Develop Program Interface P S S

D Build Database S P S

E Design Test Scenarios S S S P S S

F Run Test Scenarios S S S S S P

G Create User Documentation P S S

H Install System S P S S

I Develop Customer Support S P S S

FIGURE 5-12 Task responsibility matrix

Reviewing the Baseline Project Plan

Before the next phase of the SDLC can begin, the users, management, and develop- ment group must review the BPP in order to verify that it makes sense. This review takes place before the BPP is submitted or presented to a project approval body, such as an IS steering committee or the person who must fund the project. The objective of this review is to ensure that the proposed system conforms to organizational standards and that all relevant parties understand and agree with the information contained in the BPP. A common method for performing this review (as well as reviews during subsequent life-cycle phases) is called a structured walk-through. Walk-throughs are peer group reviews of any product created during the systems development process and are widely used by professional development organizations. Experience has shown that walk-throughs are a very effective way to ensure the quality of an information system and have become a common day-to-day activity for many systems analysts.

Most walk-throughs are not rigidly formal or exceedingly long in duration. It is important, however, to establish a specific agenda for the walk-through so that all attendees understand what is to be covered and the expected completion time. At

Walk-through A peer group review of any product created during the systems develop- ment process; also called a structured walk-through.

Stakeholder Document Format Team Contact Date Due

Team Members Project Status Report Project Intranet Juan and Kim First Monday of Month

Management Supervisor Project Status Report Hard Copy Juan and Kim First Monday of Month

User Group Project Status Report Hard Copy James and Kim First Monday of Month

Internal IT Staff Project Status Report E-Mail Jackie and James First Monday of Month

IT Manager Project Status Report Hard Copy Juan and Jeremy First Monday of Month

Contract Programmers Software Specifications E-Mail/Project Intranet Jordan and Kim October 4, 2020

Training Subcontractor Implementation and Training Plan Hard Copy Jordan and James January 10, 2021

FIGURE 5-13 The Project Communication Matrix provides a high-level summary of the communication plan

M05_VALA1629_09_GE_C05.indd 154 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 155

walk-through meetings, there is a need to have individuals play specific roles. These roles are as follows (Yourdon, 1989):

• Coordinator. This person plans the meeting and facilitates a smooth meeting pro- cess. This person may be the project leader or a lead analyst responsible for the current life cycle step.

• Presenter. This person describes the work product to the group. The presenter is usually an analyst who has done all or some of the work being presented.

• User. This person (or group) makes sure that the work product meets the needs of the project’s customers. This user would usually be someone not on the project team.

• Secretary. This person takes notes and records decisions or recommendations made by the group. This may be a clerk assigned to the project team or it may be one of the analysts on the team.

• Standards bearer. The role of this person is to ensure that the work product adheres to organizational technical standards. Many larger organizations have staff groups within the unit responsible for establishing standard procedures, methods, and documentation formats. These standards bearers validate the work so that it can be used by others in the development organization.

• Maintenance oracle. This person reviews the work product in terms of future maintenance activities. The goal is to make the system and its documentation easy to maintain.

After Jim and Jackie completed their BPP for the CTS, Jim approached his boss and requested that a walk-through meeting be scheduled and that a walk-through coordinator be assigned to the project. PVF assists the coordinator by providing a Walk-Through Review Form, shown in Figure 5-14. Using this form, the coordinator can more easily make sure that a qualified individual is assigned to each walk-through role; that each member has been given a copy of the review materials; and that each member knows the agenda, date, time, and location of the meeting. At the meeting, Jim presented the BPP and Jackie added comments from a user’s perspective. Once the walk-through presentation was completed, the coordinator polled each represen- tative for his or her recommendation concerning the work product. The results of this voting may result in validation of the work product, validation pending changes suggested during the meeting, or a suggestion that the work product requires major revision before being presented for approval. In this latter case, substantial changes to the work product are usually requested, after which another walk-through must be scheduled before the project can be proposed to the Systems Priority Board (steer- ing committee). In the case of the CTS, the BPP was supported by the walk-through panel, pending some minor changes to the duration estimates in the schedule. These suggested changes were recorded by the secretary on a Walk-Through Action List (see Figure 5-15) and given to Jim to incorporate into a final version of the baseline plan to be presented to the steering committee.

As suggested by the previous discussion, walk-through meetings are a common occurrence in most systems development groups and can be used for more activities than reviewing the BPP, including the following:

• System specifications • Logical and physical designs • Code or program segments • Test procedures and results • Manuals and documentation

One of the key advantages in using a structured review process is it ensures that formal review points occur during the project. At each subsequent phase of the project, a formal review should be conducted (and shown on the project schedule) to make sure all aspects of the project are satisfactorily accomplished before assign- ing additional resources to the project. This conservative approach of reviewing each

M05_VALA1629_09_GE_C05.indd 155 08/04/2020 16:38

156 PART II PLANNING

FIGURE 5-14 Walk-Through Review Form (Pine Valley Furniture)

Session Coordinator:

Project/Segment:

Coordinator’s Checklist:

Agenda:

Group Decision:

Confirmation with producer(s) that material is ready and stable: Issue invitations, assign responsibilities, distribute materials: [ ] Y [ ] N Set date, time, and location for meeting:

Date: / /

Location:

[ ] Y [ ] N [ ] Y [ ] N

1. 2. 3.

All participants agree to follow PVF’s Rules of a Walk-Through New material: walk-through of all material Old material: item-by-item checko� of previous action list Creation of new action list (contribution by each participant) Group decision (see below) Deliver copy of this form to the project control manager

Accept product as-is Revise (no further walk-through) Review and schedule another walk-through

1. 2. 3. 4. 5. 6.

Pine Valley Furniture Walk-Through Review Form

Responsibilities

Coordinator

Presenter

User

Secretary

Standards

Maintenance

Participants Can Attend Received Materials

Time: A.M. / P.M. (circle one)

Signatures

M05_VALA1629_09_GE_C05.indd 156 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 157

FIGURE 5-15 Walk-Through Action List (Pine Valley Furniture)

Session Coordinator:

Project/Segment:

Date and Time of Walk-through:

Pine Valley Furniture Walk-Through Action List

Fixed ( ) Issues raised in review:

Date: / / Time: A.M. / P.M. (circle one)

M05_VALA1629_09_GE_C05.indd 157 08/04/2020 16:38

158 PART II PLANNING

major project activity with continuation contingent on successful completion of the prior phase is called incremental commitment. It is much easier to stop or redirect a project at any point when using this approach.

Walk-throughs are used throughout the duration of the project for briefing team members and external stakeholders. These presentations can provide many benefits to the team, but, unfortunately, are often not well done. With the proliferation of computer technology and the availability of powerful software to assist in designing and delivering presentations, making an effective presentation has never been easier. Microsoft’s PowerPoint has emerged as the de facto standard for creating computer- based presentations. Although this program is relatively easy to use, it can also be misused such that the “bells and whistles” added to a computer-based presentation actually detract from the presentation. Like any project, to make an effective presenta- tion it must be well-planned, well-designed, and well-delivered. Planning and design- ing your presentation is equally important as delivering it. If your slides are poorly laid out, hard to read, or inconsistent, it won’t matter how good your delivery is; your audience will think more about the poor quality of the slides than about what you are saying. Fortunately, with a little work it is easy to design a high-quality presentation if you follow a few simple steps, which are outlined in Table 5-8.

Presentation Planning

Who is the audience? To design the most effective presentation, you need to consider the audience (e.g., What do they know about your topic? What is their education level?).

What is the message? Your presentation should be designed with a particular objective in mind. What is the presentation

environment? Knowledge of the room size, shape, and lighting is valuable information for designing an optimal

presentation.

Presentation Design

Organize the sequence. Organize your presentation so that like elements or topics are found in one place, instead of scattered throughout the material in random fashion.

Keep it simple. Make sure that you don’t pack too much information onto a slide so that it is difficult to read. Also, work to have as few slides as possible; in other words, only include information that you absolutely need.

Be consistent. Make sure that you are consistent in the types of fonts, font sizes, colors, design approach, and backgrounds.

Use variety. Use both textual and graphical slides to convey information in the most meaningful format. Don’t rely on the spell

checker alone. Make sure you carefully review your presentation for typographical and wording errors.

Use bells and whistles sparingly.

Make sure that you use familiar graphical icons to guide and enhance slides; don’t lose sight of your message as you add bells and whistles. Also, take great care when making transitions between slides and elements so that “special effects” don’t take away from your message.

Use supplemental materials appropriately.

Take care when using supplemental materials so that they don’t distract the audience. For example, don’t provide handouts until you want the audience to actually read this material.

Have a clear beginning and end.

At the beginning, introduce yourself and your teammates (if any), thank your audience for being there, and provide a clear outline of what will be covered during the presentation. At the conclusion, have a concluding slide so that the audience clearly sees that the presentation is over.

Presentation Delivery

Practice. Make sure that you thoroughly test your completed work on yourself and others to be sure it covers your points and presents them in an effective manner within the time frame required.

Arrive early and cue up your presentation.

It is good practice, when feasible, to have your presentation ready to go prior to the arrival of the audience.

Learn to use the “special” software keys.

Using special keys to navigate the presentation will allow you to focus on your message and not on the software.

Have a backup plan. Have a backup plan in case technology fails or your presentation is lost when traveling. Deliver the information

effectively. To make an effective presentation, you must become an effective public speaker through practice.

Personal appearance matters.

Your appearance and demeanor can go a long way toward enhancing how the audience receives your presentation.

TABLE 5-8 Guidelines for Making an Effective Presentation

M05_VALA1629_09_GE_C05.indd 158 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 159

ELECTRONIC COMMERCE APPLICATIONS: INITIATING AND PLANNING SYSTEMS DEVELOPMENT PROJECTS Initiating and planning systems development projects for an Internet-based EC appli- cation is very similar to the process followed for more traditional applications. In Chapter 4, you read how PVF’s management began the WebStore project—to sell furniture products over the Internet. In this section, we highlight some of the issues that relate directly to the process of identifying and selecting systems development projects.

Initiating and Planning Systems Development Projects for Pine Valley Furniture’s WebStore

Given the high priority of the WebStore project, Vice President of Marketing Jackie Judson, and senior systems analyst, Jim Woo, were assigned to work on this project. Like the CTS described earlier in this chapter, their initial activity was to begin the project’s initiation and planning activities.

Initiating and Planning PVF’s E-Commerce System To start the initiation and planning process, Jim and Jackie held several meetings over several days. At the first meeting they agreed that “WebStore” would be the proposed system project name. Next, they worked on identifying potential benefits, costs, and feasibility concerns. To assist in this process, Jim developed a list of potential costs from developing Web- based systems that he shared with Jackie and the other project team members (see Table 5-9).

WebStore Project Walk-Through After meeting with the project team, Jim and Jackie established an initial list of benefits and costs (see Table 5-10) as well as several feasibility concerns (see Table 5-11). Next, Jim worked with several of PVF’s technical specialists to develop an initial project schedule. Figure 5-16 shows the Gantt chart for this 84-day schedule. Finally, Jim and Jackie presented their initial project plans in a walk-through to PVF’s board of directors and senior management. All were excited about the project plan, and approval was given to move the WebStore project into the analysis phase.

Cost Category Examples

Design ❑❑ Number of pages / content ❑❑ Style of design / graphics design ❑❑ System comprehensiveness / functionality ❑❑ Copyrighting of pages ❑❑ Responsive design (mobile devices)

Development ❑❑ Programming ❑❑ Database integration ❑❑ Hosting ❑❑ Technical site manager ❑❑ Content / support staff

Marketing ❑❑ Search Engine Optimization ❑❑ Launch and ongoing public relations ❑❑ Search engine advertising / paid links from other Websites ❑❑ Promotions ❑❑ Marketing / advertising staff

TABLE 5-9 Web-Based System Costs

PINE VALLEY FURNITURE

M05_VALA1629_09_GE_C05.indd 159 08/04/2020 16:38

160 PART II PLANNING

Tangible Benefits Intangible Benefits

❑❑ Lower per-transaction overhead cost ❑❑ Repeat business ❑❑ New customers

❑❑ First to market ❑❑ Foundation for complete Web-based IS ❑❑ Simplicity for customers

Tangible Costs (one-time) Intangible Costs

❑❑ Site and usability design ❑❑ Programming ❑❑ Initial Marketing / Search Engine Optimization ❑❑ Database integration

❑❑ No face-to-face interaction ❑❑ Not all customers use Internet

Tangible Costs (recurring)

❑❑ Hosting fee ❑❑ Site management ❑❑ Annual Marketing / Search Engine Optimization ❑❑ Maintenance ❑❑ Decreased sales via traditional channels

TABLE 5-10 PVF WebStore: Project Benefits and Costs

Feasibility Concern Description

Operational Online store is open 24/7/365 Returns/customer support

Technical New skill set for development, maintenance, and operation Schedule Must be open for business by Q1, 2021 Legal Credit card fraud Political Traditional distribution channel loses business

TABLE 5-11 PVF WebStore: Feasibility Concerns

FIGURE 5-16 Schedule for WebStore project at Pine Valley Furniture

(Source: Microsoft Corporation.)

M05_VALA1629_09_GE_C05.indd 160 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 161

SUMMARY The project initiation and planning (PIP) phase is a critical activity in the life of a project. It is at this point that proj- ects are accepted for development, rejected as infeasible, or redirected. The objective of this process is to transform a vague system request into a tangible system description clearly outlining the objectives, feasibility issues, benefits, costs, and time schedules for the project.

Project initiation includes forming the project ini- tiation team, establishing customer relationships, devel- oping a plan to get the project started, setting project management procedures, and creating an overall proj- ect manage ment environment. A key activity in project planning is the assessment of numerous feasibility issues associated with the project. The types of feasibility that should be examined include economic, technical, opera- tional, schedule, legal and contractual, and political. These issues are influenced by the project size, the type of system proposed, and the collective experience of the development group and potential customers of the sys- tem. High project costs and risks are not necessarily bad; rather it is more important that the organization under- stands the costs and risks associated with a project and with the portfolio of active projects before proceeding.

After completing all analyses, a BPP can be created. A BPP includes a high-level description of the proposed system or system change, an outline of the various feasi- bilities, and an overview of management issues specific to the project. Before the development of an information sys- tem can begin, the users, management, and development group must review and agree on this specification. The focus of this walk-through review is to assess the merits of the project and to ensure that the project, if accepted for development, conforms to organizational standards and goals. An objective of this process is also to make sure that all relevant parties understand and agree with the informa- tion contained in the plan before subsequent development activities begin.

Project initiation and planning is a challenging and time-consuming activity that requires active involvement from many organizational participants. The eventual suc- cess of a development project, and the information systems function in general, hinges on the effective use of disci- plined, rational approaches such as the techniques outlined in this chapter. In subsequent chapters, you will be exposed to numerous other tools that will equip you to become an effective designer and developer of information systems.

KEY TERMS

5.1 Baseline Project Plan (BPP) 5.2 Break-even analysis 5.3 Business case 5.4 Discount rate 5.5 Economic feasibility 5.6 Intangible benefit 5.7 Intangible cost

5.8 Legal and contractual feasibility 5.9 One-time cost 5.10 Operational feasibility 5.11 Political feasibility 5.12 Present value 5.13 Project Scope Statement (PSS) 5.14 Recurring cost

5.15 Schedule feasibility 5.16 Tangible benefit 5.17 Tangible cost 5.18 Technical feasibility 5.19 Time value of money (TVM) 5.20 Total cost of ownership (TCO) 5.21 Walk-through

Match each of the key terms above with the definition that best fits it.

____ The concept that money available today is worth more than the same amount tomorrow.

____ The process of evaluating how key stakeholders within the organization view the proposed system.

____ A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project.

____ The justification for an information system, presented in terms of the tangible and intangible economic benefits and costs, and the technical and organizational feasibility of the proposed system.

____ A process of identifying the financial benefits and costs asso- ciated with a development project.

____ The process of assessing the degree to which a proposed system solves business problems or takes advantage of busi- ness opportunities.

____ A cost resulting from the ongoing evolution and use of a system.

____ The rate of return used to compute the present value of future cash flows.

____ A benefit derived from the creation of an information system that cannot be easily measured in dollars or with certainty.

____ The process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and con- straints for affecting change.

M05_VALA1629_09_GE_C05.indd 161 08/04/2020 16:38

162 PART II PLANNING

____ A cost associated with an information system that can be easily measured in dollars and with certainty.

____ A peer group review of any product created during the sys- tems development process.

____ A process of assessing the development organization’s ability to construct a proposed system.

____ A cost associated with project start-up and development or system start-up.

____ The current value of a future cash flow.

____ A benefit derived from the creation of an information system that can be measured in dollars and with certainty.

____ The process of assessing potential legal and contractual rami- fications due to the construction of a system.

____ A cost associated with an information system that cannot be easily measured in terms of dollars or with certainty.

____ This plan is the major outcome and deliverable from the project initiation and planning phase and contains the best estimate of the project’s scope, benefits, costs, risks, and resource requirements.

____ A type of cost–benefit analysis to identify at what point (if ever) benefits equal costs.

____ The cost of owning and operating a system, including the total cost of acquisition, as well as all costs associated with its ongoing use and maintenance.

REVIEW QUESTIONS 5.22 Contrast the following terms:

a. Break-even analysis; present value; net present value; return on investment

b. Economic feasibility; legal and contractual feasibility; oper- ational feasibility; political feasibility; schedule feasibility

c. Intangible benefit; tangible benefit d. Intangible cost; tangible cost

5.23 List and describe the steps in the project initiation and plan- ning process.

5.24 What two documents make up the main deliverables from the planning phase, and what are they used for?

5.25 What three questions must be answered to judge whether a certain activity belongs to the initiation phase or the analysis phase? Why are these questions important?

5.26 List and discuss the different types of project feasibility factors. Is any factor most important? Why or why not?

5.27 About how much of the total time and money spent on a project should be devoted to the project initiation and plan- ning study?

5.28 What does the term “business case” refer to?

5.29 What is the main point of working with the structured review processes of a development project?

5.30 What is the main use of a break-even analysis, and how is it executed?

5.31 What are the four parts of the BPP, and what are their purposes?

5.32 Describe the structured walk-through process. What roles need to be performed during a walk-through?

PROBLEMS AND EXERCISES 5.33 Consider the purchase of a PC and laser printer for use

at your home and assess the risk for this project using the project risk assessment factors in Table 5-7.

5.34 Create a task responsibility matrix for some work you are involved in (it could be a group assignment for the course you are taking or for activities you are involved in during your free time). Be sure to include the various portions of the matrix as depicted in Figure 5-12. In what way do you think it could help your project (or other work)?

5.35 Assume you are put in charge of launching a new Website for a local nonprofit organization. What costs would you need to account for? Make a list of expected costs and benefits for the project. You don’t need to list values, just sources of expense. Consider both one-time and recurring costs.

5.36 Performing individual interviews and group interviews may result in both tangible and intangible benefits and costs being discovered. Explain how and give some examples.

5.37 Explain the concept of time value of money (TVM). Discuss other reasons why money is worth more today than it will be in a few years’ time.

5.38 Assuming monetary benefits of an information system at $85,000 per year, one-time costs of $75,000, recurring costs of $35,000 per year, a discount rate of 12 percent, and a five- year time horizon, calculate the net present value of these costs and benefits of an information system. Also calculate the overall return on investment of the project and then present a break-even analysis. At what point does breakeven occur?

5.39 Running calculations for return on investment and per- forming break-even analysis are used for more or less the same thing. What are they for, and what are the merits of each of the concepts?

5.40 Change the discount rate for Problem and Exercise 5.34 to 10 percent and redo the analysis.

5.41 Change the recurring costs in Problem and Exercise 5.34 to $40,000 and redo the analysis.

5.42 Change the time horizon in Problem and Exercise 5.34 to three years and redo the analysis.

5.43 Assume monetary benefits of an information system of $40,000 the first year and increasing benefits of $10,000 a year for the next five years (year 1=$50,000, year 2=$60,000,

M05_VALA1629_09_GE_C05.indd 162 08/04/2020 16:38

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 163

REFERENCES Applegate, L. M., Austin, R. D., & Soule, D. L. (2009). Corporate

information strategy and management (8th ed.). New York: McGraw-Hill.

Brynjolfsson, E., & Yang, S. (1997). The intangible benefits and costs of investments: Evidence from financial markets. In Pro- ceedings of the International Conference on Information Systems (pp. 147–66). Retrieved March 22, 2018 from http://aisel.ais- net.org/cgi/viewcontent.cgi?article=1053&context=icis1997.

Cresswell, A. M. (2004). Return on investment in information tech- nology: A guide for managers center for technology in government. University at Albany, SUNY. Retrieved March 22, 2018 from http://www.ctg.albany.edu/publications/guides/roi/roi.pdf.

Fuller, M. A., Valacich, J. S., George, J.F., & Schneider, C. (2018). Information systems project management. Prospect Press: Burl- ington, VT.

year 3=$70,000, year 4=$80,000, year 5=$90,000). One-time development costs were $80,000 and recurring costs were $45,000 over the duration of the system’s life. The discount rate for the company was 11 percent. Using a six-year time horizon, calculate the net present value of these costs and benefits. Also calculate the overall return on investment and then present a break-even analysis. At what point does breakeven occur?

5.44 Change the discount rate for Problem and Exercise 5.42 to 12 percent and redo the analysis.

5.45 Change the recurring costs in Problem and Exercise 5.42 to $40,000 and redo the analysis.

5.46 Look at the money amounts listed in Figures 5-4, 5-5, and especially 5-3. Do you see a pattern here when it comes to doing predictions and budgeting?

5.47 A start-up company approaches you as a systems analyst. They want to have a Website developed to sell fashion

clothing to children. What risks, based on the discussion on feasibility, do you see here?

5.48 In an economy where the stock market reacts heavily to quarterly reports, CEOs need to perform well according to some set metrics. This means that what may look good is not always what is financially best for the company. For example, in the smartphone race of the last two decades, it has been important for companies to outsell their competitors. One of these major companies now wants to invest in a very large customer relationship management system from your con- sultancy firm. What kinds of risks are involved under such circumstances?

5.49 As stated in the chapter, projects may be selected “due to the power or persuasiveness of the manager proposing the sys- tem.” In other words, there are more factors influencing the choice of what systems to implement than just an objective evaluation of economics, technical issues, etc. As a systems analyst, how would you tackle this problem?

FIELD EXERCISES 5.50 Describe several projects you are involved in or plan to under-

take, whether they are related to your education or to your professional or personal life (e.g., purchasing a new vehicle, learning a new language, renovating a home). For each project, sketch out a BPP like that outlined in Figure 5-9. Focus your efforts on item numbers 1.0 (Introduction) and 2.0 (System Description).

5.51 Imagine that a new system is to be developed for handling student grades at your institute. Try to assess the risks involved with this particular project using your acquired knowledge of economic, technical, operational, scheduling, legal and contractual, and political feasibility. Your answer may vary greatly depending on many factors: Should the new system be part of a current system or should it be a stand-alone system? How many students are there at your institute? Who should have access to the system? Who will build it? Who will be part of the development team, and when are they available? Are there any legal issues, perhaps involving storing student data, that must be taken into consideration? In your opin- ion, should the new system be accessed from the employees’ computers only or should it be online? Hint: Consider the bullet points and tables in this chapter as well as the matrix for assessing relative risks depicted in Figure 5.8.

5.52 Network with a contact you have in some organization that conducts projects (these might be information systems proj- ects, but they could be construction, product development,

research and development, or any type of project). Interview a project manager and find out what type of BPP is constructed. For a typical project, in what ways are baseline plans modified during the life of a project? Why are plans modified after the project begins? What does this tell you about project planning?

5.53 Investigate a privately held organization and try to find out how they go about initiating IS projects. Answer the follow- ing questions: Do they perform roughly the same kind of calculations that have been shown in this chapter (TVM, break-even analysis, etc.)? Do they work with BPPs and PSSs? Who seems to be in charge of initiating the projects? What is the company’s take on risk assessment (economic, technical, political, and so on)?

5.54 Now investigate an organization belonging to the govern- ment and answer the same questions as in the exercise above. What differs between these two organizations and their attitude toward the project initiation process? Does one of them work more strictly than the other, and if so, what could be the reason for this?

5.55 Find an organization that does not use BPP for their IS projects. Why doesn’t this organization use this method? What are the advantages and disadvantages of not using this method? What benefits could be gained from implementing the use of BPP? What barriers are there to implementing this method?

M05_VALA1629_09_GE_C05.indd 163 08/04/2020 16:38

http://aisel.ais-net.org/cgi/viewcontent.cgi?article=1053&context=icis1997

http://www.ctg.albany.edu/publications/guides/roi/roi.pdf

164 PART II PLANNING

Hubbard, D. (2007, June 13). The IT Measurement Inversion. Retrieved March 22, 2018 from http://www.cio.com/arti- cle/2438748/it-organization/the-it-measurement- inversion. html.

Keen, J. (2003). Intangible benefits can play key role in business case. Retrieved March 22, 2018 from http://www.cio.com/ article/2442083/it-organization/intangible-benefits-can- play-key-role-in-business-case.html.

King, J. L., and Schrems, E. (1978). Cost–benefit analysis in infor- mation systems development and operation. ACM Computing Surveys, 10(1), 19–34.

Kirsch, L. J. (2000). Software project management: An integrated perspective for an emerging paradigm. In R. W. Zmud (ed.), Framing the domains of IT management: Projecting the future from the past (pp. 285–304). Cincinnati, OH: Pinnaflex Edu- cational Resources.

Laplante, P. A. (2006). Software return on investment (ROI). In P. A. Laplante and T. Costello (eds.), CIO wisdom II (pp. 163–76). Upper Saddle River, NJ: Prentice Hall.

Lederer, A. L., & Prasad, J. (1992). Nine management guidelines for better cost estimating. Communications of the ACM, 35(2), 51–59.

Morris, R., & Sember, B. M. (2008). Project management that works. New York, NY: American Management Association.

Nash, K. S. (2008, April 9). TCO Versus ROI. Retrieved March 22, 2018 from http://www.cio.com/article/2436828/metrics/ tco-versus-roi.html.

Parker, M. M., & Benson, R. J. (1988). Information economics. Upper Saddle River, NJ: Prentice Hall.

Pressman, R. S. (2014). Software engineering (8th ed.). New York: McGraw-Hill.

Shim, J.K. & Henteleff, N. (1994). What every engineer should know about accounting and finance. New York: Marcel Dekker.

Sonje, R. (2008). Improving project estimation effectiveness. Retrieved March 22, 2018 from http://www.projectper- fect.com.au/white-paper-improving-project-estimation- effectiveness.php.

White, S., & Lui, S. (2005). Distinguishing costs of cooperation and control in alliances. Strategic Management Journal, 26(10), 913–32.

Yourdon, E. (1989). Structured walkthroughs (4th ed.). Upper Sad- dle River, NJ: Prentice Hall.

M05_VALA1629_09_GE_C05.indd 164 08/04/2020 16:38

http://www.cio.com/article/2438748/it-organization/the-it-measurement-inversion.html

http://www.cio.com/article/2438748/it-organization/the-it-measurement�inversion.html

http://www.cio.com/article/2442083/it-organization/intangible-benefits-can-play-key-role-in-business-case.html

http://www.cio.com/article/2436828/metrics/tco-versus-roi.html

http://www.projectperfect.com.au/white-paper-improving-project-estimation-effectiveness.php

http://www.cio.com/article/2442083/it-organization/intangible-benefits-can-play-key-role-in-business-case.html

http://www.cio.com/article/2436828/metrics/tco-versus-roi.html

CHAPTER 5 InItIatIng anD PlannIng SyStemS DeveloPment ProjectS 165

Chapter 5: Initiating and Planning Systems Development Projects

Now that the “No Customer Escapes” project team has been formed and a plan has been developed for distribut- ing project information, Jim can begin working on the proj- ect’s scope statement, workbook, and Baseline Project Plan. He first drafted the project’s scope statement and posted it on the project’s intranet (see PE Figure 5-1). Once posted on the intranet, he sent a short e-mail message to all team members requesting feedback.

Minutes after posting the project charter, Jim’s office phone rang.

“Jim, it’s Sally. I just looked over the scope statement and have a few comments.”

“Great,” replied Jim, “It’s just a draft. What do you think?” “Well, I think that we need to explain more about how

the system will work and why we think this new system will more than pay for itself.”

“Those are good suggestions; I am sure many others will also want to know that information. However, the scope statement is a pretty high-level document and doesn’t get into too much detail. Basically, its purpose is to just formally announce the project, providing a very high-level descrip- tion as well as briefly listing the objectives, key assumptions, and stakeholders. The other documents that I am work- ing on, the workbook and the Baseline Project Plan, are intended to provide more details on specific deliverables, costs, benefits, and so on. So, anyway, that type of more detailed information will be coming next.”

“Oh, OK, that makes sense. I have never been on a proj- ect like this, so this is all new to me,” said Sally.

“Don’t worry,” replied Jim, “Getting that kind of feed- back from you and the rest of the team will be key for us doing a thorough feasibility analysis. I am going to need a lot of your help in identifying possible costs and benefits of the system. When we develop the Baseline Project Plan, we do a very thorough feasibility analysis—we examine financial, technical, operational, schedule, legal and con- tractual feasibility, as well as potential political issues arising through the development of the system.”

“Wow, we have to do all that? Why can’t we just build the system? I think we all know what we want,” replied Sally.

“That is another great question,” replied Jim. “I used to think exactly the same way, but what I learned in my last job was that there are great benefits to following a fairly formal project management process with a new system. By moving forward with care, we are much more likely to have the right system, on time and on budget.”

“So,” asked Sally, “what is the next step?” “Well, we need to do the feasibility analysis I just men-

tioned, which becomes part of the project’s Baseline Project Plan. Once this is completed, we will have a walk-through presentation to management to make sure they agree with

PETRIE ELECTRONICS

and understand the scope, risks, and costs associated with making ‘No Customer Escapes’ a reality,” said Jim.

“This is going to be a lot of work, but I am sure I am going to learn a lot,” replied Sally.

“So, let me get to work on the feasibility analyses,” said Jim. “I will be sending requests out to all the team members to get their ideas. I should have this e-mail ready within an hour or so.”

“Great, I’ll look for it and respond as soon as I can,” answered Sally.

“Thanks, the faster we get this background work done, the sooner we will be able to move on to what the system will do,” replied Jim.

“Sounds good, talk to you later. Bye,” Sally said. “Bye, Sally, and thanks for your quick feedback,”

answered Jim.

Case Questions

5.56 Look over the scope statement (PE Figure 5-1). If you were an employee at Petrie Electronics, would you want to work on this project? Why or why not?

5.57 If you were part of the management team at Petrie Electronics, would you approve the project out- lined in the scope statement in PE Figure 5-1? What changes, if any, need to be made to the document?

5.58 Identify a preliminary set of tangible and intangible costs you think would occur for this project and the system it describes. What intangible benefits do you anticipate for the system?

5.59 What do you consider to be the risks of the project as you currently understand it? Is this a low-, medium-, or high-risk project? Justify your answer. Assuming you were part of Jim’s team, would you have any par- ticular risks?

5.60 If you were assigned to help Jim with this project, how would you utilize the concept of incremental commit- ment in the design of the Baseline Project Plan?

5.61 If you were assigned to Jim’s team for this project, when in the project schedule (in what phase or after which activities are completed) do you think you could develop an economic analysis of the pro- posed system? What economic feasibility factors do you think would be relevant?

5.62 If you were assigned to Jim’s team for this project, what activities would you conduct in order to prepare the details for the Baseline Project Plan? Explain the purpose of each activity and show a timeline or schedule for these activities.

5.63 In case Question 5.59, you analyze the risks associ- ated with this project. Once deployed, what are the potential operational risks of the proposed system? How do you factor operational risks into a systems development plan?

M05_VALA1629_09_GE_C05.indd 165 08/04/2020 16:38

166 PART II PLANNING

Petrie Electronics Prepared: February 6, 2020 Scope Statement

Project Name: No Customer Escapes Project Manager: Jim Watanabe ([email protected])

Customer: Operations Project Sponsor: Ella Whinston ([email protected]) Project Start/End (projected): 2/5/2020 – 7/30/2021

Project Overview:

This project will design and implement a customer relationship management system in order to provide superior customer service by rewarding our most loyal customers. Specifically, the system will track customer purchases, assign points for cumulative purchases, and allow points to be redeemed for “rewards” at local stores. This goal of this system is to provide an incentive to customers to choose Petrie Electronics as their first and only choice for making electronic purchases. The system will provide Petrie management with improved information on the purchase behavior of our most loyal customers.

Objectives:

• Track customer purchases • Accumulate redeemable points • Reward customer loyalty and provide incentives to remain loyal customers • Provide improved management information

Key Assumptions:

• System development will be outsourced • Interface will be a Web browser • System will access existing customer sales databases

Stakeholders and Responsibilities:

Stakeholder Role Responsibility Signatures

Ella Whinston Chief Operating Officer Project Vision, Executive Sponsor

Ella Whinston Bob Petroski Senior Operations

Manager Monitoring, Resources Bob Petroski

Jim Watanabe Project Manager Plan, Monitor, Execute Project

Jim Watanabe

Sally Fukuyama Assistant Director, Marketing

System Functionality Sally Fukuyama

Sanjay Agarwal Lead Analyst Technical Architect Sanjay Agarwal

PE FIGURE 5-1 A Scope Statement for Petrie’s Customer Relationship Management System

M05_VALA1629_09_GE_C05.indd 166 08/04/2020 16:38

mailto:[email protected]

Chapter 6 Determining System Requirements

Chapter 7 Structuring System Process Requirements

Analysis

Chapter 8 Structuring System Data Requirements

PA RT T H R E E

167

M06A_VALA1629_09_GE_P03.indd 167 08/04/2020 16:38

168

Analysis is the first systems development life cycle (SDLC) phase where you begin to understand, in depth, the need for system changes. Systems analysis involves a substantial amount of effort and cost and is therefore undertaken only after management has decided that the systems development project under consideration has merit and should be pursued through this phase. The analysis team should not take the analysis process for granted or attempt to speed through it. Most observers would agree that many of the errors in developed systems are directly traceable to inadequate efforts in the analysis and design phases of the life cycle. Because analysis is a large and involved process, we divide it into two main activities to make the overall process easier to understand:

• Requirements determination. This is primarily a fact- finding activity.

• Requirements structuring. This activity creates a thor- ough and clear description of current business opera- tions and new information processing services.

The purpose of analysis is to determine what informa- tion and information processing services are needed to support selected objectives and functions of the organi- zation. Gathering this information is called requirements determination, the subject of Chapter 6. The fact-finding techniques in Chapter 6 are used to learn about the cur- rent system, the organization that the replacement system will support, and user requirements or expectations for the replacement system.

In Chapter 6, we also discuss a major source of new systems, Business Process Reengineering (BPR). In con- trast to the incremental improvements that drive many systems development projects, BPR results in a radical redesign of the processes that information systems are designed to support. We show how BPR relates to infor- mation systems analysis in Chapter 7, where we use data flow diagrams to support the reengineering process. In Chapter 6, you will also learn about new requirements determination techniques sometimes used as part of agile methodologies. These include the Planning Game (from eXtreme Programming) and Usage-Centered Design.

Information about current operations and require- ments for a replacement system must be organized for analysis and design. Organizing, or structuring, sys- tem requirements results in diagrams and descriptions

OVERVIEW

(models) that can be analyzed to show deficiencies, inef- ficiencies, missing elements, and illogical components of the current business operation and information systems. Along with user requirements, they are used to determine the strategy for the replacement system.

The results of requirements determination can be structured according to three essential views of the cur- rent and replacement information systems:

• Process. The sequence of data movement and handling operations within the system.

• Logic and timing. The rules by which data are trans- formed and manipulated and an indication of what triggers data transformation.

• Data. The inherent structure of data independent of how or when they are processed.

The process view of a system can be represented by data flow diagrams, the primary subject of Chapter 7. The chapter also includes a section on decision tables— one of the ways to describe the logic and timing of what goes on inside the process boxes in data flow diagrams. Chapter 7 ends with three appendices. The first two are dedicated to techniques from the object-oriented view of development. The first appendix introduces you to use case modeling, an object-oriented method used to map a system’s functionality, and the second appendix introduces you to activity diagrams. These object-oriented models focus on system logic and timing. The third appendix covers business process modeling, which is not part of the object-oriented approach. Finally, the data view of a system, discussed in Chapter 8, shows the rules that govern the structure and integrity of data and concentrates on what data about business entities and relationships among these entities must be accessed within the system. Chapter 8 features entity relationship techniques in the body of the chapter and class diagramming techniques for modeling data in a special object-oriented section at the end of the chapter. Petrie’s case installments follow Chapters 7 and 8 to illustrate the processes, logic, and data models that describe a new system. The cases also illustrate how diagrams and models for each of these three views of a system relate to one another to form a consistent and thorough structured description of a proposed system.

PART THREE

Analysis

M06A_VALA1629_09_GE_P03.indd 168 08/04/2020 16:38

169

Systems analysis is the part of the systems development life cycle in which you determine how the current informa- tion system functions and assess what users would like to see in a new system. Analysis has two subphases: require- ments determination and requirements structuring. In this chapter, you will learn about determining system require- ments. We will first study the more traditional requirements determination methods, including interviewing, observing users in their work environment, and collecting procedures and other written documents. We will then discuss more current methods for collecting system requirements. The first of these methods is Joint Application Design ( JAD). Next, you will read about how analysts rely more and more on information systems to help them perform analysis. As you will see, prototyping has become a key tool for some requirements determination efforts. Finally, you will learn how requirements analysis continues to be an important part of systems analysis and design, whether the approach involves business process redesign, agile techniques (such as constant user involvement or usage-centered design), or development of Internet applications.

PERFORMING REQUIREMENTS DETERMINATION As stated earlier and shown in Figure 6-1, there are two subphases to systems analysis: requirements determination and requirements structuring. We will address these as sep- arate steps, but you should consider the steps as parallel and iterative. For example, as you determine some aspects of the current and desired system(s), you begin to struc- ture these requirements or build prototypes to show users how a system might behave. Inconsistencies and deficien- cies discovered through structuring and prototyping lead you to explore further the operation of current system(s) and the future needs of the organization. Eventually, your ideas and discoveries converge in a thorough and accu- rate depiction of current operations and requirements for the new system. As you think about beginning the analysis phase, you are probably wondering what exactly is involved in requirements determination. We discuss this process in the next section.

6.4 participate in and help plan a Joint Application Design session;

6.5 use prototyping during requirements determination;

6.6 describe contemporary approaches to requirements determination; and

6.7 understand how requirements determination techniques apply to the development of electronic commerce applications.

Learning Objectives After studying this chapter, you should be able to

6.1 describe options for designing and conducting interviews and develop a plan for conducting an interview to determine system requirements;

6.2 explain the advantages and pitfalls of observing workers and analyzing business documents to determine system requirements;

6.3 explain how computing can provide support for requirements determination;

Determining System Requirements6

Introduction

M06B_VALA1629_09_GE_C06.indd 169 15/04/2020 11:45

170 PART III ANALYSIS

The Process of Determining Requirements

Once management has granted permission to pursue development of a new system (this was done at the end of the project identification and selection phase of the SDLC) and a project is initiated and planned (see Chapter 5), you begin determining what the new system should do. During requirements determination, you and other analysts gather information on what the system should do from as many sources as possible: from users of the current system; from observing users; and from reports, forms, and procedures. All of the system requirements are carefully documented and prepared for structuring, the subject of Chapters 7 and 8.

In many ways, gathering system requirements is like conducting any investiga- tion. Have you read any Sherlock Holmes or similar mystery stories? Do you enjoy solving puzzles? From these experiences, we can detect some similar characteristics for a good systems analyst during the requirements determination subphase. These characteristics include the following:

• Impertinence. You should question everything. You need to ask questions such as: Are all transactions processed the same way? Could anyone be charged something other than the standard price? Might we someday want to allow and encourage employees to work for more than one department?

• Impartiality. Your role is to find the best solution to a business problem or opportunity. It is not, for example, to find a way to justify the purchase of new hardware or to insist on incorporating what users think they want into the new system requirements. You must consider issues raised by all parties and try to find the best organizational solution.

• Relax constraints. Assume that anything is possible and eliminate the infeasible. For example, do not accept this statement: “We’ve always done it that way, so we have to continue the practice.” Traditions are different from rules and poli- cies. Traditions probably started for a good reason but, as the organization and its environment change, they may turn into habits rather than sensible procedures.

• Attention to details. Every fact must fit with every other fact. One element out of place means that even the best system will fail at some time. For example, an imprecise definition of who a customer is may mean that you purge customer data when a customer has no active orders, yet these past customers may be vital contacts for future sales.

FIGURE 6-1 Systems development life cycle with analysis phase highlighted

DesignImplementation

Planning

Maintenance Requirements Determination Requirements Structuring

Analysis

M06B_VALA1629_09_GE_C06.indd 170 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 171

• Reframing. Analysis is, in part, a creative process. You must challenge yourself to look at the organization in new ways. You must consider how each user views his or her requirements. You must be careful not to jump to the following conclu- sion: “I worked on a system like that once—this new system must work the same way as the one I built before.”

Deliverables and Outcomes

The primary deliverables from requirements determination are the various forms of information gathered during the determination process: transcripts of interviews; notes from observation and analysis of documents; sets of forms, reports, job descrip- tions, and other documents; and computer-generated output such as system proto- types. In short, anything that the analysis team collects as part of determining system requirements is included in the deliverables resulting from this subphase of the sys- tems development life cycle. Table 6-1 lists examples of some specific information that might be gathered during requirements determination.

These deliverables contain the information you need for systems analysis within the scope of the system you are developing. In addition, you need to understand the following components of an organization:

• The business objectives that drive what and how work is done • The information people need to do their jobs • The data (definition, volume, size, etc.) handled within the organization to sup-

port the jobs • When, how, and by whom or what the data are moved, transformed, and stored • The sequence and other dependencies among different data-handling activities • The rules governing how data are handled and processed • Policies and guidelines that describe the nature of the business and the market

and environment in which it operates • Key events affecting data values and when these events occur

As should be obvious, such a large amount of information must be organized in order to be useful. This is the purpose of the next subphase—requirements structuring.

From just this subphase of analysis, you have probably already realized that the amount of information to be gathered could be huge, especially if the scope of the system under development is broad. The time required to collect and structure a great deal of information can be extensive and, because it involves so much human effort, quite expensive. Too much analysis is not productive, and the term analysis paralysis has been coined to describe a systems development project that has become bogged down in an abundance of analysis work. Because of the dangers of excessive analysis, today’s systems analysts focus more on the system to be developed than on the current system. The techniques you will learn about later in this chapter, JAD and prototyp- ing, were developed to keep the analysis effort at a minimum yet still keep it effective. Newer techniques have also been developed to keep requirements determination fast and flexible, including continual user involvement, usage-centered design, and the Planning Game from eXtreme Programming. Traditional fact-gathering techniques are the subject of the next section.

1. Information collected from conversations with or observations of users: interview tran- scripts, notes from observation, meeting minutes

2. Existing written information: business mission and strategy statements, sample business forms and reports and computer displays, procedure manuals, job descriptions, training manuals, flowcharts and documentation of existing systems, consultant reports

3. Computer-based information: results from JAD sessions, reports of existing systems, and displays and reports from system prototypes

TABLE 6-1 Deliverables for Requirements Determination

M06B_VALA1629_09_GE_C06.indd 171 15/04/2020 11:45

172 PART III ANALYSIS

TRADITIONAL METHODS FOR DETERMINING REQUIREMENTS At the core of systems analysis is the collection of information. At the outset, you must collect information about the information systems that are currently being used and how users would like to improve the current systems and organizational operations with new or replacement information systems. One of the best ways to get this infor- mation is to talk to the people who are directly or indirectly involved in the different parts of the organizations affected by the possible system changes: users, managers, shareholders, and so on. Another way to find out about the current system is to gather copies of documentation relevant to current systems and business processes. In this chapter, you will learn about various ways to get information directly from stakehold- ers: interviews, group interviews, the Nominal Group Technique, and direct obser- vation. You will learn about collecting documentation on the current system and organizational operation in the form of written procedures, forms, reports, and other hard copy. These traditional methods of collecting system requirements are listed in Table 6-2.

Interviewing and Listening

Interviewing is one of the primary ways analysts gather information about an informa- tion systems project. Early in a project, an analyst may spend a large amount of time interviewing people about their work, the information they use to do it, and the types of information processing that might supplement their work. Other stakeholders are interviewed to understand organizational direction, policies, expectations managers have on the units they supervise, and other nonroutine aspects of organizational operations. During interviewing you will gather facts, opinions, and speculation and observe body language, emotions, and other signs of what people want and how they assess current systems.

There are many ways to effectively interview someone, and no one method is necessarily better than another. Some guidelines you should keep in mind when you interview, summarized in Table 6-3, are discussed next.

First, you should prepare thoroughly before the interview. Set up an appoint- ment at a time and for a duration convenient for the interviewee. The general nature of the interview should be explained to the interviewee in advance. You may ask the interviewee to think about specific questions or issues or to review certain documenta- tion to prepare for the interview. You should spend some time thinking about what you need to find out and write down your questions. Do not assume that you can anticipate all possible questions. You want the interview to be natural, and, to some degree, you want to spontaneously direct the interview as you discover what expertise the interviewee brings to the session.

You should prepare an interview guide or checklist so that you know in which sequence you intend to ask your questions and how much time you want to spend in each area of the interview. The checklist might include some probing questions

• Individually interview people informed about the operation and issues of the current system and future systems needs

• Interview groups of people with diverse needs to find synergies and contrasts among system requirements

• Observe workers at selected times to see how data are handled and what information people need to do their jobs

• Study business documents to discover reported issues, policies, rules, and directions as well as concrete examples of the use of data and information in the organization

TABLE 6-2 Traditional Methods of Collecting System Requirements

Plan the Interview

• Prepare interviewee: appoint- ment, priming questions

• Prepare checklist, agenda, and questions

Listen carefully and take notes (record if permitted)

Review notes within 48 hours of interview

Be neutral Seek diverse views

TABLE 6-3 Guidelines for Effec- tive Interviewing

M06B_VALA1629_09_GE_C06.indd 172 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 173

to ask as follow-ups if you receive certain anticipated responses. You can, to some degree, integrate your interview guide with the notes you take during the interview, as depicted in a sample guide in Figure 6-2. This same guide can serve as an outline for a summary of what you discover during an interview.

The first page of the sample interview guide contains a general outline of the interview. Besides basic information on who is being interviewed and when, you list major objectives for the interview. These objectives typically cover the most important data you need to collect, a list of issues on which you need to seek agreement (e.g., content for certain system reports), and which areas you need to explore, not nec- essarily with specific questions. You also include reminder notes to yourself on key information about the interviewee (e.g., job history, known positions taken on issues, and role with current system). This information helps you to be personal, shows that you consider the interviewee to be important, and may assist you in interpreting some answers. Also included is an agenda for the interview with approximate time limits for different sections of the interview. You may not follow the time limits precisely, but the schedule helps you cover all areas during the time the interviewee is available. Space is also allotted for general observations that do not fit under specific questions and for notes taken during the interview about topics skipped or issues raised that could not be resolved.

On subsequent pages you list specific questions; the sample form in Figure 6-2 includes space for taking notes on these questions. Because unanticipated informa- tion arises, you will not strictly follow the guide in sequence. You can, however, check off the questions you have asked and write reminders to yourself to return to or skip certain questions as the dynamics of the interview unfold.

Choosing Interview Questions You need to decide what mix and sequence of open-ended and closed-ended questions you will use. Open-ended questions are usually used to probe for information for which you cannot anticipate all possible responses or for which you do not know the precise question to ask. The person being interviewed is encouraged to talk about whatever interests him or her within the general bounds of the question. An example is, “What would you say is the best thing about the information system you currently use to do your job?” or “List the three most frequently used menu options.” You must react quickly to answers and determine whether or not any follow-up questions are needed for clarification or elaboration. Sometimes body language will suggest that a user has given an incomplete answer or is reluctant to divulge some information; a follow-up question might yield additional insight. One advantage of open-ended questions is that previously unknown informa- tion can surface. You can then continue exploring along unexpected lines of inquiry to reveal even more new information. Open-ended questions also often put the inter- viewees at ease because they are able to respond in their own words using their own structure; open-ended questions give interviewees more of a sense of involvement and control in the interview. A major disadvantage of open-ended questions is the length of time it can take for the questions to be answered. In addition, open-ended questions can be difficult to summarize.

Closed-ended questions provide a range of answers from which the interviewee may choose. Here is an example:

Which of the following would you say is the one best thing about the information system you currently use to do your job (pick only one)?

a. Having easy access to all of the data you need b. The system’s response time c. The ability to access the system from remote locations

Closed-ended questions work well when the major answers to questions are well known. Another plus is that interviews based on closed-ended questions do not nec- essarily require a large time commitment—more topics can be covered. You can see body language and hear voice tone, which can aid in interpreting the interviewee’s

Open-ended questions Questions in interviews that have no prespecified answers.

Closed-ended questions Questions in interviews that ask those responding to choose from among a set of specified responses.

M06B_VALA1629_09_GE_C06.indd 173 15/04/2020 11:45

174 PART III ANALYSIS

FIGURE 6-2 Typical interview guide

M06B_VALA1629_09_GE_C06.indd 174 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 175

responses. Closed-ended questions can also be an easy way to begin an interview and to determine which line of open-ended questions to pursue. You can include an “other” option to encourage the interviewee to add unanticipated responses. A major disad- vantage of closed-ended questions is that useful information that does not quite fit into the defined answers may be overlooked as the respondent tries to make a choice instead of providing his or her best answer.

Closed-ended questions, like objective questions on an examination, can follow several forms, including the following choices:

• True or false. • Multiple choice (with only one response or selecting all relevant choices). • Rating a response or idea on a scale, say from bad to good or strongly agree to

strongly disagree. Each point on the scale should have a clear and consistent meaning to each person, and there is usually a neutral point in the middle of the scale.

• Ranking items in order of importance.

Interview Guidelines First, with either open- or closed-ended questions, do not phrase a question in a way that implies a right or wrong answer. The respondent must feel that he or she can state his or her true opinion and perspective and that his or her idea will be considered equally with those of others. Questions such as “Should the system continue to provide the ability to override the default value, even though most users now do not like the feature?” should be avoided because such wording predefines a socially acceptable answer.

The second guideline to remember about interviews is to listen very carefully to what is being said. Take careful notes or, if possible, record the interview (be sure to ask permission first!). The answers may contain extremely important information for the project. Also, this may be the only chance you have to get information from this particular person. If you run out of time and still need to get information from the person you are talking to, ask to schedule a follow-up interview.

Third, once the interview is over, go back to your office and type up your notes within 48 hours. If you recorded the interview, use the recording to verify the material in your notes. After 48 hours, your memory of the interview will fade quickly. As you type and organize your notes, write down any additional questions that might arise from lapses in your notes or from ambiguous information. Separate facts from your opinions and interpretations. Make a list of unclear points that need clarification. Call the person you interviewed and get answers to these new questions. Use the phone call as an opportunity to verify the accuracy of your notes. You may also want to send a written copy of your notes to the person you interviewed so the person can check your notes for accuracy. Finally, make sure you thank the person for his or her time. You may need to talk to your respondent again. If the interviewee will be a user of your system or is involved in another way in the system’s success, you want to leave a good impression.

Fourth, be careful during the interview not to set expectations about the new or replacement system unless you are sure these features will be part of the delivered system. Let the interviewee know that there are many steps to the project and the perspectives of many people need to be considered, along with what is technically possible. Let respondents know that their ideas will be carefully considered, but that due to the iterative nature of the systems development process, it is premature to say now exactly what the ultimate system will or will not do.

Fifth, seek a variety of perspectives from the interviews. Find out what potential users of the system, users of other systems that might be affected by changes, managers and superiors, information systems staff who have experience with the current system, and others think the current problems and opportunities are and what new informa- tion services might better serve the organization. You want to understand all possible perspectives so that in a later approval step you will have information on which to base a recommendation or design decision that all stakeholders can accept.

M06B_VALA1629_09_GE_C06.indd 175 15/04/2020 11:45

176 PART III ANALYSIS

Interviewing Groups

One drawback to using interviews to collect systems requirements is the need for the analyst to reconcile apparent contradictions in the information collected. A series of interviews may turn up inconsistent information about the current system or its replacement. You must work through all of these inconsistencies to figure out what might be the most accurate representation of current and future systems. Such a process requires several follow-up phone calls and additional interviews. Catching important people in their offices is often difficult and frustrating, and scheduling new interviews may become very time consuming. In addition, new interviews may reveal new questions that in turn require additional interviews with those interviewed earlier. Clearly, gathering information about an information system through a series of individual interviews and follow-up calls is not an efficient process.

Another option available to you is the group interview. In a group interview, several key people are interviewed at once. To make sure all of the important informa- tion is collected, you may conduct the interview with one or more analysts. In the case of multiple interviewers, one analyst may ask questions while another takes notes, or different analysts might concentrate on different kinds of information. For example, one analyst may listen for data requirements while another notes the timing and trig- gering of key events. The number of interviewees involved in the process may range from two to however many you believe can be comfortably accommodated.

A group interview has a few advantages. One, it is a much more effective use of your time than a series of interviews with individuals (although the time commitment of the interviewees may be more of a concern). Two, interviewing several people together allows them to hear the opinions of other key people and gives them the opportunity to agree or disagree with their peers. Synergies also often occur. For example, the comments of one person might cause another person to say, “That reminds me of” or “I didn’t know that was a problem.” You can benefit from such a discussion as it helps you identify issues on which there is general agreement and areas where views diverge widely.

The primary disadvantage of a group interview is the difficulty in scheduling it. The more people who are involved, the more difficult it will be finding a convenient time and place for everyone. Modern videoconferencing technology can minimize the geographical dispersion factors that make scheduling meetings so difficult. Group interviews are at the core of the JAD process, which we discuss in a later section in this chapter. A specific technique for working with groups, Nominal Group Technique, is discussed next.

Nominal Group Technique Many different techniques have been developed over the years to improve the process of working with groups. One of the more popular techniques for generating ideas among group members is called Nominal Group Technique (NGT). NGT is exactly what the name indicates—the individuals working together to solve a problem are a group in name only, or nominally. Group members may be gathered in the same room for NGT, but they all work alone for a period of time. Typically, group members make a written list of their ideas. At the end of the idea-generation time, group members pool their individual ideas under the guidance of a trained facilitator. Pooling usually involves having the facilitator ask each person in turn for an idea that has not been presented before. As the person reads the idea aloud, someone else writes down the idea on a blackboard or flip chart. After all of the ideas have been introduced, the facilitator will then ask for the group to openly discuss each idea, primarily for clarification.

Once all of the ideas are understood by all of the participants, the facilitator will try to reduce the number of ideas the group will carry forward for additional consid- eration. There are many ways to reduce the number of ideas. The facilitator may ask participants to choose only a subset of ideas that they believe are important. Then the facilitator will go around the room, asking each person to read aloud an idea that is

Nominal Group Technique (NGT) A facilitated process that supports idea generation by groups. At the beginning of the process, group members work alone to generate ideas. The ideas are then pooled under the guidance of a trained facilitator.

M06B_VALA1629_09_GE_C06.indd 176 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 177

important to him or her that has not yet been identified by someone else. Or the facilitator may work with the group to identify and either eliminate or combine ideas that are very similar to others. At some point, the facilitator and the group end up with a tractable set of ideas, which can be further prioritized.

In a requirements determination context, the ideas being sought in an NGT exercise would typically apply to problems with the existing system or ideas for new features in the system being developed. The end result would be a list of either prob- lems or features that group members themselves had generated and prioritized. There should be a high level of ownership of such a list, at least for the group that took part in the NGT exercise.

There is some evidence to support the use of NGT to help focus and refine the work of a group in that the number and quality of ideas that result from an NGT may be higher than what would normally be obtained from an unfacilitated group meet- ing. An NGT exercise could be used to complement the work done in a typical group interview or as part of a Joint Application Design effort, described in more detail later in this chapter.

Directly Observing Users

All the methods of collecting information that we have been discussing up until now involve getting people to recall and convey information they have about an organiza- tional area and the information systems that support these processes. People, however, are not always very reliable informants, even when they try to be reliable and tell what they think is the truth. As odd as it may sound, people often do not have a completely accurate appreciation of what they do or how they do it. This is especially true con- cerning infrequent events, issues from the past, or issues for which people have con- siderable passion. Because people cannot always be trusted to reliably interpret and report their own actions, you can supplement and corroborate what people tell you by watching what they do or by obtaining relatively objective measures of how people behave in work situations. (See the box “Lost Soft Drink Sales” for an example of the importance of systems analysts learning firsthand about the business for which they are designing systems.)

For example, one possible view of how a hypothetical manager does her job is that a manager carefully plans her activities, works for long periods of time and con- sistently on solving problems, and controls the pace of her work. A manager might tell you that is how she spends her day. When Mintzberg (1973) observed how man- agers work, however, he found that a manager’s day is actually punctuated by many, many interruptions. Managers work in a fragmented manner, focusing on a problem or on a communication for only a short time before they are interrupted by phone calls or e-mail or visits from their subordinates and other managers. An information system designed to fit the work environment described by our hypothetical manager would not effectively support the actual work environment in which that manager finds herself.

As another example, consider the difference between what another employee might tell you about how much he uses e-mail and how much e-mail use you might discover through more objective means. An employee might tell you he is swamped with e-mail messages and that he spends a significant proportion of his time respond- ing to e-mail. However, if you were able to check electronic mail records, you might find that this employee receives only three e-mail messages per day on average, and that the most messages he has ever received during one eight-hour period is 10. In this case, you were able to obtain an accurate behavioral measure of how much e-mail this employee copes with without having to watch him read his e-mail.

The intent behind obtaining system records and direct observation is the same, however, and that is to obtain more firsthand and objective measures of employee interaction with information systems. In some cases, behavioral measures will be a more accurate reflection of reality than what employees believe. In other cases,

M06B_VALA1629_09_GE_C06.indd 177 15/04/2020 11:45

178 PART III ANALYSIS

the behavioral information will substantiate what employees have told you directly. Although observation and obtaining objective measures are desirable ways to collect pertinent information, such methods are not always possible in real organizational settings. Thus, these methods are not totally unbiased, just as no other one data- gathering method is unbiased.

For example, observation can cause people to change their normal operating behavior. Employees who know they are being observed may be nervous and make more mistakes than normal, may be careful to follow exact procedures they do not typically follow, and may work faster or slower than normal. Moreover, because obser- vation typically cannot be continuous, you receive only a snapshot image of the person or task you observe, which may not include important events or activities. Because observation is very time consuming, you will not only observe for a limited time, but also a limited number of people and a limited number of sites. Again, observation yields only a small segment of data from a possibly vast variety of data sources. Exactly which people or sites to observe is a difficult selection problem. You want to pick both typical and atypical people and sites and observe during normal and abnormal condi- tions and times to receive the richest possible data from observation.

Analyzing Procedures and Other Documents

As noted earlier, asking questions of the people who use a system every day or who have an interest in a system is an effective way to gather information about current and future systems. Observing current system users is a more direct way of seeing how an existing system operates, but even this method provides limited exposure to all aspects of current operations. These methods of determining system requirements can be enhanced by examining system and organizational documentation to discover more details about current systems and the organization these systems support.

Although we discuss here several important types of documents that are useful in understanding possible future system requirements, our discussion does not exhaust all possibilities. You should attempt to find all written documents about the organiza- tional areas relevant to the systems under redesign. Besides the few specific documents

A systems analyst was quite surprised to read that sales of all soft-drink products were lower, instead of higher, after a new delivery truck routing system was installed. The software was designed to reduce stock-outs at customer sites by allowing drivers to visit each customer more often using more efficient delivery routes.

Confused by the results, management asked the analyst to delay a scheduled vacation, but he insisted that he could look afresh at the system only after a few overdue days of rest and relaxation.

Instead of taking a vacation, however, the analyst called a delivery dispatcher he interviewed during the design of the system and asked to be given a route for a few days. The analyst drove a route (for a regular driver who was actually on vacation), following the schedule developed from the new system. What the analyst discovered was that the route was very efficient, as expected; so, at first, the analyst could not see any reason for lost sales.

During the third and last day of his “vacation,” the analyst stayed overtime at one store to ask the manager if she had

any ideas why sales might have dropped off in recent weeks. The manager had no explanation but did make a seemingly unrelated observation that the regular route driver appeared to have less time to spend in the store. He did not seem to take as much interest in where the products were displayed and did not ask for promotional signs to be displayed, as he had often done in the past.

From this conversation, the analyst concluded that the new delivery truck routing system was, in one sense, too good. It placed the driver on such a tight schedule that he had no time left for the “schmoozing” required to get special treatment, which gave the company’s products an edge over the competition.

Without firsthand observation of the system in action gained by participating as a system user, the analyst might never have discovered the true problem with the system design. Once time was allotted for not only stocking new products but also for necessary marketing work, product sales returned to and exceeded levels achieved before the new system had been introduced.

Lost Soft Drink Sales

M06B_VALA1629_09_GE_C06.indd 178 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 179

we discuss, organizational mission statements, business plans, organization charts, business policy manuals, job descriptions, internal and external correspondence, and reports from prior organizational studies can all provide valuable insight.

What can the analysis of documents tell you about the requirements for a new system? In documents you can find information about the following:

• Problems with existing systems (e.g., missing information or redundant steps) • Opportunities to meet new needs if only certain information or information

processing were available (e.g., analysis of sales based on customer type) • Organizational direction that can influence information system requirements

(e.g., trying to link customers and suppliers more closely to the organization) • Titles and names of key individuals who have an interest in relevant

existing systems (e.g., the name of a sales manager who led a study of the buying behavior of key customers)

• Values of the organization or individuals who can help determine priorities for different capabilities desired by different users (e.g., maintaining market share even if it means lower short-term profits)

• Special information processing circumstances that occur irregularly that may not be identified by any other requirements determination technique (e.g., special handling needed for a few large-volume customers that requires use of customized customer ordering procedures)

• The reason why current systems are designed as they are, which can suggest fea- tures left out of current software, which may now be feasible and more desirable (e.g., data about a customer’s purchase of competitors’ products were not avail- able when the current system was designed; these data are now available from several sources)

• Data, rules for processing data, and principles by which the organization operates that must be enforced by the information system (e.g., each customer is assigned exactly one sales department staff member as a primary contact if the customer has any questions)

One type of useful document is a written work procedure for an individual or a work group. The procedure describes how a particular job or task is performed, including data and information that are used and created in the process of perform- ing the job. For example, the procedure shown in Figure 6-3 includes the data (list of features and advantages, drawings, inventor name, and witness names) that are required to prepare an invention disclosure. It also indicates that besides the inventor, the vice president for research, the department head, and the dean must review the material, and that a witness is required for any filing of an invention disclosure. These insights clearly affect what data must be kept, to whom information must be sent, and the rules that govern valid forms.

Procedures are not trouble-free sources of information, however. Sometimes your analysis of several written procedures will reveal a duplication of effort in two or more jobs. You should call such duplication to the attention of management as an issue to be resolved before system design can proceed. That is, it may be necessary to redesign the organization before the redesign of an information system can achieve its full benefits. Another problem you may encounter with a procedure occurs when the procedure is missing. Again, it is not your job to create a document for a missing procedure—that is up to management. A third and common problem with a written procedure happens when the procedure is out of date. You may realize the procedure is out of date when you interview the person responsible for performing the task described in the procedure. Once again, the decision to rewrite the procedure so that it matches reality is made by management, but you may make suggestions based upon your understanding of the organization. A fourth problem often encountered with written procedures is that the formal procedures may contradict information you collected from interviews and observation about how the organization operates and what information is required. As in the other cases, resolution rests with management.

M06B_VALA1629_09_GE_C06.indd 179 15/04/2020 11:45

180 PART III ANALYSIS

All of these problems illustrate the difference between formal systems and informal systems. Formal systems are recognized in the official documentation of the organization; informal systems are the way in which the organization actually works. Informal systems develop because of inadequacies of formal procedures, individual work habits and preferences, resistance to control, and other factors. It is important to understand both formal and informal systems because each provides insight into information requirements and what will be required to convert from present to future information services.

A second type of document useful to systems analysts is a business form (see Figure 6-4). Forms are used for all types of business functions, from recording an order acknowledging the payment of a bill to indicating what goods have been shipped. Forms are important for understanding a system because they explicitly indicate what

Formal system The official way a system works as described in organizational documentation.

Informal system The way a system actually works.

FIGURE 6-3 Example of a procedure GUIDE FOR PREPARATION OF INVENTION DISCLOSURE

(See FACULTY and STAFF MANUALS for Detailed Patent Policy and Routing Procedures.)

(1) DISCLOSE ONLY ONE INVENTION PER FORM.

(2) PREPARE COMPLETE DISCLOSURE.

The disclosure of your invention is adequate for patent purposes ONLY if it enables a person skilled in the art to understand the invention.

(3) CONSIDER THE FOLLOWING IN PREPARING A COMPLETE DISCLOSURE:

(a) All essential elements of the invention, their relationship to one another, and their mode of operation.

(b) Equivalents that can be substituted for any elements.

(d) Advantages this invention has over the prior art.

(e) Whether the invention has been built and/or tested.

(4) PROVIDE APPROPRIATE ADDITIONAL MATERIAL.

Drawings and descriptive material should be provided as needed to clarify the dis- closure. Each page of this material must be signed and dated by each inventor and properly witnessed. A copy of any current and/or planned publication relating to the invention should be included.

(5) INDICATE PRIOR KNOWLEDGE AND INFORMATION.

Pertinent publications, patents or previous devices, and related research or engineer- ing activities should be identified.

(6) HAVE DISCLOSURE WITNESSED.

Persons other than coinventors should serve as witnesses and should sign each sheet of the disclosure only after reading and understanding the disclosure.

(7) FORWARD ORIGINAL PLUS ONE COPY (two copies if supported by grant/contract) TO VICE PRESIDENT FOR RESEARCH VIA DEPARTMENT HEAD AND DEAN.

M06B_VALA1629_09_GE_C06.indd 180 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 181

data flow in or out of a system and which are necessary for the system to function. In the sample invoice form in Figure 6-4, we see locations for data such as the name and bill-to address of the customer, the invoice number, data (quantity, description, amount) about each line item on the invoice, and calculated data such as the total.

A form gives us crucial information about the nature of the organization. For example, the company can ship and bill to different addresses; customers can have discounts applied; and the freight expense is charged to the customer. A printed form may correspond to a computer display that the system will generate for someone to enter and maintain data or to display data to online users. Forms are most useful to you when they contain actual organizational data because this allows you to determine the characteristics of the data that are actually used by the application. The ways in which people use forms change over time, and data that were needed when a form was designed may no longer be required. You can use the systems analysis techniques pre- sented in Chapters 7 and 8 to help you determine which data are no longer required.

A third type of useful document is a report generated by current systems. As the primary output for some types of systems, a report enables you to work backward from the information on the report to the data that must have been necessary to generate them. Figure 6-5 presents an example of a typical financial report, a statement of cash

FIGURE 6-4 An invoice form from Microsoft Excel

(Source: Microsoft Corporation.)

Your Company Name

INVOICE

SUBTOTAL

TAX RATE

SALES TAX

THANK YOU FOR YOUR BUSINESS! OTHER

TOTAL

Your Company Slogan

8.60 Percent

Street Address City, ST ZIP Code Phone: Fax:

–

DESCRIPTION T

AMOUNT

March 13, 2020DATE:

100INVOICE #

Project or Service DescriptionFOR:

Name Company Name Street Address City, ST ZIP Code Phone:

BILL TO:

Make all checks payable to Your Company Name. If you have any questions concerning this invoice, contact Name, Phone Number, Email

–

M06B_VALA1629_09_GE_C06.indd 181 15/04/2020 11:45

182 PART III ANALYSIS

FIGURE 6-5 An example of a report: a statement of cash flows

Mellankamp Industries

Statement of Cash Flows

October 1 through December 31, 2020

OPERATING ACTIVITIES

Net Income

Adjustments to reconcile Net Income to net cash provided by operations:

Accounts Receivable

Employee Loans

Inventory Asset

Retainage

Accounts Payable

Business Credit Card

BigOil Card

Sales Tax Payable

Net cash provided by Operating Activities

INVESTING ACTIVITIES

Equipment

Prepaid Insurance

Net cash provided by Investing Activities

FINANCING ACTIVITIES

Bank Loan

Emergency Loan

Note Payable

Equipment Loan

Opening Balance Equity

Owner’s Equity: Owner’s Draw

Retained Earnings

Net cash provided by Financing Activities

Net cash increase for period

Cash at beginning of period

Cash at end of period

Oct 1–Dec 31, 2020

$38,239.15

–$46,571.69

–62.00

–18,827.16

–2,461.80

29,189.66

70.00

–18.86

687.65

$244.95

–$44,500.00

2,322.66

–$42,177.34

–$868.42

3,911.32

–17,059.17

43,013.06

–11,697.50

–6,000.00

8,863.39

$20,162.68

–$21,769.71

–$21,818.48

–$43,588.19

M06B_VALA1629_09_GE_C06.indd 182 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 183

flows. You would analyze such reports to determine which data need to be captured over what time period and what manipulation of these raw data would be necessary to produce each field on the report.

If the current system is computer-based, a fourth set of useful documents are those that describe the current information systems—how they were designed and how they work. A lot of different types of documents fit this description, everything from flowcharts to data dictionaries to user manuals. An analyst who has access to such documents is lucky; many information systems developed in-house lack complete documentation.

Analysis of organizational documents and observation, along with interview- ing, are the methods most often used for gathering system requirements. Table 6-4 summarizes the comparative features of observation and analysis of organizational documents.

CONTEMPORARY METHODS FOR DETERMINING SYSTEM REQUIREMENTS Even though we called interviews, observation, and document analysis traditional methods for determining a system’s requirements, all of these methods are still very much used by analysts to collect important information. There are additional techniques to collect information about the current system, the organizational area requesting the new system, and what the new system should be like. In this section, you will learn about several contemporary information-gathering techniques for analysis (listed in Table 6-5): JAD and prototyping. As we said earlier, these techniques can support effective information collection and structuring while reducing the amount of time required for analysis.

Characteristic Observation Document Analysis

Information Richness High (many channels) Low (passive) and old Time Required Can be extensive Low to moderate Expense Can be high Low to moderate Chance for Follow-Up

and Probing Good: probing and clarification

questions can be asked during or after observation

Limited: probing possible only if original author is available

Confidentiality Observee is known to interviewer; observee may change behavior when observed

Depends on nature of document; does not change simply by being read

Involvement of Subject Interviewees may or may not be involved and committed depend- ing on whether they know if they are being observed

None, no clear commitment

Potential Audience Limited numbers and limited time (snapshot) of each

Potentially biased by which documents were kept or because document was not created for this purpose

TABLE 6-4 Comparison of Observation and Document Analysis

• Bringing session users, sponsors, analysts, and others together in a JAD session to discuss and review system requirements

• Iteratively developing system prototypes that refine the understanding of system require- ments in concrete terms by showing working versions of system features

TABLE 6-5 Contemporary Methods for Collecting System Requirements

M06B_VALA1629_09_GE_C06.indd 183 15/04/2020 11:45

184 PART III ANALYSIS

Joint Application Design

Joint Application Design ( JAD) started in the late 1970s at IBM, and since then the practice of JAD has spread throughout many companies and industries. For example, it is quite popular in the insurance industry in Connecticut, where a JAD users’ group has been formed. In fact, several generic approaches to JAD have been documented and popularized (see Wood and Silver, 1995, for an example). The main idea behind JAD is to bring together the key users, managers, and systems analysts involved in the analysis of a current system. In that respect, JAD is similar to a group interview; a JAD, however, follows a particular structure of roles and agenda that is quite differ- ent from a group interview during which analysts control the sequence of questions answered by users. The primary purpose of using JAD in the analysis phase is to collect systems requirements simultaneously from the key people involved with the system. The result is an intense and structured, but highly effective, process. As with a group interview, having all the key people together in one place at one time allows analysts to see where there are areas of agreement and where there are conflicts. Meeting with all of these important people for over a week of intense sessions allows you the opportunity to resolve conflicts, or at least to understand why a conflict may not be simple to resolve.

JAD sessions are usually conducted at a location other than the place where the people involved normally work. The idea behind such a practice is to keep participants away from as many distractions as possible so that they can concentrate on systems analysis. A JAD may last anywhere from four hours to an entire week and may consist of several sessions. A JAD employs thousands of dollars of corporate resources, the most expensive of which is the time of the people involved. Other expenses include the costs associated with flying people to a remote site and putting them up in hotels and feeding them for several days.

The typical participants in a JAD are listed below:

• JAD session leader. The JAD session leader organizes and runs the JAD. This person has been trained in group management and facilitation as well as in systems analysis. The JAD leader sets the agenda and sees that it is met; he or she remains neutral on issues and does not contribute ideas or opinions, but rather concentrates on keeping the group on the agenda, resolving conflicts and disagreements, and soliciting all ideas.

• Users. The key users of the system under consideration are vital participants in a JAD. They are the only ones who have a clear understanding of what it means to use the system on a daily basis.

• Managers. Managers of the work groups who use the system in question provide insight into new organizational directions, motivations for and organizational impacts of systems, and support for requirements determined during the JAD.

• Sponsor. As a major undertaking due to its expense, a JAD must be sponsored by someone at a relatively high level in the company. If the sponsor attends any sessions, it is usually only at the very beginning or the end.

• Systems analysts. Members of the systems analysis team attend the JAD, although their actual participation may be limited. Analysts are there to learn from users and managers, not to run or dominate the process.

• Scribe. The scribe takes notes during the JAD sessions. This is usually done on a laptop.

• IS staff. Besides systems analysts, other information systems (IS) staff, such as programmers, database analysts, IS planners, and data center personnel, may attend to learn from the discussion and possibly contribute their ideas on the technical feasibility of proposed ideas or the technical limitations of current systems.

Joint Application Design (JAD) A structured process in which users, managers, and analysts work together for several days in a series of intensive meetings to specify or review system requirements.

JAD session leader The trained individual who plans and leads Joint Application Design sessions.

Scribe The person who makes detailed notes of the happenings at a Joint Application Design session.

M06B_VALA1629_09_GE_C06.indd 184 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 185

JAD sessions are usually held in special-purpose rooms where participants sit around horseshoe-shaped tables, as shown in Figure 6-6. These rooms are typically equipped with whiteboards. Other audiovisual tools may be used, such as magnetic sym- bols that can be easily rearranged on a whiteboard, flip charts, and computer-generated displays. Flip-chart paper is typically used for keeping track of issues that cannot be resolved during the JAD or for those issues requiring additional information that can be gathered during breaks in the proceedings. Computers may be used to create and display form or report designs, diagram existing or replacement systems, or create prototypes.

When a JAD is completed, the end result is a set of documents that detail the workings of the current system related to the study of a replacement system. Depend- ing on the exact purpose of the JAD, analysts may also walk away from the JAD with some detailed information on what is desired of the replacement system.

Taking Part in a JAD Imagine that you are a systems analyst taking part in your first JAD. What might participating in a JAD be like? Typically, JADs are held off-site at comfortable conference facilities. On the first morning of the JAD, you and your fel- low analysts walk into a room that looks much like the one depicted in Figure 6-6. The JAD facilitator is already there; she is finishing writing the day’s agenda on a flip chart. The scribe is seated in a corner with his laptop, preparing to take notes on the day’s activities. Users and managers begin to enter in groups and seat themselves around the U-shaped table. You and the other analysts review your notes that describe what you have learned so far about the information system you are all here to discuss. The session leader opens the meeting with a welcome and a brief rundown of the agenda. The first day will be devoted to a general overview of the current system and major problems associated with it. The next two days will be devoted to an analysis of current system screens. The last two days will be devoted to analysis of reports.

FIGURE 6-6 Illustration of the typical room layout for a JAD

(Source: Based on Wood and Silver, 1995.)

Flip Chart

Laptop

Projector

Agenda 1. 2. 3. 4. 5. 6. 7. 8. 9.

Overview ... ... ... ... ... ... ...

Name Tents

M06B_VALA1629_09_GE_C06.indd 185 15/04/2020 11:45

186 PART III ANALYSIS

The session leader introduces the corporate sponsor, who talks about the orga- nizational unit and current system related to the systems analysis study and the impor- tance of upgrading the current system to meet changing business conditions. He leaves, and the JAD session leader takes over. She yields the floor to the senior analyst, who begins a presentation on key problems with the system that have already been identified. After the presentation, the session leader opens the discussion to the users and managers in the room.

After a few minutes of talk, a heated discussion begins between two users from different corporate locations. One user, who represents the office that served as the model for the original systems design, argues that the system’s perceived lack of flex- ibility is really an asset, not a problem. The other user, who represents an office that was part of another company before a merger, argues that the current system is so inflexible as to be virtually unusable. The session leader intervenes and tries to help the users isolate particular aspects of the system that may contribute to the system’s perceived lack of flexibility.

Questions arise about the intent of the original developers. The session leader asks the analysis team about their impressions of the original system design. Because these questions cannot be answered during this meeting (none of the original design- ers are present and none of the original design documents are readily available), the session leader assigns the question about intent to the “to do” list. This question becomes the first one on a flip-chart sheet of “to do” items, and the session leader gives you the assignment of finding out about the intent of the original designers. She writes your name next to the “to do” item on the list and continues with the session. Before the end of the JAD, you must get an answer to this question.

The JAD will continue like this for its duration. Analysts will make presentations, help lead discussions on form and report design, answer questions from users and managers, and take notes on what is being said. After each meeting, the analysis team will meet, usually informally, to discuss what has occurred that day and to consolidate what they have learned. Users will continue to contribute during the meetings, and the session leader will facilitate, intervening in conflicts and seeing that the group follows the agenda. When the JAD is over, the session leader and her assistants must prepare a report that documents the findings in the JAD and is circulated among users and analysts.

Using Prototyping During Requirements Determination

Prototyping is an iterative process involving analysts and users whereby a rudimentary version of an information system is built and rebuilt according to user feedback. Pro- totyping can replace the systems development life cycle or augment it. What we are interested in here is how prototyping can augment the requirements determination process.

In order to gather an initial basic set of requirements, you will still have to inter- view users and collect documentation. Prototyping, however, will enable you to quickly convert basic requirements into a working, though limited, version of the desired information system. The prototype will then be viewed and tested by the user. Typi- cally, seeing verbal descriptions of requirements converted into a physical system will prompt the user to modify existing requirements and generate new ones. For exam- ple, in the initial interviews, a user might have said that he wanted all relevant utility billing information (e.g., the client’s name and address, the service record, and pay- ment history) on a single computer display form. Once the same user sees how crowded and confusing such a design would be in the prototype, he might change his mind and instead ask to have the information organized on several screens, but with easy transitions from one screen to another. He might also be reminded of some important requirements (data, calculations, etc.) that had not surfaced during the initial interviews.

Prototyping An iterative process of systems development in which requirements are converted to a working system that is continually revised through close collaboration between an analyst and users.

M06B_VALA1629_09_GE_C06.indd 186 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 187

You would then redesign the prototype to incorporate the suggested changes (Figure 6-7). Once modified, users would again view and test the prototype. And, once again, you would incorporate their suggestions for change. Through such an itera- tive process, the chances are good that you will be able to better capture a system’s requirements.

As the prototype changes through each iteration, more and more of the design specifications for the system are captured in the prototype. The prototype can then serve as the basis for the production system in a process called evolutionary prototyping. Alternatively, the prototype can serve only as a model, which is then used as a refer- ence for the construction of the actual system. In this process, called throwaway proto- typing, the prototype is discarded after it has been used.

Evolutionary Prototyping In evolutionary prototyping, you begin by modeling parts of the target system and, if the prototyping process is successful, you evolve the rest of the system from those parts (McConnell, 1996). A life-cycle model of evolu- tionary prototyping illustrates the iterative nature of the process and the tendency to refine the prototype until it is ready to release (Figure 6-8). One key aspect of this approach is that the prototype becomes the actual production system. Because of this, you often start with those parts of the system that are most difficult and uncertain.

Although a prototype system may do a great job of representing easy-to-see aspects of a system, such as the user interface, the production system itself will per- form many more functions, several of which are transparent or invisible to the users. Any given system must be designed to facilitate database access, database integrity, system security, and networking. Systems also must be designed to support scalability, multiuser support, and multiplatform support. Few of these design specifications will be coded into a prototype. Further, as much as 90 percent of a system’s functioning is devoted to handling exceptional cases (McConnell, 1996). Prototypes are designed to handle only the typical cases, so exception handling must be added to the prototype as it is converted to the production system. Clearly, the prototype captures only part of the system requirements.

Throwaway Prototyping Unlike evolutionary prototyping, throwaway prototyp- ing does not preserve the prototype that has been developed. With throwaway proto- typing, there is never any intention to convert the prototype into a working system. Instead, the prototype is developed quickly to demonstrate some aspect of a system design that is unclear or to help users decide among different features or interface characteristics. Once the uncertainty the prototype was created to address has been reduced, the prototype can be discarded, and the principles learned from its creation and testing can then become part of the requirements determination.

FIGURE 6-7 The prototyping methodology

(Source: Based on Naumann, J. D. & Jenkins, A. M. (1982). Prototyping: The New Paradigm for Systems Development. MIS Quarterly, 6(3), 29–44.)

Identify Problem

Initial Requirements Develop

Prototype

Problems

W or

kin g

Pr ot

ot yp

New Requirements

Next Version

Convert to Operational

System

Implement and Use Prototype

Revise and Enhance Prototype

If Prototype Ine cient

M06B_VALA1629_09_GE_C06.indd 187 15/04/2020 11:45

188 PART III ANALYSIS

Prototyping is most useful for requirements determination when

• user requirements are not clear or well understood, which is often the case for totally new systems or systems that support decision making;

• one or a few users and other stakeholders are involved with the system; • possible designs are complex and require concrete form to fully evaluate; • communication problems have existed in the past between users and analysts

and both parties want to be sure that system requirements are as specific as pos- sible; and

• tools (such as form and report generators) and data are readily available to rap- idly build working systems.

Prototyping also has some drawbacks as a tool for requirements determination. These include the following:

• Prototypes have a tendency to avoid creating formal documentation of system requirements, which can then make the system more difficult to develop into a fully working system.

• Prototypes can become very idiosyncratic to the initial user and difficult to dif- fuse or adapt to other potential users.

• Prototypes are often built as stand-alone systems, thus ignoring issues of sharing data and interactions with other existing systems, as well as issues with scaling up applications.

• Checks in the SDLC are bypassed so that some more subtle, but still important, system requirements might be forgotten (e.g., security, some data entry controls, or standardization of data across systems).

RADICAL METHODS FOR DETERMINING SYSTEM REQUIREMENTS Whether traditional or contemporary, the methods for determining system require- ments that you have read about in this chapter apply to any requirements determina- tion effort, regardless of its motivation. But most of what you have learned has traditionally been applied to systems development projects that involve automating existing processes. Analysts use system requirements determination to understand current problems and opportunities, as well as to determine what is needed and desired in future systems. Typically, the current way of doing things has a large impact on the new system. In some organizations, though, management is looking for new ways to perform current tasks. These new ways may be radically different from how things are done now, but the payoffs may be enormous: Fewer people may be needed to do the same work, relationships with customers may improve dramatically, and processes may become much more efficient and effective, all of which can result in increased profits. The overall process by which current methods are replaced with radically new methods is generally referred to as business process reengineering (BPR). Although the term BPR is usually associated with a management fad that occurred in the 1990s, organizations continue to focus on business processes and how

Business process reengineering (BPR) The search for, and implementation of, radical change in business processes to achieve breakthrough improvements in products and services.

FIGURE 6-8 McConnell’s evolutionary prototyping model

Initial Concept Design and Implement Initial Prototype

Refine Prototype until Acceptable

Complete and Release Prototype

M06B_VALA1629_09_GE_C06.indd 188 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 189

they can be improved. Even if the term business process reengineering may seem dated, process orientation remains a lasting legacy of the BPR movement.

To better understand BPR, consider the following analogy. Suppose you are a successful European golfer who has tuned your game to fit the style of golf courses and weather in Europe. You have learned how to control the flight of the ball in heavy winds, roll the ball on wide open greens, putt on large and undulating greens, and aim at a target without the aid of the landscaping common on North American courses. When you come to the United States to make your fortune on the U.S. tour, you discover that incrementally improving your putting, driving accuracy, and sand shots will help, but the new competitive environment is simply not suited to your style of the game. You need to reengineer your whole approach, learning how to aim at targets, spin and stop a ball on the green, and manage the distractions of crowds and the press. If you are good enough, you may survive, but without reengineering, you will never be a winner.

Just as the competitiveness of golf forces good players to adapt their games to changing conditions, the competitiveness of our global economy has driven most companies into a mode of continuously improving the quality of their products and services (Dobyns & Crawford-Mason, 1991). Organizations realize that creatively using information technologies can yield significant improvements in most business pro- cesses. The idea behind BPR is not just to improve each business process, but, in a systems modeling sense, to reorganize the complete flow of data in major sections of an organization to eliminate unnecessary steps, achieve synergies among previously separate steps, and become more responsive to future changes. Companies such as IBM, Procter & Gamble, Walmart, and Ford are actively pursuing BPR efforts and have had great success. Yet many other companies have found difficulty in applying BPR principles (Moad, 1994). Nonetheless, BPR concepts are actively applied in both corporate strategic planning and information systems planning as a way to radically improve business processes (as described in Chapter 4).

BPR advocates suggest that radical increases in the quality of business processes can be achieved through creative application of information technologies. BPR advo- cates also suggest that radical improvement cannot be achieved by tweaking existing processes but rather by using a clean sheet of paper and asking, “If we were a new organization, how would we accomplish this activity?” Changing the way work is per- formed also changes the way information is shared and stored, which means that the results of many BPR efforts are the development of information system maintenance requests or requests for system replacement. It is likely that you will encounter or have encountered BPR initiatives in your own organization.

Identifying Processes to Reengineer

A first step in any BPR effort relates to understanding what processes to change. To do this, you must first understand which processes represent the key business pro- cesses for the organization. Key business processes are the structured set of measur- able activities designed to produce a specific output for a particular customer or market. The important aspect of this definition is that key processes are focused on some type of organizational outcome, such as the creation of a product or the delivery of a service. Key business processes are also customer focused. In other words, key business processes would include all activities used to design, build, deliver, support, and service a particular product for a particular customer. BPR efforts, therefore, first try to understand those activities that are part of the organization’s key business pro- cesses and then alter the sequence and structure of activities to achieve radical improvements in speed, quality, and customer satisfaction. The same techniques you learned to use for systems requirement determination can be used to discover and understand key business processes. Interviewing key individuals, observing activities, reading and studying organizational documents, and conducting JADs can all be used to find and fathom key business processes.

Key business processes The structured, measured set of activi- ties designed to produce a specific out- put for a particular customer or market.

M06B_VALA1629_09_GE_C06.indd 189 15/04/2020 11:45

190 PART III ANALYSIS

After identifying key business processes, the next step is to identify specific activi- ties that can be radically improved through reengineering. Hammer and Champy (1993), who are most closely identified with the term BPR and the process itself, sug- gest asking three questions to identify activities for radical change:

1. How important is the activity to delivering an outcome? 2. How feasible is changing the activity? 3. How dysfunctional is the activity?

The answers to these questions provide guidance for selecting which activities to change. Those activities deemed important, changeable, yet dysfunctional, are pri- mary candidates. To identify dysfunctional activities, they suggest you look for activities where there are excessive information exchanges between individuals, where informa- tion is redundantly recorded or needs to be rekeyed, where there are excessive inven- tory buffers or inspections, and where there is a lot of rework or complexity. Many of the tools and techniques for modeling data, processes, events, and logic within the IS development process are also being applied to model business processes within BPR efforts (see Davenport, 1993). Thus, the skills of a systems analyst are often central to many BPR efforts.

Disruptive Technologies

Once key business processes and activities have been identified, information technologies must be applied to radically improve business processes. To do this, Hammer and Champy (1993) suggest that organizations think “inductively” about information technology. Induction is the process of reasoning from the specific to the general, which means that managers must learn the power of new technolo- gies and think of innovative ways to alter the way work is done. This is contrary to deductive thinking, where problems are first identified and solutions are then formulated.

Hammer and Champy suggest that managers especially consider disruptive tech- nologies when applying deductive thinking. Disruptive technologies are those that enable breaking long-held business rules that inhibit organizations from making radi- cal business changes. For example, Procter & Gamble (P&G), the huge consumer products company, uses information technology to “innovate innovation” (Teresko, 2004). Technology helps different organizational units work together seamlessly on new products. P&G also uses computer simulations to expedite product design and test potential products with consumers early in the design process. Table 6-6 shows

Disruptive technologies Technologies that enable breaking long- held business rules that inhibit organi- zations from making radical business changes.

Rule Disruptive Technology

Information can appear in only one place at a time.

Distributed databases allow the sharing of information.

Businesses must choose between centraliza- tion and decentralization.

Advanced telecommunications networks can support dynamic organizational structures.

Managers must make all decisions. Decision-support tools can aid nonmanagers. Field personnel need offices where they

can receive, store, retrieve, and transmit information.

Wireless data communication and portable computers provide a “virtual” office for workers.

The best contact with a potential buyer is personal contact.

Interactive communication technologies allow complex messaging capabilities.

You have to find out where things are. Automatic identification and tracking technol- ogy knows where things are.

Plans get revised periodically. High-performance computing can provide real-time updating.

TABLE 6-6 Long-Held Organizational Rules That Are Being Eliminated through Disruptive Technologies

M06B_VALA1629_09_GE_C06.indd 190 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 191

several long-held business rules and beliefs that constrain organizations from making radical process improvements. For example, the first rule suggests that information can only appear in one place at a time. However, the advent of distributed data- bases (see Chapter 12) and pervasive wireless networking have “disrupted” this long- held business belief.

REQUIREMENTS DETERMINATION USING AGILE METHODOLOGIES You’ve already learned about many different ways to determine the requirements for a system. Yet new methods and techniques are constantly being developed. Three more requirements determination techniques are presented in this section. The first is continual user involvement in the development process, a technique that works especially well with small and dedicated development teams. The second approach is a JAD-like process called Agile Usage-Centered Design. The third approach is the Planning Game, which was developed as part of eXtreme Programming.

Continual User Involvement

In Chapter 1, you read about the criticisms of the traditional waterfall SDLC. One of those criticisms was that the waterfall SDLC allowed users to be involved in the development process only in the early stages of analysis. Once requirements had been gathered from them, the users were not involved again in the process until the system was being installed and they were asked to sign off on it. Typically, by the time the users saw the system again, it was nothing like what they had imagined. Also, given how their business processes had changed since analysis ended, the system most likely did not adequately address user needs. This view of the traditional waterfall SDLC and user involvement is a stereotype of the process, and it does not describe every systems development project that used the waterfall model. However, limited user involvement has been common enough to be perceived as a real and serious problem in systems development.

One approach to the problem of limited user involvement is to involve the users continually, throughout the entire analysis and design process. Such an approach works best when development can follow the analysis–design–code–test cycle favored by the agile methodologies (Figure 6-9), because the user can provide information on requirements and then watch and evaluate as those requirements are designed, coded, and tested. This iterative process can continue through sev- eral cycles, until most of the major functionality of the system has been developed. Extensive involvement of users in the analysis and design process is a key part of many agile approaches.

Continual user involvement was a key aspect of the success of Boeing’s Wire Design and Wire Install system for the 757 aircraft (Bedoll, 2003). The system was intended to support engineers who customize plane configurations for customers, allowing them to analyze all 50,000 wires that can possibly be installed on a 757. A previous attempt at building a similar system took over three years, and the resulting system was never used. The second attempt, relying on agile methodologies, resulted in a system that was in production after only six weeks. One of the keys to success was a user liaison who spent half of his time with the small development team and half with the other end users. In addition to following the analysis–design–code–test cycle, the team also had weekly production releases. The user liaison was involved every step of the way. Obviously, for such a requirements determination to succeed, the user who works with the development team must be very knowledgeable, but he or she must also be in a position to give up his or her normal business responsibilities in order to become heavily involved in the system’s development.

M06B_VALA1629_09_GE_C06.indd 191 15/04/2020 11:45

192 PART III ANALYSIS

Agile Usage-Centered Design

Continual user involvement in systems development is an excellent way to ensure that requirements are captured accurately and immediately implemented in system design. However, such constant interaction works best when the development team is small, as was the case in the Boeing example. Also, it is not always possible to have continual access to users for the duration of a development project. Thus, agile developers have come up with other means for effectively involving users in the requirements deter- mination process. One such method is called Agile Usage-Centered Design, originally developed by Larry Constantine (2002) and adapted for agile methodologies by Jeff Patton (2002). Patton describes the process in nine steps, which we have adapted and presented as eight steps in Table 6-7.

Notice how similar the overall process is to a JAD meeting. All of the experts are gathered together and work with the help of the facilitator. What is unique about the Agile Usage-Centered Design is the process that supports it, which focuses on user roles, user goals, and the tasks necessary to achieve those goals. Then, tasks are grouped and turned into paper-and-pencil prototypes before the meeting is over. Requirements captured from users and developers are captured as prototyped system screens. Patton (2002) believes that the two most effective aspects of this approach are the venting session, which lets everyone get their complaints out in the open, and the use of 3 × 5 cards, which serve as very effective communication tools. As with any analysis and design process or technique, however, Agile Usage-Centered Design will not work for every project or every company.

The Planning Game from eXtreme Programming

You read about eXtreme Programming in Chapter 1, and you know that it is an approach to software development put together by Kent Beck (Beck & Andres, 2004). You also know that it is distinguished by its short cycles, its incremental plan- ning approach, its focus on automated tests written by programmers and customers to monitor the process of development, and its reliance on an evolutionary approach to development that lasts throughout the lifetime of the system. One of the key empha- ses of eXtreme Programming is its use of two-person programming teams and having a customer on-site during the development process. The relevant parts of eXtreme Programming that relate to requirements determination are (1) how planning, anal- ysis, design, and construction are all fused together into a single phase of activity and (2) its unique way of capturing and presenting system requirements and design

FIGURE 6-9 The iterative analysis–design–code–test cycle

Code

Analyze

Test Design

M06B_VALA1629_09_GE_C06.indd 192 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 193

specifications. All phases of the life cycle converge into a series of activities based on the basic processes of coding, testing, listening, and designing.

What is of interest here, however, is the way requirements and specifications are dealt with. Both of these activities take place in what Beck calls the “Planning Game.” The Planning Game is really just a stylized approach to development that seeks to maximize fruitful interaction between those who need a new system and those who build it. The players in the Planning Game, then, are Business and Devel- opment. Business is the customer and is ideally represented by someone who knows the processes to be supported by the system being developed. Development is rep- resented by those actually designing and constructing the system. The game pieces are what Beck calls “Story Cards.” These cards are created by Business and contain a description of a procedure or feature to be included in the system. Each card is dated and numbered and has space on it for tracking its status throughout the development effort.

The Planning Game has three phases: exploration, commitment, and steering (Figure 6-10). In exploration, Business creates a Story Card for something it wants the new system to do. Development responds with an estimation of how long it would take to implement the procedure. At this point, it may make sense to split a Story Card into multiple Story Cards, as the scope of features and procedures becomes more clear during discussion. In the commitment phase, Business sorts Story Cards into three stacks: one for essential features, one for features that are not essential but would still add value, and one for features that would be nice to have. Develop- ment then sorts Story Cards according to risk, based on how well they can estimate the time needed to develop each feature. Business then selects the cards that will be included in the next release of the product. In the final phase, steering, Business has a chance to see how the development process is progressing and to work with Development to adjust the plan accordingly. Steering can take place as often as once every three weeks.

The Planning Game between Business and Development is followed by the Iteration Planning Game, played only by programmers. Instead of Story Cards,

1. Gather a group of people, including analysts, users, programmers, and testing staff, and sequester them in a room to collaborate on this design. Include a facilitator who knows this process.

2. Give everyone a chance to vent about the current system and to talk about the features everyone wants in the new system. Record all of the complaints and suggestions for change on whiteboards or flip charts for everyone to see.

3. Determine what the most important user roles would be. Determine who will be using the system and what their goals are for using the system. Write the roles on 3 × 5 cards. Sort the cards so that similar roles are close to each other. Patton (2002) calls this a role model.

4. Determine what tasks user roles will have to complete in order to achieve their goals. Write these down on 3 × 5 cards. Order tasks by importance and then by frequency. Place the cards together based on how similar the tasks are to each other. Patton calls this a task model.

5. Task cards will be grouped together on the table based on their similarity. Grab a stack of cards. This is called an interaction context.

6. For each task card in the interaction context, write a description of the task directly on the task card. List the steps that are necessary to complete the task. Keep the descriptions conversational to make them easy to read. Simplify.

7. Treat each stack as a tentative set of tasks to be supported by a single aspect of the user interface, such as a screen, page, or dialogue, and create a paper-and-pencil prototype for that part of the interface. Show the basic size and placement of the screen components.

8. Take on a user role and step through each task in the interaction context as modeled in the paper-and-pencil prototype. Make sure the user role can achieve its goals by using the prototype. Refine the prototype accordingly.

TABLE 6-7 Steps in the Agile Usage-Centered Design Method for Requirements Determination

M06B_VALA1629_09_GE_C06.indd 193 15/04/2020 11:45

194 PART III ANALYSIS

programmers write Task Cards, which are based on Story Cards. Typically, several Task Cards are generated for each Story Card. The Iteration Planning Game has the same three phases as the Planning Game: exploration, commitment, and steer- ing. During exploration, programmers convert Story Cards into Task Cards. During commitment, they accept responsibility for tasks and balance their workloads. Dur- ing steering, the programmers write the code for the feature and test it. If it works, they integrate the feature into the product being developed. The Iteration Planning Game takes place during the time intervals between steering phase meetings in the Planning Game.

You can see how the Planning Game is similar in some ways to Agile Usage- Centered Design. Both rely on participation by users, rely on cards as communica- tion devices, and focus on tasks the system being designed is supposed to perform. Although these approaches differ from some of the more traditional ways of determin- ing requirements, such as interviews and prototyping, many of the core principles are the same. Customers, or users, remain the source for what the system is supposed to do. Requirements are still captured and negotiated. The overall process is still docu- mented, although the extent and formality of the documentation may differ. Given the way requirements are identified and recorded and broken down from stories to tasks, design specifications can easily incorporate the characteristics of quality require- ments: completeness, consistency, modifiability, and traceability.

ELECTRONIC COMMERCE APPLICATIONS: DETERMINING SYSTEM REQUIREMENTS Determining system requirements for an electronic commerce application is no different than the process followed for other applications. In the last chapter, you read how PVF’s management began the WebStore project, a project to sell furniture products over the Internet. In this section, we examine the process fol- lowed by PVF to determine system requirements and highlight some of the issues and capabilities that you may want to consider when developing your own Internet- based application.

FIGURE 6-10 eXtreme Programming’s Planning Game

(Sources: Top to bottom: George Rudy/Shutterstock; Rawpixel. com/ Shutterstock; Denis Simonov/ Shutterstock)

COMMITMENT Business sorts Stories by necessity. Development sorts Stories by risk.

Business chooses Stories for next release.

STEERING Business reviews progress.

Business and Development adjust plan.

EXPLORATION Business writes a Story Card.

Development provides an estimate.

M06B_VALA1629_09_GE_C06.indd 194 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 195

Determining System Requirements for Pine Valley Furniture’s WebStore

To collect system requirements as quickly as possible, Jim and Jackie decided to hold a three-day JAD session. In order to get the most out of these sessions, they invited a broad range of people, including representatives from Sales and Marketing, Operations, and Information Systems. Additionally, they asked an experienced JAD facilitator, Cheri Morris, to conduct the session. Together with Cheri, Jim and Jackie developed a very ambitious and detailed agenda for the session. Their goal was to collect requirements on the following items:

• System Layout and Navigation Characteristics • WebStore and Site Management System Capabilities • Customer and Inventory Information • System Prototype Evolution

In the remainder of this section, we briefly highlight the outcomes of the JAD session.

System Layout and Navigation Characteristics As part of the process of prepar- ing for the JAD session, all participants were asked to visit several established retail Websites, including www.amazon.com, www.landsend.com, www.sony.com, and www .pier1.com. At the JAD session, participants were asked to identify characteristics of these sites that they found appealing and those characteristics that they found cumber- some. This allowed participants to identify and discuss those features that they wanted the WebStore to possess. The outcomes of this activity are summarized in Table 6-8.

WebStore and Site Management System Capabilities After agreeing to the general layout and navigational characteristics of the WebStore, the session then turned its focus to the basic system capabilities. To assist in this process, systems ana- lysts from the Information Systems Department developed a draft skeleton of the WebStore. This skeleton was based on the types of screens common to and capabili- ties of popular retail Websites. For example, many retail Websites have a “shopping cart” feature that allows customers to accumulate multiple items before checking out rather than buying a single item at a time. After some discussion, the participants agreed that the system structure shown in Table 6-9 would form the foundation for the WebStore system.

In addition to the WebStore capabilities, members of the Marketing and Sales Department described several reports that would be necessary to effectively manage customer accounts and sales transactions. In addition, the department wants to be able to conduct detailed analyses of site visitors, sales tracking, and so on. Members of the Operations Department expressed a need to easily update the product catalog. These collective requests and activities were organized into a system design structure called the Site Management System, which is summarized in Table 6-9. The structures of both the WebStore and Site Management Systems will be given to the Information Systems Department as the baseline for further analysis and design activities.

PINE VALLEY FURNITURE

Layout and Design • Navigation menu and logo placement should remain consistent throughout the entire site (this allows users to maintain familiarity while using the site and minimizes users who get “lost” in the site)

• Graphics should be lightweight to allow for quick page display • Text should be used over graphics whenever possible

Navigation • Any section of the store should be accessible from any other section via the navigation menu

• Users should always be aware of what section they are currently in

TABLE 6-8 Desired Layout and Navigation Feature of WebStore

M06B_VALA1629_09_GE_C06.indd 195 15/04/2020 11:45

http://www.amazon.com

http://www.landsend.com

http://www.sony.com

www.pier1.com

196 PART III ANALYSIS

Customer and Inventory Information The WebStore will be designed to support the furniture purchases of three distinct types of customers:

• Corporate customers • Home office customers • Student customers

To effectively track the sales to these different types of customers, distinct information must be captured and stored by the system. Table 6-10 summarizes this information for each customer type that was identified during the JAD session. In addition to the cus- tomer information, information about the products ordered must also be captured and stored. Orders reflect the range of product information that must be specified to execute a sales transaction. Thus, in addition to capturing the customer information, product and sales data must also be captured and stored. Table 6-10 lists the results of this analysis.

System Prototype Evolution As a final activity, the JAD participants, benefiting from extensive input from the Information Systems staff, discussed how the system implementation should evolve. After completing analysis and design activities, it was agreed that the system implementation should progress in three main stages so that changes to the requirements could be more easily identified and implemented. Table 6-11 summarizes these stages and the functionality that would be incorporated at each stage of the implementation.

WebStore System Site Management System

❑❑ Main Page • Product Line (catalog)

✓ Desks ✓ Chairs ✓ Tables ✓ File Cabinets

• Shopping Cart • Checkout • Account Profile • Order Status/History • Customer Comments

❑❑ Company Info ❑❑ Feedback ❑❑ Contact Information

❑❑ User Profile Manager ❑❑ Order Maintenance Manager ❑❑ Content (catalog) Manager ❑❑ Reports • Total Hits • Most Frequent Page Views • Users/Time of Day • Users/Day of Week • Shoppers Not Purchasing (used shopping cart—did not

checkout) • Feedback Analysis

TABLE 6-9 System Structure of the WebStore and Site Management Systems

Corporate Customer Home Office Customer Student Customer

• Company Name • Company Address • Company Phone • Company Fax • Company Preferred Shipping

Method • Buyer Name • Buyer Phone • Buyer E-Mail

• Name • Doing Business as

(company name) • Address • Phone • Fax • E-Mail

• Name • School • Address • Phone • E-Mail

Inventory Information • SKU • Name • Description

• Finished Product Size • Finished Product Weight • Available Materials

• Available Colors • Price • Lead Time

TABLE 6-10 Customer and Inventory Information for WebStore

M06B_VALA1629_09_GE_C06.indd 196 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 197

At the conclusion of the JAD session there was a good feeling among the partici- pants. All felt that a lot of progress had been made and that clear requirements had been identified. With these requirements in hand, Jim and the Information Systems staff could now begin to turn these lists of requirements into formal analysis and design specifications. To show how information flows through the WebStore, data flow diagrams (Chapter 7) will be produced. To show a conceptual model of the data used within WebStore, an entity-relationship diagram (Chapter 8) will be produced. Both of these analysis documents will become part of the foundation for detailed system design and implementation.

Stage 1—Basic Functionality: • Simple catalog navigation; two products per section—limited attributes set • 25 sample users • Simulated credit card transaction • Full shopping cart functionality Stage 2—Look and Feel: • Full product attribute set and media (images, video)—commonly referred to as the “prod-

uct data catalog” • Full site layout • Simulated integration with Purchasing Fulfillment and Customer Tracking systems Stage 3—Staging/Preproduction: • Full integration with Purchasing Fulfillment and Customer Tracking systems • Full credit card processing integration • Full product data catalog

TABLE 6-11 Stages of System Implementation of WebStore

SUMMARY

As we saw in Chapter 1, there are two subphases in the sys- tems analysis phase of the systems development life cycle: requirements determination and requirements structur- ing. Chapter 6 has focused on requirements determina- tion, the gathering of information about current systems and the need for replacement systems. Chapters 7 and 8 will address techniques for structuring the requirements elicited during requirements determination.

For requirements determination, the traditional sources of information about a system include interviews; observation; group interviews; and procedures, forms, and other useful documents. Often many or even all of these sources are used to gather perspectives on the adequacy of current systems and the requirements for replacement systems. Each form of information collection has its advan- tages and disadvantages. Selecting the methods to use depends on the need for rich or thorough information, the time and budget available, the need to probe deeper once initial information is collected, the need for confidentiality for those providing assessments of system requirements, the desire to get people involved and committed to a proj- ect, and the potential audience from which requirements should be collected.

Both open- and closed-ended questions can be posed during interviews. In either case, you must be very precise in

formulating a question in order to avoid ambiguity and to ensure a proper response. During observation you must try not to intrude or interfere with normal business activities so that the people being observed do not modify their activities from normal processes. The results of all requirements-gathering methods should be compared because there may be differ- ences between the formal or official system and the way peo- ple actually work, the informal system.

You also learned about contemporary methods to col- lect requirements information, many of which make use of information systems. JAD begins with the idea of the group interview and adds structure and a JAD session leader to it. Typical JAD participants include the session leader, a scribe, key users, managers, a sponsor, and systems analysts. JAD sessions are usually held off-site and may last as long as one week.

Systems analysis routinely relies on prototyping to support requirements determination. As part of the proto- typing process, users and analysts work closely together to determine requirements that the analyst then builds into a model. The analyst and user then work together to revise the model until it is close to what the user desires.

BPR is an approach to radically changing business processes. BPR efforts are a source of new information requirements. Information systems and technologies

M06B_VALA1629_09_GE_C06.indd 197 15/04/2020 11:45

198 PART III ANALYSIS

often enable BPR by allowing an organization to elimi- nate or relax constraints on traditional business rules. Agile requirements determination techniques are another contemporary approach to figuring out what a new or improved system is supposed to do. Continual customer involvement relies on high levels of user participation. Agile Usage-Centered Design and the Planning Game rely on novel interactions between users and developers to uncover basic tasks and features the new system should include.

Most of the same techniques used for requirements determination for traditional systems can also be fruit- fully applied to the development of online applications. Accurately capturing requirements in a timely manner for

Internet applications is just as important as for more tradi- tional systems.

The result of requirements determination is a thor- ough set of information, including some charts, that describes the current systems being studied and the need for new and different capabilities to be included in the replacement systems. This information, however, is not in a form that makes analysis of true problems and clear statements of new features possible. Thus, you and other analysts will study this information and structure it into standard formats suitable for identifying problems and unambiguously describing the specifications for new sys- tems. We discuss a variety of popular techniques for struc- turing requirements in the next two chapters.

KEY TERMS

6.1 Business process reengineering (BPR)

6.2 Closed-ended questions 6.3 Disruptive technologies 6.4 Formal system

6.5 Informal system 6.6 JAD session leader 6.7 Joint Application Design ( JAD) 6.8 Key business processes 6.9 Nominal Group Technique (NGT)

6.10 Open-ended questions 6.11 Prototyping 6.12 Scribe

REVIEW QUESTIONS 6.13 Explain the three essential views of current and replacement

information systems.

6.14 Describe the characteristics of a good systems analyst.

6.15 What are the guidelines for effectively interviewing someone?

6.16 An analyst comes to you to ask for some assistance with inter- view guidelines. What do you tell the analyst?

6.17 Describe the difference between formal and informal systems.

6.18 What is the Nominal Group Technique? How is it beneficial to requirements determination?

6.19 List at least four types of information an analyst can locate in documents during the analysis phase.

6.20 Describe the contemporary methods for collection of sys- tems requirements.

6.21 Describe the typical participants in a JAD.

Match each of the key terms above with the definition that best fits it.

____ Questions in interviews that ask those responding to choose from among a set of specified responses.

____ Technologies that enable breaking long-held business rules that inhibit organizations from making radical business changes.

____ A facilitated process that supports idea generation by groups. At the beginning of the process, group members work alone to generate ideas. The ideas are then pooled under the guid- ance of a trained facilitator.

____ The structured, measured set of activities designed to pro- duce a specific output for a particular customer or market.

____ An iterative process in which requirements are converted to a working system that is continually revised through orga- nized user collaboration.

____ The official way a system works as described in organizational documentation.

____ The search for, and implementation of, radical change in business processes to achieve breakthrough improvements in products and services.

____ The way a system actually works.

____ The person who makes detailed notes of the happenings at a JAD session.

____ Questions in interviews that have no prespecified answers.

____ The trained individual who plans and leads JAD sessions.

____ A structured process in which users, managers, and analysts work together for several days in a series of meetings to clarify or review requirements.

M06B_VALA1629_09_GE_C06.indd 198 15/04/2020 11:45

CHAPTER 6 DeteRmining SyStem RequiRementS 199

FIELD EXERCISES 6.32 Effective interviewing is not something that you can learn

from just reading about it. You must first do some interview- ing, preferably a lot of it, because interviewing skills improve only with experience. To get an idea of what interviewing is like, try the following: Find three friends or classmates to help you complete this exercise. Organize yourselves into pairs. Write down a series of questions you can use to find out about a job your partner now has or once held. You decide what questions to use, but at a minimum, you must find out the following: (1) the job’s title; (2) the job’s responsibilities; (3) who your partner reported to; (4) who reported to your partner, if anyone did; and (5) what infor- mation your partner used to do his or her job. At the same time, your partner should be preparing questions to ask you about a job you had. Now conduct the interview. Take care- ful notes. Organize what you find into a clear form that another person could understand. Now repeat the process, but this time, your partner interviews you.

While the two of you have been interviewing each other, your two other friends should have been doing the same thing. When all four of you are done, switch partners and repeat the entire process. When you are all done, each of you should have interviewed two people, and each of you should have been interviewed by two people. Now, you and the person who interviewed your original partner should compare your findings. Most likely, your findings will not be identical to what the other person found. If your findings differ, discover why. Did you use the same questions? Did

the other person do a more thorough job of interviewing your first partner because it was the second time he or she had conducted an interview? Did you both ask follow-up questions? Did you both spend about the same amount of time on the interview? Prepare a report with this person about why your findings differed. Now find both of the people who interviewed you. Does one set of findings dif- fer from the other? If so, try to figure out why. Did one of them (or both of them) misrepresent or misunderstand what you told them? Each person should now write a report on their experience, using it to explain why interviews are sometimes inconsistent and inaccurate and why having two people interview someone on a topic is better than having just one person do the interview. Explain the implications of what you have learned for the requirements determination subphase of the systems development life cycle.

6.33 Choose a work team at your work or university and interview them in a group setting. Ask them about their current sys- tem (whether computer-based or not) for performing their work. Ask each of them what information they use and/or need and from where/whom they get it. Was this a useful method for you to learn about their work? Why or why not? What comparative advantages does this method provide as compared to one-on-one interviews with each team mem- ber? What comparative disadvantages?

6.34 For the same work team you used in Field Exercise 6.33, examine copies of any relevant written documentation (e.g., written procedures, forms, reports, system documentation).

PROBLEMS AND EXERCISES 6.22 Find and review related articles from the popular press

and from the academic research literature on prototyping. Summarize the two articles and, based on your reading, pre- pare a list of arguments for why this type of system would be useful in a JAD session. Also address the limits for applying this type of system in a JAD setting.

6.23 Compare and contrast the traditional and contemporary methods for determining requirements in system analy- sis and design. List the situations where each method is suitable. Highlight some of the distinct features of these methods.

6.24 Summarize the problems that arise with open-ended ques- tions, and explain why closed-ended questions can be a suit- able alternative. List the groundwork an interviewer has to do to frame close-ended questions.

6.25 Suppose you have to interview a systems analyst to collect information about designing a management information system for your institute. Prepare a checklist of the guide- lines you will follow in the interview.

6.26 In which situations can prototyping be applied? List the pros and cons of evolutionary prototyping and throwaway pro- totyping. Comment on the applicability of the prototyping method, and list the problems associated with them.

6.27 Review academic literature on the Nominal Group Tech- nique. Pick a research paper and find out which situation

this technique was used for and whether there were any limitations to the technique. Note down the key aspects of the technique as well.

6.28 Visit the library of your institute and read different case studies on an observation method similar to the case in the box “Lost Soft Drink Sales” in this chapter. Prepare a report summarizing the key points of the case studies you have read.

6.29 Imagine that your department needs to design a library information system, and your course instructor has asked you to determine the system requirements. Discuss with a partner which of the traditional methods of determining system requirements you would apply, and why (refer to Table 6-2).

6.30 Suppose you want to open a coffee shop chain and require an information system for managing the sales. Organize a JAD session in your class. You are the user, your course teacher is the systems analyst, some students are appointed to play the other roles, and others act as the audience. Discuss and list the different system requirements for con- structing the information system.

6.31 Referring to Table 6-6, search the Internet to get informa- tion on how organizations are using disruptive technologies to change the conventional rules of the business. Explain using an example.

M06B_VALA1629_09_GE_C06.indd 199 15/04/2020 11:45

200 PART III ANALYSIS

REFERENCES Beck, K., & Andres, C. (2004). eXtreme Programming eXplained.

Upper Saddle River, NJ: Addison-Wesley. Bedoll, R. (2003, August). A tale of two projects: How ‘agile’ meth-

ods succeeded after ‘traditional’ methods had failed in a crit- ical system-development project. In Proceedings of 2003 XP/ Agile Universe Conference (pp. 25–34). Berlin: Springer-Verlag, 25–34.

Constantine, L. (2002, August/September). Process agility and software usability: Toward lightweight usage-centered design. Information Age. Retrieved February 12, 2004 from http:// www.infoage.idg.com.au/index.php?id=244792583.

Davenport, T. H. (1993). Process innovation: Reengineering work through information technology. Boston: Harvard Business School Press.

Dobyns, L., & Crawford-Mason, C. (1991). Quality or else. Boston: Houghton-Mifflin.

Hammer, M. (1996). Beyond reengineering. New York: Harper Business.

Hammer, M., & Champy, J. (1993). Reengineering the corporation. New York: Harper Business.

McConnell, S. (1996). Rapid development. Redmond, WA: Microsoft Press.

Mintzberg, H. (1973). The nature of managerial work. New York: Harper & Row.

Moad, J. (1994). After reengineering: Taking care of business. Datamation, 40(20), 40–44.

Naumann, J. D., & Jenkins, A. M. (1982). Prototyping: The new paradigm for systems development. MIS Quarterly, 6(3), 29–44.

Patton, J. (2002). Designing requirements: Incorporating usage- centered design into an agile SW development process. In D. Wells and L. Williams (eds.), Extreme Programming and Agile Methods – XP/Agile Universe 2002, LNCS 2418 (pp. 1–12). Ber- lin: Springer-Verlag.

Teresko, J. (2004). P&G’s secret: Innovating innovation. Industry Week, 253(12), 27–34.

Wood, J., & Silver, D. (1995). Joint application development (2nd ed.). New York: John Wiley & Sons.

Are any of these forms of written documentation missing? Why? With what consequences? To what extent does this written documentation fit with the information you received in the group interview?

6.35 Interview a systems analyst to find out what type of busi- ness form they use for system requirements analysis. Which specific business form does the systems analyst prefer? Explain in detail by what criteria a particular business form is selected, and explain how different business forms help them understand future system requirements.

6.36 Survey the literature on JAD in the academic and popular press and determine the “state of the art.” How is JAD being used to help determine system requirements? Is using JAD for this process beneficial? Why or why not? Present your analysis to the IS manager at your work or at your university.

Does your analysis of JAD fit with his or her perception? Why or why not? Is he or she currently using JAD, or a JAD- like method, for determining system requirements? Why or why not?

6.37 With the help of other students or your instructor, contact someone in an organization who conducts JAD sessions. Interview the different participants of JAD sessions and find out what role each of them plays. Is the role played by them different from the one explained in this chapter?

6.38 Find an organization that uses the planning game approach (Figure 6-10) to deal with requirements and specifications. What are the different phases they follow in the planning game? What role do the two players play in each phase? Which phase, according to them, is the most challenging, and why?

M06B_VALA1629_09_GE_C06.indd 200 15/04/2020 11:45

http://www.infoage.idg.com.au/index.php?id=244792583

PE TABLE 6-1 Requirements and Constraints for Petrie’s Customer Loyalty Project

Requirements:

• Effective customer incentives – System should be able to effectively store customer activity and convert to rewards and other incentives

• Easy for customers to use – Interface should be intuitive for customer use

• Proven performance – System as proposed should have been used successfully by other clients

• Easy to implement – Implementation should not require out- side consultants or extraordinary skills on the part of our staff or require specialized hardware

• Scalable – System should be easily expandable as number of participating customers grows

• Vendor support – Vendor should have proven track record of reliable support and infrastructure in place to provide it

Constraints:

• Cost to buy – Licenses for one year should be under $500,000

• Cost to operate – Total operating costs should be no more than $1 million per year

• Time to implement – Duration of implementation should not exceed three months

• Staff to implement – Implementation should be successful with the staff we have and with the skills they already possess

PETRIE ELECTRONICS

Chapter 6: Determining System Requirements

Jim Watanabe, the project manager, thought that although the customer loyalty project at Petrie Electronics had gone slowly at first, the past few weeks had been fast-paced and busy. He spent much of his time planning and conduct- ing interviews with key stakeholders inside the company. He also worked with the marketing group to put together some focus groups made up of loyal customers, to get some ideas about what they would value in a customer loyalty pro- gram. Jim had also spent some time studying customer loy- alty programs at other big retail chains and those in other industries as well, such as the airlines, which are known for their extensive customer loyalty programs. As project manager, he also supervised the efforts of his team mem- bers. Together, they collected a great deal of data. Jim had just finished creating a high-level summary of the infor- mation into a table he could send to his team members (PE Table 6-1).

From the list of requirements, it was clear that he and his team did not favor building a system from scratch in-house. Jim was glad that the team felt that way. Not only was build- ing a system like this in-house an antiquated practice, it was

expensive and time consuming. As nice as it might have been to develop a unique system just for Petrie, there was little point in reinventing the wheel. The IT staff would custom- ize the system interface, and there would be lots of work for Sanjay’s staff in integrating the new system and its related components with Petrie’s existing systems, but the core of the system would have already been developed by someone else.

Just as he was finishing the e-mail he would send to his team about the new system’s requirements and constraints, he received a new message from Sanjay. He had asked Sanjay to take the lead in scouting out existing customer loyalty systems that Petrie could license. Sanjay conducted a preliminary investigation that was now complete. His e-mail contained the descriptions of three of the systems he found and studied (PE Table 6-2). Obviously, Jim and his team would need to have a lot more information about these alternatives, but Jim was intrigued by the possibilities. He sent a reply to Sanjay, asking him to pass the alterna- tives on to the team and to prepare a briefing for the team that would include more detailed information about each alternative.

PE TABLE 6-2 Alternatives for Petrie’s Customer Loyalty Project

Alternative A: Data warehousing-centered system designed and licensed by Standard Basic Systems Inc. (SBSI). The data warehousing tools at the heart of the system were designed and developed by SBSI and work with standard relational DBMS and relational/ OO hybrid DBMS. The SBSI tools and approach have been used for many years and are well known in the industry, but SBSI-certified staff are essential for implementation, operation, and maintenance. The license is relatively expensive. The cus- tomer loyalty application using the SBSI data warehousing tools is an established application, used by many retail businesses in other industries. Alternative B: Customer relationship management–centered system designed and licensed by XRA Corporation. XRA is a pioneer in CRM sys- tems, so its CRM is widely recognized as an industry leader. The system includes tools that support customer loyalty programs. The CRM system itself is large and complex, but pricing in this proposal is based only on modules used for the customer loy- alty application. Alternative C: Proprietary system designed and licensed by Nova Innovation Group, Inc. The system is relatively new and leading edge, so it has only been implemented in a few sites. The vendor is truly innovative but small and inexperienced. The customer interface, designed for a standard Web browser, is stunning in its design and is extremely easy for customers to use to check on their loyalty program status. The software runs remotely, in the “cloud,” and data related to the customer loyalty program would be stored in the cloud too.

CHAPTER 6 DeteRmining SyStem RequiRementS 201

M06B_VALA1629_09_GE_C06.indd 201 15/04/2020 11:45

Case Questions

6.39 What do you think are the sources of the information Jim and his team collected? How do you think they collected all of that information?

6.40 Examine PE Table 6-1. Are there any requirements or constraints that you can think of that were over- looked? List them.

6.41 If you were looking for alternative approaches for Pet- rie’s customer loyalty program, where would you look for information? Where would you start? How would you know when you were done?

6.42 Using the Web, find three customizable customer loy- alty program systems being sold by vendors. Create a table like PE Table 6-2 that compares them.

6.43 Why shouldn’t Petrie’s staff build their own unique system in-house?

202 PART III ANALYSIS

M06B_VALA1629_09_GE_C06.indd 202 15/04/2020 11:45

concepts related to data flow diagrams are also presented: balancing and decomposition. Toward the end of the chap- ter, we present the use of data flow diagrams as part of the analysis of an information system and as a tool for support- ing business process reengineering. You will also learn how process modeling is important for the analysis of electronic commerce applications. Also in this chapter, you will learn about decision tables. Decision tables allow you to repre- sent the conditional logic that is part of some data flow diagram processes. Finally, at the end of the chapter, we have included special sections on an object-oriented devel- opment approach to process and logic modeling. These sections cover use cases, activity diagrams, and sequence diagrams. We have also included an appendix on business process modeling.

PROCESS MODELING Process modeling involves graphically representing the functions, or processes, that capture, manipulate, store, and distribute data between a system and its environment and between components within a system. A common

In the last chapter, you learned of various methods that systems analysts use to collect the information neces- sary to determine information systems requirements. In this chapter, our focus will be on one tool that is used to coherently represent the information gathered as part of requirements determination—data flow diagrams. Data flow diagrams enable you to model how data flow through an information system, the relationships among the data flows, and how data come to be stored at specific loca- tions. Data flow diagrams also show the processes that change or transform data. Because data flow diagrams concentrate on the movement of data between processes, these diagrams are called process models.

As its name indicates, a data flow diagram is a graphi- cal tool that allows analysts (and users, for that matter) to depict the flow of data in an information system. The sys- tem can be physical or logical, manual or computer-based. In this chapter, you will learn how to draw and revise data flow diagrams. We present the basic symbols used in such diagrams and a set of rules that govern how these diagrams are drawn. You will also learn about what to do and what not to do when drawing data flow diagrams. Two important

7.4 balance higher-level and lower-level data flow diagrams;

7.5 use data flow diagrams as a tool to support the analysis of information systems;

7.6 discuss process modeling for electronic commerce applications; and

7.7 use decision tables to represent the logic of choice in conditional statements.

Learning Objectives After studying this chapter, you should be able to

7.1 understand the logical modeling of processes by studying examples of data flow diagrams;

7.2 draw data flow diagrams following specific rules and guidelines that lead to accurate and well- structured process models;

7.3 decompose data flow diagrams into lower-level diagrams;

Structuring System Process Requirements7

Introduction

203

M07_VALA1629_09_GE_C07.indd 203 08/04/2020 16:40

204 PART III ANALYSIS

form of a process model is a data flow diagram (DFD). Over the years, several dif- ferent tools have been developed for process modeling. In this chapter, we focus on DFDs, the traditional process modeling technique of structured analysis and design and one of the techniques most frequently used today for process modeling. We also introduce you to decision tables, a well-known way to model the conditional logic contained in many DFD processes.

Modeling a System’s Process for Structured Analysis

As Figure 7-1 shows, the analysis phase of the systems development life cycle has two subphases: requirements determination and requirements structuring. The analy- sis team enters the requirements structuring phase with an abundance of informa- tion gathered during the requirements determination phase. During requirements structuring, you and the other team members must organize the information into a meaningful representation of the information system that currently exists and of the requirements desired in a replacement system. In addition to modeling the process- ing elements of an information system and how data are transformed in the system, you must also model the processing logic (decision tables) and the structure of data within the system (Chapter 8). For traditional structured analysis, a process model is only one of three major complementary views of an information system. Together, process, logic, and data models provide a thorough specification of an information system and, with the proper supporting tools, also provide the basis for the automatic generation of many working information system components.

Deliverables and Outcomes

In structured analysis, the primary deliverables from process modeling are a set of co - herent, interrelated DFDs. Table 7-1 provides a more detailed list of the deliverables that result when DFDs are used to study and document a system’s processes. First, a context diagram shows the scope of the system, indicating which elements are inside and which are outside the system. Second, DFDs of the system specify which pro- cesses move and transform data, accepting inputs and producing outputs. These dia- grams are developed with sufficient detail to understand the current system and to

Data flow diagram (DFD) A picture of the movement of data between external entities and the processes and data stores within a system.

FIGURE 7-1 Systems development life cycle with the analysis phase highlighted

DesignImplementation

Planning

Maintenance Analysis Requirements Determination Requirements Structuring

M07_VALA1629_09_GE_C07.indd 204 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 205

eventually determine how to convert the current system into its replacement. This logical progression of deliverables allows you to understand the existing system. You can then abstract this system into its essential elements to show how the new system should meet the information-processing requirements identified during requirements determination. Remember, the deliverables of process modeling are simply stating what you learned during requirements determination; in later steps in the systems development life cycle, you and other project team members will make decisions on exactly how the new system will deliver these new requirements in specific manual and automated functions. Because requirements determination and structuring are often parallel steps, DFDs evolve from the more general to the more detailed as current and replacement systems are better understood.

DFDs provide notation as well as illustrate important concepts about the move- ment of data between manual and automated steps, and they offer a way to depict work flow in an organization. DFDs continue to be beneficial to information sys- tems professionals as tools for both analysis and communication. For that reason, we devote almost an entire chapter to DFDs, but we complement our coverage of DFDs with an introduction to use cases and use case diagrams in the chapter appendix on use cases.

DATA FLOW DIAGRAMMING MECHANICS DFDs are versatile diagramming tools. With only four symbols, you can use DFDs to represent both physical and logical information systems. DFDs are not as good as flowcharts for depicting the details of physical systems; on the other hand, flowcharts are not very useful for depicting purely logical information flows. In fact, flowchart- ing has been criticized by proponents of structured analysis and design because it is too physically oriented. Flowcharting symbols primarily represent physical comput- ing equipment, such as terminals and permanent storage. One continual criticism of system flowcharts has been that overreliance on such charts tends to result in prema- ture physical system design. Consistent with the incremental commitment philosophy of the systems development life cycle (SDLC), you should wait to make technology choices and to decide on physical characteristics of an information system until you are sure all functional requirements are correct and accepted by users and other stakeholders.

DFDs do not share this problem of premature physical design because they do not rely on any symbols to represent specific physical computing equipment. They are also easier to use than flowcharts because they involve only four different symbols.

Definitions and Symbols

There are two different standard sets of DFD symbols (see Figure 7-2); each set con- sists of four symbols that represent the same things: data flows, data stores, processes, and sources/sinks (or external entities). The set of symbols we will use in this book was devised by Gane and Sarson (1979). The other standard set was developed by DeMarco (1979) and Yourdon (Yourdon & Constantine, 1979).

A data flow can be best understood as data in motion, moving from one place in a system to another. A data flow could represent data on a customer order form or a

1. Context DFD 2. DFDs of the system (adequately decomposed) 3. Thorough descriptions of each DFD component

TABLE 7-1 Deliverables for Process Modeling

M07_VALA1629_09_GE_C07.indd 205 08/04/2020 16:40

206 PART III ANALYSIS

payroll check; it could also represent the results of a query to a database, the contents of a printed report, or data on a data entry computer display form. A data flow consists of data that move together, so it can be composed of many individual pieces of data that are generated at the same time and that flow together to common destinations. A data store is data at rest. A data store may represent one of many different physical locations for data; for example, a file folder, one or more computer-based file(s), or a notebook. To understand data movement and handling in a system, it is not important to understand the system’s physical configuration. A data store might contain data about customers, students, customer orders, or supplier invoices. A process is the work or action(s) performed on data so that they are transformed, stored, or distributed. When modeling the data processing of a system, it does not matter whether a process is performed manually or by a computer. Finally, a source/sink is the origin and/or destination of the data. Sources/sinks are sometimes referred to as external entities because they are outside the system. Once processed, data or information leave the system and go to some other place. Because sources and sinks are outside the system we are studying, many of the characteristics of sources and sinks are of no interest to us. In particular, we do not consider the following:

• Interactions that occur between sources and sinks • What a source or sink does with information or how it operates (i.e., a source or

sink is a “black box”) • How to control or redesign a source or sink because, from the perspective of

the system we are studying, the data a sink receives and often what data a source provides are fixed

• How to provide sources and sinks direct access to stored data because, as exter- nal agents, they cannot directly access or manipulate data stored within the sys- tem; that is, processes within the system must receive or distribute data between the system and its environment

The symbols for each set of DFD conventions are presented in Figure 7-2. In both conventions, a data flow is depicted as an arrow. The arrow is labeled with a meaningful name for the data in motion; for example, Customer Order, Sales Receipt, or Paycheck. The name represents the aggregation of all the individual elements of data moving as part of one packet, that is, all the data moving together at the same time. A square is used in both conventions for sources/sinks and has a name that states

Data store Data at rest, which may take the form of many different physical representations.

Process The work or actions performed on data so that they are transformed, stored, or distributed.

Source/sink The origin and/or destination of data; sometimes referred to as external entities.

FIGURE 7-2 Comparison of DeMarco and Yourdon with Gane and Sarson DFD symbol sets

(Source: Based on Celko, 1987) process

data store

source/sink

data flow

DeMarco and Yourdon symbols

Gane and Sarson symbols

M07_VALA1629_09_GE_C07.indd 206 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 207

what the external agent is, such as Customer, Teller, EPA Office, or Inventory Control System. The Gane and Sarson symbol for a process is a rectangle with rounded cor- ners; it is a circle for DeMarco and Yourdon. The Gane and Sarson rounded rectangle has a line drawn through the top. The upper portion is used to indicate the number of the process. Inside the lower portion is a name for the process, such as Generate Paycheck, Calculate Overtime Pay, or Compute Grade Point Average. The Gane and Sarson symbol for a data store is a rectangle that is missing its right vertical side. At the left end is a small box used to number the data store, and inside the main part of the rectangle is a meaningful label for the data store, such as Student File, Transcripts, or Roster of Classes. The DeMarco and Yourdon data store symbol consists of two parallel lines, which may be depicted horizontally or vertically.

As stated earlier, sources/sinks are always outside the information system and define the boundaries of the system. Data must originate outside a system from one or more sources, and the system must produce information to one or more sinks (these are principles of open systems, and almost every information system is an open system). If any data processing takes place inside the source/sink, it is of no interest because this processing takes place outside the system we are diagramming. A source/ sink might consist of the following:

• Another organization or organization unit that sends data to or receives information from the system you are analyzing (e.g., a supplier or an academic department—in either case, the organization is external to the system you are studying)

• A person inside or outside the business unit supported by the system you are analyzing who interacts with the system (e.g., a customer or loan officer)

• Another information system with which the system you are analyzing exchanges information

Many times students who are just learning how to use DFDs will become con- fused as to whether something is a source/sink or a process within a system. This dilemma occurs most often when the data flows in a system cross office or depart- mental boundaries so that some processing occurs in one office and the processed data are moved to another office where additional processing occurs. Students are tempted to identify the second office as a source/sink to emphasize the fact that the data have been moved from one physical location to another (Figure 7-3a). However, we are not concerned with where the data are physically located. We are more interested in how they are moving through the system and how they are being processed. If the processing of data in the other office may be automated by your system or the handling of data there may be subject to redesign, then you should represent the second office as one or more processes rather than as a source/sink (Figure 7.3b).

Developing DFDs: An Example

To illustrate how DFDs are used to model the logic of data flows in information sys- tems, we will present and work through an example. Consider Hoosier Burger, a fic- tional restaurant in Bloomington, Indiana, owned by Bob and Thelma Mellankamp. Some are convinced that its hamburgers are the best in Bloomington, maybe even in southern Indiana. Many people, especially Indiana University students and faculty, frequently eat at Hoosier Burger. The restaurant uses an information system that takes customer orders, sends the orders to the kitchen, monitors goods sold and inventory, and generates reports for management.

The information system is depicted as a DFD in Figure 7-4. The highest-level view of this system, shown in the figure, is called a context diagram. You will notice that this context diagram contains only one process, no data stores, four data flows, and three sources/sinks. The single process, labeled 0, represents the entire sys- tem; all context diagrams have only one process, labeled 0. The sources/sinks

Hoosier Burger

Context diagram An overview of an organizational system that shows the system boundaries, external entities that interact with the system, and the major information flows between the entities and the system.

M07_VALA1629_09_GE_C07.indd 207 08/04/2020 16:40

208 PART III ANALYSIS

represent the environmental boundaries of the system. Because the data stores of the system are conceptually inside one process, data stores do not appear on a context diagram.

The analyst must determine which processes are represented by the single pro- cess in the context diagram. As you can see in Figure 7-5, we have identified four

FIGURE 7-3 Differences between sources/sinks and processes (a) An improperly drawn DFD showing a process as a source/sink

(b) A DFD showing proper use of a process

(Source: Based on Celko, 1987)

Payment

Payment Data Receipt

Payment Data

Deposit Data

Credit Data

BANK

CUSTOMER MASTER

2.0

Make Bank

Deposit

1.0

Record Payment

CUSTOMER

Accounting Department

BANK

Payment

Payment Data Receipt

Payment Data

Deposit Data

Credit Data

3.0

Update Customer

Master

CUSTOMER

1.0

Record Payment

2.0

Make Bank

Deposit

CUSTOMER MASTER

FIGURE 7-4 Context diagram of Hoosier Burger’s food-ordering system

RESTAURANT MANAGER

KITCHEN

Receipt

Customer Order Food Order

Management Reports

Food- Ordering System

CUSTOMER

M07_VALA1629_09_GE_C07.indd 208 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 209

separate processes. The main processes represent the major functions of the system, and these major functions correspond to actions such as the following:

1. Capturing data from different sources (e.g., Process 1.0) 2. Maintaining data stores (e.g., Processes 2.0 and 3.0) 3. Producing and distributing data to different sinks (e.g., Process 4.0) 4. High-level descriptions of data transformation operations (e.g., Process 1.0)

These major functions often correspond to the activities on the main system menu.

We see that the system begins with an order from a customer, as was the case with the context diagram. In the first process, labeled 1.0, we see that the customer order is processed. The result is four streams, or flows, of data: (1) the food order is transmitted to the kitchen, (2) the customer order is transformed into a list of goods sold, (3) the customer order is transformed into inventory data, and (4) the process generates a receipt for the customer.

Notice that the sources/sinks are the same in the context diagram and in this diagram: the customer, the kitchen, and the restaurant’s manager. This diagram is called a level-0 diagram because it represents the primary individual processes in the system at the highest possible level. Each process has a number that ends in .0 (cor- responding to the level number of the DFD).

Two of the data flows generated by the first process, Receive and Transform Customer Food Order, go to external entities, so we no longer have to worry about them. We are not concerned about what happens outside our system. Let’s trace the flow of the data represented in the other two data flows. First, the data labeled Goods Sold go to Process 2.0, Update Goods Sold File. The output for this process is labeled Formatted Goods Sold Data. This output updates a data store labeled

Level-0 diagram A DFD that represents a system’s major processes, data flows, and data stores at a high level of detail.

FIGURE 7-5 Level-0 DFD of Hoosier Burger’s food-ordering system

CUSTOMER

RESTAURANT MANAGER

KITCHEN

Receipt

Customer Order Food Order

Management Reports

Goods Sold

Inventory Data

Formatted Goods Sold Data

Formatted Inventory Data

Daily Inventory Depletion Amounts

Daily Goods Sold Amounts

Inventory FileD1

Goods Sold FileD2

1.0

Receive and Transform Customer

Food Order

3.0

Update Inventory

File

2.0

Update Goods Sold

File

4.0

Produce Management

Reports

M07_VALA1629_09_GE_C07.indd 209 08/04/2020 16:40

210 PART III ANALYSIS

Goods Sold File. If the customer order was for two cheeseburgers, one order of fries, and a large soft drink, each of these categories of goods sold in the data store would be incremented appropriately. The Daily Goods Sold Amounts are then used as input to Process 4.0, Produce Management Reports. Similarly, the remaining data flow generated by Process 1.0, Inventory Data, serves as input for Process 3.0, Update Inventory File. This process updates the Inventory File data store, based on the inventory that would have been used to create the customer order. For example, an order of two cheeseburgers would mean that Hoosier Burger now has two fewer hamburger patties, two fewer burger buns, and four fewer slices of American cheese. The Daily Inventory Depletion Amounts are then used as input to Process 4.0. The data flow leaving Process 4.0, Management Reports, goes to the sink Restaurant Manager.

Figure 7-5 illustrates several important concepts about information movement. Consider the data flow Inventory Data moving from Process 1.0 to Process 3.0. We know from this diagram that Process 1.0 produces this data flow and that Process 3.0 receives it. However, we do not know the timing of when this data flow is pro- duced, how frequently it is produced, or what volume of data is sent. Thus, this DFD hides many physical characteristics of the system it describes. We do know, however, that this data flow is needed by Process 3.0 and that Process 1.0 provides these needed data.

Also implied by the Inventory Data data flow is that whenever Process 1.0 pro- duces this flow, Process 3.0 must be ready to accept it. Thus, Processes 1.0 and 3.0 are coupled with each other. In contrast, consider the link between Process 2.0 and Process 4.0. The output from Process 2.0, Formatted Goods Sold Data, is placed in a data store and, later, when Process 4.0 needs such data, it reads Daily Goods Sold Amounts from this data store. In this case, Processes 2.0 and 4.0 are decoupled by placing a buffer, a data store, between them. Now, each of these processes can work at their own pace, and Process 4.0 does not have to be ready to accept input at any time. Further, the Goods Sold File becomes a data resource that other processes could potentially draw upon for data.

Data Flow Diagramming Rules

You must follow a set of rules when drawing DFDs. Unlike system flowcharts, these rules allow you to evaluate DFDs for correctness. The rules for DFDs are listed in Table 7-2. Figure 7-6 illustrates incorrect ways to draw DFDs and the corresponding correct application of the rules. The rules that prescribe naming conventions (rules C, G, I, and P) and those that explain how to interpret data flows in and out of data stores (rules N and O) are not illustrated in Figure 7-6.

In addition to the rules in Table 7-2, there are two DFD guidelines that often apply:

1. The inputs to a process are different from the outputs of that process. The reason is that processes, because they have a purpose, typically transform inputs into outputs, rather than simply pass the data through without some manipulation. What may happen is that the same input goes in and out of a process, but the process also produces other new data flows that are the result of manipulating the inputs.

2. Objects on a DFD have unique names. Every process has a unique name. There is no reason for two processes to have the same name. To keep a DFD uncluttered, however, you may repeat data stores and sources/sinks. When two arrows have the same data flow name, you must be careful that these flows are exactly the same. It is easy to reuse the same data flow name when two packets of data are almost the same but not identical. A data flow name represents a specific set of data, and another data flow that has even one more or one less piece of data must be given a different, unique name.

M07_VALA1629_09_GE_C07.indd 210 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 211

Decomposition of DFDs

In the earlier example of Hoosier Burger’s food-ordering system, we started with a high-level context diagram. Upon thinking more about the system, we saw that the larger system consisted of four processes. The act of going from a single system to four component processes is called (functional) decomposition. Functional decomposition is an iterative process of breaking the description or perspective of a system down into finer and finer detail. This process creates a set of hierarchically related charts in which one process on a given chart is explained in greater detail on another chart. For the Hoosier Burger system, we broke down, or decomposed, the larger system into four processes. Each resulting process (or subsystem) is also a candidate for decom- position. Each process may consist of several subprocesses. Each subprocess may also be broken down into smaller units. Decomposition continues until you have reached the point at which no subprocess can logically be broken down any further. The lowest level of a DFD is called a primitive DFD, which we define later in this chapter.

Let’s continue with Hoosier Burger’s food-ordering system to see how a level-0 DFD can be further decomposed. The first process in Figure 7-5, called Receive and Transform Customer Food Order, transforms a customer’s verbal food order (e.g., “Give me two cheeseburgers, one small order of fries, and one regular orange soda”)

Functional decomposition An iterative process of breaking the description of a system down into finer and finer detail, which creates a set of charts in which one process on a given chart is explained in greater detail on another chart.

Process: A. No process can have only outputs. It would be making data from nothing (a miracle). If an

object has only outputs, then it must be a source. B. No process can have only inputs (a black hole). If an object has only inputs, then it must

be a sink. C. A process has a verb phrase label. Data Store: D. Data cannot move directly from one data store to another data store. Data must be

moved by a process. E. Data cannot move directly from an outside source to a data store. Data must be moved

by a process that receives data from the source and places the data into the data store. F. Data cannot move directly to an outside sink from a data store. Data must be moved by a

process. G. A data store has a noun phrase label. Source/Sink: H. Data cannot move directly from a source to a sink. It must be moved by a process if the

data are of any concern to our system. Otherwise, the data flow is not shown on the DFD. I. A source/sink has a noun phrase label. Data Flow: J. A data flow has only one direction of flow between symbols. It may flow in both directions

between a process and a data store to show a read before an update. The latter is usually indicated, however, by two separate arrows because these happen at different times.

K. A fork in a data flow means that exactly the same data goes from a common location to two or more different processes, data stores, or sources/sinks (this usually indicates different copies of the same data going to different locations).

L. A join in a data flow means that exactly the same data come from any of two or more different processes, data stores, or sources/sinks to a common location.

M. A data flow cannot go directly back to the same process it leaves. There must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process.

N. A data flow to a data store means update (delete or change). O. A data flow from a data store means retrieve or use. P. A data flow has a noun phrase label. More than one data flow noun phrase can appear

on a single arrow as long as all of the flows on the same arrow move together as one package.

TABLE 7-2 Rules Governing Data Flow Diagramming

(Source: Based on Celko, 1987.)

Hoosier Burger

M07_VALA1629_09_GE_C07.indd 211 08/04/2020 16:40

212 PART III ANALYSIS

FIGURE 7-6 Incorrect and correct ways to draw DFDs

Incorrect Correct

Rule

into four different outputs. Process 1.0 is a good candidate process for decomposition. Think about all of the different tasks that Process 1.0 has to perform: (1) receive a customer order, (2) transform the entered order into a form meaningful for the kitchen’s system, (3) transform the order into a printed receipt for the customer, (4) transform the order into goods sold data, and (5) transform the order into inven- tory data. At least five logically separate functions can occur in Process 1.0. We can represent the decomposition of Process 1.0 as another DFD, as shown in Figure 7-7.

M07_VALA1629_09_GE_C07.indd 212 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 213

Note that each of the five processes in Figure 7-7 is labeled as a subprocess of Process 1.0: Process 1.1, Process 1.2, and so on. Also note that, just as with the other DFDs we have looked at, each of the processes and data flows is named. You will also notice that no sources or sinks are represented. Although you may include sources and sinks, the context and level-0 diagrams show the sources and sinks. The DFD in Figure 7-7 is called a level-1 diagram. If we should decide to decompose Processes 2.0, 3.0, or 4.0 in a similar manner, the DFDs we would create would also be level-1 diagrams. In general, a level-n diagram is a DFD that is generated from n nested decompositions from a level-0 diagram.

Processes 2.0 and 3.0 perform similar functions in that they both use data input to update data stores. Because updating a data store is a singular logical function, neither of these processes needs to be decomposed further. We can, however, decom- pose Process 4.0, Produce Management Reports, into at least three subprocesses: Access Goods Sold and Inventory Data, Aggregate Goods Sold and Inventory Data, and Prepare Management Reports. The decomposition of Process 4.0 is shown in the level-1 diagram of Figure 7-8.

Each level-1, -2, or -n DFD represents one process on a level-n-1 DFD; each DFD should be on a separate page. As a rule of thumb, no DFD should have more

Level-n diagram A DFD that is the result of n nested decompositions from a process on a level-0 diagram.

FIGURE 7-7 Level-1 diagram showing the decomposition of Process 1.0 from the level-0 diagram for Hoosier Burger’s food-ordering system

Customer Order

Customer Order Customer Order

Customer Order

Customer Order Food Order

Inventory Data

Goods Sold Data

Receipt

1.1

Receive Customer

Order

1.2

Generate Customer Receipt

1.5

Generate Inventory

Decrements

1.4

Generate Goods Sold Increments

1.3

Transform Order to Kitchen Format

FIGURE 7-8 Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s food-ordering system

Daily Goods Sold Amounts

Inventory Data

Goods Sold Data

Aggregated Data

Management Reports

Daily Inventory Depletion Amounts

4.2

Aggregate Goods Sold

and Inventory Data

4.1

Access Goods Sold

and Inventory Data

4.3

Prepare Management

Reports

M07_VALA1629_09_GE_C07.indd 213 08/04/2020 16:40

214 PART III ANALYSIS

than about seven processes because too many processes will make the diagram too crowded and difficult to understand. To continue with the decomposition of Hoosier Burger’s food-ordering system, we examine each of the subprocesses identified in the two level-1 diagrams we have produced, one for Process 1.0 and one for Process 4.0. Should we decide that any of these subprocesses should be further decomposed, we would create a level-2 diagram showing that decomposition. For example, if we decided that Process 4.3 in Figure 7-8 should be further decomposed, we would create a diagram that looks something like Figure 7-9. Again, notice how the subprocesses are labeled.

Just as the labels for processes must follow numbering rules for clear communi- cation, process names should also be clear yet concise. Typically, process names begin with an action verb, such as Receive, Calculate, Transform, Generate, or Produce. Process names often are the same as the verbs used in many computer programming languages. Example process names include Merge, Sort, Read, Write, and Print. Pro- cess names should capture the essential action of the process in just a few words, yet be descriptive enough of the process’s action so that anyone reading the name gets a good idea of what the process does. Many times, students just learning DFDs will use the names of people who perform the process or the department in which the process is performed as the process name. This practice is not very useful because we are more interested in the action the process represents than the person performing it or the place where it occurs.

Balancing DFDs

When you decompose a DFD from one level to the next, there is a conservation prin- ciple at work. You must conserve inputs and outputs to a process at the next level of decomposition. In other words, Process 1.0, which appears in a level-0 diagram, must have the same inputs and outputs when decomposed into a level-1 diagram. This conservation of inputs and outputs is called balancing.

Let’s look at an example of balancing a set of DFDs. Look back at Figure 7-4. This is the context diagram for Hoosier Burger’s food-ordering system. Notice that there is one input to the system, the customer order, which originates with the cus- tomer. Notice also that there are three outputs: the customer receipt, the food order intended for the kitchen, and management reports. Now look at Figure 7-5. This is the level-0 diagram for the food-ordering system. Remember that all data stores and flows to or from them are internal to the system. Notice that the same single input to the system and the same three outputs represented in the context diagram also appear at level 0. Further, no new inputs to or outputs from the system have been introduced. Therefore, we can say that the context diagram and level-0 DFDs are balanced.

Now look at Figure 7-7, where Process 1.0 from the level-0 DFD has been decom- posed. As we have seen before, Process 1.0 has one input and four outputs. The single input and multiple outputs all appear on the level-1 diagram in Figure 7-7. No new inputs or outputs have been added. Compare Process 4.0 in Figure 7-5 with its decom- position in Figure 7-8. You see the same conservation of inputs and outputs.

Figure 7-10 shows one example of what an unbalanced DFD could look like. The context diagram shows one input to the system, A, and one output, B. Yet in the level-0 diagram, there is an additional input, C, and flows A and C come from different

Balancing The conservation of inputs and outputs to a DFD process when that process is decomposed to a lower level.

FIGURE 7-9 Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering system

4.3.2

Print Management

Reports

Formatted DataAggregated Data Management Reports

4.3.1

Format Management

Reports

M07_VALA1629_09_GE_C07.indd 214 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 215

sources. These two DFDs are not balanced. If an input appears on a level-0 diagram, it must also appear on the context diagram. What happened with this example? Per- haps, when drawing the level-0 DFD, the analyst realized that the system also needed C in order to compute B. A and C were both drawn in the level-0 DFD, but the analyst forgot to update the context diagram. When making corrections, the analyst should also include “SOURCE ONE” and “SOURCE TWO” on the context diagram. It is very important to keep DFDs balanced from the context diagram all the way through each level of diagram you create.

A data flow consisting of several subflows on a level-n diagram can be split apart on a level-n diagram for a process that accepts this composite data flow as input. For example, consider the partial DFDs from Hoosier Burger, illustrated in Figure 7-11. In Figure 7-11a, we see that a composite, or package, data flow—Payment and Coupon—is input to the process. That is, the payment and coupon always flow together and are input to the process at the same time. In Figure 7-11b, the process is decomposed (sometimes referred to as exploded or nested) into two subprocesses,

FIGURE 7-10 An unbalanced set of DFDs (a) Context diagram

(b) Level-0 diagram

A B

SOURCE SINK

Formatted C

C B

Formatted A

1.0

SOURCE ONE

2.0

SOURCE TWO

SINK

FIGURE 7-11 Example of data flow splitting (a) Composite data flow

(b) Disaggregated data flows

Write Software

X.0

Payment and Coupon

(a)

X.1

X.2

Payment

Coupon

(b)

M07_VALA1629_09_GE_C07.indd 215 08/04/2020 16:40

216 PART III ANALYSIS

Q. A composite data flow on one level can be split into component data flows at the next level, but no new data can be added and all data in the composite must be accounted for in one or more subflows.

R. The inputs to a process must be sufficient to produce the outputs (including data placed in data stores) from the process. Thus, all outputs can be produced, and all data in inputs move somewhere: to another process or to a data store outside the process or onto a more detailed DFD showing a decomposition of that process.

S. At the lowest level of DFDs, new data flows may be added to represent data that are transmitted under exceptional conditions; these data flows typically represent error messages (e.g., “Customer not known; do you want to create a new customer?”) or confirmation notices (e.g., “Do you want to delete this record?”).

T. To avoid having data flow lines cross each other, you may repeat data stores or sources/ sinks on a DFD. Use an additional symbol, like a double line on the middle vertical line of a data store symbol or a diagonal line in a corner of a sink/source square, to indicate a repeated symbol.

TABLE 7-3 Advanced Rules Governing Data Flow Diagramming

FIGURE 7-12 List of activities involved in Bob Mellankamp’s inventory control system for Hoosier Burger

1. Meet delivery trucks before opening restaurant.

2. Unload and store deliveries.

3. Log invoices and file in accordion file.

4. Manually add amounts received to stock logs.

5. After closing, print inventory report.

6. Count physical inventory amounts.

7. Compare inventory report totals to physical count totals.

8. Compare physical count totals to minimum order quantities. If the amount is less, make order; if not, do nothing.

9. Pay bills that are due and record them as paid.

(Source: Based on Celko, 1987.)

and each subprocess receives one of the components of the composite data flow from the higher-level DFD. These diagrams are still balanced because exactly the same data are included in each diagram.

The principle of balancing and the goal of keeping a DFD as simple as possible led to four additional, advanced rules for drawing DFDs. These advanced rules are summarized in Table 7-3. Rule Q covers the situation illustrated in Figure 7-11. Rule R covers a conservation principle about process inputs and outputs. Rule S addresses one exception to balancing. Rule T tells you how you can minimize clutter on a DFD.

AN EXAMPLE DFD To illustrate the creation and refinement of DFDs, we will look at another example from Hoosier Burger. We saw that the food-ordering system generates two types of usage data—goods sold and inventory. At the end of each day, the manager, Bob Mellankamp, generates the inventory report that tells him how much inventory should have been used for each item associated with a sale. The amounts shown on the inven- tory report are just one input to a largely manual inventory control system Bob uses every day. Figure 7-12 lists the steps involved in Bob’s inventory control system.

In the Hoosier Burger inventory system, three sources of data come from outside: suppliers, the food-ordering system inventory report, and stock on hand. Suppliers provide invoices as input, and the system returns payments and orders as outputs to the suppliers. Both the inventory report and the stock-on-hand amounts provide inventory counts as system inputs. When Bob receives invoices from suppliers,

Hoosier Burger

M07_VALA1629_09_GE_C07.indd 216 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 217

he records their receipt on an invoice log sheet and files the actual invoices in his accordion file. Using the invoices, Bob records the amount of stock delivered on the stock logs, which are paper forms posted near the point of storage for each inventory item. Figure 7-13 gives a partial example of Hoosier Burger’s stock log. Notice that the minimum order quantities—the stock level at which orders must be placed in order to avoid running out of an item—appear on the log form. The stock log also has spaces for entering the starting amount, amount delivered, and the amount used for each item. Amounts delivered are entered on the sheet when Bob logs stock deliveries; amounts used are entered after Bob has compared the amounts of stock used accord- ing to a physical count and according to the numbers on the inventory report gener- ated by the food-ordering system. We should note that Hoosier Burger has standing daily delivery orders for some perishable items that are used every day, such as burger buns, meats, and vegetables. Bob uses the minimum order quantities and the amount of stock on hand to determine which orders need to be placed. He uses the invoices to determine which bills need to be paid, and he carefully records each payment.

To create the DFD, we need to identify the essence of the inventory system Bob has established. What are the key data necessary to keep track of inventory and pay bills? What are the key processes involved? At least four key processes make up Hoosier Burger’s inventory system: (1) account for anything added to inventory, (2) account for anything taken from inventory, (3) place orders, and (4) pay bills. Key data used by the system include inventories and stock-on-hand counts, however they are determined. Major outputs from the system continue to be orders and payments. If we focus on the essential elements of the system, we obtain the context diagram and the level-0 DFD shown in Figure 7-14.

At this point, we can revise the DFD based on any new functionality desired for the system. For Hoosier Burger’s inventory system, Bob Mellankamp would like to add three additional functions. First, Bob would like data on new shipments to be entered into an automated system, thus doing away with paper stock log sheets. Bob would like shipment data to be as current as possible because it will be entered into the system as soon as the new stock arrives at the restaurant. Second, Bob would like the system to determine automatically whether a new order should be placed. Auto- matic ordering would relieve Bob of worrying about whether Hoosier Burger has enough of everything in stock at all times. Finally, Bob would like to be able to know, at any time, the approximate inventory level for each good in stock. For some goods, such as hamburger buns, Bob can visually inspect the amount in stock and determine approximately how much is left and how much more is needed before closing time. For other items, however, Bob may need a rough estimate of what is in stock more quickly than he can estimate via a visual inspection.

FIGURE 7-13 Hoosier Burger’s stock log form

Stock Log

Date: Jan 1 Jan 2

Reorder Quantity

Starting Amount

Amount Delivered

Amount Used

Starting Amount

Item

Hamburger buns 50 dozen 5 50 43 12

Hot dog buns 25 dozen 0 25 22 3

English mu�ns 10 dozen 6 10 12 4

Napkins 2 cases 10 0 2 8

Straws 1 case 1 0 1 0

M07_VALA1629_09_GE_C07.indd 217 08/04/2020 16:40

218 PART III ANALYSIS

The revised DFD for Hoosier Burger’s inventory system is shown in Figure 7-15. The main difference between the DFD in Figure 7-14b and the revised DFD in Figure 7-15 is the new Process 5.0, which allows for querying the inventory data to get an estimate of how much of an item is in stock. Bob’s two other requests for change

FIGURE 7-14 (a) Context diagram for Hoosier Burger’s inventory control system

Orders

Invoices Counts

Payments

SUPPLIER STOCK

ON HAND Inventory System

Invoices

InvoicesPayments

Orders

Counts

Amounts UsedAmounts Added

Inventory Levels

Minimum Order Quantities

INVENTORYD1

1.0

Update Inventory

Added

3.0

Generate Orders

4.0

Generate Payments

2.0

Update Inventory

Used

SUPPLIER STOCK

ON HAND

FIGURE 7-15 Revised level-0 DFD for Hoosier Burger’s inventory control system

Invoices

InvoicesPayments Orders

Counts

Amounts Used

Amounts Added

Inventory Levels

Minimum Order Quantities

INVENTORYD1

1.0

Update Inventory

Added

3.0

Generate Orders

4.0

Generate Payments

2.0

Update Inventory

Used

SUPPLIER STOCK ON HAND

Query Request

Query Result

5.0

Query Inventory

Levels

MANAGER

(b) Level-0 DFD for Hoosier Burger’s inventory control system

M07_VALA1629_09_GE_C07.indd 218 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 219

can both be handled within the existing logical view of the inventory system. Pro- cess 1.0, Update Inventory Added, does not indicate whether the updates are in real time or batched, or whether the updates occur on paper or as part of an automated system. Therefore, immediately entering shipment data into an automated system is encompassed by Process 1.0. Similarly, Process 2.0, Generate Orders, does not indicate whether Bob or a computer generates orders or whether the orders are generated on a real-time or batch basis, so Bob’s request that orders be generated automatically by the system is already represented by Process 3.0.

USING DATA FLOW DIAGRAMMING IN THE ANALYSIS PROCESS Learning the mechanics of drawing DFDs is important because DFDs have proven to be essential tools for the structured analysis process. Beyond the issue of drawing mechanically correct DFDs, there are other issues related to process modeling with which you, as an analyst, must be concerned. Such issues, including whether the DFDs are complete and consistent across all levels, are dealt with in the next section, which covers guidelines for drawing DFDs. Another issue to consider is how you can use DFDs as a useful tool for analysis. In these final sections, we also illustrate how DFDs can be used to support business process reengineering.

Guidelines for Drawing DFDs

In this section, we will consider additional guidelines for drawing DFDs that extend beyond the simple mechanics of drawing diagrams and making sure that the rules listed in Tables 7-2 and 7-3 are followed. These guidelines include (1) completeness, (2) consistency, (3) timing considerations, (4) the iterative nature of drawing DFDs, and (5) primitive DFDs.

Completeness The concept of DFD completeness refers to whether you have included in your DFDs all of the components necessary for the system you are model- ing. If your DFD contains data flows that do not lead anywhere or data stores, pro- cesses, or external entities that are not connected to anything else, your DFD is not complete.

Not only must all necessary elements of a DFD be present, each of the compo- nents must be fully described in the project dictionary. Different descriptive informa- tion can be kept about each of the four types of elements on a DFD, and each project dictionary standard an organization adopts has different entry information. Data flow repository entries typically include the following:

• The label or name for the data flow as entered on the DFDs (Note: Case and punctuation of the label matter, but if exactly the same label is used on multiple DFDs, whether nested or not, then the same repository entry applies to each reference.)

• A short description defining the data flow • A list of other repository objects grouped into categories by type of object • The composition or list of data elements contained in the data flow • Notes supplementing the limited space for the description that go beyond

defining the data flow to explaining the context and nature of this repository object

• A list of locations (the names of the DFDs) on which this data flow appears and the names of the sources and destinations on each of these DFDs for the data flow

DFD completeness The extent to which all necessary components of a DFD have been included and fully described.

M07_VALA1629_09_GE_C07.indd 219 08/04/2020 16:40

220 PART III ANALYSIS

Consistency The concept of DFD consistency refers to whether or not the depiction of the system shown at one level of a nested set of DFDs is compatible with the depictions of the system shown at other levels. A gross violation of consis- tency would be a level-1 diagram with no level-0 diagram. Another example of incon- sistency would be a data flow that appears on a higher-level DFD but not on lower levels (also a violation of balancing). Yet another example of inconsistency is a data flow attached to one object on a lower-level diagram but also attached to another object at a higher level; for example, a data flow named Payment, which serves as input to Process 1 on a level-0 DFD, appears as input to Process 2.1 on a level-1 diagram for Process 2.

Timing You may have noticed in some of the DFD examples we have presented that DFDs do not do a very good job of representing time. On a given DFD, there is no indication of whether a data flow occurs constantly in real time, once per week, or once per year. There is also no indication of when a system would run. For example, many large, transaction-based systems may run several large, computing-intensive jobs in batch mode at night, when demands on the computer system are lighter. A DFD has no way of indicating such overnight batch processing. When you draw DFDs, then, draw them as if the system you are modeling has never started and will never stop.

Iterative Development The first DFD you draw will rarely capture perfectly the system you are modeling. You should count on drawing the same diagram over and over again, in an iterative fashion. With each attempt, you will come closer to a good approximation of the system or aspect of the system you are modeling. Iterative DFD development recognizes that requirements determination and requirements struc- turing are interacting, not sequential, subphases of the analysis phase of the SDLC.

Primitive DFDs One of the more difficult decisions you need to make when draw- ing DFDs is when to stop decomposing processes. One rule is to stop drawing when you have reached the lowest logical level; however, it is not always easy to know what the lowest logical level is. Other, more concrete rules for when to stop decomposing include the following:

• When you have reduced each process to a single decision or calculation or to a single database operation, such as retrieve, update, create, delete, or read

• When each data store represents data about a single entity, such as a customer, employee, product, or order

• When the system user does not care to see any more detail or when you and other analysts have documented sufficient detail to do subsequent systems devel- opment tasks

• When every data flow does not need to be split further to show that different data are handled in different ways

• When you believe that you have shown each business form or transaction, computer online display, and report as a single data flow (this often means, for example, that each system display and report title corresponds to the name of an individual data flow)

• When you believe there is a separate process for each choice on all lowest-level menu options for the system

Obviously, the iteration guideline discussed earlier and the various feedback loops in the SDLC (see Figure 7-1) suggest that when you think you have met the rules for stopping, you may later discover nuances to the system that require you to further decompose a set of DFDs.

By the time you stop decomposing a DFD, it may be quite detailed. Seemingly simple actions, such as generating an invoice, may pull information from several enti- ties and may also return different results depending on the specific situation. For example, the final form of an invoice may be based on the type of customer (which

DFD consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels.

M07_VALA1629_09_GE_C07.indd 220 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 221

would determine such things as discount rate), where the customer lives (which would determine such things as sales tax), and how the goods are shipped (which would determine such things as the shipping and handling charges). At the lowest-level DFD, called a primitive DFD, all of these conditions would have to be met. Given the amount of detail called for in a primitive DFD, perhaps you can see why many experts believe analysts should not spend their time completely diagramming the current physical information system because much of the detail will be discarded when the current logical DFD is created.

Using the guidelines presented in this section will help you to create DFDs that are more than just mechanically correct. Your DFDs will also be robust and accurate representations of the information system you are modeling. Primitive DFDs facilitate consistency checks with the documentation produced from other requirements struc- turing techniques and make it easy for you to transition to system design steps. Having mastered the skills of drawing good DFDs, you can now use them to support the analy- sis process, the subject of the next section.

Using DFDs as Analysis Tools

We have seen that DFDs are versatile tools for process modeling and that they can be used to model systems that are either physical or logical, current or new. DFDs can also be used in a process called gap analysis. Analysts can use gap analysis to discover discrepancies between two or more sets of DFDs, representing two or more states of an information system, or discrepancies within a single DFD.

Once the DFDs are complete, you can examine the details of individual DFDs for such problems as redundant data flows, data that are captured but are not used by the system, and data that are updated identically in more than one location. These problems may not have been evident to members of the analysis team or to other participants in the analysis process when the DFDs were created. For example, redun- dant data flows may have been labeled with different names when the DFDs were created. Now that the analysis team knows more about the system it is modeling, such redundancies can be detected. From the labels of these processes, you can determine whether the data are captured redundantly or if more than one process is maintaining the same data stores. In such cases, the DFDs may well accurately mirror the activities occurring in the organization. Because the business processes being modeled took many years to develop, sometimes with participants in one part of the organization adapting procedures in isolation from other participants, redundancies and overlap- ping responsibilities may well have resulted. The careful study of the DFDs created as part of analysis can reveal these procedural redundancies and allow them to be cor- rected as part of system design.

Inefficiencies can also be identified by studying DFDs, and there are a wide vari- ety of inefficiencies that might exist. Some inefficiencies relate to violations of DFD drawing rules. For example, a violation of rule R from Table 7-3 could occur because obsolete data are captured but never used within a system. Other inefficiencies are due to excessive processing steps. For example, consider the correct DFD in item M of Figure 7-1. Although this flow is mechanically correct, such a loop may indicate potential delays in processing data or unnecessary approval operations.

Similarly, a set of DFDs that models the current logical system can be compared with DFDs that model the new logical system to better determine which processes systems developers need to add or revise when building the new system. Processes for which inputs, outputs, and internal steps have not changed can possibly be reused in the construction of the new system. You can compare alternative logical DFDs to identify those few elements that must be discussed in evaluating competing opinions on system requirements. The logical DFDs for the new system can also serve as the basis for developing alternative design strategies for the new physical system. As we saw with the Hoosier Burger example, a process on a DFD can be physically implemented in several different ways.

Primitive DFD The lowest level of decomposition for a DFD.

Gap analysis The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD.

M07_VALA1629_09_GE_C07.indd 221 08/04/2020 16:40

222 PART III ANALYSIS

Using DFDs in Business Process Reengineering

DFDs are also useful for modeling processes in business process reengineering (BPR), which you read about in Chapter 6. To illustrate the usefulness of DFDs for BPR, let’s look at an example from Hammer and Champy (1993). Hammer and Champy use IBM Credit Corporation as an example of a firm that successfully reengineered its primary business process. IBM Credit Corporation provides financing for customers making large purchases of IBM computer equipment. Its job is to analyze deals pro- posed by salespeople and write the final contracts governing those deals.

According to Hammer and Champy, IBM Credit Corporation typically took six business days to process each financing deal. The process worked like this: First, the salesperson called in with a proposed deal. The call was taken by one of a half dozen people sitting around a conference table. Whoever received the call logged it and wrote the details on a piece of paper. A clerk then carried the paper to a second per- son, who initiated the next step in the process by entering the data into a computer system and checking the client’s creditworthiness. This person then wrote the details on a piece of paper and carried the paper, along with the original documentation, to a loan officer. Then, in a third step, the loan officer modified the standard IBM loan agreement for the customer. This step involved a separate computer system from the one used in step two.

In the fourth step, details of the modified loan agreement, along with the other documentation, were sent on to the next station in the process, where a different clerk determined the appropriate interest rate for the loan. This step also involved its own information system. In step five, the resulting interest rate and all of the paper generated up to this point were then carried to the next stop, where the quote letter was created. Once complete, the quote letter was sent via overnight mail back to the salesperson.

Only reading about this process makes it seem complicated. We can use DFDs to illustrate the overall process (see Figure 7-16). DFDs help us see that the process is not as complicated as it is tedious and wasteful, especially when you consider that so many different people and computer systems were used to support the work at each step.

According to Hammer and Champy, two IBM managers decided to see if they could improve the overall process at IBM Credit Corporation. They took a call from a salesperson and walked it through the system. These managers found that the actual

FIGURE 7-16 IBM Credit Corporation’s primary work process before BPR

(Source: Based on Hammer & Champy, 1993.)

Salesperson

Request

Documentation

Rate

Status

2.0

Check Credit-

worthiness

3.0

Modify Loan

Agreement

5.0

Create Quote Letter

Salesperson

1.0

Log Request

4.0

Determine Interest

Rate

Credit FilesD2

Interest FilesD1

Documentation

Contract

M07_VALA1629_09_GE_C07.indd 222 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 223

work being done on a contract only took 90 minutes. For much of the rest of the six days it took to process the deal, the various bits of documentation were sitting in someone’s in-basket waiting to be processed.

IBM Credit Corporation management decided to reengineer its entire process. The five sets of task specialists were replaced with generalists. Now each call from the field goes to a single clerk, who does all the work necessary to process the contract. Instead of having different people check for creditworthiness, modify the basic loan agreement, and determine the appropriate interest rate, one person does it all. IBM Credit Corporation still has specialists for the few cases that are significantly different from what the firm routinely encounters. In addition, the process is now supported by a single computer system. The new process is modeled by the DFD in Figure 7-17. The most striking difference between the DFD in Figure 7-16 and the DFD in Figure 7-17, other than the number of process boxes in each one, is the lack of documentation flow in Figure 7-17. The resulting process is much simpler and cuts down dramatically on any chance of documentation getting lost between steps. Redesigning the process from beginning to end allowed IBM Credit Corporation to increase the number of contracts it can handle by 100-fold—not 100 percent, which would only be doubling the amount of work. BPR allowed IBM Credit Corporation to handle 100 times more work in the same amount of time and with fewer people!

MODELING LOGIC WITH DECISION TABLES A decision table is a diagram of process logic where the logic is reasonably compli- cated. All of the possible choices and the conditions the choices depend on are rep- resented in tabular form, as illustrated in the decision table in Figure 7-18.

The decision table in Figure 7-18 models the logic of a generic payroll system. The table has three parts: the condition stubs, the action stubs, and the rules. The condition stubs contain the various conditions that apply to the situation the table is modeling. In Figure 7-18, there are two condition stubs for employee type and hours worked. Employee type has two values: “S,” which stands for salaried, and “H,” which stands for hourly. Hours worked has three values: less than 40, exactly 40, and more than 40. The action stubs contain all the possible courses of action that result from combining values of the condition stubs. There are four possible courses of action in this table: Pay Base Salary, Calculate Hourly Wage, Calculate Overtime, and Produce Absence Report. You can see that not all actions are triggered by all combinations of conditions. Instead, specific combinations trigger specific actions. The part of the table that links conditions to actions is the section that contains the rules.

To read the rules, start by reading the values of the conditions as specified in the first column: Employee type is “S,” or salaried, and hours worked is less than 40. When both of these conditions occur, the payroll system is to pay the base salary. In the next

Decision table A matrix representation of the logic of a decision; it specifies the possible conditions for the decision and the resulting actions.

Condition stubs The part of a decision table that lists the conditions relevant to the decision.

Action stubs The part of a decision table that lists the actions that result for a given set of conditions.

Rules The part of a decision table that specifies which actions are to be followed for a given set of conditions.

Request

Supporting Data

Rate

Status

Salesperson

Process Contract

Credit FilesD2

Interest FilesD1

Contract

Specialists

FIGURE 7-17 IBM Credit Corporation’s primary work process after BPR

(Source: Based on Hammer and Champy, 1993.)

M07_VALA1629_09_GE_C07.indd 223 08/04/2020 16:40

224 PART III ANALYSIS

column, the values are “H” and “<40,” meaning an hourly worker who worked less than 40 hours. In such a situation, the payroll system calculates the hourly wage and makes an entry in the Absence Report. Rule 3 addresses the situation when a salaried employee works exactly 40 hours. The system pays the base salary, as was the case for rule 1. For an hourly worker who has worked exactly 40 hours, rule 4 calculates the hourly wage. Rule 5 pays the base salary for salaried employees who work more than 40 hours. Rule 5 has the same action as rules 1 and 3 and governs behavior with regard to salaried employees. The number of hours worked does not affect the outcome for rules 1, 3, or 5. For these rules, hours worked is an indifferent condition in that its value does not affect the action taken. Rule 6 calculates hourly pay and overtime for an hourly worker who has worked more than 40 hours.

Because of the indifferent condition for rules 1, 3, and 5, we can reduce the number of rules by condensing rules 1, 3, and 5 into one rule, as shown in Figure 7-19. The indifferent condition is represented with a dash. Whereas we started with a deci- sion table with six rules, we now have a simpler table that conveys the same informa- tion with only four rules.

In constructing these decision tables, we have actually followed a set of basic procedures:

1. Name the conditions and the values that each condition can assume. Determine all of the conditions that are relevant to your problem and then determine all of the values each condition can take. For some conditions, the values will be simply “yes” or “no” (called a limited entry). For others, such as the conditions in Figures 7-18 and 7-19, the conditions may have more values (called an extended entry).

2. Name all possible actions that can occur. The purpose of creating decision tables is to determine the proper course of action given a particular set of conditions.

Indifferent condition In a decision table, a condition whose value does not affect which actions are taken for two or more rules.

FIGURE 7-18 Complete decision table for payroll system example

Conditions/ Rules Courses of Action

1 3 4 5 6

Condition Employee type S

H S H S H Stubs

Hours worked <4 0 <4 0 40 40 >4 0 >4 0

Action Pay base salary X X X Stubs

Calculate hourly wage X X X

XCalculate overtime

Produce absence report X

FIGURE 7-19 Reduced decision table for payroll system example

Conditions/ Rules Courses of Action

1 2 3 4

Employee type S H H H

Hours worked – < 40 40 >4 0

Pay base salary X

Calculate hourly wage X X X

XCalculate overtime

Produce absence report X

M07_VALA1629_09_GE_C07.indd 224 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 225

3. List all possible rules. When you first create a decision table, you have to create an exhaustive set of rules. Every possible combination of conditions must be repre- sented. It may turn out that some of the resulting rules are redundant or make no sense, but these determinations should be made only after you have listed every rule so that no possibility is overlooked. To determine the number of rules, mul- tiply the number of values for each condition by the number of values for every other condition. In Figure 7-18, we have two conditions, one with two values and one with three, so we need 2 × 3, or 6, rules. If we added a third condition with three values, we would need 2 × 3 × 3, or 18, rules.

When creating the table, alternate the values for the first condition, as we did in Figure 7-18 for type of employee. For the second condition, alternate the values but repeat the first value for all values of the first condition, then repeat the second value for all values of the first condition, and so on. You essentially follow this procedure for all subsequent conditions. Notice how we alternated the values of hours worked in Figure 7-18. We repeated “<40” for both values of type of employee, “S” and “H.” Then we repeated “40,” and then “>40.”

4. Define the actions for each rule. Now that all possible rules have been identified, pro- vide an action for each rule. In our example, we were able to figure out what each action should be and whether all of the actions made sense. If an action doesn’t make sense, you may want to create an “impossible” row in the action stubs in the table to keep track of impossible actions. If you can’t tell what the system ought to do in that situation, place question marks in the action stub spaces for that particular rule.

5. Simplify the decision table. Make the decision table as simple as possible by removing any rules with impossible actions. Consult users on the rules where system actions aren’t clear and either decide on an action or remove the rule. Look for patterns in the rules, especially for indifferent conditions. We were able to reduce the number of rules in the payroll example from six to four, but greater reductions are often possible.

Let’s look at an example from Hoosier Burger. The Mellankamps are trying to determine how they reorder food and other items they use in the restaurant. If they are going to automate the inventory control functions at Hoosier Burger, they need to articulate their reordering process. In thinking through the problem, the Mel- lankamps realize that how they reorder depends on whether the item is perishable. If an item is perishable, such as meat, vegetables, or bread, the Mellankamps have a standing order with a local supplier stating that a prespecified amount of food is delivered each weekday for that day’s use and each Saturday for weekend use. If the item is not perishable, such as straws, cups, and napkins, an order is placed when the stock on hand reaches a certain predetermined minimum reorder quantity. The Mel- lankamps also realize the importance of the seasonality of their work. Hoosier Burger’s business is not as good during the summer months when the students are off campus as it is during the academic year. They also note that business falls off during Christ- mas and spring break. Their standing orders with all their suppliers are reduced by specific amounts during the summer and holiday breaks. Given this set of conditions and actions, the Mellankamps put together an initial decision table (see Figure 7-20).

Notice three things about Figure 7-20. First, notice how the values for the third condition have been repeated, providing a distinctive pattern for relating the values for all three conditions to each other. Every possible rule is clearly provided in this table. Second, notice that we have 12 rules. Two values for the first condition (type of item) times 2 values for the second condition (time of week) times 3 values for the third condition (season of year) equals 12 possible rules. Third, notice how the action for nonperishable items is the same, regardless of day of week or time of year. For nonperishable goods, both time-related conditions are indifferent. Collapsing the decision table accordingly gives us the decision table in Figure 7-21. Now there are only 7 rules instead of 12.

Hoosier Burger

M07_VALA1629_09_GE_C07.indd 225 08/04/2020 16:40

226 PART III ANALYSIS

You have now learned how to draw and simplify decision tables. You can also use decision tables to specify additional decision-related information. For example, if the actions that should be taken for a specific rule are more complicated than one or two lines of text can convey or if some conditions need to be checked only when other conditions are met (nested conditions), you may want to use separate, linked decision tables. In your original decision table, you can specify an action in the action stub that says “Perform Table B.” Table B could contain an action stub that returns to the original table, and the return would be the action for one or more rules in Table B. Another way to convey more information in a decision table is to use numbers that indicate sequence rather than Xs where rules and action stubs intersect. For example, for rules 3 and 4 in Figure 7-21, it would be important for the Mellankamps to account for the summer reduction to modify the existing standing order for supplies. “Sum- mer reduction” would be marked with a “1” for rules 3 and 4, whereas “Standing daily order” would be marked with a “2” for rule 3, and “Standing weekend order” would be marked with a “2” for rule 4.

FIGURE 7-20 Complete decision table for Hoosier Burger’s inventory reordering

Conditions/ Rules Courses of Action

1 2 3 4 6 85 7 9 10 11 12

Type of item P PN N N NP P P PN N

Time of week D D D D D DW W W W W W

Season of year A A A A S S S S H H H H

Standing daily order X X X

Standing weekend order X X X

Minimum order quantity X X X X

X X

Holiday reduction

Summer reduction XX

Type of item: Season of year: P = perishable D = weekday

Time of week: A = academic year

N = nonperishable W = weekend S = summer H = holiday

FIGURE 7-21 Reduced decision table for Hoosier Burger’s inventory reordering

Conditions/ Rules Courses of Action

1 2 3 4 5 6 7

Type of item P P P P P P N

Time of week D W D W D W –

Season of year A A S S H H –

Standing daily order X X X

Standing weekend order X X X

Minimum order quantity X

Holiday reduction X X

Summer reduction XX

M07_VALA1629_09_GE_C07.indd 226 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 227

You have seen how decision tables can model the relatively complicated logic of a process. As such, decision tables are compact; you can pack a lot of information into a small table. Decision tables also allow you to check for the extent to which your logic is complete, consistent, and not redundant.

ELECTRONIC COMMERCE APPLICATION: PROCESS MODELING USING DATA FLOW DIAGRAMS Process modeling for an Internet-based electronic commerce application is no dif- ferent than the process followed for other applications. In Chapter 6, you read how Pine Valley Furniture (PVF) determined the system requirements for their WebStore project, a project to sell furniture products over the Internet. In this section, we ana- lyze the WebStore’s high-level system structure and develop a level-0 DFD for those requirements.

Process Modeling for Pine Valley Furniture’s WebStore

After completing the Joint Application Design ( JAD) session, senior systems analyst Jim Woo went to work on translating the WebStore system structure into a DFD. His first step was to identify the level-0—major system—processes. To begin, he care- fully examined the outcomes of the JAD session that focused on defining the system structure of the WebStore system. From this analysis, he identified six high-level pro- cesses that would become the foundation of the level-0 DFD. These processes, listed in Table 7-4, were the “work” or “action” parts of the Web site. Note that each of these processes corresponds to the major processing items listed in the system structure.

Next, Jim determined that it would be most efficient if the WebStore system exchanged information with existing PVF systems rather than capture and store redundant information. This analysis concluded that the WebStore should exchange information with the Purchasing Fulfillment System (a system for tracking orders [see Chapter 3]) and the Customer Tracking System (a system for managing customer information). These two existing systems will be “sources” (providers) and “sinks” (receivers) of information for the WebStore system. When a customer opens an account, his or her information will be passed from the WebStore system to the Cus- tomer Tracking System. When an order is placed, information will be stored in the Purchasing Fulfillment System. When a customer requests status information on a prior order, information will be retrieved from the Purchase Fulfillment System.

WebStore System Processes

❑❑ Main Page • Product Line (Catalog)

✓ Desks ✓ Chairs ✓ Tables ✓ File Cabinets

• Shopping Cart • Checkout • Account Profile • Order Status/History • Customer Comments

❑❑ Company Information ❑❑ Feedback ❑❑ Contact Information

Information Display (minor/no processes) 1.0 Browse Catalog 2.0 Select Item for Purchase

3.0 Display Shopping Cart 4.0 Check Out Process Order 5.0 Add/Modify Account Profile 6.0 Order Status Request Information Display (minor/no processes)

TABLE 7-4 System Structure of the WebStore and Corresponding Level-0 Processes

PINE VALLEY FURNITURE

M07_VALA1629_09_GE_C07.indd 227 08/04/2020 16:40

228 PART III ANALYSIS

Finally, Jim found that the system would need to access two additional data sources. First, in order to produce an online product catalog, the system would need to access the inventory database. Second, to store the items a customer wanted to purchase in the WebStore’s shopping cart, a temporary database would need to be cre- ated. Once a transaction is completed, the shopping cart data can be deleted. With this information, Jim was able to develop the level-0 DFD for the WebStore system, which is shown in Figure 7-22. He then felt that he had a good understanding of how infor- mation would flow through the WebStore, of how a customer would interact with the system, and of how the WebStore would share information with existing PVF systems. Each of these high-level processes would eventually need to be further decomposed before system design could proceed. Yet, before doing that, he wanted to get a clear picture of exactly what data were needed throughout the entire system. We will dis- cover the outcomes of this analysis activity—conceptual data modeling—in Chapter 8.

FIGURE 7-22 Level-0 DFD for the WebStore

PURCHASING FULFILLMENT

SYSTEMCUSTOMER TRACKING

SYSTEM

D1 Inventory D2 Shopping Cart

CUSTOMER

Cart ID/ Item Profile

Item Profile Purchase

Request Product

Item

Product Item

Request

InvoiceCheck Out/ Customer

Item Profile

Cart ID/ Item Profile

Order Number/ Return Code

Order Number

Order Status

Information

Order Status

Information

Product Item to Remove

Item to Remove

Items in Cart

Item Profile

Cart Request

Customer ID

Customer Information

Customer Information/ID

Customer Information

Order

6.0

5.0

2.0

3.01.0

4.0

Add/Modify Account Profile

Browse Catalog

Check Out Process Order

Order Status

Request

Display Shopping

Cart

Select Item for

Purchase

M07_VALA1629_09_GE_C07.indd 228 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 229

SUMMARY Processes can be modeled in many different ways, but this chapter has focused on data flow diagrams, or DFDs. DFDs are very useful for representing the overall data flows into, through, and out of an information system. DFDs rely on four symbols to represent the four conceptual components of a process model: data flows, data stores, processes, and sources/sinks. DFDs are hierarchical in nature, and each level of a DFD can be decomposed into smaller, simpler units on a lower-level diagram. You begin process modeling by con- structing a context diagram, which shows the entire system as a single process. The next step is to generate a level-0 dia- gram, which shows the most important high-level processes in the system. You then decompose each process in the level-0 diagram, as warranted, until it makes no sense to go any fur- ther. When decomposing DFDs from one level to the next, it is important that the diagrams be balanced; that is, inputs and outputs on one level must be conserved on the next level.

DFDs should be mechanically correct, but they should also accurately reflect the information system being modeled. To that end, you need to check DFDs for completeness and consistency and draw them as if the system being modeled were timeless. You should be willing to revise DFDs several

times. Complete sets of DFDs should extend to the primi- tive level, where every component reflects certain irreducible properties; for example, a process represents a single database operation and every data store represents data about a single entity. Following these guidelines, you can produce DFDs that can be used to analyze the gaps between existing and desired procedures and between current and new systems.

Decision tables are a graphical method of represent- ing process logic. In decision tables, conditions are listed in the condition stubs, possible actions are listed in the action stubs, and rules link combinations of conditions to the actions that should result. Analysts reduce the complex- ity of decision tables by eliminating rules that do not make sense and by combining rules with different conditions.

Although analysts have been modeling processes for information systems for over 30 years, dating back at least to the beginnings of the philosophy of structured analysis and design, it is just as important for electronic commerce appli- cations as it is for more traditional systems. Future chapters will show, as this one did, how traditional tools and tech- niques developed for structured analysis and design provide powerful assistance for electronic commerce development.

Match each of the key terms above with the definition that best fits it.

____ A picture of the movement of data between external entities and the processes and data stores within a system.

____ The part of a decision table that lists the actions that result for a given set of conditions.

____ The conservation of inputs and outputs to a DFD process when that process is decomposed to a lower level.

____ A DFD that represents a system’s major processes, data flows, and data stores at a high level of detail.

____ The origin and/or destination of data; sometimes referred to as external entities.

____ In a decision table, a condition whose value does not affect which actions are taken for two or more rules.

____ An overview of an organizational system that shows the sys- tem boundary, external entities that interact with the sys- tem, and the major information flows between the entities and the system.

____ The lowest level of decomposition for a DFD.

____ The extent to which all necessary components of a DFD have been included and fully described.

____ A matrix representation of the logic of a decision; it speci- fies the possible conditions for the decision and the result- ing actions.

____ The extent to which information contained on one level of a set of nested DFDs is also included on other levels.

____ A DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram.

____ The part of a decision table that lists the conditions relevant to the decision.

____ The work or actions performed on data so that they are transformed, stored, or distributed.

____ Data at rest, which may take the form of many different physical representations.

KEY TERMS

7.1 Action stubs 7.2 Balancing 7.3 Condition stubs 7.4 Context diagram 7.5 Data flow diagram (DFD) 7.6 Data store

7.7 Decision table 7.8 DFD completeness 7.9 DFD consistency 7.10 Functional decomposition 7.11 Gap analysis 7.12 Indifferent condition

7.13 Level-0 diagram 7.14 Level-n diagram 7.15 Primitive DFD 7.16 Process 7.17 Rules 7.18 Source/sink

M07_VALA1629_09_GE_C07.indd 229 08/04/2020 16:40

230 PART III ANALYSIS

____ The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD.

____ The part of a decision table that specifies which actions are to be followed for a given set of conditions.

____ An iterative process of breaking the description of a sys- tem down into finer and finer detail, which creates a set of charts in which one process on a given chart is explained in greater detail on another chart.

PROBLEMS AND EXERCISES 7.31 Draw a context diagram corresponding to the level-0 dia-

gram found in Figure 7-3b.

7.32 Draw a DFD for a small e-commerce Website according to the following information: A customer enters the shop and decides to place an order. A clerk then sends an e-mail to the appropriate supplier. In addition, the clerk inserts a copy of the e-mail in a binder. The client gets a receipt of the order. The owner of the company sends the order binder to the accountant from time to time. Draw a level-0 dataflow diagram for this system. (Use your own imagination and rea- soning in case you feel additional information is needed.)

7.33 Evaluate your level-0 DFD from Problem and Exercise 7-32 using the rules for drawing DFDs in this chapter. Edit your DFD so that it does not break any of these rules.

7.34 Choose an example like the one in Problem and Exercise 7-32 and draw a context diagram. Decompose this diagram until it does not make sense to continue. Be sure that your diagrams are balanced.

7.35 Based on the information below, draw a context diagram and a level-0 diagram for the entire system. In addition, draw a level-1 diagram and a level-2 diagram for one part of the system.

• A person sends a letter to another person using postal services.

• The letter should be franked (stamped), sorted, and delivered to the recipient.

• When a letter has been franked, it is noted in a table in a database.

• A letter with an unreadable address is handled manually.

7.36 This assignment concerns drawing a dataflow diagram for a new loaning system for a library. Draw a context diagram and a level-0 diagram for the new loaning system according to the following:

When a person with a library card (referred to as “visitor”) has found a book to borrow, the card is read by a machine. The visitor then scans the book(s) in a machine for automatic registration. When all books have been registered for borrowing, a receipt is printed, and information regarding the books is inserted in the library database. Reminders about loans soon expiring or books not returned on time are sent out from the database on a daily basis. There is also a librarian, who performs searches for visitors by querying ( = asking) the database, which returns the catalog information.

If you miss any information, make assumptions that feel reasonable.

7.37 Consider the DFD in Figure 7-24. List three errors (rule violations) on this DFD.

REVIEW QUESTIONS 7.19 What are the symbols making up a DFD?

7.20 When drawing a DFD of the symbols Process, Data store, and External entity, one must always be placed between the others. Which one, and why?

7.21 What is decomposition? What is balancing? How can you determine if DFDs are not balanced?

7.22 As the name clearly states, drawing a DFD is about display- ing the transference and manipulation of data. However, equally important is discovering where most of the system’s code will be needed. How does drawing DFDs help in find- ing out what code needs to be written?

7.23 In a context diagram and a level-0 diagram, some objects will remain exactly the same. Which ones? What is the reason for this?

7.24 State which of the following a DFD is not good at: showing progression and transformation of information or showing the timing of different processes.

7.25 Explain the guidelines for deciding when to stop decom- posing DFDs.

7.26 Which of the following statements is true?

a. A data flow to a data store means retrieve or use. b. Many processes can, in a way, be viewed as context dia-

grams of their own. c. A data store can be directly connected to another data

store. d. In the notation used in this chapter, a process doesn’t

have to be numbered.

7.27 What part of a context diagram must also appear in its corresponding level-0 diagram?

7.28 What are the three headings or keywords used in a decision table?

7.29 In a certain decision table, there are eight rules and three of them yield the same result. How many rules are there in the reduced decision table?

7.30 What is the formula that is used to calculate the number of rules a decision table must cover?

M07_VALA1629_09_GE_C07.indd 230 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 231

FIGURE 7-23 Class registration system for Problem and Exercise 7.35Class Schedule

Class Schedule

Course Request

List of Courses

Course Request

List of Courses

Possible Classes

Scheduled Classes

Context Diagram

Level-0 Diagram

To Student

From Student

From Department

Class Registration

System

Student

Department Roster of ClassesD1

Receive Course Request

Check for

Availability

Receive Course

Lists

Class RosterD2

FIGURE 7-24 DFD for Problem and Exercise 7.37

DF2

DF5

DF4

DF1

DF2

DF3DF6 DS1

1.0

2.0

7.38 Consider the three DFDs in Figure 7-25. List three errors (rule violations) on these DFDs.

7.39 Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all the details of the employee hiring system described in the following narrative. You must draw at least a context and a level-0 diagram. If you

discover while drawing these diagrams that the narrative is incomplete, make up reasonable explanations to complete the story. Supply these extra explanations along with the diagrams.

Projects, Inc., is an engineering firm with approxi- mately 500 engineers of different types. The company

M07_VALA1629_09_GE_C07.indd 231 08/04/2020 16:40

232 PART III ANALYSIS

FIGURE 7-25 DFD for Problem and Exercise 7.38

DF2

DF5

DF4DF1

DF3

DF6

Level 0

Level 1

Level 2

DF7

DF9DF1 DF2

DF8

DF6

DF9

DF8 DF10

DF11 DF12

DF2

DS1

DS2

P2P1

DS2

P1.2P1.1

P1.4.1 P1.4.3

P1.3

P1.4.2

P1.4

keeps records on all employees, their skills, assigned projects, and the departments they work in. New employees are hired by the personnel manager based on data in an application form and evaluations col- lected from other managers who interview the job can- didates. Prospective employees may apply at any time. Engineering managers notify the personnel manager when a job opens and list the characteristics necessary to be eligible for the job. The personnel manager com- pares the qualifications of the available pool of appli- cants with the characteristics of an open job and then schedules interviews between the manager in charge of the open position and the three best candidates from the pool. After receiving evaluations on each interview

from the manager, the personnel manager makes the hiring decision based upon the evaluations and appli- cations of the candidates and the characteristics of the job and then notifies the interviewees and the manager about the decision. Applications of rejected applicants are retained for one year, after which time the applica- tion is purged. When hired, a new engineer completes a nondisclosure agreement, which is filed with other information about the employee.

7.40 Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all of the details of the system described in the following narrative. In draw- ing these diagrams, if you discover that the narrative is

M07_VALA1629_09_GE_C07.indd 232 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 233

incomplete, make up reasonable explanations to make the story complete. Supply these extra explanations along with the diagrams.

Maximum Software is a developer and supplier of soft- ware products to individuals and businesses. As part of their operations, Maximum provides a 1-800 help desk line for clients who have questions about software purchased from Maximum. When a call comes in, an operator inquires about the nature of the call. For calls that are not truly help desk functions, the opera- tor redirects the call to another unit of the company (such as Order Processing or Billing). Because many customer questions require in-depth knowledge of a product, help desk consultants are organized by prod- uct. The operator directs the call to a consultant skilled on the software that the caller needs help with. Because a consultant is not always immediately available, some calls must be put into a queue for the next available consultant. Once a consultant answers the call, the consultant determines if this is the first call from this customer about a particular problem. If it is, the con- sultant creates a new call report to keep track of all information about the problem. If it is not the first call about a problem, the consultant asks the customer for a call report number and retrieves the open call report to determine the status of the inquiry. If the caller does not know the call report number, the consultant col- lects other identifying information such as the caller’s name, the software involved, or the name of the con- sultant who has handled the previous calls on the prob- lem in order to conduct a search for the appropriate call report. If a resolution of the customer’s problem has been found, the consultant informs the client as to what that resolution is, indicates on the report that the customer has been notified, and closes out the report. If resolution has not been discovered, the consultant finds out if the consultant who handled the previous call for this problem is on duty. If so, he or she transfers the call to the other consultant (or puts the call into the queue of calls waiting to be handled by that con- sultant). Once the proper consultant receives the call, that consultant records any new details the customer may have. For continuing problems and for new call reports, the consultant tries to discover an answer to the problem by using the relevant software and looking up information in reference manuals. If the consultant can now resolve the problem, the consultant tells the customer how to deal with the problem and closes the call report. Otherwise, the consultant files the report for continued research and tells the customer that someone at Maximum will get back to him or her, and that if the customer discovers new information about the problem, he or she should call Maximum with the information, identifying the problem with a specified call report number.

Analyze the DFDs you created in the first part of this ques- tion. What recommendations for improvements in the help desk system at Maximum can you make based on this analysis? Draw new logical DFDs that represent the requirements you would suggest for an improved help desk

system. Remember, these are to be logical DFDs, so consider improvements independent of technology that can be used to support the help desk.

7.41 Develop a context diagram and level-0 diagram for the hos- pital pharmacy system described in the following narrative. If you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Supply these extra explanations along with the diagrams.

The pharmacy at Mercy Hospital fills medical prescrip- tions for all hospital patients and distributes these medi- cations to the nurse stations responsible for the patients’ care. Prescriptions are written by doctors and sent to the pharmacy. A pharmacy technician reviews each prescription and sends it to the appropriate pharmacy station. Prescriptions for drugs that must be formulated (made on-site) are sent to the lab station, prescriptions for off-the-shelf drugs are sent to the shelving station, and prescriptions for narcotics are sent to the secure station. At each station, a pharmacist reviews the order, checks the patient’s file to determine the appropriate- ness of the prescription, and fills the order if the dos- age is at a safe level and it will not negatively interact with the other medications or allergies indicated in the patient’s file. If the pharmacist does not fill the order, the prescribing doctor is contacted to discuss the situ- ation. In this case, the order may ultimately be filled, or the doctor may write another prescription depend- ing on the outcome of the discussion. Once filled, a prescription label is generated listing the patient’s name, the drug type and dosage, an expiration date, and any special instructions. The label is placed on the drug container, and the order is sent to the appropri- ate nurse station. The patient’s admission number, the drug type and amount dispensed, and the cost of the prescription are then sent to the Billing department.

7.42 Develop a context diagram and a level-0 diagram for the contracting system described in the following narrative. If you discover that the narrative is incomplete, make up rea- sonable explanations to complete the story. Supply these extra explanations along with the diagrams.

Government Solutions Company (GSC) sells computer equipment to federal government agencies. Whenever a federal agency needs to purchase equipment from GSC, it issues a purchase order against a standing con- tract previously negotiated with the company. GSC holds several standing contracts with various federal agencies. When a purchase order is received by GSC’s contracting officer, the contract number referenced on the purchase order is entered into the contract data- base. Using information from the database, the con- tracting officer reviews the terms and conditions of the contract and determines whether the purchase order is valid. The purchase order is valid if the contract has not expired, the type of equipment ordered is listed on the original contract, and the total cost of the equipment does not exceed a predetermined limit. If the purchase order is not valid, the contracting officer sends the pur- chase order back to the requesting agency with a letter stating why the purchase order cannot be filled, and

M07_VALA1629_09_GE_C07.indd 233 08/04/2020 16:40

234 PART III ANALYSIS

a copy of the letter is filed. If the purchase order is valid, the contracting officer enters the purchase order number into the contract database and flags the order as outstanding. The purchase order is then sent to the Order Fulfillment department. Here the inventory is checked for each item ordered. If any items are not in stock, the Order Fulfillment department creates a report listing the items not in stock and attaches it to the purchase order. All purchase orders are forwarded to the warehouse, where the items in stock are pulled from the shelves and shipped to the customer. The warehouse then attaches to the purchase order a copy of the shipping bill listing the items shipped and sends it to the contracting officer. If all items were shipped, the contracting officer closes the outstanding purchase order record in the database. The purchase order, ship- ping bill, and exception report (if attached) are then filed in the contracts office.

7.43 Develop a context diagram and as many nested DFDs as you consider necessary to represent all the details of the training logistics system described in the following narrative. If you discover that the narrative is incomplete, make up reason- able explanations to complete the story. Supply these extra explanations along with the diagrams.

Training, Inc., conducts training seminars in major U.S. cities. For each seminar, the Logistics department must make arrangements for the meeting facilities, the training consultant’s travel, and the shipment of any seminar materials. For each scheduled seminar, the Bookings department notifies the logistics coordina- tor of the type of seminar, the dates and city location, and the name of the consultant who will conduct the training. To arrange for meeting facilities, the logistics coordinator gathers information on possible meeting sites in the scheduled city. The meeting site location decision is made based on date availability, cost, type of meeting space available, and convenience of the location. Once the site decision is made, the coordina- tor speaks with the sales manager of the meeting facil- ity to reserve the meeting room(s), plan the seating arrangement(s), and reserve any necessary audiovisual equipment. The coordinator estimates the number and size of meeting rooms, the type of seating arrange- ments, and the audiovisual equipment needed for each seminar from the information kept in a logistics data- base on each type of seminar offered and the number of anticipated registrants for a particular booking. After negotiations are conducted by the logistics coordinator and the sales manager of the meeting facility, the sales manager creates a contract agreement specifying the negotiated arrangements and sends two copies of it to the logistics coordinator. The coordinator reviews the agreement and approves it if no changes are needed. One copy of the agreement is filed and the other copy is sent back to the sales manager. If changes are needed, the agreement copies are changed and returned to the sales manager for approval. This approval process con- tinues until both parties have approved the agreement. The coordinator must also contact the training consul- tant to make travel arrangements. First, the coordinator

reviews the consultant’s travel information in the logis- tics database and researches flight schedules. Then the consultant is contacted to discuss possible travel arrangements; subsequently, the coordinator books a flight for the consultant with a travel agency. Once the consultant’s travel arrangements have been completed, a written confirmation and itinerary are sent to the con- sultant. Two weeks before the date of the seminar, the coordinator determines what, if any, seminar materials (e.g., transparencies, training guides, pamphlets, etc.) need to be sent to the meeting facility. Each type of seminar has a specific set of materials assigned to it. For some materials, the coordinator must know how many participants have registered for the seminar in order to determine how many to send. A request for materials is sent to the Materials-Handling department, where the materials are gathered, boxed, and sent to the meet- ing address listed on the request. Once the requested materials have been shipped, a notification is sent to the logistics coordinator.

7.44 Look at the set of DFDs created in this chapter for Hoosier Burger’s food-ordering system. Represent the decision logic of one or more of the processes as decision tables.

7.45 What is the ultimate reason for simplifying decision tables?

7.46 In one company, the rules for buying personal comput- ers specify that if the purchase is over $15,000, it has to go out for bid, and the Request for Proposals (RFP) must be approved by the Purchasing department. If the purchase is under $15,000, the personal computers can simply be bought from any approved vendor; however, the Purchase Order must still be approved by the Purchasing depart- ment. If the purchase goes out for bid, there must be at least three proposals received for the bid. If not, the RFP must go out again. If there are still not enough proposals, then the process can continue with the one or two vendors that have submitted proposals. The winner of the bid must be on an approved list of vendors for the company and must not have any violations against them for affirmative action or environmental matters. At this point, if the proposal is complete, the Purchasing department can issue a Purchase Order. Draw a decision table to represent the logic in this process. Notice the similarities between the text in this ques- tion and the format of your answer.

7.47 In a relatively small company that sells thin, electronic key- pads and switches, the rules for selling products specify that sales representatives are assigned to unique regions of the country. Sales come either from cold calling, referrals, or current customers with new orders. A sizable portion of their business comes from referrals from larger com- petitors who send their excess and/or “difficult” projects to this company. The company tracks these referrals and returns the favors to these competitors by sending business their way. The sales reps receive a 10 percent commission on actual purchases, not on orders, in their region. They can collaborate on a sale with reps in other regions and share the commissions, with 8 percent going to the “home” rep and 2 percent going to the “visiting” rep. For any sales beyond the rep’s previously stated and approved individual annual sales goals, he or she receives an additional 5 percent

M07_VALA1629_09_GE_C07.indd 234 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 235

commission, an additional end-of-the-year bonus deter- mined by management, and a special vacation for his or her family. Customers receive a 10 percent discount for any purchases over $100,000 per year, which are factored into the rep’s commissions. In addition, the company focuses on customer satisfaction with the product and service, so there is an annual survey of customers in which they rate the sales rep. These ratings are factored into the bonuses such that a high rating increases the bonus amount, a mod- erate rating does nothing, and a low rating can lower the bonus amount. The company also wants to ensure that the reps close all sales. Any differences between the amount of orders and actual purchases are also factored into the rep’s bonus amount. As best you can, present the logic of this business process using a decision table. Write down any assumptions you have to make.

7.48 The following is an example that demonstrates the rules of the tenure process for faculty at many universities. Present the logic of this business using a decision table. Write down any assumptions you have to make.

A faculty member applies for tenure in his or her sixth year by submitting a portfolio summarizing his or her work. In rare circumstances, a faculty member can come up for tenure earlier than the sixth year, but only if the faculty member has the permission of the department chair and college dean. New professors who have worked at other universities before taking their current jobs rarely, if ever, start their new jobs with tenure. They are usually asked to undergo one probationary year during which they are evaluated; only then can they be granted tenure. Top administra- tors coming to a new university job, however, can often negotiate for retreat rights that enable them to become a tenured faculty member should their administrative post end. These retreat arrangements generally have to be approved by faculty. The tenure review process begins with an evaluation of the candidate’s portfolio by a committee of faculty within the candidate’s depart- ment. The committee then writes a recommendation on tenure and sends it to the department’s chairper- son, who then makes a recommendation and passes the portfolio and recommendation to the next level, a college-wide faculty committee. This committee does the same as the department committee and passes its recommendation, the department’s recommendation, and the portfolio to the next level, a university-wide fac- ulty committee. This committee does the same as the other two committees and passes everything to the pro- vost (or sometimes the academic vice president). The provost then writes his or her own recommendation and passes everything to the president, the final deci- sion maker. This process, from the time the candidate creates his or her portfolio until the time the president makes a decision, can take an entire academic year. The focus of the evaluation is on research, which could be grants, presentations, and publications, though pref- erence is given to empirical research that has been published in top-ranked, refereed journals and makes a contribution to the field. The candidate must also do well in teaching and service (i.e., to the university, the

community, or the discipline), but the primary empha- sis is on research.

7.49 An organization is in the process of upgrading microcom- puter hardware and software for all employees. Hardware will be allocated to each employee in one of three pack- ages. The first hardware package includes a standard microcomputer with a color monitor of moderate resolu- tion and moderate storage capabilities. The second package includes a high-end microcomputer with a high-resolution color monitor and a great deal of RAM and ROM. The third package is a high-end notebook-sized microcomputer. Each computer comes with a network interface card so that it can be connected to the network for printing and e-mail. The notebook computers come with a modem for the same purpose. All new and existing employees will be evaluated in terms of their computing needs (e.g., the types of tasks they perform, how much and in what ways they can use the computer). Light users receive the first hardware package. Heavy users receive the second package. Some moderate users will receive the first package and some will receive the second package, depending on their needs. Any employee who is deemed to be primarily mobile (e.g., most of the sales force) will receive the third package. Each employee will also be considered for additional hardware. For example, those who need scanners and/or printers will receive them. A determination will be made regarding whether the user receives a color or black-and-white scanner and whether they receive a slow or fast or color or black-and-white printer. In addition, each employee will receive a suite of software that includes a word processor, a spreadsheet, and a presenta- tion maker. All employees will be evaluated for additional software needs. Depending on their needs, some will receive a desktop publishing package, some will receive a database management system (some will also receive a developer’s kit for the DBMS), and some will receive a programming language. Every 18 months, those employees with the high- end systems will receive new hardware, and their old systems will be passed on to those who previously had the standard systems. All those employees with the portable systems will receive new notebook computers. Present the logic of this business process using a decision table. Write down any assumptions you have to make.

7.50 Read the narratives in the next column and follow the direc- tions for each. If you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Supply these extra explanations along with your answers.

a. Samantha must decide which courses to register for this semester. She has a part-time job, and she is waiting to find out how many hours per week she will be working during the semester. If she works 10 hours or less per week, she will register for three classes, but if she works more than 10 hours per week, she will register for only two classes. If she registers for two classes, she will take one class in her major area and one elective. If she regis- ters for three classes, she will take two classes in her major area and one elective. Use a decision table to represent this logic.

b. Jerry plans on registering for five classes this semester: English Composition, Physics, Physics Lab, Java, and

M07_VALA1629_09_GE_C07.indd 235 08/04/2020 16:40

236 PART III ANALYSIS

REFERENCES

Celko, J. (1987, January). I. Data flow diagrams. Computer Lan- guage, 4, 41–43.

DeMarco, T. (1979). Structured analysis and system specification. Upper Saddle River, NJ: Prentice Hall.

Gane C., & Sarson, T. (1979). Structured systems analysis. Upper Saddle River, NJ: Prentice Hall.

Hammer, M., & Champy, J. (1993). Reengineering the corporation. New York: Harper Business.

Vessey, I., & Weber, R. (1986). Structured tools and conditional logic. Communications of the ACM, 29(1), 48–57.

Yourdon, E., & Constantine, L. L. (1979). Structured design. Upper Saddle River, NJ: Prentice Hall.

FIELD EXERCISES 7.53 Locate an information system that you are familiar with,

such as a sales or an inventory system for a workplace or an organization you have access to. Draw a DFD for a certain part of the system, such as a sales system or a student grading system. Draw the following:

a. A context diagram for the system b. A level-0 diagram for the system, with at least two

processes c. A level-1 diagram for a part of the system, having at least

two processes, such as 1.1 and 1.2

7.54 Interview several people in an organization about a particu- lar system. What is the system like now and what would they like to see changed? Create a complete set of DFDs for the system. Show your DFDs to some of the people you inter- viewed and ask for their reactions. What kinds of comments do they make? What kinds of suggestions?

7.55 Bring up the application(s) you may have at your school for drawing figures (such as Microsoft Visio). Investigate what kinds of symbols are available for drawing DFDs. Are they different or similar to the ones found in this chapter?

7.56 At an organization with which you have contact, ask one or more employees to draw a “picture” of the business process they interact with at that organization. Ask them to draw the process using whatever format suits them. Ask them to depict in their diagram each of the components of the process and the flow of information among these components at the high- est level of detail possible. What type of diagram have they drawn? In what ways does it resemble (and not resemble) a DFD? Why? When they have finished, help the employees to convert their diagram to a standard DFD. In what ways is the DFD stronger and/or weaker than the original diagram?

Music Appreciation. However, he is not sure if these classes are being offered this semester or if there will be timing conflicts. Also, two of the classes, Physics and Physics Lab, must be taken together during the same semester. Therefore, if he can register for only one of them, he will not take either class. If, for any reason, he cannot register for a class, he will identify and register for a different class to take its place and that fits his time schedule. Use a decision table that shows all rules to rep- resent this logic.

7.51 Mary is trying to decide which graduate programs she will apply to. She wants to stay in the southeastern region of the United States, but if a program is considered one of the top 10 in the country, she is willing to move to another part of the United States. Mary is interested in both the MBA and Master of MIS programs. An MBA program must have at least one well-known faculty member and meet her location requirements before she will consider applying to it. Addi- tionally, any program she applies to must offer financial aid, unless she is awarded a scholarship. Use a decision table to represent this logic.

7.52 At a local bank, loan officers must evaluate loan applications before approving or denying them. During this evaluation process, many factors regarding the loan request and the applicant’s background are considered. If the loan is for less than $2000, the loan officer checks the applicant’s credit report. If the credit report is rated good or excellent, the loan officer approves the loan. If the credit report is rated

fair, the officer checks to see if the applicant has an account at the bank. If the applicant holds an account, the applica- tion is approved; otherwise, the application is denied. If the credit report is rated poor, the application is denied. Loan applications for amounts between $2000 and $200,000 are divided into four categories: car, mortgage, education, and other. For car, mortgage, and other loan requests, the appli- cant’s credit report is reviewed and an employment check is made to verify the applicant’s reported salary income. If the credit report rating is poor, the loan is denied. If the credit report rating is fair, good, or excellent and the sal- ary income is verified, the loan is approved. If the salary income is not verifiable, the applicant is contacted and additional information is requested. In this case, the loan application, along with the additional information, is sent to the vice president for review and a final loan decision. For educational loans, the educational institution the applicant will attend is contacted to determine the estimated cost of attendance. This amount is then compared to the amount of the loan requested in the application. If the requested amount exceeds the cost of attendance, the loan is denied. Otherwise, education loan requests for amounts between $2000 and $34,999 are approved if the applicant’s credit rating is fair, good, or excellent. Education loan applications requesting amounts from $35,000 to $200,000 are approved only if the credit rating is good or excellent. All loan applica- tions for amounts greater than $200,000 are sent to the vice president for review and approval. Use a decision table to represent this logic.

M07_VALA1629_09_GE_C07.indd 236 08/04/2020 16:40

237

object-oriented Analysis and Design

Appendix

7A use cases*

7A.3 discuss process modeling with use cases for electronic commerce applications.

Learning Objectives After studying this section, you should be able to

7A.1 explain use cases and use case diagrams and how they can be used to model system functionality;

7A.2 present the basic aspects of how to create written use cases; and

Here we will introduce you to use cases and use case diagrams. Use cases are a different way to model the functionality of a business process that facilitates the development of information systems to support that process. Although common in object-oriented sys- tems analysis and design, use case modeling can also be used with more traditional methods for modeling business processes. After learning the basics about use cases, including use case diagrams and written use cases, you will also learn how process modeling can be done with use cases for the analysis of electronic commerce applications.

USE CASES As Chapter 7 has shown, DFDs are powerful modeling tools that you can use to show a system’s functionality and the flow of data necessary for the system to perform its functions. DFDs are not the only way to show func- tionality, of course. Another way is use case modeling. Use case modeling helps analysts analyze the functional requirements of a system. Use case modeling helps devel- opers understand the functional requirements of the sys- tem without worrying about how those requirements will

Introduction

be implemented. The process is inherently iterative— analysts and users work together throughout the model development process to further refine their use case mod- els. Although use case modeling is most often associated with object-oriented systems analysis and design, the con- cept is flexible enough that it can also be used within more traditional approaches. In this section of the chapter, you will learn about use cases, use case diagrams and their con- stituent parts, and written use cases.

What Is a Use Case?

A use case shows the behavior or functionality of a system (see Figure 7-26). It consists of a set of possible sequences of interactions between a system and a user in a particular environment, possible sequences that are related to a par- ticular goal. A use case describes the behavior of a system under various conditions as the system responds to requests from principal actors. A principal actor initiates a request of the system, related to a goal, and the system responds. A use case can be stated as a present-tense verb phrase, containing the verb (what the system is supposed to do) and the object of the verb (what the system is to act on). For example, use case names would include Enter Sales Data, Compute Commission, Generate Quarterly Report.

* The original version of this appendix was written by Professor Atish P. Sinha.

M07_VALA1629_09_GE_C07.indd 237 08/04/2020 16:40

238 PART III ANALYSIS

As with DFDs, use cases do not reflect all of the system requirements; they must be augmented by documents that detail requirements, such as business rules, data fields and formats, and complex formulas.

A use case model consists of actors and use cases. An actor is an external entity that interacts with the system. It is someone or something that exchanges information with the system. For the most part, a use case represents a sequence of related actions initiated by an actor to accomplish a specific goal; it is a specific way of using the system ( Jacobson Christerson, Jonsson, & Overgaard, 1992). Note that there is a difference between an actor and a user. A user is anyone who uses the system. An actor, on the other hand, represents a role that a user can play. The actor’s name should indicate that role. An actor is a type or class of users; a user is a specific instance of an actor class playing the actor’s role. Note that the same user can play multiple roles. For example, if William Alvarez plays two roles, one as an instructor and the other as an adviser, we represent him as an instance of an actor called Instructor and as an instance of another actor called Adviser. Because actors are outside the system, you do not need to describe them in detail. The advantage of identifying actors is that it helps you to identify the use cases they carry out.

For identifying use cases, Jacobson et al. (1992) recommend that you ask the following questions:

• What are the main tasks performed by each actor? • Will the actor read or update any information in the system? • Will the actor have to inform the system about changes outside the system? • Does the actor have to be informed of unexpected changes?

Use Case Diagrams

Use cases help you capture the functional requirements of a system. As you saw in Chapter 6, during the requirements analysis stage, the analyst sits down with the intended users of a system and makes a thorough analysis of what functions they desire from the system. When it comes time to structure these requirements, the identified system functions are represented as use cases. For example, a university registration system has a use case for class registration and another for student billing. These use cases, then, represent the typical interactions the system has with its users.

A use case diagram is depicted diagrammatically, as in Figure 7-26. It is a picture that shows system behavior, along with the key actors that interact with the system. The use case diagram in Figure 7-26 is for a university registration system, which is shown

Use case A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users.

Actor An external entity that interacts with a system.

FIGURE 7-26 A use case diagram for a university registration system

Student Registration Clerk

Bursar’s O�ce

Instructor

Identify Prerequisite Courses Not Completed

<<extend>><< ex

ten d>

Bill Student

Use case diagram A picture showing system behavior, along with the key actors that interact with the system.

M07_VALA1629_09_GE_C07.indd 238 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 239

as a box. Outside the box are four actors—Student, Registration Clerk, Instructor, and Bursar’s Office—that interact with the system. An actor is shown using a stick- figure symbol with its name below it. Inside the box are four use cases—Register for Classes, Register for Special Class, Identify Prereq Courses Not Completed, and Bill Student—which are shown as ellipses with their names underneath. These use cases are performed by the actors outside the system.

Typically, a use case is initiated by an actor. For example, Bill Student is initiated by the Bursar’s Office. A use case can interact with actors other than the one that initi- ated it. The Bill Student use case, although initiated by the Bursar’s Office, interacts with the Students by mailing them tuition invoices. Another use case, Register for Classes, is carried out by two actors, Student and Registration Clerk. This use case performs a series of related actions aimed at registering a student for a class. Although use cases are typically initiated by actors, in some circumstances a use case is initiated by another use case. Such use cases are called abstract use cases. We will discuss these in more detail later in this appendix.

A use case represents complete functionality. You should not represent an indi- vidual action that is part of an overall function as a use case. For example, although submitting a registration form and paying tuition are two actions performed by users (students) in the university registration system, we do not show them as use cases because they do not specify a complete course of events; each of these actions is executed only as part of an overall function or use case. You can think of Submit Registration Form as one of the actions of the Register for Classes use case and of Pay Tuition as one of the actions of the Bill Student use case.

Definitions and Symbols

Use case diagramming is relatively simple because it involves only a few symbols. However, like DFDs and other relatively simple diagramming tools, these few sym- bols can be used to represent quite complex situations. Mastering use case diagram- ming takes a lot of practice. The key symbols in a use case diagram are illustrated in Figure 7-26 and explained below:

• Actor. As explained earlier, an actor is a role, not an individual. Individuals are instances of actors. One particular individual may play many roles simultane- ously. An actor is involved with the functioning of a system at some basic level. Actors are represented by stick figures.

• Use case. Each use case is represented as an ellipse. Each use case represents a single system function. The name of the use case can be listed inside the ellipse or just below it.

• System boundary. The system boundary is represented as a box that includes all of the relevant use cases. Note that actors are outside the system boundary.

• Connections. In Figure 7-26, note that the actors are connected to use cases with lines, and that use cases are connected to each other with arrows. A solid line connecting an actor to a use case shows that the actor is involved in that particular system function. The solid line does not mean that the actor is sending data to or receiving data from the use case. Note that all of the actors in a use case diagram are not involved in all the use cases in the system. The dotted-line arrows that connect use cases also have labels (there is an <<extend>> label on the arrows in Figure 7-26). These use case connections and their labels are explained next. Note that use cases do not have to be connected to other use cases. The arrows between use cases do not illustrate data or process flows.

• Extend relationship. An extend relationship extends a use case by adding new behaviors or actions. It is shown as a dotted-line arrow pointing toward the use case that has been extended and labeled with the <<extend>> symbol. The

Extend relationship An association between two use cases where one adds new behaviors or actions to the other.

M07_VALA1629_09_GE_C07.indd 239 08/04/2020 16:40

240 PART III ANALYSIS

dotted-line arrow does not indicate any kind of data or process flow between use cases. In Figure 7-26, for example, the Register for Special Class use case extends the Register for Classes use case by capturing the additional actions that need to be performed in registering a student for a special class. Registering for a special class requires prior permission of the instructor, in addition to the other steps carried out for a regular registration. You may think of Register for Classes as the basic course, which is always performed—independent of whether the extension is performed or not—and Register for Special Class as an alternative course, which is performed only under special circumstances.

Note also that the Instructor actor is needed for Register for Special Class. The Instructor is not needed for Register for Classes, which involves the Student and Registration Clerk actors only. The reason for not including the Instructor for normal registration but including him or her for registering for special classes is that certain additional actions are required from the Instructor for a special class. The Instructor’s approval is likely needed just to create an instance of a special class, and there may be other special requirements that need to be met for the class to be created. None of these special arrangements are necessary for normal registration, so the Instructor is not needed under normal circumstances.

Another example of an extend relationship is that between the Identify Prereq Courses Not Completed and Register for Classes use cases. The former extends the latter in situations where a student registering for a class has not taken the prerequi- site courses.

• Include relationship. Another kind of relationship between use cases is an include relationship, which arises when one use case uses another use case. An include relationship is shown diagrammatically as a dotted-line arrow pointed toward the use case that is being used. The line is labeled with the <<include>> sym- bol. The dotted-line arrow does not indicate any kind of data or process flow between use cases. An include relationship implies that the use case where the arrow originates uses the use case where the arrow ends while it is executing. Typically, the use case that is “included” represents a generic function that is common to many business functions. Rather than reproduce that functionality within every use case that needs it, the functionality is factored out into a sepa- rate use case that can then be used by other use cases. An example of an include relationship is shown in Figure 7-27.

Figure 7-27 shows a generic use case diagram for any business that needs to reorder supplies on a regular basis, such as a retail establishment or a restaurant. Because this is a generic use case diagram, its use cases are high level. Three different use cases are identified in the figure: Reorder Supplies, Produce Management Reports,

Include relationship An association between two use cases where one use case uses the functionality contained in the other.

FIGURE 7-27 A use case diagram featuring an include relationship

<<inc lude>

> <<

inc lud

e> >

Supplier

Manager

Reorder Supplies

Produce Management

Reports Track Sales and Inventory Data

M07_VALA1629_09_GE_C07.indd 240 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 241

and Track Sales and Inventory Data. Two actors have been identified: Supplier and Manager. Reorder Supplies involves the Manager and Supplier actors. A manager initi- ates the use case, which then sends requests to suppliers for various items. The Pro- duce Management Reports use case involves only the Manager actor. In Figure 7-27, the include relationship between the Reorder Supplies and Track Sales and Inventory Data use cases implies that the former uses the latter while executing. Simply put, when a manager reorders supplies, the sales and inventory data are tracked. The same data are also tracked when management reports are produced, so there is another include relationship between the Produce Management Reports and Track Sales and Inventory Data use cases.

The Track Sales and Inventory Data is a generalized use case, representing the common behavior among the specialized use cases Reorder Supplies and Produce Management Reports. When Reorder Supplies or Produce Management Reports is performed, the entire Track Sales and Inventory Data use case is used. Note, however, that it is used only when one of the specialized use cases is performed. Such a use case, which is never performed by itself, is called an abstract use case (Eriksson & Penker, 1998; Jacobson et al., 1992). An abstract case does not interact directly with an actor.

Figure 7-28 shows a use case diagram for Hoosier Burger. Several actors and use cases can be identified. The actor that first comes to mind is Customer, which represents the class of all customers who order food at Hoosier Burger; Order food is therefore represented as a use case. The other actor that is involved in this use case is Service Person. A specific scenario would represent a customer (an instance of Cus- tomer) placing an order with a service person (an instance of Service Person). At the end of each day, the manager of Hoosier Burger reorders supplies by calling suppliers. We represent this by a use case called Reorder Supplies, which involves the Manager and Supplier actors. A manager initiates the use case, which then sends requests to suppliers for various items.

FIGURE 7-28 Use case diagram for Hoosier Burger

Customer Service Person

Applicant

Supplier

Manager

Order Food

Hire Employee

Reorder Supplies

Track Sales and Inventory Data

Produce Management Reports

<<include>>

<<i nclu

de> >

M07_VALA1629_09_GE_C07.indd 241 08/04/2020 16:40

242 PART III ANALYSIS

Hoosier Burger also hires employees from time to time. Therefore, we have identified a use case, called Hire employee, in which two actors, Manager and Appli- cant, are involved. When a person applies for a job at Hoosier Burger, the manager makes a hiring decision.

Figure 7-28 provides another example of an include relationship, shown diagrammatically as a dashed line pointing toward the use case that is being used; the line is labeled with the <<include>> symbol. In Figure 7-28, for example, the include relationship between the Reorder Supplies and Track Sales and Inventory Data use cases implies that the former uses the latter while executing. When a man- ager reorders supplies, the sales and inventory data are tracked. The same data are also tracked when management reports are produced, so there is another include relationship between the Produce Management Reports and Track Sales and Inven- tory Data use cases.

Track Sales and Inventory Data is a generalized use case, representing the com- mon behavior among the specialized use cases Reorder Supplies and Produce Man- agement Reports. When a task like Reorder Supplies or Produce Management Reports is performed, the entire Track Sales and Inventory Data case is used. Note, however, that it is used only when one of the specialized use cases is performed. As you will recall, such a use case, which is never performed by itself, is called an abstract use case (Eriksson & Penker, 1998; Jacobson et al., 1992).

WRITTEN USE CASES Use case diagrams can represent the functionality of a system by showing use case names and the actors who are involved with them. The names of the use cases alone do not provide much of the information that is necessary to continue with analysis and to move on to the design phase. We also need to know what goes on inside each use case. The contents of a use case can be written in simple text, as was explained before for the Register for Classes use case in Figure 7-26. Others recommend tem- plates that force consideration of all of the important information one needs to have about use cases.

Cockburn (2001) recommends a specific template for writing use cases (Figure 7-29). Templates can be simpler than the one Cockburn recommends or more complicated. The point is not the format of the template so much as it is how the template encourages analysts to write complete use cases. Each heading reminds the analyst of the information that needs to be provided. In the template in Figure 7-29, it should be clear what information is being sought. The use case title and the name of the primary actor role, both of which were featured in the discussion of use case

FIGURE 7-29 A template for writing use cases

(Source: Cockburn, A. (2001). Writing effective use cases (1st ed.). Reprinted and Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey.)

Use Case Title:

Primary Actor:

Level:

Stakeholders:

Precondition:

Minimal Guarantee:

Success Guarantee:

Trigger:

Main Success Scenario:

Extensions:

M07_VALA1629_09_GE_C07.indd 242 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 243

diagrams, can be found on the use case diagram. The other information asked for in the template is new and will be discussed in more detail. The next section will deal exclusively with an important concept, the level of the use case. The following section will deal with the rest of the terms in the template.

Level

Level has to do with the level of detail at which the use case is being described. Level can range from high to low, where high is general and abstract, and low is detailed. Cockburn suggests five different levels of detail:

• White: As seen from the clouds, as if flying in a plane at 35,000 feet. • Kite: You’re still in the air, but more detail than at cloud level. • Blue: Also known as sea level. • Fish: This is below sea level with a lot of detail. The detail increases deeper

down, just like air pressure. • Black: This is the bottom of the sea where the maximum amount of detail is

provided.

Both the white and kite levels provide a summary of the use case goals. These goals are at a very high level. Goals at the white level are enterprise-wide, whereas at the kite level, the goals are those of a single business unit. Use cases at the white and kite levels are sometimes called summary use cases. Summary use cases do not include functional requirements. Use cases written at the blue level, or sea level, focus on user goals: What is the user trying to achieve in interacting with the system? Use cases written at the fish and black levels (sometimes called the clam level) are much more detailed and focus on subfunction goals. To see how the levels relate to each other, think about the view of the Caribbean Sea you would get if you were flying over it in a big plane like a 757. You can’t see the bottom of the sea, and at this altitude, you can’t even see much detail about the surface of the water. This would be the white level. Then think about how the same stretch of the Caribbean would look from about 100 feet up. This is the kite level. From the kite level, you would be able to see a lot more detail on the surface, compared to being in the 757 jet, but you still can’t see a lot of detail on the sea bottom, even with the water as clear as it is in a lot of the Caribbean. Now imagine the view of the same place from a rowboat. This is the user goal or sea-level view. You can see the bottom much more clearly now, but it’s still not completely clear. Now dive under the water and go down about 50 feet. You are a lot closer to the bottom—the fish level—and so now you can see a lot more detail at the bottom of the sea. But you don’t see the most detail possible until you are sitting on the bottom itself—the black or clam level.

To put all this into a business function perspective, let’s imagine five levels of use cases written for the Ford Motor Company. The white level use cases would serve an enterprise-wide goal (“Buy parts to build cars”), whereas a kite level use case would serve one business unit (“Buy parts to build Escorts”). If a system user has the role of procurement manager for the Escort model, the user goals at sea level might be “Order Escort parts from suppliers” and “Pay bills.” A fish level goal for the procure- ment system might include “Choose supplier for a part.” A black or clam level goal for the same system might include “Establish a secure connection.” Figure 7-30 shows the relationships among the levels.

The Rest of the Template

Next in the use case template is the list of stakeholders: those people who have some key interest in the development of the system. They would include the system’s users as well as the manager, other managers in the company, customers, stockholders, the vendors that supply the company, and so on. Stakeholders are important to identify

Level Perspective from which a use case description is written, typically ranging from high level to extremely detailed.

Stakeholder People who have a vested interest in the system being developed.

M07_VALA1629_09_GE_C07.indd 243 08/04/2020 16:40

244 PART III ANALYSIS

because they typically have some impact on what the system does and on how it is designed. It should be obvious that some stakeholders have more of a stake than oth- ers, and the most involved stakeholders are the ones that probably should be listened to first.

The next term in Cockburn’s template (Figure 7-29) is preconditions, which are those things the system must ensure are true before the use case can start. For example, in Figure 7-26, for the use case Register for Classes, students would not be allowed to register if they had any outstanding debts due to the university. No outstanding debts would be listed under preconditions for Register for Classes in its written use case template.

Next is minimal guarantee. According to Cockburn, the minimal guarantee is the least amount promised by the use case to the stakeholder. One way to determine what this should be is to ask, “What would make the stakeholder unhappy?” For some use cases, the minimal guarantee might be simply that nothing happens. The stake- holder would be unhappy because the system does not do what it is supposed to. However, no detrimental effects result either; no bad data are entered into the system, no data are lost, and the system does not crash. For many use cases, the best thing to offer for a minimal guarantee is to roll back the transaction to its original starting place; nothing is gained but no harm is done either.

A success guarantee lists what it takes to satisfy stakeholders if the use case is completed successfully. For example, in Figure 7-26, for the use case Bill Student, a success guarantee would involve the successful compilation of charges due from the student and the successful creation of an accurate invoice that reflects those charges. This does not imply that the student is happy with the result; he or she might think the charges are too high or too low (although rarely the latter). What is important is that the use case functioned correctly and achieved its goals.

Next is the slot in the template for trigger, the thing that initiates the use case. A trigger could be a phone call, a letter, or even a call from another use case. In the example of Bill Student, the trigger could be a message indicating that the class reg- istration process was complete.

The last item in Cockburn’s written use case template is extensions. Maybe the best way to think about an extension is as the “else statement” that follows an “if state- ment.” An extension is invoked only if its associated condition is encountered. In a written use case, the conditions that invoke extensions usually refer to some type of system failure. For example, if a use case involves access through the Internet and a network failure occurs so that the Internet connection is lost, what happens? If the system requires a log-in and the user provides the wrong account name, what hap- pens? If the user provides the wrong password, what happens? All of the actions that would follow these conditions would be listed in the use case template as extensions.

Preconditions Things that must be true before a use case can start.

Minimal guarantee The least amount promised to the stake- holder by a use case.

Success guarantee What a use case must do effectively in order to satisfy stakeholders.

Trigger Event that initiates a use case.

Extension The set of behaviors or functions in a use case that follow exceptions to the main success scenario.

FIGURE 7-30 Use case levels and detail when moving from top to bottom

(Source: George, J. F., Batra, D., Valacich, J. S., Hoffer, J. A. (2007). Object-oriented systems analysis and design (2nd ed.) (pp. 174, 168, 175, 172, 176, 177). Reprinted and Electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Buy parts to build cars

Buy parts to build Escorts

Order Escort parts from suppliers

Choose supplier for part

Encrypt data for secure transmission

M07_VALA1629_09_GE_C07.indd 244 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 245

Figure 7-31 shows a use case diagram for a reservation system. Figure 7-32 shows a finished, written use case, based on the reservation use case diagram. This use case description is written at the kite level, or summary level, which means that it shows only the user goals rather than the functional requirements. You’ll notice that five user goals are described, four of which are carried out by the customer, and this reflects the content of the use case diagram in Figure 7-31. Although Figure 7-31 is generic to any system that handles reservations, the written use case in Figure 7-32 is specific to hotel reservations. For hotel reservations made on the Web, certain simplifying assumptions particular to hotel reservations have been made, such as customers being required to provide one night’s deposit in order to hold the reservation. You’ll also notice that there is a list of extensions at the end of the written use case. There is at least one extension for each user goal, although the first function, searching for a room for a desired time period at a specific hotel, has two extensions. There is no set number of extensions required for a user goal. In fact, there is no requirement that a user goal has an extension at all.

ELECTRONIC COMMERCE APPLICATION: PROCESS MODELING USING USE CASES Jim Woo decided to try to model the functionality of the PVF WebStore application with a use case diagram. He identified six high-level functions that would be included in his use case diagram. Jim created a table that listed the main characteristics of the WebStore Web site in one column and the corresponding system functions in another column (Table 7-5). Note how these functions correspond to the major Web site characteristics listed in the system structure. These functions represent the “work” or “action” parts of the Web site. Jim noted that all the functions listed in his table involved the customer, so Jim realized that Customer would be a key actor in his use case diagram.

FIGURE 7-31 A use case diagram for a reservation system

(Source: George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object- oriented systems analysis and design (2nd Ed.) (pp. 174, 168, 175, 172, 176, 177). Reprinted and Electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Request Confirmation

Purchase Reservations

Authorize Credit Card Use

Make Reservations

Search Schedules

Reservation System

<<include>>

Customer

PINE VALLEY FURNITURE

M07_VALA1629_09_GE_C07.indd 245 08/04/2020 16:40

246 PART III ANALYSIS

In looking at the table, however, Jim realized that one of the key functions iden- tified in the JAD, Fill Order, was not represented in his table. He had to include it in the use case diagram, but it was clear to him that it was a back-office function and that it required adding another actor to the use case diagram. This actor would be the Shipping Clerk. Jim added Shipping Clerk to the right-hand side of his use case diagram. The finished diagram is shown in Figure 7-33.

FIGURE 7-32 Kite Level Written Use Case for Making a Hotel Room Reservation

(Source: George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object-oriented systems analysis and design (2nd Ed.) (pp. 174, 168, 175, 172, 176, 177). Reprinted and Electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Use Case Title: Browse catalog

Primary Actor: Customer

Level: Kite (summary)

Stakeholders: Customer, credit bureau

Precondition: Customer accesses the hotel Web site

Minimal Guarantee: Rollback of any uncompleted transaction

Success Guarantees: Reservation held with one night’s deposit

Trigger: Customer accesses hotel homepage

Main Success Scenario:

Extensions:

1a. Hotel property search function is not available. 1a1. Customer quits site 1b. Specific hotel room not available for desired time period. 1b1. Customer quits site. 1b2. Customer searches for di�erent hotel for desired time period. 1b3. Customer searches for same hotel for di�erent time period 2a. Making reservation transaction is interrupted. 2a1. Transaction rolled back. Customer starts again. 2a2. Transaction rolled back. Customer quits site. 3a. Holding reservation transaction is interrupted. 3a1. Transaction rolled back. Customer starts again. 3a2. Transaction rolled back. Customer quits site. 4a. Credit bureau cannot verify that customer has necessary credit. 4a1. Customer notified of issue. Transaction rolled back. Customer quits site. 4a2. Customer notified of issue. Transaction rolled back. Customer begins reservation process again with di�erent credit card. 5a. Confirmation of transaction is interrupted. 5a1. Customer seeks other means of confirmation. 5a2. Customer quits site.

1. Customer searches for hotel location and room availability for desired time period. 2. Customer makes reservation for desired room for desired time period. 3. Customer holds reservation by authorizing a deposit for one night’s stay. 4. Credit bureau verifies that customer has necessary credit for deposit. 5. Customer requests confirmation of reservations.

M07_VALA1629_09_GE_C07.indd 246 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 247

WRITING USE CASES FOR PINE VALLEY FURNITURE’S WEBSTORE Jim Woo was pleased with the use case diagram he created for the WebStore (Figure 7-33). Now that he had identified all of the use cases necessary (he thought), he was ready to go back and start writing the use cases. The management in Pine Val- ley’s Information Systems department mandated that analysts use a standard template for writing use cases. Given his use case diagram, Jim decided to create two types of written use cases. The first would deal with the entire process of buying a PVF product on the WebStore, as depicted in his use case diagram. This written use case would be

FIGURE 7-33 WebStore use case diagram

Fill Order

Place Order

Maintain Account

Browse Catalog

Customer Shipping Clerk

Check Order

TABLE 7-5 System Structure of the WebStore and Corresponding Functions

WebStore System Functions

❑❑ Main Page • Product Line (Catalog)

✓ Desks ✓ Chairs ✓ Tables ✓ File Cabinets

• Shopping Cart • Checkout • Account Profile • Order Status/History • Customer Comments

❑❑ Company Information ❑❑ Feedback ❑❑ Contact Information

Browse Catalog

Place Order Place Order Maintain Account Check Order

M07_VALA1629_09_GE_C07.indd 247 08/04/2020 16:40

248 PART III ANALYSIS

at the kite level. It would be a summary use case and would not include functional requirements. The finished product is shown in Figure 7-34.

After finishing the kite level use case, Jim went on to create a couple of writ- ten use cases for individual use cases in his diagram. Jim wanted to write these use cases at the sea level or user goal level. He started with the first use case in his diagram, Browse catalog. Figure 7-35 shows the template Jim completed for this first use case.

Jim was amazed at how much detail he could generate for something as seem- ingly simple as a customer browsing a Web catalog. Yet he knew that he had left out

FIGURE 7-34 Jim Woo’s Kite Level Written Use Case for Buying a Product at PVF’s WebStore

(Source: George, J. F., Batra, D.; Valacich, J. S., & Hoffer, J. A. Object-oriented systems analysis and design (2nd Ed.) (pp. 174, 168, 175, 172, 176, 177). Reprinted and Electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Use Case Title: Making a hotel room reservation

Primary Actor: Customer

Level: Kite (summary)

Stakeholders: Customer, credit bureau

Precondition: Customer accesses the hotel Web site

Minimal Guarantee: Rollback of any uncompleted transaction

Success Guarantees: Reservation held with one night’s deposit

Trigger: Customer accesses hotel homepage

Main Success Scenario:

Extensions:

M07_VALA1629_09_GE_C07.indd 248 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 249

FIGURE 7-35 Jim Woo’s completed template for PVF’s Browse catalog use case

(Source: George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object-oriented systems analysis and design (2nd Ed.) (pp. 174, 168, 175, 172, 176, 177). Reprinted and Electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Use Case Title: Browse catalog

Primary Actor: Customer

Level: Sea level (user goal)

Stakeholders: Customer

Precondition: Customer must be online with Web access

Minimal Guarantee: Rollback of any uncompleted transaction; system logs progress until failure

Success Guarantees: Files customer desires load correctly

Trigger: Customer accesses WebStore homepage

Main Success Scenario:

Extensions:

1.a. Cookie cannot be created. 1.a.1. Message created indicates to customer that browsing is not possible because his or her Web browser does not allow for the creation of cookies. 1.a.2. Customer either adjusts the browser’s cookie settings and tries again or leaves the site. 6.a. Full-sized photo does not load. 6.a.1. Customer gets a broken-link symbol. 6.a.2. Customer hits the refresh button and the photo loads successfully. 6.a.3. Customer hits the refresh button and the photo does not load successfully; customer leaves the site. 2-7.a. The requested Web page does not load or cannot be found. 2-7.a.1. Customer gets a “page not found” error page in browser. 2-7.a.2. Customer hits the refresh button and the requested page loads successfully. 2-7.a.3. Customer hits the refresh button and the requested page does not load successfully; customer leaves the site.

1. Cookie created on customer hard drive. 2. Customer selects category of item to view from list (e.g., home, o�ce, patio). 3. Customer selects subcategory of item to view from list (e.g., home is subdivided into kitchen, dining room, bedroom, living room, den, etc.). 4. Customer selects specific item from list in subcategory to view (e.g., TV stand in den). 5. Customer selects specific item from list of products (e.g., Smith & Wesson TV stand). 6. Customer clicks on thumbnail photo of item to get regular-sized photo to view. 7. Customer selects “Product Specifications” to get detailed information on product. 8. Customer uses Web browser “Back” button to go back to see other products or other rooms or other types of furniture. 9. Customer selects from choices on menu bar to go elsewhere, either “Other Types of Furniture,” “WebStore Home,” or “PVF Home.”

many details, details that could be specified in a use case at different levels, such as fish level or below. Still, Jim was happy with the progress he had made on this use case for catalog browsing. Now he turned his attention to the other four use cases he had identified for the WebStore (Figure 7-33) and wrote sea-level use cases for them. Once he finished, he called a couple of other analysts at PVF so they could review his work.

M07_VALA1629_09_GE_C07.indd 249 08/04/2020 16:40

250 PART III ANALYSIS

SUMMARY Use case modeling, featuring use case diagrams and written use cases, is another method you can use to model business processes. Use cases focus on system functionality and busi- ness processes, and they provide little, if any, information

about how data flow through a system. In many ways, use case modeling complements DFD modeling. The use case approach provides another tool for analysts to use in struc- turing system requirements.

Match each of the key terms above with the definition that best fits it.

____ People who have a vested interest in the system being developed.

____ The least amount promised to the stakeholder by a use case.

____ An association between two use cases where one adds new behaviors or actions to the other.

____ An external entity that interacts with a system.

____ Event that initiates a use case.

____ A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users.

____ The set of behaviors or functions in a use case that follow exceptions to the main success scenario.

____ A picture showing system behavior, along with the key actors that interact with the system.

____ What a use case must do effectively in order to satisfy stakeholders.

____ An association between two use cases where one use case uses the functionality contained in the other.

____ Things that must be true before a use case can start.

____ Perspective from which a use case description is written, typically ranging from high level to extremely detailed.

KEY TERMS

7A.1 Actor 7A.2 Extend relationship 7A.3 Extension 7A.4 Include relationship

7A.5 Level 7A.6 Minimal guarantee 7A.7 Preconditions 7A.8 Stakeholder

7A.9 Success guarantee 7A.10 Trigger 7A.11 Use case 7A.12 Use case diagram

REVIEW QUESTIONS 7A.13 What are use cases?

7A.14 What is use case modeling?

7A.15 What is a use case diagram?

7A.16 What is a written use case and how does it compare to a use case diagram?

7A.17 Explain an include relationship.

7A.18 Explain an extend relationship.

7A.19 Compare DFDs with use case diagrams.

7A.20 What can a written description of a use case provide that a use case diagram cannot?

7A.21 Describe Cockburn’s template for a written use case.

7A.22 List and explain the five levels from which use case descrip- tions can be written.

7A.23 What is the difference between a minimal guarantee and a success guarantee?

7A.24 What are extensions?

PROBLEMS AND EXERCISES 7A.25 Draw a use case diagram for the situation described in

Problem and Exercise 7.39, page 231.

7A.26 Draw a use case diagram for the situation described in Problem and Exercise 7.40, page 232.

7A.27 Draw a use case diagram for the situation described in Problem and Exercise 7.41, page 233.

7A.28 Draw a use case diagram for the situation described in Problem and Exercise 7.42, page 233.

7A.29 Draw a use case diagram for the situation described in Problem and Exercise 7.43, page 234.

7A.30 Draw a use case diagram based on the level-0 diagram in Figure 7-23. How does your use case diagram for Figure 7-23 differ from the one in Figure 7-26, which is also about registering for classes? To what do you attribute the differences?

7A.31 Develop a use case diagram for using an ATM machine to withdraw cash.

M07_VALA1629_09_GE_C07.indd 250 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 251

REFERENCES

Cockburn, A. (2001). Writing effective use cases. Reading, MA: Addison-Wesley.

Eriksson, H., & Penker, M. (1998). UML toolkit. New York: Wiley.

Jacobson, I., Christerson, M., Jonsson, P., & Overgaard, G. (1992). Object-oriented software engineering: A use-case-driven approach. Reading, MA: Addison-Wesley.

7A.32 Develop a written use case for using an ATM machine to withdraw cash.

7A.33 Choose a transaction that you are likely to encounter, per- haps ordering a cap and gown for graduation, and develop a use case diagram for it.

7A.34 Choose a transaction that you are likely to encounter and develop a written use case for it.

7A.35 The diagram in Figure 7-33 includes five use cases. In this chapter, Jim Woo wrote descriptions for one of them, Browse catalog. Prepare written descriptions for the other use cases in Figure 7-33.

7A.36 An auto rental company wants to develop an automated system that can handle car reservations, customer billing,

and car auctions. Usually a customer reserves a car, picks it up, and then returns it after a certain period of time. At the time of pickup, the customer has the option to buy or waive collision insurance on the car. When the car is returned, the customer receives a bill and pays the specified amount. In addition to renting cars, every six months or so, the auto rental company auctions the cars that have accumulated over 20,000 miles. Draw a use case diagram for capturing the requirements of the system to be developed. Include an abstract use case for capturing the common behavior among any two use cases. Extend the diagram to capture corporate billing, where corporate customers are not billed directly; rather, the corporations they work for are billed and payments are made sometime later.

FIELD EXERCISE 7A.37 At an organization with which you have contact, find an

analyst who uses use case modeling. Find out how long he or she has been writing use cases and how he or she feels about use cases compared with DFDs.

M07_VALA1629_09_GE_C07.indd 251 08/04/2020 16:40

252

Introduction parallel activities are done, they come back together in a join. The join is shown as a horizontal line with two arrows coming in and one arrow leaving. After the join, the overall process continues.

Figure 7-37 shows a simple activity diagram that illus- trates conditional logic. A user wants to log in to a system, which could be a Web site or some other information sys- tem. If the user has already registered, then the flow of activities shifts to the left-hand side. If the user has not registered, the flow shifts to the right-hand side. First, the user has to click on the “Register” button. A registration

An activity diagram shows the conditional logic for the sequence of system activities needed to accomplish a business process. An individual activity may be manual or automated. Further, each activity is the responsibility of a particular organizational unit.

The basic activity diagram notation contains only a few symbols (Figure 7-36). Each activity is represented with a rounded rectangle, with the action performed by that activity written inside it. The diagram itself represents an overall process that is made up of a series of activities. The beginning of the process is indicated with a filled in circle. An arrow connects the circle with the first activity. The end of the process is also indicated with a filled in circle, but it is surrounded by another circle. An activity diagram is designed to show conditional logic. The symbol that illustrates a choice that must be made is a diamond, and it is called a branch. The diamond follows one activity, so there is an arrow coming into it. Two activities follow it, so an arrow leaves the diamond for each possible course of action. These arrows are labeled with the conditions that cause each branch to be followed. The different courses of possible action end at some point, so they join together, and the overall process continues. The point at which they join is called a merge, and the symbol for it is also a dia- mond. For a merge diamond, two arrows come into the diamond but only one leaves. An activity diagram can also show parallel activities. We show where the parallel activi- ties begin with a fork. The fork is shown with a horizon- tal line, which has two arrows coming out of it. When the

object-oriented Analysis and Design

Appendix

Activity Diagrams*

FIGURE 7-36 Basic notation for activity diagrams

Start End

Activity

Fork

Join

Branch

Merge

Learning Objective After studying this section, you should be able to

7B.1 understand how to represent system logic with activity diagrams.

* The original version of this appendix was written by Professor Atish P. Sinha.

M07_VALA1629_09_GE_C07.indd 252 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 253

form will then open, which the user must complete. The system then checks to see if the form has been completed correctly. If so, the action proceeds to the merge point. If not, the user must complete the registration form again. Once the user has suc- cessfully logged in, the flow of the action moves to the end of the activity diagram. In practice, this activity diagram would illustrate only one small part of a larger process involving a system. There would typically be activities before the log-in branch, and there would be other activities following the merge at the bottom of the diagram.

Another simple activity diagram is shown in Figure 7-38. This activity diagram shows how you might order a pizza. The process starts with the first activity, browsing the menu of your favorite pizza restaurant or take-out place. The next step is to call and order the pizza. The third step is to take delivery. But if the pizza is not what you ordered, you don’t want it. So there is a conditional branch included. If the order is correct, then you pay for the pizza. If the pizza is not what you wanted, then you return it. Note how both of the activities that follow the branch lead to the end of the activity diagram.

Both of the activity diagrams you have seen so far have been relatively simple and have involved only one participant. But organizational processes are rarely so simple, and they almost always involve multiple actors, typically located in different organi- zational departments. Figure 7-39 illustrates one such process: A typical customer ordering process for a stock-to-order business, such as a catalog or an Internet sales company. Interactions with other business processes, such as replenishing inventory, forecasting sales, or analyzing profitability, are not shown.

In Figure 7-39, each column, called a swimlane, represents the organizational unit responsible for certain activities. The vertical axis is time, but without a time scale (i.e., the distance between symbols implies nothing about the absolute amount of time passing). As usual, the process starts at the filled in circle. This activity diagram includes a fork, which means that several parallel, independent sequences of activities

Activity diagram Shows the conditional logic for the sequence of system activities needed to accomplish a business process.

FIGURE 7-37 Simple activity diagram showing conditional logic

Click on ‘Register’

Complete registration

form

Submit registration

form

[User has registered] [User has not registered]

[Form OK]

[Form not OK]

FIGURE 7-38 A simple activity diagram for ordering pizza

Browse menu

Call to order pizza

Take delivery

Return pizza

Pay for pizza

[Order not OK]

[Order OK]

M07_VALA1629_09_GE_C07.indd 253 08/04/2020 16:40

254 PART III ANALYSIS

FIGURE 7-39 Activity diagram for a customer order process

Purchasing Fulfillment Customer Service Accounting

Prepare Invoice

Receive Order

Activity

Branch

Merge

Join

End

Fork

Start

Close Order

Pull Available Inventory

[missing some items]

[request express] [else]

Send Order

Send Express

Mail

Send Regular

Mail

Prepare Back Order

Pull Back Order Inventory

Send Invoice

Receive Payment

M07_VALA1629_09_GE_C07.indd 254 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 255

are initiated (such as after the Receive Order activity), and a join (such as before the Send Invoice activity) signifies that independent streams of activities now must all reach completion to move on to the next step.

The branch in the Fulfillment swimlane indicates conditional logic. After avail- able inventory is pulled from stock, it must be determined if all ordered items were found. If they were not, Purchasing must prepare a back order. After either the back- order inventory arrives and is pulled or the original order is filled completely, the process flow merges to continue to the Send Order activity.

This multi-actor activity diagram clearly shows parallel and alternative behaviors (Fowler & Scott, 1999). It provides a good way to document work or flows through an organization. However, objects are obscured and the links between objects are not shown. An activity diagram can be used to show the logic of a use case.

WHEN TO USE AN ACTIVITY DIAGRAM An activity diagram is a flexible tool that can be used in a variety of situations. It can be used at a high level as well as at a low level of abstraction. It should be used only when it adds value to the project. Our recommendation is to use it sparingly. Ask the following question: Does it add value or is it redundant? Specifically, an activity dia- gram can be used to accomplish the following tasks:

1. Depict the flow of control from activity to activity. 2. Help in use case analysis to understand what actions need to take place. 3. Help in identifying extensions in a use case. 4. Model work flow and business processes. 5. Model the sequential and concurrent steps in a computation process.

The interpretation of the term activity depends on the perspective from which one is drawing the diagram. At a conceptual level, an activity is a task that needs to be done, whether by a human or a computer (Fowler & Scott, 1999). At an implementa- tion level, an activity is a method in a class.

7B.1 Draw an activity diagram that models the following employee reimbursement process.

Employees of West Nile Valley University have to follow a specific procedure to get reimbursed for travel they undertake on behalf of the university. First, they have to gather and prepare all of the receipts the university requires for reimbursement. At the same time, they complete the official reimbursement form. They then submit both the receipts and the form to their departmental secretary. If something on the form is incorrect, the secretary returns the form to the employee for correction. If the form is correct, the employee is asked to review the reimbursement amounts, which are determined by an analysis of the reimbursement request. If the amount shown is not correct, the employee must indicate that this is the case. If the amount shown is correct, then the employee’s responsibilities for reimbursement are complete.

7B.2 Draw an activity diagram that models the reimbursement process described in the next column. Use one swimlane for each of the three actors in the process.

The travel reimbursement process for employees of West Nile Valley University involves three different actors: the employee, the employee’s departmental secretary, and the treasurer’s office. First, the employee has to gather and prepare all of the receipts the university requires for reimbursement. At the same time, she completes the official reimbursement form. She then submits both the receipts and the form to the departmental secretary. If something on the form is incorrect, the secretary returns the form to the employee for correction. If the form is correct, the secretary prepares a form required by the university. That form is then submitted to the treasurer’s office. The treasurer’s office then enters the amount to be reimbursed into the university’s system. The employee is then asked to review the reimbursement amounts. If the amount shown is not correct, the employee must indicate that this is the case. If the amount shown is correct, then the treasurer’s office sends the reimbursement to the employee’s bank, completing the process.

PROBLEMS AND EXERCISES

M07_VALA1629_09_GE_C07.indd 255 08/04/2020 16:40

256 PART III ANALYSIS

REFERENCE Fowler, M., & Scott, K. (1999). UML distilled (2nd ed.). Reading,

MA: Addison-Wesley.

7B.3 Draw an activity diagram for the following employee hiring process.

Projects, Inc., is an engineering firm with approximately 500 engineers in different specialties. New employees are hired by the personnel manager, based on data in an application form and evaluations collected from other managers who interview the job candidates. Prospective employees may apply at any time. Engineering managers notify the personnel manager when a job opens and list the characteristics necessary to be eligible for the job. The personnel manager compares the qualifications of the available pool of applicants with the characteristics of an open job and then schedules interviews between the manager in charge of the open position and the three best candidates from the pool. After receiving evalua- tions on each interview from the manager, the personnel manager makes the hiring decision based upon the evaluations and applications of the candidates and the characteristics of the job, and then notifies the interview- ees and the manager about the decision. Applications of rejected applicants are retained for one year, after which time the application is purged. When hired, a new engineer completes a nondisclosure agreement, which is filed with other information about the employee.

7B.4 Draw an activity diagram for the following case. Maximum Software develops and supplies software products to individuals and businesses. As part of its operations, Maximum provides a 1-800 telephone num- ber help desk for clients with questions about software purchased from Maximum. When a call comes in, an operator inquires about the nature of the call. For calls that are not truly help desk functions, the operator redi- rects the call to another unit of the company (such as order processing or billing). Because many customer questions require in-depth knowledge of a product, help desk consultants are organized by product. The opera- tor directs the call to a consultant skilled on the software

that the caller needs help with. Because a consultant is not always immediately available, some calls must be put into a queue for the next available consultant.

Once a consultant answers the call, he or she deter- mines whether this is the first call from this customer about this problem. If so, a new call report is created to keep track of all information about the problem. If not, the customer is asked for a call report number so the consultant can retrieve the open call report to determine the status of the inquiry. If the caller does not know the call report number, the consultant col- lects other identifying information such as the caller’s name, the software involved, or the name of the consul- tant who has handled the previous calls on the problem in order to conduct a search for the appropriate call report. If a resolution of the customer’s problem has been found, the consultant informs the client what that resolution is, indicates on the report that the customer has been notified, and closes out the report. If a resolu- tion has not been discovered, the consultant finds out whether the consultant previously handling this prob- lem is on duty. If so, the call is transferred to the other consultant (or the call is put into the queue of calls waiting to be handled by that consultant).

Once the proper consultant receives the call, any new details the customer may have are recorded. For continuing problems and for new call reports, the consultant tries to discover an answer to the problem by using the relevant software and looking up information in reference manuals. If the problem can be resolved, the customer is told how to deal with the problem, and the call report is closed. Otherwise, the consultant files the report for continued research and tells the customer that someone at Maximum will be in touch, or if the customer discovers new information about the problem, he or she can call back, identifying the problem with a specified call report number.

M07_VALA1629_09_GE_C07.indd 256 08/04/2020 16:40

257

BASIC NOTATION Business Process Modeling Notation is much more com- plicated than data flow diagrams notation; it is made up of many more symbols, and each symbol has numerous variations. (The interested reader is referred to the BPMN standards and numerous other documents to learn about all of the various aspects of the complete BPMN standard. See the reference list at the end of the appendix.) However, there are four basic concepts in BPMN, each of which has its own basic symbol. These basic concepts are events, activi- ties, gateways, and flows. Their symbols are as follows:

At the heart of just about any information system devel- oped for organizations, there is a business process. A busi- ness process is a standard method for accomplishing a particular task necessary for an organization to function. A business process can come from any business function, from accounting to supply chain management to after-sales service. It can cross business functions as well. A business process can be simple or complex, but the more complex it is, the harder it is to automate. Complexity also makes a process more difficult to understand for those who are not familiar with it. Communication tools are needed to describe business processes to those who need to know about them, such as systems analysts, but who have no first- hand knowledge of the processes. There are many ways to represent business processes, from data flow diagrams to activity diagrams. The Object Management Group (OMG), the same group that is responsible for standards for object- oriented programming, has established a specific modeling approach for business processes. It is called Business Process Modeling Notation (BPMN). This appendix provides a very brief introduction to BPMN. First, we will introduce you to the basic notation in BPMN, and second, we will provide a couple of examples. If you are interested in mastering BPMN, there are many materials available (see the refer- ence list).

Introduction

Business Process modeling

Appendix

Learning Objective After studying this section, you should be able to

7C.1 understand how to represent business processes with business process diagrams.

Event

Activity

Gateway

Flow

M07_VALA1629_09_GE_C07.indd 257 08/04/2020 16:40

258 PART III ANALYSIS

All business processes begin and end with an event. The symbol for an event is a circle. For a starting event, the walls of the circle are thin. For the ending event, the walls are thicker. A starting event can be colored green, and an ending event can be colored red. An activity is some action that must take place for the process to be com- pleted. An activity can be completed by people or by a computerized system. The symbol for an activity is a rectangle with rounded edges. A gateway, symbolized by a diamond, is a decision point. The final primary concept is flow, represented by an arrow. Flow shows sequence, the order in which activities occur. A simple example, without content, of a process represented by BPMN, is as follows:

In this simple example, you see that the business process starts with some event, shown with an event symbol on the left. BPMN diagrams are always read from left to right. The event is followed by the first activity. An arrow symbolizing flow connects the event to the activity. The first activity is followed by a gateway. This is a decision point, indicated by two choices: “Yes” and “No.” Some condition is associated with the gate- way, and that condition can either be met (Yes) or not (No). Whether the condition is met or not determines where the flow goes next in the diagram. Both conditions lead to an additional activity. If the flow goes through the top of the diagram, there is one more activity that takes place before the process ends at its ending event. If the flow goes through the bottom part of the diagram, the process concludes after just one activity is completed. Note how the walls of the circle that represents the final event are much thicker than those of the circle representing the beginning event.

Typically gateways are exclusive, which is to say that flow must follow only one path out of the gateway and only one downstream activity can take place. However, a gateway may be inclusive, which means that more than one downstream activity can occur. If a gateway is inclusive, the downstream activities that follow it must also be followed by a merge gateway, where all the flows come back together. Such a situation would look like this:

In this example, both or either of the activities that follow the gateway could occur. The merge gateway follows the activities, reuniting the two possible flows into a single flow. Note that the symbol for an inclusive gateway adds a circle inside the diamond. If it is necessary to indicate an exclusive gateway, you can add an “X” to the inside of the diamond.

In fact, there are three different types of gateways in BPMN. The gateway with an X inside is called an exclusive OR gateway (XOR), meaning that only one of the paths that exit the gateway can be followed. The gateway with a ‘plus’ sign inside is an AND gateway. This means that all of the paths that follow the gateway can be followed in parallel. The third type of gateway is the OR gateway, symbolized by an O inside the diamond. An OR gateway means that at least one path out of the gateway must be followed, but many or even all of the paths that leave the gateway can be engaged.

Event In business process modeling, a trigger that initiates the start of a process.

Activity In business process modeling, an action that must take place for a process to be completed.

Gateway In business process modeling, a decision point.

Flow In business process modeling, it shows the sequence of action in a process.

M07_VALA1629_09_GE_C07.indd 258 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 259

Figure 7-40 shows a process that includes an XOR gateway. After activity N is finished, there is an exclusive choice of which action to undertake. Based on the nota- tion, if the value found at the gateway is “a,” then activity A is performed. If the value at the gateway is “b,” then activity B is performed. If the value is “c,” then activity C is performed. But only one of these paths can be followed. Once activity A or B or C is performed, all of the paths merge together at the second gateway, and activity D can be performed.

Figure 7-41 illustrates a process that includes an AND gateway and an XOR gate- way. We again read the BPMN diagram from left to right. After activity N is complete, we come to an AND gateway. This means that both of the paths that follow the gateway must be followed. The top path leads to an XOR gateway. As we have seen, the XOR gateway means only one path that leads from it can be followed. If the value found at the XOR gateway is “a,” activity A is performed. If the value at the gateway is “b,” then activity B is performed. Activity C is performed in parallel with either activity A or B. After either A or B is performed, the paths merge to the closing XOR gateway. The path that leaves the XOR gateway and the path that leaves activity C then both merge at the next AND gateway. Now activity D can be performed, completing the process.

Although it is beyond the scope of this appendix to introduce all of the special- ized varieties of the four basic concepts in BPMN, it is useful to present a few varieties of some of the concepts. For example, here are the symbols for a couple of types of events. They both feature the basic circle as a symbol for an event, but each one has something inside. The first has an envelope inside, and the envelope stands for a mes- sage. An event shown like this, at the beginning of a process, means that the process starts with a message. A message is a basic flow of information, such as the receipt of an order or of a customer inquiry. The other event symbol has a clock inside. If a process starts with this type of event, it means the process starts at a particular time. In both

FIGURE 7-41 A process featuring an AND gateway and an XOR gateway

Done

Action? a

D× ×

Start

FIGURE 7-40 An XOR gateway

× DoneStart

N A

Action? a

D×

M07_VALA1629_09_GE_C07.indd 259 08/04/2020 16:40

260 PART III ANALYSIS

cases, the starting event is triggered by an action outside the process itself, either a message or a particular time.

Another example of variations in a basic concept appears left, for flow. You have seen the basic symbol for flow, the arrow. The next symbol for flow includes a slashing line near its beginning. This indicates a default flow, and you will usually see this sym- bol after a gateway. It shows that flow through a gateway typically follows one path out of those available. The third flow symbol is a little different. The arrow line is dotted, and it begins with a circle. This symbol is used to signify the flow of a message rather than the flow of sequence from one activity to the next.

We have presented just a few of the many variations in BPMN available for the basic concepts. There are many more, and all of them are designed to address very specific circumstances. Having all of these variations available makes BPMN very pre- cise and therefore very powerful. However, all of the variations also make BPMN relatively complex and harder to learn than diagramming notations that employ less variety.

We present a simple example of a BPMN diagram in Figure 7-42. It is a process for ordering a pizza. The first activity involves browsing the menu for your favorite pizza source, whether it is a restaurant or a delivery service. Once you know what you want, you call to order the pizza. Then the delivery person comes to your apartment, and you take delivery of the pizza. Next, there is an XOR gateway, so you can do only one of the two things that follow. You want to know if the pizza that was delivered is the same as the one that you ordered. If it is, you pay for the pizza. If not, then you return it to the delivery person. After one or the other of these activities has been performed, both paths end at the XOR merge gateway. And then the overall process ends.

Before we leave this section on notation, we need to address one other concept: swimlanes. A process diagram can be depicted with or without a swimlane, which is a way to visually encapsulate a process. Swimlanes can be depicted either vertically or horizontally. Whether a swimlane is used or not, the diagram shows only one process with one actor. If more than one actor is part of the process, then the process diagram is shown in a pool. A pool is made up of at least two swimlanes, each of which focuses on the actions of one participant. The participant need not be a single person; it can be a team or a department that participates in a part of the process. Pools can also be depicted vertically or horizontally. When a pool is used in a business process diagram, it is called a collaboration diagram.

L A

N E LANE

Pool In business process modeling, a way to encapsulate a process that has two or more participants.

Swimlane In business process modeling, a way to visually encapsulate a process.

FIGURE 7-42 A simple BPMN example

× Browse menu

Call to order pizza

Take delivery

Pay for pizza

Return pizza

[OK]

[Order not OK]

Flow: sequence

Flow: default

Flow: message

M07_VALA1629_09_GE_C07.indd 260 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 261

BUSINESS PROCESS EXAMPLE An example of a business process diagram that features both swimlanes and a pool is shown in Figure 7-43. The process depicted is recruiting. There are three participants: the job applicant (shown in a swimlane), a manager, and a Human Resources (HR) department. The manager and HR department are in the same company and so are both shown in a pool. All communication between the company (pool) and the appli- cant (swimlane) is done through messaging. Note the lines indicating communication between the applicant and the organization are dotted lines and feature envelopes at midline. The envelopes symbolize messages, or information.

To read the diagram, start at the top left, with the event symbol in the manager’s lane in the company pool. Then continue to read from left to right. Follow the arrows, which indicate flow up, down, and across. The manager needs to recruit someone for a job, so she creates an advertisement for the job. Flow control then passes to the HR department, where the ad is reviewed and then posted. At this point, a job applicant sees the ad and completes and returns an application. The application is received by HR, where it is evaluated and passed on to the manager. The manager evaluates the application and then must decide whether or not to interview the applicant. This decision is indicated by the gateway symbol. There are two possible outcomes: yes, interview the applicant, or no, don’t interview the applicant. If the decision is “no,” then the manager notifies HR. HR notifies the applicant, and the applicant must decide what to do next. The process ends for both the company and the applicant. If the decision is “yes,” then the applicant takes part in an interview. The results are evaluated by the manager. At this point, whether the manager decides to hire the applicant or not, she notifies HR of her decision, and HR then notifies the applicant. The applicant must decide on his next step, and the process ends for all involved.

Obviously, the recruiting process has been simplified for this example. Many more activities are typically involved in recruiting, such as conducting credit and background checks of the applicant. Much of the detail was removed to make the example easier to understand and depict.

FIGURE 7-43 Depicting a recruiting process with BPMN

Complete Application

Take Part in Interview

Notify Applicant

Notify HR

Review Response

Post ad

Create ad Evaluate Applicant

Evaluate Applicant

Interview? No

Yes

H R

A p

p lic

a n

t C

o m

p a n

M an

ag er

Review ad

Decide on Next Step

Notify Manager

M07_VALA1629_09_GE_C07.indd 261 08/04/2020 16:40

262 PART III ANALYSIS

SUMMARY In this appendix, we introduced you to Business Process Modeling Notation (BPMN). BPMN is a standardized way of depicting business processes. It is overseen by the Object Management Group (OMG), the same group that oversees notation for object-orientation. We introduced you to the four basic concepts of BPMN—event, activity, gateway, and

flow—and the symbols for each of them. We also intro- duced you to swimlanes and pools. BPMN is a very precise and complex modeling notation, but that makes it very powerful. Because BPMN is not technical in nature, it can be used effectively for communications between systems analysts and systems users.

KEY TERMS

7C.1 Activity 7C.2 Event

7C.3 Flow 7C.4 Gateway

7C.5 Pool 7C.6 Swimlane

Match each of the key terms above with the definition that best fits it.

____ A way to visually encapsulate a process.

____ A trigger that initiates the start of a process.

____ A way to encapsulate a process that has two or more participants.

____ A decision point.

____ Shows the sequence of action in a process.

____ An action that must take place for a process to be completed.

REVIEW QUESTIONS 7C.7 What is a business process? Why is business process dia-

gramming important?

7C.8 What is BPMN? Who is responsible for it?

7C.9 List and define the four main concepts that are part of BPMN.

7C.10 What is the difference between a swimlane and a pool? When do you use each one?

7C.11 BPMN includes many different variations on its key con- cepts. You were introduced to three different variations of the symbol for flow. Explain each one of them.

PROBLEMS AND EXERCISES 7C.12 BPMN includes many different varieties of its key con-

cepts. Go to http://www.bpmn.org (and some of the other BPMN sites listed in the reference list) and look up all of the many variations that are possible for each concept. Prepare a report on six possible variations for each of the four major concepts.

7C.13 The appendix features two BPMN examples that showed symbols but lacked content. Think of actual processes that can be described with the “empty” process diagrams in the chapter. These processes will have to be pretty simple, given how small and simple the diagrams are.

7C.14 Use BPMN to depict Hoosier Burger’s food-ordering sys- tem from Figure 7-5 as a business process model.

7C.15 Use BPMN to depict Hoosier Burger’s inventory control system from Figure 7-15 as a business process model.

7C.16 Draw a BPMN diagram that models the employee’s reim- bursement process described below.

submit both the receipts and the form to their depart- mental secretary. If something on the form is incor- rect, the secretary returns the form to the employee for correction. If the form is correct, then the employee is asked to review the reimbursement amounts, which are determined by an analysis of the reimbursement request. If the amount shown is not correct, the employee must indicate that this is the case. If the amount shown is correct, then the employee’s respon- sibilities for reimbursement are complete.

7C.17 Draw a BPMN diagram that models the reimbursement process described below. Use one swimlane for each of the three actors in the process.

The travel reimbursement process for employees of West Nile Valley University involves three different actors: the employee, the employee’s departmental sec- retary, and the treasurer’s office. First, the employee has to gather and prepare all of the receipts the univer- sity requires for reimbursement. At the same time, she completes the official reimbursement form. She then submits both the receipts and the form to the depart- mental secretary. If something on the form is incorrect, the secretary returns the form to the employee for cor- rection. If the form is correct, the secretary prepares

M07_VALA1629_09_GE_C07.indd 262 08/04/2020 16:40

http://www.bpmn.org

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 263

REFERENCES Freund, J., & Rucker, B. (2004). Real-life BPMN: Using BPMN 2.0 to

analyze, improve, and automate processes in your company. Create Space Independent Publishing Platform.

http://www.bpmn.org/ http://en.wikipedia.org/wiki/Business_Process_Modeling_

Notation

http://www.omg.org/spec/BPMN/1.2/ http://www.omg.org/spec/BPMN/2.0/ https://www.omg.org/cgi-bin/doc?dtc/10-06-02.pdf http://www.sparxsystems.com/platforms/business_process_

modeling.html.

a form required by the university. That form is then submitted to the treasurer’s office. The treasurer’s office then enters the amount to be reimbursed into the university’s system. The employee is then asked to review the reimbursement amounts. If the amount

shown is not correct, the employee must indicate that this is the case. If the amount shown is correct, then the treasurer’s office sends the reimbursement to the employee’s bank, completing the process.

FIELD EXERCISES 7C.18 Find a company in your area that uses BPMN. Interview

analysts and users about this business process modeling approach. What do they think of it? How useful is it? Ask for some examples of diagrams they have created.

7C.19 Think of several business processes you take part in regu- larly as a customer. For example, think about withdrawing

cash from an ATM. Think about ordering a movie and downloading a movie online. Consider purchasing some- thing with a credit card from a big-box store. Use BPMN to depict each of the processes you can think of.

M07_VALA1629_09_GE_C07.indd 263 08/04/2020 16:40

http://www.bpmn.org/

http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation

http://www.omg.org/spec/BPMN/1.2/

http://www.omg.org/spec/BPMN/2.0/

https://www.omg.org/cgi-bin/doc?dtc/10-06-02.pdf

http://www.sparxsystems.com/platforms/business_process_�modeling.html

http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation

PETRIE ELECTRONICS

264 PART III ANALYSIS

Chapter 7: Structuring System Process Requirements

Jim and Sanjay chatted in Jim’s office while they waited for Sally to arrive.

“Good work on researching those alternatives,” Jim said. “Thanks,” replied Sanjay. “There are a lot of alternatives

out there. I think we found the best three, considering what we are able to pay.”

Just then Sally walked in. “Sorry I’m late. Things are get- ting really busy in Marketing right now. I’ve been putting out fires all morning.”

Sally sat down at the table across from Jim. “I understand,” Jim said. “But to stay on schedule, we

need to start focusing on the specifics of what we want our system to do. Remember when you wanted more details on what the system would do? Well, now we start to spend some serious energy on getting that done.”

“Awesome,” replied Sally, as she pulled a Red Bull out of her oversized bag and popped it open.

“I’ve got a list here of four core functions the system must perform,” said Sanjay, pulling copies of a list from a folder on the table (PE Table 7-1). “Let’s look at these.”

After reviewing the list Sanjay had given them, Jim said, “Nice job, Sanjay. But we need to put this in graphical for- mat, so that everyone can see what the inputs and outputs are for each function and how they are related to each other. We also need to see how the new system fits in with our existing data sources. We need …”

“Some data flow diagrams,” Sanjay interrupted. “Exactly,” said Jim. “They are already done,” replied Sanjay, handing dia-

grams to both Jim and Sally. “I’ve already created a first draft of the context diagram (PE Figure 7-1) and a level-1 diagram (PE Figure 7-2). You can see how I’ve defined the boundaries of our system, and I’ve included our existing product and marketing databases.”

“What can I say?” Jim said. “Again, a nice job on your part. These diagrams are both good places for us to start. Let’s get copies of all of this to the team.”

“I’ll be right back,” Sally said, standing up. “I need to get some coffee.”

Function Description

Record customer activities

When a customer makes a purchase, the transaction must be recorded in the customer loyalty system, as the rewards the system generates are driven by purchases. Similarly, when a customer uses a coupon generated by the system, it must also be recorded, so that the customer activity records can be updated to show that the coupon has been used and is now invalid.

Send promotions Data about customer activities provide information about what types of products customers tend to buy and in what quantities. This information helps determine what sales promotion materials are best targeted at what customers. Customers who buy lots of video games should receive promo- tions about games, game platforms, and HD TVs, for example.

Generate point redemption coupons

Data about customer activities is used to generate coupons for future purchases. Those coupons must be made avail- able to customers, either as paper coupons sent in the mail or online, in the customer’s private account area. Once created, the customer activity database needs to be updated to show the creation of the coupon. The loyalty points needed to create the coupon must be deducted from the customer’s total points.

Generate customer reports

From time to time, either in the mail or electronically, customers need to be sent account reports that show their recent purchases, the coupons they have been issued that have not yet been redeemed, and the total points they have amassed from their purchases.

PE TABLE 7-1 Four Core Functions of Petrie’s Customer Loyalty System

M07_VALA1629_09_GE_C07.indd 264 08/04/2020 16:40

CHAPTER 7 StRuctuRing SyStem PRoceSS RequiRementS 265

PE FIGURE 7-1 Context diagram

Reports

Tailored Promotions

Coupons Customer Customer

Purchases

Coupons

No Customer Escapes System

PE FIGURE 7-2 Level-1 DFD

Customer

PromotionsMarketing Database

Send Promotions

Coupons

Purchases

Customer Generate Customer Reports

Coupons

Reports

Transactions Customer Activity Records

Customer Activities

Product Database

Generate Point Redemption

Coupons

Record Customer Activities

Tailored Promotions

Coupon Info Customer Activities

Product Info

Customer Activity Info

Case Questions

7.57 Are the DFDs in PE Figures 7-1 and 7-2 balanced? Show that they are or are not. If they are not bal- anced, how can they be fixed?

7.58 Decompose each of the core processes in PE Figure 7-2 and draw a new DFD for each core process.

7.59 Has the team overlooked any core processes in the system that should be in PE Table 7-1 and PE Figure 7-2? What would they be? Add them to PE Table 7-1 and PE Figure 7-2.

7.60 Redesign PE Figures 7-1 and 7-2 so that they are easier to understand, more efficient, and more comprehensive.

7.61 Why is it important for the team to create DFDs if they are not going to write the actual system code themselves?

M07_VALA1629_09_GE_C07.indd 265 08/04/2020 16:40

266

In Chapter 7, you learned how to model and analyze two important views of an information system: (1) the flow of data between manual or automated steps and (2) the decision logic of processing data. None of the techniques discussed so far, however, has concentrated on the data that must be retained in order to support the data flows and processing described. For example, you learned how to show data stores, or data at rest, in a data flow diagram (DFD). The natural structure of data, however, was not shown. DFDs, use cases, and various processing logic techniques show how, where, and when data are used or changed in an information system, but these techniques do not show the definition, structure, and relationships within the data. Data modeling develops these missing, and crucial, descriptive pieces of a system.

In fact, some systems developers believe that a data model is the most important part of the statement of infor- mation system requirements. This belief is based on the following reasons. First, the characteristics of data captured during data modeling are crucial in the design of databases, programs, computer screens, and printed reports. For example, facts such as these—a data element is numeric, a product can be in only one product line at a time, a line item on a customer order can never be moved to another

customer order, customer region name is limited to a speci- fied set of values—are all essential pieces of information in ensuring data integrity in an information system.

Second, data, not processes, are the most complex aspects of many modern information systems and hence require a central role in structuring system requirements. Transaction processing systems can have considerable pro- cess complexity in validating data, reconciling errors, and coordinating the movement of data to various databases. Current systems development focuses more on manage- ment information systems (such as sales tracking), deci- sion support systems (such as short-term cash investment), and business intelligence systems (such as market basket analysis). Such systems are more data intensive. The exact nature of processing is also more ad hoc than with transac- tion processing systems, so the details of processing steps cannot be anticipated. Thus, the goal is to provide a rich data resource that might support any type of information inquiry, analysis, and summarization.

Third, the characteristics about data (e.g., length, format, and relationships with other data) are reasonably permanent and have significant similarity for different organizations in the same business. In contrast, the paths and design of data flow are quite dynamic. A data model explains the inherent nature of the organization, not its

8.4 distinguish among unary, binary, and ternary relationships as well as associative entities, providing an example of each;

8.5 define supertypes and subtypes, showing how to represent these entity types with entity-relationship diagramming notation;

8.6 define four basic types of business rules in a conceptual data model; and

8.7 explain the role of prepackaged database models (patterns) in data modeling.

Learning Objectives After studying this chapter, you should be able to

8.1 explain the role of conceptual data modeling in the overall analysis and design of an information system;

8.2 describe the information gathering process for conceptual data modeling;

8.3 describe how to represent an entity-relationship model and be able to define the terms: entity type, attribute, identifier, multivalued attribute, and relationship;

Structuring System Data Requirements8

Introduction

M08_VALA1629_09_GE_C08.indd 266 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 267

transient form. Therefore, an information system design based on a data orientation, rather than a process or logic orientation, should have a longer useful life and should have common features for the same applications or domains in different organiza- tions. Finally, structural information about data is essential for automatic program generation. For example, the fact that a customer order has many line items on it instead of just one line item affects the automatic design of a computer screen for entry of customer orders. Although a data model specifically documents the file and database requirements for an information system, the business meaning, or semantics, of data included in the data model has a broader effect on the design and construc- tion of a system.

The most common format used for data modeling is entity-relationship (E-R) dia- gramming. A similar format used with object-oriented analysis and design methods is class diagramming, which is included in a special section at the end of this chapter on the object-oriented development approach to data modeling. Data models that use E-R and class diagram notations explain the characteristics and structure of data independent of how the data may be stored in computer memory. A data model is usually developed iteratively, either from scratch or from a purchased data model for the industry or business area to be supported. Information system (IS) planners use this preliminary data model to develop an enterprise-wide data model with very broad categories of data and little detail. Next, during the definition of a project, a specific data model is built to help explain the scope of a particular systems analysis and design effort. During requirements structuring, a data model represents conceptual data requirements for a particular system. Then, after system inputs and outputs are fully described during logi- cal design, the data model is refined before it is translated into a logical format (typi- cally a relational data model) from which database definition and physical database design are done. A data model represents certain types of business rules that govern the properties of data. Business rules are important statements of business policies that ideally will be enforced through the database and database management system ultimately used for the application you are designing. Thus, you will use E-R and class diagramming in many systems development project steps, and most IS project members need to know how to develop and read data model diagrams. Therefore, mastery of the requirements structuring methods and techniques addressed in this chapter is critical to your success on a systems development project team.

CONCEPTUAL DATA MODELING A conceptual data model is a representation of organizational data. The purpose of a conceptual data model is to show as many rules about the meaning and interrelation- ships among data as are possible.

Conceptual data modeling is typically done in parallel with other requirements analysis and structuring steps during systems analysis (see Figure 8-1), as outlined in prior chapters. On larger systems development teams, a subset of the project team concentrates on data modeling while other team members focus attention on pro- cess or logic modeling. Analysts develop (or use from prior systems development) a conceptual data model for the current system and then build or refine a purchased conceptual data model that supports the scope and requirements for the proposed or enhanced system.

The work of all team members is coordinated and shared through the project dictionary or repository. This repository is often maintained by a common Computer- Aided Software Engineering (CASE) or data modeling software tool, but some orga- nizations still use spreadsheets and other types of files to store data descriptions and other important information. No matter how the information is stored, it is essential that the process, logic, and data model descriptions of a system are consistent and complete because each describes different, but complementary, views of the same information system. For example, the names of data stores on the primitive-level DFDs

Conceptual data model A detailed model that captures the overall structure of organizational data and is independent of any database management system or other implementation considerations.

M08_VALA1629_09_GE_C08.indd 267 08/04/2020 16:41

268 PART III ANALYSIS

often correspond to the names of data entities in E-R diagrams, and the data elements associated with data flows on DFDs must be accounted for by attributes of entities and relationships in E-R diagrams.

The Conceptual Data Modeling Process

The process of conceptual data modeling begins with developing a conceptual data model for the system being replaced, if a system already exists. This is essential for planning the conversion of the current files or database into the database of the new system. Further, this is a good, but not a perfect, starting point for your understand- ing of the data requirements of the new system. Then, a new conceptual data model is built (or a standard one is purchased) that includes all of the data requirements for the new system. You discovered these requirements from the fact-finding methods employed during requirements determination. Today, given the popularity of rapid development methodologies, such as the use of predefined patterns, these require- ments often evolve through various iterations from some starting point in a purchased application or database design. Even when developed from scratch, data modeling is an iterative process with many checkpoints.

Conceptual data modeling is one kind of data modeling and database design carried out throughout the systems development process. Figure 8-2 shows the differ- ent kinds of data modeling and database design that go on during the whole system’s development life cycle (SDLC). The conceptual data modeling methods we discuss in this chapter are suitable for the planning and analysis phases; these methods can be used with either a data model developed from scratch or based on a purchased data model. The planning phase of the SDLC addresses issues of system scope, gen- eral requirements, and content independent of technical implementation. E-R and class diagramming are suited for this phase because these diagrams can be translated into a wide variety of technical architectures for data, such as relational, network, and hierarchical architectures. A data model evolves from the early stages of plan- ning through the analysis phase as it becomes more specific and is validated by more detailed analyses of system needs.

In the design phase, the final data model developed in analysis is matched with designs for systems inputs and outputs and is translated into a format from which physical data storage decisions can be made. After specific data storage architectures are selected, then files and databases are defined as the system is coded during imple- mentation. Through the use of the project repository, a field in a physical data record can, for example, be traced back to the conceptual data attribute that represents it on

FIGURE 8-1 Systems development life cycle with analysis phase highlighted

DesignImplementation

Planning

Maintenance Analysis Requirements Determination Requirements Structuring

M08_VALA1629_09_GE_C08.indd 268 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 269

a data model diagram. Thus, the data modeling and design steps in each of the SDLC phases are linked through the project repository.

Deliverables and Outcomes

Most organizations today do conceptual data modeling using E-R modeling, which uses a special notation to represent as much meaning about data as possible. Because of the rapidly increasing interest in object-oriented methods, class diagrams using unified modeling language (UML) drawing tools such as IBM’s Rational products or Microsoft Visio are also popular. We will focus first on E-R diagramming and then later show how it differs from class diagramming.

The primary deliverable from the conceptual data modeling step within the analysis phase is an E-R diagram, similar to the one shown in Figure 8-3. This figure shows the major categories of data (rectangles on the diagram) and the business rela- tionships between them (lines connecting rectangles). For example, Figure 8-3 shows that, for the business represented by this diagram, a SUPPLIER sometimes Supplies ITEMS to the company, and an ITEM is always Supplied by one to four SUPPLIERS. The fact that a supplier only sometimes supplies items implies that the business wants to keep track of some suppliers without designating what they can supply. This dia- gram includes two names on each line so that a relationship can be read in each direc- tion. For simplicity, we will not typically include two names on lines in E-R diagrams in this book; however, this is a standard used in many organizations.

The other deliverable from conceptual data modeling is a full set of entries about data objects that will be stored in the project dictionary, repository, or data modeling software. The repository is the mechanism that links the data, processes, and logic models of an information system. For example, there are explicit links between a data model and a DFD. Some important links are explained briefly here.

• Data elements included in data flows also appear in the data model, and vice versa. You must include in the data model any raw data captured and retained in a data store, and a data model can include only data that have been captured or

FIGURE 8-2 Relationship between data modeling and the SDLC

DesignImplementation

Planning

Maintenance Analysis

• Enterprise-wide data model (E-R with only entities)

• Conceptual data model (E-R with only entities for specific project)

• Data model evolution

• Database and file definitions (DBMS-specific code)

• Logical data model (relational) and physical file and database design (file organizations)

• Conceptual data models (E-R with attributes)

M08_VALA1629_09_GE_C08.indd 269 08/04/2020 16:41

270 PART III ANALYSIS

that have been computed from captured data. Because a data model is a general business picture of data, both manual and automated data stores will be included.

• Each data store in a process model must relate to business objects (what we will call data entities) represented in the data model. For example, in Figure 7-5, the Inven- tory File data store must correspond to one or several data objects on a data model.

You can use an automated repository to verify these linkages.

GATHERING INFORMATION FOR CONCEPTUAL DATA MODELING Requirements determination methods must include questions and investigations that take a data, not only a process and logic, focus. For example, during interviews with potential system users—during Joint Application Design ( JAD) sessions or through requirements interviews—you must ask specific questions in order to gain the per- spective on data that you need to develop or tailor a purchased data model. In later sections of this chapter, we will introduce some specific terminology and constructs used in data modeling. Even without this specific data modeling language, you can begin to understand the kinds of questions that must be answered during require- ments determination. These questions relate to understanding the rules and policies by which the area to be supported by the new information system operates. That is, a data model explains what the organization does and what rules govern how work is performed in the organization. You do not, however, need to know (and often can’t fully anticipate) how or when data are processed or used to do data modeling.

You typically do data modeling from a combination of perspectives. The first per- spective is generally called the top-down approach. This perspective derives the business rules for a data model from an intimate understanding of the nature of the business, rather than from any specific information requirements in computer displays, reports, or business forms. It is this perspective that is typically the basis for a purchased data model. Several very useful sources of typical questions to elicit the business rules needed for data modeling can be found in Gottesdiener (1999), Herbst (2013), and

FIGURE 8-3 Sample conceptual data model

SUPPLIER ORDER

PRODUCTSHIPMENT

ENTITY TYPE

CUSTOMER

ITEM

Relationship

Key

Sends

Supplies Submits

4 Submitted_by

Requests

Requested_on

Used_in

Uses

Sent_by

Supplied_by

Includes

Included_on

Cardinalities

Mandatory One Optional One

Mandatory Many Optional Many

M08_VALA1629_09_GE_C08.indd 270 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 271

Witt (2012). Table 8-1 summarizes a few key questions you should ask system users and business managers so that you can develop an accurate and complete data model tailored to the particular situation. The questions in this table are purposely posed in business terms. You can ask these questions whether you start with a clean sheet of paper or a purchased data model, but typically the questions are more obvious and thorough when you begin the data modeling project with a purchased data model for the industry or application under development. In this chapter, you will learn the more technical terms included in bold at the end of each set of questions. Of course, these technical terms do not mean much to a business manager, so you must learn how to frame your questions in business terms for your investigation.

You can also gather the information you need for data modeling by review- ing specific business documents—computer displays, reports, and business forms— handled within the system. This process of gaining an understanding of data is often called a bottom-up approach. These items will appear as data flows on DFDs and will show the data processed by the system and, hence, probably the data that must be maintained in the system’s database. Consider, for example, Figure 8-4, which shows a customer order form used at Pine Valley Furniture (PVF). From this form, we deter- mine that the following data must be kept in the database:

ORDER NO CUSTOMER NO ORDER DATE NAME PROMISED DATE ADDRESS PRODUCT NO CITY-STATE-ZIP DESCRIPTION QUANTITY ORDERED UNIT PRICE

1. What are the subjects/objects of the business? What types of people, places, things, materials, events, etc. are used or interact in this business, about which data must be maintained? How many instances of each object might exist?—data entities and their descriptions

2. What unique characteristic (or characteristics) distinguishes each object from other objects of the same type? Might this distinguishing feature change over time or is it permanent? Might this characteristic of an object be missing even though we know the object exists?— primary key

3. What characteristics describe each object? On what basis are objects referenced, selected, qualified, sorted, and categorized? What must we know about each object in order to run the business?—attributes and secondary keys

4. How do you use these data? That is, are you the source of the data for the organization, do you refer to the data, do you modify it, and do you destroy it? Who is not permitted to use these data? Who is responsible for establishing legitimate values for these data?— security controls and understanding who really knows the meaning of data

5. Over what period of time are you interested in these data? Do you need historical trends, current “snapshot” values, and/or estimates or projections? If a characteristic of an object changes over time, must you know the obsolete values?—cardinality and time dimen- sions of data

6. Are all instances of each object the same? That is, are there special kinds of each object that are described or handled differently by the organization? Are some objects summaries or combinations of more detailed objects?—supertypes, subtypes, and aggregations

7. What events occur that imply associations among various objects? What natural activities or transactions of the business involve handling data about several objects of the same or a different type?—relationships and their cardinality and degree

8. Is each activity or event always handled the same way or are there special circumstances? Can an event occur with only some of the associated objects, or must all objects be involved? Can the associations between objects change over time (for example, employees change departments)? Are values for data characteristics limited in any way?— integrity rules, minimum and maximum cardinality, time dimensions of data

TABLE 8-1 Requirements Determination Questions for Data Modeling

PINE VALLEY FURNITURE

M08_VALA1629_09_GE_C08.indd 271 08/04/2020 16:41

272 PART III ANALYSIS

We also see that each order is from one customer and that an order can have multiple line items, one for each product. We will use this understanding of an orga- nization’s operation to develop data models.

INTRODUCTION TO E-R MODELING The basic E-R modeling notation uses three main constructs: data entities, relationships, and their associated attributes. Several different E-R notations exist, and many CASE and E-R drawing programs support multiple notations. For simplicity, we have adopted one common notation for this book; this notation uses the so-called crow’s foot symbols and places data attribute names within entity rectangles. This notation is very similar to that used by many E-R drawing tools, including Microsoft Visio. If you use another notation in courses or at work, you should be able to easily translate between notations.

An entity-relationship data model (E-R model) is a detailed, logical representation of the data for an organization or for a business area. The E-R model is expressed in terms of entities in the business environment, the relationships or associations among those entities, and the attributes or properties of both the entities and their relation- ships. An E-R model is normally expressed as an entity-relationship diagram (E-R diagram), which is a graphical representation of an E-R model. The notation we will use for E-R diagrams appears in Figure 8-5, and subsequent sections explain this notation.

Entities

An entity (see the first question in Table 8-1) is a person, place, object, event, or concept in the user environment about which the organization wishes to maintain data. An entity has its own identity that distinguishes it from each other entity. Some examples of entities follow:

• Person: EMPLOYEE, STUDENT, PATIENT • Place: STORE, WAREHOUSE, STATE • Object: MACHINE, BUILDING, AUTOMOBILE, PRODUCT • Event: SALE, REGISTRATION, RENEWAL • Concept: ACCOUNT, COURSE, WORK CENTER

There is an important distinction between entity types and entity instances. An entity type (sometimes called an entity class) is a collection of entities that share com- mon properties or characteristics. Each entity type in an E-R model is given a name. Because the name represents a class or set, it is singular. Also, because an entity is an object, we use a simple noun to name an entity type. We use capital letters in naming

Entity-relationship data model (E-R model) A detailed, logical representation of the entities, associations, and data elements for an organization or business area.

Entity-relationship diagram (E-R diagram) A graphical representation of an E-R model.

Entity type A collection of entities that share common properties or characteristics.

FIGURE 8-4 Sample customer form PVF CUSTOMER OR DER

OR DER NO: 613 84 CUSTOMER NO: 1273

NAME: Contemporary Designs ADDRESS: 123 Oak St. CITY-STATE-ZIP: Austin, TX 28384

OR DER DATE: 11/04/2020 PROMISED DATE: 11/21/2020

PRODU CT QUANTITY UNIT PRICENO DESCR IPTION OR DERED

M128 Bookcase 4 200.00 B381 Cabinet 2 150.00 R210 Table 1 500.00

M08_VALA1629_09_GE_C08.indd 272 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 273

an entity type and, in an E-R diagram, the name is placed inside a rectangle represent- ing the entity, as shown in Figure 8-6a.

An entity instance (also known simply as an instance) is a single occurrence of an entity type. An entity type is described just once in a data model, whereas many instances of that entity type may be represented by data stored in the database. For example, there is one EMPLOYEE entity type in most organizations, but there may be hundreds (or even thousands) of instances of this entity type stored in the database.

A common mistake many people make when they are just learning to draw E-R diagrams, especially if they already know how to do data flow diagramming, is to confuse data entities with sources/sinks or system outputs and relationships with data flows. A simple rule to avoid such confusion is that a true data entity will have many possible instances, each with a distinguishing characteristic, as well as one or more other descriptive pieces of data. Consider the entity types that might be associated with a sorority expense system, as represented in Figure 8-6b. In this situation, the sorority treasurer manages accounts and records expense transactions against each account. However, do we need to keep track of data about the treasurer and her supervision of accounts as part of this accounting system? The treasurer is the person entering data about accounts and expenses and making inquiries about account balances and expense transactions by category. Because there is only one treasurer, TREASURER data do not need to be kept. On the other hand, if each account has an account

Entity instance A single occurrence of an entity type. Also known as an instance.

FIGURE 8-5 Basic E-R notation

Mandatory One Mandatory Many Optional One Optional Many

Identifier Partial identifier

ENTITY NAME Strong

Associative

Entity Types

Relationship Degrees

Relationship Cardinality

Unary Binary

Weak

Attributes

Ternary

Optional [Derived] {Multivalued} Composite( , , )

FIGURE 8-6 Representing entity types (a) Three entity types (b) Questionable entity types

EMPLOYEE COURSE ACCOUNT

(a)

TREASURER ACCOUNT EXPENSE

(b)

M08_VALA1629_09_GE_C08.indd 273 08/04/2020 16:41

274 PART III ANALYSIS

manager (e.g., a sorority officer) who is responsible for assigned accounts, then we may wish to have an ACCOUNT MANAGER entity type with pertinent attributes as well as relationships to other entity types.

In this same situation, is an expense report an entity type? Because an expense report is computed from expense transactions and account balances, it is a data flow, not an entity type. Even though there will be multiple instances of expense reports over time, the report contents are already represented by the ACCOUNT and EXPENSE entity types.

Often when we refer to entity types in subsequent sections, we will simply say entity. This is common among data modelers. We will clarify that we mean an entity by use of the term entity instance.

Naming and Defining Entity Types Clearly naming and defining data, such as entity types, are important tasks during requirements determination and structuring. When naming and defining entity types, you should use the following guidelines:

• An entity type name is a singular noun (such as CUSTOMER, STUDENT, or AUTOMOBILE).

• An entity type name should be descriptive and specific to the organization. For example, a PURCHASE ORDER for orders placed with suppliers is distinct from CUSTOMER ORDER for orders placed by customers. Both of these entity types cannot be named ORDER.

• An entity type name should be concise. For example, in a university database, use REGISTRATION for the event of a student registering for a class rather than STUDENT REGISTRATION FOR CLASS.

• Event entity types should be named for the result of the event, not the activity or process of the event. For example, the event of a project manager assigning an employee to work on a project results in an ASSIGNMENT.

Some specific guidelines for defining entity types follow:

• An entity type definition should include a statement of what the unique characteristic(s) is (are) for each instance of the entity type.

• An entity type definition should make clear what entity instances are included and not included in the entity type. For example, “A customer is a person or organization that has placed an order for a product from us or that we have contacted to adver- tise or promote our products. A customer does not include persons or organiza- tions that buy our products only through our customers, distributors, or agents.”

• An entity type definition often includes a description of when an instance of the entity type is created and deleted.

• For some entity types, the definition must specify when an instance might change into an instance of another entity type; for example, a bid for a construction com- pany becomes a contract once it is accepted.

• For some entity types, the definition must specify what history is to be kept about entity instances. Statements about keeping history may have ramifications about how we represent the entity type on an E-R diagram and eventually how we store data for the entity instances.

Attributes

Each entity type has a set of attributes (see the third question in Table 8-1) associated with it. An attribute is a property or characteristic of an entity that is of interest to the organization (relationships may also have attributes, as we will see in the section on relationships). Following are some typical entity types and associated attributes:

STUDENT: Student_ID, Student_Name, Home_Address, Phone_Number, Major AUTOMOBILE: Vehicle_ID, Color, Weight, Horsepower EMPLOYEE: Employee_ID, Employee_Name, Payroll_Address, Skill

Attribute A named property or characteristic of an entity that is of interest to the organization.

M08_VALA1629_09_GE_C08.indd 274 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 275

We use an initial capital letter, followed by lowercase letters, and nouns in nam- ing an attribute; underscores may or may not be used to separate words. In E-R dia- grams, we represent an attribute by placing its name inside the rectangle for the associated entity (see Figure 8-5). We use different notations for attributes to distin- guish between different types of attributes, which we describe below. Our notation is similar to that used by many CASE and E-R drawing tools, such as Microsoft Visio or Oracle’s Designer. Precisely how different types of attributes are shown varies by tool.

Naming and Defining Attributes Often several attributes have approximately the same name and meaning. Thus, it is important to carefully name attributes using the following guidelines:

• An attribute name is a noun (such as Customer_ID, Age, or Product_Minimum_ Price).

• An attribute name should be unique. No two attributes of the same entity type may have the same name, and it is desirable, for clarity, that no two attributes across all entity types have the same name.

• To make an attribute name unique and for clarity, each attribute name should fol- low a standard format. For example, your university may establish Student_GPA, as opposed to GPA_of_Student, as an example of the standard format for attri- bute naming.

• Similar attributes of different entity types should use similar but distinguishing names; for example, the city of residence for faculty and students should be, respec- tively, Faculty_Residence_City_Name and Student_Residence_City_Name.

Some specific guidelines for defining attributes follow:

• An attribute definition states what the attribute is and possibly why it is important. • An attribute definition should make it clear what is included and what is not

included in the attribute’s value; for example, “Employee_Monthly_ Salary_ Amount is the amount of money paid each month in the currency of the coun- try of residence of the employee exclusive of any benefits, bonuses, reimburse- ments, or special payments.”

• Any aliases, or alternative names, for the attribute can be specified in the definition.

• It may also be desirable to state in the definition the source of values for the attri- bute. Stating the source may make the meaning of the data clearer.

• An attribute definition should indicate if a value for the attribute is required or optional. This business rule about an attribute is important for maintaining data integrity.

• An attribute definition may indicate if a value for the attribute may change once a value is provided and before the entity instance is deleted. This business rule also controls data integrity.

• An attribute definition may also indicate any relationships that attribute has with other attributes; for example, “Employee_Vacation_Days_Number is the num- ber of days of paid vacation for the employee. If the employee has a value of ‘Exempt’ for Employee_Type, then the maximum value for Employee_ Vacation_Days_Number is determined by a formula involving the number of years of service for the employee.”

Candidate Keys and Identifiers

Every entity type must have an attribute or set of attributes that distinguishes one instance from other instances of the same type (see the second question in Table 8-1). A candidate key is an attribute (or combination of attributes) that uniquely identifies each instance of an entity type. A candidate key for a STUDENT entity type might be Student_ID.

Sometimes a combination of attributes is required to identify a unique entity. For example, consider the entity type GAME for a basketball league. The attribute

Candidate key An attribute (or combination of attributes) that uniquely identifies each instance of an entity type.

M08_VALA1629_09_GE_C08.indd 275 08/04/2020 16:41

276 PART III ANALYSIS

Team_Name is clearly not a candidate key because each team plays several games. If each team plays exactly one home game against each other team, then the combina- tion of the attributes Home_Team and Visiting_Team is a composite candidate key for GAME.

Some entities may have more than one possible candidate key. One candidate key for EMPLOYEE is Employee_ID; a second is the combination of Employee_ Name and Address (assuming that no two employees with the same name live at the same address). If there is more than one possible candidate key, the designer must choose one of the candidate keys as the identifier. An identifier is a candidate key that has been selected to be used as the unique characteristic for an entity type. We show the identifier attribute(s) by placing a solid underline below the identifier (see Figure 8-5). Bruce (1992) suggests the following criteria for selecting identifiers:

• Choose a candidate key that will not change its value over the life of each instance of the entity type. For example, the combination of Employee_Name and Payroll_Address would probably be a poor choice as an identifier for EMPLOYEE because the values of Payroll_Address and Employee_Name could easily change during an employee’s term of employment.

• Choose a candidate key so that, for each instance of the entity, the attribute is guaranteed to have valid values and not be null. To ensure valid values, you may have to include special controls in data entry and maintenance routines to eliminate the possibility of errors. If the candidate key is a combination of two or more attributes, make sure that all parts of the key have valid values.

• Avoid the use of so-called intelligent identifiers, whose structure indicates clas- sifications, locations, and so on. For example, the first two digits of a key for a PART entity may indicate the warehouse location. Such codes are often modi- fied as conditions change, which renders the primary key values invalid.

• Consider substituting single-attribute surrogate keys for large composite keys. For example, an attribute called Game_ID could be used for the entity GAME instead of the combination of Home_Team and Visiting_Team.

Figure 8-7 shows the representation for a STUDENT entity type using our E-R notation. STUDENT has a simple identifier, Student_ID, and three other simple attributes.

Other Attribute Types

A multivalued attribute may take on more than one value for each entity instance. Suppose that Skill is one of the attributes of EMPLOYEE. If each employee can have more than one skill, Skill is a multivalued attribute. Two ways of showing multivalued attributes are common. The first is to list the multivalued attribute along with other attributes, but use a special symbol to indicate that it is multivalued. This is the approach taken in Figure 8-8a, where the multivalued attribute skill is enclosed in curly brackets.

Sometimes a set of data repeats together. For example, consider Figure 8-8b for an employee entity with multivalued attributes for data about each employee’s dependents. In this situation, data such as dependent name, age, and relation to employee (spouse, child, parent, etc.) are multivalued attributes about an employee, and these attributes repeat together (we show this by using one set of curly brackets around the data that repeats together). Several attributes that repeat together are called a repeating group.

Conceptually, dependents can also be thought of as entities. Thus, many data analysts prefer a second approach to representing a repeating group. In this approach, we separate the repeating data into another entity, called a weak (or attributive) entity (designated by a rectangle with a double line border), and then use a relationship (relationships are discussed in the next section) to link the weak entity to its associ- ated regular entity (this particular relationship is also represented by a double line). We can show this in Figure 8-8c using a weak entity, DEPENDENT, and a relationship,

Identifier A candidate key that has been selected as the unique, identifying characteristic for an entity type.

Multivalued attribute An attribute that may take on more than one value for each entity instance.

Repeating group A set of two or more multivalued attributes that are logically related.

FIGURE 8-7 STUDENT entity type with attributes

Student_ID Student_Name Student_Campus_Address Student_Campus_Phone

STUDENT

M08_VALA1629_09_GE_C08.indd 276 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 277

between DEPENDENT and EMPLOYEE. The crow’s foot next to DEPENDENT means that there may be many DEPENDENTS for the same EMPLOYEE. The identifier of DEPENDENT is a combination of the dependent’s name and the ID of the employee for which this person is a dependent. It is sufficient to show Dep_Name in the weak entity and use a double underline to designate it as a partial identifier.

It may be important to designate whether an attribute must have a value (required attribute) or may not have a value (optional attribute) for every entity instance. It is also common to have an attribute, such as Name or Address, that has meaningful com- ponent parts, which we call a composite attribute. For some applications, people may want to simply refer to the set of component attributes by a composite name, whereas in other applications, we may need to display or compute with only some of the com- ponent parts. Also in conceptual modeling, users may refer to some datum that can be computed from other data in the database, a so-called derived attribute. In order to represent these unique characteristics of attributes, many E-R drawing tools have special notations for each of these types of attributes. In this text, we use the notation found in Figure 8-5. Figure 8-9 illustrates an EMPLOYEE entity with each of these types of attributes using our notation. Any identifier is required, and we have designated the composite attribute Employee_Name (with atomic components First_Name and Last_Name) as also required by putting these attribute names in bold. Date_of_Birth is an optional attribute. Employee_Age, also optional, can be computed from today’s date and Date_of_Birth, so it is a derived attribute.

Relationships

Relationships are the glue that holds together the various components of an E-R model (see the fifth, seventh, and eighth questions in Table 8-1). A relationship is an association between the instances of one or more entity types that is of interest to the organization. An association usually means that an event has occurred or that there exists some natural linkage between entity instances. For this reason, relationships are labeled with verb phrases. For example, in Figure 8-10a we represent a training department in a company that is interested in tracking which training courses each of

Required attribute An attribute that must have a value for every entity instance.

Optional attribute An attribute that may not have a value for every entity instance.

Composite attribute An attribute that has meaningful component parts.

Derived attribute An attribute whose value can be computed from related attribute values.

Relationship An association between the instance of one or more entity types that is of interest to the organization.

FIGURE 8-8 Multivalued attributes and repeating groupsEmployee_ID

Employee_Name Payroll_Address {Skill}

EMPLOYEE

(a) Multivalued attribute skill

Employee_ID { Dep_Name, Dep_Age, Dep_Relation}

EMPLOYEE

(b) Repeating group of dependent data

Employee_ID EMPLOYEE

Dep_Name Dep_Age Dep_Relation

DEPENDENT

FIGURE 8-9 Required, optional, composite, and derived attributes

Employee_ID Employee_Name(First_Name, Last_Name) Date_of_Birth [Employee_Age]

EMPLOYEE

M08_VALA1629_09_GE_C08.indd 277 08/04/2020 16:41

278 PART III ANALYSIS

its employees has completed. This leads to a relationship called Completes between the EMPLOYEE and COURSE entity types.

As indicated by the arrows, this is a many-to-many relationship: Each employee may complete more than one course, and each course may be completed by more than one employee. More significantly, we can use the Completes relationship to determine the specific courses that a given employee has completed. Conversely, we can determine the identity of each employee who has completed a particular course. For example, consider the employees and courses shown in Figure 8-10b. In this illus- tration, Melton has completed three courses (C++, COBOL, and Perl) and the SQL course has been completed by Celko and Gosling.

We sometimes use two verb phrases for a relationship name so that there is an explicit name for the relationship in each direction. The standards you follow will be determined by your organization.

CONCEPTUAL DATA MODELING AND THE E-R MODEL The last section introduced the fundamentals of the E-R data modeling notation— entities, attributes, and relationships. The goal of conceptual data modeling is to capture as much of the meaning of data as possible. The more details (business rules) about data that we can model, the better the system we can design and build. Further, if we can include all these details in a CASE repository, and if a CASE tool can generate code for data definitions and programs, then the more we know about data, the more code we can generate automatically. This will make system building more accurate and faster. More important, if we can keep a thorough repository of data descriptions, we can regenerate the system as the business rules change. Because maintenance is the largest expense with any information system, the efficiencies gained by maintaining systems at the rule rather than the code level drastically reduce the cost.

In this section, we explore more advanced concepts needed to model data more thoroughly and learn how the E-R notation represents these concepts.

FIGURE 8-10 Relationship type and instances (a) Relationship type (Completes) (b) Relationship instances

Completes EMPLOYEE

Employee_ID Employee_Name(. . .) Birth_Date

COURSE Course_ID Course_Title {Topic}

(a)

C++

Java

COBOL

Visual Basic

Perl

SQL

Chen

Melton

Ritchie

Celko

Gosling

Employee Course(b)

M08_VALA1629_09_GE_C08.indd 278 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 279

Degree of a Relationship

The degree of a relationship (see the seventh question in Table 8-1) is the number of entity types that participate in that relationship. Thus, the relationship Completes illus- trated in Figure 8-10a is of degree two because there are two entity types: EMPLOYEE and COURSE. The three most common relationships in E-R models are unary (degree one), binary (degree two), and ternary (degree three). Higher-degree relationships are possible, but they are rarely encountered in practice, so we restrict our discussion to these three cases. Examples of unary, binary, and ternary relationships appear in Figure 8-11.

Unary Relationships Also called a recursive relationship, a unary relationship is a relationship between the instances of one entity type. Three examples are shown in Figure 8-11. In the first example, Is_married_to is shown as a one-to-one relationship between instances of the PERSON entity type. That is, each person may be currently married to one other person. In the second example, Manages is shown as a one- to-many relationship between instances of the EMPLOYEE entity type. Using this relationship, we can identify, for example, the employees who report to a particular manager; reading the Manages relationship in the opposite direction, we can identify

Degree The number of entity types that participate in a relationship.

Unary relationship A relationship between instances of one entity type; also called recursive relationship.

FIGURE 8-11 Examples of relationships of different degrees (a) Unary relationships (b) Binary relationships (c) Ternary relationship

PERSON

One-to-one One-to-many One-to-one

Is_married_to Manages Stands_after

EMPLOYEE TEAM

(a)

EMPLOYEE PARKING

SPACE

STUDENT COURSE

PRODUCT LINE

PRODUCT

One-to-one

Many-to-many

One-to-many

Is_assigned

Registers_for

Contains

(b)

VENDOR

PART

WAREHOUSE Supplies

Shipping_Mode Unit_Cost

(c)

M08_VALA1629_09_GE_C08.indd 279 08/04/2020 16:41

280 PART III ANALYSIS

who the manager is for a given employee. In the third example, Stands_after is shown as a one-to-one relationship between instances of the TEAM entity type. This relation- ship represents the sequential order of teams in a league; this sequential ordering could be based on any criteria, such as winning percentage.

Figure 8-12 shows an example of another common unary relationship, called a bill-of-materials structure. Many manufactured products are made of subassemblies, which in turn are composed of other subassemblies and parts, and so on. As shown in Figure 8-12a, we can represent this structure as a many-to-many unary relationship. In this figure, we use Has_components for the relationship name. The attribute Quantity, which is a property of the relationship, indicates the number of each component that is contained in a given assembly.

Two occurrences of this structure are shown in Figure 8-12b. Each of these dia- grams shows the immediate components of each item as well as the quantities of that component. For example, item TX100 consists of item BR450 (quantity 2) and item DX500 (quantity 1). You can easily verify that the associations are in fact many-to-many. Several of the items have more than one component type (e.g., item MX300 has three immediate component types: HX100, TX100, and WX240). Also, some of the compo- nents are used in several higher-level assemblies. For example, item WX240 is used in both item MX300 and item WX340, even at different levels of the bill of materials. The many-to-many relationship guarantees that, for example, the same subassembly structure of WX240 (not shown) is used each time item WX240 goes into making some other item.

Binary Relationships A binary relationship is a relationship between instances of two entity types and is the most common type of relationship encountered in data modeling. Figure 8-11b shows three examples. The first (one-to-one) indicates that an employee is assigned one parking place, and each parking place is assigned to one employee. The second (one-to-many) indicates that a product line may contain several products, and each product belongs to only one product line. The third (many-to- many) shows that a student may register for more than one course, and that each course may have many student registrants.

Ternary Relationships A ternary relationship is a simultaneous relationship among instances of three entity types. In the example shown in Figure 8-11c, the relationship

Binary relationship A relationship between instances of two entity types. This is the most common type of relationship encountered in data modeling.

Ternary relationship A simultaneous relationship among instances of three entity types.

FIGURE 8-12 Representing a bill-of-materials structure (a) Many-to-many relationship (b) Two ITEM bill-of-materials structure instances Quantity

Has_components

ITEM

(a)

Mountain Bike MX300

Transmission System TX100

Qty: 1

Handle Bars HX100 Qty: 1

Brakes BR450 Qty: 2

Wheels WX240 Qty: 2

Derailer DX500 Qty: 1

Tandem Bike TR425

Transmission System TX101

Qty: 1

Handle Bars HT200 Qty: 2

Derailer DX500 Qty: 1

Wheels WX340 Qty: 2

Brakes BR250 Qty: 2

Wheels WX240 Qty: 2

Wheel Trim WT100 Qty: 2

(b)

M08_VALA1629_09_GE_C08.indd 280 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 281

Supplies tracks the quantity of a given part that is shipped by a particular vendor to a selected warehouse. Each entity may be a one or a many participant in a ternary relationship (in Figure 8-11, all three entities are many participants).

Note that a ternary relationship is not the same as three binary relationships. For example, Shipping_Mode is an attribute of the Supplies relationship in Figure 8-11c. Shipping_Mode cannot be properly associated with any of the three possible binary relationships among the three entity types (such as that between PART and VENDOR) because Shipping_Mode is the type of shipping carrier used for a particular PART shipped from a particular VENDOR to a particular WAREHOUSE. We strongly recom- mend that all ternary (and higher) relationships be represented as associative entities (described later). We examine the cardinality of relationships next.

Cardinalities in Relationships

Suppose there are two entity types, A and B, connected by a relationship. The cardinality of a relationship (see the fifth, seventh, and eighth questions in Table 8-1) is the number of instances of entity B that can (or must) be associated with each instance of entity A. For example, consider the relationship for DVDs at a video store shown in Figure 8-13a.

Clearly, a video store may stock more than one DVD of a given movie. In the terminology we have used so far, this example is intuitively a “many” relationship. Yet it is also true that the store may not have a single copy of a particular movie in stock. We need a more precise notation to indicate the range of cardinalities for a relationship. This notation was introduced in Figure 8-5, which you may want to review at this point.

Minimum and Maximum Cardinalities The minimum cardinality of a relation- ship is the minimum number of instances of entity B that may be associated with each instance of entity A. In the preceding example, the minimum number of DVDs avail- able for a movie is zero, in which case we say that DVD is an optional participant in the Is_stocked_as relationship. When the minimum cardinality of a relationship is one, then we say that entity B is a mandatory participant in the relationship. The maximum cardinality is the maximum number of instances. For our example, this maximum is “many” (an unspecified number greater than one). Using the notation from Figure 8-5, we diagram this relationship in Figure 8-13b. The zero through the line near the DVD entity means a minimum cardinality of zero, whereas the crow’s foot notation means a “many” maximum cardinality. The double underline of Copy_Number indicates that this attribute is part of the identifier of DVD, but the full composite identifier must also include the identifier of MOVIE, Movie_Name.

Examples of three relationships that show all possible combinations of mini- mum and maximum cardinalities appear in Figure 8-14. A brief description of each relationship follows:

1. PATIENT Has_recorded PATIENT_HISTORY (Figure 8-14a). Each patient has recorded one or more patient histories (we assume that the initial patient visit is always recorded as an instance of PATIENT HISTORY). Each instance of PATIENT HISTORY is a record for exactly one PATIENT.

Cardinality The number of instances of entity B that can (or must) be associated with each instance of entity A.

FIGURE 8-13 Introducing cardinality constraints (a) Basic relationship (b) Relationship with cardinality constraints

Is_stocked_as DVDMOVIE

(a)

Is_stocked_asMOVIE Movie_Name

DVD Copy_Number

(b)

M08_VALA1629_09_GE_C08.indd 281 08/04/2020 16:41

282 PART III ANALYSIS

2. EMPLOYEE Is_assigned_to PROJECT (Figure 8-14b). Each PROJECT has at least one assigned EMPLOYEE (some projects have more than one). Each EMPLOYEE may or (optionally) may not be assigned to any existing PROJECT, or may be assigned to several PROJECTs.

3. PERSON Is_married_to PERSON (Figure 8-14c). This is an optional zero or one cardinality in both directions because a person may or may not be married.

It is possible for the maximum cardinality to be a fixed number, not an arbitrary “many” value. For example, suppose corporate policy states that an employee may work on at most five projects at the same time. We could show this business rule by placing a “5” above or below the crow’s foot next to the PROJECT entity in Figure 8-14b.

Naming and Defining Relationships

Relationships may be the most difficult component of an E-R diagram to understand. Thus, you should use a few special guidelines for naming relationships, such as the following:

• A relationship name is a verb phrase (such as Assigned_to, Supplies, or Teaches). Rela- tionships represent actions, usually in the present tense. A relationship name states the action taken, not the result of the action (e.g., use Assigned_to, not Assignment).

• You should avoid vague names, such as Has or Is_related_to. Use descriptive verb phrases taken from the action verbs found in the definition of the relationship.

Specific guidelines for defining relationships follow:

• A relationship definition explains what action is being taken and possibly why it is important. It may be important to state who or what does the action, but it is not important to explain how the action is taken.

• It may be important to give examples to clarify the action. For example, for a rela- tionship Registered_for between student and course, it may be useful to explain that this covers both on-site and online registration and registrations made dur- ing the drop/add period.

FIGURE 8-14 Examples of cardinality constraints (a) Mandatory cardinalities (b) One optional, one mandatory cardinality (c) Optional cardinalities

Mark

Sarah

Elsie

Visit 1

Visit 1 Visit 2

PATIENT PATIENT HISTORY

Has recorded (a)

Rose

Pete

Debbie

Tom

Heidi

BPR

TQM

EMPLOYEE Is_assigned_to

PROJECT

(b)

Shirley

Mack

Dawn

Kathy

Ellis

Fred

PERSON

Is_married_to (c)

M08_VALA1629_09_GE_C08.indd 282 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 283

• The definition should explain any optional participation. You should explain what conditions lead to zero associated instances, whether this can happen only when an entity instance is first created or whether this can happen at any time.

• A relationship definition should also explain the reason for any explicit maximum cardinality other than many.

• A relationship definition should explain any restrictions on participation in the relation- ship. For example, “Supervised_by links an employee with the other employees he or she supervises and links an employee with the other employee who supervises him or her. An employee cannot supervise him or herself, and an employee can- not supervise other employees if his or her job classification level is below 4.”

• A relationship definition should explain the extent of history that is kept in the relationship. • A relationship definition should explain whether an entity instance involved in a

relationship instance can transfer participation to another relationship instance. For example, “Places links a customer with the orders they have placed with our company. An order is not transferable to another customer.”

Associative Entities

As seen in the examples of the Supplies relationship in Figure 8-11 and the Has_com- ponents relationship of Figure 8-12, attributes may be associated with a many-to-many relationship as well as with an entity. For example, suppose that the organization wishes to record the date (month and year) that an employee completes each course. Some sample data follow:

Employee_ID Course_Name Date_Completed 549-23-1948 Basic Algebra March 2020 629-16-8407 Software Quality June 2020 816-30-0458 Software Quality February 2020 549-23-1948 C Programming May 2020

From these limited data, you can conclude that the attribute Date_Completed is not a property of the entity EMPLOYEE because a given employee, 549-23-1948, has com- pleted courses on different dates. Nor is Date_Completed a property of COURSE because a particular course (Software Quality) may be completed on different dates. Instead, Date_Completed is a property of the relationship between EMPLOYEE and COURSE. The attribute is associated with the relationship and diagrammed in Figure 8-15.

FIGURE 8-15 An associative entity (a) Attribute on a relationship (b) An associative entity (CERTIFICATE) (c) An associative entity using Microsoft Visio

B A EMPLOYEE

Employee_ID Employee_Name(. . .) Birth_Date

Completes

Course_ID Course_Title {Topic}

COURSE

Date_Completed

(a)

A BEMPLOYEEEmployee_ID Employee_Name(. . .) Birth_Date

COURSE Course_ID Course_Title {Topic}

Certificate_Number Date_Completed

CERTIFICATE (b)

Employee_IDPK

Employee_Name

EMPLOYEE

Certificate_NumberPK

Date_Completed

CERTIFICATE

Course_IDPK

Course_Title

COURSE (c)

M08_VALA1629_09_GE_C08.indd 283 08/04/2020 16:41

284 PART III ANALYSIS

Because many-to-many and one-to-one relationships may have associated attri- butes, the E-R data model poses an interesting dilemma: Is a many-to-many rela- tionship actually an entity in disguise? Often the distinction between entity and relationship is simply a matter of how you view the data. An associative entity (some- times called a gerund) is a relationship that the data modeler chooses to model as an entity type. Figure 8-15b shows the E-R notation for representing the Completes relationship as an associative entity and Figure 8-15c shows how this would be mod- eled using Microsoft Visio. The lines from CERTIFICATE to the two entities are not two separate binary relationships, so they do not have labels. Note that EMPLOYEE and COURSE have mandatory one cardinality because an instance of Completes must have an associated EMPLOYEE and COURSE. The labels A and B show where the cardinalities from the Completes relation now appear. We have created an identifier for CERTIFICATE of Certificate_Number, rather than use the implied combination of the identifiers of EMPLOYEE and COURSE, Employee_ID and Course_Name, respectively.

An example of the use of an associative entity for a ternary relationship appears in Figure 8-16. This figure shows an alternative (and more explicit) representation of the ternary Supplies relationship shown in Figure 8-11. In Figure 8-16, the entity type (associative entity) SHIPMENT SCHEDULE replaces the Supplies relationship from Figure 8-11. Each instance of SHIPMENT SCHEDULE represents a real-world shipment by a given vendor of a particular part to a selected warehouse. The Ship- ment_Mode and Unit_Cost are attributes of SHIPMENT SCHEDULE. We have not designated an identifier for SHIPMENT SCHEDULE, so implicitly it would be a com- posite identifier of the identifiers of the three related entities. Business rules about participation of vendors, parts, and warehouses in supplies relationships are shown via the cardinalities next to SUPPLY SCHEDULE. Remember, as with any associative identity, these are not three separate relationships.

One situation in which a relationship must be turned into an associative entity is when the associative entity has other relationships with entities besides the relation- ship that caused its creation. For example, consider the E-R diagram in Figure 8-17a that represents price quotes from different vendors for purchased parts stocked by PVF. Now, suppose that we also need to know which price quote is in effect for each part shipment received. This additional data requirement necessitates that the Quotes_price relationship be transformed into an associative entity, as shown in Figure 8-17b.

Associative entity An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity Instances; also called a gerund.

FIGURE 8-16 Cardinality constraints in a ternary relationship

Each vendor can supply many parts to any number of ware- houses, but need not supply any parts.

Each part can be supplied by any number of vendors to more than one warehouse, but each part must be supplied by at least one vendor to a warehouse.

Each warehouse can be supplied with any number of parts from more than one vendor, but each warehouse must be supplied with at least one part.

Business Rules

PART

VENDOR

SUPPLY SCHEDULE Shipping_Mode Unit_Cost

WAREHOUSE

M08_VALA1629_09_GE_C08.indd 284 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 285

In this case, PRICE QUOTE is not a ternary relationship. Rather, PRICE QUOTE is a binary many-to-many relationship (associative entity) between VENDOR and PART. In addition, each PART RECEIPT, based on Amount, has an applicable, nego- tiated Price. Each PART RECEIPT is for a given PART from a specific VENDOR, and the Amount of the receipt dictates the purchase price in effect by matching with the Quantity attribute. Because the PRICE QUOTE pertains to a given PART and a given VENDOR, PART RECEIPT does not need direct relationships with these entities.

Summary of Conceptual Data Modeling with E-R Diagrams

The purpose of E-R diagramming is to capture the richest possible understanding of the meaning of data necessary for an information system or organization. Besides the aspects shown in this chapter, there are many other semantics about data that E-R diagramming can represent. Some of these more advanced capabilities are explained in Hoffer, Ramesh, & Topi (2016), Hills (2016), or Kroenke, Auer, Vandenberg, & Yoder (2017). You can also find some general guidelines for effective conceptual data modeling in Hoberman, Burbank, & Bradley (2012). The following section presents one final aspect of conceptual data modeling: capturing the relationship between similar entity types.

REPRESENTING SUPERTYPES AND SUBTYPES Often two or more entity types seem very similar (maybe they have almost the same name), but there are a few differences. That is, these entity types share common prop- erties but also have one or more distinct attributes or relationships. To address this situ- ation, the E-R model has been extended to include supertype/subtype relationships. A subtype is a subgrouping of the entities in an entity type that is meaningful to the organization. For example, STUDENT is an entity type in a university. Two subtypes of STUDENT are GRADUATE STUDENT and UNDERGRADUATE STUDENT. A super- type is a generic entity type that has a relationship with one or more subtypes.

Subtype A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings.

Supertype A generic entity type that has a relationship with one or more subtypes.

FIGURE 8-17 Situation requiring an associative entity (a) Many-to-many relationship with attributes (b) Associative entity with separate relationship

PART

Quantity Price

VENDOR

PART

PART RECEIPT Order_Number Date Amount

VENDOR

PRICE QUOTE Quantity Price

Priced_at

(a)

(b)

M08_VALA1629_09_GE_C08.indd 285 08/04/2020 16:41

286 PART III ANALYSIS

An example illustrating the basic notation used for supertype/subtype relation- ships appears in Figure 8-18. The supertype PATIENT is connected with a line to a circle, which in turn is connected by a line to each of the two subtypes, OUTPATIENT and RESIDENT PATIENT. Attributes that are shared by all patients (including the identifier) are associated with the supertype; attributes that are unique to a particular subtype (e.g., Checkback_Date for OUTPATIENT) are associated with that subtype. Relationships in which all types of patients participate (Is_cared_for) are associated with the supertype; relationships in which only a subtype participates (Is_assigned for RESIDENT PATIENTS) are associated only with the relevant subtype.

Several important business rules govern supertype/subtype relationships. The total specialization rule specifies that each entity instance of the supertype must be a member of some subtype in the relationship. The partial specialization rule specifies that an entity instance of the supertype does not have to belong to any subtype. Total specialization is shown on an E-R diagram by a double line from the supertype to the circle, and partial specialization is shown by a single line. The disjoint rule specifies that if an entity instance of the supertype is a member of one subtype, it cannot simul- taneously be a member of any other subtype. The overlap rule specifies that an entity instance can simultaneously be a member of two (or more) subtypes. Disjoint versus overlap is shown by a “d” or an “o” in the circle.

Figure 8-19 illustrates several combinations of these rules for a hierarchy of supertypes and subtypes in a university database. In this example

• a PERSON must be (total specialization) an EMPLOYEE, an ALUMNUS, or a STUDENT, or any combination of these subtypes (overlap);

• an EMPLOYEE must be a FACULTY or a STAFF (disjoint), or may be just an EMPLOYEE (partial specialization); and

• a STUDENT can be only a GRADUATE STUDENT or an UNDERGRADUATE STUDENT and nothing else (total specialization and disjoint).

BUSINESS RULES Conceptual data modeling is a step-by-step process for documenting information requirements, and it is concerned with both the structure of data and with rules about the integrity of those data (see the eighth question in Table 8-1). Business rules are specifications that preserve the integrity of the logical data model. Four basic types of business rules are as follows:

1. Entity integrity. Each instance of an entity type must have a unique identifier that is not null.

Total specialization rule Specifies that each entity instance of the supertype must be a member of some subtype of the relationship.

Partial specialization rule Specifies that an entity instance of the supertype does not have to belong to any subtype.

Disjoint rule Specifies that if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype.

Overlap rule Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

Business rules Specifications that preserve the integrity of the logical data model.

FIGURE 8-18 Supertype/subtype relationships in a hospital

Checkback_Date

OUTPATIENT RESIDENT PATIENT

Date_Discharged

Is_cared_for

Is_assigned BED

Bed_ID

PATIENT

Patient_ID Patient_Name Admit_Date

RESPONSIBLE PHYSICIAN

Physician_ID

M08_VALA1629_09_GE_C08.indd 286 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 287

2. Referential integrity constraints. Rules concerning the relationships between entity types.

3. Domains. Constraints on valid values for attributes. 4. Triggering operations. Other business rules that protect the validity of attribute

values.

The E-R model that we have described in this chapter is concerned primarily with the structure of data rather than with expressing business rules (although some elemen- tary rules are implied in the E-R model). Generally, the business rules are captured during requirements determination and stored in the CASE repository as they are docu- mented. Entity integrity was described earlier in this chapter, and referential integrity is described in Chapter 9 because it applies to database design. In this section, we briefly describe two types of rules: domains and triggering operations. These rules are illustrated with a simple example from a banking environment, shown in Figure 8-20a. In this example, an ACCOUNT entity has a relationship (Is_for) with a WITHDRAWAL entity.

Domains

A domain is the set of all data types and ranges of values that attributes may assume (Hoffer et al., 2016). Domain definitions typically specify some (or all) of the following characteristics of attributes: data type, length, format, range, allowable values, meaning, uniqueness, and null support (whether an attribute value may or may not be null).

Figure 8-20b shows two domain definitions for the banking example. The first definition is for Account_Number. Because Account_Number is an identifier attri- bute, the definition specifies that Account_Number must be unique and must not be null (these specifications are true of all identifiers). The definition specifies that the

Domain The set of all data types and values that an attribute can assume.

FIGURE 8-19 Example of supertype/subtype hierarchyPERSON

SSN Name Address Gender Date_of_Birth

ALUMNUS

{Degree(Year, Designation, Date)}

Contract_Number Billing_Rate

Salary Date_Hired

EMPLOYEE STUDENT

Major_Dept

STAFF

PositionRank

FACULTY UNDERGRAD STUDENT

Class_StandingTest_Score

GRADUATE STUDENT

M08_VALA1629_09_GE_C08.indd 287 08/04/2020 16:41

288 PART III ANALYSIS

attribute data type is character and that the format is nnn-nnnn. Thus, any attempt to enter a value for this attribute that does not conform to its character type or format will be rejected, and an error message will be displayed.

The domain definition for the Amount attribute (dollar amount of the requested withdrawal) also may not be null, but is not unique. The format allows for two decimal places to accommodate a currency field. The range of values has a lower limit of zero (to prevent negative values) and an upper limit of 10,000. The latter is an arbitrary upper limit for a single withdrawal transaction.

The use of domains offers several advantages:

• Domains verify that the values for an attribute (stored by insert or update opera- tions) are valid.

• Domains ensure that various data manipulation operations (such as joins or unions in a relational database system) are logical.

• Domains help conserve effort in describing attribute characteristics.

Domains can conserve effort because we can define domains and then associate each attribute in the data model with an appropriate domain. To illustrate, suppose that a bank has three types of accounts, with the following identifiers:

Account Type Identifier CHECKING Checking_Account_Number SAVINGS Savings_Account_Number LOAN Loan_Account_Number

If domains are not used, the characteristics for each of the three identifier attri- butes must be described separately. Suppose, however, that the characteristics for all three of the attributes are identical. Having defined the domain Account_Number once (as shown in Figure 8-13b), we simply associate each of these three attributes with Account_Number. Other common domains such as Date, Social_Security_Number, and Telephone_Number also need to be defined just once in the model.

FIGURE 8-20 Examples of business rules (a) Simple banking relationship (b) Typical domain definitions (c) Typical triggering operation

ACCOUNT Is_forAccount_Number

Balance

WITHDRAWAL Date Time Amount

(a)

Name: Account_Number Name: Amount Meaning: Customer account number in bank Meaning: Dollar amount of transaction Data type: Character Data type: Numeric Format: nnn-nnnn Format: 2 decimal places Uniqueness: Must be unique Range: 0–10,000 Null support: Non-null Uniqueness: Nonunique

Null support: Non-null

(b)

User rule: WITHDRAWAL Amount may not exceed ACCOUNT Balance Event: Insert Entity Name: WITHDRAWAL Condition: WITHDRAWAL Amount > ACCOUNT Balance Action: Reject the insert transaction

(c)

M08_VALA1629_09_GE_C08.indd 288 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 289

Triggering Operations

A triggering operation (also called a trigger) is an assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete. The scope of triggering operations may be limited to attributes within one entity or it may extend to attributes in two or more entities. Complex business rules may often be stated as triggering operations.

A triggering operation normally includes the following components:

1. User rule. A concise statement of the business rule to be enforced by the triggering operation.

2. Event. The data manipulation operation (insert, delete, or update) that initiates the operation.

3. Entity name. The name of the entity being accessed and/or modified. 4. Condition. The condition that causes the operation to be triggered. 5. Action. The action taken when the operation is triggered.

Figure 8-20c shows an example of a triggering operation for the banking situa- tion. The business rule is a simple (and familiar) one: The amount of an attempted withdrawal may not exceed the current account balance. The event of interest is an attempted insert of an instance of the WITHDRAWAL entity type (perhaps from an automated teller machine). The condition is

Amount (of the withdrawal). ACCOUNT Balance

When this condition is triggered, the action taken is to reject the transaction. You should note two things about this triggering operation: First, it spans two entity types; second, the business rule could not be enforced through the use of domains.

The use of triggering operations is an increasingly important component of database strategy. With triggering operations, the responsibility for data integrity lies within the scope of the database management system rather than with application programs or human operators. In the banking example, tellers could conceivably check the account balance before processing each withdrawal. Human operators would be subject to human error and, in any event, manual processing would not work with automated teller machines. Alternatively, the logic of integrity checks could be built into the appropriate application programs, but integrity checks would require duplicating the logic in each program. There is no assurance that the logic would be consistent (because the application programs may have been developed at different times by different people) or that the application programs will be kept up to date as conditions change.

As stated earlier, business rules should be documented in the CASE repository. Ideally, these rules will then be checked automatically by database software. Removing business rules from application programs and incorporating them in the repository (in the form of domains, referential integrity constraints, and triggering operations) has several important advantages; specifically, incorporating business rules in the repository

1. provides for faster application development with fewer errors because these rules can be generated into programs or enforced by the database management system,

2. reduces maintenance effort and expenditures, 3. provides for faster response to business changes, 4. facilitates end-user involvement in developing new systems and manipulating

data, 5. provides for consistent application of integrity constraints, 6. reduces the time and effort required to train application programmers, and 7. promotes ease of use of a database.

For a more thorough treatment of business rules, see Hoffer et al. (2016).

Triggering operation (trigger) An assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete; also called a trigger.

M08_VALA1629_09_GE_C08.indd 289 08/04/2020 16:41

290 PART III ANALYSIS

ROLE OF PACKAGED CONCEPTUAL DATA MODELS: DATABASE PATTERNS Fortunately, the art and science of data modeling has progressed to the point where it is seldom necessary for an organization to develop its data models internally in their entirety. Instead, common database patterns for different business situations are available in packaged data models (or model components) that can be purchased at comparatively low cost and, after suitable customization, assembled into full-scale data models. These generic data models are developed by industry specialists, consultants, and database technology vendors based on their expertise and experience in dozens of organizations across multiple industry types. The models are typically provided as the contents of a data modeling software package, such as ERWin from Computer Associates. The software is able to produce E-R diagrams, maintain all metadata about the data model, and produce a variety of reports that help in the process of tailoring the data model to the specific situation, such as customizing data names, changing relationship characteristics, or adding data unique to your environment. The software can then generate the computer code to define the database to a database manage- ment system once the design is fully customized to the local situation. Some simple and limited generic data models can be found in books or on the Internet.

There are two principal types of packaged data models: universal data models, applicable to nearly any business or organization, and industry-specific data models. We discuss each of these types briefly and provide references for each type.

Universal Data Models

Numerous core subject areas are common to many (or even most) organizations, such as customers, products, accounts, documents, and projects. Although they dif- fer in detail, the underlying data structures are often quite similar for these subjects. Further, there are core business functions such as purchasing, accounting, receiv- ing, and project management that follow common patterns. Universal data models are templates for one or more of these subject areas and/or functions. All of the expected components of data models are generally included: entities, relationships, attributes, primary and foreign keys, and even sample data. Two examples of universal data model sets are provided by Hoberman (2009), Marco and Jennings (2004), and Silverston and Agnew (2008).

Industry-Specific Data Models

Industry-specific data models are generic data models that are designed to be used by organizations within specific industries. Data models are available for nearly every major industry group, including health care, telecommunications, discrete manufacturing, process manufacturing, banking, insurance, and higher education. These models are based on the premise that data model patterns for organizations are very similar within a particular industry (“a bank is a bank”). However, the data models for one industry (such as banking) are quite different from those for another (such as hospitals). Promi- nent examples of industry-specific data models are provided by Inmon (2005), Keller and Keller (2013), Kimball and Ross (2013), and Silverston and Agnew (2008).

Benefits of Database Patterns and Packaged Data Models

Most people in the data modeling field refer to a purchased universal or industry- specific database pattern as a logical data model (LDM). Technically, the term logical data model means a conceptual data model with some additional properties associated with the most popular type of database technology—relational databases. The type of data planning and analysis we have covered in this chapter can, in fact, be done

M08_VALA1629_09_GE_C08.indd 290 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 291

using either a conceptual or a logical data model. The process is the same; only the starting point is different.

LDMs are the database version of patterns, components, and prepackaged appli- cations that have been discussed in prior chapters as ways to more quickly and reliably build a new application. An advantage of LDMs is that a packaged data model now exists for almost every industry and application area, for specific operational systems to enterprise systems, such as Enterprise Resource Planning (ERP) and data warehouses. They are available from database software vendors, application software providers, and consulting firms. The use of a prepackaged data model does not eliminate the need for the methods and techniques we discuss in this chapter; they only change the context in which these methods and techniques are used.

It is now important that you consider purchasing a prepackaged data model even when an application is to be built from scratch. Consider the following benefits of starting with and then tailoring a purchased data model:

• Validated. Purchased models are proven through extensive experience. • Cost reduction. Projects with purchased models take less time and cost less

because the initial discovery steps are no longer necessary, leaving only iterative tailoring and refinement to the local situation.

• Anticipate future requirements, not just initial requirements. Purchased models antici- pate future needs, not just those recognized during the first version of an appli- cation. Thus, because the database structure does not require structural change (which can have costly ramifications for reprogramming the applications using the database), their benefits are recurring, not one-time.

• Facilitates systems analysis. The purchased model actually facilitates database plan- ning and analysis by providing a first data model, which you can use to generate specific analysis questions and concrete, not hypothetical or abstract, examples of what might be in the appropriate database.

• Consistent and complete. The purchased data models are very general, covering almost all options employed by the associated functional area or industry. Thus, they provide a structure that, when tailored, will be consistent and complete.

See Hoffer et al. (2016) for more details on the use of packaged data models in data modeling and database development. Of course, packaged data models are no substitute for sound database analysis and design. Skilled analysts and designers are still necessary to determine database requirements and to select, modify, install, and integrate any packaged systems that are used.

ELECTRONIC COMMERCE APPLICATION: CONCEPTUAL DATA MODELING Conceptual data modeling for an Internet-based electronic commerce application is no different than the process followed when analyzing the data needs for other types of applications. In the preceding chapters, you read how Jim Woo analyzed the flow of information within the WebStore and developed a DFD. In this section, we exam- ine the process he followed when developing the WebStore’s conceptual data model.

Conceptual Data Modeling for Pine Valley Furniture’s WebStore

To better understand what data would be needed within the WebStore, Jim Woo care- fully reviewed the information from the JAD session and his previously developed DFD. Table 8-2 shows a summary of the customer and inventory information identi- fied during the JAD session. Jim wasn’t sure if this information was complete, but he knew that it was a good starting place for identifying what information the WebStore needed to capture, store, and process. To identify additional information, he carefully studied the DFD shown in Figure 8-21. In this diagram, two data stores—Inventory and

PINE VALLEY FURNITURE

M08_VALA1629_09_GE_C08.indd 291 08/04/2020 16:41

292 PART III ANALYSIS

Home Office Customer Student Customer Inventory Information

Name Name SKU Doing Business as School Name (company’s name) Address Description Address Phone Finished Product Size Phone E-Mail Finished Product Weight Fax Available Materials E-Mail Available Colors

Price Lead Time

TABLE 8-2 Customer and Inventory Information for the WebStore

FIGURE 8-21 Level-0 DFD for the WebStore

PURCHASING FULFILLMENT

SYSTEMCUSTOMER TRACKING

SYSTEM

D1 Inventory D2 Shopping Cart

CUSTOMER

Cart ID/ Item Profile

Item Profile Purchase

Request Product

Item

Product Item

Request

InvoiceCheck Out/ Customer

Item Profile

Cart ID/ Item Profile

Order Number/ Return Code

Order Number

Order Status

Information

Order Status

Information

Product Item to Remove

Item to Remove

Items in Cart

Item Profile

Cart Request

Customer ID

Customer Information

Customer Information/ID

Customer Information

Order

6.0

5.0

2.0

3.01.0

4.0

Add/Modify Account Profile

Browse Catalog

Check Out Process Order

Order Status

Request

Display Shopping

Cart

Select Item for

Purchase

M08_VALA1629_09_GE_C08.indd 292 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 293

Shopping Cart—are clearly identified; both were strong candidates to become entities within the conceptual data model. Finally, Jim examined the data flows from the DFD as additional possible sources for entities. This analysis resulted in the identification of five general categories of information that he needed to consider:

• Customer • Inventory • Order • Shopping Cart • Temporary User/System Messages

After identifying these multiple categories of data, Jim’s next step was to care- fully define each item. To do this, he again examined all data flows within the DFD and recorded the source and destination of all data flows. By carefully listing these flows, he could more easily move through the DFD and more thoroughly understand what information was needed to move from point to point. This activity resulted in the creation of two tables that documented his growing understanding of the Web- Store’s requirements. The first, Table 8-3, lists each of the data flows within each data category and its corresponding description. The second, Table 8-4, lists each of the unique data flows within each data category. He now felt ready to construct an E-R diagram for the WebStore.

Jim concluded that Customer, Inventory, and Order were each a unique entity and would be part of his E-R diagram. Recall that an entity is a person, place, or object; all three of these items meet this criteria. Because the Temporary User/System

Data Category/Data Flow Description

Customer-Related Customer ID Unique identifier for each customer (generated by Cus-

tomer Tracking System) Customer Information Detailed customer information (stored in Customer

Tracking System) Inventory-Related Product Item Unique identifier for each product item (stored in

Inventory Database) Item Profile Detailed product information (stored in Inventory

Database) Order-Related Order Number Unique identifier for an order (generated by Purchasing

Fulfillment System) Order Detailed order information (stored in Purchasing Fulfill-

ment System) Return Code Unique code for processing customer returns (gener-

ated by/stored in Purchasing Fulfillment System) Invoice Detailed order summary statement (generated from

order information stored in Purchasing Fulfillment System)

Order Status Information Detailed summary information on order status (stored/ generated by)

Shopping Cart Cart ID Unique identifier for shopping cart Temporary User/System Messages Product Item Request Request to view information on a catalog item Purchase Request Request to move an item into the shopping cart View Cart Request to view the contents of the shopping cart Items in Cart Summary report of all shopping cart items Remove Item Request to remove item from shopping cart Check Out Request to check out and process order

TABLE 8-3 Data Category, Data Flow, and Data Flow Descriptions for the WebStore

M08_VALA1629_09_GE_C08.indd 293 08/04/2020 16:41

294 PART III ANALYSIS

Messages data were not permanently stored items—nor were they a person, place, or object—he concluded that this should not be an entity in the conceptual data model. Alternatively, although the shopping cart was also a temporarily stored item, its con- tents needed to be stored for at least the duration of a customer’s visit to the WebStore and should be considered an object. As shown in Figure 8-21, Process 4.0, Check Out Process Order, moves the Shopping Cart contents to the Purchasing Fulfillment System, where the order details are stored. Thus, he concluded that Shopping Cart— along with Customer, Inventory, and Order—would be entities in his E-R diagram.

The final step was to identify the interrelationships among these four enti- ties. After carefully studying all the related information, Jim came to the following conclusions:

1. Each Customer owns zero or one Shopping Cart instances; each Shopping Cart instance is owned by one and only one Customer.

2. Each Shopping Cart instance contains one and only one Inventory item; each Inventory item is contained in zero or many Shopping Cart instances.

Data Flow From/To

Customer-Related Customer ID From Customer to Process 4.0

From Process 4.0 to Customer Tracking System From Process 5.0 to Customer

Customer Information From Customer to Process 5.0 From Process 5.0 to Customer From Process 5.0 to Customer Tracking System From Customer Tracking System to Process 4.0

Inventory-Related Product Item From Process 1.0 to Data Store D1

From Process 3.0 to Data Store D2 Item Profile From Data Store D1 to Process 1.0

From Process 1.0 to Customer From Process 1.0 to Process 2.0 From Process 2.0 to Data Store D2 From Data Store D2 to Process 3.0 From Data Store D2 to Process 4.0

Order-Related Order Number From Purchasing Fulfillment System to Process 4.0

From Customer to Process 6.0 From Process 6.0 to Purchasing Fulfillment System

Order From Process 4.0 to Purchasing Fulfillment System Return Code From Purchasing Fulfillment System to Process 4.0 Invoice From Process 4.0 to Customer Order Status From Process 6.0 to Customer

From Purchasing Fulfillment System to Process 6.0 Shopping Cart Cart ID From Data Store D2 to Process 3.0

From Data Store D2 to Process 4.0 Temporary User/System Messages Product Item Request From Customer to Process 1.0 Purchase Request From Customer to Process 2.0 View Cart From Customer to Process 3.0 Items in Cart From Process 3.0 to Customer Remove Item From Customer to Process 3.0

From Process 3.0 to Data Store D2 Check Out From Customer to Process 4.0

TABLE 8-4 Data Category, Data Flow, and the Source/Destination of Data Flows within the WebStore DFD

M08_VALA1629_09_GE_C08.indd 294 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 295

3. Each Customer places zero to many Orders; each Order is placed by one and only one Customer.

4. Each Order contains one to many Shopping Cart instances; each Shopping Cart instance is contained in one and only one Order.

With these relationships defined, Jim drew the E-R diagram shown in Figure 8-22. He now had a very good understanding of the requirements, the flow of information within the WebStore, the flow of information between the WebStore and existing PVF systems, and now the conceptual data model. Over the next few hours, Jim planned to further refine his understanding by listing the specific attributes for each entity and then comparing these lists with the existing inventory, customer, and order database tables. Making sure that all attributes were accounted for would be the final conceptual data modeling activity before beginning the process of selecting a final design strategy.

FIGURE 8-22 E-R diagram for the WebStore systemORDER

SHOPPING CART

INVENTORYCUSTOMER

Is_placed_by

Places

Contains

Is_contained_in

Contains Is_contained_in

Is_owned_by

Owns

SUMMARY We have presented the process and basic notation used to model the data requirements of an information system. We outlined the structuring of conceptual data models using the E-R notation and discussed how the components of a conceptual data model relate to data flows and data stores.

Conceptual data modeling is based on certain con- structs about the structure, not use, of data. These con- structs include entity, relationship, degree, and cardinality. A data model shows the relatively permanent business rules that define the nature of an organization. Rules define characteristics of data such as the legitimate domain of values for data attributes, the unique characteristics (iden- tifier) of entities, the relationships between different enti- ties, and the triggering operations that protect the validity of attributes during data maintenance.

A data model shows major categories of data, called entities for the E-R notation; the associations or relation- ships between entities; and the attributes of both entities and relationships. A special type of entity called an associa- tive entity is often necessary to represent a many-to-many relationship between entities. Entity types are distinct from

entity instances. Each entity instance is distinguished from other instances of the same type by an identifier attribute.

Relationships are the glue that holds a data model together. Three common relationship types are unary, binary, and ternary. The minimum and maximum number of entity instances that participate in a relationship repre- sent important rules about the nature of the organization, as captured during requirements determination. Super- type/subtype relationships can be used to show a hierarchy of more-general to more-specific related entity types that share common attributes and relationships. Rules for total and partial specialization between the supertype and sub- types and disjoint and overlap among the subtypes clarify the meaning of the related entity types.

Modern systems analysis is based on reuse, and one form of reuse is prepackaged conceptual data models. These data models can be purchased from various vendors and are very helpful in learning best practices from other organizations in the same industry or for the same busi- ness function. They save considerable time over building complex data models from scratch.

KEY TERMS

8.1 Associative entity 8.2 Attribute 8.3 Binary relationship 8.4 Business rules

8.5 Candidate key 8.6 Cardinality 8.7 Composite attribute 8.8 Conceptual data model

8.9 Degree 8.10 Derived attribute 8.11 Disjoint rule 8.12 Domain

M08_VALA1629_09_GE_C08.indd 295 08/04/2020 16:41

296 PART III ANALYSIS

REVIEW QUESTIONS 8.31 Discuss why some systems developers believe that a data

model is one of the most important parts of the statement of information system requirements.

8.32 Distinguish between the data modeling done during infor- mation systems planning, project initiation and planning, and the analysis phases of the SDLC.

8.33 Discuss why data modeling is necessary during the systems development process.

8.34 Explain why a ternary relationship is not the same as three binary relationships.

8.35 How is a data model employed when structuring system data requirements?

8.36 Describe the relationship between business rules and data models.

8.37 Why do systems analysts need to collect system data for con- ceptual data modeling?

8.38 What are the linkages among DFDs, decision tables, and E-R diagrams?

8.39 How are relationships classified? Give an example of each.

8.13 Entity instance 8.14 Entity-relationship data model

(E-R model) 8.15 Entity-relationship diagram

(E-R diagram) 8.16 Entity type 8.17 Identifier

8.18 Multivalued attribute 8.19 Optional attribute 8.20 Overlap rule 8.21 Partial specialization rule 8.22 Relationship 8.23 Repeating group 8.24 Required attribute

8.25 Subtype 8.26 Supertype 8.27 Ternary relationship 8.28 Total specialization rule 8.29 Triggering operation

(trigger) 8.30 Unary relationship

Match each of the key terms above with the definition that best fits it.

____A detailed model that captures the overall structure of orga- nizational data and is independent of any database manage- ment system or other implementation considerations.

____A detailed, logical representation of the entities, associations, and data elements for an organization or business area.

____A graphical representation of an E-R model.

____A collection of entities that share common properties or characteristics.

____A single occurrence of an entity type.

____A named property or characteristic of an entity that is of interest to the organization.

____An attribute (or combination of attributes) that uniquely identifies each instance of an entity type.

____A candidate key that has been selected as the unique, identi- fying characteristic for an entity type.

____An attribute that may take on more than one value for each entity instance.

____A set of two or more multivalued attributes that are logically related.

____An association between the instances of one or more entity types that is of interest to the organization.

____The number of entity types that participate in a relationship.

____A relationship between the instances of one entity type.

____A relationship between instances of two entity types.

____A simultaneous relationship among instances of three entity types.

____The number of instances of entity B that can (or must) be associated with each instance of entity A.

____An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances.

____A subgrouping of the entities in an entity type that is mean- ingful to the organization.

____A generic entity type that has a relationship with one or more subtypes.

____Specifies that each entity instance of the supertype must be a member of some subtype in the relationship.

____Specifies that an entity instance of the supertype does not have to belong to any subtype.

____Specifies that if an entity instance of the supertype is a mem- ber of one subtype, it cannot simultaneously be a member of any other subtype.

____Specifies that an entity instance can simultaneously be a member of two (or more) subtypes.

____Specifications that preserve the integrity of the logical data model.

____The set of all data types and values that an attribute can assume.

____An assertion or rule that governs the validity of data manipu- lation operations such as insert, update, and delete.

____An attribute that must have a value for every entity instance.

____An attribute that may not have a value for every entity instance.

____An attribute that has meaningful component parts.

____An attribute whose value can be computed from related attri- bute values.

M08_VALA1629_09_GE_C08.indd 296 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 297

FIGURE 8-23 E-R diagram for Problem and Exercise 8.53

CITYTOOL

Includes

Works_on

Done_atUsed_on TASK Task_ID Time {Skill}

PROJECT Project_ID

EMPLOYEE Employee_ID

8.40 What are the three most common degrees of relationships? How do entity types participate in the relationship?

8.41 List the deliverables from the conceptual data modeling part of the analysis phase of the systems development process.

8.42 Identify and explain the cardinality of relationships between two entity types, Employee and Project. Is it possible to fix a maximum cardinality?

8.43 When is an associative entity created? Why are there no rela- tionship names on the lines between an associative entity and a strong entity?

8.44 What is the role of an entity-relationship diagram in data modeling?

8.45 Contrast the following terms:

a. Subtype; supertype b. Total specialization rule; partial specialization rule c. Disjoint rule; overlap rule d. Attribute; operation

PROBLEMS AND EXERCISES 8.46 Assume that at PVF each product (described by Product

No., Description, and Cost) is composed of at least three components (described by Component No., Description, and Unit of Measure), and components are used to make one or many products (i.e., must be used in at least one product). In addition, assume that components are used to make other components and that raw materials are also considered to be components. In both cases of components being used to make products and components being used to make other components, we need to keep track of how many components go into making something else. Draw an E-R diagram for this situation and place minimum and maximum cardinalities on the diagram.

8.47 State whether there is a one-to-one, one-to-many, or many-to-many relationship for the following pairs of related entities. Use the notation introduced in the text to draw a diagram for each of the relationships.

a. Employee and Project b. Student and Course c. Course and Section d. Customer and Order e. Patient and Bed

8.48 If you were going to develop a computer-based tool to help an analyst interview users and quickly and easily create and edit E-R diagrams, what type of tool would you build? What features would it have? How would it work?

8.49 A software training program is divided into training mod- ules, and each module is described by module name and the approximate practice time. Each module sometimes has

prerequisite modules. Model this situation of training pro- grams and modules with an E-R diagram.

8.50 Each semester, each student must be assigned an adviser who counsels students about degree requirements and helps stu- dents register for classes. Students must register for classes with the help of an adviser, but if their assigned adviser is not available, they may register with any adviser. We must keep track of students, their assigned adviser, and with whom the student registered for the current term. Represent this situ- ation of students and advisers with an E-R diagram.

8.51 Assume that entity PART has attributes Part_Number, Drawing_Number, Weight, Description, Storage_Location, and Cost. Which attributes are candidate keys? Why? Which attribute would you select for the identifier of PART? Why? Or do you think that you should create another attribute to be the identifier? Why or why not?

8.52 Consider the E-R diagram in Figure 8.15b.

a. What would be the identifier for the CERTIFICATE associative entity if Certificate_Number were not included?

b. Now assume that the same employee may take the same course multiple times on different dates. Does this change your answer to Problem and Exercise 8.52a? Why or why not?

8.53 Study the E-R diagram in Figure 8-23. Based on this E-R diagram, answer the following questions:

a. How many PROJECTs can an employee work on? b. What is the degree of the Includes relationship?

M08_VALA1629_09_GE_C08.indd 297 08/04/2020 16:41

298 PART III ANALYSIS

FIGURE 8-24 E-R diagram for Problem and Exercises 8.54 and 8.55

CUSTOMER

ORDER BACKORDER

Places

Includes

Generates

Comprised_of Supplied_byPRODUCT COMPONENT VENDOR

FIGURE 8-25 E-R diagram for Problem and Exercise 8.60

May_contain

Goes_on

Holds Transports

Is_responsible_for AGENT Agent_ID

VESSEL Vessel_ID Country_of_ Registry

CONSIGNMENT Consignment_Number $_Value

VOYAGE Voyage_ID Tonnage

c. Are there any associative entities on this diagram? If so, name them.

d. How else could the attribute Skill be modeled? e. Is it possible to attach any attributes to the Includes

relationship? f. Could TASK be modeled as an associative entity? g. Employees’ earnings are calculated based on a different

hourly pay rate for each project. Where on the E-R diagram would you represent the new attribute Hourly pay rate?

8.54 For the E-R diagram provided in Figure 8-24, draw in the relationship cardinalities and describe them. Describe any assumptions you must make about relevant business rules. Are there any changes or additions you would make to this diagram to make it better? Why or why not?

8.55 For the E-R diagram provided in Figure 8-24, assume that this company decided to assign each sales representative to a small, unique set of customers; some customers can now become “members” and receive unique benefits; small man- ufacturing teams will be formed and each will be assigned to the production of a small, unique set of products; and each

purchasing agent will be assigned to a small, unique set of vendors. Make the necessary changes to the E-R diagram and draw and describe the new relationship cardinalities.

8.56 Why are data flow diagrams important for the development of conceptual data modeling?

8.57 Using Table 8.1 as a guide, develop the complete script (questions and possible answers) of an interview between analysts and users within the order entry function at PVF.

8.58 A concert ticket reservation is an association among a patron, a concert, and a seat. Select a few pertinent attri- butes for each of these entity types and represent a reserva- tion in an E-R diagram.

8.59 Choose from your own experiences with organizations and draw an E-R diagram for a situation that has a ternary relationship.

8.60 Consider the E-R diagram in Figure 8-25. Are all three rela- tionships—Holds, Goes_on, and Transports— necessary (i.e., can one of these be deduced from the other two)? Are there reasonable assumptions that make all three relation- ships necessary? If so, what are these assumptions?

M08_VALA1629_09_GE_C08.indd 298 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 299

8.61 Draw an E-R diagram to represent the sample customer order in Figure 8-4.

8.62 In a real estate database, there is an entity called PROP- ERTY, which is a property for sale by the agency. Each time a potential property buyer makes a purchase offer on a prop- erty, the agency records the date, offering price, and name of the person making the offer.

a. Represent the PROPERTY entity and its purchase offer attributes using the notation for multivalued attributes.

b. Represent the PROPERTY entity and its purchase offer attributes using two entity types.

c. Assume the agency decides to also keep data about buy- ers and potential buyers, including their name, phone number, and address. Buyers often have multiple phone numbers and addresses, which are not necessarily related to each other. Augment your answer to Problem and Exercise 8.62b to accommodate this new entity type.

d. Finally, assume that, for each purchase offer, we need to know which buyer phone number and address to associ- ate with that offer. Augment your answer to Problem and Exercise 8.62c to accommodate this new requirement.

8.63 Consider the Is_married_to unary relationship in Figure 8-14c.

a. Assume that we want to know the date on which a mar- riage occurred. Augment this E-R diagram to include a Date_married attribute.

b. Because persons sometimes remarry after the death of a spouse or a divorce, redraw this E-R diagram to show the whole history of marriages (not just the current mar- riage) for persons. Show the Date_married attribute on this diagram.

c. In your answer to Problem and Exercise 8.63b, is it possible to represent a situation in which the same two people marry each other a multiple number of times? Explain.

8.64 Consider Figure 8.20.

a. Write a domain integrity rule for Balance. b. Write a triggering operation for the Balance attribute for

the event of inserting a new ACCOUNT. 8.65 Suppose a technology supplier deals in two types of IT prod-

ucts: monitors and hard disks. The detailed attributes of these products are (1) Monitor(Product_ID, Name, and Resolution) and (2) Hard disk(Product_ID, Name, Speed, and Storage Size).

a. Through generalization, construct an EER model for this situation using supertype and subtype notation. Inclu- sion of a subtype discriminator is necessary.

b. Is the total specialization rule or the partial specialization rule applicable to this situation? Why?

8.66 In the Purchasing department at one company, a purchase request may be assigned an expediter within the Purchas- ing department. This expediter follows the purchase request through the entire purchasing process and acts as the sole contact person with the person or unit within the company buying the goods or services. The Purchasing department refers to its fellow employees buying goods and services as cus- tomers. The purchasing process is such that purchase requests from certain special customers must go out for bid to vendors, and the associated Request for Bids for these requests must be approved by the Purchasing department. If the purchase is not by a special customer, the product or service can sim- ply be bought from any approved vendor, but the purchase request must still be approved by the Purchasing department, and the department must issue a Purchase Order. For “special customer” purchases, the Purchasing department can issue a Purchase Order once the winning bid is accepted. List the rel- evant entities and attributes, and draw an E-R diagram, for this business process. List whatever assumptions you must make to define identifiers, assess cardinality, and so on.

FIELD EXERCISES 8.67 Interview a friend or family member about each of the enti-

ties, attributes, relationships, and relevant business rules he or she comes into contact with at work. Use this informa- tion to construct and present to this person an E-R diagram. Revise the diagram until it seems appropriate to you and to your friend or family member.

8.68 Visit an organization that provides primarily a service, such as a dry cleaner, and a company that manufactures a more tangible product. Interview employees from these organiza- tions about the entities, attributes, relationships, and rele- vant business rules that are commonly encountered by their company. Use this information to construct E-R diagrams. What differences and similarities are there between the dia- grams for the service and the product-oriented companies? Does the E-R diagramming technique handle both situations equally well? Why or why not? What differences, if any, might there be in the use of this technique for a public agency?

8.69 Discuss with a systems analyst the role of conceptual data modeling in the overall systems analysis and design of information systems at their company. How, and by whom, is conceptual data modeling performed? What training in this technique is given? At what point(s) is this done in the development process? Why?

8.70 Ask a systems analyst to give you examples of unary, binary, and ternary relationships that they have heard of or dealt with personally at their company. Ask them which is the most common. Why?

8.71 Interview a database designer and ask them to give you an example of an E-R diagram showing multiple relationships between entities. Which type of E-R diagram is easier to construct when compared to a simple E-R diagram indicat- ing simple relationships? Can a unary relationship be intro- duced into the E-R diagram showing multiple relationships? Is it possible to develop an associative entity between two other entities in the same diagram?

8.72 Ask a database designer or database administrator working in a bank to give you three examples of customer account types. Ask them to help you come up with the attributes of these types of customers. Ask them to use generation rules to develop an EER model to represent this situation using traditional EER notation.

8.73 Ask a systems analyst in a manufacturing company to show you an E-R diagram for a database in that organization that contains bill-of-materials data. Compare that E-R diagram to the one in Figure 8-7. What are the differences between these diagrams?

M08_VALA1629_09_GE_C08.indd 299 08/04/2020 16:41

300 PART III ANALYSIS

REFERENCES

Bruce, T. A. (1992). Designing quality databases with IDEF1X infor- mation models. New York: Dorset House Publications.

Gottesdiener, E. (1999). Turning rules into requirements. Applica- tion Development Trends, 6(7), 37–50.

Herbst, H. (2013). Business rule-oriented conceptual modeling. Hei- delberg, Germany: Physica-Verlag.

Hills, T. (2016). NoSQL and SQL data modeling: Bringing together data, semantics, and software. Basking Ridge, NJ: Technics Publications.

Hoberman, S. (2009). Industry logical data models serve as maps to an organization’s information. Retrieved April 9, 2018 from http://www.teradata.com/Resources/White-Papers/ Leveraging-the-Industry-Logical-Data-Model-as.

Hoberman, S., Burbank, D., & Bradley, C. (2012). Data modeling for the business. Bradley Beach, NJ: Technics Publications.

Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern database man- agement (12th ed.). Upper Saddle River, NJ: Prentice Hall.

Inmon, W. H. (2005). Building the data warehouse. Indianapolis, IN: Wiley.

Keller, S. B, and Keller, B. C. (2013). The definitive guide to ware- housing. Upper Saddle River, NJ: Pearson.

Kimball, R., & Ross, M. (2013). The data warehouse toolkit: The com- plete guide to dimensional data modeling (3rd ed.). New York: John Wiley & Sons, Inc.

Kroenke, D.M., Auer, D.J., Vandenberg, S.L., & Yoder, R.C. (2017). Database concepts (8th ed.). New York: Pearson.

Marco, D., & Jennings, M. (2004). Universal meta data models. New York: John Wiley & Sons, Inc.

Silverston, L., & Agnew, P. (2008). The data model resource book, vol. 3: Universal patterns for data modeling. New York: John Wiley & Sons, Inc.

Witt, G. (2012). Writing effective business rules. Burlington, MA: Morgan Kaufmann.

M08_VALA1629_09_GE_C08.indd 300 08/04/2020 16:41

http://www.teradata.com/Resources/White-Papers/Leveraging-the-Industry-Logical-Data-Model-as

301

Learning Objectives After studying this section, you should be able to

8.1 demonstrate the differences between object diagrams and class diagrams;

8.2 explain the three types of operations possible in class diagrams;

8.3 illustrate how associations are represented in class diagrams;

In this section, we show how to develop class diagrams, the object-oriented data modeling notation. We describe the main concepts and techniques involved in object modeling, including objects and classes, encapsulation of attributes and operations, aggregation relationships, polymorphism, and inheritance. We show how you can develop class diagrams, using the UML notation, to pro- vide a conceptual view of the system being modeled. For a more thorough coverage of object modeling, see George, Batra, Valacich, & Hoffer. (2007), Daoust (2012), Seidl, Scholz, Huemer, & Kappel, (2015), or Unhelkar (2017).

REPRESENTING OBJECTS AND CLASSES With the object-oriented approach, we model the world in objects. Before applying this approach to a real-world prob- lem, we need to understand what an object really is. Similar to an entity instance, an object has a well-defined role in the application domain, and it has state (data), behavior, and identity characteristics. An object is a single occurrence of a class, which we define below.

An object has a state and exhibits behavior through operations that can examine or affect its state. The state of an object encompasses its properties (attributes and rela- tionships) and the values of those properties. Its behavior represents how an object acts and reacts (Booch, Maksim- chuk, Engle, Young, & Conallen, 2007; Unhelkar, 2017).

An object’s state is determined by its attribute values and links to other objects. An object’s behavior depends on its state and the operation being performed. An operation is simply an action that one object performs upon another in order to get a response. You can think of an operation as a service provided by an object (supplier) to its clients. A client sends a message to a supplier, which delivers the desired service by executing the corresponding operation.

Consider the example of a student, Mary Jones, repre- sented as an object. The state of this object is characterized by its attributes (name, date of birth, year, address, and phone number) and the values these attributes currently have; for example, name is “Mary Jones,” year is “junior,” and so on. Its behavior is expressed through operations such as calc-gpa, which is used to calculate a student’s cur- rent grade point average. The Mary Jones object, therefore, packages both its state and its behavior together.

All objects have an identity; that is, no two objects are the same. For example, if there are two Student instances with the same name and date of birth (or even all attri- butes), they are essentially two different objects. An object maintains its own identity over its life. For example, if Mary Jones gets married and changes her name, address, and phone, she will still be represented by the same object. This concept of an inherent identity is different from the identi- fier concept we saw earlier for E-R modeling.

We use the term object class (or simply class) to refer to a logical grouping of objects that have the same (or similar)

8.4 show how associative classes are drawn in class diagrams; and

8.5 show how generalization and aggregation are represented in class diagrams.

Introduction

Object-Oriented analysis and Design

Appendix

Object modeling—class Diagrams

M08_VALA1629_09_GE_C08.indd 301 08/04/2020 16:41

302 PART III ANALYSIS

attributes, relationships, and behaviors (methods) (just as we used entity type and entity instance earlier in this chapter). In our example, therefore, Mary Jones is an object instance, whereas Student is an object class (as Student was an entity type in E-R diagramming).

Classes can be depicted graphically in a class diagram, as shown in Figure 8-26. A class diagram shows the static structure of an object-oriented model: the object classes, their internal structure, and the relationships in which they participate. In UML, a class is represented by a rectangle with three compartments separated by horizontal lines. The class name appears in the top compartment, the list of attributes in the middle compartment, and the list of operations in the bottom compartment of the rectangle. The diagram in Figure 8-26 shows two classes, Student and Course, along with their attributes and operations.

The Student class is a group of Student objects that share a common structure and a common behavior. Each object knows to which class it belongs; for example, the Mary Jones object knows that it belongs to the Student class. Objects belonging to the same class may also participate in similar relationships with other objects; for example, all students register for courses and, therefore, the Student class can participate in a relationship called “registers-for” with another class called Course (see the section Representing Associations).

An operation, such as calc-gpa in Student (see Figure 8-26), is a function or a service that is provided by all the instances of a class to invoke behavior in an object by passing a message. It is only through such operations that other objects can access or manipulate the information stored in an object. The operations, therefore, provide an external interface to a class; the interface presents the outside view of the class without showing its internal structure or how its operations are implemented. This technique of hiding the internal implementation details of an object from its external view is known as encapsulation, or information hiding (Booch et al., 2007; Seidl et al., 2015; Unhelkar, 2017). So while we provide the abstraction of the behavior common to all instances of a class in its interface, we encapsulate within the class its structure and the secrets of the desired behavior.

TYPES OF OPERATIONS Operations can be classified into three types, depending on the kind of service requested by clients: (1) constructor, (2) query, and (3) update (Bell, 2004; Seidl et al., 2015; Unhelkar, 2017). A constructor operation creates a new instance of a class. For example, you can have an operation called create-student within Student that creates a new student and initializes its state. Such constructor operations are available to all classes and, therefore, are not explicitly shown in the class diagram.

A query operation is an operation that does not have any side effects; it accesses the state of an object but does not alter the state (Unhelkar, 2017). For example, the Student class can have an operation called get-year (not shown) that simply retrieves the year (freshman, sophomore, junior, or senior) of the Student object specified in the query. Note that there is no need to show explicitly a query

Object An entity that has a well-defined role in the application domain, and it has state, behavior, and identity characteristics.

Behavior Represents how an object acts and reacts.

State Encompasses an object’s properties (attributes and relationships) and the values of those properties.

Object class A logical grouping of objects that have the same (or similar) attributes, relationships, and behaviors; also called class.

Class diagram Shows the static structure of an object- oriented model: the object classes, their internal structure, and the relationships in which they participate.

Operation A function or a service that is provided by all the instances of a class.

Encapsulation The technique of hiding the internal implementation details of an object from its external view.

Constructor operation An operation that creates a new instance of a class.

Query operation An operation that accesses the state of an object but does not alter the state.

FIGURE 8-26 UML class diagram showing two classes

name dateOfBirth year address phone

calc-age ( ) calc-gpa ( ) register-for (course)

Student

crse-code crse-title credit-hrs

enrollment ( )

CourseClass name

List of attributes

List of operations

M08_VALA1629_09_GE_C08.indd 302 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 303

such as get-year in the class diagram because it retrieves the value of an indepen- dent base attribute. Consider, however, the calc-age operation within Student. This is also a query operation because it does not have any side effects. Note that the only argument for this query is the target Student object. Such a query can be rep- resented as a derived attribute (Seidl et al., 2015; Unhelkar, 2017); for example, we can represent “age” as a derived attribute of Student. Because the target object is always an implicit argument of an operation, there is no need to show it explicitly in the operation declaration.

An update operation has side effects; it alters the state of an object. For example, consider an operation of Student called promote-student (not shown). The opera- tion promotes a student to a new year, say, from junior to senior, thereby changing the Student object’s state (value of the year attribute). Another example of an update operation is register-for (course), which, when invoked, has the effect of establishing a connection from a Student object to a specific Course object. Note that, in addi- tion to having the target Student object as an implicit argument, the operation has an explicit argument called “course” that specifies the course for which the student wants to register. Explicit arguments are shown within parentheses.

A class-scope operation is an operation that applies to a class rather than an object instance. For example, avg-gpa for the Student class (not shown with the other operations for this class in Figure 8-26) calculates the average GPA across all students (the operation name is underlined to indicate that it is a scope operation).

REPRESENTING ASSOCIATIONS Parallel to the definition of a relationship for the E-R model, an association is a rela- tionship among instances of object classes. As in the E-R model, the degree of an association relationship may be one (unary), two (binary), three (ternary), or higher (n-ary). In Figure 8-27, we illustrate how the object-oriented model can be used to represent association relationships of different degrees. An association is shown as a solid line between the participating classes. The name given to the end of an associa- tion where it connects to a class is called an association role (Bell, 2004). Each associa- tion has two or more roles. A role may be explicitly named with a label near the end of an association (see the “manager” role in Figure 8-27). The role name indicates the role played by the class attached to the end near which the name appears. Use of role names is optional. You can specify role names in place of or in addition to an association name. You may show the direction of an association explicitly by using a solid triangle next to the association name.

Figure 8-27 shows two unary relationships, Is-married-to and Manages. At one end of the Manages relationship, we have named the role as “manager,” implying that an employee can play the role of a manager. We have not named the other roles, but we have named the associations. When the role name does not appear, you may think of the role name as being that of the class attached to that end (Unhelkar, 2017). For example, you may call the role for the right end of the Is-assigned relationship in Figure 8-27 “Parking Place.”

Each role has a multiplicity, which indicates how many objects participate in a given association relationship. For example, a multiplicity of 2..5 denotes that a minimum of two and a maximum of five objects can participate in a given relation- ship. Multiplicities, therefore, are nothing but cardinality constraints, which you saw in E-R diagrams. In addition to integer values, the upper bound of a multiplicity can be an * (asterisk), which denotes an infinite upper bound. If a single integer value is specified, it means that the range includes only that value.

The multiplicities for both roles in the Is-married-to relationship in Figure 8-27 are 0..1, indicating that a person may be single or married to one person. The multi- plicity for the manager role in the Manages relationship is 0..1 and that for the other role is 0..*, implying that an employee may be managed by only one manager, but a manager may manage zero to many employees.

Update operation An operation that alters the state of an object.

Class-scope operation An operation that applies to a class rather than an object instance.

Association A named relationship between or among object classes.

Association role The end of an association where it connects to a class.

Multiplicity A specification that indicates how many objects participate in a given relationship.

M08_VALA1629_09_GE_C08.indd 303 08/04/2020 16:41

304 PART III ANALYSIS

In Figure 8-27, we show a ternary relationship called Supplies among Vendor, Part, and Warehouse. As is preferred in an E-R diagram, we represent a ternary rela- tionship using a class and place the name of the relationship there.

The class diagram in Figure 8-28 shows several binary associations. The diagram shows that a student may have an adviser, while a faculty member may advise up to a maximum of 10 students. Also, while a course may have multiple offerings, a given course offering is scheduled for exactly one course. UML allows you to specify numeri- cally any multiplicity. For example, the diagram shows that a course offering may be taught by one or two instructors (1, 2). You can specify a single number (e.g., 2 for the members of a bridge team), a range (e.g., 11–14 for the players of a soccer team who participated in a particular game), or a discrete set of numbers and ranges (e.g., 3, 5, 7 for the number of committee members and 20–32, 35–40 for the workload in hours per week of a company’s employees).

Figure 8-28 also shows that a faculty member plays the role of an instructor, as well as that of an adviser. While the adviser role identifies the Faculty object associated with

FIGURE 8-27 Examples of association relationships of different degrees

Is-married-to

Is-assigned

0..1

0..1 0..1

Person

One-to-one

One-to-many

Many-to-many

Manages

0..1 manager

Employee

Contains1

Registers-for*

Employee

Product Line

Student

Parking Place

Product

Course

PART

WAREHOUSE

*1 1* SUPPLIESVENDOR

1..*

FIGURE 8-28 Example of binary associations

Registers-for

Teaches

Scheduled-for

0..10

0..1

advisees

adviser

instructor 1,2

Faculty

* 1

Student Course O�ering Course

** *

M08_VALA1629_09_GE_C08.indd 304 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 305

a Student object, the advisee’s role identifies the set of Student objects associated with a Faculty object. We could have named the association Advises; in this case, however, the role names are sufficiently meaningful to convey the semantics of the relationship.

REPRESENTING ASSOCIATIVE CLASSES When an association itself has attributes or operations of its own or when it par- ticipates in relationships with other classes, it is useful to model the association as an associative class ( just as we used an associative entity in E-R diagramming). For example, in Figure 8-29, the attributes term and grade really belong to the many-to- many association between Student and Course. The grade of a student for a course cannot be determined unless both the student and the course are known. Similarly, to find the term(s) in which the student took the course, both student and course must be known. The check Eligibility operation, which determines if a student is eli- gible to register for a given course, also belongs to the association, rather than to any of the two participating classes. We have also captured the fact that, for some course registrations, a computer account is issued to a student. For these reasons, we model Registration as an association class, with its own set of features and an association with another class (Computer Account). Similarly, for the unary Tutors association, begin- Date and numberOfHrs (number of hours tutored) really belong to the association, and therefore they appear in a separate association class.

You have the option of showing the name of an association class on the associa- tion path, on the class symbol, or on both. When an association has only attributes but does not have any operations or does not participate in other associations, the recommended option is to show the name on the association path, but omit it from the association class symbol, to emphasize its “association nature” (Bell, 2004). That is how we have shown the Tutors association. On the other hand, we have displayed the name of the Registration association—which has two attributes and one operation of its own, as well as an association called Issues with Computer Account—within the class rectangle to emphasize its “class nature.”

Figure 8-30 shows a ternary relationship among the Student, Software, and Course classes. It captures the fact that students use various software tools for dif- ferent courses. For example, we could store the information that Mary Jones used Microsoft Access and Oracle for the Database Management course, Rational Rose and Visual C++ for the Object-Oriented Modeling course, and Jess for the Expert Systems Course. Now suppose we want to estimate the number of hours per week Mary will spend using Oracle for the Database Management course. This process really belongs to the ternary association, and not to any of the individual classes. Hence, we have created an associative class called Log, within which we have declared an operation called estimate Usage. In addition to this operation, we have specified three attributes that belong to the association: beginDate, expiryDate, and hoursLogged. Alternatively,

Associative class An association that has attributes or operations of its own or that participates in relationships with other classes.

FIGURE 8-29 Class diagram showing associative classes

beginDate numberOfHrs

acctID password serverSpace

Computer Account

Student

pupil

tutor

Tutors

Issues

Course

* 0..1 term grade

checkEligibility ( )

Registration

* *

M08_VALA1629_09_GE_C08.indd 305 08/04/2020 16:41

306 PART III ANALYSIS

the associative class Log can be placed at the intersection of the association lines, as shown in Figure 8-16; in this case, multiplicities are required on all the lines next to the Log class.

REPRESENTING STEREOTYPES FOR ATTRIBUTES In E-R diagrams, we designated attributes as being primary keys, and we designated them as multivalued, derived, and other types. This can also be done in a class diagram by placing a stereotype next to the attribute. Stereotypes simply extend the common UML vocabulary. For instance, in Figure 8-31, age is a derived attribute of Student because it can be calculated from the date of birth and the current date. Because the calculation is a constraint on the object class, the calculation is shown on this diagram within braces near the Student object class. Also, the crseCode is a primary key for the Course class. Other properties of attributes can be similarly shown.

REPRESENTING GENERALIZATION In the object-oriented approach, you can abstract the common features (attributes and operations) among multiple classes, as well as the relationships they participate in, into a more general class, as we saw with supertype/subtype relationships in E-R diagramming. The classes that are generalized are called subclasses, and the class they are generalized into is called a superclass.

Consider the example shown in Figure 8-32, which is the class diagramming equivalent of the E-R diagram in Figure 8-18. There are two types of patients: outpa- tients and resident patients. The features that are shared by all patients—patientId, patientName, and admitDate—are stored in the Patient superclass, whereas the fea- tures that are peculiar to a particular patient type are stored in the corresponding subclass (e.g., checkbackDate of Outpatient). A generalization path is shown as a solid

FIGURE 8-30 Ternary relationship with association classes

tool

user forum

Software

Student

Log

Course* *

beginDate expiryDate hoursLogged

estimateUsage ( )

FIGURE 8-31 Stereotypes

Student

name ssn dateOfBirth <<Derived>>/age

Course

<<PK>>crseCode crseTitle creditHrs

Course O�ering

term section

Registers-for Scheduled-for

registrants

{age=currentDate-dateOfBirth}

* * * 1

M08_VALA1629_09_GE_C08.indd 306 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 307

line from the subclass to the superclass, with an arrow at the end, and pointing toward the superclass. We also specify that this generalization is dynamic, meaning that an object may change subtypes. This generalization is also complete (there are no other subclasses) and disjoint (subclasses are not overlapping). Although not using exactly the same terminology, the same generalization business rules that we saw with E-R diagramming can be represented.

You can indicate the basis of a generalization by specifying a discriminator next to the path. A discriminator shows which property of an object class is being abstracted by a particular generalization relationship. You can discriminate on only one property at a time. For example, in Figure 8-32, we discriminate the Patient class on the basis of residency.

An instance of a subclass is also an instance of its superclass. For example, in Figure 8-32, an Outpatient instance is also a Patient instance. For that reason, a gen- eralization is also referred to as an Is-a relationship. Also, a subclass inherits all the features from its superclass. For example, in Figure 8-32, in addition to its own special feature—checkbackDate—the Outpatient subclass inherits patientId, patientName, admitDate, and any operations (not shown) from Patient.

Notice that in Figure 8-32, the Patient class is in italics, implying that it is an abstract class. An abstract class is a class that has no direct instances but whose descen- dants may have direct instances (Booch et al., 2007; Seidl et al., 2015; Unhelkar, 2017). (Note: You can also write the word abstract within braces just below the class name. This is especially useful when you generate a class diagram by hand.) A class that can have direct instances (e.g., Outpatient or Resident Patient) is called a concrete class. In this example, therefore, Outpatient and Resident Patient can have direct instances, but Patient cannot have any direct instances of its own.

The Patient abstract class participates in a relationship called Treated-by with Physician, implying that all patients—outpatients and resident patients alike—are treated by physicians. In addition to this inherited relationship, the Resident Patient class has its own special relationship called Assigned-to with Bed, implying that only resident patients may be assigned to beds. So, in addition to refining the attributes and operations of a class, a subclass can also specialize the relationships in which it participates.

In Figure 8-32, the words complete and disjoint have been placed within braces next to the generalization. They indicate semantic constraints among the subclasses (complete corresponds to total specialization in the Extended Entity Relationship [EER] notation [see Hoffer et al., 2016], whereas incomplete corresponds to partial specialization). Any of the following UML keywords may be used:

• Overlapping. A descendant may be descended from more than one of the sub- classes (same as the overlapping rule in EER diagramming).

Abstract class A class that has no direct instance, but whose descendants may have direct instances.

Concrete class A class that can have direct instances.

FIGURE 8-32 Example of generalizations, inheritance, and constraints

Patient {abstract} Treated-by

patientId patientName admitDate

* 1 Physician

physicianId

{complete, disjoint}

residency <<dynamic>>

Assigned-to 0..1 1 Bed

bedNumber

Outpatient

checkbackDate dateDischarged

Resident Patient

M08_VALA1629_09_GE_C08.indd 307 08/04/2020 16:41

308 PART III ANALYSIS

• Disjoint. A descendant may not be descended from more than one of the sub- classes (same as the disjoint rule in EER diagramming).

• Complete. All subclasses have been specified (whether or not shown). No addi- tional subclasses are expected (same as the total specialization rule in EER diagramming).

• Incomplete. Some subclasses have been specified, but the list is known to be incomplete. There are additional subclasses that are not yet in the model (same as the partial specialization rule in EER diagramming).

In Figure 8-33, we represent both graduate and undergraduate students in a model developed for student billing. The calc-tuition operation computes the tuition a student has to pay; this sum depends on the tuition per credit hour (tuitionPer- Cred), the courses taken, and the number of credit hours (creditHrs) for each of those courses. The tuition per credit hour, in turn, depends on whether the student is a graduate or an undergraduate student. In this example, that amount is $300 for all graduate students and $250 for all undergraduate students. To denote this, we have underlined the tuitionPerCred attribute in each of the two subclasses, along with its value. Such an attribute is called a class-scope attribute, which specifies a value com- mon to an entire class, rather than a specific value for an instance (Seidl et al., 2015; Unhelkar, 2017).

You can specify an initial default value of an attribute using an equals sign (=) after the attribute name (see creditHrs for the Course class in Figure 8-33). The dif- ference between an initial value specification and a class-scope attribute is that the former allows the possibility of different attribute values for the instances of a class, and the latter forces all the instances to share a common value.

In addition to specifying the multiplicity of an association role, you can also specify other properties, for example, if the objects playing the role are ordered or not. In the figure, we placed the keyword constraint “{ordered}” next to the Course Offering end of the Scheduled-for relationship to denote the fact that the offerings

Class-scope attribute An attribute of a class that specifies a value common to an entire class, rather than a specific value for an instance.

FIGURE 8-33 Polymorphism, abstract operation, class-scope attribute, and ordering

name ssn dateOfBirth address phone

Student {abstract}

term section

enrollment ( )

Course O�ering

crseCode crseTitle creditHrs=3

enrollment ( )

Course

Registers-for Scheduled-for * * * 1

{ordered}

undergradMajor greScore gmatScore tuitionPerCred=300

calc-tuition ( )

Graduate Student

satScore actScore tuitionPerCred=250

calc-tuition ( )

Undergrad Student

M08_VALA1629_09_GE_C08.indd 308 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 309

for a given course are ordered into a list—say, according to term and section. The default constraint on a role is “{unordered}.”

The Graduate Student subclass specializes the abstract Student class by adding four attributes—undergradMajor, greScore, gmatScore, and tuitionPerCred—and by refining the inherited calc-tuition operation. Notice that the operation is shown in italics within the Student class, indicating that it is an abstract operation. An abstract operation defines the form or protocol of the operation, but not its implementation. In this example, the Student class defines the protocol of the calc-tuition operation without providing the corresponding method (the actual implementation of the oper- ation). The protocol includes the number and types of the arguments, the result type, and the intended semantics of the operation. The two concrete subclasses, Graduate Student and Undergrad Student, supply their own implementations of the calc-tuition operation. Note that because these classes are concrete, they cannot store abstract operations.

It is important to note that, although the Graduate Student and Undergraduate Student classes share the same calc-tuition operation, they might implement the oper- ation in quite different ways. For example, the method that implements the operation for a graduate student might add a special graduate fee for each course the student takes. The fact that the same operation may apply to two or more classes in different ways is known as polymorphism, a key concept in object-oriented systems (Booch et al., 2007; Seidl et al., 2015; Unhelkar, 2017). The enrollment operation in Figure 8-33 illustrates another example of polymorphism. Whereas the enrollment operation within Course Offering computes the enrollment for a particular course offering or section, an operation with the same name within Course computes the combined enrollment for all sections of a given course.

REPRESENTING AGGREGATION An aggregation expresses a part-of relationship between a component object and an aggregate object. It is a stronger form of association relationship (with the added “part-of” semantics) and is represented with a hollow diamond at the aggregate end.

Figure 8-34 shows an aggregation structure of a university. Notice that the dia- mond at one end of the relationship between Building and Room is solid, not hollow. A solid diamond represents a stronger form of aggregation known as composition. In composition, a part object belongs to only one whole object; for example, a room is part of only one building. Therefore, the multiplicity on the aggregate end may not exceed one. Parts may be created after the creation of the whole object; for example,

Abstract operation Defines the form or protocol of the operation, but not its implementation.

Method The implementation of an operation.

Polymorphism The same operation may apply to two or more classes in different ways.

Aggregation A part-of relationship between a component object and an aggregate object.

Composition A part-of relationship in which parts belong to only one whole object, and the parts live and die with the whole object.

FIGURE 8-34 Aggregation and composition

1 1

20..*

1..* 1..*

Administrative Unit

Department

School Housed in

Consists of Part of

Building

Room

University

M08_VALA1629_09_GE_C08.indd 309 08/04/2020 16:41

310 PART III ANALYSIS

rooms may be added to an existing building. However, once part of a composition is created, it lives and dies with the whole; deletion of the aggregate object cascades to its components. If a building is demolished, for example, so are all of its rooms. However, it is possible to delete a part before its aggregate dies, just as it is possible to demolish a room without bringing down a building.

AN EXAMPLE OF CONCEPTUAL DATA MODELING AT HOOSIER BURGER Chapter 7 structured the process and logic requirements for a new inventory control system for Hoosier Burger. The DFD and decision table (repeated here as Figures 8-35 and 8-36) describe requirements for this new system. The purpose of this system is to monitor and report changes in raw material inventory levels and to issue material orders and payments to suppliers. Thus, the central data entity for this system will be an INVENTORY ITEM, corresponding to data store D1 in Figure 8-22.

Changes in inventory levels are due to two types of transactions: receipt of new items from suppliers and consumption of items from sales of products. Inventory is added upon receipt of new raw materials, for which Hoosier Burger receives a supplier INVOICE (see Process 1.0 in Figure 8-35). Each INVOICE indicates that the supplier has sent a specific quantity of one or more INVOICE_ITEMS, which correspond to Hoosier’s INVENTORY ITEMS. Inventory is used when customers order and pay for PRODUCTS. That is, Hoosier makes a SALE for one or more ITEM SALES, each of which corresponds to a food PRODUCT. Because the real-time customer order processing system is separate from the inventory control system, a source, STOCK ON HAND in Figure 8-35, represents how data flow from the order processing to the inventory control system. Finally, because food PRODUCTS are made up of vari- ous INVENTORY ITEMS (and vice versa), Hoosier maintains a RECIPE to indicate how much of each INVENTORY ITEM goes into making one PRODUCT. From this discussion, we have identified the data entities required in a data model for the new Hoosier Burger inventory control system: INVENTORY ITEM, INVOICE, INVOICE ITEM, PRODUCT, SALE, ITEM SALE, and RECIPE. To complete the data model, we

Hoosier Burger

FIGURE 8-35 Level-0 data flow diagram for Hoosier Burger’s new logical inventory control system

Invoices

InvoicesPayments Orders

Counts

Amounts Used

Amounts Added

Inventory Levels

Minimum Order Quantities

INVENTORYD1

1.0

Update Inventory

Added

3.0

Generate Orders

4.0

Generate Payments

2.0

Update Inventory

Used

SUPPLIER STOCK ON HAND

Query Request

Query Result

5.0

Query Inventory

Levels

MANAGER

M08_VALA1629_09_GE_C08.indd 310 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 311

must determine a necessary relationship between these entities as well as attributes for each entity.

The wording in the previous description tells us much of what we need to know to determine relationships:

• An INVOICE includes one or more INVOICE ITEMS, each of which corre- sponds to an INVENTORY ITEM. Obviously, an INVOICE ITEM cannot exist without an associated INVOICE, and over time there will be zero to many receipts, or INVOICE ITEMS, for an INVENTORY ITEM.

• Each PRODUCT has a RECIPE of INVENTORY ITEMS. Thus, RECIPE is an associative entity supporting a bill-of-materials type relationship between PRODUCT and INVENTORY ITEM.

• A SALE indicates that Hoosier sells one or more ITEM SALES, each of which corresponds to a PRODUCT. An ITEM SALE cannot exist without an associated SALE, and over time there will be zero to many ITEM SALES for a PRODUCT.

Figure 8-37 shows a class diagram with the classes and relationships described on the next page. In some cases, we include role names (e.g., a Sale plays the role of a transaction in the Sells association). RECIPE is shown as an association class rather than as simply a relationship between PRODUCT and INVENTORY ITEM because it is likely to have attributes and behaviors. Now that we understand the data classes and relationships, we must decide which data element and behaviors are associated with the data classes in this diagram. We have cho-sen to develop the conceptual data model using UML notation rather than E-R notation, but you should be able to easily translate the UML class diagrams into E-R diagrams (which is left as an exercise at the end of this section).

You may wonder at this point why only the INVENTORY data store is shown in Figure 8-35 when there are seven data classes on the class diagram. The INVEN- TORY data store corresponds to the INVENTORY ITEM data class in Figure 8-37. The other data classes are hidden inside other processes for which we have not shown lower-level diagrams. In actual requirements structuring steps, you would have to match all data classes with data stores: Each data store represents some sub- set of a class or an E-R diagram, and each data class or entity is included in one or more data stores. Ideally, each data store on a primitive DFD will be an individual data class or entity.

To determine data elements for a data class, we investigate data flows in and out of data stores that correspond to the data class and supplement this with a study of decision logic and temporal logic that uses or changes data about the data class.

FIGURE 8-36 Reduced decision table for Hoosier Burger’s inventory reordering

Conditions/ Rules Courses of Action

1 2 3 4 5 6 7

Type of item P P P P P P N

Time of week D W D W D W –

Season of year A A S S H H –

Standing daily order X X X

Standing weekend order X X X

Minimum order quantity X

Holiday reduction X X

Summer reduction XX

M08_VALA1629_09_GE_C08.indd 311 08/04/2020 16:41

312 PART III ANALYSIS

Six data flows are associated with the INVENTORY data store in Figure 8-35. The description of each data flow in the project dictionary or CASE repository would include the data flow’s composition, which then tells us what data are flowing in or out of the data store. For example, the Amounts Used data flow coming from Process 2.0 indicates how much to decrement an attribute Quantity_in_Stock due to use of the INVENTORY ITEM to fulfill a customer sale. Thus, the Amounts Used data flow implies that Process 2.0 will first read the relevant INVENTORY ITEM record, then update its Quantity_in_Stock attribute, and finally store the updated value in the record. Structured English for Process 2.0 would depict this logic. Each data flow would be analyzed similarly (space does not permit us to show the analysis for each data flow).

The analysis of data flows for data elements is supplemented by a study of deci- sion logic. For example, consider the decision table in Figure 8-36. One condition used to determine the process of reordering an INVENTORY ITEM involves the Type_of_Item. Thus, Process 3.0 in Figure 8-35 (to which this decision table relates) needs to know this characteristic of each INVENTORY ITEM, so this identifies another attribute of this data class.

An analysis of the DFD and decision table also suggests possible operations for each class. For example, the Inventory Item class will need operations to update quan- tity on hand, generate replenishment orders, and receive inventory counts.

After considering all data flows in and out of data stores related to data classes, plus all decision and temporal logic related to inventory control, we derive the full class diagram, with attributes and operations, shown in Figure 8-38.

FIGURE 8-37 Preliminary class diagram for Hoosier Burger’s inventory control system

Sale

transaction1

line item1..*

Sells

Item Sale

0..nline item

1item sold

Orders

Product

Invoice

1..*

Includes

Invoice Item

Receives

Inventory Item

Recipe

1..* 1..*

M08_VALA1629_09_GE_C08.indd 312 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 313

FIGURE 8-38 Final class diagram for Hoosier Burger’s inventory control systemSale

<<PK>> receiptNumber saleDate

transaction1

line item1..*

Sells

Item Sale

quantitySold

0..*line item

1item sold

Orders

Product

<<PK>> productId productDescription

Invoice

1..*

Includes

Invoice Item

1 Receives

Inventory Item

<<PK>> vendorId <<PK>> invoiceNumber invoiceDate Paid?

generalPayment()

quantityAdded

<<PK>> itemNumber itemDescription quantityInStock typeOfItem minimumOrderQuantity

updateQuantity() generateOrder() receiveCount()

Recipe

quantityUsed

1..* 1..*

SUMMARY We have presented the process and basic notation used to model the data requirements of an information system using class diagramming. A data model shows the rela- tively permanent business rules that define the nature of an organization. Rules define characteristics of data such as the unique characteristics of data classes and the rela- tionships between different data classes. A data model shows major categories of data, called classes for the UML notation; the associations or relationships between classes; and the attributes (only classes have attributes on a class

diagram). A special type of class called an association class is often necessary to represent a many-to-many relationship between classes. Classes are distinct from objects. Each object is distinguished from other instances of the same type by an identifier attribute (or attributes). Relationships are the glue that holds a data model together. The mini- mum and maximum number of objects that participate in a relationship represent important rules about the nature of the organization, as captured during requirements determination.

KEY TERMS

8.74 Abstract class 8.75 Abstract operation 8.76 Aggregation

8.77 Association 8.78 Association role 8.79 Associative class

8.80 Behavior 8.81 Class diagram 8.82 Class-scope attribute

M08_VALA1629_09_GE_C08.indd 313 08/04/2020 16:41

314 PART III ANALYSIS

REVIEW QUESTIONS 8.97 Give an example of aggregation. Your example should

include at least one aggregate object and three compo- nent objects. Specify the multiplicities at each end of all the aggregation relationships.

8.98 Contrast the following terms:

Object class; object Abstract class; concrete class

8.83 Class-scope operation 8.84 Composition 8.85 Concrete class 8.86 Constructor operation 8.87 Encapsulation

8.88 Method 8.89 Multiplicity 8.90 Object 8.91 Object (class) 8.92 Operation

8.93 Polymorphism 8.94 Query operation 8.95 State 8.96 Update operation

Match each of the key terms above with the definition that best fits it.

____A part object that belongs to only one whole object and that lives and dies with the whole.

____A part-of relationship between a component object and an aggregate object.

____The same operation may apply to two or more classes in dif- ferent ways.

____The implementation of an operation.

____Defines the form or protocol of the operation, but not its implementation.

____An attribute of a class that specifies a value common to an entire class, rather than a specific value for an instance.

____A class that can have direct instances.

____A class that has no direct instances but whose descendants may have direct instances.

____An association that has attributes or operations of its own or that participates in relationships with other classes.

____Indicates how many objects participate in a given relationship.

____The end of an association where it connects to a class.

____A relationship among instances of object classes.

____An operation that applies to a class rather than an object instance.

____An operation that alters the state of an object.

____An operation that accesses the state of an object but does not alter the state.

____An operation that creates a new instance of a class.

____The technique of hiding the internal implementation details of an object from its external view.

____A function or a service that is provided by all the instances of a class.

____A diagram that shows the static structure of an object-ori- ented model.

____A logical grouping of objects that have the same (or similar) attributes and behaviors (methods).

____Represents how an object acts and reacts.

____Encompasses an object’s properties (attributes and relation- ships) and the values those properties have.

____An entity that has a well-defined role in the application domain and has state, behavior, and identity characteristics.

PROBLEMS AND EXERCISES 8.99 Draw a class diagram, showing the relevant classes, attri-

butes, operations, and relationships for each of the fol- lowing situations (if you believe that you need to make additional assumptions, clearly state them for each situation):

a. A company has a number of employees. The attributes of Employee include employeeID (primary key), name, address, and birth date. The company also has several projects. Attributes of Project include projectName and startDate. Each employee may be assigned to one or

more projects, or may not be assigned to a project. A proj- ect must have at least one employee assigned, and it may have any number of employees assigned. An employee’s billing rate may vary by project, and the company wishes to record the applicable billing rate for each employee when assigned to a particular project. At the end of each month, the company mails a check to each employee who has worked on a project during that month. The check amount is based on the billing rate and the hours logged for each project assigned to the employee.

M08_VALA1629_09_GE_C08.indd 314 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 315

REFERENCES Bell, D. (2004). UML basics: The class diagram. Retrieved

April 9, 2018 from http://www.ibm.com/developerworks/ rational/library/content/RationalEdge/sep04/bell/index. html.

Booch, G., Maksimchuk, R. A., Engle, M. W., Young, B. J., Conallen, J., & Houston, K. A. (2007). Object-oriented analysis and design with applications (3rd ed.). Reading, MA: Addison-Wesley.

Daoust, N. (2012). UML Requirements Modeling for Business Analysts. Westfield, NJ: Technics Publications.

George, J., Batra, D., Valacich, J., & Hoffer, J. (2007). Object- oriented systems analysis and design (2nd ed.). Upper Saddle River, NJ: Prentice Hall.

Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern database man- agement (12th ed.). Upper Saddle River, NJ: Prentice Hall.

Seidl, M., Scholz, M., Huemer, C., & Kappel, G. (2015). UML@ Classroom: An introduction of object-oriented Modeling. Heidel- berg, Germany: Springer.

Unhelkar, B. (2017). Software engineering with UML. Boca Raton, FL: CRC Press.

b. A university has a large number of courses in its cata- log. Attributes of Course include courseNumber (pri- mary key), courseName, and units. Each course may have one or more different courses as prerequisites, or a course may have no prerequisites. Similarly, a par- ticular course may be a prerequisite for any number of courses, or it may not be a prerequisite for any other course. The university adds or drops a prerequisite for a course only when the director for the course makes a formal request to that effect.

c. A laboratory has several chemists who work on one or more projects. Chemists also may use certain kinds of equipment on each project. Attributes of Chem- ist include name and phoneNo. Attributes of Proj- ect include projectName and startDate. Attributes of Equipment include serialNo and cost. The organiza- tion wishes to record assignDate—that is, the date when a given equipment item was assigned to a particular chemist working on a specified project—as well as total Hours, that is, the total number of hours the chemist has used the equipment for the project. The organiza- tion also wants to track the usage of each type of equip- ment by a chemist. It does so by computing the average number of hours the chemist has used that equipment on all assigned projects. A chemist must be assigned to at least one project and one equipment item. A given equipment item need not be assigned, and a given project need not be assigned either a chemist or an equipment item.

d. A college course may have one or more scheduled sections, or it may not have a scheduled section. Attri- butes of Course include courseID, courseName, and units. Attributes of Section include sectionNumber and semester. The value of sectionNumber is an inte- ger (such as 1 or 2) that distinguishes one section from another for the same course, but does not uniquely identify a section. There is an operation called find- NumSections that finds the number of sections offered for a given course in a given semester.

e. A hospital has a large number of registered physicians. Attributes of Physician include physicianID (primary

key) and specialty. Patients are admitted to the hospital by physicians. Attributes of Patient include patientID (primary key) and patientName. Any patient who is admitted must have exactly one admitting physician. A physician may optionally admit any number of patients. Once admitted, a given patient must be treated by at least one physician. A particular physician may treat any number of patients, or he or she may not treat any patients. Whenever a patient is treated by a physician, the hospital wishes to record the details of the treat- ment by including the date, time, and results of the treatment.

8.100 A student, whose attributes include studentName, Address, phone, and age, may engage in multiple campus-based activities. The university keeps track of the number of years a given student has participated in a specific activity and, at the end of each academic year, mails an activity report to the student showing his or her participation in various activities. Draw a class diagram for this situation.

8.101 A bank has three types of accounts: checking, savings, and loan. Following are the attributes for each type of account:

CHECKING: Acct_No, Date_Opened, Balance, Service_ Charge SAVINGS: Acct_No, Date_Opened, Balance, Interest_Rate LOAN: Acct_No, Date_Opened, Balance, Interest_Rate, Payment

Assume that each bank account must be a member of exactly one of these subtypes. At the end of each month, the bank computes the balance in each account and mails a statement to the customer holding that account. The balance computation depends on the type of the account. For example, a checking account balance may reflect a service charge, whereas a savings account balance may include an interest amount. Draw a class diagram to rep- resent the situation. Your diagram should include an abstract class as well as an abstract operation for comput- ing balance.

8.102 Convert the class diagram in Figure 8-37 to the equivalent E-R diagram. Compare the two diagrams. Describe what different system specifications are shown in each diagram.

M08_VALA1629_09_GE_C08.indd 315 08/04/2020 16:41

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html

316 PART III ANALYSIS

stood up, carried his tray over to the recycling area of the cafeteria, and went back to his office.

When Jim got back to his office, Sanjay was waiting for him.

“I’ve got more information on those alternatives we talked about earlier,” Sanjay said. “I had one of my employ- ees gather some data on how the alternatives might satisfy our needs.” (See the descriptions of the alternatives at the end of Chapter 6.) Sanjay handed Jim a short report. “The matrix shows the requirements and constraints for each alternative and makes it relatively easy to compare them.” (See PE Figure 8-2.)

“The matrix favors the XRA CRM system,” Jim said, after looking over the report. “It looks like their proposal meets our requirements the best, but the Nova group’s proposal does the best job with the constraints.”

“Yes, but just barely,” Sanjay said. “There is only a five- point difference between XRA and Nova, so they are pretty comparable when it comes to constraints. But I think the XRA system has a pretty clear advantage in meeting our requirements.”

“XRA seems to be pretty highly rated in your matrix in terms of all of the requirements. You have them ranked better than the other two proposals for implementation, scalability, and vendor support,” Jim said. “The ‘5’ you gave them for proven performance is one of the few ‘5’s you have in your whole matrix.”

“That’s because they are one of the best companies in the industry to work with,” Sanjay responded. “Their reputa- tion is stellar.”

“This looks really promising,” Jim said. “Let’s see if reality matches what we have here. It’s time to put together the formal request for proposal. I’ll get that work started today. I hope that all three of these companies decide to bid.”

PETRIE ELECTRONICS

Chapter 8: Structuring System Data Requirements

Jim Watanabe, manager of the “No Customer Escapes” project, and assistant director of IT for Petrie Electronics, was sitting in the company cafeteria. He had just finished his house salad and was about to go back to his office when Stephanie Welch sat down at his table. Jim had met Stepha- nie once, back when he started work at Petrie. He remem- bered she worked for the database administrator.

“Hi, Jim, remember me?” she asked. “Sure, Stephanie, how are you? How are things in data-

base land?” “Can’t complain. Sanjay asked me to talk to you about

the database needs for your new customer loyalty system.” Stephanie’s phone beeped. She pulled it out of her oversize bag and looked at it. She started to text as she continued to talk to Jim. “How far along are you on your database requirements?”

That’s kind of rude, Jim thought. Oh well. “We are still in the early stages. I can send you a very preliminary E-R diagram we have (PE Figure 8-1), along with a description of the major entities.”

“OK, that will help. I suspect that you won’t have too many new entities to add to what’s already in the system,” Stephanie responded, still looking at her phone and still texting. She briefly looked up at Jim and smiled slightly before going back to texting. “Just send the E-R to me, and I’ll let you know if I have any questions.” She stood up, still looking at her phone. “Gotta go,” she said, and she walked away.

OK, Jim thought, I need to remember to send Stephanie the preliminary E-R we have. I should probably send her the entity descriptions too (PE Table 8-1), just in case. Jim

PE FIGURE 8-1 Initial E-R diagram for Petrie’s customer loyalty program

Promotion

Coupon Service

Customer Transaction

Product

M08_VALA1629_09_GE_C08.indd 316 08/04/2020 16:41

CHAPTER 8 StRuctuRing SyStem Data RequiRementS 317

Entity Description

Coupon A coupon is a special promotion created specifically for an individual customer. A coupon is for a set dollar amount, for example, $10. The customer may use it like cash or like a dollars-off promotion when purchasing products or services. Coupons can only be created for an individual customer based on the points in his or her customer loyalty account. For each dollar value of a coupon, a certain number of points must be redeemed. Coupons must be accounted for when created and when redeemed.

Customer A customer is someone who buys products and/or services from Petrie Electronics. Customers include both online customers and those who shop in Petrie’s brick-and-mortar stores.

Product A service is an item made available for sale to a Petrie customer. For example, a product is a 40” Sony LCD HD television. Products can be purchased online or in brick-and-mortar stores.

Promotion A promotion is a special incentive provided to a customer to entice the customer into buying a specific product or service. For example, a promotion intended to sell Blu-ray discs may involve 2-for-1 coupons. Promotions are targeted to all customers, or to subsets of customers, not just to individual customers.

Service A service is a job performed by one of Petrie’s associates for a customer. For example, upgrading the memory in a computer by installing new memory cards is a service that Petrie provides for a fee. Services may only be ordered and performed in brick-and-mortar stores, not online.

Transaction A transaction is a record that a particular product or service was sold to a specified customer on a particular date. A transaction may involve more than one product or service, and it may involve more than one of a particular kind of product or service. For example, one transaction may involve blank DVDs and pre-recorded DVDs, and the pre-recorded DVDs may all be of the same movie. For members of the loyalty program, each transaction is worth a number of points, depending on the dollar value of the transaction.

PE TABLE 8-1 Entity Descriptions for the preliminary E-R diagram for Petrie’s customer loyalty system

PE FIGURE 8-2 Evaluation matrix for customer loyalty proposals

Criteria Alt A: SBSI Alt B XRA Alt C Nova Weight Rating Score Rating Score Rating Score

Requirements

E�ective customer incentives 15 5 75 4 60 4 60 Easy for customers to use 10 3 30 4 40 5 50 Proven performance 10 4 40 5 50 3 30 Easy to implement 5 3 15 4 20 3 15 Scalable 10 3 30 4 40 3 30 Vendor support 10 3 30 4 40 3 30

60 220 250 215

Constraints

Cost to buy 15 3 45 4 60 5 75 Cost to operate 10 3 30 4 40 4 40 Time to implement 5 3 15 3 15 3 15 Sta� to implement 10 3 30 4 40 3 30

40 120 155 160

TOTAL 100 340 405 375

Case Questions

8.103 Review the data flow diagrams you developed for questions in the Petrie Electronics case at the end of Chapter 7 (or diagrams given to you by your instructor). Study the data flows and data stored on these diagrams and decide whether you agree with the team’s conclusion that the only six entity types needed are listed in the case and in PE Figure 8-1. If you disagree, define additional entity types, explain why they are necessary, and modify PE Figure 8-1 accordingly.

8.104 Again, review the DFDs you developed for the Pet- rie Electronics case (or those given to you by your instructor). Use these DFDs to identify the attributes of each of the six entities listed in this case plus any additional entities identified in your answer to Case Question 8.103. Write an unambiguous definition for each attribute. Then, redraw PE Figure 8-1 by placing the six (and additional) entities in this case on the diagram along with their associated attributes.

M08_VALA1629_09_GE_C08.indd 317 08/04/2020 16:41

318 PART III ANALYSIS

8.105 Using your answer to Case Question 8.104, desig- nate which attribute or attributes form the identifier for each entity type. Explain why you chose each identifier.

8.106 Using your answer to Case Question 8.105, draw the relationships between entity types needed by the sys- tem. Remember, a relationship is needed only if the system wants data about associated entity instances. Give a meaningful name to each relationship. Spec- ify cardinalities for each relationship and explain how you decided on each minimum and maximum cardinality on each end of each relationship. State any assumptions you made if the Petrie Electronics cases you have read so far and the answers to ques- tions in these cases do not provide the evidence to justify the cardinalities you chose. Redraw your final E-R diagram in Microsoft Visio.

8.107 Now that you have developed in your answer to Case Question 8.106 a complete E-R diagram for the Petrie Electronics database, what are the con- sequences of not having an employee entity type in

this diagram? Assuming only the attributes you show on the E-R diagram, would any attribute be moved from the entity it is currently associated with to an employee entity type if it were in the diagram? Why or why not?

8.108 Write project dictionary entries (using standards given to you by your instructor) for all the entities, attributes, and relationships shown in the E-R dia- gram in your answer to Case Question 8.106. How detailed are these entries at this point? What other details still must be filled in? Are any of the entities on the E-R diagram in your answer to Case Ques- tion 8.106 weak entities? Why? In particular, is the SERVICE entity type a weak entity? If so, why? If not, why not?

8.109 What date-related attributes did you identify in each of the entity types in your answer to Case Question 8.106? Why are each of these needed? Can you make some general observations about why date attributes must be kept in a database based on your analysis of this database?

M08_VALA1629_09_GE_C08.indd 318 08/04/2020 16:41

Chapter 9 Designing Databases

Chapter 10 Designing Forms and Reports

Design

Chapter 11 Designing Interfaces and Dialogues

Chapter 12 Designing Distributed and Internet Systems

PA RT F O U R

319

M09A_VALA1629_09_GE_P04.indd 319 08/04/2020 16:42

320

The focus of Part Four is system design, which is often the first phase of the systems development life cycle, the phase in which you and the user develop a concrete understand- ing of how the system will operate. The activities within design are not necessarily sequential. For example, the design of data, system inputs and outputs, and interfaces interact, allowing you to identify flaws and missing ele- ments. This means that the project dictionary or CASE repository becomes an active and evolving component of systems development management during design. It is only when each design element is consistent with others and each one is satisfactory to the end user that you know that the design phase is complete.

Data are a core system element, and data design and structure are studied in all systems development method- ologies. You have seen how data flow diagrams (DFDs) and entity-relationship (E-R) diagrams (as well as use cases and class diagrams from the object-oriented mate- rial at the end of prior chapters) are used to depict the data requirements of a system. These diagrams are flex- ible and allow considerable latitude in how you represent data. For example, you can use one or many data stores with a process in a DFD. E-R diagrams provide more structure, but an entity can still be either very detailed or rather aggregate. When designing databases, you define data in its most fundamental form, called normalized data. Normalization is a well-defined method of identifying rela- tionships between each data attribute and representing all the data so that they cannot logically be broken down into more detail. The goal is to rid the data design of unwanted anomalies that would make a database sus- ceptible to errors and inefficiencies. This is the topic of Chapter 9.

In Chapter 10, you will learn the principles and guidelines for usable system inputs and outputs. Your overall goal in formatting the presentation of data to users should be usability: helping users of all types to use the system efficiently, accurately, and with satisfaction. The achievement of these goals can be greatly improved if you follow certain guidelines when presenting data on

OVERVIEW

business forms, visual display screens, printed documents, and other kinds of media. Fortunately, there has been considerable research on how to present data to users, and Chapter 10 summarizes and illustrates the most use- ful of these guidelines. Chapter 11 is closely related to Chapter 10 and addresses principles you should follow in tying all the system inputs and outputs together into an overall pattern of interaction between users and the system. System interfaces and dialogues form a conversa- tion that provides user access to and navigation between each system function. Chapter 11 focuses on providing specifications for designing effective system interfaces and dialogues and a technique for representing these designs called dialogue diagramming.

For traditional development efforts, before devel- opers can begin the implementation process, questions about multiple users, multiple platforms, and program and data distribution have to be considered. The extent to which the system is Internet-based also has an impact on numerous design issues. The focus of Chapter 12 is on the intricacies of designing distributed and Internet systems.

The deliverables of design include detailed, func- tional specifications for system inputs, outputs, interfaces, dialogues, and databases. Often these elements are rep- resented in prototypes, or working versions. The project dictionary or CASE repository is updated to include each form, report, interface, dialogue, and relation design. Due to considerable user involvement in reviewing proto- types and specifications during design, and due to the fact that activities within design can be scheduled with con- siderable overlap in the project baseline plan, a formal review milestone or walk-through often does not occur after each activity. If prototyping is not done, however, you should conduct a formal walk-through at the comple- tion of the system design phase.

All of the chapters in Part Four conclude with a Petrie Electronics case. These cases illustrate numerous relevant design activities for an ongoing systems develop- ment project within the company.

PART FOUR

Design

M09A_VALA1629_09_GE_P04.indd 320 08/04/2020 16:42

321

In Chapter 8, you learned how to represent an organiza- tion’s data graphically using an entity-relationship (E-R), or class, diagram. In this chapter, you will learn guidelines for well-structured and efficient database files, and you will learn about logical and physical database design. It is likely that the human interface and database design steps will happen in parallel, as illustrated in the systems development life cycle (SDLC) in Figure 9-1.

Database design has five purposes:

1. Structure the data in stable structures, called normalized tables, that are not likely to change over time and that have minimal redundancy.

2. Develop a logical database design that reflects the actual data requirements that exist in the forms (hard copy and computer displays) and reports of an informa- tion system. This is why database design is often done in parallel with the design of the human interface of an information system.

3. Develop a logical database design from which we can do physical database design. Because most information systems today use relational database management sys- tems, logical database design usually uses a relational

database model, which represents data in simple tables with common columns to link related tables.

4. Translate a relational database model into a technical file and database design that balances several perfor- mance factors.

5. Choose data storage technologies (such as Read/Write DVD or optical disc) that will efficiently, accurately, and securely process database activities.

The implementation of a database (i.e., creating and loading data into files and databases) is done during the next phase of the systems development life cycle. Because implementation is technology specific, we address imple- mentation issues only at a general level in Chapter 13.

DATABASE DESIGN File and database design occurs in two steps. You begin by developing a logical database model, which describes data using a notation that corresponds to a data organiza- tion used by a database management system. This is the system software responsible for storing, retrieving, and protecting data (such as Microsoft Access, Oracle, or SQL

9.5 describe physical database design concepts including choosing storage formats for fields in database tables, translating well-structured relations into efficient database tables, explaining when to use different types of file organizations to store com- puter files, and describing the purpose of indexes and the important considerations in selecting attri- butes to be indexed.

Learning Objectives After studying this chapter, you should be able to

9.1 describe the database design process, its outcomes, and the relational database model;

9.2 describe normalization and the rules for second and third normal form;

9.3 transform an entity-relationship (E-R) diagram into an equivalent set of well-structured (normalized) relations;

9.4 merge normalized relations from separate user views into a consolidated set of well-structured relations; and

Designing Databases9

Introduction

M09B_VALA1629_09_GE_C09.indd 321 08/04/2020 16:43

322 PART IV DESIGN

Server). The most common style for a logical database model is the relational database model. Once you develop a clear and precise logical database model, you are ready to prescribe the technical specifications for computer files and databases in which to store the data. A physical database design provides these specifications.

You typically do logical and physical database design in parallel with other sys- tems design steps. Thus, you collect the detailed specifications of data necessary for logical database design as you design system inputs and outputs. Logical database design is driven not only from the previously developed E-R data model for the appli- cation or enterprise but also from form and report layouts. You study data elements on these system inputs and outputs and identify interrelationships among the data. As with conceptual data modeling, the work of all systems development team members is coordinated and shared through the project dictionary or repository. The designs for logical databases and system inputs and outputs are then used in physical design activi- ties to specify to computer programmers, database administrators, network managers, and others how to implement the new information system. For this text, we assume that the design of computer programs and distributed information processing and data networks are topics of other courses, so we concentrate on the aspect of physical design most often undertaken by a systems analyst—physical file and database design.

The Process of Database Design

Figure 9-2 shows that database modeling and design activities occur in all phases of the systems development process. In this chapter, we discuss methods that help you final- ize logical and physical database designs during the design phase. In logical database design, you use a process called normalization, which is a way to build a data model that has the properties of simplicity, nonredundancy, and minimal maintenance.

In most situations, many physical database design decisions are implicit or elimi- nated when you choose the data management technologies to use with the applica- tion. We concentrate on those decisions you will make most frequently and use Oracle to illustrate the range of physical database design parameters you must manage. The

FIGURE 9-1 Systems development life cycle with design phase highlighted

DesignImplementation

Planning

Maintenance Analysis

Databases Forms and Reports Dialogues and Interfaces Finalizing Design Specifications Distributed and Internet Systems

M09B_VALA1629_09_GE_C09.indd 322 08/04/2020 16:43

CHAPTER 9 Designing Databases 323

interested reader is referred to Hoffer, Ramesh, & Topi (2016) for a more thorough treatment of techniques for logical and physical database design.

There are four key steps in logical database modeling and design:

1. Develop a logical data model for each known user interface (form and report) for the application using normalization principles.

2. Combine normalized data requirements from all user interfaces into one consoli- dated logical database model; this step is called view integration.

3. Translate the conceptual E-R data model for the application or enterprise, devel- oped without explicit consideration of specific user interfaces, into normalized data requirements.

4. Compare the consolidated logical database design with the translated E-R model and produce, through view integration, one final logical database model for the application.

During physical database design, you use the results of these four key logical database design steps. You also consider definitions of each attribute; descriptions of where and when data are entered, retrieved, deleted, and updated; expectations for response time and data integrity; and descriptions of the file and database technolo- gies to be used. These inputs allow you to make key physical database design decisions, including the following:

• Choosing the storage format (called data type) for each attribute from the logi- cal database model; the format is chosen to minimize storage space and to maxi- mize data quality. Data type involves choosing length, coding scheme, number of decimal places, minimum and maximum values, and potentially many other parameters for each attribute.

• Grouping attributes from the logical database model into physical records (in general, this is called selecting a stored record, or data, structure).

• Arranging related records in secondary memory (hard disks and magnetic tapes) so that individual records and groups of records can be stored, retrieved, and updated rapidly (called file organization). You should also consider protect- ing data and recovering data after errors are found.

FIGURE 9-2 Relationship between data modeling and the SDLC

DesignImplementation

Planning

Maintenance Analysis

• Enterprise-wide data model (E-R with only entities)

• Conceptual data mode (E-R with only entities for specific project)

• Data model evolution

• Database and file definitions (DBMS specific code)

• Logical data model (relational) and physical file and database design (file organizations)

• Conceptual data models (E-R with attributes)

M09B_VALA1629_09_GE_C09.indd 323 08/04/2020 16:43

324 PART IV DESIGN

• Selecting media and structures for storing data to make access more efficient. The choice of media affects the utility of different file organizations. The pri- mary structure used today to make access to data more rapid is key indexes on unique and nonunique keys.

In this chapter, we show how to do each of these logical database design steps and discuss factors to consider in making each physical file and database design decision.

Deliverables and Outcomes

During logical database design, you must account for every data element on a system input or output—form or report—and on the E-R diagram. Each data element (e.g., customer name, product description, or purchase price) must be a piece of raw data kept in the system’s database or, in the case of a data element on a system output, the element can be derived from data in the database. Figure 9-3 illustrates the outcomes from the four-step logical database design process listed earlier. Figures 9-3a and 9-3b (step 1) contain two sample system outputs for a customer order processing system at Pine Valley Furniture (PVF). A description of the associated database requirements, in the form of what we call normalized relations, is listed below each output diagram. Each relation (think of a relation as a table with rows and columns) is named, and its attributes (columns) are listed within parentheses. The primary key attribute—that attribute whose value is unique across all occurrences of the relation—is indicated by an underline, and an attribute of a relation that is the primary key of another relation is indicated by a dashed underline.

In Figure 9-3a, data about customers, products, and the customer orders and associated line items for products are shown. Each of the attributes of each relation either appears in the display or is needed to link connected relations. For example, because an order is for a customer, an attribute of ORDER is the associated Cus- tomer_ID. The data for the display in Figure 9-3b are more complex. A backlogged product on an order occurs when the amount ordered (Order_Quantity) is less than the amount shipped (Ship_Quantity) for invoices associated with an order. The query refers only to a specified time period, so the Order_Date is needed. The INVOICE Order_Number links invoices with the associated order.

Figure 9-3c (step 2) shows the result of integrating these two separate sets of normalized relations. Figure 9-3d (step 3) shows an E-R diagram for a customer order processing application that might be developed during conceptual data modeling, along with equivalent normalized relations. Finally, Figure 9-3e (step 4) shows a set of normalized relations that would result from reconciling the logical database designs of Figures 9-3c and 9-3d. Normalized relations like those in Figure 9-3e are the primary deliverable from logical database design.

It is important to remember that relations do not correspond to computer files. In physical database design, you translate the relations from logical database design into specifications for computer files. For most information systems, these files will be tables in a relational database. These specifications are sufficient for programmers and database analysts to code the definitions of the database. The coding, done dur- ing systems implementation, is written in special database definition and processing languages, such as Structured Query Language (SQL), or by filling in table defini- tion forms, such as with Microsoft Access. Figure 9-4 shows a possible definition for the SHIPMENT relation from Figure 9-3e using Microsoft Access. This display of the SHIPMENT table definition illustrates choices made for several physical database design decisions.

• All three attributes from the SHIPMENT relation, and no attributes from other relations, have been grouped together to form the fields of the SHIPMENT table.

• The Invoice Number field has been given a data type of Text, with a maximum length of 10 characters.

Primary key An attribute (or combination of attri- butes) whose value is unique across all occurrences of a relation.

M09B_VALA1629_09_GE_C09.indd 324 08/04/2020 16:43

CHAPTER 9 Designing Databases 325

FIGURE 9-3 Simple example of logical data modeling (a) Highest-volume customer query screen

HIGHEST-VOLUME CUSTOMER

ENTER PRODUCT ID.: M128 START DATE: 11/01/2020 END DATE: 12/31/2020 – – – – – – – – – – – – – – – – – – – – – CUSTOMER ID.: 1256 NAME: Commonwealth Builder VOLUME: 30

This inquiry screen shows the customer with the largest volume of total sales for a specified product during an indicated time period.

Relations: CUSTOMER(Customer_ID,Name) ORDER(Order_Number,Customer_ID,Order_Date) PRODUCT(Product_ID) LINE ITEM(Order_Number,Product_ID,Order_Quantity)

- - - - - - - - -

(a)

BACKLOG SUMMARY REPORT 11/30/2020

PAGE 1

BACKLOG QUANTIT YPRODUCT ID

B381 B975 B985 E125

M128

0 0 6

… …

This report shows the unit volume of each product that has been ordered less that amount shipped through the specified date.

Relations: PRODUCT(Product_ID) LINE ITEM(Product_ID,Order_Number,Order_Quantity) ORDER(Order_Number,Order_Date) SHIPMENT(Product_ID,Invoice_Number,Ship_Quantity) INVOICE(Invoice_Number,Invoice_Date,Order_Number)

(b)

CUSTOMER(Customer_ID,Name) PRODUCT(Product_ID) INVOICE(Invoice_Number,Invoice_Date,Order_Number) ORDER(Order_Number,Customer_ID,Order_Date) LINE ITEM(Order_Number,Product_ID,Order_Quantity) SHIPMENT(Product_ID,Invoice_Number,Ship_Quantity)

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _

(c)

(b) Backlog summary report

M09B_VALA1629_09_GE_C09.indd 325 08/04/2020 16:43

326 PART IV DESIGN

• The Invoice Number field is required because it is part of the primary key for the SHIPMENT table (the value that makes every row of the SHIPMENT table unique is a combination of Invoice Number and Product ID).

• An index is defined for the Invoice Number field, but because there may be several rows in the SHIPMENT table for the same invoice (different products on the same invoice), duplicate index values are allowed (so Invoice Number is what we will call a secondary key).

Places

Bills

LINE ITEM Order_Quantity

SHIPMENT Ship_Quantity

CUSTOMER Customer_ID Name Address

ORDER Order_Number Order_Date

INVOICE Invoice_Number

PRODUCT Product_ID Description

Relations:

CUSTOMER(Customer_ID,Name,Address) PRODUCT(Product_ID,Description) ORDER(Order_Number,Customer_ID,Order_Date) LINE ITEM(Order_Number,Product_ID,Order_Quantity) INVOICE(Invoice_Number,Order_Number) SHIPMENT(Invoice_Number,Product_ID,Ship_Quantity)

- - - - - - - - - -

- - - - - - - - -

(d)

CUSTOMER(Customer_ID,Name,Address) PRODUCT(Product_ID,Description) ORDER(Order_Number,Customer_ID,Order_Date) LINE ITEM(Order_Number,Product_ID,Order_Quantity) INVOICE(Invoice_Number,Order_Number,Invoice_Date) SHIPMENT(Invoice_Number,Product_ID,Ship_Quantity)

_ _ _ _ _ _ _

_ _ _ _ _ _ _ _

(e)

FIGURE 9-3 (continued) (d) Conceptual data model and trans- formed relations

(e) Final set of normalized relations

FIGURE 9-4 Definition of shipment table in Microsoft Access

(Source: Microsoft Corporation.)

M09B_VALA1629_09_GE_C09.indd 326 08/04/2020 16:43

CHAPTER 9 Designing Databases 327

Many other physical database design decisions were made for the SHIPMENT table, but they are not apparent on the display in Figure 9-4. Further, this table is only one table in the Pine Valley Furniture Company Order Entry database, and other tables and structures for this database are not illustrated in this figure.

The Relational Database Model

Many different database models are in use and are the bases for database technologies. Although hierarchical and network models have been popular in the past, these are not used very often today for new information systems. Object-oriented database models are emerging but are still not common. The vast majority of information systems today use the relational database model. The relational database model (Codd, 1970; Date, 2012; Elmasri & Navathe, 2015; Umanath & Scamell, 2014) represents data in the form of related tables, or relations. A relation is a named, two-dimensional table of data. Each relation (or table) consists of a set of named columns and an arbitrary number of unnamed rows. Each column in a relation corresponds to an attribute of that relation. Each row of a relation corresponds to a record that contains data values for an entity.

Figure 9-5 shows an example of a relation named EMPLOYEE1. This relation contains the following attributes describing employees: Emp_ID, Name, Dept, and Salary. This table has five sample rows, corresponding to five employees.

You can express the structure of a relation with a shorthand notation in which the name of the relation is followed (in parentheses) by the names of the attributes in the relation. The identifier attribute (called the primary key of the relation) is under- lined. For example, you would express EMPLOYEE1 as follows:

EMPLOYEE1(Emp_ID,Name,Dept,Salary)

Not all tables are relations. Relations have several properties that distinguish them from nonrelational tables:

1. Entries in cells are simple. An entry at the intersection of each row and column has a single value.

2. Entries in a given column are from the same set of values. 3. Each row is unique. Uniqueness is guaranteed because the relation has a non-

empty primary key value. 4. The sequence of columns can be interchanged without changing the meaning or

use of the relation. 5. The rows may be interchanged or stored in any sequences.

Well-Structured Relations

What constitutes a well-structured relation (also known as a table)? Intuitively, a well- structured relation contains a minimum amount of redundancy and allows users to insert, modify, and delete the rows in a table without errors or inconsistencies.

Relational database model Data represented as a set of related tables or relations.

Relation A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows.

Well-structured relation A relation that contains a minimum amount of redundancy and that allows users to insert, modify, and delete the rows without error or inconsistencies; also known as a table.

FIGURE 9-5 EMPLOYEE1 relation with sample data

EMPLOYEE1

Emp_ID Name Dept Salary

100 Margaret Simpson Marketing 75,000 140 Allen Beeton Accounting 95,000 110 Chris Lucero Info Systems 90,000 190 Lorenzo Davis Finance 90,000 150 Susan Martin Marketing 62,000

M09B_VALA1629_09_GE_C09.indd 327 08/04/2020 16:43

328 PART IV DESIGN

EMPLOYEE1 (Figure 9-5) is such a relation. Each row of the table contains data describing one employee, and any modification to an employee’s data (such as a change in salary) is confined to one row of the table.

In contrast, EMPLOYEE2 (Figure 9-6) contains data about employees and the courses they have completed. Each row in this table is unique for the combination of Emp_ID and Course, which becomes the primary key for the table. This is not a well- structured relation, however. If you examine the sample data in the table, you notice a considerable amount of redundancy. For example, the Emp_ID, Name, Dept, and Salary values appear in two separate rows for employees 100, 110, and 150. Conse- quently, if the salary for employee 100 changes, we must record this fact in two rows (or more, for some employees).

The problem with this relation is that it contains data about two entities: EMPLOYEE and COURSE. You will learn to use principles of normalization to divide EMPLOYEE2 into two relations. One of the resulting relations is EMPLOYEE1 (Figure 9-5). The other we will call EMP COURSE, which appears with sample data in Figure 9-7. The primary key of this relation is the combination of Emp_ID and Course (we emphasize this by underlining the column names for these attributes).

NORMALIZATION We have presented an intuitive discussion of well-structured relations; however, we need rules and a process for designing them. Normalization is a process for converting complex data structures into simple, stable data structures (Date, 2012). For example,

Normalization The process of converting complex data structures into simple, stable data structures.

FIGURE 9-6 Relation with redundancy

Emp_ID Name Dept Salary Course Date_Completed

100 Margaret Simpson Marketing 42,000 SPSS 6/19/2020 100 Margaret Simpson Marketing 42,000 Surveys 10/7/2020 140 Alan Beeton Accounting 39,000 Tax Acc 12/8/2020 110 Chris Lucero Info Systems 41,500 SPSS 1/22/2020 110 Chris Lucero Info Systems 41,500 C++ 4/22/2020 190 Lorenzo Davis Finance 38,000 Investments 5/7/2020 150 Susan Martin Marketing 38,500 SPSS 6/19/2020 150 Susan Martin Marketing 38,500 TQM 8/12/2020

EMPLOYEE2

FIGURE 9-7 EMP COURSE relation

Date_ Emp_ID Course Completed

100 SPSS 6/19/2020 100 Surveys 10/7/2020 140 Tax Acc 12/8/2020 110 SPSS 1/22/2020 110 C++ 4/22/2020 190 Investments 5/7/2020 150 SPSS 6/19/2020 150 TQM 8/12/2020

EMP COURSE

M09B_VALA1629_09_GE_C09.indd 328 08/04/2020 16:43

CHAPTER 9 Designing Databases 329

we used the principles of normalization to convert the EMPLOYEE2 table with its redundancy to EMPLOYEE1 (Figure 9-5) and EMP COURSE (Figure 9-7).

Rules of Normalization

Normalization is based on well-accepted principles and rules. There are many nor- malization rules, more than can be covered in this text (see Hoffer et al. [2016] or Kroenke, Auer, Vandenberg, & Yoder [2017] for a more complete coverage). Besides the five properties of relations outlined previously, there are two other frequently used rules:

1. Second normal form (2NF). Each nonprimary key attribute is identified by the whole key (what we call full functional dependency). For example, in Figure 9-7, both Emp_ID and Course identify a value of Date_Completed because the same Emp_ID can be associated with more than one Date_Completed and the same for Course.

2. Third normal form (3NF). Nonprimary key attributes do not depend on each other (what we call no transitive dependencies). For example, in Figure 9-5, Name, Dept, and Salary cannot be guaranteed to be unique for one another.

The result of normalization is that every nonprimary key attribute depends upon the whole primary key and nothing but the primary key. We discuss second and third normal form in more detail next.

Functional Dependence and Primary Keys

Normalization is based on the analysis of functional dependence. A functional dependency is a particular relationship between two attributes. In a given relation, attribute B is functionally dependent on attribute A if, for every valid value of A, that value of A uniquely determines the value of B (Date, 2012; Hoffer et al., 2016; Kroenke et al., 2017). The functional dependence of B on A is represented by an arrow, as follows: A → B (e.g., Emp_ID→ Name in the relation of Figure 9-5). Functional depen- dence does not imply mathematical dependence—that the value of one attribute may be computed from the value of another attribute; rather, functional dependence of B on A means that there can be only one value of B for each value of A. Thus, a given Emp_ID value can have only one Name value associated with it; the value of Name, however, cannot be derived from the value of Emp_ID. Other examples of functional dependencies from Figure 9-3b are in ORDER, Order_Number, Order_Date, and in INVOICE, Invoice_Number, Invoice_Date, and Order_Number.

An attribute may be functionally dependent on two (or more) attributes rather than on a single attribute. For example, consider the relation EMP COURSE (Emp_ ID,Course,Date_Completed) shown in Figure 9-7. We represent the–functional depen- dency in this relation as follows:

Emp_ID,Course → Date_Completed (this is sometimes shown as Emp_ID + Course → Date_Completed). In this case, Date_Completed cannot be determined by either Emp_ID or Course alone because Date_Completed is a characteristic of an employee taking a course.

You should be aware that the instances (or sample data) in a relation do not prove that a functional dependency exists. Only knowledge of the problem domain, obtained from a thorough requirements analysis, is a reliable method for identifying a functional dependency. However, you can use sample data to demonstrate that a functional dependency does not exist between two or more attributes. For example, consider the sample data in the relation EXAMPLE(A,B,C,D), shown in Figure 9-8. The sample data in this relation prove that attribute B is not functionally dependent on attribute A because A does not uniquely determine B (two rows with the same value of A have different values of B).

Functional dependency A constraint between two attributes in which the value of one attribute is deter- mined by the value of another attribute.

FIGURE 9-8 EXAMPLE relation

A B C D

X U Y X Z Y Y Z

X Y Z X Y Y W Z

EXAMPLE

M09B_VALA1629_09_GE_C09.indd 329 08/04/2020 16:43

330 PART IV DESIGN

Second Normal Form

A relation is in second normal form (2NF) if every nonprimary key attribute is func- tionally dependent on the whole primary key. Thus, no nonprimary key attribute is functionally dependent on part, but not all, of the primary key. Second normal form is satisfied if any one of the following conditions apply:

1. The primary key consists of only one attribute (such as the attribute Emp_ID in relation EMPLOYEE1).

2. No nonprimary key attributes exist in the relation. 3. Every nonprimary key attribute is functionally dependent on the full set of primary

key attributes.

EMPLOYEE2 (Figure 9-6) is an example of a relation that is not in second nor- mal form. The shorthand notation for this relation is

EMPLOYEE2(Emp_ID,Name,Dept,Salary,Course,Date_Completed)

The functional dependencies in this relation are the following:

Emp_ID → Name,Dept,Salary

Emp_ID,Course → Date_Completed

The primary key for this relation is the composite key Emp_ID,Course. There- fore, the nonprimary key attributes Name, Dept, and Salary are functionally depen- dent on only Emp_ID but not on Course. EMPLOYEE2 has redundancy, which results in problems when the table is updated.

To convert a relation to second normal form, you decompose the relation into new relations using the attributes, called determinants, that determine other attributes; the determinants are the primary keys of these relations. EMPLOYEE2 is decomposed into the following two relations:

1. EMPLOYEE(Emp_ID,Name,Dept,Salary): This relation satisfies the first second normal form condition (sample data shown in Figure 9-5).

2. EMP COURSE(Emp_ID,Course,Date_Completed): This relation satisfies second normal form condition three (sample data appear in Figure 9-7).

Third Normal Form

A relation is in third normal form (3NF) if it is in second normal form and there are no functional dependencies between two (or more) nonprimary key attributes (a functional dependency between nonprimary key attributes is also called a transi- tive dependency). For example, consider the relation SALES (Customer_ID,Customer, Name,Salesperson,Region) (sample data shown in Figure 9-9a).

The following functional dependencies exist in the SALES relation:

1. Customer_ID → Customer_Name,Salesperson,Region (Customer_ID is the primary key.)

2. Salesperson → Region (Each salesperson is assigned to a unique region.)

Notice that SALES is in second normal form because the primary key consists of a single attribute (Customer_ID). However, Region is functionally dependent on Salesperson, and Salesperson is functionally dependent on Customer_ID. As a result, there are data maintenance problems in SALES.

1. A new salesperson (Robinson) assigned to the North region cannot be entered until a customer has been assigned to that salesperson (because a value for Cus- tomer_ID must be provided to insert a row in the table).

Second normal form (2NF) A relation is in second normal form if every nonprimary key attribute is functionally dependent on the whole primary key.

Third normal form (3NF) A relation is in second normal form and has no functional (transitive) dependen- cies between two (or more) nonprimary key attributes.

M09B_VALA1629_09_GE_C09.indd 330 08/04/2020 16:43

CHAPTER 9 Designing Databases 331

2. If customer number 6837 is deleted from the table, we lose the information that salesperson Hernandez is assigned to the East region.

3. If salesperson Smith is reassigned to the East region, several rows must be changed to reflect that fact (two rows are shown in Figure 9-9a).

These problems can be avoided by decomposing SALES into the two rela- tions, based on the two determinants, shown in Figure 9-9b. These relations are the following:

SALES1(Customer_ID,Customer_Name,Salesperson) SPERSON(Salesperson,Region)

Note that Salesperson is the primary key in SPERSON. Salesperson is also a foreign key in SALES1. A foreign key is an attribute that appears as a nonprimary key attribute in one relation (such as SALES1) and as a primary key attribute (or part of a primary key) in another relation. You designate a foreign key by using a dashed underline.

A foreign key must satisfy referential integrity, which specifies that the value of an attribute in one relation depends on the value of the same attribute in another relation. Thus, in Figure 9-9b, the value of Salesperson in each row of table SALES1 is limited only to the current values of Salesperson in the SPERSON table. If some sales do not have to have a salesperson, then it is possible for the value of Salesperson to be null (i.e., have no value). Referential integrity is one of the most important principles of the relational model.

TRANSFORMING E-R DIAGRAMS INTO RELATIONS Normalization produces a set of well-structured relations that contains all of the data mentioned in system inputs and outputs developed in human interface design. Because these specific information requirements may not represent all future information needs, the E-R diagram you developed in conceptual data modeling is another source of insight into possible data requirements for a new application system. To compare the

Foreign key An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation.

Referential integrity A rule that states that either each foreign key value must match a primary key value in another relation or the foreign key value must be null (i.e., have no value).

Salesperson Region

Smith South Hicks Hernandez East Faulb

West

North

SPERSON

Customer_ID C ustomer_Name Salesperson

8023 Anderson Smith 9167 Bancroft Hicks 7924 Hobbs Smith 6837 Tucker Hernandez 8596 Eckersley Hicks 7018 Arnold Faulb

SALES1

Customer_ID C ustomer_Name Salesperson Region

8023 Anderson Smith South 9167 Bancroft Hicks West 7924 Hobbs Smith South 6837 Tucker Hernandez East 8596 Eckersley Hicks West 7018 Arnold Faulb North

SALES FIGURE 9-9 Removing transitive dependencies (a) Relation with transitive dependency

(b) Relation in 3NF

M09B_VALA1629_09_GE_C09.indd 331 08/04/2020 16:43

332 PART IV DESIGN

conceptual data model and the normalized relations developed so far, your E-R diagram must be transformed into relational notation, normalized, and then merged with the existing normalized relations.

Transforming an E-R diagram into normalized relations and then merging all the relations into one final, consolidated set of relations can be accomplished in four steps. These steps are summarized briefly here, and then steps 1, 2, and 4 are discussed in detail in the remainder of this chapter.

1. Represent entities. Each entity type in the E-R diagram becomes a relation. The identifier of the entity type becomes the primary key of the relation, and other attributes of the entity type become nonprimary key attributes of the relation.

2. Represent relationships. Each relationship in an E-R diagram must be represented in the relational database design. How we represent a relationship depends on its nature. For example, in some cases we represent a relationship by making the primary key of one relation a foreign key of another relation. In other cases, we create a separate relation to represent a relationship.

3. Normalize the relations. The relations created in steps 1 and 2 may have unnec- essary redundancy. So we need to normalize these relations to make them well structured.

4. Merge the relations. So far in database design we have created various relations from both a bottom-up normalization of user views and from transforming one or more E-R diagrams into sets of relations. Across these different sets of relations, there may be redundant relations (two or more relations that describe the same entity type) that must be merged and renormalized to remove the redundancy.

Represent Entities

Each regular entity type in an E-R diagram is transformed into a relation. The identi- fier of the entity type becomes the primary key of the corresponding relation. Each nonkey attribute of the entity type becomes a nonkey attribute of the relation. You should check to make sure that the primary key satisfies the following two properties:

1. The value of the key must uniquely identify every row in the relation. 2. The key should be nonredundant; that is, no attribute in the key can be deleted

without destroying its unique identification.

Some entities may have keys that include the primary keys of other entities. For example, an EMPLOYEE DEPENDENT may have a Name for each dependent, but to form the primary key for this entity, you must include the Employee_ID attribute from the associated EMPLOYEE entity. Such an entity whose primary key depends upon the primary key of another entity is called a weak entity.

Representation of an entity as a relation is straightforward. Figure 9-10a shows the CUSTOMER entity type for PVF. The corresponding CUSTOMER relation is rep- resented as follows:

CUSTOMER(Customer_ID,Name,Address,City_State_ZIP,Discount)

In this notation, the entity type label is translated into a relation name. The identifier of the entity type is listed first and underlined. All nonkey attributes are listed after the primary key. This relation is shown as a table with sample data in Figure 9-10b.

Represent Relationships

The procedure for representing relationships depends on both the degree of the relationship—unary, binary, ternary—and the cardinalities of the relationship.

M09B_VALA1629_09_GE_C09.indd 332 08/04/2020 16:43

CHAPTER 9 Designing Databases 333

Binary 1:N and 1:1 Relationships A binary one-to-many (1:N) relationship in an E-R diagram is represented by adding the primary key attribute (or attributes) of the entity on the one side of the relationship as a foreign key in the relation that is on the many side of the relationship.

Figure 9-11a, an example of this rule, shows the Places relationship (1:N) link- ing CUSTOMER and ORDER at PVF. Two relations, CUSTOMER and ORDER, were formed from the respective entity types (see Figure 9-11b). Customer_ID, which is the primary key of CUSTOMER (on the one side of the relationship), is added as a foreign key to ORDER (on the many side of the relationship). One special case under this rule was mentioned in the previous section. If the entity on the many side needs the key of the entity on the one side as part of its primary key (this is a so-called weak entity), then this attribute is added, not as a nonkey but as part of the primary key.

For a binary or unary one-to-one (1:1) relationship between two entities A and B (for a unary relationship, A and B would be the same entity type), the relationship can be represented by any of the following choices:

1. Adding the primary key of A as a foreign key of B 2. Adding the primary key of B as a foreign key of A 3. Both of the above

FIGURE 9-10 Transforming an entity type to a relation (a) E-R diagram

CUSTOMER Customer_ID Name Address City_State_Zip Discount

(a)

Customer_ID Name Address City_State_ZIP Discount

1273 Contemporary Designs 123 Oak St. Austin, TX 28384 5% 6390 Casual Corner 18 Hoosier Dr. Bloomington, IN45821 3%

CUSTOMER(b) (b) Relations

FIGURE 9-11 Representing a 1:N relationship (a) E-R diagram

CUSTOMER Customer_ID Name Address City_State_Zip Discount

Places

ORDER Order_Number Order_Date Promised_Date

(a)

Order_Number Order_Date Promised_Date Customer_ID

57194 3/28/2020 6390 63725 3/17/2020 4/01/2020 1273 80149

3/15/2020

3/14/2020 3/24/2020 6390

ORDER

CUSTOMER

Customer_ID Name Address City_State_ZIP Discount

1273 Contemporary Designs 123 Oak St. Austin, TX 28384 5% 6390 Casual Corner 18 Hoosier Dr. Bloomington, IN 45821 3%

(b) (b) Relations

M09B_VALA1629_09_GE_C09.indd 333 08/04/2020 16:43

334 PART IV DESIGN

Binary and Higher-Degree M:N Relationships Suppose that there is a binary many- to-many (M:N) relationship (or associative entity) between two entity types A and B. For such a relationship, we create a separate relation C. The primary key of this relation is a composite key consisting of the primary key for each of the two entities in the relationship. Any nonkey attributes associated with the M:N relationship are included with relation C.

Figure 9-12a, an example of this rule, shows the Requests relationship (M:N) between the entity types ORDER and PRODUCT for PVF. Figure 9-12b shows the three relations (ORDER, ORDER LINE, and PRODUCT) that are formed from the entity types and the Requests relationship. A relation (called ORDER LINE in Figure 9-12b) is created for the Requests relationship. The primary key of ORDER LINE is the combina- tion (Order_Number,Product_ID), which is the respective primary keys of ORDER and PRODUCT. The nonkey attribute Quantity_Ordered also appears in ORDER LINE.

Occasionally, the relation created from an M:N relationship requires a primary key that includes more than just the primary keys from the two related relations. Consider, for example, the following situation:

SHIPMENT Date Amount

CUSTOMER Customer_ID Name

VENDOR Vendor_ID Address

FIGURE 9-12 Representing an M:N relationship (a) E-R diagram

ORDER Order_Number Order_Date Promised_Date

Ordered_Quantity

Requests

PRODUCT Product_ID Description Room City_State_Zip (Other Attributes)

(a)

Order_Number Order_Date Promised_Date

613 84 2/17/2014 3/01/2020 6200 9 2/13/2014 2/27/2020 628 07 2/15/2014 3/01/2020

ORDER

Quantity_ Order_Number Product_ID Ordered

613 84 M128 2 613 84 A261 1

ORDER LINE

(Other Product_ID Description Room Attributes)

M128 Bookcase Study — A261 Wall unit Family — R149 Cabinet Study —

PRODUCT

(b)(b) Relations

M09B_VALA1629_09_GE_C09.indd 334 08/04/2020 16:43

CHAPTER 9 Designing Databases 335

In this case, Date must be part of the key for the SHIPMENT relation to uniquely distinguish each row of the SHIPMENT table, as follows:

SHIPMENT(Customer_ID,Vendor_ID,Date,Amount)

If each shipment has a separate nonintelligent key, say, a shipment number, then Date becomes a nonkey and Customer_ID and Vendor_ID become foreign keys, as follows:

SHIPMENT(Shipment_Number,Customer_ID,Vendor_ID,Date,Amount)

In some cases, there may be a relationship among three or more entities. In such cases, we create a separate relation that has as a primary key the composite of the pri- mary keys of each of the participating entities (plus any necessary additional key ele- ments). This rule is a simple generalization of the rule for a binary M:N relationship.

Unary Relationships To review, a unary relationship is a relationship between the instances of a single entity type, which are also called recursive relationships. Figure 9-13 shows two common examples. Figure 9-13a shows a one-to-many relationship named Manages that associates employees with another employee who is their manager. Figure 9-13b shows a many-to-many relationship that associates certain items with their component items. This relationship is called a bill-of-materials structure.

For a unary 1:N relationship, the entity type (such as EMPLOYEE) is modeled as a relation. The primary key of that relation is the same as for the entity type. Then a foreign key is added to the relation that references the primary key values. A recursive foreign key is a foreign key in a relation that references the primary key values of that same relation. We can represent the relationship in Figure 9-13a as follows:

EMPLOYEE(Emp_ID,Name,Birthdate,Manager_ID)

In this relation, Manager_ID is a recursive foreign key that takes its values from the same set of worker identification numbers as Emp_ID.

For a unary M:N relationship, we model the entity type as one relation. Then we create a separate relation to represent the M:N relationship. The primary key of this new relation is a composite key that consists of two attributes (which need not have the same name) that both take their values from the same primary key. Any attribute

Recursive foreign key A foreign key in a relation that refer- ences the primary key values of that same relation.

FIGURE 9-13 Two unary relationships (a) EMPLOYEE with Manages relationship (1:N) (b) Bill-of-materials structure (M:N)

EMPLOYEE

Emp_ID Name Birthdate Manages

ITEM

Item_Number Name Cost

Contains

Quantity

(b)

(a)

M09B_VALA1629_09_GE_C09.indd 335 08/04/2020 16:43

336 PART IV DESIGN

associated with the relationship (such as Quantity in Figure 9-13b) is included as a nonkey attribute in this new relation. We can express the result for Figure 9-13b as follows:

ITEM(Item_Number,Name,Cost) ITEM-BILL(Item_Number,Component_Number,Quantity)

Summary of Transforming E-R Diagrams to Relations

We have now described how to transform E-R diagrams to relations. Table 9-1 lists the rules discussed in this section for transforming E-R diagrams into equivalent rela- tions. After this transformation, you should check the resulting relations to determine whether they are in third normal form and, if necessary, perform normalization as described earlier in this chapter.

MERGING RELATIONS As part of the logical database design, normalized relations likely have been created from a number of separate E-R diagrams and various user interfaces. Some of the rela- tions may be redundant—they may refer to the same entities. If so, you should merge those relations to remove the redundancy. This section describes merging relations, or view integration, which is the last step in logical database design and prior to physical file and database design.

An Example of Merging Relations

Suppose that modeling a user interface or transforming an E-R diagram results in the following 3NF relation:

EMPLOYEE1(Emp_ID,Name,Address,Phone)

E-R Structure Relational Representation

Regular entity Create a relation with primary key and nonkey attributes. Weak entity Create a relation with a composite primary key (which includes the

primary key of the entity on which this weak entity depends) and nonkey attributes.

Binary or unary 1:1 relationship

Place the primary key of either entity in the relation for the other entity or do this for both entities.

Binary 1:N relationship Place the primary key of the entity on the one side of the relationship as a foreign key in the relation for the entity on the many side.

Binary or unary M:N relationship or associative entity

Create a relation with a composite primary key using the primary keys of the related entities, plus any nonkey attributes associative entity of the relationship or associative entity.

Binary or unary M:N relationship or associative entity with additional key(s)

Create a relation with a composite primary key using the primary keys of the related entities and additional primary key attributes associated with the relationship or associative entity, plus any nonkey attributes of the relationship or associative entity.

Binary or unary M:N relationship or associative entity with its own key

Create a relation with the primary key associated with the relationship or associative entity, plus any nonkey attributes of the relationship or associative entity and the primary keys of the related entities (as foreign key attributes).

Supertype/subtype Create a relation for the superclass, which contains the primary relationship key and all nonkey attributes in common with all subclasses, plus create a separate relation for each subclass with the same primary key (with the same or local name) but with only the nonkey attributes related to that subclass.

TABLE 9-1 E-R Diagrams to Relational Transformation

M09B_VALA1629_09_GE_C09.indd 336 08/04/2020 16:43

CHAPTER 9 Designing Databases 337

Modeling a second user interface might result in the following relation:

EMPLOYEE2(Emp_ID,Name,Address,Jobcode,Number_of_Years)

Because these two relations have the same primary key (Emp_ID) and describe the same entity, they should be merged into one relation. The result of merging the relations is the following relation:

EMPLOYEE(Emp_ID,Name,Address,Phone,Jobcode,Number_of_Years)

Notice that an attribute that appears in both relations (such as Name in this example) appears only once in the merged relation.

View Integration Problems

When integrating relations, you must understand the meaning of the data and be prepared to resolve any problems that may arise in the process. In this section, we describe and illustrate four problems that arise in view integration: synonyms, hom- onyms, dependencies between nonkeys, and class/subclass relationships.

Synonyms In some situations, two or more attributes may have different names but the same meaning, as when they describe the same characteristic of an entity. Such attributes are called synonyms. For example, Emp_ID and Employee_Number may be synonyms.

When merging relations that contain synonyms, you should obtain, if possible, agreement from users on a single standardized name for the attribute and eliminate the other synonym. Another alternative is to choose a third name to replace the syn- onyms. For example, consider the following relations:

STUDENT1(Student_ID,Name) STUDENT2(Matriculation_Number,Name,Address)

In this case, the analyst recognizes that both the Student_ID and the Matricu- lation_Number are synonyms for a person’s social security number (SSN) and are identical attributes. One possible resolution would be to standardize one of the two attribute names, such as Student_ID. Another option is to use a new attribute name, such as SSN, to replace both synonyms. With the latter approach, merging the two relations would produce the following result:

STUDENT(SSN,Name,Address)

Homonyms In other situations, a single attribute name, called a homonym, may have more than one meaning or describe more than one characteristic. For example, the term account might refer to a bank’s checking account, savings account, loan account, or other type of account; therefore, account refers to different data, depend- ing on how it is used.

You should be on the lookout for homonyms when merging relations. Consider the following example:

STUDENT1(Student_ID,Name,Address) STUDENT2(Student_ID,Name,Phone_Number,Address)

In discussions with users, the systems analyst may discover that the attribute Address in STUDENT1 refers to a student’s campus address, whereas in STUDENT2 the same attribute refers to a student’s home address. To resolve this conflict, we

Synonym Two different names that are used for the same attribute.

Homonym A single attribute name that is used for two or more different attributes.

M09B_VALA1629_09_GE_C09.indd 337 08/04/2020 16:43

338 PART IV DESIGN

would probably need to create new attribute names, and the merged relation would become

STUDENT(Student_ID,Name,Phone_Number,Campus_Address,Permanent_ Address)

Dependencies between Nonkeys When two 3NF relations are merged to form a single relation, dependencies between nonkeys may result. For example, consider the following two relations:

STUDENT1(Student_ID,Major)

STUDENT2(Student_ID,Adviser)

Because STUDENT1 and STUDENT2 have the same primary key, the two rela- tions may be merged:

STUDENT(Student_ID,Major,Adviser)

However, suppose that each major has exactly one adviser. In this case, Adviser is functionally dependent on Major:

Major → Adviser

If this dependency exists, then STUDENT is in 2NF but not 3NF because it con- tains a functional dependency between nonkeys. The analyst can create 3NF relations by creating two relations with Major as a foreign key in STUDENT:

STUDENT(Student_ID,Major)

MAJOR ADVISER(Major,Adviser)

Class/Subclass Class/subclass relationships may be hidden in user views or rela- tions. Suppose that we have the following two hospital relations:

PATIENT1(Patient_ID,Name,Address,Date_Treated)

PATIENT2(Patient_ID,Room_Number)

Initially, it appears that these two relations can be merged into a single PATIENT relation. However, suppose that there are two different types of patients: inpatients and outpatients. PATIENT1 actually contains attributes common to all patients. PATIENT2 contains an attribute (Room_Number) that is a characteristic only of inpatients. In this situation, you should create class/subclass relationships for these entities:

PATIENT(Patient_ID,Name,Address) INPATIENT(Patient_ID,Room_Number) OUTPATIENT(Patient_ID,Date_Treated)

LOGICAL DATABASE DESIGN FOR HOOSIER BURGER Figure 9-14 shows an E-R diagram that has been developed for a new inventory control system at Hoosier Burger. The new system was discussed previously in Chapter 7, where a DFD and decision table (respectively) for the system were created. In this section we show how this E-R model is translated into normalized relations, and how

Hoosier Burger

M09B_VALA1629_09_GE_C09.indd 338 08/04/2020 16:43

CHAPTER 9 Designing Databases 339

to normalize and then merge the relations for a new report with the relations from the E-R model.

In this E-R model, four entities exist independently of other entities: SALE, PRODUCT, INVOICE, and INVENTORY ITEM. Given the attributes shown in Figure 9-14, we can represent these entities in the following four relations:

The entities ITEM SALE and INVOICE ITEM as well as the associative entity RECIPE each have a composite primary key taken from the entities to which they relate, so we can represent these three entities in the following three relations:

ITEM SALE(Receipt_Number,Product_ID,Quantity_Sold) INVOICE ITEM (Vendor_ID,Invoice_Number,Item_Number,Quantity_Added) RECIPE(Product_ID,Item_Number,Quantity_Used)

Because there are no many-to-many, one-to-one, or unary relationships, we have now represented all the entities and relationships from the E-R model. Also, each of the above relations is in 3NF because all attributes are simple, all nonkeys are fully dependent on the whole key, and there are no dependencies between nonkeys in the INVOICE and INVENTORY ITEM relations.

Now suppose that Bob Mellankamp wanted an additional report that was not previously known by the analyst who designed the inventory control system for Hoo- sier Burger. A rough sketch of this new report, listing volume of purchases from each

FIGURE 9-14 Final E-R diagram for Hoosier Burger’s inventory control systemSALE

Receipt_Number Sale_Date

Sells

ITEM SALE Quantity_Sold

Orders

PRODUCT Product_ID Product_Description

INVOICE

Includes

INVOICE ITEM

Received on

INVENTORY ITEM

Invoice_Number Vendor_ID Invoice_Date Paid?

Quantity_Added

Item_Number Item_Description Quantity_in_Stock Type_of_Item Minimum_Order_Quantity

RECIPE Quantity_Used

M09B_VALA1629_09_GE_C09.indd 339 08/04/2020 16:43

340 PART IV DESIGN

vendor by type of item in a given month, appears in Figure 9-15. In this report, the same type of item may appear many times if multiple vendors supply the same type of item.

This report contains data about several relations already known to the analyst, including the following:

• INVOICE(Vendor_ID,Invoice_Number,Invoice_Date): Primary keys and the date are needed to select invoices in the specified month of the report.

• INVENTORY ITEM(Item_Number,Type_of_Item): Primary key and a nonkey in the report.

• INVOICE ITEM (Vendor_ID,Invoice_Number,Item_Number,Quantity_Added): Primary keys and the raw quantity of items invoiced that are subtotaled by ven- dor and type of item in the report.

In addition, the report includes a new attribute—Vendor_Name. After some investigation, an analyst determines that Vendor_ID → Vendor_Name. The whole primary key of the INVOICE relation is Vendor_ID and Invoice_Number, so if Ven- dor_Name were part of the INVOICE relation, this relation would violate the 3NF rule. Thus, a new VENDOR relation must be created as follows:

VENDOR(Vendor_ID,Vendor_Name)

Now, Vendor_ID not only is part of the primary key of INVOICE but also is a foreign key referencing the VENDOR relation. Hence, there must be a one-to-many relationship from VENDOR to INVOICE. The systems analyst determines that an invoice must come from a vendor, and there is no need to keep data about a vendor unless the vendor invoices Hoosier Burger. An updated E-R diagram, reflecting these enhancements for new data needed in the monthly vendor load report, appears in Figure 9-16. The normalized relations for this database are as follows:

SALE(Receipt_Number,Sale_Date) PRODUCT(Product_ID,Product_Description) INVOICE(Vendor_ID,Invoice_Number,Invoice_Date,Paid?) INVENTORY ITEM(Item_Number,Item_Description,Quantity_in_ Stock,Minimum_Order_Quantity,Type_of_Item) ITEM SALE(Receipt_Number,Product_ID,Quantity_Sold) INVOICE ITEM(Vendor_ID,Invoice_Number,Item_Number,Quantity_Added) RECIPE(Product_ID,Item_Number,Quantity_Used) VENDOR(Vendor_ID,Vendor_Name)

FIGURE 9-15 Hoosier Burger Monthly Vendor Load Report

Vendor

ID Name Type of Item Total Quantity Added

V1 V1name aaa nnn1 bbb nnn2 ccc nnn3

V2 V2name bbb nnn4 mmm nnn5

x x x

Monthly Vendor Load Report Page x ofn for Month: xxxxx

M09B_VALA1629_09_GE_C09.indd 340 08/04/2020 16:43

CHAPTER 9 Designing Databases 341

PHYSICAL FILE AND DATABASE DESIGN Designing physical files and databases requires certain information that should have been collected and produced during prior SDLC phases. This information includes the following:

• Normalized relations, including volume estimates • Definitions of each attribute • Descriptions of where and when data are used: entered, retrieved, deleted, and

updated (including frequencies) • Expectations or requirements for response time and data integrity • Descriptions of the technologies used for implementing the files and database

so that the range of required decisions and choices for each is known

Normalized relations are, of course, the result of logical database design. Statis- tics on the number of rows in each table as well as the other information listed above may have been collected during requirements determination in systems analysis. If not, these items need to be discovered to proceed with database design.

We take a bottom-up approach to reviewing physical file and database design. Thus, we begin the physical design phase by addressing the design of physical fields for each attribute in a logical data model.

Designing Fields

A field is the smallest unit of application data recognized by system software, such as a programming language or database management system. An attribute from a logical database model may be represented by several fields. For example, a student name attribute in a normalized student relation might be represented as three fields: last name, first name, and middle initial. In general, you will represent each attribute from each normalized relation as one or more fields. The basic decisions you must make

Field The smallest unit of named application data recognized by system software.

FIGURE 9-16 E-R diagram corresponding to normal- ized relations of Hoosier Burger’s inven- tory control system

VENDOR Vendor_ID Vendor_Name

SALE Receipt_Number Sale_Date

Sells

ITEM SALE Quantity_Sold

Orders

PRODUCT Product_ID Product_Description

INVOICE

Includes

INVOICE ITEM

Received on

INVENTORY ITEM

Invoice_Number Vendor_ID Invoice_Date Paid?

Quantity_Added

Item_Number Item_Description Quantity_in_Stock Type_of_Item Minimum_Order_Quantity

RECIPE Quantity_Used

M09B_VALA1629_09_GE_C09.indd 341 08/04/2020 16:43

342 PART IV DESIGN

in specifying each field concern the type of data (or storage type) used to represent the field and data integrity controls for the field.

Choosing Data Types

A data type is a coding scheme recognized by system software for representing organizational data. The bit pattern of the coding scheme is usually immaterial to you, but the space to store data and the speed required to access data are of consequence in the physical file and database design. The specific file or database management software you use with your system will dictate which choices are avail- able to you. For example, Table 9-2 lists the most commonly used data types avail- able in Oracle 10g.

Selecting a data type balances four objectives that will vary in degree of impor- tance depending on the application:

1. Minimize storage space 2. Represent all possible values of the field 3. Improve data integrity for the field 4. Support all data manipulations desired on the field

You want to choose a data type for a field that minimizes space, represents every possible legitimate value for the associated attribute, and allows the data to be manipu- lated as needed. For example, suppose a quantity sold field can be represented by a Number data type. You would select a length for this field that would handle the maximum value, plus some room for growth of the business. Further, the Number data type will restrict users from entering inappropriate values (text), but it does allow negative numbers (if this is a problem, application code or form design may be required to restrict the values to positive ones).

Be careful—the data type must be suitable for the life of the application; other- wise, maintenance will be required. Choose data types for future needs by anticipat- ing growth. Also, be careful that date arithmetic can be done so that dates can be subtracted or time periods can be added to or subtracted from a date.

Several other capabilities of data types may be available with some database technologies. We discuss a few of the most common of these features next: calculated fields and coding and compression techniques.

Data type A coding scheme recognized by system software for representing organizational data.

Data Type Description

VARCHAR2 Variable-length character data with a maximum length of 4,000 characters; you must enter a maximum field length (e.g., VARCHAR2(30) for a field with a maximum length of 30 characters). A value less than 30 characters will consume only the required space.

CHAR Fixed-length character data with a maximum length of 255 characters; default length is 1 character (e.g., CHAR(5) for a field with a fixed length of five characters, capable of holding a value from 0 to 5 characters long).

LONG Capable of storing up to two gigabytes of one variable-length character data field (e.g., to hold a medical instruction or a customer comment).

NUMBER Positive and negative numbers in the range 10–130 to 10126; can specify the precision (total number of digits to the left and right of the decimal point) and the scale (the number of digits to the right of the decimal point) (e.g., NUMBER(5) specifies an integer field with a maximum of 5 digits and NUM- BER(5, 2) specifies a field with no more than five digits and exactly two dig- its to the right of the decimal point).

DATE Any date from January 1, 4712 BC to December 31, 4712 AD; date stores the century, year, month, day, hour, minute, and second.

BLOB Binary large object, capable of storing up to four gigabytes of binary data (e.g., a photograph or sound clip).

TABLE 9-2 Commonly Used Data Types in Oracle 10g

M09B_VALA1629_09_GE_C09.indd 342 08/04/2020 16:43

CHAPTER 9 Designing Databases 343

Calculated Fields It is common for an attribute to be mathematically related to other data. For example, an invoice may include a total due field, which represents the sum of the amount due on each item on the invoice. A field that can be derived from other database fields is called a calculated field (or a computed field or a derived field). Recall that a functional dependency between attributes does not imply a cal- culated field. Some database technologies allow you to explicitly define calculated fields along with other raw data fields. If you specify a field as calculated, you would then usually be prompted to enter the formula for the calculation; the formula can involve other fields from the same record and possibly fields from records in related files. The database technology will either store the calculated value or compute it when requested.

Coding and Compression Techniques Some attributes have very few values from a large range of possible values. For example, suppose that each product from PVF has a finish attribute, with possible values of Birch, Walnut, Oak, and so forth. To store this attribute as text might require 12, 15, or even 20 bytes to represent the longest finish value. Suppose that even a liberal estimate is that PVF will never have more than 25 finishes. Thus, a single alphabetic or alphanumeric character would be more than sufficient. We not only reduce storage space but also increase integrity (by restricting input to only a few values), which helps to achieve two of the physical file and database design goals. Codes also have disadvantages. If used in system inputs and outputs, they can be more difficult for users to remember, and programs must be written to decode fields if codes will not be displayed.

Controlling Data Integrity

Accurate data are essential for compliance with new national and international reg- ulations, such as Sarbanes-Oxley (SOX) and Basel II. COBIT (Control Objectives for Information and Related Technologies) and ITIL (IT Infrastructure Library) provide standards, guidelines, and rules for corporate governance, risk assessment, security, and controls of data. These preventive controls are best and consistently applied if designed into the database and enforced by the database management system (DBMS). Data integrity controls can be viewed very positively during audits for compliance with regulations. These controls are only as good as the underlying field data controls.

We have already explained that data typing helps control data integrity by lim- iting the possible range of values for a field. There are additional physical file and database design options you might use to ensure higher-quality data. Although these controls can be imposed within application programs, it is better to include these as part of the file and database definitions so that the controls are guaranteed to be applied all the time as well as uniformly for all programs. There are four popular data integrity control methods: default value, range control, referential integrity, and null value control.

• Default value. A default value is the value a field will assume unless an explicit value is entered for the field. For example, the city and state of most customers for a particular retail store will likely be the same as the store’s city and state. Assigning a default value to a field can reduce data entry time (the field can simply be skipped during data entry) and data entry errors, such as typing IM instead of IN for Indiana.

• Range control. Both numeric and alphabetic data may have a limited set of per- missible values. For example, a field for the number of product units sold may have a lower bound of zero, and a field that represents the month of a product sale may be limited to the values JAN, FEB, and so forth.

• Referential integrity. As noted earlier in this chapter, the most common example of referential integrity is cross-referencing between relations. For example,

Calculated field A field that can be derived from other database fields. Also known as a com- puted field or a derived field.

Default value A value a field will assume unless an explicit value is entered for that field.

M09B_VALA1629_09_GE_C09.indd 343 08/04/2020 16:43

344 PART IV DESIGN

consider the pair of relations in Figure 9-17a. In this case, the values for the foreign key Customer_ID field within a customer order must be limited to the set of Customer_ID values from the CUSTOMER relation; we would not want to accept an order for a nonexisting or unknown customer. Referential integrity may be useful in other instances. Consider the employee relation example in Figure 9-17b. In this example, the EMPLOYEE relation has a field of Supervi- sor_ID. This field refers to the Employee_ID of the employee’s supervisor and should have referential integrity on the Employee_ID field within the same relation. Note in this case that the value of a Supervisor_ID field may be empty because some employees do not have supervisors; therefore, this is a weak refer- ential integrity constraint.

• Null value control. A null value is a special field value, distinct from a zero, blank, or any other value, that indicates that the value for the field is missing or oth- erwise unknown. It is not uncommon that when it is time to enter data—for example, a new customer—you might not know the customer’s phone number. The question is whether a customer, to be valid, must have a value for this field. The answer for this field is probably no, initially, because most data process- ing can continue without knowing the customer’s phone number. Later, a null value may not be allowed when you are ready to ship a product to the customer. On the other hand, you must always know a value for the Customer_ID field. Due to referential integrity, you cannot enter any customer orders for this new customer without knowing an existing Customer_ID value, and customer name is essential for visual verification of correct data entry. Besides using a special null value when a field is missing its value, you can also estimate the value, produce a report indicating rows of tables with critical missing values, or deter- mine whether the missing value matters when computing needed information.

Designing Physical Tables

A relational database is a set of related tables (tables are related by foreign keys referencing primary keys). In logical database design, you grouped into a relation those attributes that concern some unifying, normalized business concept, such as a customer, product, or employee. In contrast, a physical table is a named set of rows and columns that specifies the fields in each row of the table. A physical table may or may not correspond to one relation. Whereas normalized relations possess properties of well-structured relations, the design of a physical table has two goals different from those of normalization: efficient use of secondary storage and data processing speed.

The efficient use of secondary storage (disk space) relates to how data are loaded on disks. Disks are physically divided into units (called pages) that can be

Null value A special field value, distinct from zero, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown.

Physical table A named set of rows and columns that specifies the fields in each row of the table.

FIGURE 9-17 Examples of referential integrity field controls (a) Referential integrity between rela- tions (b) Referential integrity within a relation

CUSTOMER (Customer_ID,Cust_Name,Cust_Address, . . .)

CUST_ORDER (Order_ID,Customer_ID,Order_Date, . . .) and Customer_ID may not be null because every order must be for some existing customer

EMPLOYEE(Employee_I D,Supervisor_ID,Empl_Name, . . .) and Superviosr_ID may be null because not all employees have supervisors

M09B_VALA1629_09_GE_C09.indd 344 08/04/2020 16:43

CHAPTER 9 Designing Databases 345

read or written in one machine operation. Space is used efficiently when the physi- cal length of a table row divides close to evenly into the length of the storage unit. For many information systems, this even division is very difficult to achieve because it depends on factors, such as operating system parameters, outside the control of each database. Consequently, we do not discuss this factor of physical table design in this text.

A second and often more important consideration when selecting a physical table design is efficient data processing. Data are most efficiently processed when they are stored close to one another in secondary memory, thus minimizing the number of input/output (I/O) operations that must be performed. Typically, the data in one physical table (all the rows and fields in those rows) are stored close together on disk. Denormalization is the process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields. In Figure 9-18a, a normalized product relation is split into separate physical tables, each containing only engineer- ing, accounting, or marketing product data; the primary key must be included in each table. Note that the Description and Color attributes are repeated in both the engineering and marketing tables because these attributes relate to both kinds of data. In Figure 9-18b, a customer relation is denormalized by putting rows from different geographic regions into separate tables. In both cases, the goal is to create tables that contain only the data used together in programs. By placing data used together close to one another on disk, the number of disk I/O operations to retrieve all the data needed by a program is minimized.

The capability to split a table into separate sections, often called partitioning, is possible with most relational database products. With Oracle, there are three types of table partitioning:

1. Range partitioning. Partitions are defined by nonoverlapping ranges of values for a specified attribute (so separate tables are formed of the rows whose specified attribute values fall in indicated ranges).

2. Hash partitioning. A table row is assigned to a partition by an algorithm and then maps the specified attribute value to a partition.

3. Composite partitioning. Combines range and hash partitioning by first segregating data by ranges on the designated attribute, and then within each of these parti- tions, it further partitions by hashing on the designated attribute.

Each partition is stored in a separate contiguous section of disk space, which Oracle calls a tablespace.

Denormalization can increase the chance of errors and inconsistencies that normalization avoided. Further, denormalization optimizes certain data process- ing activities at the expense of others, so if the frequencies of different processing activities change, the benefits of denormalization may no longer exist (Hoffer et al., 2016).

Various forms of denormalization, which involves combining data from several normalized tables, can be done, but there are no hard-and-fast rules for deciding when to denormalize data. Here are three common situations (Microsoft, 2015) in which denormalization across tables often makes accessing related data faster (see Figure 9-19 for illustrations):

1. Two entities with a one-to-one relationship. Figure 9-19a shows student data with optional data from a standard scholarship application that a student may com- plete. In this case, one record could be formed with four fields from the STU- DENT and SCHOLARSHIP APPLICATION FORM normalized relations. (Note: In this case, fields from the optional entity must have null values allowed.)

2. A many-to-many relationship (associative entity) with nonkey attributes. Figure 9-19b shows price quotes for different items from different vendors. In this case, fields from ITEM and PRICE QUOTE relations might be combined into one physi- cal table to avoid having to combine all three tables together. (Note: This may

Denormalization The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields.

M09B_VALA1629_09_GE_C09.indd 345 08/04/2020 16:43

346 PART IV DESIGN

FIGURE 9-18 Examples of denormalization (a) Denormalization by columns (b) Denormalization by rows

Normalized Product Relation Product(Product_ID,Description,Drawing_Number,Weight,Color,Unit_Cost,

Burden_Rate,Price,Product_Manager)

Denormalized Functional Area Product Relations for Tables Engineering: E_Product(Product_ID,Description,Drawing_Number,Weight,Color) Accounting: A_Product(Product_ID,Unit_Cost,Burden_Rate) Marketing: M_Product(Product_ID,Description,Color,Price,Product_Manager)

Customer_ID Name Region Annual_Sales

1256 Rogers Atlantic 10,000

2566 Bailey Atlantic 12,000

A_CUSTOMER

Customer_ID Name Region Annual_Sales

1256 Rogers Atlantic 10,000

1323 Temple Pacific 20,000

1455 Gates South 15,000

1626 Hope Pacific 22,000

2433 Bates South 14,000

2566 Bailey Atlantic 12,000

CUSTOMER Normalized Customer Table

Denormalized Regional Customer Tables

Customer_ID Name Region Annual_Sales

1323 Temple Pacific 20,000

1626 Hope Pacific 22,000

P_CUSTOMER

Customer_ID Name Region Annual_Sales

1455 Gates South 15,000

2433 Bates South 14,000

S_CUSTOMER

create considerable duplication of data—in the example, the ITEM fields, such as Description, would repeat for each price quote—and excessive updating if dupli- cated data change.)

3. Reference data. Figure 9-19c shows that several ITEMs have the same STORAGE INSTRUCTIONS and that STORAGE INSTRUCTIONS relate only to ITEMs. In this case, the storage instruction data could be stored in the ITEM table, thus reducing the number of tables to access but also creating redundancy and the potential for extra data maintenance.

M09B_VALA1629_09_GE_C09.indd 346 08/04/2020 16:43

CHAPTER 9 Designing Databases 347

Arranging Table Rows

The result of denormalization is the definition of one or more physical files. A com- puter operating system stores data in a physical file, which is a named set of table rows stored in a contiguous section of secondary memory. A file contains rows and columns from one or more tables, as produced from denormalization. To the operating system (e.g., Windows, Linux, or UNIX), each table may be one file or the whole database may be in one file, depending on how the database technology and database designer organize data. The way the operating system arranges table rows in a file is called a

Physical file A named set of table rows stored in a contiguous section of secondary memory.

FIGURE 9-19 Possible denormalization situations (a) Two entities with a one-to-one relationship

Normalized relations: STUDENT(Student_ID,Campus_Address,Application_ID) APPLICATION(Application_ID,Application_Date,Qualifications,Student_ID)

Denormalized relation: STUDENT(Student_ID,Campus_Address,Application_Date,Qualifications) and Application_Date and Qualifications may be null

(Note: We assume Application_ID is not necessary when all fields are stored in one record, but this field can be included if it is required application data.)

STUDENT Student_ID Campus_Address

SCHOLARSHIP APPLICATION FORM Application_ID Application_Date Qualifications

Submits

(a)

Normalized relations: VENDOR(Vendor_ID,Address,Contact_Name) ITEM(Item_ID,Description) PRICE QUOTE(Vendor_ID,Item_ID,Price)

Denormalized relations: VENDOR(Vendor_ID,Address,Contact_Name) ITEM-QUOTE(Vendor_ID,Item_ID,Description,Price)

VENDOR

Vendor_ID Address Contact_Name

ITEM

Item_ID Description

PRICE QUOTE Price

(b)

Normalized relations: STORAGE(Instr_ID,Where_Store,Container_Type) ITEM(Item_ID,Description,Instr_ID)

Denormalized relation ITEM(Item_ID,Description,Where_Store,Container_Type)

STORAGE INSTRUCTIONS Instr_ID Where_Store Container_Type

Control for

ITEM Item_ID Description

(c)

(b) A many-to-many relationship with nonkey attributes

M09B_VALA1629_09_GE_C09.indd 347 08/04/2020 16:43

348 PART IV DESIGN

file organization. With some database technologies, the systems designer can choose from among several organizations for a file.

If the database designer has a choice, he or she chooses a file organization for a specific file that will provide the following:

1. Fast data retrieval 2. High throughput for processing transactions 3. Efficient use of storage space 4. Protection from failures or data loss 5. Minimal need for reorganization 6. Accommodation of growth 7. Security from unauthorized use

Often these objectives conflict, and you must select an organization for each file that provides a reasonable balance among the criteria within the resources available.

To achieve these objectives, many file organizations use a pointer. A pointer is a field of data that can be used to locate a related field or row of data. In most cases, a pointer contains the address of the associated data, which has no business meaning. Pointers are used in file organizations when it is not possible to store related data next to each other. Because this is often the case, pointers are common. In most cases, for- tunately, pointers are hidden from a programmer. Because a database designer may need to decide if and how to use pointers, however, we introduce the concept here.

Literally hundreds of different file organizations and variations have been cre- ated, but we outline the basics of three families of file organizations used in most file management environments: sequential, indexed, and hashed, as illustrated in Figure 9-20. You need to understand the particular variations of each method available in the environment for which you are designing files.

Sequential File Organizations In a sequential file organization, the rows in the file are stored in sequence according to a primary key value (see Figure 9-20a). To locate a particular row, a program must normally scan the file from the begin- ning until the desired row is located. A common example of a sequential file is the alphabetic list of persons in the white pages of a phone directory (ignoring any index that may be included with the directory). Sequential files are very fast if you want to process rows sequentially, but they are impractical for random row retrievals. Deleting rows can cause wasted space or the need to compress the file. Adding rows requires rewriting the file, at least from the point of insertion. Updating a row may also require rewriting the file, unless the file organization supports rewriting over the updated row only. Only one sequence can be maintained without duplicating the rows.

Indexed File Organizations In an indexed file organization, the rows are stored either sequentially or nonsequentially, and an index is created that allows the appli- cation software to locate individual rows (see Figure 9-20b). Like a card catalog in a library, an index is a structure that is used to determine the rows in a file that satisfy some condition. Each entry matches a key value with one or more rows. An index can point to unique rows (a primary key index, such as on the Product_ID field of a product table) or potentially to more than one row. An index that allows each entry to point to more than one record is called a secondary key index. Secondary key indexes are important for supporting many reporting requirements and for provid- ing rapid ad hoc data retrieval. An example would be an index on the Finish field of a product table.

One of the most powerful capabilities of indexed file organizations is the abil- ity to create multiple indexes, similar to the title, author, and subject indexes in a library. Search results from the multiple indexes can be combined very quickly to find those records with precisely the combination of values sought. The example in Figure 9-20b, typical of many index structures, illustrates that indexes can be built

File organization A technique for physically arranging the records of a file.

Pointer A field of data that can be used to locate a related field or row of data.

Sequential file organization A file organization in which rows in a file are stored in sequence according to a primary key value.

Indexed file organization A file organization in which rows are stored either sequentially or nonsequen- tially, and an index is created that allows software to locate individual rows.

Index A table used to determine the loca- tion of rows in a file that satisfy some condition.

Secondary key One or a combination of fields for which more than one row may have the same combination of values.

M09B_VALA1629_09_GE_C09.indd 348 08/04/2020 16:43

CHAPTER 9 Designing Databases 349

FIGURE 9-20 Comparison of file organizations (a) Sequential

Start of file

Scan

...

Aces

Boilermakers

Devils

Flyers

Hawkeyes

Hoosiers

Miners

Panthers

Seminoles

(a)

Key

(Hoosiers)

B D F H L P

F P Z

R S Z

Miners

Panthers

Seminoles

Devils

Aces

Boilermakers

Flyers

Hawkeyes

Hoosiers

(b)

Relative Record Number

...

Miners

Hawkeyes

Aces

Hoosiers

Seminoles

Devils

Flyers

Panthers

Boilermakers

Hashing Algorithm

Key

(Hoosiers)(c)

(b) Indexed

M09B_VALA1629_09_GE_C09.indd 349 08/04/2020 16:43

350 PART IV DESIGN

on top of indexes, creating a hierarchical set of indexes, and the data are stored sequentially in many contiguous segments. For example, to find the record with key “Hoosiers,” the file organization would start at the top index and take the pointer after the entry P, which points to another index for all keys that begin with the letters G through P in the alphabet. Then the software would follow the pointer after the H in this index, which represents all those records with keys that begin with the letters G through H. Eventually, the search through the indexes either locates the desired record or indicates that no such record exists. The reason for storing the data in many contiguous segments is to allow room for some new data to be inserted in sequence without rearranging all the data.

The main disadvantages to indexed file organizations are the extra space required to store the indexes and the extra time necessary to access and maintain indexes. Usually these disadvantages are more than offset by the advantages. Because the index is kept in sequential order, both random processing and sequential pro- cessing are practical. Also, because the index is separate from the data, you can build multiple index structures on the same data file ( just as in the library, where there are multiple indexes on author, title, subject, and so forth). With multiple indexes, software may rapidly find records that have compound conditions, such as records of books by Tom Clancy on espionage.

The decision of which indexes to create is probably the most important physical database design task for relational database technology, such as Microsoft Access, Oracle, DB2, and similar systems. Indexes can be created for both primary and secondary keys. When using indexes, there is a trade-off between improved per- formance for retrievals and degrading performance for inserting, deleting, and updating the rows in a file. Thus, indexes should be used generously for databases intended primarily to support data retrievals, such as for decision support applica- tions. Because they impose additional overhead, indexes should be used judiciously for databases that support transaction processing and other applications with heavy updating requirements.

Here are some guidelines for choosing indexes for relational databases (Gibson, Hughes, & Remington, 1989):

1. Specify a unique index for the primary key of each table (file). This selection ensures the uniqueness of primary key values and speeds retrieval based on those values. Random retrieval based on primary key value is common for answering multitable queries and for simple data maintenance tasks.

2. Specify an index for foreign keys. As in the first guideline, this speeds processing of multitable queries.

3. Specify an index for nonkey fields that are referenced in qualification and sorting commands for the purpose of retrieving data.

To illustrate the use of these rules, consider the following relations for PVF: PRODUCT(Product_Number,Description,Finish,Room,Price) ORDER(Order_ Number,Product_Number,Quantity)

You would normally specify a unique index for each primary key: Product_Num- ber in PRODUCT and Order_Number in ORDER. Other indexes would be assigned based on how the data are used. For example, suppose that there is a system module that requires PRODUCT and PRODUCT_ORDER data for products with a price below $500, ordered by Product_Number. To speed up this retrieval, you could consider specifying indexes on the following nonkey attributes:

1. Price in PRODUCT because it satisfies rule 3 2. Product_Number in ORDER because it satisfies rule 2

Because users may direct a potentially large number of different queries to the database, and especially for a system with a lot of ad hoc queries, you will probably have to be selective in specifying indexes to support the most common or frequently

M09B_VALA1629_09_GE_C09.indd 350 08/04/2020 16:43

CHAPTER 9 Designing Databases 351

used queries. See Hoffer et al. (2016) for a more thorough discussion of factors and rules of thumb for selecting indexes.

Hashed File Organizations In a hashed file organization, the location of each row is determined using an algorithm (see Figure 9-20c) that converts a primary key value into a row address. Although there are several variations of hashed files, in most cases the rows are located nonsequentially as dictated by the hashing algo- rithm. Thus, sequential data processing is impractical. On the other hand, retrieval of random rows is very fast. There are issues in the design of hashing file organiza- tions, such as how to handle two primary keys that translate into the same address, but again, these issues are beyond our scope (see Hoffer et al. [2016] for a thorough discussion).

Summary of File Organizations The three families of file organizations— sequential, indexed, and hashed—cover most of the file organizations you will have at your disposal as you design physical files and databases. Table 9-3 summarizes the comparative features of these file organizations. You can use this table to help choose a file organization by matching the file characteristics and file processing requirements with the features of the file organization.

Designing Controls for Files

Two of the goals of physical table design mentioned earlier are protection from fail- ures or data loss and security from unauthorized use. These goals are achieved primar- ily by implementing controls on each file. Data integrity controls, a primary type of control, were mentioned earlier in this chapter. Two other important types of controls address file backup and security.

It is almost inevitable that a file will be damaged or lost, due to either software or human errors. When a file is damaged, it must be restored to an accurate and reasonably current condition. A file and database designer has several techniques for file restoration, including

• periodically making a backup copy of a file, • storing a copy of each change to a file in a transaction log or audit trail, or • storing a copy of each row before or after it is changed.

Hashed file organization A file organization in which the address of each row is determined using an algorithm.

Factor

File Organization

Sequential Indexed Hashed

Storage space No wasted space No wasted space for data, but extra space for index

Extra space may be needed to allow for addition and deletion of records

Sequential retrieval on primary key

Very fast Moderately fast Impractical

Random retrieval on primary key

Impractical Moderately fast Very fast

Multiple key retrieval Possible, but requires scanning whole file

Very fast with multiple indexes Not possible

Deleting rows Can create wasted space or require reorganizing

If space can be dynamically allo- cated, this is easy, but requires maintenance of indexes

Very easy

Adding rows Requires rewriting file If space can be dynamically allo- cated, this is easy, but requires maintenance of indexes

Very easy, except multiple keys with same address require extra work

Updating rows Usually requires rewrit- ing file

Easy, but requires maintenance of indexes

Very easy

TABLE 9-3 Comparative Features of Sequential, Indexed, and Hashed File Organizations

M09B_VALA1629_09_GE_C09.indd 351 08/04/2020 16:43

352 PART IV DESIGN

For example, a backup copy of a file and a log of rows after they were changed can be used to reconstruct a file from a previous state (the backup copy) to its cur- rent values. This process would be necessary if the current file were so damaged that it could not be used. If the current file is operational but inaccurate, then a log of before images of rows can be used in reverse order to restore a file to an accurate but previous condition. Then a log of the transactions can be reapplied to the restored file to bring it up to current values. It is important that the information system designer make provisions for backup, audit trail, and row image files so that data files can be rebuilt when errors and damage occur.

An information system designer can build data security into a file by several means, including the following:

• Coding, or encrypting, the data in the file so that they cannot be read unless the reader knows how to decrypt the stored values.

• Requiring data file users to identify themselves by entering user names and pass- words, and then possibly allowing only certain file activities (read, add, delete, change) for selected users to selected data in the file.

• Prohibiting users from directly manipulating any data in the file, but rather force programs and users to work with a copy (real or virtual) of the data they need; the copy contains only the data that users or programs are allowed to manipulate, and the original version of the data will change only after changes to the copy are thoroughly checked for validity.

Security procedures such as these all add overhead to an information system, so only necessary controls should be included.

PHYSICAL DATABASE DESIGN FOR HOOSIER BURGER A set of normalized relations and an associated E-R diagram for Hoosier Burger (Figure 9-16) were presented in the section Logical Database Design for Hoosier Burger earlier in this chapter. The display of a complete design of this database would require more documentation than space permits in this text, so we illustrate in this section only a few key decisions from the complete physical database.

As outlined in this chapter, to translate a logical database design into a physical database design, you need to make the following decisions:

1. Create one or more fields for each attribute and determine a data type for each field.

2. For each field, decide if it is calculated; needs to be coded or compressed; must have a default value or picture; or must have range, referential integrity, or null value controls.

3. For each relation, decide if it should be denormalized to achieve desired process- ing efficiencies.

4. Choose a file organization for each physical file. 5. Select suitable controls for each file and the database.

Remember, the specifications for these decisions are made in physical database design, and then the specifications are coded in the implementation phase using the capabilities of the chosen database technology. These database technology capa- bilities determine what physical database design decisions you need to make. For example, for Oracle, which we assume is the implementation environment for this illustration, the only choice for file organization is indexed, so the file organization decision becomes which primary and secondary key attributes should be used to build indexes.

We illustrate these physical database design decisions only for the INVOICE table. The first decision most likely would be whether to denormalize this table. Based

Hoosier Burger

M09B_VALA1629_09_GE_C09.indd 352 08/04/2020 16:43

CHAPTER 9 Designing Databases 353

PINE VALLEY FURNITURE

on the suggestions for possible denormalization presented in this chapter, the only possible denormalization of this table would be to combine it with the VENDOR table. Because each invoice must have a vendor, and the only additional data about vendors not in the INVOICE table is the Vendor_Name attribute, this is a good candidate for denormalization. Because Vendor_Name is not very volatile, repeating Vendor_Name in each invoice for the same vendor will not cause excessive update maintenance. If Vendor_ Name is often used with other invoice data when invoice data are displayed, then this would be a good candidate for denormalization. So the denormalized rela- tion to be transformed into a physical table is

INVOICE(Vendor_ID,Invoice_Number,Invoice_Date,Paid?,Vendor_Name)

The next decision can be what indexes to create. The guidelines presented in this chapter suggest creating an index for the primary key, all foreign keys, and secondary keys used for sorting and qualifications in queries. So we create a primary key index on the combined fields Vendor_ID and Invoice_Number. INVOICE has no foreign keys. To determine what fields are used as secondary keys in query sorting and qualification clauses, we would need to know the content of queries. Also, it would be helpful to know query frequency because indexes do not provide much performance efficiency for infrequently run queries. For simplicity, suppose there were only two frequently run queries that reference the INVOICE table, as follows:

1. Display all the data about all unpaid invoices due this week. 2. Display all invoices ordered by vendor, show all unpaid invoices first, then all paid

invoices, and order the invoices of each category in reverse sequence by invoice date.

In the first query, both the Paid? and Invoice_Date fields are used for qualifica- tion. Paid?, however, may not be a good candidate for an index because there are only two values for this field. The systems analyst would need to discover what percentage of invoices on file are unpaid. If this value is more than 10 percent, then an index on Paid? would not likely be helpful. Invoice_Date is a more discriminating field, so an index on this field would be helpful.

In the second query, Vendor_ID, Paid?, and Invoice_Date are used for sort- ing. Vendor_ID and Invoice_Date are discriminating fields (most values occur in less than 10 percent of the rows), so indexes on these fields will be helpful. Assum- ing less than 10 percent of the invoices on file are unpaid, then it would make sense to create the following indexes to make these two queries run as efficiently as possible:

1. Primary key index: Vendor_ID and Invoice_Number 2. Secondary key indexes: Vendor_ID, Invoice_Date, and Paid?

We do not illustrate security and other types of controls because these decisions are very dependent on unique capabilities of the technology and a complex analysis of what data which users have the right to read, modify, add, or delete.

ELECTRONIC COMMERCE APPLICATION: DESIGNING DATABASES Like many other analysis and design activities, designing the database for an Inter- net-based electronic commerce application is no different than the process followed when designing the database for other types of applications. In the last chapter, you read how Jim Woo and the PVF development team designed the human interface for the WebStore. In this section, we examine the processes Jim followed when transforming the conceptual data model for the WebStore into a set of normalized relations.

M09B_VALA1629_09_GE_C09.indd 353 08/04/2020 16:43

354 PART IV DESIGN

Designing Databases for Pine Valley Furniture’s WebStore

The first step Jim took when designing the database for the WebStore was to review the conceptual data model—the E-R diagram—developed during the analysis phase of the SDLC (see Figure 8-22 for a review). Given that there were no associative entities— many-to-many relationships—in the diagram, he began by identifying four distinct entity types, which he named

CUSTOMER, ORDER, INVENTORY, and SHOPPING_CART

Once reacquainted with the conceptual data model, he examined the lists of attributes for each entity. He noted that three types of customers were identified dur- ing conceptual data modeling, namely, corporate customers, home office customers, and student customers. Yet all were referred to simply as a “customer.” Nonetheless, because each type of customer had some unique information (attributes) that other types of customers did not, Jim created three additional entity types, or subtypes, of customers:

CORPORATE HOME_OFFICE STUDENT

Table 9-4 lists the common and unique information about each customer type. As Table 9-4 implies, four separate relations are needed to keep track of customer information without having anomalies. The CUSTOMER relation is used to capture common attributes, whereas the additional relations are used to capture information unique to each distinct customer type. To identify the type of customer within the CUSTOMER relation easily, a Customer_Type attribute is added to the CUSTOMER relation. Thus, the CUSTOMER relation consists of

CUSTOMER(Customer_ID,Address,Phone,E-mail,Customer_Type).

To link the CUSTOMER relation to each of the separate customer types— CORPORATE, HOME_OFFICE, and STUDENT—all share the same primary key,

Common Information About ALL Customer Types

Corporate Customer Home Office Customer Student Customer

Customer ID Customer ID Customer ID Address Address Address Phone Number Phone Number Phone Number E-Mail Address E-Mail Address E-Mail Address

Unique Information About EACH Customer Type

Corporate Customer Home Office Customer Student Customer

Corporate Name Customer Name Customer Name Shipping Method Corporate Name School Buyer Name Fax Number Fax Number

TABLE 9-4 Common and Unique Information about Each Customer Type

M09B_VALA1629_09_GE_C09.indd 354 08/04/2020 16:43

CHAPTER 9 Designing Databases 355

Customer_ID, in addition to the attributes unique to each. This results in the follow- ing relations:

CORPORATE(Customer_ID,Corporate_Name,Shipping_Method,Buyer_ Name,Fax) HOME_OFFICE(Customer_ID,Customer_Name,Corporate_Name,Fax) STUDENT(Customer_ID,Customer_Name,School)

In addition to identifying all the attributes for customers, Jim also identified the attributes for the other entity types. The results of this investigation are sum- marized in Table 9-5. As described in Chapter 8, much of the order-related infor- mation is captured and tracked within PVF’s Purchasing Fulfillment System. This means that the ORDER relation does not need to track all the details of the order because the Purchasing Fulfillment System produces a detailed invoice that contains all order details such as the list of ordered products, materials used, colors, quanti- ties, and other such information. To access this invoice information, a foreign key, Invoice_ID, is included in the ORDER relation. To identify easily which orders belong to a specific customer, the Customer_ID attribute is also included in ORDER. Two additional attributes, Return_Code and Order_Status, are also included in ORDER. The Return_Code is used to track the return of an order more easily—or a product within an order—whereas Order_Status is a code used to represent the state of an order as it moves through the purchasing fulfillment process. This results in the fol- lowing ORDER relation:

ORDER(Order_ID,Invoice_ID,Customer_ID,Return_Code,Order_Status)

In the INVENTORY entity, two attributes—Materials and Colors—could take on multiple values but were represented as single attributes. For example, Materials represents the range of materials that a particular inventory item could be constructed from. Likewise, Colors is used to represent the range of possible product colors. PVF has a long-established set of codes for representing materials and colors; each of these complex attributes is represented as a single attribute. For example, the value “A” in the Colors field represents walnut, dark oak, light oak, and natural pine, whereas the value “B” represents cherry and walnut. Using this coding scheme, PVF can use a single character code to represent numerous combinations of colors. This results in the following INVENTORY relation:

INVENTORY(Inventory_ID,Name,Description,Size,Weight,Materials,Colors, Price,Lead_Time)

Finally, in addition to Cart_ID, each shopping cart contains the Customer_ID and Inventory_ID attributes so that each item in a cart can be linked to a particular

Order Inventory Shopping_Cart

Order_ID (primary key) Inventory_ID (primary key) Cart_ID (primary key) Invoice_ID (foreign key) Name Customer_ID (foreign key) Customer_ID (foreign key) Description Inventory_ID (foreign key) Return_Code Size Material Order_Status Weight Color

Materials Quantity Colors Price Lead_Time

TABLE 9-5 Attributes for Order, Inventory, and Shopping Cart Entities

M09B_VALA1629_09_GE_C09.indd 355 08/04/2020 16:43

356 PART IV DESIGN

inventory item and to a specific customer. In other words, both the Customer_ID and Inventory_ID attributes are foreign keys in the SHOPPING_CART relation. Recall that the SHOPPING_CART is temporary and is kept only while a customer is shopping. When a customer actually places the order, the ORDER relation is created and the line items for the order—the items in the shopping cart—are moved to the Purchase Fulfillment System and stored as part of an invoice. Because we also need to know the selected material, color, and quantity of each item in the SHOPPING_CART, these attributes are included in this relation. This results in the following:

SHOPPING_CART(Cart_ID,Customer_ID,Inventory_ID,Material,Color, Quantity)

Now that Jim has completed the database design for the WebStore, he has shared all the design information with his project team so that the design can be turned into a working database during implementation. We read more about the WebStore’s implementation in the next chapter.

SUMMARY

Databases are defined during the design phase of the sys- tems development life cycle. They are designed usually in parallel with the design of system interfaces. To design a database, a systems analyst must understand the concep- tual database design for the application, usually specified by an E-R diagram, and the data requirements of each sys- tem interface (report, form, screen, etc.). Thus, database design is a combination of top-down (driven by an E-R diagram) and bottom-up (driven by specific information requirements in system interfaces) processes. Besides data requirements, systems analysts must also know physical data characteristics (e.g., length and format), frequency of use of the system interfaces, and the capabilities of database technologies.

An E-R diagram is transformed into normalized rela- tions by following well-defined principles, which are sum- marized in Table 9-1. For example, each entity becomes a relation and each many-to-many relationship or associative entity also becomes a relation. These principles also specify how to add foreign keys to relations to represent one-to- many relationships.

Separate sets of normalized relations are merged (a process called view integration) to create a consolidated logical database design. The different sets of relations come from the conceptual E-R diagram for the applica- tion, known human system interfaces (reports, screens, forms, etc.), and known or anticipated queries for data that meet certain qualifications. The result of merging is a comprehensive, normalized set of relations for the appli- cation. Merging is not simply a mechanical process. A sys- tems analyst must address issues of synonyms, homonyms, and functional dependencies between nonkeys during view integration.

Fields in the physical database design represent the attributes (columns) of relations in the logical database design. Each field must have a data type as well as poten- tially other characteristics such as a coding scheme to sim- plify the storage of business data, a default value, picture (or template) control, range control, referential integrity control, or null value control. A storage format is chosen to balance four objectives: (1) minimize storage space, (2) represent all possible values of the field, (3) improve data integrity for the field, and (4) support all data manipu- lations desired on the field.

Whereas normalized relations possess properties of well-structured relations, the design of a physical table attempts to achieve two goals different from those of nor- malization: efficient use of secondary storage and data processing speed. Efficient use of storage means that the amount of extra (or overhead) information is minimized. Therefore, sequential file organizations are efficient in the use of storage because little or no extra information, besides the meaningful business data, is kept. Data process- ing speed is achieved by storing data close together that are used together and by building extra information in the database, which allows data to be quickly found based on primary or secondary key values or by sequence.

Table 9-3 summarizes the performance characteristics of different types of file organizations. The systems analyst must decide which performance factors are most important for each application and the associated database. These factors are storage space; sequential retrieval speed; ran- dom row retrieval speed; speed of retrieving data based on multiple key qualifications; and the speed to perform data maintenance activities of row deletion, addition, and updating.

M09B_VALA1629_09_GE_C09.indd 356 08/04/2020 16:43

CHAPTER 9 Designing Databases 357

An index is information about the primary or sec- ondary keys of a file. Each index entry contains the key value and a pointer to the row that contains that key value. An index facilitates rapid retrieval to rows for queries that involve AND, OR, and NOT qualifications of keys (e.g., all products with a maple finish and unit cost greater than $500 or all products in the office furniture product line). When using indexes, there is a trade-off between improved performance for retrievals and degrading per- formance for inserting, deleting, and updating the rows

in a file. Thus, indexes should be used generously for databases intended primarily to support data retrievals, such as for decision support applications. Because they impose additional overhead, indexes should be used judi- ciously for databases that support transaction processing and other applications with heavy updating requirements. Typically, you create indexes on a file for its primary key, foreign keys, and other attributes used in qualification and sorting clauses in queries, forms, reports, and other system interfaces.

KEY TERMS

9.1 Calculated field 9.2 Data type 9.3 Default value 9.4 Denormalization 9.5 Field 9.6 File organization 9.7 Foreign key 9.8 Functional dependency 9.9 Hashed file organization 9.10 Homonym

9.11 Index 9.12 Indexed file organization 9.13 Normalization 9.14 Null value 9.15 Physical file 9.16 Physical table 9.17 Pointer 9.18 Primary key 9.19 Recursive foreign key 9.20 Referential integrity

9.21 Relation 9.22 Relational database model 9.23 Second normal form (2NF) 9.24 Secondary key 9.25 Sequential file organization 9.26 Synonym 9.27 Third normal form (3NF) 9.28 Well-structured relation

Match each of the key terms above to the definition that best fits it.

____ A named, two-dimensional table of data. Each relation con- sists of a set of named columns and an arbitrary number of unnamed rows.

____ A relation that contains a minimum amount of redundancy and allows users to insert, modify, and delete the rows with- out errors or inconsistencies.

____ The process of converting complex data structures into sim- ple, stable data structures.

____ A particular relationship between two attributes.

____ A relation for which every nonprimary key attribute is func- tionally dependent on the whole primary key.

____ A relation that is in second normal form and that has no functional (transitive) dependencies between two (or more) nonprimary key attributes.

____ An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation.

____ An integrity constraint specifying that the value (or exis- tence) of an attribute in one relation depends on the value (or existence) of the same attribute in another relation.

____ A foreign key in a relation that references the primary key values of that same relation.

____ Two different names that are used for the same attribute.

____ A single attribute name that is used for two or more differ- ent attributes.

____ The smallest unit of named application data recognized by system software.

____ A coding scheme recognized by system software for repre- senting organizational data.

____ A field that can be derived from other database fields.

____ A value a field will assume unless an explicit value is entered for that field.

____ A special field value, distinct from a zero, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown.

____ A named set of rows and columns that specifies the fields in each row of the table.

____ The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields.

____ A named set of table rows stored in a contiguous section of secondary memory.

____ A technique for physically arranging the records of a file.

____ A field of data that can be used to locate a related field or row of data.

____ The rows in the file are stored in sequence according to a primary key value.

M09B_VALA1629_09_GE_C09.indd 357 08/04/2020 16:43

358 PART IV DESIGN

FIGURE 9-21 E-R diagram for Problem and Exercise 9.45

Priced_at

VENDOR

Vendor_ID Address

PART

Item_Number Description

PRICE QUOTE Quote_Quantity Price

PART RECEIPT Order_Number Date Order_Quantity

____ The rows are stored either sequentially or nonsequentially, and an index is created that allows software to locate indi- vidual rows.

____ A table used to determine the location of rows in a file that satisfy some condition.

____ One or a combination of fields for which more than one row may have the same combination of values.

____ The address for each row is determined using an algorithm.

____ An attribute whose value is unique across all occurrences of a relation.

____ Data represented as a set of related tables or relations.

REVIEW QUESTIONS 9.29 What is the purpose of normalization?

9.30 List five properties of relations.

9.31 What is a relational database model? Why is a relational database model widely used by many enterprises?

9.32 How are relationships between entities represented in the relational data model?

9.33 What is the relationship between the primary key of a rela- tion and the functional dependencies among all attributes within that relation?

9.34 What is a well-structured relation? How can the accuracy of the relation be maintained?

9.35 List and describe two normalization rules that are com- monly used for the normalization process. What is the result of the normalization process?

9.36 Use an example of the Employee entity type to justify how a unary 1:N relationship works.

9.37 List two conditions regulating a relation that is already in first normal form (1NF).

9.38 List and describe the components of a domain using a com- mon attribute, such as Salary, as an example.

9.39 Can the value of an identifier, such as the Emp_ID attribute of an Employee relation, be assigned by a software automati- cally? If yes, what is its characteristic? What is the purpose of assigning a value by the software automatically?

9.40 What are the advantages of assigning a default value to a field?

9.41 How can the efficiency of data processing be improved by using physical table design?

9.42 What are the seven factors that should be considered in selecting a file organization?

PROBLEMS AND EXERCISES 9.43 Assume that, at PVF, products are composed of compo-

nents, products are assigned to salespersons, and compo- nents are produced by vendors. Also assume that, in the relation PRODUCT(Prodname, Salesperson, Compname, Vendor), Vendor is functionally dependent on Compname and Compname is functionally dependent on Prodname. Eliminate the transitive dependency in this relation and form 3NF relations.

9.44 Transform the E-R diagram of Figure 8-23 into a set of 3NF relations. Make up a primary key where needed and one or more nonkey attributes for each entity.

9.45 Consider the E-R diagram of Figure 9-21.

a. Transform this E-R diagram into a set of 3NF relations.

b. State and justify all referential integrity rules for the 3NF relations you created in Problem and Exercise 9.45a.

M09B_VALA1629_09_GE_C09.indd 358 08/04/2020 16:43

CHAPTER 9 Designing Databases 359

9.46 Consider the list of individual 3NF relations below. These relations were developed from several separate normaliza- tion activities.

PATIENT(Patient_ID,Room_Number,Admit_Date,Address) ROOM(Room_Number,Phone,Daily_Rate) PATIENT(Patient_Number,Treatment_Description, Address) TREATMENT(Treatment_ID,Description,Cost) PHYSICIAN(Physician_ID,Name,Department) PHYSICIAN(Physician_ID,Name,Supervisor_ID)

a. Merge these relations into a consolidated set of 3NF rela- tions. State whatever assumptions you consider necessary (including but not limited to foreign keys) to resolve any potential problems you identify in the merging process.

b. Draw an E-R diagram for your answer to Problem and Exercise 9.46a.

9.47 Consider the following 3NF relations about a sorority or fraternity:

MEMBER(Member_ID,Name,Address,Dues_Owed) OFFICE(Office_Name,Officer_ID,Term_Start_Date, Budget) EXPENSE(Ledger_Number,Office_Name,Expense_ Date,Amt_Owed) PAYMENT(Check_Number,Expense_Ledger_Number, Amt_Paid) RECEIPT(Member_ID,Receipt_Date,Dues_Received) COMMITTEE(Committee_ID,Officer_in_Charge) WORKERS(Committee_ID,Member_ID)

a. Foreign keys are not indicated in these relations. Decide which attributes are foreign keys and justify your decisions.

b. Draw an E-R diagram for these relations, using your answer to Problem and Exercise 9.47a.

c. Explain the assumptions you made about cardinalities in your answer to Problem and Exercise 9.47b. Explain why it is said that the E-R data model is more expres- sive or more semantically rich than the relational data model.

9.48 Consider the following functional dependencies:

Applicant_ID → Applicant_Name Applicant_ID → Applicant_Address Position_ID → Position_Title Position_ID → Date_Position_Opens Position_ID → Department Applicant_ID + Position_ID → Date_Applied Applicant_ID + Position_ID → Date_ Interviewed

a. Represent these attributes with 3NF relations. Provide meaningful relation names.

b. Represent these attributes using an E-R diagram. Provide meaningful entity and relationship names.

9.49 Indicate the type of normal form for each of the following relations. If the relation is not in third normal form, decom- pose it into 3NF relations. Convert the 3NF relations into an E-R diagram.

a. OrderDetails(OrderID, ProductID, OrderedAmount) b. Product(ProductID, ProductName, ProductPrice) c. CustOrder(OrderID, OrderDate, CustomerID, Customer-

Name, CustomerAddress, CustomerPhone)

9.50 Refer to Figure 8-4 and answer the following questions:

a. Transform the order details in an ER diagram. b. If the order form can accommodate only three product

items, is it possible to indicate the maximum number in the ER diagram? If yes, how?

c. How many entities are there in the order form? d. Decompose the entities into 3NF relations.

9.51 Suppose you created a file for each relation in your answer to Problem and Exercise 9.45. If the following queries rep- resented the complete set of accesses to this database, sug- gest and justify what primary and secondary key indexes you would build.

a. For each PART in Item_Number order list in Vendor_ID, sequence all the vendors and their associated prices for that part.

b. List all PART RECEIPTS, including related PART fields for all the parts received on a particular day.

c. For a particular VENDOR, list all the PARTS, and their associated prices, that VENDOR can supply.

9.52 Suppose you were designing a default value for the mari- tal status field in a student record at your university. What possible values would you consider and why? How would the default value change depending on other fac- tors, such as type of student (undergraduate, graduate, professional)?

9.53 Consider Figure 9-19b. Explain a query that would likely be processed more quickly using the denormalized relations rather than the normalized relations.

9.54 Consider Figure 9-6.

a. In order to determine course uniqueness, what is the name of the new attribute you will introduce to the rela- tion? What is this attribute?

b. Draw a relational schema and diagram the functional dependencies in the relation after performing item (a).

c. In what normal from is the relation? d. Decompose the relation into a set of 3NF relations. e. Draw a relational schema for your 3NF relations and

show the referential integrity constraints.

FIELD EXERCISES 9.55 Interview a database designer working in a medium-sized

supermarket. Ask them why the company uses sequential file organization to store employee records. Why are the inventory records stored in hashed file organization? Will they consider indexed file organization if there is a choice? Why or why not?

9.56 Contact a database designer in your institute. Ask them what kind of backup procedures they use for copying student data. Why are backup procedures essential? What are the types of file organization available for this procedure? What kind of data storage media is being selected? Why?

M09B_VALA1629_09_GE_C09.indd 359 08/04/2020 16:43

360 PART IV DESIGN

REFERENCES Codd, E. F. (1970). A relational model of data for large relational

databases. Communications of the ACM, 13(6), 77–87. Date, C. J. (2012). Database design and relational theory. Sebastopol,

CA: O’Reilly Media. Elmasri, R., & Navathe, S. B. (2015). Fundamentals of database sys-

tems (6th ed.). Upper Saddle River, NJ: Addison-Wesley. Gibson, M., Hughes, C., & Remington, W. (1989, January). Track-

ing the trade-offs with inverted lists. Database Programming & Design, 2, 28–34.

Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern database man- agement (12th ed.). Upper Saddle River, NJ: Prentice Hall.

Kroenke, D.M., Auer, D.J., Vandenberg, S.L., & Yoder, R.C. (2017). Database concepts (8th Ed.). New York: Pearson.

Microsoft. (2015). Lesson 3: Optimizing the database design by denormalizing. Microsoft Developer Network. Retrieved April 10, 2018 from http://msdn.microsoft.com/en-us/library/ cc505841.aspx.

Umanath, N. S., and Scamell, R. W. (2014). Data modeling and database design. Independence, KY: Cengage Learning.

9.57 Use your own academic report, issued by your institute, as an example. Ask a database administrator how they use normalization steps to transform the details of the report into a set of relations in third normal form. After reaching third normal form, will they continue the normalization process? Why? Draw an E-R diagram to show the relation- ships maintained between entities and the cardinality constrains.

9.58 Use your university library and other Internet resources to investigate the types of database models widely available for

systems development. Which type is more popular? Why are others not used very often for designing new information systems? What is an emerging database model?

9.59 Interview database designers working in a small and a large trading company. Ask them how to start the normalization process. Is there any difference between companies in per- forming the normalization process? If yes, what are they? What are the anomalies caused when system data are updated? What additional steps are required if redundancy is identified?

M09B_VALA1629_09_GE_C09.indd 360 08/04/2020 16:43

http://msdn.microsoft.com/en-us/library/

CHAPTER 9 Designing Databases 361

PETRIE ELECTRONICS

Chapter 9: Designing Databases

Jim Watanabe, assistant director of IT for Petrie Electronics, and the manager of the “No Customer Escapes” customer loyalty system project, was walking down the hall from his office to the cafeteria. It was 4 p.m., but Jim was nowhere close to going home yet. The deadlines he had imposed for the project were fast approaching. His team was running behind, and he had a lot of work to do over the next week to try to get things back on track. He needed to get some coffee for what was going to be a late night.

As Jim approached the cafeteria, he saw Sanjay Agar- wal and Sam Waterston walking toward him. Sanjay was in charge of systems integration for Petrie, and Sam was one of the company’s top interface designers. They were both on the customer loyalty program team. They were having an intense conversation as Jim approached.

“Hi guys,” Jim said. “Oh, hi, Jim,” Sanjay replied. “Glad I ran into you—we

are moving ahead on the preliminary database designs. We’re translating the earlier conceptual designs into physi- cal designs.”

“Who’s working on that? Stephanie?” Jim asked. Stepha- nie Welch worked for Petrie’s database administrator.

“Yes,” Sanjay replied. “But she is supervising a couple of interns who have been assigned to her for this task.”

“So how is that going? Has she approved their work?” “Yeah, I guess so. It all seems to be under control.” “I don’t want to second-guess Stephanie, but I’m curious

about what they’ve done.” “Do you really have time to review interns’ work?” Sanjay

asked. “OK, let me send you the memo Stephanie sent me (PE Figure 9-1).”

PE FIGURE 9-1 Memo on issues related to physical database design for Petrie Electronic’s customer loyalty program

To: Stephanie Welch From: Xin Zhu & Anton Washington Re: Preliminary physical database design for “No Customer Escapes” Date: June 1, 2020

We were charged with converting the conceptual database designs for the customer loyalty system to physical database designs. We started with one of the initial ERDs (see PE Figure 8-1), designed at a very high level. The ERD identified six entities: Customer, Product, Service, Promotion, Transaction, and Coupon. We discovered that all of these entities are already defined in Petrie’s existing systems. The only entity not already defined is Coupon. Product and Service are defined as part of the product database. Promotion is defined as part of the marketing database. Customer and Transaction are defined as part of the core database. However, after considerable consideration, we are not sure if some of these already identified and defined entities are the same as those identified in the preliminary ERD we were given. Specifically, we have questions about Customer, Transaction and Promotion. Customer: The Customer entity is more complex than it appears. There are several ways to think about the instances of this entity. For example, we can divide Customers into those who shop online and those who shop in the brick-and-mortar stores. And there is of course some overlap. The biggest distinction between these two groups is that we know the names of (and other information about) the Customers who shop online, but we may have very little identifying information about those who shop only in the stores. For example, if an individual shops only at a store and pays only with cash, that individual meets the definition of Customer (see PE Table 8-1), but we collect no data on that individual at all. We raise these issues to call attention to the relationship between Customers and members of the customer loyalty program: All members are Customers, but not all Customers are members. We suggest that the entity called Customer in the preliminary ERD be renamed ‘Member,’ as we think that is a better name for this entity. We are prepared to map out the table design when this change is approved. Transaction: Petrie already has a relational table called Transaction, but that applies to all transactions in all stores and online. The customer loyalty program focuses on the transactions of its Members, so the program involves only a subset of Transactions. We suggest that the ERD be redesigned to take this fact into account, and that what is now called Transaction be renamed ‘Member Transaction.’ The relational tables should then be designed accordingly. Promotion: Petrie already has a relational table called Promotion. Again, the customer loyalty program, while having some interest in general promotions, focuses primarily on promotions created specifically for Members of the program. What is called Promotion in the ERD is really a subset of all of Petrie’s promotions. We recommend a name change to ‘Member Promotion’ with the associated relational table design. Finally, for the Coupon entity, which is new, we note from the ERD that Coupon only has one relationship, and that is with Customer. As it is a one-to-many relationship, the PK from Customer will be an FK in Coupon. We recommend the

following table design: COUPON (Coupon ID,Customer ID, Creation Date, Expiration Date, Value)

MEMO

M09B_VALA1629_09_GE_C09.indd 361 08/04/2020 16:43

362 PART IV DESIGN

“You’re right, I don’t have time,” Jim said. “But I’m curi- ous. It won’t take long to read the memo, right?”

“OK, I’ll send it as soon as I get back to my desk.” “OK, thanks.” Jim walked on to the cafeteria, and he

poured himself a big cup of coffee.

Case Questions

9.60 In the questions associated with the Petrie Electronics case at the end of Chapter 8, you were asked to modify the E-R diagram given in PE Figure 8-1 to include any other entities and the attributes you identified from the Petrie cases. Review your answers to these ques- tions, and add any additional needed relations to the document in PE Figure 9-1.

9.61 Study your answer to Case Question 9-60. Verify that the relations you say represent the Petrie Electronics database are in third normal form. If they are, explain why. If they are not, change them so that they are.

9.62 The E-R diagram you developed in questions in the Petrie Electronics case at the end of Chapter 8 should have shown minimum cardinalities on both ends of each relationship. Are minimum cardinalities repre- sented in some way in the relations in your answer to

Case Question 9.61? If not, how are minimum cardi- nalities enforced in the database?

9.63 Using your answer to Case Question 9.61, select data types, formats, and lengths for each attribute of each relation. Use the data types and formats supported by Microsoft Access. What data type should be used for nonintelligent primary keys?

9.64 Complete all table and field definitions for the Pet- rie Electronics case database using Microsoft Access. Besides the decisions you have made in answers to the preceding questions, fill in all other field definition parameters for each field of each table.

9.65 The one decision for a relational database that usu- ally influences efficiency the most is index definition. What indexes do you recommend for this database? Justify your selection of each index.

9.66 Using Microsoft Visio, develop an E-R diagram with all the supporting database properties for decisions you made in Case Questions 9.60–65. Can all the database design decisions you made be documented in Visio? Finally, use Visio to generate Microsoft Access table definitions. Did the table genera- tion create the table definitions you would create manually?

M09B_VALA1629_09_GE_C09.indd 362 08/04/2020 16:43

363

In this chapter, you will learn what guidelines to follow when designing forms and reports. In general, forms are used to present or collect information on a single item, such as a customer, product, or event. Forms can be used for both input and output. Reports, on the other hand, are used to convey information on a collection of items. Form and report design is a key ingredient for successful systems. Because users often equate the quality of a sys- tem with the quality of its input and output methods, you can see that the design process for forms and reports is an especially important activity. And because information can be collected and formatted in many ways, gaining an understanding of design dos and don’ts and the trade-offs between various formatting options is useful for all systems analysts.

In the next section, the process of designing forms and reports is briefly described, and we also provide guid- ance on the deliverables produced during this process. Guidelines for formatting information are then provided that serve as the building blocks for designing all forms and reports. We then describe methods for assessing the usabil- ity of form and report designs. The chapter concludes by examining how to design forms and reports for Internet- based electronic commerce applications.

DESIGNING FORMS AND REPORTS This is the second chapter that focuses on system design within the systems development life cycle (see Figure 10-1). In this chapter, we describe issues related to the design of sys- tem inputs and outputs—forms and reports. In Chapter 11, we focus on the design of dialogues and interfaces, which are how users interact with systems. Due to the highly related topics and guidelines in these two chapters, they form one conceptual body of guidelines and illustrations that jointly guide the design of all aspects of system inputs and outputs. In each of these chapters, your objective is to gain an understanding of how you can transform infor- mation gathered during analysis into a coherent design. Although all system design issues are related, topics dis- cussed in this chapter on designing forms and reports are especially relative to those in the following chapter—the design of dialogues and interfaces.

System inputs and outputs—forms and reports—were identified during requirements structuring. The kinds of forms and reports the system will handle were estab- lished as part of the design strategy formed at the end of the analysis phase of the systems development process. Dur- ing analysis, however, you may not have been concerned with the precise appearance of forms and reports; your

10.5 explain how to assess usability and describe how variations in users, tasks, technology, and environmental characteristics influence the usability of forms and reports; and

10.6 discuss guidelines for the design of forms and reports for Internet-based electronic commerce systems.

Learning Objectives After studying this chapter, you should be able to

10.1 explain the process of designing forms and reports and the deliverables for their creation;

10.2 apply the general guidelines for formatting forms and reports;

10.3 use color and know when color improves the usability of information;

10.4 format text, tables, and lists effectively;

Introduction

Designing Forms and Reports

M10_VALA1629_09_GE_C10.indd 363 08/04/2020 16:43

364 PART IV DESIGN

medium such as microfilm. Often a report has rows and columns of data, but a report may be of any format—for example, mailing labels. Frequently, the differences between a form and a report are subtle. A report is only for reading and often con- tains data about multiple unrelated records in a computer file. In contrast, a form typically contains data from only one record or is based on one record, such as data about one customer, one order, or one student. The guidelines for the design of forms and reports are very similar.

The Process of Designing Forms and Reports

Designing forms and reports is a user-centered activity that typically follows a proto- typing approach (see Figure 6-7) (Coleman & Goodwin, 2017). User-centered design refers to a design approach that involves an understanding of the target audience, their tasks and goals, information needs, experience levels, and so on. So, to begin, you must gain an understanding of the intended user and task objectives by collecting initial requirements during requirements determination. During this process, several questions must be answered. These questions attempt to answer the “who, what, when, where, and how” related to the creation of all forms or reports (see Table 10-2). Gain- ing an understanding of these questions is a required first step in the creation of any form or report.

For example, understanding who the users are—their skills and abilities—will greatly enhance your ability to create an effective design (Lazar, 2004; McCracken, Wolfe, & Spoll, 2004; Te’eni, Carey, & Zhang, 2006). In other words, are your users experienced computer users or novices? What are the educational level, business background, and task-relevant knowledge of each user? Answers to these questions will provide guidance for both the format and content of your designs. Also, what is the purpose of the form or report? What task will users be performing and what information is needed to complete this task? Other questions are also important to consider. Where will the users be when performing this task? Will users have access to online systems or will they be in the field? Also, how many people will need to use this form or report? If, for example, a report is being produced for a single user, the design requirements and usability assessment will be relatively simple. A design for a larger audience, however, may need to go through a more extensive requirement collection and usability assessment process (Enders, 2016).

Report A business document that contains only predefined data; it is a passive docu- ment used solely for reading or viewing. A report typically contains data from many unrelated records or transactions.

concerns likely focused on which forms or reports need to exist and their contents. You may have distributed prototypes of forms and reports that emerged during analy- sis as a way to confirm requirements with users. Forms and reports are integrally related to various diagrams developed during requirements structuring. For example, every input form will be associated with a data flow entering a process on a data flow diagram (DFD), and every output form or report will be a data flow produced by a process on a DFD. This means that the contents of a form or report correspond to the data elements contained in the associated data flow. Further, the data on all forms and reports must consist of data elements in data stores and on the E-R data model for the application, or must be computed from these data elements. (In rare instances, data simply go from system input to system output without being stored within the system.) It is common that, as you design forms and reports, you will discover flaws in DFDs and E-R diagrams; these diagrams should be updated as designs evolve.

If you are unfamiliar with computer-based information systems, it will be helpful to clarify exactly what we mean by a form or report. A form is a business document that contains some predefined data and often includes some areas where additional data are to be filled in. Most forms have a stylized format and are usually not in a simple row and column format. Examples of business forms are product order forms, employment applications, and class registration sheets. Traditionally, forms have been displayed on a paper medium, but today video display technology allows us to duplicate the layout of almost any printed form, including an organizational logo or any graphic, on a video display terminal. Forms displayed on a video display may be used for data display or data entry. Additional examples of forms are an elec- tronic spreadsheet, a computer sign-on or menu, and an ATM transaction layout. On the Internet, form interaction is the standard method of gathering and displaying information when consumers order products, request product information, or query account status.

A report is a business document that contains only predefined data; it is a pas- sive document used solely for reading or viewing. Examples of reports include invoices, weekly sales summaries by region and salesperson, or a pie chart of popula- tion by age categories (see Table 10-1). We usually think of a report as printed on paper, but it may be printed to a computer file, a visual display screen, or some other

Form A business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance of a form is typically based on one database record.

FIGURE 10-1 Systems development life cycle with logical design phase highlighted

DesignImplementation

Planning

Maintenance Analysis

Databases Forms and Reports Dialogues and Interfaces Distributed and Internet Systems

M10_VALA1629_09_GE_C10.indd 364 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 365

The Process of Designing Forms and Reports

Report Name Description

Scheduled Reports Reports produced at predefined intervals—daily, weekly, or monthly—to support the routine informational needs of an organization.

Key-Indicator Reports Reports that provide a summary of critical information on a recurring basis.

Exception Reports Reports that highlight data that are out of the normal operating range.

Drill-Down Reports Reports that provide details behind the summary values on a key-indicator or exception report.

Ad-hoc Reports Unplanned information requests in which information is gathered to support a nonroutine decision.

TABLE 10-1 Common Types of Business Reports

1. Who will use the form or report? 2. What is the purpose of the form or report? 3. When is the form or report needed and used? 4. Where does the form or report need to be delivered and used? 5. How many people need to use or view the form or report?

TABLE 10-2 Fundamental Questions When Designing Forms and Reports

M10_VALA1629_09_GE_C10.indd 365 08/04/2020 16:43

366 PART IV DESIGN

After collecting the initial requirements, you structure and refine this informa- tion into an initial prototype. Structuring and refining the requirements are com- pleted independently of the users, although you may need to occasionally contact users in order to clarify some issue overlooked during analysis. Finally, you ask users to review and evaluate the prototype. After reviewing the prototype, users may accept the design or request that changes be made. If changes are needed, you will repeat the construction–evaluate–refinement cycle until the design is accepted. Usually, several iterations of this cycle occur during the design of a single form or report. As with any prototyping process, you should make sure that these iterations occur rapidly in order to gain the greatest benefits from this design approach.

The initial prototype may be constructed in numerous environments, including Windows, OSX, or, most frequently, for the Web. The obvious choice is to employ standard development tools used within your organization and the target platform for your system. Often, initial prototypes are simply a series of mock screens that are not working modules or systems. Mock screens can be produced from a word processor, a computer graphics design package, an electronic spreadsheet, or even on paper (Snyder, 2003). This series of mock screens is commonly referred to as a paper prototype. In addition to providing a look and feel that can be assessed, the paper prototype is also used to test content, task flow, and other usability factors (Enders, 2016). It is important to remember that the focus of this activity is on the design—content, layout, and flow—of forms and reports; of course, you must also consider how specific forms and reports will be implemented. It is fortunate that tools for designing forms and reports are rapidly evolving, making development faster and easier. In the past, inputs and outputs of all types were typically designed by hand on a coding or layout sheet. For example, Figure 10-2 shows the layout of a data input form using a coding sheet.

Although coding sheets are still used, their importance has diminished due to significant changes in system operating environments and the evolution of automated design tools. Prior to the creation of graphical operating environments, for example, analysts designed many inputs and outputs that were 80 columns (characters) by 25 rows, the standard dimensions for most video displays. These limits in screen dimen- sions are radically different in graphical operating environments such as Microsoft’s Windows or the Web, where font sizes and screen dimensions can change from user to user, or from device to device. Consequently, the creation of new tools and develop- ment environments was needed to help analysts and programmers develop these graphi- cal and flexible designs. Increasingly, developers are using tools that can quickly create screen mockups, referred to as wireframes, to show the placement of information ele- ments on a screen and the space needed for each element. Wireframe can be used to quickly develop a series of screens so that users can get a sense of the look and feel of a design, as well as the flow and interaction of a series of screens (see Figure 10-3A). Some wireframe development tools, like Axure, can directly generate HTML code for Web applications. For non-web applications, developers may build screen prototypes using a development language. For example, Figure 10-3B shows an example of the same data input form as designed in Microsoft’s Visual Basic.NET. Note the variety of fonts, sizes, and highlighting that was used. Given the need for rapid, iterative develop- ment when designing forms and reports, tools that seamlessly move prototype designs to functional systems are becoming standard in most professional development organizations.

Deliverables and Outcomes

Each systems development life cycle (SDLC) phase helps you to construct a system. In order to move from phase to phase, each activity produces a type of deliverable that is used in a later phase or activity. For example, within the project initiation and plan- ning phase of the SDLC, the Baseline Project Plan serves as input to many subsequent

Paper prototype A series of mock screens that can be used to test content, look, and feel, as well as the task flow and other usability factors.

Wireframe A simple design to show the placement of information elements on a screen and the space needed for each element.

M10_VALA1629_09_GE_C10.indd 366 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 367

SDLC activities. In the case of designing forms and reports, design specifications are the major deliverables and are inputs to the system implementation phase. Design specifications have three sections:

1. Narrative overview 2. Sample design 3. Testing and usability assessment

The first section of a design specification contains a general overview of the characteristics of the target users, tasks, system, and environmental factors in which the form or report will be used. The purpose is to explain to those who will actually develop the final form why this form exists and how it will be used so that they can

FIGURE 10-2 The layout of a data input form using a coding sheet

SYSTEM PROGRAM PROGRAMMER DATE

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

M10_VALA1629_09_GE_C10.indd 367 08/04/2020 16:43

368 PART IV DESIGN

FIGURE 10-3B A data input screen designed in Microsoft’s Visual Basic.NET

(Source: Microsoft Corporation.)

FIGURE 10-3A A data input screen designed as a wireframe

make the appropriate implementation decisions. In this section, you list general infor- mation and the assumptions that helped shape the design. For example, Figure 10-4 shows an excerpt of a design specification for a Customer Account Status form for Pine Valley Furniture (PVF). The first section of the specification, Figure 10-4a, pro- vides a narrative overview containing the relevant information to developing and using the form within PVF. The overview explains the tasks supported by the form, where

M10_VALA1629_09_GE_C10.indd 368 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 369

and when the form is used, characteristics of the people using the form, the technol- ogy delivering the form, and other pertinent information. For example, if the form is delivered on a visual display terminal, this section would describe the capabilities of this device, such as whether it has a touch screen and whether color and a mouse are available.

In the second section of the specification, Figure 10-4b, a sample design of the form is shown. This design may be hand drawn using a coding sheet, although in most instances it is developed using standard development tools. Using actual development

FIGURE 10-4 Design specification for the design of forms and reports

(Source: Microsoft Corporation.)

(a) Narrative overview

Form: Customer Account Status Users: Customer account representatives within corporate o ces Tasks: Assess customer account information: address, account

balance, year-to-date purchases and payments, credit limit, discount percentage, and account status

System: Novell Network, Microsoft Windows Environment: Standard o ce environment

(b) Sample design

User Rated Perceptions (average 14 users): consistency [ 1 = consistent to 7 = inconsistent]: 1.52 su ciency [1 = su cient to 7 = insu ciency]: 1.43 accuracy [1 = accurate to 7 = inaccurate]: 1.67 . . .

M10_VALA1629_09_GE_C10.indd 369 08/04/2020 16:43

370 PART IV DESIGN

tools allows the design to be more thoroughly tested and assessed. The final section of the specification, Figure 10-4c, provides all testing and usability assessment infor- mation. Procedures for assessing designs are described later in this chapter. Some specification information may be irrelevant when designing some forms and reports. For example, the design of a simple Yes/No selection form may be so straightforward that no usability assessment is needed. Also, much of the narrative overview may be unnecessary unless intended to highlight some exception that must be considered during implementation.

FORMATTING FORMS AND REPORTS A wide variety of information can be provided to users of information systems, rang- ing from text to video to audio. As technology continues to evolve, a greater variety of data types will be used. Unfortunately, a definitive set of rules for delivering every type of information to users has yet to be defined, and these rules are continuously evolving along with the rapid changes in technology. Nonetheless, a large body of human–computer interaction research has provided numerous general guidelines for formatting information. Many of these guidelines will undoubtedly apply to the formatting of information on yet-to-be-determined devices. Keep in mind that the mainstay of designing usable forms and reports requires your active interaction with users. If this single and fundamental activity occurs, it is likely that you will create effective designs.

For example, one of the greatest challenges for designing mobile applications that run on devices like the iPhone is the human–computer interface (Nielsen & Budiu, 2012). In particular, the small video display of these devices presents signifi- cant challenges for application designers. Nevertheless, as these and other comput- ing devices evolve and gain popularity, standard guidelines will emerge to make the process of designing interfaces for these devices much less challenging.

General Formatting Guidelines

Over the past several years, industry and academic researchers have investigated how the format of information influences individual task performance and percep- tions of usability. Through this work, several guidelines for formatting information have emerged (see Table 10-3). These guidelines reflect some of the general truths

Meaningful Titles: Clear and specific titles describing content and use of form or report Revision date or code to distinguish a form or report from prior versions Current date, which identifies when the form or report was generated Valid date, which identifies on what date (or time) the data in the form or report were accurate Meaningful Information: Only needed information should be displayed Information should be provided in a manner that is usable without modification Balance the Layout: Information should be balanced on the screen or page Adequate spacing and margins should be used All data and entry fields should be clearly labeled Design an Easy Navigation System: Clearly show how to move forward and backward Clearly show where you are (e.g., page 1 of 3) Notify user when on the last page of a multipaged sequence

TABLE 10-3 General Guidelines for the Design of Forms and Reports

M10_VALA1629_09_GE_C10.indd 370 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 371

FIGURE 10-5 Contrasting customer information forms (Pine Valley Furniture) (a) Poorly designed form

(Source: Microsoft Corporation.)

Vague title Di�cult to read: information

is packed too tightly

No summary of account activity

No navigation information

that apply to the formatting of most types of information (for more information, the interested reader should see the books by Coleman & Goodwin, 2017; Enders, 2016; Flanders & Peters, 2002; Johnson, 2007; Krug, 2014; Nielsen, 1999; Nielsen & Loranger, 2006; and Shneiderman, Plaisant, Cohen, Jacobs, Elqvist, & Diakopoulos, 2016). The differences between a well-designed form or report and one that is poorly designed will often be obvious. For example, Figure 10-5a shows a poorly designed form for viewing the current account balance for a PVF customer. Figure 10-5b (page 2 of 2) is a better design that incorporates several general guidelines from Table 10-3.

The first major difference between the two forms has to do with the title. The title on Figure 10-5a is ambiguous, whereas the title on Figure 10-5b clearly and specifically describes the contents of the form. The form in Figure 10-5b also includes the date on which the form was generated so that, if printed, it will be clear to the reader when this occurred. Figure 10-5a displays information that is extrane- ous to the intent of the form—viewing the current account balance—and provides

M10_VALA1629_09_GE_C10.indd 371 08/04/2020 16:43

372 PART IV DESIGN

information that is not in the most useful format for the user. For example, Figure 10-5a provides all customer data as well as account transactions and a summary of year-to-date purchases and payments. The form does not, however, provide the cur- rent outstanding balance of the account; a user who desires this information must make a manual calculation. The layout of information between the two forms also varies in balance and information density. Gaining an understanding of the skills of the intended system users and the tasks they will be performing is invaluable when constructing a form or report. By following these general guidelines, your chances of creating effective forms and reports will be enhanced. In the next sections, we will discuss specific guidelines for highlighting information, using color, displaying text, and presenting numeric tables and lists.

Highlighting Information

As display technologies continue to improve, a greater variety of methods will be avail- able to you for highlighting information. Table 10-4 provides a list of the most com- monly used methods for highlighting information. Given this vast array of options, it is more important than ever to consider how highlighting can be used to enhance an output and not prove a distraction. In general, highlighting should be used sparingly to draw the user to or away from certain information and to group together related

(b) Improved design for form

(Source: Microsoft Corporation)

Easy to read: clear, balanced layout Clear title

Summary of account information

Clear navigation information

Blinking and audible tones Color differences Intensity differences Size differences Font differences Reverse video Boxing Underlining All capital letters Offsetting the position of

nonstandard information

TABLE 10-4 Methods of Highlighting

FIGURE 10-5 (continued)

M10_VALA1629_09_GE_C10.indd 372 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 373

information. There are several situations when highlighting can be a valuable tech- nique for conveying special information:

• Notifying users of errors in data entry or processing • Providing warnings to users regarding possible problems such as unusual data

values or an unavailable device • Drawing attention to keywords, commands, high-priority messages, and data

that have changed or gone outside normal operating ranges

Additionally, many highlighting techniques can be used singularly or in tandem, depending upon the level of emphasis desired by the designer. Figure 10-6 illustrates a form where several types of highlighting are used. In this example, boxes clarify different categories of data, capital letters and different fonts distinguish labels from actual data, and bold is used to draw attention to important data.

Much research has focused on the effects of varying highlighting techniques on task performance and user perceptions. A general guideline resulting from this research is that highlighting should be used conservatively. For example, blinking and audible tones should be used only to highlight critical information requiring an immediate response from the user. Once a response is made, these highlights should be turned off. Additionally, highlighting methods should be consistently used and selected based upon the level of importance of the emphasized information. It is also important to examine how a particular highlighting method appears on all

FIGURE 10-6 Customer account status display using various highlighting techniques (Pine Valley Furniture)

(Source: Microsoft Corporation.)

Font size, intensity

Intensity di�erences

All captial letters

Boxing

M10_VALA1629_09_GE_C10.indd 373 08/04/2020 16:43

374 PART IV DESIGN

possible output devices that could be used with the system. For example, some color combinations may convey appropriate information on one display configuration but wash out and reduce legibility on another.

The continued evolution of graphical operating environments such as Windows, Macintosh, and the Web has provided designers with some standard highlighting guidelines. However, these guidelines are often quite vague and are continuously evolving, leaving a great deal of control in the hands of the sys- tems developer. Therefore, in order for organizations to realize the benefits of using standard graphical operating environments—such as reduced user training time and interoperability among systems—you must be disciplined in how you use highlighting.

Color versus No Color

Color is a powerful tool for the designer in influencing the usability of a system (Enders, 2016). When applied appropriately, color provides many potential benefits to forms and reports, which are summarized in Table 10-5. As the use of color dis- plays became widely available during the 1980s, a substantial amount of color versus no color research was conducted. The objective of this research was to gain a better understanding of the effects of color on human task performance (e.g., see Benbasat, Dexter, & Todd, 1986).

The general findings from this research were that the use of color had positive effects on user task performance and perceptions when the user was under time constraints for the completion of a task. Color was also beneficial for gaining greater understanding from a display or chart. An important conclusion from this research was that color was not universally better than no color. The benefits of color only seem to apply if the information is first provided to the user in the most appropriate presentation format. That is, if information is most effectively displayed in a bar chart, color can be used to enhance or supplement the display. If information is displayed in an inappropriate format, color has little or no effect on improving understanding or task performance.

Several problems are associated with using color, also summarized in Table 10-5. Most of these dangers are related more to the technical capabilities of the display and hard-copy devices than misuse. However, color blindness is a particular user issue that is often overlooked in the design of systems; approximately 8 percent of the males in the European and North American communities have some form of color blindness (Shneiderman et al., 2016). It is recommended that you first design video displays for

Benefits from Using Color: Soothes or strikes the eye. Accents an uninteresting display. Facilitates subtle discriminations in complex displays. Emphasizes the logical organization of information. Draws attention to warnings. Evokes more emotional reactions. Problems from Using Color: Color pairings may wash out or cause problems for some users (e.g., color blindness). Resolution may degrade with different displays. Color fidelity may degrade on different displays. Printing or conversion to other media may not easily translate.

(Source: Based on Shneiderman et al., 2016; Benbasat, Dexter, & Todd, 1986.)

TABLE 10-5 Benefits and Problems from Using Color

M10_VALA1629_09_GE_C10.indd 374 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 375

monochrome and allow color (or better yet, a flexible palette of colors) to be a user- activated option. Shneiderman et al. (2016) also suggest that you limit the number of colors and where they are applied, using color primarily as a tool to assist in the highlighting and formatting of information.

Displaying Text

In business-related systems, textual output is becoming increasingly important as text-based applications such as electronic mail, bulletin boards, and information services (e.g., Dow Jones) are more widely used. The display and formatting of sys- tem help screens, which often contain lengthy textual descriptions and examples, is one example of textual data that can benefit from following a few simple guidelines that have emerged from past research. These guidelines appear in Table 10-6. The first guideline is simple: You should display text using common writing conven- tions such as mixed uppercase and lowercase letters and appropriate punctuation. For large blocks of text, if space permits, text should be double-spaced. However, if the text is short, or rarely used, it may be appropriate to use single spacing and place a blank line between each paragraph. You should also left-justify text and use a ragged-right margin—research shows that a ragged-right margin makes it easier to find the next line of text when reading than when text is both left and right justified.

When displaying textual information, you should also be careful not to hyphenate words between lines or use obscure abbreviations and acronyms. Users may not know whether the hyphen is a significant character if it is used to continue words across lines. Information and terminology that are not widely understood by the intended users may significantly influence the usability of the system. Thus, you should use abbreviations and acronyms only if they are significantly shorter than the full text and are commonly known by the intended system users. Figure 10-7 shows two versions of a help screen from an application system at PVF. Figure 10-7a shows many violations of the general guidelines for displaying text, whereas Figure 10-7b shows the same information but follows the general guidelines for displaying text. Formatting guidelines for the entry of text and alphanumeric data are also a very important topic. These guidelines are presented in Chapter 11, “Designing Interfaces and Dialogues,” where we focus on issues of human–com- puter interaction.

Designing Tables and Lists

Unlike textual information, where context and meaning are derived through reading, the context and meaning of tables and lists are derived from the for- mat of the information. Consequently, the usability of information displayed in tables and alphanumeric lists is likely to be much more heavily influenced by effec- tive layout than most other types of information display. As with the display of

Case Display text in mixed uppercase and lowercase and use conventional punctuation.

Spacing Use double spacing if space permits. If not, place a blank line between paragraphs.

Justification Left-justify text and leave a ragged-right margin. Hyphenation Do not hyphenate words between lines. Abbreviations Use abbreviations and acronyms only when they are widely understood

by users and are significantly shorter than the full text.

TABLE 10-6 Guidelines for Displaying Text

M10_VALA1629_09_GE_C10.indd 375 08/04/2020 16:43

376 PART IV DESIGN

(b) An improved design for a help screen

(Source: Microsoft Corporation.) Mixed caseClear title

Spacing between sections

FIGURE 10-7 Contrasting the display of textual help information (a) Poorly designed help screen with many violations of the general guidelines for displaying text

(Source: Microsoft Corporation.)

Fixed, uppercase textVague title

Single spacing

M10_VALA1629_09_GE_C10.indd 376 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 377

textual information, tables and lists can also be greatly enhanced by following a few simple guidelines. These are summarized in Table 10-7. You should review these guidelines and carefully apply them to ensure that your tables and lists are highly usable.

Figure 10-8 displays two versions of a form design from a PVF application system that displays customer year-to-date transaction information in a table format. Figure 10-8a displays the information without consideration of the guidelines presented in Table 10-7, and Figure 10-8b (only page 2 of 2 is shown) displays this information after consideration of these guidelines.

One key distinction between these two display forms relates to labeling. The information reported in Figure 10-8b has meaningful labels that more clearly stand out as labels compared with the display in Figure 10-8a. Transactions are sorted by date, and numeric data are right justified and aligned by decimal point in Figure 10-8b, which helps to facilitate scanning. Adequate space is left between columns, and blank lines are inserted after every five rows in Figure 10-8b to help ease the finding and reading of information. Such spacing also provides room for users to annotate data that catch their attention. Use of the guidelines presented in Table 10-7 helped the analyst to create an easy-to-read layout of the information for the user.

Most of the guidelines in Table 10-7 are rather obvious, but this and other tables serve as a quick reference to validate that your form and report designs will be usable. It is beyond our scope here to discuss each of these guidelines, but you should read each carefully and think about why each is appropriate. For example, why are labels repeated on subsequent screens and pages (the third guideline in Table 10-7)? One explanation is that pages may be separated or copied and the origi- nal labels will no longer be readily accessible to the reader of the data. Why should long alphanumeric data (see the last guideline) be broken into small groups? (If you have a credit card or bank check, look at how your account number is displayed.) One reason is that the characters will be easier to remember as you read and type them. Another reason is that there will be a natural and consistent place to pause when you speak them over the phone; for example, when you are placing a phone order for products in a catalog.

TABLE 10-7 General Guidelines for Displaying Tables and Lists

Use Meaningful Labels: All columns and rows should have meaningful labels. Labels should be separated from other information by using highlighting. Redisplay labels when the data extend beyond a single screen or page. Formatting Columns, Rows, and Text: Sort in a meaningful order (e.g., ascending, descending, or alphabetic). Place a blank line between every five rows in long columns. Similar information displayed in multiple columns should be sorted vertically (i.e., read from

top to bottom, not left to right). Columns should have at least two spaces between them. Allow white space on printed reports for user to write notes. Use a single typeface, except for emphasis. Use same family of typefaces within and across displays and reports. Avoid overly fancy fonts. Formatting Numeric, Textual, and Alphanumeric Data: Right-justify numeric data and align columns by decimal points or other delimiter. Left-justify textual data. Use short line length, usually 30–40 characters per line (this is what

newspapers use, and it is easier to speed-read). Break long sequences of alphanumeric data into small groups of three to four characters each.

M10_VALA1629_09_GE_C10.indd 377 08/04/2020 16:43

378 PART IV DESIGN

When you design the display of numeric information, you must determine whether a table or a graph should be used. A considerable amount of research focus- ing on this topic has been conducted (e.g., see Jarvenpaa & Dickson [1988] for very specific guidelines on the use of tables and graphs). In general, this research has found that tables are best when the user’s task is related to finding an individual data value from a larger data set, whereas line and bar graphs are more appropriate for gaining an understanding of data changes over time (see Table 10-8). For example, if the marketing manager for PVF needed to review the actual sales of a particular salesperson for a particular quarter, a tabular report like the one shown in Figure 10-9 would be most useful. This report has been annotated to emphasize good report- design practices. The report has both a printed date as well as a clear indication, as part of the report title, of the period over which the data apply. There is also sufficient white space to provide some room for users to add personal comments and obser- vations. Often, to provide such white space, a report must be printed in landscape, rather than portrait, orientation. Alternatively, if the marketing manager wished to

FIGURE 10-8 Contrasting the display of tables and lists (Pine Valley Furniture) (a) Poorly designed form

(Source: Microsoft Corporation.)

Single column for all types of data

No column labels

Numeric data are left justified

Use Tables For: Reading individual data values Use Graphs For: Providing a quick summary of data Detecting trends over time Comparing points and patterns of

different variables Forecasting activities Reporting vast amounts of infor-

mation when relatively simple impressions are to be drawn

(Source: Based on Jarvenpaa & Dickson, 1988.)

TABLE 10-8 Guidelines for Selecting Tables versus Graphs

M10_VALA1629_09_GE_C10.indd 378 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 379

compare the overall sales performance of each sales region, a line or bar graph would be more appropriate (see Figure 10-10). As with other formatting considerations, the key consideration as to when you should select a table or a graph is the task being performed by the user.

Paper versus Electronic Reports

When a report is produced on paper rather than on a computer display, there are some additional things that you need to consider. For example, laser printers (especially color laser printers) and ink jet printers allow you to produce a report that looks exactly as it does on the display screen. Thus, when using these types of printers, you can follow our general design guidelines to create a report with high usability. However, other types of printers are not able to closely reproduce the display screen image onto paper. For example, many business reports are produced using high-speed impact printers that produce characters and a limited range of graphics by printing a fine pattern of dots. The advantages of impact printers are that they are very fast, very reliable, and relatively inexpensive. Their drawbacks are that they have a limited ability to produce graphics and have a somewhat lower print quality. In other words, they are good at rapidly producing reports that con- tain primarily alphanumeric information, but they cannot exactly replicate a screen

(b) Improved design for form

(Source: Microsoft Corporation.)

Clear and separate column labels for each data type

Numeric data are right justified

FIGURE 10-8 (continued)

M10_VALA1629_09_GE_C10.indd 379 08/04/2020 16:43

380 PART IV DESIGN

report onto paper. Because of this, impact printers are mostly used for producing large batches of reports, such as a batch of phone bills for a telephone company, on a wide range of paper widths and types. When designing reports for impact printers, you use a coding sheet like that displayed in Figure 10-2, although coding sheets for designing printer reports typically can have up to 132 columns. Like the process for designing all forms and reports, you follow a prototyping process and carefully control the spacing of characters in order to produce a high-quality report. However,

FIGURE 10-9 Tabular report illustrating numerous design guidelines (Pine Valley Furniture)

Superscript characters can be used to alert

reader of more detailed information

Sort columns in some meaningful order (names are sorted

alphabetically within region)

Long sequence of alphanumeric data

is grouped into smaller segments

Right justify all numeric data

Try to fit table onto a single page to help in making

comparisons

Place meaningful labels on all

columns and rows

Alphabetic text is left justified

Use a meaningful

title

Box the table data to improve the appearance

of the table

Northwest & Mountain

Midwest & Mid-Atlantic

New England

Baker Hawthorne Hodges

Franklin Stephenson1 Swenson

Brightman Kennedy

999-99-9999 999-99-9999 999-99-9999

999-99-9999 999-99-9999

Quarterly Actual Sales Region Salesperson SSN First Second Third Fourth

195,000 220,000 110,000

110,000 75,000

110,000

250,000 310,000

146,000 175,000 95,000

120,000 66,000 98,000

280,000 190,000

133,000 213,000 170,000

170,000 80,000

100,000

260,000 270,000

120,000 198,000 120,000

90,000 80,000 90,000

330,000 280,000

Pine Valley Furniture Salesperson Annual Summary Report, 2020

January 10, 2021 Page 1 of 2

1Sales reflect July 1, 2020 – December 31, 2020.

FIGURE 10-10 Graphs for comparison (a) Line graph

S al

es V

o lu

m e

(0 0 0 0 )

Quarter Northwest & Mountain Region

FourthThirdSecondFirst

Pine Valley Furniture Quarterly Sales Report

Salesperson

Hawthorne Baker Hodges

M10_VALA1629_09_GE_C10.indd 380 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 381

unlike other form and report designs, you may be limited in the range of formatting, text types, and highlighting options. Nonetheless, you can easily produce a highly usable report of any type if you carefully and creatively use the formatting options that are available.

ASSESSING USABILITY There are many factors to consider when you design forms and reports. The objec- tive for designing forms, reports, and all human–computer interactions is usability (Enders, 2016). Usability typically refers to the following three characteristics:

1. Speed. Can you complete a task efficiently? 2. Accuracy. Does the system provide what you expect? 3. Satisfaction. Do you like using the system?

In other words, usability means that your designs should assist, not hinder, user performance. Thus, usability refers to an overall evaluation of how a system performs in supporting a particular user for a particular task. In the remainder of this section, we describe numerous factors that influence usability and several techniques for assess- ing the usability of a design.

Usability Success Factors

Research and practical experience have found that design consistency is the key ingredient in designing usable systems (Cooper, Reimann, Cronin, & Noessel, 2014; Enders, 2016; Krug, 2014; Nielsen & Loranger, 2006; Shneiderman et al., 2016). Consistency significantly influences users’ ability to gain proficiency when interact- ing with a system. Consistency means, for example, that titles, error messages, menu options, and other design elements appear in the same place and look the same on all forms and reports. Consistency also means that the same form of highlight- ing has the same meaning each time it is used and that the system will respond in roughly the same amount of time each time a particular operation is performed. Other important factors include efficiency, ease (or understandability), format, and flexibility. Each of these usability factors, with associated guidelines, is described in more detail in Table 10-9.

When designing outputs, you must also consider the context in which the screens, forms, and reports will be used. As mentioned, numerous characteristics play an important role in shaping a system’s usability. These characteristics are related to the intended users and task being performed in addition to the techno- logical, social, and physical environment in which the system and outputs are used.

Usability An overall evaluation of how a system performs in supporting a particular user for a particular task.

(b) Bar graph S

al es

V o

lu m

e (0

0 0 0 )

Quarter Northwest & Mountain Region

FourthThirdSecondFirst

Pine Valley Furniture Quarterly Sales Report

Salesperson

Hawthorne Baker Hodges

FIGURE 10-10 (continued)

M10_VALA1629_09_GE_C10.indd 381 08/04/2020 16:43

382 PART IV DESIGN

Table 10-10 lists several factors that influence the usability of a design. Your role is to gain a keen awareness of these factors so that your chances of creating highly usable designs are increased.

Measures of Usability

User-friendliness is a term often used, and misused, to describe system usability. Although the term is widely used, it is too vague from a design standpoint to provide adequate information because it means different things to different people. Consequently, most development groups use several methods for assessing usability, including the follow- ing considerations (Enders, 2016; Shneiderman et al., 2016; Te’eni et al., 2006):

• Learnability—How difficult is it for a user to perform a task for the first time? • Efficiency—How quickly can users perform tasks once they know how to per-

form them? • Error rate—How many errors might a user encounter, and how easy it is to

recover from those errors?

Learnability A usability dimension concerned with how difficult it is for the user to perform a task for the first time.

Error rate A usability dimension concerned with how many errors a user might encounter and how easy it is to recover from those errors.

Efficiency A usability dimension concerned with how quickly users can perform tasks once they know how to perform them.

Usability Factor Guidelines for Achievement of Usability

Consistency Consistent use of terminology, abbreviations, formatting, titles, and navigation within and across outputs. Consistent response time each time a function is performed.

Organization Formatting should be designed with an understanding of the task being performed and the intended user. Text and data should be aligned and sorted for efficient navigation and entry. Entry of data should be avoided where possible (e.g., computing rather than entering totals).

Clarity Outputs should be self-explanatory and not require users to remem- ber information from prior outputs in order to complete tasks. Labels should be extensively used, and all scales and units of mea- sure should be clearly indicated.

Format Information format should be consistent between entry and display. Format should distinguish each piece of data and highlight, not bury, important data. Special symbols, such as decimal places, dollar signs, and ± signs, should be used as appropriate.

Flexibility Information should be viewed and retrieved in a manner most con- venient to the user. For example, users should be given options for the sequence in which to enter or view data and for use of short- cut keystrokes, and the system should remember where the user stopped during the last use of the system.

TABLE 10-9 General Design Guidelines for Usability of Forms and Reports

Characteristic Consideration for Form and Report Design

User Issues related to experience, skills, motivation, education, and per- sonality should be considered.

Task Tasks differ in amount of information that must be obtained from or provided to the user. Task demands such as time pressure, cost of errors, and work duration (fatigue) will influence usability.

System The platform on which the system is constructed will influence inter- action styles and devices.

Environment Social issues such as the users’ status and role should be considered in addition to environmental concerns such as lighting, sound, task interruptions, temperature, and humidity. The creation of usable forms and reports may necessitate changes in the users’ physical work facilities.

(Source: Based on Norman, 1991.)

TABLE 10-10 Characteristics for Consideration When Designing Forms and Reports

M10_VALA1629_09_GE_C10.indd 382 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 383

• Memorability—How easy is it to remember how to accomplish a task when revis- iting the system after some period of time?

• Satisfaction and aesthetics—How enjoyable is the system’s visual appeal and how enjoyable is the system to use?

In assessing usability, you can collect information by observation, interviews, keystroke capturing, and questionnaires. Time to learn simply reflects how long it takes the average system user to become proficient using the system. Equally impor- tant is the extent to which users remember how to use inputs and outputs over time. The manner in which the processing steps are sequenced and the selection of one set of keystrokes over others can greatly influence learning time, the user’s task per- formance, and error rates. For example, the most commonly used functions should be quickly accessed with the fewest number of steps possible (e.g., pressing one key to save your work). Additionally, the layout of information should be consistent, both within and across applications, whether the information is delivered on a screen display or on a hard-copy report.

ELECTRONIC COMMERCE APPLICATIONS: DESIGNING FORMS AND REPORTS FOR PINE VALLEY FURNITURE’S WEBSTORE Designing the forms and reports for an Internet-based electronic commerce applica- tion is a central and critical design activity. Because this is where a customer will inter- act with a company, much care must be put into its design. Like the process followed when designing the forms and reports for other types of systems, a prototyping design process is most appropriate (Coleman & Goodwin, 2017). Although the techniques and technology for building Internet sites are rapidly evolving, several general design guidelines have emerged. In this section, we examine some of these as they apply to the design of PVF’s WebStore.

General Guidelines

When designing forms and reports, there are several errors that are specific to Web site design. It is unfortunately beyond the scope of this book to critically examine all possible design problems within contemporary Web sites. Here, we will simply sum- marize those errors that commonly occur and that are particularly detrimental to the user’s experience (see Table 10-11). Fortunately, there are numerous excellent sources for learning more about designing useful Web sites (Ash et al., 2012; Cooper et al., 2014; Flanders & Peters, 2002; Johnson, 2007; Krug, 2014; Nielsen, 1999; Nielsen & Loranger, 2006; Shneiderman et al., 2016; http://www.nngroup.com; http://www. webpagesthatsuck.com).

Designing Forms and Reports at Pine Valley Furniture

When Jim Woo and the PVF development team focused on designing the forms and reports (i.e., the “pages”) for the WebStore, they first reviewed many popular elec- tronic commerce Web sites. From this review, they established the following design guidelines:

• Use lightweight graphics. • Establish forms and data integrity rules. • Use stylesheet-based HTML.

In order to ensure that all team members understood what was meant by each guideline, Jim organized a design briefing to explain how each guideline would be incorporated into the WebStore interface design.

Memorability A usability dimension concerned with how easy it is to remember how to accomplish a task when revisiting the system after a period of time.

Satisfaction and aesthetics A usability dimension concerned with how enjoyable a system’s visual appeal is and how enjoyable the system is to use.

PINE VALLEY FURNITURE

M10_VALA1629_09_GE_C10.indd 383 08/04/2020 16:43

http://www.nngroup.com

http://www.webpagesthatsuck.com

384 PART IV DESIGN

Lightweight Graphics

In addition to easy menu and page navigation, the PVF development team wants a system where Web pages load quickly. A technique that can assist in making pages load quickly is the use of lightweight graphics. Lightweight graphics are small, simple images that allow a page to load as quickly as possible. “Using light- weight graphics allows pages to load quickly and helps users to reach their final location in the site—hopefully the point of purchase area—as quickly as possible. Large color images will only be used for displaying detailed product pictures that customers explicitly request to view,” explained Jim. Experienced Web designers have found that customers are not willing to wait at each hop of navigation for a page to load, just so they have to click and wait again. The quick feedback that a Web site with lightweight graphics can provide will help to keep customers at the WebStore longer.

Forms and Data Integrity Rules

Because the goal of the WebStore is to have users place orders for products, all forms that request information should be clearly labeled and provide adequate room for input. If a specific field requires a specific input format such as a date of birth or phone number, it must provide a clear example for the user so that data errors can be reduced. Additionally, the site must clearly designate which fields are optional, which are required, and which have a range of values.

Lightweight graphics Small, simple images that allow a Web page to be displayed more quickly.

Error Recommendation

Nonstandard Use of GUI Widgets

Make sure that when using standard design items, they behave in accordance with major interface design standards. For example, the rules for radio buttons state that they are used to select one item among a set of items, that is, not confirmed until “OK’d” by a user. In many Web sites select- ing radio buttons is used as both selection and action.

Anything That Looks Like Advertising

Because research on Web traffic has shown that many users have learned to stop paying attention to Web advertisements, make sure that you avoid designing any legitimate information in a manner that resembles advertising (e.g., banners, animations, pop-ups).

Bleeding-Edge Technology Make sure that users don’t need the latest browsers or plug-ins to view your site.

Scrolling Test and Looping Animations

Avoid scrolling text and animations because they are both hard to read and users often equate such content with advertising.

Nonstandard Link Colors Avoid using nonstandard colors to show links and for showing links that users have already used; nonstandard colors will confuse the user and reduce ease of use.

Outdated Information Make sure your site is continuously updated so that users “feel” that the site is regularly maintained and updated. Outdated content is a sure way to lose credibility.

Slow Download Times Avoid using large images, lots of images, unnecessary animations, or other time-consuming content that will slow the downloading time of a page.

Fixed-Formatted Text Avoid fixed-formatted text that requires users to scroll horizontally to view content or links

Displaying Long Lists as Long Pages

Avoid requiring users to scroll down a page to view informa- tion, especially navigational controls. Manage information by showing only N items at a time, using multiple pages, or by using a scrolling container within the window.

TABLE 10-11 Common Errors When Designing the Layout of Web Pages

M10_VALA1629_09_GE_C10.indd 384 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 385

Jim emphasized, “All of this seems to be overkill, but it makes processing the data much simpler. Our site will check all data before submitting it to the server for process- ing. This will allow us to provide quicker feedback to the user on any data entry error and eliminate the possibility of writing erroneous data into the permanent database. Additionally, we want to provide a disclaimer to reassure our customers that the data will be used only for processing orders, that it will never be sold to marketers, and that it will be kept strictly confidential.”

Stylesheet-Based HTML

When Jim talked with the consultants about the WebStore during the analysis phase, they emphasized the advantages of using stylesheet-based HTML. He was told that when dis- playing individual products, it would be very advantageous to try to have a few “stylesheets” that could be used where appropriate in order to make sure that all pages within the WebStore had the same look and feel. Stylesheets describe how information will be pre- sented (i.e., its style). Thus, stylesheet-based HTML design allows the content of a Web page to remain separate from the way it is formatted. By separating the content from its formatting information, it is much easier to update the look and feel of the Web site and make sure that all pages have a similar appearance. Jim explained, “We need to look for ways to make the Web site consistent and easy to update. By using stylesheets, we not only get all the pages looking the same, we can also update the look of the Web site by making changes in a few stylesheets, rather than in hundreds of Web pages. For example, a desk and a filing cabinet are two completely different products. Yet stylesheets guarantee that their separate pages will be formatted and look the same way.”

Stylesheet-Based HTML A Web design approach that separates content from the way in which it is for- matted and presented, making ongoing maintenance easier and site-wide con- sistency much higher.

SUMMARY This chapter focused on a primary product of information systems: forms and reports. As organizations move into more complex and competitive business environments with greater diversity in the workforce, the quality of the busi- ness processes will determine success. One key to design- ing quality business processes is the delivery of the right information to the right people in the right format at the right time. The design of forms and reports concentrates on this goal. A major difficulty of this process comes from the great variety of information-formatting options avail- able to designers.

Specific guidelines should be followed when design- ing forms and reports. These guidelines, proven over years of experience with human–computer interaction, help you to create professional, usable systems. This chapter presented a variety of guidelines covering the use of titles, layout of fields, navigation between pages or screens, high- lighting of data, use of color, format of text and numeric data, appropriate use and layout of tables and graphs,

avoidance of bias in information display, and achievement of usable forms and reports.

Form and report designs are created through a prototyp- ing process. Once created, designs may be stand-alone or inte- grated into actual working systems. The purpose, however, is to show users what a form or report will look like when the system is implemented. The outcome of this activity is the creation of a specification document where characteristics of the users, tasks, system, and environment are outlined along with each form and report design. Performance testing and usability assessments may also be included in the design specification.

The goal of form and report design is usability. Usabil- ity means that users can use a form or report quickly, accu- rately, and with a high level of satisfaction. To be usable, designs must be consistent, efficient, self-explanatory, well formatted, and flexible. These objectives are achieved by applying a wide variety of guidelines concerning aspects such as navigation; the use of highlighting and color; and the display of text, tables, and lists.

KEY TERMS

10.1 Efficiency 10.2 Error rate 10.3 Form 10.4 Learnability

10.5 Lightweight graphics 10.6 Memorability 10.7 Paper prototype 10.8 Report

10.9 Satisfaction and aesthetics 10.10 Stylesheet-based HTML 10.11 Usability 10.12 Wireframe

M10_VALA1629_09_GE_C10.indd 385 08/04/2020 16:43

386 PART IV DESIGN

REVIEW QUESTIONS 10.13 Describe the prototyping process of designing forms and

reports. What deliverables are produced from this process? Are these deliverables the same for all types of system proj- ects? Why or why not?

10.14 Why is considering the design of forms and reports impor- tant in the systems design process?

10.15 What guidelines should be followed when highlighting information on display?

10.16 Discuss the benefits, problems, and general design process for the use of color when designing system output.

10.17 What kind of formatting should be avoided in textual output?

10.18 What type of labeling can you use in a table or list to improve its usability?

10.19 How should lists and tables be formatted, for instance, in a customer information form?

10.20 When should tables and graphs be used when displaying numeric information?

10.21 What are the key factors determining how design can assist user performance in the best possible way?

10.22 What measures do many development groups use to assess a system’s usability?

10.23 How can information be collected when assessing usabil- ity? What information should be collected?

10.24 What benefits were expected from following the three main guidelines when designing forms and reports at Pine Valley Furniture?

PROBLEMS AND EXERCISES 10.25 Imagine that you are to design a budget report for a col-

league at work using a spreadsheet package. Following the prototyping discussed in the chapter (see also Figure 6-7), describe the steps you would take to design a prototype of this report.

10.26 Consider a system that produces budget reports for your department at work. Alternatively, consider a registration system that produces enrollment reports for a department at a university. For whichever system you choose, answer the following design questions: Who will use the output? What is the purpose of the output? When is the output needed and when is the information that will be used within the out- put available? Where does the output need to be delivered? How many people need to view the output?

10.27 What should be considered about possible users, tasks, systems, and the environment of an electronic commerce application from the customer’s point of view? How can you use this information when designing forms and reports?

10.28 Imagine an output display form for a hotel registration sys- tem. Using a software package for drawing such as Micro- soft Visio, follow the design suggestions in this chapter and design this form entirely in black and white. Save the file and then, following the color design suggestions in this chapter, redesign the form using color. Based on this exercise, discuss the relative strengths and weaknesses of each output form.

10.29 Table 10-1 lists common types of business reports. In Table 10-4, you will find different methods of highlighting. What kind of highlighting techniques would you use for the dif- ferent types of reports?

10.30 List the PC-based software packages you like to use. Describe each package in terms of the following usability characteristics: time to learn, speed of performance, rate of errors by users, retention over time, and subjective satis- faction. Which of these characteristics has made you want to continue to use this package?

Match each of the key terms above with the definition that best fits it.

____ A usability dimension concerned with how difficult it is for the user to perform a task for the first time.

____ A Web design approach that separates content from the way in which it is formatted and presented, making ongoing maintenance easier and site-wide consistency much higher.

____ A simple design to show the placement of information ele- ments on a screen and the space needed for each element.

____ An overall evaluation of how a system performs in support- ing a particular user for a particular task.

____ A usability dimension concerned with how quickly users can perform tasks once they know how to perform them.

____ A business document that contains only predefined data; it is a passive document used only for reading or viewing. It typically contains data from many unrelated records or transactions.

____ A usability dimension concerned with how many errors a user might encounter and how easy it is to recover from those errors.

____ A business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance on such a document is typically based on one database record.

____ A usability dimension concerned with how easy it is to remember how to accomplish a task when revisiting the sys- tem after a period of time.

____ Small, simple images that allow a Web page to be displayed more quickly.

____ A usability dimension concerned with how enjoyable a sys- tem’s visual appeal is and how enjoyable the system is to use.

____ A series of mock screens that can be used to test content, look, and feel, as well as the task flow and other usability factors.

M10_VALA1629_09_GE_C10.indd 386 08/04/2020 16:43

CHAPTER 10 Designing FoRms anD RepoRts 387

REFERENCES Ash, T., Ginty, M., & Page, R. (2012). Landing page optimization: The

definitive guide to testing and tuning for conversion (2nd ed.). New York: Sybex.

Benbasat, I., Dexter, A. S., & Todd, P. (1986). The influence of color and graphical information presentation in a managerial deci- sion simulation. Human—Computer Interaction, 2, 65–92

Coleman, B., & Goodwin, D. (2017). Designing UX: Prototyp- ing: Because modern design is never static. Collingwood, VIC, Australia: SitePoint.

Cooper, A., Reimann, R., Cronin, D. & Noessel, C. (2014). About face: The essentials of interaction design (4th ed.). New York: Wiley and Sons.

Enders, J. (2016). Designing UX: Forms: Create forms that don’t drive users crazy. Collingwood, VIC, Australia: SitePoint.

Flanders, V., & Peters, D. (2002). Son of web pages that suck: Learn good design by looking at bad design. Alameda, CA: Sybex Publishing

10.31 Given the guidelines presented in this chapter, identify flaws in the design of the Report of Customers that follows. What assumptions about users and tasks did you make in order to assess this design? Redesign this report to correct these flaws.

Report of Customers 26-Oct-2020

Cust-ID Organization

AC-4 A.C. Nielson Co. ADTRA-20799 Adran ALEXA-15812 Alexander & Alexander, Inc. AMERI-1277 American Family Insurance AMERI-28157 American Residential Mortgage ANTAL-28215 Antalys ATT-234 AT&T Residential Services ATT-534 AT&T Consumer Services … DOLE-89453 Dole United, Inc. DOME-5621 Dome Caps, Inc. DO-67 Doodle Dandies … ZNDS-22267 Zenith Data System

10.32 Review the guidelines for attaining usability of forms and reports in Table 10-9. Consider an online form you might use to register a guest at a hotel. For each usability factor, list two examples of how this form could be designed to achieve that dimension of usability. Use examples other than those mentioned in Table 10-9.

10.33 Consider a badly designed form or report in terms of speed, accuracy, and satisfaction. For each of these char- acteristics, list the possible consequences.

10.34 Based on your experiences, add as many as possible com- mon errors to the list presented in Table 10-11.

10.35 Compare Figures 10-8a and 10-8b and reflect the changes to the guidelines summarized in Table 10-7. What improve- ments can be found?

10.36 With the help of a wireframing tool, such as Visio or Bal- samiq Mockups, generate a wireframe of your school’s or university’s homepage.

FIELD EXERCISES 10.37 Select an online fill-in form, such as one for generating

an e-mail account. Following the user-centered design process presented in this chapter, redesign the form with help of test users.

10.38 For one week, record all reports that you encounter. Analyze them with the help of the guidelines presented in this chapter. Write a report summarizing how different techniques were used to enhance the usability, and what design flaws were found.

10.39 Go online and find return forms for five different e- commerce applications. Compare the forms. Which has the best usability and why?

10.40 Interview a variety of people you know about the different types of forms and reports they use in their jobs. Ask to examine a few of these documents and answer the follow- ing questions for each one:

a. What types of tasks does each support and how is it used?

b. What types of technologies and devices are used to deliver each one?

c. Assess the usability of each form or report. Is each usable? Why or why not? How could each be improved?

10.41 Go online and find the annual reports of seven different universities. Write a report that lists what methods of high- lighting have been used, how color is used to enhance usability, and when tables have been selected over graphs. Compare these findings with the guidelines presented in this chapter.

10.42 Choose a PC-based software package you like to use and choose one that you don’t like to use. Interview other users to determine their evaluations of these two packages. Ask each individual to evaluate each package in terms of speed, accuracy, and satisfaction as described in this chap- ter. Is there a consensus among these evaluations or do the respondents’ evaluations differ from each other or from your own evaluations? Why?

M10_VALA1629_09_GE_C10.indd 387 08/04/2020 16:43

388 PART IV DESIGN

Jarvenpaa, S. L., & Dickson, G. W. (1988). Graphics and manage- rial decision making: Research based guidelines. Communica- tions of the ACM, 31(6), 764–74.

Johnson, J. (2007). GUI bloopers 2.0: Common user interface design don’ts and dos (2nd ed.). New York: Morgan Kaufmann.

Krug, S. (2014). Don’t make me think: A common sense approach to web usability (3rd ed.). Upper Saddle River, NJ: Prentice Hall.

Lazar, J. (2004). User-centered web development: Theory into practice. Sudbury, MA: Jones & Bartlett.

McCracken, D. D., Wolfe, R. J., & Spoll, J. M. (2004). User-centered Web site development: A human–computer interaction approach. Upper Saddle River, NJ: Prentice Hall.

Nielsen, J. (1999). User interface directions for the Web.” Com- munications of the ACM, 42(1), 65–71.

Nielsen, J., & Budiu, R. (2012). Mobile usability. Indianapolis, IN: New Riders Publishing.

Nielsen, J., & H. Loranger. (2006). Prioritizing web usability. Upper Saddle River, NJ: Prentice Hall.

Norman, K. L. (1991). The psychology of menu selection. Norwood, NJ: Ablex.

Shneiderman, B., Plaisant, C., Cohen, M., Jacobs, S., Elqvist, N., & Diakopoulos, N. (2016). Designing the user interface: Strate- gies for effective human-computer interaction (6th ed.). Reading, MA: Pearson.

Snyder, C. (2003). Paper prototyping: The fast and easy way to design and refine user interfaces. San Francisco: Morgan Kaufmann Publishers.

Sun Microsystems. (2001). Java look and feel guidelines. Palo Alto, CA: Sun Microsystems.

Te’eni, D., Carey, J., & Zhang, P. (2006). Human–computer inter- action: Developing effective organizational information systems. New York: John Wiley & Sons.

M10_VALA1629_09_GE_C10.indd 388 08/04/2020 16:43

PETRIE ELECTRONICS

PE FIGURE 10-1 Initial design for Best Customers Monthly Summary Report

(Source: Microsoft Corporation.)

Chapter 10: Designing Forms and Reports

It was late. Sally Fukuyama, assistant director of market- ing, knocked on the slightly open door of Jim Wata- nabe’s office. Jim was the project director for the “No Customer Escapes” customer loyalty system for Petrie Electronics.

“Yeah, come in,” Jim called. “Hi, Jim,” Sally said, pushing the door open further. “Are

you getting ready to leave?” “Well, I was thinking about it, but something tells me that

I’m probably not leaving any time soon. What’s up?” “I just got an e-mail from John ( John Smith, the head

of marketing at Petrie). He has a whole bunch of reports he wants this system to generate,” Sally replied. She took the stuffed manila folder in her hand and dropped it on Jim’s desk.

“What is all this?” he moaned. “John says all of these reports are absolutely essential. He

says you should be able to generate all of the necessary data from the new customer loyalty system.”

“It will take forever to work out the specific designs on all of these reports,” Jim said. “I’m going to need a lot of help on this.” Jim dropped the folder on his desk.

“Sorry, Jim,” Sally said. “I’ll help you tomorrow, but I really need to go.”

“OK, bye,” Jim said, as Sally left his office. He opened the folder and started to look at what was there.

Some of the report requirements were more complete than others. One of the reports near the top of the heap focused

on listing the best customers, based on how much they had spent in a particular month. “I’ll start with this one,” Jim thought. “I think I’ll do a quick design in Excel.”

Jim worked on the report design for 15 minutes. His first cut is featured in PE Figures 10-1 and 10-2. PE Figure 10-1 shows the high-level summary report, which lists only the names of the customers, where they are from, and the total they spent during a given month. PE Figure 10-2 shows the details of what each customer bought.

“Well,” Jim thought, “these are certainly practical designs for the reports. They show what John says he wants, but they sure are ugly. I wonder how I can make them look bet- ter. No time for that now. I have to start work on all of these other report designs. How many are there? A hundred? Sure seems like it. Maybe I can get the interns to work on some of this. It would be good for them.”

Jim looked over the next suggestion for a report from John’s stack of requests.

Case Questions

10.43 How would you make the reports in PE Figures 10-1 and 10-2 “look better”? After you improve the design of the reports, explain why you make the changes you did.

10.44 What other reports do you think John would ask for, based on the data that would be available from Pet- rie’s customer loyalty system? Make a list. Then take the first two reports on your list and design how they would look.

CHAPTER 10 Designing FoRms anD RepoRts 389

M10_VALA1629_09_GE_C10.indd 389 08/04/2020 16:43

10.45 Using the text as one source and what you can find on the Internet as another source, make a list of the 10 most important things to consider when design- ing reports.

10.46 Do you belong to any customer loyalty programs such as an airline’s frequent flyer program or a

program at a national retailer? If not, maybe your parents or other relatives do. Take the monthly report that a loyalty program sends to customers. Identify all of the data elements needed to create the report and use that information to create an E-R diagram.

PE FIGURE 10-2 Initial design for Best Customers Monthly Detail Report

(Source: Microsoft Corporation.)

390 PART IV DESIGN

M10_VALA1629_09_GE_C10.indd 390 08/04/2020 16:43

391

In this chapter, you will learn about system interface and dialogue design. Interface design focuses on how information is provided to and captured from users; dialogue design focuses on the sequencing of inter- face displays. Dialogues are analogous to a conversation between two people. The grammatical rules followed by each person during a conversation are analogous to the interface. Thus, the design of interfaces and dialogues is the process of defining the manner in which humans and computers exchange information. A good human– computer interface provides a uniform structure for find- ing, viewing, and invoking the different components of a system. This chapter complements Chapter 10, which addressed design guidelines for the content of forms and reports. Here, you will learn about navigation between forms, alternative ways for users to cause forms and reports to appear, and how to supplement the content of forms and reports with user help and error messages, among other topics.

We then describe the process of designing interfaces and dialogues and the deliverables produced during this activity. This is followed by a section that describes inter- action methods and devices. Next, interface design is described. This discussion focuses on layout design, data entry, providing feedback, and designing help menus. We then examine techniques for designing human–computer

dialogues. Finally, we examine the design of interfaces and dialogues within electronic commerce applications.

DESIGNING INTERFACES AND DIALOGUES This is the third chapter that focuses on design within the sys- tems development life cycle (see Figure 11-1). In Chapter 10, you learned about the design of forms and reports. As you will see, the guidelines for designing forms and reports also apply to the design of human–computer interfaces.

The Process of Designing Interfaces and Dialogues

Similar to designing forms and reports, the process of design- ing interfaces and dialogues is a user-focused activity. This means that you follow a prototyping methodology of iteratively collecting information, constructing a prototype, assessing usability, and making refinements. To design usable interfaces and dialogues, you must answer the same who, what, when, where, and how questions used to guide the design of forms and reports (see Table 10-2). Thus, this process parallels that of designing forms and reports (see Coleman & Goodwin, 2017; Lazar, 2004; McCracken, Wolfe, & Spoll, 2004; Shneider- man, Plaisant, Cohen, Jacobs, Elqvist, & Diakopoulos, 2016).

11.4 design human–computer dialogues and understand how dialogue diagramming can be used to design dialogues;

11.5 design graphical user interfaces; and

11.6 discuss guidelines for the design of interfaces and dialogues for Internet-based electronic commerce systems.

Learning Objectives After studying this chapter, you should be able to

11.1 explain the process of designing interfaces and dialogues and the deliverables for their creation;

11.2 contrast and apply several methods for interacting with a system;

11.3 describe and apply the general guidelines for designing interfaces and specific guidelines for layout design, structuring data entry fields, providing feedback, and system help;

Designing Interfaces and Dialogues11

Introduction

M11_VALA1629_09_GE_C11.indd 391 08/04/2020 17:31

392 PART IV DESIGN

Deliverables and Outcomes

The deliverable and outcome from system interface and dialogue design is the cre- ation of a design specification. This specification is also similar to the specification produced for form and report designs—with one exception. Recall that the design specification document discussed in Chapter 10 had three sections (see Figure 10-4):

1. Narrative overview 2. Sample design 3. Testing and usability assessment

For interface and dialogue designs, one additional subsection is included: a section outlining the dialogue sequence—the ways a user can move from one display to another. Later in this chapter, you will learn how to design a dialogue sequence by using dialogue diagramming. An outline for a design specification for interfaces and dialogues is shown in Figure 11-2.

INTERACTION METHODS AND DEVICES The human–computer interface defines the ways in which users interact with an infor- mation system. All human–computer interfaces must have an interaction style and use some hardware device(s) for supporting this interaction. In this section, we describe various interaction methods and guidelines for designing usable interfaces.

Methods of Interacting

When designing the user interface, the most fundamental decision you make relates to the methods used to interact with the system. Given that there are numerous approaches for designing the interaction, we briefly provide a review of those most commonly used. (Readers interested in learning more about interaction methods are encouraged to see the books by Johnson [2007], Seffah & Javahery [2003], Shneider- man et al.[2016], and Te’eni et al.[2006].) Our review will examine the basics of five widely used styles: command language, menu, form, object, and natural language. We

Interface A method by which users interact with an information system.

FIGURE 11-1 Systems development life cycle

DesignImplementation

Planning

Maintenance Analysis

Databases Forms and Reports Dialogues and Interfaces Distributed and Internet Systems

M11_VALA1629_09_GE_C11.indd 392 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 393

will also describe several devices for interacting, focusing primarily on their usability for various interaction activities.

Command Language Interaction In command language interaction, the user enters explicit statements to invoke operations within a system. This type of interaction requires users to remember command syntax and semantics. For example, to rename a copy of a file called “file.doc” in the current directory as “newfile.doc” at the com- mand prompt within Linux, you would type:

$ cp file.doc newfile.doc

Command language interaction places a substantial burden on the user to remember names, syntax, and operations. Most newer or large-scale systems no longer rely entirely on a command language interface. Yet command languages are good for experienced users, for systems with a limited command set, and for rapid interaction with the system.

A relatively simple application such as a word processor may have hundreds of commands for operations such as saving a file, deleting words, canceling the current action, finding a specific piece of data, or switching between windows. Some of the burden of assigning keys to actions has been taken off users’ shoulders through the development of user interface standards such as those for Apple and Windows-based systems (Pogue, 2015; Schooley, 2013). For example, Figure 11-3a shows a help screen from Microsoft Word describing keyboard shortcuts, and Figure 11-3b shows the same screen for Microsoft PowerPoint. Note how many of the same keys have been assigned the same function. Also note that designers still have great flexibility in how they inter- pret and implement these standards. This means that you still need to pay attention to usability factors and conduct formal assessments of designs.

Menu Interaction A significant amount of interface design research has stressed the importance of a system’s ease of use and understandability. Menu interaction is a means by which many designers have accomplished this goal. A menu is simply a list of options; when an option is selected by the user, a specific command is invoked or another menu is activated. Menus have become the most widely used interface method because the user only needs to understand simple signposts and route options to effectively navigate through a system.

Command language interaction A human–computer interaction method whereby users enter explicit statements into a system to invoke operations.

Menu interaction A human–computer interaction method in which a list of system options is provided and a specific command is invoked by user selection of a menu option.

FIGURE 11-2 Specification outline for the design of interfaces and dialogues

Design Specification

1. Narrative Overview a. Interface/Dialogue Name b. User Characteristics c. Task Characteristics d. System Characteristics e. Environmental Characteristics

2. Interface/Dialogue Designs a. Form/Report Designs b. Dialogue Sequence Diagram(s) and Narrative Description

3. Testing and Usability Assessment a. Testing Objectives b. Testing Procedures c. Testing Results

i) Time to Learn ii) Speed of Performance iii) Rate of Errors iv) Retention over Time v) User Satisfaction and Other Perceptions

M11_VALA1629_09_GE_C11.indd 393 08/04/2020 17:31

394 PART IV DESIGN

Menus can differ significantly in their design and complexity. The variation of their design is most often related to the capabilities of the development environment, the skills of the developer, and the size and complexity of the system. For smaller and less complex systems with limited system options, you may use a single menu or a linear sequence of menus. A single menu has obvious advantages over a command language but may provide little guidance beyond invoking the command. An example of a single menu can be found on the “Tabs” settings under the “Options” menu in the popular Firefox Web browser, as shown in Figure 11-4.

For large and more complex systems, you can use menu hierarchies to provide navigation between menus. These hierarchies can be simple tree structures or varia- tions wherein children menus have multiple parent menus. Some of these hierarchies may allow multilevel traversal. Variations as to how menus are arranged can greatly influence the usability of a system. For instance, Microsoft has recently deployed its “ribbon menu” system in recent Office products. Figure 11-5 shows a variety of ways in which menus can be structured and traversed. An arc on this diagram signifies the ability to move from one menu to another. Although more complex menu structures

FIGURE 11-3 Function key assignments in Microsoft Office 2016 (a) Help screen from Microsoft Word describing keyboard commands

(Source: Microsoft Corporation.)

(b) Help screen from Microsoft Power- Point describing keyboard commands

M11_VALA1629_09_GE_C11.indd 394 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 395

FIGURE 11-4 Single-level menu for selecting Settings in the Chrome Web browser

(Source: Google, Inc.)

FIGURE 11-5 Various types of menu configurations

(Source: Based on Shneiderman et al., 2016.)

Single Menu

Linear Sequence Menu

Multilevel Tree Menu Multilevel Tree Menu with Multiple Parents

Multilevel Tree Menu with Multiple Parents and Multilevel Traversal

M11_VALA1629_09_GE_C11.indd 395 08/04/2020 17:31

396 PART IV DESIGN

FIGURE 11-6 Menus from Chrome Web browser (a) Pop-up menu

(Source: Google, Inc.)

(b) Drop-down menu

provide greater user flexibility, they may also confuse users about exactly where they are in the system. Structures with multiple parent menus also require the application to remember which path has been followed so that users can correctly backtrack.

There are two common methods for positioning menus. With a pop-up menu (also called a dialogue box), menus are displayed near the current cursor position so users don’t have to move the position or their eyes to view system options (Figure 11-6a).

Pop-up menu A menu-positioning method that places a menu near the current cursor position.

M11_VALA1629_09_GE_C11.indd 396 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 397

A pop-up menu has a variety of potential uses. One is to show a list of commands rele- vant to the current cursor position (e.g., delete, clear, copy, or validate current field). Another is to provide a list of possible values (from a look-up table) to fill in for the current field. For example, in a customer order form, a list of current customers could pop up next to the customer number field so the user can select the correct customer without having to know the customer’s identifier. With a drop-down menu, menus drop down from the top line of the display (Figure 11-6b). Drop-down menus have become very popular in recent years because they provide consistency in menu location and operation among applications and efficiently use display space. Most advanced operat- ing environments, such as Microsoft Windows or the Apple macOS, provide a combina- tion of both pop-up and drop-down menus.

When designing menus, several general rules should be followed, and these are summarized in Table 11-1. For example, each menu should have a meaningful title and be presented in a meaningful manner to users. A menu option of Quit, for instance, is ambiguous—does it mean return to the previous screen or exit the pro- gram? To more easily see how to apply these guidelines, Figure 11-7 contrasts a poorly designed menu with a menu that follows the menu design guidelines.

Drop-down menu A menu-positioning method that places the access point of the menu near the top line of the display; when accessed, menus open by dropping down onto the display.

Wording • Each menu should have a meaningful title. • Command verbs should clearly and specifically describe operations. • Menu items should be displayed in mixed uppercase and lowercase letters and have a clear,

unambiguous interpretation. Organization • A consistent organizing principle should be used that relates to the tasks the intended users

perform; for example, related options should be grouped together, and the same option should have the same wording and codes each time it appears.

Length • The number of menu choices should not exceed the length of the screen. • Submenus should be used to break up exceedingly long menus.

Selection • Selection and entry methods should be consistent and reflect the size of the application and sophistication of the users.

• How the user is to select each option and the consequences of each option should be clear (e.g., whether another menu will appear).

Highlighting • Highlighting should be minimized and used only to convey selected options (e.g., a check mark) or unavailable options (e.g., dimmed text).

TABLE 11-1 Guidelines for Menu Design

FIGURE 11-7 Contrasting menu designs (a) Poor menu design

SYSTEM OPTIONS

01 02 03 04 05 06

ENTER OPTION (01):__

ORDER INFO ORDER STATUS SALESPERSON INFO REPORTS HELP QUIT

Vague title

Vague command names

All uppercase letters

Vague exit statement

Two-key selection

Common options are not separated and

assigned a standard key

(Continued)

M11_VALA1629_09_GE_C11.indd 397 08/04/2020 17:31

398 PART IV DESIGN

Annotations on the two parts of this figure highlight poor and improved menu interface design features.

Many advanced programming environments provide powerful tools for design- ing menus. For example, Microsoft’s Visual Basic.NET allows you to quickly design a menu structure for a system. For example, Figure 11-8 shows a design form in which a menu structure is being defined; menu items are added by selecting the “Type Here” tags and typing the words that represent each item on the menu. With the use of a few easily invoked options, you can also assign shortcut keys to menu items, connect help screens to individual menu items, define submenus, and set usage properties (see the Properties window within Figure 11-8). Usage properties, for example, include the

(b) Improved menu design

Customer Information System Main Menu

1 2 3 4

9 0

Type option number (1):__

Query Information on a Specific Order Check Status of a Specific Order Review Salesperson Information Produce Order and Sales Reports

Help Exit to Operating System

Clear title

Descriptive command names with

mixed-case letters

Clear exit statement

One-key selection

Common options are separated and

assigned a standard key

FIGURE 11-8 Menu building with Microsoft Visual Basic.NET

(Source: Microsoft Corporation.)

FIGURE 11-7 (continued)

M11_VALA1629_09_GE_C11.indd 398 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 399

ability to dim the color of a menu item while a program is running, indicating that a function is currently unavailable. Menu-building tools allow a designer to quickly and easily prototype a design that will look exactly as it will in the final system.

Form Interaction The premise of form interaction is to allow users to fill in the blanks when working with a system. Form interaction is effective for both the input and presentation of information. An effectively designed form includes a self-explan- atory title and field headings, has fields organized into logical groupings with distinc- tive boundaries, provides default values when practical, displays data in appropriate field lengths, and minimizes the need to scroll windows (Shneiderman et al, 2004). You saw many other design guidelines for forms in Chapter 10. Form interaction is the most commonly used method for data entry and retrieval in business-based systems. Figure 11-9 shows a form from the Google Advanced Search Engine. Using interac- tive forms, organizations can easily provide all types of information to Web surfers.

Object-Based Interaction The most common method for implementing object- based interaction is through the use of icons. Icons are graphic symbols that look like the processing option they are meant to represent. Users select operations by pointing to the appropriate icon with some type of pointing device. The primary advantages to icons are that they take up little screen space and can be quickly understood by most users. An icon may also look like a button that, when selected or depressed, causes the system to take an action relevant to that form, such as cancel, save, edit a record, or ask for help. For example, Figure 11-10 illustrates an icon-based interface when setting Options within the Firefox Web browser.

Natural Language Interaction One branch of artificial intelligence research studies techniques for allowing systems to accept inputs and produce outputs in a

Form interaction A highly intuitive human–computer interaction method whereby data fields are formatted in a manner similar to paper-based forms.

Object-based interaction A human–computer interaction method in which symbols are used to represent commands or functions.

Icon Graphical picture that represents specific functions within a system.

FIGURE 11-9 Example of form interaction from the Google Advanced Search Engine

(Source: Google, Inc.)

M11_VALA1629_09_GE_C11.indd 399 08/04/2020 17:31

400 PART IV DESIGN

conventional language such as English. This method of interaction is referred to as natural language interaction. Presently, natural language interaction is not as viable an interaction style as the other methods presented. Current implementa- tions can be tedious, frustrating, and time-consuming for the user and are often built to accept input in narrowly constrained domains (e.g., database queries). Natural language interaction is being applied within both keyboard and voice entry systems.

Hardware Options for System Interaction

In addition to the variety of methods used for interacting with a system, there is also a growing number of hardware devices employed to support this interaction (see Table 11-2 for a list of interaction devices along with brief descriptions of the typical usage of each). The most fundamental and widely used device is the keyboard, which is the mainstay of most computer-based applications for the entry of alphanumeric information. Keyboards vary, from the typewriter kind of keyboards used with per- sonal computers to special-function keyboards on point-of-sale or shop-floor devices. The growth in graphical user environments, however, has spurred the broader use of pointing devices such as mice, joysticks, trackballs, and graphics tablets. The creation of notebook and pen-based computers with trackballs, joysticks, or pens attached directly to the computer has also brought renewed interest to the usability of these various devices.

Research has found that each device has its strengths and weaknesses. These strengths and weaknesses must guide your selection of the appropriate devices to aid users in their interaction with an application. The selection of an interaction device must be made during logical design because different interfaces require different devices. Table 11-3 summarizes much of the usability assessment research by relating each device to various types of human–computer interaction problems. For example, for many applications, keyboards do not give users a precise feel for cursor movement,

Natural language interaction A human–computer interaction method whereby inputs to and outputs from a computer-based application are in a conventional spoken language such as English.

FIGURE 11-10 Object-based (icon) interface from Microsoft’s Snipping tool

(Source: Microsoft Corporation.)

M11_VALA1629_09_GE_C11.indd 400 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 401

do not provide direct feedback on each operation, and can be a slow way to enter data (depending on the typing skill of the user). Another means to gain an understand- ing of device usability is to highlight which devices have been found most useful for completing specific tasks. The results of this research are summarized in Table 11-4.

Device Description and Primary Characteristics or Usage

Keyboard Users push an array of small buttons that represent symbols that are then translated into words and com- mands. Keyboards are widely understood and provide considerable flexibility for interaction.

Mouse A small plastic box that users push across a flat surface and whose movements are translated into cursor movement on a computer display. Buttons on the mouse tell the system when an item is selected. A mouse works well on flat desks but may not be practical in dirty or busy environments, such as a shop floor or check-out area in a retail store. Newer pen-based mice provide the user with more of the feel of a writ- ing implement.

Joystick A small vertical lever mounted on a base that steers the cursor on a computer display. Provides similar func- tionality to a mouse.

Trackball A sphere mounted on a fixed base that steers the cursor on a computer display. A suitable replacement for a mouse when work space for a mouse is not available.

Touch Screen Selections are made by touching a computer display. This works well in dirty environments or for users with limited dexterity or expertise.

Light Pen Selections are made by pressing a pen-like device against the screen. A light pen works well when the user needs to have a more direct interaction with the contents of the screen.

Graphics Tablet Moving a pen-like device across a flat tablet steers the cursor on a computer display. Selections are made by pressing a button or by pressing the pen against the tablet. This device works well for drawing and graphi- cal applications.

Voice Spoken words are captured and translated by the computer into text and commands. This is most appropri- ate for users with physical challenges or when hands need to be free to do other tasks while interacting with the application.

TABLE 11-2 Common Devices for Interacting with an Information System

Problem

Device Visual

Blocking User

Fatigue Movement

Scaling Durability Adequate Feedback Speed

Pointing Accuracy

Keyboard □ □ ■ □ ■ ■ □ Mouse □ □ ■ □ ■ □ □ Joystick □ □ ■ □ ■ □ ■ Trackball □ □ ■ ■ ■ □ □ Touch

Screen ■ ■ □ ■ □ □ ■

Light Pen ■ ■ □ □ □ □ ■ Graphics

Tablet □ □ ■ □ ■ □ □

Voice □ □ ■ □ ■ □ ■

Key: □ = little or no usability problems ■ = potentially high usability problems for some applications Visual Blocking = extent to which device blocks display when using User Fatigue = potential for fatigue over long use Movement Scaling = extent to which device movement translates to equivalent screen

movement Durability = lack of durability or need for maintenance (e.g., cleaning) over extended use Adequate Feedback = extent to which device provides adequate feedback for each

operation Speed = cursor movement speed Pointing Accuracy = ability to precisely direct cursor

TABLE 11-3 Summary of Interaction Device Usability Problems

M11_VALA1629_09_GE_C11.indd 401 08/04/2020 17:31

402 PART IV DESIGN

The rows of this table list common user–computer interaction tasks, and the columns show three criteria for evaluating the usability of the different devices. After reviewing these three tables, it should be evident that no device is perfect and that some are more appropriate for performing some tasks than others. To design the most effective interfaces for a given application, you should understand the capabilities of various interaction methods and devices.

DESIGNING INTERFACES Building on the information provided in Chapter 10 on the design of content for forms and reports, here we discuss issues related to the design of interface layouts. This discussion provides guidelines for structuring and controlling data entry fields, providing feedback, and designing online help. Effective interface design requires that you gain a thorough understanding of each of these concepts.

Designing Layouts

To ease user training and data recording, you should use standard formats for com- puter-based forms and reports similar to those used on paper-based forms and reports for recording or reporting information. A typical paper-based form for reporting customer sales activity is shown in Figure 11-11. This form has several general areas common to most forms:

• Header information • Sequence and time-related information • Instruction or formatting information • Body or data details • Totals or data summary • Authorization or signatures • Comments

In many organizations, data are often first recorded on paper-based forms and then later recorded within application systems. When designing layouts to record or

Task Most Accurate Shortest Positioning Most Preferred

Target Selection tra ckball, graphics tablet, mouse, joystick

tou ch screen, light pen, mouse, graphics tablet, trackball

tou ch screen, light pen

Text Selection Mouse mouse — Data Entry light pen light pen — Cursor Positioning — light pen — Text Correction light pen, cursor keys light pen light pen Menu Selection touch screen — keyboard, touch screen

Key: Target Selection = moving the cursor to select a figure or item Text Selection = moving the cursor to select a block of text Data Entry = entering information of any type into a system Cursor Positioning = moving the cursor to a specific position Text Correction = moving the cursor to a location to make a text correction Menu Selection = activating a menu item — = no clear conclusion from the research

TABLE 11-4 Summary of General Conclusions from Experimental Comparisons of Input Devices in Relation to Specific Task Activities

M11_VALA1629_09_GE_C11.indd 402 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 403

display information on paper-based forms, you should try to make both as similar as possible. Additionally, data entry displays should be consistently formatted across applications to speed data entry and reduce errors. Figure 11-12 shows an equivalent computer-based form to the paper-based form shown in Figure 11-11.

Another concern when designing the layout of computer-based forms is the design of between-field navigation. Because you can control the sequence for users to move between fields, standard screen navigation should flow from left to right and top to bottom just as when you work on paper-based forms. For example, Figure 11-13 contrasts the flow between fields on a form used to record business contacts. Figure 11-13a uses a consistent left-to-right, top-to-bottom flow. Figure 11- 13b uses a flow that is nonintuitive. When appropriate, you should also group data fields into logical categories with labels describing the contents of the category. Areas of the screen not used for data entry or commands should be inaccessible to the user.

FIGURE 11-11 Paper-based form for reporting customer sales activity (Pine Valley Furniture)

Header

Body

Authorization

Totals

Sequence and Time Information

PINE VALLEY FURNITURE

Sales Invoice

INVOICE No. Date:

SOLD TO:

SOLD BY:

Customer Number: Name:

Address: City:

Phone:

Customer Signature: Date:

State: Zip:

Product Number Description

Quantity Ordered

Unit Price

Total Price

Total Order Amount Less Discount____%

Total Amount

M11_VALA1629_09_GE_C11.indd 403 08/04/2020 17:31

404 PART IV DESIGN

When designing the navigation procedures within your system, flexibility and consistency are primary concerns. Users should be able to freely move forward and backward or to any desired data entry fields. Users should be able to navigate each form in the same way or in as similar a manner as possible. Additionally, data should not usually be permanently saved by the system until the user makes an explicit request to do so. This allows the user to abandon a data entry screen, back up, or move forward without adversely affecting the contents of the permanent data.

Consistency extends to the selection of keys and commands. Each key or com- mand should have only one function, and this function should be consistent through- out the entire system and across systems, if possible. Depending upon the application, various types of functional capabilities will be required to provide smooth navigation and data entry. Table 11-5 provides a list of the functional requirements for provid- ing smooth and easy navigation within a form. For example, a functional and con- sistent interface will provide common ways for users to move the cursor to different places on the form, edit characters and fields, move among form displays, and obtain help. These functions may be provided by keystrokes, mouse or other pointing device operations, or menu selection or button activation. It is possible that, for a single

FIGURE 11-12 Computer-based form reporting customer sales activity (Pine Valley Furniture) (Source: Microsoft Corporation.)

M11_VALA1629_09_GE_C11.indd 404 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 405

application, all of the functional capabilities listed in Table 11-5 may not be needed in order to create a flexible and consistent user interface. Yet the capabilities that are used should be consistently applied to provide an optimal user environment. As with other tables in Chapters 10 and 11, Table 11-5 can serve as a checklist for you to validate the usability of user interface designs.

Structuring Data Entry

Several rules should be considered when structuring data entry fields on a form (see Table 11-6). The first is simple, but it is often violated by designers. To minimize data entry errors and user frustration, never require the user to enter information that is already available within the system or information that can be easily computed by the system. For example, never require the user to enter the current date and time because each of these values can be easily retrieved from the computer system’s inter- nal calendar and clock. By allowing the system to do this, the user simply confirms that the calendar and clock are working properly.

FIGURE 11-13 Contrasting the navigation flow within a data entry form (a) Proper flow between data entry field

(Source: Microsoft Corporation.)

(b) Poor flow between data entry fields

M11_VALA1629_09_GE_C11.indd 405 08/04/2020 17:31

406 PART IV DESIGN

Other rules are equally important. For example, suppose that a bank customer is repaying a loan on a fixed schedule with equal monthly payments. Each month when a payment is sent to the bank, a clerk needs to record into a loan processing system that the payment has been received. Within such a system, default values for fields should be provided whenever appropriate. This means that only in the instances where the customer pays more or less than the scheduled amount should the clerk have to enter data into the system. In all other cases, the clerk would simply verify that the check is for the default amount provided by the system and press a single key to confirm the receipt of payment.

When entering data, the user should also not be required to specify the dimen- sional units of a particular value. For example, a user should not be required to specify that an amount is in dollars or that a weight is in tons. Field formatting and the data entry prompt should make clear the type of data being requested. In other words, a caption describing the data to be entered should be adjacent to each data field. Within this caption, it should be clear to the user what type of data is being requested. As with the display of information, all data entered onto a form should automatically justify in a standard format (e.g., date, time, money). Table 11-7 illustrates a few options appropriate for printed forms. For data entry on video display terminals, you should

Cursor Control Capabilities: Move the cursor forward to the next data field Move the cursor backward to the previous data field Move the cursor to the first, last, or some other designated data field Move the cursor forward one character in a field Move the cursor backward one character in a field Editing Capabilities: Delete the character to the left of the cursor Delete the character under the cursor Delete the whole field Delete data from the whole form (empty the form) Exit Capabilities: Transmit the screen to the application program Move to another screen/form Confirm the saving of edits or go to another screen/form Help Capabilities: Get help on a data field Get help on a full screen/form

TABLE 11-5 Data Entry Screen Functional Capabilities

Entry Never require data that are already online or that can be computed; for example, do not enter customer data on an order form if those data can be retrieved from the database, and do not enter extended prices that can be computed from quantity sold and unit prices.

Defaults Always provide default values when appropriate; for example, assume today’s date for a new sales invoice, or use the standard product price unless overridden.

Units Make clear the type of data units requested for entry; for example, indicate quantity in tons, dozens, pounds, etc. Replacement Use character replacement when appropriate; for example, allow the user to look up the value in a table or

automatically fill in the value once the user enters enough significant characters. Captioning Always place a caption adjacent to fields; see Table 11-7 for caption options. Format Provide formatting examples when appropriate; for example, automatically show standard embedded symbols,

decimal points, credit symbol, or dollar sign. Justify Automatically justify data entries; numbers should be right justified and aligned on decimal points, and text should

be left justified. Help Provide context-sensitive help when appropriate; for example, provide a hot key, such as the F1 key, that opens the

help system on an entry that is most closely related to where the cursor is on the display.

TABLE 11-6 Guidelines for Structuring Data Entry Fields

M11_VALA1629_09_GE_C11.indd 406 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 407

highlight the area in which text is entered so that the exact number of characters per line and number of lines are clearly shown. You can also use check boxes or radio but- tons to allow users to choose standard textual responses. And you can use data entry controls to ensure that the proper type of data (alphabetic or numeric, as required) is entered. Data entry controls are discussed next.

Controlling Data Input

One objective of interface design is to reduce data entry errors. As data are entered into an information system, steps must be taken to ensure that the input is valid. As a systems analyst, you must anticipate the types of errors users may make and design features into the system’s interfaces to avoid, detect, and correct data entry mistakes. Several types of data errors are summarized in Table 11-8. In essence, data errors can occur from appending extra data onto a field, truncating characters off a field, transcripting the wrong characters into a field, or transposing one or more characters within a field. Systems designers have developed numerous tests and techniques for catching invalid data before saving or transmission, thus improving the likelihood that data will be valid (see Table 11-9 for a summary of these techniques). These tests and techniques are often incorporated into both data entry screens and intercomputer data transfer programs.

Practical experience has also found that it is much easier to correct erroneous data before they are permanently stored in a system. Online systems can notify a user of input problems as data are being entered. When data are processed online as events occur, it is much less likely that data validity errors will occur and not be caught. In an online system, most problems can be easily identified and resolved before permanently saving data to a storage device, using many of the techniques

Options Example

Line Caption Phone Number ( ) - Drop Caption ( ) -

Phone Number Boxed Caption Phone Number Delimited Characters

Phone Number Check Boxes Method of communication (check one or more)

❑ E-mail ❑ SMS (Text Message) ❑ Phone

Radio Buttons Method of communication (check preferred method)

❍ E-mail ❍ SMS (Text Message) ● Phone

TABLE 11-7 Options for Entering or Selecting Text

Data Error Description

Appending Adding additional characters to a field Truncating Losing characters from a field Transcripting Entering invalid data into a field Transposing Reversing the sequence of one or more characters in a field

TABLE 11-8 Sources of Data Errors

( ) -

M11_VALA1629_09_GE_C11.indd 407 08/04/2020 17:31

408 PART IV DESIGN

described in Table 11-9. However, in systems where inputs are stored and entered (or transferred) in batch, the identification and notification of errors is more difficult. Batch processing systems can, however, reject invalid inputs and store them in a log file for later resolution.

Most of the tests and techniques shown in Table 11-9 are widely used and straight- forward. Some of these tests can be handled by data management technologies, such as a database management system (DBMS), to ensure that they are applied for all data maintenance operations. If a DBMS cannot perform these tests, then you must design the tests into program modules. An example of one item that is a bit sophisticated, self-checking digits, is shown in Figure 11-14. The figure provides a description and an outline of how to apply the technique as well as a short example. The example shows how a check digit is added to a field before data entry or transfer. Once entered or transferred, the check digit algorithm is again applied to the field to “check” whether the check digit received obeys the calculation. If it does, it is likely (but not guaranteed because two different values could yield the same check digit) that no data transmis- sion or entry error occurred. If the transferred value does not equal the calculated value, then some type of error occurred.

In addition to validating the data values entered into a system, controls must be established to verify that all input records are correctly entered and are processed only once. A common method used to enhance the validity of entering batches of data records is to create an audit trail of the entire sequence of data entry, processing, and storage. In such an audit trail, the actual sequence, count, time, source location, human operator, and so on are recorded into a separate transaction log in the event of a data input or processing error. If an error occurs, corrections can be made by reviewing the contents of the log. Detailed logs of data inputs are not only useful for resolving batch data entry errors and system audits, but they also serve as a powerful method for performing backup and recovery operations in the case of a catastrophic system failure. These types of file and database controls are discussed further in Hoffer et al. (2016).

Providing Feedback

When talking with a friend, you would be concerned if he or she did not provide you with feedback by nodding and replying to your questions and comments. Without feedback, you would be concerned that he or she was not listening, likely resulting in a less-than-satisfactory experience. Similarly, when designing system interfaces, pro- viding appropriate feedback is an easy method for making a user’s interaction more

Validation Test Description

Class or Composition Test to ensure that data are of proper type (e.g., all numeric, all alphabetic, all alphanumeric) Combinations Test to see if the value combinations of two or more data fields are appropriate or make sense (e.g.,

Does the quantity sold make sense given the type of product?) Expected Values Test to see if data are what is expected (e.g., match with existing customer names, payment amount, etc.) Missing Data Test for existence of data items in all fields of a record (e.g., Is there a quantity field on each line item of

a customer order?) Pictures/Templates Test to ensure that data conform to a standard format (e.g., Are hyphens in the right places for a student

ID number?) Range Test to ensure data are within proper range of values (e.g., Is a student’s grade point average between

0 and 4.0?) Reasonableness Test to ensure data are reasonable for situation (e.g., pay rate for a specific type of employee) Self-Checking Digits Test where an extra digit is added to a numeric field in which its value is derived using a standard formula

(see Figure 11-14) Size Test for too few or too many characters (e.g., Is social security number exactly nine digits?) Values Test to make sure values come from set of standard values (e.g., two-letter state codes)

TABLE 11-9 Validation Tests and Techniques to Enhance the Validity of Data Input

M11_VALA1629_09_GE_C11.indd 408 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 409

enjoyable; not providing feedback is a sure way to frustrate and confuse. There are three types of system feedback:

1. Status information 2. Prompting cues 3. Error or warning messages

Status Information Providing status information is a simple technique for keeping users informed of what is going on within a system. For example, relevant status informa- tion such as displaying the current customer name or time, placing appropriate titles on a menu or screen, or identifying the number of screens following the current one (e.g., Screen 1 of 3) all provide needed feedback to the user. Providing status information dur- ing processing operations is especially important if the operation takes longer than a sec- ond or two. For example, when opening a file you might display “Please wait while I open the file” or, when performing a large calculation, flash the message “Working … ” to the user. Further, it is important to tell the user that besides working, the system has accepted the user’s input and that the input was in the correct form. Sometimes it is important to give the user a chance to obtain more feedback. For example, a function key could toggle between showing a “Working … ” message and giving more specific information as each intermediate step is accomplished. Providing status information will reassure users that nothing is wrong and will make them feel in command of the system, not vice versa.

Prompting Cues A second feedback method is to display prompting cues. When prompting the user for information or action, it is useful to be specific in your request. For example, suppose a system prompted users with the following request:

READY FOR INPUT: ___________

With such a prompt, the designer assumes that the user knows exactly what to enter. A better design would be specific in its request, possibly providing an example,

FIGURE 11-14 Using check digits to verify data correctness

Description Techniques where extra digits are added to a field to assist in verifying its accuracy

Method 1. Multiply each digit of a numeric field by a weighting factor (e.g., 1, 2, 1, 2, _).

2. Sum the results of weighted digits. 3. Divide sum by modulus number (e.g., 10). 4. Subtract remainder of division from modulus number to deter-

mine check digit. 5. Append check digits to field.

Example Assume a numeric part number of: 12473 1-2. Multiply each digit of part number by weighting factor from right

to left and sum the results of weighted digits:

1 2 4 7 3 ×1 ×2 ×1 ×2 ×1

141 + 4 + 4 + + 3 = 26

3. Divide sum by modulus number.

26/10 = 2 remainder 6

4. Subtract remainder from modulus number to determine check digit.

check digit = 10 – 6 = 4

5. Append check digits to field.

Field value with appended check digit = 124734

M11_VALA1629_09_GE_C11.indd 409 08/04/2020 17:31

410 PART IV DESIGN

default values, or formatting information. An improved prompting request might be as follows:

Enter the customer account number (123–456–7): _______-_______-_______

Errors and Warning Messages A final method available to you for providing sys- tem feedback is using error and warning messages. Practical experience has found that a few simple guidelines can greatly improve their usefulness. First, messages should be specific and free of error codes and jargon. Additionally, messages should never scold the user and should attempt to guide the user toward a resolution. For example, a message might say, “No customer record found for that Customer ID. Please verify that digits were not transposed.” Messages should be in user, not computer, terms. Hence, such terms as end of file, disk I/O error, or write protected may be too technical and not helpful for many users. Multiple messages can be useful so that a user can get more detailed explanations if wanted or needed. Also, error messages should appear in roughly the same format and placement each time so that they are recognized as error messages and not as some other information. Examples of good and bad mes- sages are provided in Table 11-10. Using these guidelines, you will be able to provide useful feedback in your designs. A special type of feedback is answering help requests from users. This important topic is described next.

Providing Help

Designing how to provide help is one of the most important interface design issues you will face. When designing help, you need to put yourself in the user’s place. When accessing help, the user likely does not know what to do next, does not understand what is being requested, or does not know how the requested information needs to be formatted. A user requesting help is much like a ship in distress sending an SOS. In Table 11-11, we provide our SOS guidelines for the design of system help: simplicity, organize, and show. Our first guideline, simplicity, suggests that help messages should be short and to the point, and use words that enable understanding. This leads to our second guideline, organize, which means that help messages should be written so that information can be easily absorbed by users. Practical experience has found that long paragraphs of text are often difficult for people to understand. A better design organizes lengthy information in a manner that is easier for users to digest, for example, through the use of bulleted and ordered lists. Finally, it is often useful to explicitly show users how to perform an operation and the outcome of procedural steps. Figures 11-15a and 11-15b show the contrasts between two help screen designs, one that employs our guidelines and one that does not.

Poor Error Messages Improved Error Messages

ERROR 56 OPENING FILE The file name you typed was not found. Press F2 to list valid file names.

WRONG CHOICE Please enter an option from the menu. DATA ENTRY ERROR The prior entry contains a value outside the range of acceptable

values. Press F9 for list of acceptable values. FILE CREATION ERROR The file name you entered already exists. Press F10 if you want

to overwrite it. Press F2 if you want to save it to a new name.

TABLE 11-10 Examples of Poor and Improved Error Messages

Guideline Explanation

Simplicity Use short, simple wording, common spelling, and complete sentences. Give users only what they need to know, with the option to find additional information.

Organize Use lists to break information into manageable pieces. Show Provide examples of proper use and the outcomes of such use.

TABLE 11-11 Guidelines for Designing Usable Help

M11_VALA1629_09_GE_C11.indd 410 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 411

Many commercially available systems provide extensive system help. For example, Table 11-12 lists the range of help available in a popular electronic spreadsheet. Many systems are also designed so that users can vary the level of detail provided. Help may be provided at the system level, screen or form level, and individual field level. The ability to provide field-level help is often referred to as “context-sensitive” help. For some applica- tions, providing context-sensitive help for all system options is a tremendous undertaking that is virtually a project in itself. If you do decide to design an extensive help system with

FIGURE 11-15 Contrasting help screens (a) Poorly designed help display

(Source: Microsoft Corporation.)

(b) Improved design for help display

M11_VALA1629_09_GE_C11.indd 411 08/04/2020 17:31

412 PART IV DESIGN

many levels of detail, you must be sure that you know exactly what the user needs help with, or your efforts may confuse users more than help them. After leaving a help screen, users should always return to where they were prior to requesting help. If you follow these simple guidelines, you will likely design a highly usable help system.

As with the construction of menus, many programming environments provide pow- erful tools for designing system help. For example, Microsoft’s HTML Help environment allows you to quickly construct hypertext-based help systems. In this environment, you use a text editor to construct help pages that can be easily linked to other pages contain- ing related or more specific information. Linkages are created by embedding special characters into the text document that make words hypertext buttons—that is, direct linkages—to additional information. HTML Help transforms the text document into a hypertext document. For example, Figure 11-16 shows a hypertext-based help screen from the Firefox browser. Hypertext-based help systems have become the standard for most commercial applications. This has occurred for two primary reasons. First, standard- izing system help across applications eases user training. Second, hypertext allows users to selectively access the level of help they need, making it easier to provide effective help for both novice and experienced users within the same system.

DESIGNING DIALOGUES The process of designing the overall sequences that users follow to interact with an information system is called dialogue design. A dialogue is the sequence in which infor- mation is displayed to and obtained from a user. As the designer, your role is to select the most appropriate interaction methods and devices (described earlier) and to define the conditions under which information is displayed to and obtained from users. The dialogue design process consists of three major steps:

1. Designing the dialogue sequence 2. Building a prototype 3. Assessing usability

A few general rules that should be followed when designing a dialogue are sum- marized in Table 11-13. For a dialogue to have high usability, it must be consistent in form, function, and style. All other rules regarding dialogue design are mitigated by the consistency guideline. For example, the effectiveness of how well errors are handled or feedback is provided will be significantly influenced by consistency in design. If the system does not consistently handle errors, the user will often be at a loss as to why certain things happen.

One example of these guidelines concerns removing data from a database or file (see the Reversal entry in Table 11-13). It is good practice to display the i nformation that will be deleted before making a permanent change to the file. For example, if the customer service representative wanted to remove a customer from the data- base, the system should ask only for the customer ID in order to retrieve the correct customer account. Once found, and before allowing the confirmation of the deletion,

Dialogue The sequence of interaction between a user and a system.

Type of Help Example of Question

Help on Help How do I get help? Help on Concepts What is a customer record? Help on Procedures How do I update a record? Help on Messages What does “Invalid File Name” mean? Help on Menus What does “Graphics” mean? Help on Function Keys What does each Function key do? Help on Commands How do I use the “Cut” and “Paste” commands? Help on Words What do “merge” and “sort” mean?

TABLE 11-12 Types of Help

M11_VALA1629_09_GE_C11.indd 412 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 413

FIGURE 11-16 Hypertext-based help system from Chrome Web browser

(Source: Google, Inc.)

the system should display the account information. For actions making permanent changes to system data files and when the action is not commonly performed, many system designers use the double-confirmation technique. With this technique, users must confirm their intention twice before being allowed to proceed.

Designing the Dialogue Sequence

Your first step in dialogue design is to define the sequence. In other words, you must first gain an understanding of how users might interact with the system. This means that you must have a clear understanding of user, task, technological, and environ- mental characteristics when designing dialogues. Suppose that the marketing man- ager at Pine Valley Furniture (PVF) wants sales and marketing personnel to be able to review the year-to-date transaction activity for any PVF customer. After talking with the manager, you both agree that a typical dialogue between a user and the Customer Information System for obtaining this information might proceed as follows:

M11_VALA1629_09_GE_C11.indd 413 08/04/2020 17:31

414 PART IV DESIGN

1. Request to view individual customer information 2. Specify the customer of interest 3. Select the year-to-date transaction summary display 4. Review customer information 5. Leave system

As a designer, once you understand how a user wishes to use a system, you can then transform these activities into a formal dialogue specification.

A formal method for designing and representing dialogues is dialogue diagramming. Dialogue diagrams have only one symbol, a box with three sections; each box represents one display (which might be a full screen or a specific form or window) within a dialogue (see Figure 11-17). The three sections of the box are used as follows:

1. Top: Contains a unique display reference number used by other displays for refer- encing it.

2. Middle: Contains the name or description of the display. 3. Bottom: Contains display reference numbers that can be accessed from the current

display.

All lines connecting the boxes within dialogue diagrams are assumed to be bidi- rectional and thus do not need arrowheads to indicate direction. This means that users are allowed to move forward and backward between adjacent displays. If you desire only unidirectional flows within a dialogue, arrowheads should be placed on one end of the line. Within a dialogue diagram, you can easily represent the sequenc- ing of displays, the selection of one display over another, or the repeated use of a single display (e.g., a data entry display). These three concepts—sequence, selection, and iteration—are illustrated in Figure 11-18.

Continuing with our PVF example, Figure 11-19 shows a partial dialogue diagram for processing the marketing manager’s request. In this diagram, the analyst placed

Dialogue diagramming A formal method for designing and rep- resenting human–computer dialogues using box and line diagrams.

Guideline Explanation

Consistency Dialogues should be consistent in sequence of actions, keystrokes, and terminology (e.g., the same labels should be used for the same operations on all screens, and the location of the same information should be the same on all displays).

Shortcuts and Sequence

Allow advanced users to take shortcuts using special keys (e.g., CTRL-C to copy highlighted text). A natural sequence of steps should be followed (e.g., enter first name before last name, if appropriate).

Feedback Feedback should be provided for every user action (e.g., confirm that a record has been added, rather than simply putting another blank form on the screen).

Closure Dialogues should be logically grouped and have a beginning, middle, and end (e.g., the last in the sequence of screens should indicate that there are no more screens).

Error Handling All errors should be detected and reported; suggestions on how to proceed should be made (e.g., suggest why such errors occur and what user can do to correct the error). Synonyms for certain responses should be accepted (e.g., accept either “t,” “T,” or “TRUE”).

Reversal Dialogues should, when possible, allow the user to reverse actions (e.g., undo a deletion); data should not be deleted without confirmation (e.g., display all the data for a record the user has indicated is to be deleted).

Control Dialogues should make the user (especially an experienced user) feel in control of the system (e.g., provide a consis- tent response time at a pace acceptable to the user).

Ease It should be a simple process for users to enter information and navigate between screens (e.g., provide means to move forward, backward, and to specific screens, such as first and last).

(Source: Based on Shneiderman et al., 2016.)

TABLE 11-13 Guidelines for the Design of Human–Computer Dialogues

FIGURE 11-17 Sections of a dialogue diagramming box

Unique Reference Number of Display

Name or Description of Display

Reference Numbers of Return Displays

Top

Middle

Bottom

M11_VALA1629_09_GE_C11.indd 414 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 415

the request to view year-to-date customer information within the context of the overall Customer Information System. The user must first gain access to the system through a log-on procedure (item 0). If log-on is successful, a main menu is displayed that has four items (item 1). Once the user selects the Individual Customer Information (item 2), control is transferred to the Select Customer display (item 2.1). After a customer is selected, the user is presented with an option to view customer information four differ- ent ways (item 2.1.1). Once the user views the customer’s year-to-date transaction activity (item 2.1.1.2), the system will allow the user to back up to select a different customer (2.1), return to the main menu (1), or exit the system (see bottom of item 2.1.1.2).

Building Prototypes and Assessing Usability

Building dialogue prototypes and assessing usability are often optional activities. Some systems may be very simple and straightforward; others may be more complex but are extensions to existing systems where dialogue and display standards have already been established. In either case, you may not be required to build prototypes and do a formal assessment. However, for many other systems, it is critical that you build prototype displays and then assess the dialogue; this can pay numerous dividends later in the systems development life cycle (e.g., it may be easier to implement a system or train users on a system they have already seen and used).

Building prototype displays is often a relatively easy activity if you use graphical development environments such as Microsoft’s Visual Studio.NET. Some systems devel- opment environments include easy-to-use input and output (form, report, or window) design utilities. Tools called “prototypers” or “demo builders” allow you to quickly design displays and show how an interface will work within a full system. For building Web applications, environments that allow you to quickly build wireframes that can be evolved into a working Website are often used for assessing usability (Figure 11-20).

FIGURE 11-18 Dialogue diagram illustrating sequence, selection, and iteration

Sequence

Iteration

Selection

Display A

Display B

Display D

Display C

Display E

M11_VALA1629_09_GE_C11.indd 415 08/04/2020 17:31

416 PART IV DESIGN

These prototypers typically allow users to enter data and move through screens as if using the actual system. Such activities are not only useful for you to show how an inter- face will look and feel, they are also useful for assessing usability and for performing user training long before actual systems are completed. In the next section, we extend our discussion of interface and dialogue design to consider issues specific to graphical user interface environments.

FIGURE 11-19 Dialogue diagram for the customer information system (Pine Valley Furniture) Login

Screen

Main Menu

System

0, System

Reports

0, 1

Individual Customer

Information

0, 1

Order Status

0, 1

Select Customer

2.1

Customer Information

2.1, 1

2.1.1

YTD Summary

1, 2.1, 0

2.1.1.1

YTD Transactions

1, 2.1, 0

2.1.1.2

Lifetime Summary

1, 2.1, 0

2.1.1.3

Lifetime Transactions

1, 2.1, 0

2.1.1.4

Salesperson Information

0, 1

M11_VALA1629_09_GE_C11.indd 416 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 417

DESIGNING INTERFACES AND DIALOGUES IN GRAPHICAL ENVIRONMENTS Graphical user interface (GUI) environments have become the de facto standard for human–computer interaction. Although all of the interface and dialogue design guidelines presented previously apply to designing GUIs, additional issues that are unique to these environments must be considered. Here, we briefly discuss some of these issues.

Graphical Interface Design Issues

When designing GUIs for an operating environment such as Microsoft Windows or the Apple macOS, numerous factors must be considered. Some factors are common to all GUI environments, whereas others are specific to a single environment. We will not, however, discuss the subtleties and details of any single environment. Instead, our discussion will focus on a few general truths that experienced designers mention as critical to the design of usable GUIs (Coleman & Goodwin, 2017; Cooper, Rei- mann, Cronin, & Noessel, 2014; Krug, 2014; Nielsen & Loranger, 2006; Shneiderman et al., 2016). In most discussions of GUI programming, two rules repeatedly emerge as composing the first step to becoming an effective GUI designer:

1. Become an expert user of the GUI environment. 2. Understand the available resources and how they can be used.

The first step should be an obvious one. The greatest strength of designing within a standard operating environment is that standards for the behavior of most system operations have already been defined. For example, how you cut and paste, set up your default printer, design menus, or assign commands to functions have been standardized both within and across applications. This allows experienced users of one GUI-based application to easily learn a new application. Thus, in order to design effective interfaces in such environments, you must first understand how other appli- cations have been designed so that you will adopt the established standards for “look and feel.” Failure to adopt the standard conventions in a given environment will result in a system that will likely frustrate and confuse users.

FIGURE 11-20 Wireframes are often used for testing usability

M11_VALA1629_09_GE_C11.indd 417 08/04/2020 17:31

418 PART IV DESIGN

The second rule—gaining an understanding of the available resources and how they can be used—is a much larger undertaking. For example, within Windows you can use menus, forms, and boxes in many ways. In fact, the flexibility with which these resources can be used versus the established standards for how most designers actually use these resources makes design especially challenging. For example, you have the ability to design menus using all uppercase text, putting multiple words on the top line of the menu, and other nonstandard conventions. Yet the standards for menu design require that top-level menu items consist of one word and follow a specific ordering. Numerous other standards for menu design have also been established (see Figure 11-21 for illustrations of many of these standards). Failure to follow standard design conventions will likely prove very confusing to users.

In GUIs, information is requested by placing a window (or form) on the visual display screen. Like menu design, forms can also have numerous properties that can be mixed and matched (see Table 11-14). For example, properties about a form deter- mine whether a form is resizable or movable after being opened. Because properties define how users can actually work with a form, the effective application of properties is fundamental to gaining usability. This means that, in addition to designing the lay- out of a form, you must also define the “personality” of the form with its characteristic properties. Fortunately, numerous GUI design tools have been developed that allow you to “visually” design forms and interactively engage properties. Interactive GUI design tools have greatly facilitated the design and construction process.

In addition to the issues related to interface design, the sequencing of displays turns out to be a bit more challenging in graphical environments. This topic is dis- cussed next.

FIGURE 11-21 Highlighting GUI design standards

(Source: Microsoft Corporation.)

Right arrow shows that an item leads to a submenu

Help menu item is always last item (if present)

Edit menu item is always second item (if present)

File menu item is always first item (if present)

M11_VALA1629_09_GE_C11.indd 418 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 419

Dialogue Design Issues in a Graphical Environment

When designing a dialogue, your goal is to establish the sequence of displays (full screens or windows) that users will encounter when working with the system. This process can be a bit more challenging due to the GUI’s ability to suspend activities (without resolving a request for information or exiting the application altogether) and switch to another application or task. For example, within Microsoft Word, the spell-checker executes independently from the general word processor. This means that you can easily jump between the spell-checker and word processor without exit- ing either one. Conversely, when selecting the print operation, you must either initi- ate printing or abort the request before returning to the word processor. This is an example of the concept of “modality” described in Table 11-14. Thus, Windows-type environments allow you to create forms that either require the user to resolve a request before proceeding (print example) or selectively choose to resolve a request before pro- ceeding (the spell-checker). Creating dialogues that allow the user to jump from appli- cation to application or from module to module within a given application requires that you carefully think through the design of dialogues.

One easy way to deal with the complexity of designing advanced GUIs is to require users to always resolve all requests for information before proceeding. For such designs, the dialogue diagramming technique is an adequate design tool. This, however, would make the system operate in a manner similar to a traditional non-GUI environment where the sequencing of displays is tightly controlled. The drawback to such an approach would be the failure to capitalize on the task-switching capabilities of these environments. Consequently, designing dialogues in environments where the sequence between displays cannot be predetermined offers significant challenges to the designer. Using tools such as dialogue diagramming helps analysts to better man- age the complexity of designing graphical interfaces.

ELECTRONIC COMMERCE APPLICATION: DESIGNING INTERFACES AND DIALOGUES FOR PINE VALLEY FURNITURE’S WEBSTORE Designing the human interface for an Internet-based electronic commerce appli- cation is a central and critical design activity. Because this is where a customer will interact with a company, much care must be put into its design. Like the process fol- lowed when designing the interface for other types of systems, a prototyping design process is most appropriate when designing the human interface for an Internet electronic commerce system. Although the techniques and technology for building the human interface for Internet sites is rapidly evolving, several general design

Property Explanation

Modality Requires users to resolve the request for information before proceeding (e.g., need to cancel or save before closing a window)

Resizable Allows users to resize a window or form (e.g., to make room to see other windows that are also on the screen) Movable Allows users to move a window or form (e.g., to allow another window to be seen) Maximize Allows users to expand a window or form to a full-size screen (e.g., to avoid distraction from other active windows or

forms) Minimize Allows users to shrink a window or form to an icon (e.g., to get the window out of the way while working on other

active windows) System Menu Allows a window or form to also have a system menu to directly access system-level functions (e.g., to save or copy

data)

(Source: Based on Wagner, 1994.)

TABLE 11-14 Common Properties of Windows and Forms in a GUI Environment That Can Be Active or Inactive

PINE VALLEY FURNITURE

M11_VALA1629_09_GE_C11.indd 419 08/04/2020 17:31

420 PART IV DESIGN

guidelines have emerged. In this section, we examine some of these as they apply to the design of PVF’s WebStore.

General Guidelines

Over the years, interaction standards have emerged for virtually all of the com- monly used desktop computing environments such as Windows or macOS. However, some interface design experts believe that the growth of the Web has resulted in a big step backward for interface design. One problem, as discussed in Chapter 10, is that countless nonprofessional developers are designing commercial Web appli- cations. In addition to this, there are four other important contributing factors ( Johnson, 2007):

1. The Web’s single “click-to-act” method of loading static hypertext documents (i.e., most buttons on the Web do not provide click feedback)

2. Limited capabilities of most Web browsers to support finely grained user interactivity

3. Limited agreed-upon standards for encoding Web content and control mechanisms

4. Lack of maturity of Web scripting and programming languages as well as limita- tions in commonly used Web GUI component libraries

In addition to these contributing factors, designers of Web interfaces and dia- logues are often guilty of many design errors. Although not inclusive of all possible errors, Table 11-15 summarizes those errors that are particularly troublesome. Fortu- nately, there are numerous excellent sources on how to avoid these and other inter- face and design errors (Cooper et al., 2014; Flanders & Peters, 2002; Krug, 2014; Johnson, 2007; Nielsen, 2000; Seffah & Javahery, 2003; http://www.nngroup.com/; http://www.webpagesthatsuck.com/).

Error Description

Opening New Browser Window Avoid opening a new browser window when a user clicks on a link unless it is clearly marked that a new window will be opened; users may not see that a new window has been opened, which will complicate navigation, especially moving backward.

Breaking or Slowing Down the Back Button

Make sure users can use the back button to return to prior pages. Avoid opening new browser windows, using an immediate redirect where, when users click the back button, they are pushed forward to an undesired location, or prevent caching such that each click of the back button requires a new trip to the server.

Complex URLs Avoid overly long and complex URLs because it makes it more difficult for users to understand where they are and can cause problems if users want to e-mail page locations to colleagues.

Orphan Pages Avoid having pages with no “parent” that can be reached by using a back button; requires users to “hack” the end of the URL to get back to some other prior page.

Scrolling Navigation Pages Avoid placing navigational links below where a page opens because many users may miss these important options that are below the opening window.

Lack of Navigation Support Make sure your pages conform to users’ expectations by providing commonly used icon links such as a site logo at the top or other major elements. Also place these elements on pages in a con- sistent manner.

Hidden Links Make sure you leave a border around images that are links, don’t change link colors from normal defaults, and avoid embedding links within long blocks of text.

Links That Don’t Provide Enough Information

Avoid not turning off link-marking borders so that links clearly show which links users have clicked and which they have not. Make sure users know which links are internal anchor points versus external links, and indicate if a link brings up a separate browser window from those that do not. Finally, make sure link images and text provide enough information to users so that they under- stand the meaning of the link.

Buttons That Provide No Click Feedback

Avoid using image buttons that don’t clearly change when being clicked; use Web GUI toolkit but- tons, HTML form-submit buttons, or simple textual links.

TABLE 11-15 Common Errors When Designing the Interface and Dialogues of Websites

M11_VALA1629_09_GE_C11.indd 420 08/04/2020 17:31

http://www.nngroup.com/

http://www.webpagesthatsuck.com/

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 421

Designing Interfaces and Dialogues at Pine Valley Furniture

To establish design guidelines for the human–computer interface, Jim Woo and the PVF development team again reviewed many popular electronic commerce Web- sites. The key feature they wanted to incorporate into the design was an interface with “menu-driven navigation with cookie crumbs.” In order to ensure that all team members understood what was meant by this guideline, Jim organized a design briefing to explain how this feature would be incorporated into the WebStore interface.

Menu-Driven Navigation with Cookie Crumbs

After reviewing several sites, the team concluded that menus should stay in the exact same place throughout the entire site. They concluded that placing a menu in the same location on every page will help customers to more quickly become famil- iar with the site and therefore more rapidly navigate it. Experienced Web develop- ers know that the quicker customers can reach a specific destination at a site, the quicker they can purchase the product they are looking for or get the information they seek. Jim emphasized this point by stating, “These details may seem silly, but the second a user finds themselves ‘lost’ in our site, they’re gone. One mouse click and they’re no longer shopping at Pine Valley, but at one of our competitor’s sites.”

A second design feature, and one that is being used on many electronic com- merce sites, is cookie crumbs (see Figure 11-22). Cookie crumbs are “tabs” or sequenced links on a Web page that show a user where he or she is within a site and where he or she has been. These tabs or sequenced link are hypertext links that can be used to quickly move backward in the site. For example, suppose that a site is four levels deep, with the top level called “Log in,” the second called “Shipping & Payment,” the third called “Review Order,” and the fourth called “Confirmation.” As the user moves deeper into the site, a tab or sequenced link is displayed across the top of the page showing the user where he or she is, giving the user the ability to quickly jump backward one or more levels. In other words, when first entering the store, a tab or link will be displayed at the top (or some other standard place) of the screen with the word “Log in.” After moving down a level, two links will be displayed, “Log in” and “Shipping & Payment.” After providing the shipping and payment information on the second level, a third level is displayed where a user can review the order information. When this level is displayed, a third link is provided

Cookie crumbs The technique of placing “tabs” or sequenced links on a Web page that show a user where he or she is within a site and where he or she has been.

FIGURE 11-22 Cookie crumbs help users know where they are within a Website

Cookie Crumbs

M11_VALA1629_09_GE_C11.indd 421 08/04/2020 17:31

422 PART IV DESIGN

with the label “Review Order.” Finally, if the customer decides to place an order and selects this option, a fourth-level screen is displayed and a fourth link is displayed with the label “Confirmation.”

1. Level 1: Log in 2. Level 2: Log in S Shipping & Payment 3. Level 3: Log in S Shipping & Payment S Review Order 4. Level 4: Log in S Shipping & Payment S Review Order S Confirmation

By using cookie crumbs, users know exactly how far they have wandered from “home.” If each tab is a link, users can quickly jump back to a broader part of the store should they not find exactly what they are looking for. Cookie crumbs serve two important purposes: First, they allow users to navigate to a point previously visited and will ensure that they are not lost. Second, they clearly show users where they have been and how far they have gone from home.

SUMMARY In this chapter, our focus was to acquaint you with the process of designing human–computer interfaces and dialogues. It is imperative that you understand the char- acteristics of various interaction methods (command lan- guage, menu, form, object, natural language) and devices (keyboard, mouse, joystick, trackball, touch screen, light pen, graphics tablet, voice). No single interaction style or device is the most appropriate in all instances: Each has its strengths and weaknesses. You must consider the character- istics of the intended users, the tasks being performed, and various technical and environmental factors when making design decisions.

The chapter also reviewed design guidelines for computer-based forms. You learned that most forms have a header, sequence or time-related information, instructions, a body, summary data, authorization, and comments. Users must be able to move the cursor position, edit data, exit with different consequences, and obtain help. Techniques for structuring and controlling data entry were presented along with guidelines for providing feedback, prompts, and error messages. A simple, well-organized help function that shows examples of proper use of the system should be pro- vided. A variety of help types were reviewed.

Next, guidelines for designing human–computer dialogues were presented. These guidelines are consis- tency, allowing for shortcuts, providing feedback and closure on tasks, handling errors, allowing for operations reversal, giving the user a sense of control, and ease of

navigation. We also discussed dialogue diagramming as a design tool. Assessing the usability of dialogues and pro- cedures was also reviewed. Several interface and dialogue design issues were described within the context of design- ing GUIs. These included the need to follow standards to provide the capabilities of modality, resizing, moving, and maximizing and minimizing windows, and to offer a system menu choice. This discussion highlighted how concepts presented earlier in this chapter can be applied or augmented in these emerging environments. Finally, interface and dialogue design issues for Internet-based applications were discussed, and several common design errors were highlighted.

Our goal was to provide you with a foundation for building highly usable human–computer interfaces. As more and more development environments provide rapid prototyping tools for the design of interfaces and dialogues, many complying with common interface standards, the dif- ficulty of designing usable interfaces will be reduced. How- ever, you still need a solid understanding of the concepts presented in this chapter in order to succeed. Learning to use a computer system is like learning to use a parachute: If a person fails on the first try, odds are he or she won’t try again (Blattner & Schultz, 1988). If this analogy is true, it is important that a user’s first experience with a system be a positive one. By following the design guidelines outlined in this chapter, your chances of providing a positive first experience to users will be greatly enhanced.

KEY TERMS

11.1 Command language interaction 11.2 Cookie crumbs 11.3 Dialogue 11.4 Dialogue diagramming

11.5 Drop-down menu 11.6 Form interaction 11.7 Icon 11.8 Interface

11.9 Menu interaction 11.10 Natural language interaction 11.11 Object-based interaction 11.12 Pop-up menu

M11_VALA1629_09_GE_C11.indd 422 08/04/2020 17:31

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 423 Match each of the key terms above to the definition that best fits it.

____ A method by which users interact with information systems.

____ A human–computer interaction method whereby users enter explicit statements into a system to invoke operations.

____ A formal method for designing and representing human– computer dialogues using box and line diagrams.

____ A menu-positioning method that places a menu near the current cursor position.

____ A human–computer interaction method whereby a list of sys- tem options is provided and a specific command is invoked by user selection of a menu option.

____ The technique of placing “tabs” or sequenced links on a Web page to show a user where he or she is within a site and where he or she has been.

____ A menu-positioning method that places the access point of the menu near the top line of the display; when accessed, menus open by dropping down onto the display.

____ A highly intuitive human–computer interaction method whereby data fields are formatted in a manner similar to paper-based forms.

____ A human–computer interaction method whereby symbols are used to represent commands or functions.

____ Graphical pictures that represent specific functions within a system.

____ A human–computer interaction method whereby inputs to and outputs from a computer-based application are in a con- ventional speaking language such as English.

____ The sequence of interaction between a user and a system.

REVIEW QUESTIONS 11.13 What does the term “usability” refer to? What is the name

of the academic field?

11.14 Describe the process of designing interfaces and dia- logues. What deliverables are produced from this process? Are these deliverables the same for all types of system proj- ects? Why or why not?

11.15 Describe five methods of interacting with a system. Is one method better than all others? Why or why not?

11.16 Describe several input devices for interacting with a sys- tem. Is one device better than all others? Why or why not?

11.17 What is the difference between command language inter- action and natural language interaction?

11.18 Form interaction is effective for input and presentation of information. What are the most important things to con- sider when designing a form?

11.19 What is the difference between a pop-up menu and a drop-down menu?

11.20 Describe the general guidelines for structuring data entry fields. Can you think of any instances when it would be appropriate to violate these guidelines?

11.21 When designing dialogues (and in many other cases when designing software interfaces), consistency is a key word. What does it mean?

11.22 What are the three sections of a dialogue diagramming box?

11.23 What are the main reasons for prototyping?

11.24 Describe the general guidelines for designing usable help. Can you think of any instances when it would be appropri- ate to violate these guidelines?

11.25 What steps do you need to follow when designing a dia- logue? Of the guidelines for designing a dialogue, which is most important? Why?

11.26 The last two decades have seen a new design paradigm, courtesy of the advent and popularity of the Internet. When it comes to interface design, this evolution could be seen as a step backward. What is the reason for this claim; that is, what are the design limitations of Websites?

11.27 Figure 11-2 shows a form for reporting a customer’s pur- chasing activities. The form looks nice, but there are some areas where it could be improved. Which areas are they?

PROBLEMS AND EXERCISES 11.28 List the keyboard shortcut keys you use for operating com-

mands in Microsoft Word and Microsoft PowerPoint if you are a Windows user and in iWork if you are a macOS user. Search the Internet to find more shortcut key commands that are commonly used.

11.29 There are two methods for positioning menus. Briefly describe their potential applicability in Microsoft Word. Which menu is more interactive and convenient for a systems analyst to use? Give reasons to justify your answer.

11.30 Shortlist some of the elements of your institute’s Website, like courses, activities, events, and library. Discuss them with three of your classmates and make a partial dialogue diagram. Now visit the Website and compare the actual dialogue box with the partial dialogue diagram. Make a report highlighting the effectiveness of the dialogue box of your institute.

11.31 Take a look at the device types listed in this chapter for interact- ing with a system. Many new ways of interacting with systems have been introduced in recent years. Can any of them also be used for interacting with a typical information system (such as handling invoices, customer relations, or student grades)?

11.32 Take a close look at the ribbon interface of Microsoft Office. Try to get hold of either old versions of Microsoft Office or screenshots from that software package. Compare the differences in the performance of various tasks, such as an operation for adjusting the looks of a paragraph in a Word document. Which option seems most natural to you? Which takes the least amount of time to work with?

11.33 Visit the computer lab at your institute. List the hardware avail- able there and compare your list with the one in Table 11-2. If applicable, highlight any hardware devices not listed in the table that are available in your computer lab.

M11_VALA1629_09_GE_C11.indd 423 08/04/2020 17:31

424 PART IV DESIGN

REFERENCES Coleman, B., & Goodwin, D. (2017). Designing UX: Prototyp-

ing: Because modern design is never static. Collingwood, VIC, Australia: SitePoint.

Cooper, A., Reimann, R., Cronin, D., & Noessel, C. (2014). About face: The essentials of interaction design (4th ed.). New York: Wiley and Sons.

Enders, J. (2016). Designing UX: Forms: Create forms that don’t drive users crazy. Collingwood, VIC, Australia: SitePoint.

Flanders, V., & Peters, D. (2002). Son of web pages that suck: Learn good design by looking at bad design. Alameda, CA: Sybex Publishing.

Hoffer, J. A., Ramesh, V., & Topi, H. (2016). Modern database management (12th ed.). Upper Saddle River, NJ: Prentice Hall.

Johnson, J. (2007). GUI bloopers 2.0: Common user interface design don’ts and dos (2nd ed.). New York: Morgan Kaufmann.

Krug, S. (2014). Don’t make me think: A common sense approach to web usability (3rd ed.). Upper Saddle River, NJ: Prentice Hall.

Lazar, J. (2004). User-centered web development: Theory into practice. Sudbury, MA: Jones & Bartlett.

McCracken, D. D., Wolfe, R. J., & Spoll, J. M. (2004). User centered web site development: A human–computer interaction approach. Upper Saddle River, NJ: Prentice Hall.

Nielsen, J. (2000). Designing web usability: The practice of simplicity. Indianapolis, IN: New Riders Publishing.

Nielsen, J., & Loranger, H. (2006). Prioritizing web usability. Upper Saddle River, NJ: Prentice Hall.

Pogue, D. (2015). OX X Yosemite: The missing manual. Sebastopol, CA: O’Reilly Media.

Schooley, B. (2013). Designing for Windows 8: Fundamentals of great design in Windows store apps. New York, NY: Apress.

Seffah, A., & Javahery, H. (2003). Multiple user interfaces: Cross- platform applications and context-aware interfaces. New York: John Wiley & Sons.

Te’eni, D., Carey, J., & Zhang, P. (2006). Human–computer interac- tion: Developing effective organizational information systems. New York: John Wiley & Sons.

11.34 Try to find some documentation of keyboard shortcuts for very common software, such as Microsoft Office and Adobe Creative Suite (or their open-source counterparts). How similar are these shortcuts? For example, does shift-click or shift-drag do the same thing in these applications?

11.35 Refer to Table 11-14 and look at the modality property. Find out different operations in Microsoft Word that fall under modality.

11.36 Explore Gmail’s e-mail registration form. As a user reg- istering for a new e-mail ID, comment on the functional capability for smooth and easy navigation in the form and compare it with the data entry screen functional capabilities given in Table 11-5.

11.37 To ensure that the correct (valid) data is being supplied to a database, a number of tests can be run. Think of 10 differ- ent tests to accomplish this task. Then compare your ideas to Table 11-9. Did you come up with the same or different things?

11.38 There are many open-source as well as freeware applica- tions that shouldn’t be overlooked. Compare Microsoft Word with OpenOffice and Google Docs. What are the main differences between the applications? Which of them seems to have the most features? Which has the most attractive user interface, in your opinion?

11.39 There is a lot of research being conducted on ways of inter- acting with computer systems. Look at what is presented on the Websites for MIT, Google, HP Labs, and similar organizations. Do some research through computer maga- zines or their corresponding Websites as well. What new ways for interaction do you find? Do you think any of them will replace the more traditional ways, such as working with a computer and a mouse?

11.40 Visit your institute’s Website. Referring to Figure 11-5, list the various types of menus used in it and explain their effectiveness.

FIELD EXERCISES 11.41 One novel invention when it comes to user interaction is

Microsoft’s Kinect, which tracks user movements via thou- sands of infrared dots. Read more on the Kinect on Wiki- pedia or other sources. Consider how Kinect can be used in combination with information systems, how it could be adapted to fit a common information system’s needs, and how the information system could be adapted to fit it. Cre- ate a scenario in which adapted versions of an informa- tion system and Kinect could work together, perhaps even improving usability in some situations.

11.42 Examine two PC-based GUIs (e.g., Microsoft’s Windows and Apple’s macOS). If you do not own these interfaces, you are likely to find them at your university or workplace, or at a computer retail store. You may want to supplement your hands-on evaluation with recent formal evaluations published on the Web. In what ways are these two interfaces similar and different? Are these interfaces intuitive? Why or why not? Is one more intuitive than the other? Why or why

not? Which interface seems easier to learn? Why? What types of system requirements does each interface have? What are the costs of each interface? Which do you prefer? Why?

11.43 Interview a variety of people about the various ways they interact, in terms of inputs, with systems at their work- places. What types of technologies and devices are used to deliver these inputs? Are the input methods and devices easy to use, and do they help these people complete their tasks effectively and efficiently? Why or why not? How could these input methods and devices be improved?

11.44 Try to get hold of a few smartphones or tablets support- ing natural language interaction, such as Apple’s Siri or Microsoft’s Cortana (note that some of these systems are only available in certain countries). If possible, try to speak the same words to the different devices and see what hap- pens. For example, ask Cortana or Siri for directions to a restaurant and see if they direct you to the same place. Which system do you prefer, and why?

M11_VALA1629_09_GE_C11.indd 424 08/04/2020 17:31

Chapter 11: Designing Interfaces and Dialogues

Jim Watanabe, project director for the “No Customer Escapes” customer loyalty system for Petrie Electronics, walked into the conference room. Sally Fukuyama, from marketing, and Sanjay Agarwal, from IT, were already there. Also at the meeting was Sam Waterston, one of Pet- rie’s key interface designers.

“Good morning,” Jim said. “I’m glad everyone could be here today. I know you are all busy, but we need to make some real progress on the customer account area for ‘No Customer Escapes.’ We have just awarded the development of the system to XRA, and once all the documents are signed, they will be coming over to brief us on the imple- mentation process and our role in it.”

“I’m sorry,” Sally said, “I don’t understand. If we are licensing their system, what’s left for us to do? Don’t we just install the system and we’re done?” Sally took a big gulp of coffee from her cup.

“I wish it were that easy,” Jim said. “While it is true that we are licensing their system, there are many parts of it that we need to customize for our own particular needs. One obvious area we need to customize is all of the human

interfaces. We don’t want the system to look generic to our loyal customers—we need to make it unique to Petrie.”

“And we have to integrate the XRA system with our own operations,” added Sanjay. “For example, we have to inte- grate our existing marketing and product databases with the XRA CRM (see PE Figure 7-2). That’s just one piece of all the technical work we have to do.”

“We’ve already done some preliminary work on system functionality and the conceptual database,” Jim said. “I want to start working on interface issues now. That’s why Sam is here. What we want to do today is start work on how the customer account area should look and operate. And, Sally, the customer loyalty site is a great opportunity for marketing. We can advertise specials and other promotions to our best customers on this site. Maybe we could use it to show offers that are only good for members of our loyalty program.”

“Oh yeah,” Sally replied. “That’s a great idea. How would that look?”

“I have ideas,” said Sam. Using a drawing program on a tablet PC, he started to draw different zones that would be part of the interface. “Here at the top we would have a simple banner that says ‘Petrie’s’ and the name of the program.”

CHAPTER 11 DesIgnIng Interfaces anD DIalogues 425

PETRIE ELECTRONICS

PE FIGURE 11-1 Preliminary design for the customer account area

(Source: Microsoft Corporation.)

M11_VALA1629_09_GE_C11.indd 425 08/04/2020 17:31

“It’s not really going to be called ‘No Customer Escapes,’ is it?” asked Sally.

“No, that’s an internal name,” replied Jim, “but I don’t know what the real name will be yet.”

“OK, so the real name of the program will go in the banner, after ‘Petrie’s.’ Then on the left side, we’ll have a sidebar that has overview information about the customer account, things like name and points balance,” said Sam, drawing in a sidebar on the left of the screen. “There will also be links to more detailed information about the account, so the customer can see more details on past transactions and on his or her profile.”

“So the rest of the screen is open. That would be a per- fect place for marketing information,” suggested Sally. “Would we want just one big window for marketing? Maybe we could divide it up into additional windows, so we could use one to focus on general promotions and one to adver- tise ‘member only’ promotions?”

“Yeah, we can do that,” said Sam. Just then Jim’s phone beeped. Jim looked at it. Uh-oh,

it was an urgent message from his boss, the director of IT. “Sorry, I need to take care of this immediately,” he told the group. “Can you guys work on this some more and then send me some of the screen designs you come up with?”

Later that afternoon, after the crisis was over, Jim sat back down at his desk for the first time in what seemed like a very

long time. He glanced over his e-mail and noticed there was a message from Sam. Attached was a preliminary design for the customer account area. Jim opened it and looked it over (PE Figure 11-1). Hmmm, not bad, he thought. This is a good place for us to start.

Case Questions

11.45 Using the guidelines from this chapter and other sources, evaluate the usability of the page design depicted in PE Figure 11-1.

11.46 Chapter 11 encourages the design of a help system early in the design of the human interface. How would you incorporate help into the interface shown in PE Figure 11-1?

11.47 Describe how cookie crumbs could be used in this system. Are cookie crumbs a desirable navigation aid for this system? Why or why not?

11.48 The page design depicted in PE Figure 11-1 links to an Order History page. Sketch a similar layout for the Order History page, following guidelines from Chapter 11.

11.49 Describe how the use of template-based HTML might be leveraged in the design of the “No Customer Escapes” system.

426 PART IV DESIGN

M11_VALA1629_09_GE_C11.indd 426 08/04/2020 17:31

427

Designing Distributed and Internet Systems12

Advances in computing technology and the rapid evolu- tion of mobile technologies are changing the way today’s computing systems are being used to meet ever more demanding business needs. Existing models of managing computing resources are quickly evolving to cloud com- puting-based and service-oriented architectures.

A variety of new opportunities and competitive pres- sures are driving the trend toward these technologies. Corporate restructuring—mergers, acquisitions, and con- solidations—requires the integration of disparate systems. Applications are being downsized from expensive main- frames and dedicated data centers to both public and pri- vate cloud-based architectures that are much more cost effective, scalable, and manageable. The explosion of elec- tronic and mobile commerce is today’s biggest driver for developing new types of systems. How systems are designed can significantly influence system performance, usability, and maintenance.

DESIGNING DISTRIBUTED AND INTERNET SYSTEMS In this section, we briefly discuss the process and deliver- ables in designing distributed and Internet systems. Given the direction of organizational change and technological evolution, it is likely that most future systems development

efforts will need to consider the issues surrounding the design of distributed and Internet-based systems.

The Process of Designing Distributed and Internet Systems

This is the last chapter in the text that deals with system design within the systems development life cycle (see Figure 12-1). In the previous chapters on system design, specific techniques for representing and refining data, screens, interfaces, and design specifications were presented. In this chapter, however, no specific techniques will be presented on how to represent the design of distrib- uted and Internet systems because no generally accepted techniques exist. Alternatively, we will focus on increasing your awareness of common environments for deploying these systems and the issues you will confront surrounding their design and implementation. To distinguish between distributed and Internet-focused system design, we will use “distributed” to refer to LAN-based file server and client/ server architectures.

Designing distributed and Internet systems is much like designing single-location systems. The primary dif- ference is that, because such a system will be deployed over two or more locations, many more design issues must be considered that will influence the reliabil- ity, availability, and survivability of the system once it is

12.3 describe standards shaping the design of Internet- based systems, options for ensuring Internet design consistency, site management issues influencing customer loyalty, trustworthiness, and security.

Learning Objectives After studying this chapter, you should be able to:

12.1 distinguish between file server and client/server environments, contrasting how each is used in a LAN;

12.2 describe cloud computing and other current trends that help organizations address IS infra- structure-related challenges; and

Introduction

M12_VALA1629_09_GE_C12.indd 427 15/04/2020 11:51

428 PART IV DESIGN

implemented. Because distributed and Internet systems have more components than a single-location system—that is, more processors, networks, locations, data, and so on—there are more potential places for a failure to occur. Consequently, various strategies can be used when designing and implementing these systems to minimize points of failure.

Thus, when designing distributed and Internet systems, you will need to consider numerous trade-offs. To create effective designs, you need to understand the charac- teristics of the architectures commonly used to support these systems.

Deliverables and Outcomes

When designing distributed and Internet systems, the deliverable is a document that will consolidate the information that must be considered when implementing a system design. Figure 12-2 lists the types of information that should be consid- ered when implementing such a system. In general, the information that must be considered is the site, processing needs, and data information for each location (or processor) in the distributed environment. Specifically, information related to physical distances between locations, counts and usage patterns by users, building and location infrastructure issues, personnel capabilities, data usage (create, use, update, or destroy), and local organizational processes should be described. Addi- tionally, the pros and cons of various implementation solutions for each location should be reviewed. The collection of this information, in conjunction with the physical design information already developed, will provide the basis for imple- menting the information system in the distributed environment. Note, however, that our discussion assumes that any required information systems infrastructure is already in place. In other words, we focus only on those issues in which you will likely have a choice.

FIGURE 12-1 Systems development life cycle

DesignImplementation

Planning

Maintenance Analysis

Databases Forms and Reports Dialogues and Interfaces Distributed and Internet Systems

M12_VALA1629_09_GE_C12.indd 428 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 429

DESIGNING LAN AND CLIENT/SERVER SYSTEMS In this section, we focus on issues related to the design of distributed systems that use LAN-based file server or client/server architectures. The section begins by providing a high-level description of both architectures. This is followed by a brief description of advanced client/server designs using middleware to create a more robust system deployment model.

Designing Systems for LANs

Personal computers and workstations can be used as stand-alone systems to support local applications. However, organizations have discovered that if data is valuable to one employee, it is probably also valuable to other employees in the same workgroup or in other workgroups. By interconnecting their computers, workers can exchange information electronically and can also share devices such as printers that may be too expensive to be utilized by only a single user.

A local area network (LAN) supports a network of personal computers, each with its own storage; each computer is able to share common devices and software attached to the LAN. Each PC and workstation on a LAN is typically within a few hundred feet of another, with a total network cable length of less than 1 mile. Usually, at least one computer (a microcomputer or larger) is designated as a file server, on which shared databases and applications are stored. The LAN modules of a DBMS, for example, add concurrent access controls, possibly extra security features, and query or transaction queuing management to support concurrent access from multiple users of a shared database.

File Servers In a basic LAN environment (see Figure 12-3), all data manipulation occurs at the workstations from which data are requested. One or more file servers are attached to the LAN. A file server is a device that manages file operations and is shared by each client PC that is attached to the LAN. In a file server configuration,

Local area network (LAN) The cabling, hardware, and software used to connect workstations, computers, and file servers located in a confined geographical area (typically within one building or campus).

File server A device that manages file operations and is shared by each client PC attached to a LAN.

FIGURE 12-2 Outcomes and deliverables from designing distributed systems

1. Description of Site (for each site) a. geographical information b. physical location c. infrastructure information d. personnel characteristics (education, technical skills, etc.) e. . . .

2. Description of Data Usage (for each site) a. data elements used b. data elements created c. data elements updated d. data elements deleted

3. Description of Business Process (for each site) a. list of processes b. description of processes

4. Contrasts of Alternative IS Architectures for Site, Data, and Process Needs (for each site) a. pros and cons of no technological support b. pros and cons of non-networked, local system c. pros and cons of various distributed configurations d. . . .

M12_VALA1629_09_GE_C12.indd 429 15/04/2020 11:51

430 PART IV DESIGN

each file server acts as an additional hard disk for each client PC. For example, your PC might recognize a logical F: drive, which is actually a disk volume stored on a file server on the LAN. Programs on your PC refer to files on this drive by the typical path specification, using this drive and any directories, as well as the file name.

When using a DBMS in a file server environment, each client PC is authorized to use the DBMS application program on that PC. Thus, there is one database on the file server and many concurrently running copies of the DBMS on each active PC client. The primary characteristic of a client-based LAN is that all data manipulation is per- formed at the client PC, not at the file server. The file server acts simply as a shared data storage device and is an extension of a typical PC. It also provides additional resources (e.g., disk drives, shared printing) and collaborative applications (e.g., e-mail) in addi- tion to the shared data. Software at the file server only queues access requests; it is up to the application program at each client PC, working with the copy of the DBMS on that PC, to handle all data management functions. This means that, in an application that wants to view a single customer account record in a database stored on the server, the file containing all customer account records will be sent over the network to the PC. Once at the PC, the file will be searched to find the desired record. Additionally, data security checks and file and record locking are done at the client PCs in this envi- ronment, making multiple-user application development a relatively complex process.

Limitations of File Servers There are three primary limitations when using file servers on LANs:

1. Excessive data movement 2. The need for a powerful client workstation 3. Decentralized data control

First, when using a file server architecture, considerable data movement is gen- erated across the network. For example, when an application program running on a client PC in Pine Valley Furniture (PVF) wants to access the birch products, the whole product table is transferred to the client PC; then the table is scanned at the client to find the few desired records. Thus, the server does very little work, the client is busy

FIGURE 12-3 File server model

• Requests for data • Requests to lock data

• Entire file of data • Lock status

Client • Process/scan tables • Application program – user interface – database processing – generate queries • Handle integrity and security • Full DBMS

File Server • File storage • Record locking • Acts like extra hard disk to client • Not very busy • Significant LAN traffic

Client

File Server

Local Area Network

Data

M12_VALA1629_09_GE_C12.indd 430 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 431

with extensive data manipulation, and the network is transferring large blocks of data (see Figure 12-4). Consequently, a client-based LAN places a considerable burden on the client PC to carry out functions that have to be performed on all clients and cre- ates a high network traffic load.

Second, because each client workstation must devote memory to a full version of the DBMS, there is less room on the client PC to rapidly manipulate data in high- speed random access memory (RAM). Often, data must be swapped between RAM and a relatively slower hard disk when processing a particularly large database. Fur- ther, because the client workstation does most of the work, each client must be rather powerful to provide a suitable response time. File server architectures also benefit from having a very fast hard disk and cache memory in both clients and the server to enhance their ability to transfer files to and from the network, RAM, and hard disk.

Third, and possibly most important, the DBMS copy in each workstation must manage the shared database integrity. In addition, each application program must recognize, for example, locks on data and take care to initiate the proper locks. A lock is necessary to stop users from accessing data that are in the process of being updated. Thus, application programmers must be rather sophisticated to understand the various subtle conditions that can arise in a multiple-user database environment. Programming in such an environment is complex because you have to program each application with the proper concurrency, recovery, and security controls.

Designing Systems for a Client/Server Architecture

An improvement in LAN-based systems is the client/server architecture in which appli- cation processing is divided (not necessarily evenly) between client and server. The client workstation is most often responsible for managing the user interface, includ- ing presenting data, and the database server is responsible for database storage and access, such as query processing. The typical client/server architecture is illustrated in Figure 12-5.

Client/server architecture A LAN-based computing environment in which a central database server or engine performs all database commands sent to it from client workstations, and application programs on each client con- centrate on user interface functions.

FIGURE 12-4 File servers transfer files when data are requested from a clientClient

Server

Entire file sent to client

File Server Architecture

Client request for data

FIGURE 12-5 The required data after a request from a client

Client Server

ONLY result of request

Client/Server Architecture

Client request for data

M12_VALA1629_09_GE_C12.indd 431 15/04/2020 11:51

432 PART IV DESIGN

Advantages of the Client/Server Architecture In the typical client/server archi- tecture, all database recovery, security, and concurrent access management are central- ized at the server; this is the responsibility of each user workstation in a simple LAN. These central DBMS functions are often called a database engine in a client/server environment (Hoffer, Ramesh, & Topi, 2016). Some people refer to the central DBMS functions as the back-end functions and the client-based delivery of applications to users using PCs and workstations as the front-end applications. Further, in the client/server architecture, the server executes all requests for data so that only data that match the requested criteria are passed across the network to client stations. This is a significant advantage of client/server over simple file server designs. Because the server provides all shared database services, this leaves the client software to concentrate on user interface and data manipulation functions. The trade-off is that the server must be more powerful than the server in a file server environment.

An application built using the client/server architecture is also different from a centralized database system on a mainframe. The primary difference is that each client is an intelligent part of the application processing system. In other words, the appli- cation program executed by a user is running on the client, not on the server. The application program handles all interactions with the user and local devices (printer, keyboard, screen, etc.). Thus, there is a division of duties between the server (database engine) and the client. The database engine handles all database access and control functions, and the client handles all user interaction and data manipulation functions. The client PC sends database commands to the database engine for processing. Alter- natively, in a mainframe environment, all parts of the information system are managed and executed by the central computer.

Another advantage of client/server architectures is the ability to decouple the client environment from the server environment. Clients can consist of multiple types (e.g., different computers, operating systems, and application programs), which means that the client can be running any application system that can generate the proper commands (often SQL) to request data from the server. For example, the application program might be written in Visual Basic, a report writer, a sophisticated screen painter, or any fourth-generation language that has an application program interface (API) for the database engine. The database engine might be DB2 on an IBM mainframe or midrange computer or MySQL, Sybase, or Oracle running on a variety of platforms. An API calls library routines that transparently route SQL com- mands from the front-end client application to the database server. An API might work with existing front-end software, such as a third-generation language or custom report generator, and it might include its own facilities for building applications. When APIs exist for several program development tools, then you have considerable indepen- dence to develop client applications in the most convenient front-end programming environment, yet still draw from a common server database. With some APIs, it is pos- sible to access data from both the client and server in one database operation, as if the data were in one location managed by one DBMS (see Hoffer et al., 2016; Kroenke, Auer, Vandenberg, & Yoder, 2017).

In sum, several significant benefits can be realized by adopting a client/server architecture:

1. It allows companies to leverage the benefits of microcomputer technology. Today’s workstations deliver impressive computing power at a fraction of the cost of a mainframe.

2. It allows most processing to be performed close to the source of processed data, thereby improving response times and reducing network traffic.

3. It facilitates the use of graphical user interfaces and visual presentation techniques commonly available for workstations.

4. It allows for and encourages the acceptance of open systems.

Table 12-1 summarizes some of the key differences between file server and client/server architectures. Now that you have an understanding of the general

Database engine The (back-end) portion of the client/ server database system running on the server that provides database process- ing and shared access functions.

Client The (front-end) portion of the client/ server database system that provides the user interface and data manipulation functions.

Application program interface (API) Software building blocks that are used to ensure that common system capabili- ties, such as user interfaces and printing, as well as modules are standardized to facilitate data exchange between clients and servers.

M12_VALA1629_09_GE_C12.indd 432 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 433

differences between file server and client/server architectures, we will briefly examine advanced client/server architectures.

Advanced Forms of Client/Server Architectures Client/server architectures represent the way different application system functions can be distributed between client and server computers. These variations are based on the concept that there are three general components to any information system:

1. Data management. These functions manage all interaction between software and files and databases, including data retrieval/querying, updating, security, concur- rency control, and recovery.

2. Data presentation. These functions manage just the interface between system users and the software, including the display and printing of forms and reports and possibly validating system inputs.

3. Data analysis. These functions transform inputs into outputs, including simple summarization to complex mathematical modeling such as regression analysis.

Different client/server architectures distribute, or partition, each of these func- tions, and others (e.g., load balancing), to one or both of the client or server com- puters, and increasingly, into a third computer, referred to as the application server. In fact, it is becoming commonplace to use three or more distinct computers in many advanced client/server architectures (see Bass, Clements, & Kazman, 2012; Marchioni, 2014). It is also important to note, however, as hardware and software has gotten more powerful and sophisticated, the partitioning of these various functions across separate physical computers has decreased. Increasingly, these different features may reside on virtual machines. A virtual machine is a software emulation of a physical computer system, both hardware and operating system, that allows more efficient sharing of physical hardware resources. Virtualization, a foundation of modern distributed com- puting architectures like cloud computing (see below), refers to the act of creating virtual (rather than physical) versions of a variety of computing capabilities including hardware platforms, operating systems, storage devices, and networks.

This evolution in client/server computing to separate various functions across different physical or virtual machines, has resulted in two important concepts, three- tiered client/server architecture and middleware, to represent this evolution. Three- tiered client/server architectures allow three logical and distinct functions of a computing system—data management, presentation, and analysis—to be developed and maintained as independent modules that often reside on separate physical or virtual machines. Increasingly, an n-tiered architecture is being utilized by many organiza- tions because it enables the development of more flexible and reusable applications. By segregating a system into multiple tiers, developers can modify an existing tier, or add a completely new tier, rather than reworking the entire system when new capabili- ties are needed. These tiers between data management and presentation are referred to as “middleware.” Middleware brings together the distinct hardware, software, and

Application server A computing server where data analysis functions primarily reside.

Virtual machine A software emulation of a physical computer system, both hardware and operating system, that allows more efficient sharing of physical hardware resources.

Virtualization The act of creating virtual (rather than physical) versions of a variety of computing capabilities including hardware platforms, operating systems, storage devices, and networks.

Three-tiered client/server architecture Advanced client/server architectures in which there are three logical and distinct applications—data management, presentation, and analysis—that are combined to create a single information system.

Middleware A combination of hardware, software, and communication technologies that brings data management, presentation, and analysis together into a three-tiered (or n-tiered) client/server environment.

Characteristic File Server Client/Server

Processing Client only Both client and server Concurrent Data Access Low—managed by each

client High—managed by server

Network Usage Large file and data transfers Efficient data transfers Database Security and

Integrity Low—managed by each

client High—managed by server

Software Maintenance Low—software changes just on server

Mixed—some new parts must be delivered to each client

Hardware and System Soft- ware Flexibility

Client and server decoupled and can be mixed

Need for greater coordination between client and server

TABLE 12-1 Several Differences between File Server and Client/Server Architectures

M12_VALA1629_09_GE_C12.indd 433 15/04/2020 11:51

434 PART IV DESIGN

communication technologies in order to create a three-tiered (or n-tiered) client/ server environment (as shown in Figure 12-6).

The easiest way to think of middleware is as plumbing. In your house, you don’t see plumbing, you see water that fills your glass (DiMaggio, 2008). When interacting with an information system, you see applications and data. You are clearly aware of the Web interface that you are using on your PC or smartphone, which is similar to water: You can see it, feel it, and taste it. You are also likely aware of the databases and systems that store and provide information to your devices; this would be analogous to the water purification plant (i.e., we know the water [and data] is coming from somewhere). Further, you are aware of how the water gets from the plant and into your glass; this is the plumbing. Likewise, the way in which the information gets to your client device, whether it be a PC or smartphone, is provided by middleware (i.e., the technological plumbing). Like plumbing components, middleware provides a lot of benefits. First, it remains mostly invisible. It is there, but you don’t usually see it or interact with it too much. Second, it provides a standard way to connect devices to applications and data by using standards, libraries, and APIs. Third, it provides a consistent way to tie together various parts of a complex system; like in your home, where you want water to various locations, you also want data to various applications and devices located throughout an organization or around the world.

In addition to these benefits, there are other good reasons for creating three- tiered (or n-tiered) client/server architectures (Bass et al., 2012). First, applications can be partitioned in a way that best fits organizational computing needs. For exam- ple, in a traditional two-tiered client/server system, the application (data analysis) resides on the client, which would access information such as customer data from a database server. In advanced architectures, data analysis can reside on a powerful application server, resulting in substantially faster response times for users. In addi- tion, a multi-tiered architecture provides greater flexibility by allowing the partitioning of applications in different ways for different users, thus optimizing performance for each type of client.

A second advantage is that because most or all of the data analysis is contained in the application server, making global changes or customizing processes for individual users is relatively easy. This allows developers to easily create custom versions of large- scale systems without creating a completely separate system. Also, because the data analysis is separate from the user interface, it is a lot easier to change one or both with- out having a major maintenance effort. By separating the data analysis from the data presentation (the user interface), either can be changed independently without affect- ing the other, greatly simplifying system maintenance. Lastly, this architecture provides

FIGURE 12-6 Middleware ties together diverse appli- cations and devices

(Source: Andrey Mertsalov/Shutterstock, Mr Aesthetics/Shutterstock, & A-R-T/ Shutterstock)

Server and Applications

Middleware

M12_VALA1629_09_GE_C12.indd 434 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 435

data presentation device independence, allowing for the use of thin clients, like tablet computers and smartphones, to access information from powerful enterprise-wide information systems. Thin clients are most appropriate for doing a minimal amount of client-side processing, essentially displaying information sent to the client from the server (Robbins, 2013). The combinations of these benefits—application partition- ing, easier customization, easier maintenance, and device independence—are driving many organizations to adopt this powerful architecture for developing applications.

CLOUD COMPUTING Managing the information systems infrastructure—the hardware, software, data, facili- ties, human resources, and services used by organizations to support their decision making, business processes, and competitive strategy—can be a challenge for many organizations, due to the evolution of hardware and software, the demand for more storage and networking bandwidth, and the rising costs of energy. Further, organiza- tions need dedicated staff to support their infrastructure, which incurs further costs; often, managing the IS infrastructure is not among the organization’s core competen- cies, so others may be better at managing the infrastructure for them (see Valacich & Schneider, 2018).

In many organizations, the IS infrastructure has grown over the years, leading to a fragmented infrastructure that tends to be difficult to consolidate. However, effi- ciency, effectiveness, and agility are key for successfully competing in the digital world, and organizations require a flexible, scalable infrastructure for their applications and databases. As a result, over the past decades, there has been a shift away from think- ing about developing and maintaining the IS infrastructure toward thinking about what services the infrastructure should deliver. For example, people and organizations want to use e-mail rather than having to think about purchasing an e-mail server and dealing with associated issues such as administration, maintenance, storage, energy consumption, and so on. In addition, organizations increasingly buy or rent, rather than build, applications (except for highly specialized systems that help gain or sus- tain competitive advantage, as is the case with Amazon.com or Dell) to support their business processes; in other words, organizations leave the building and managing of applications to other parties, and assume that these applications will work. Given this trend, a solid infrastructure is important, as the infrastructure determines how quickly new systems can be implemented, and how well they will function; turning over the responsibility for the lower levels of the infrastructure to other organizations allows a business to focus on developing and implementing those applications that help to gain or sustain competitive advantage. This becomes even more important as any lack of robustness or integration of an organization’s infrastructure will be immediately noticed by customers or other stakeholders, potentially leading to loss of business, trust, or goodwill.

What Is Cloud Computing?

Technological advances such as faster processing, increasing Internet bandwidth, improving data management and processing frameworks like Hadoop and Bigtable, as well as improving methods for virtualization, have given rise to cloud computing (the “cloud” is a metaphor for the Internet; see Figure 12-7). As introduced in Chapter 2, cloud computing refers to the provision of applications over the Internet where cus- tomers do not have to invest in the hardware and software resources needed to run and maintain the applications, but are charged on a per-use basis (see Erl, Puttini, & Mahmood, 2013). Cloud computing is a utility computing model (i.e., organizations “renting” resources such as processing, data storage, or networking from an external provider on an as-needed basis, and pay only for what is actually used). Cloud com- puting thus helps to transform IT infrastructure costs from a capital expenditure to

Thin client A client device designed so that most processing and data storage occur on the server.

Information systems infrastructure The hardware, software, data, facilities, human resources, and services used by organizations to support their decision making, business processes, and com- petitive strategy.

Utility computing A form of on-demand computing where resources in terms of processing, data storage, or networking are rented on an as-needed basis. The organization only pays for the services used.

M12_VALA1629_09_GE_C12.indd 435 15/04/2020 11:51

436 PART IV DESIGN

an operational expenditure (Figure 12-8). One prime example of a cloud comput- ing provider is Amazon Web Services (AWS); having built an immense infrastructure (in terms of both information technology and logistics) for supporting its online store, Amazon.com has decided to use these resources to generate additional revenue streams. For example, individuals and organizations can rent storage space on Ama- zon’s Simple Storage Service (S3) or computing time on Amazon’s Elastic Compute Cloud (EC2), all on an as-needed basis. The ability to create an entire infrastruc- ture by combining Amazon’s various services has facilitated many successful startup companies, such as the social scrapbooking site Pinterest or the community travel marketplace Airbnb. As Airbnb grew in popularity with travelers all over the globe, the company found itself being limited by challenges and constraints imposed by their original service provider. Moving to AWS allowed Airbnb to quickly obtain 200

FIGURE 12-7 Processing, storage, and transmission of data taking place in the cloud

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Manag- ing in the digital world (8th ed.) (p. 118). Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Processing Storage

Transmission

FIGURE 12-8 Cloud computing uses a utility com- puting model, allowing companies to pay for computing resources on an as- needed basis.

M12_VALA1629_09_GE_C12.indd 436 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 437

servers without needing to negotiate service contracts or commit to minimum usage. Flexibly scaling the infrastructure would have been close to impossible were Airbnb using its own data center because of both the time and the money needed to acquire this number of servers; and, at the time, who knew whether Airbnb’s business would actually take off? With a traditional in-house infrastructure, Airbnb would have had to add capacity in “chunks,” leading to either having too many unused resources or not being able to satisfy its users’ demand; using a cloud infrastructure, Airbnb can elastically scale the resources to be just above what is needed to keep the users satis- fied (Figure 12-9).

Cloud Characteristics The cloud computing model has several unique and essen- tial characteristics that distinguish cloud computing from an in-house infrastructure and provide various benefits to users (NIST, 2011). These characteristics are discussed next.

On-Demand Self-Service To allow for most flexibility, users can access cloud resources in a buffet-style fashion on an as-needed basis without the need for lengthy negotiations with the service provider; in many cases, resources in the cloud are acces- sible by the customer with no need for human interaction with the provider. In the case of AWS, a customer needs only a credit card (for billing purposes) and can set up server instances or expand storage space via a Web-based control panel. For busi- nesses, whose needs may rapidly change, this allows for unprecedented flexibility, as it greatly facilitates scaling the infrastructure up or down as needed.

Rapid Elasticity Typically, servers and other elements of an IS infrastructure take several weeks to be delivered and days or weeks to be configured (as a company’s IS personnel has to install and configure system software, databases, and application soft- ware, depending on the organization’s needs); in contrast, in a cloud environment, computing resources can be scaled up or down almost instantaneously and often automatically, based on user needs. Hence, there is no need to purchase expensive equipment to prepare for an anticipated surge in demand (which ultimately may not materialize) during the holiday season. If, however, the surge in demand does materialize, businesses can access the required resources instantaneously at almost any quantity.

Broad Network Access As cloud services are accessed via the Internet, they are acces- sible from almost anywhere and from almost any Web-enabled device. For organiza- tions, this enables real-time management of business processes, as applications hosted in the cloud can be accessed whenever needed, from any location, be it from one’s desktop or laptop, or using an iPhone, iPad, or Android smartphone app. Thus, knowledge workers can swiftly respond to anything that may require their immediate attention, without having to be physically in their office.

FIGURE 12-9 It is difficult to match demand using an in-house infrastruc- ture; with a cloud infrastructure, resources can be added incre- mentally, on an as-needed basis.

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Managing in the digital world (8th ed.) (p. 119). Reprinted and elec- tronically reproduced by permis- sion of Pearson Education, Inc., New York, NY.)

Demand

Capacity

In-House Infrastructure Cloud Infrastructure

M12_VALA1629_09_GE_C12.indd 437 15/04/2020 11:51

438 PART IV DESIGN

Resource Pooling Rather than renting out space or time to each customer on one specific, physical machine, cloud providers manage multiple distributed resources that are dynamically assigned to multiple customers based on their needs. Hence, the customer only rents a resource, with no knowledge or control over how it is provided or where it is located. In some cases, however, service providers allow for specifying particular geographic areas of the resources; for example, a California company may want to rent resources located in California (close to its customers) so as to reduce response latency, or a European company may need to rent storage space on servers located in Europe so as to comply with data protection directives.

Measured Service Service is typically provided using a utility computing model, where customers pay only for what they use, and the metering depends on type of resource. For example, customers are charged on an hourly basis for the use of server instances (the price typically depends on the instance’s computing power, memory, and operat- ing system), based on volume of data stored, and/or on data transferred into or out of the cloud. For customers, the fixed costs associated with the IS infrastructure are thus transformed into variable costs, which are very easy to track and monitor.

Service Models As can be seen from the previously mentioned examples, various services are provided in the cloud. Whereas some users require access only to certain software, others want to have more control, being able to run the software of their choice on a server in the cloud (Figure 12-10). Different cloud computing service models (NIST, 2011) are discussed next.

Infrastructure as a Service In the infrastructure as a service (IaaS) model, only the basic capabilities of processing, storage, and networking are provided. Hence, the customer has the most control over the resources. For example, using AWS, custom- ers can choose computing power, memory, operating system, and storage based on individual needs and requirements, thus being able to build (almost) their entire infrastructure in the cloud. Using such infrastructure, Netflix migrated its own IT infrastructure to AWS using EC2 and S3 to transcode movies into various formats, power its customer-focused Website, and host other mission-critical applications. The IaaS model provides the customer with the greatest flexibility; on the other hand, while the infrastructure is provided, managing software licenses is still the responsibil- ity of the customer, and setup costs are relatively high.

Platform as a Service In the platform as a service (PaaS) model, customers can run their own applications, which are typically designed using tools provided by the service provider. In this model, the user has control over the applications but has limited or no control over the underlying infrastructure. One example is Microsoft’s Windows

Infrastructure as a service (IaaS) A cloud computing model in which only the basic capabilities of processing, storage, and networking are provided.

Platform as a service (PaaS) A cloud computing model in which the customer can run his or her own applica- tions that are typically designed using tools provided by the service provider; the customer has limited or no control over the underlying infrastructure.

FIGURE 12-10 Services by SaaS, PaaS, and IaaS providers

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Manag- ing in the digital world (8th ed.) (p. 120). Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

P aaS

IaaS

Operating System Web Server Database Management System Programming Language

S aaS

Application Software Salesforce.com

M12_VALA1629_09_GE_C12.indd 438 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 439

Azure, which acts as a cloud services operating system that customers can use to deploy custom applications. Using this platform, Outback Steakhouse launched a viral mar- keting campaign when it first introduced its Facebook Fan Page. To support the spikes in demand, Outback developed and deployed an e-mail marketing campaign using Windows Azure. As the underlying computing platform is provided, the customer does not have to worry about purchasing software licenses, for example, for the Web serv- ers’ operating systems or for database management systems, and the service provider manages the functioning and updating of the platform provided.

Software as a Service In the software as a service (SaaS) model, the customer uses only applications provided via a cloud infrastructure. Typically, such applications include Web-based e-mail services (e.g., Google’s Gmail) and Web-based productivity suites (such as Zoho or Google Docs), but also advanced applications such as cus- tomer relationship management system, as provided by Salesforce.com. Typically, the customer cares only about the application, with no knowledge or control over the underlying infrastructure, and typically has only limited ability to control or configure application-specific settings. Applications under the SaaS model are typically easiest to deploy, because the customer does not have to worry about maintaining or updating the software, the underlying platform, or the hardware infrastructure.

Types of Clouds Cloud service providers such as Amazon.com offer what is referred to as a public cloud. Services in a public cloud can be used by any interested party on a pay-per-use basis; hence, they are often used for applications that need rapid scalability (i.e., the ability to adapt to increases or decreases in demand for processing or data storage), or in cases where there is insufficient capital or other resources to build or expand an IT infrastructure. In contrast, a private cloud (or internal cloud) is inter- nal to an organization and can help the organization to balance demand and supply of computing resources within the organization; similar to a public cloud, a private cloud provides self-service access to resources, allowing business users to provision resources on-demand using a utility computing model. A private cloud does not free an organization from the issues associated with managing the cloud infrastructure, but it does give the organization a high degree of customizability, flexibility, and control over their data and applications (Figure 12-11).

Managing the Cloud

Because of its various benefits, cloud computing has gained much popularity, espe- cially among executives who try to harness the potential of scalability and increase the business’ agility. However, there are also various issues management should consider

Software as a service (SaaS) A cloud computing model in which a service provider offers applications via a cloud infrastructure.

FIGURE 12-11 Public clouds versus private clouds

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Manag- ing in the digital world (8th ed.) (p. 121). Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Private Cloud

Availability Control

Privacy Security

Increased e�ciency

Capital expenditure

Owned by client

Centralized

Public Cloud

Operational expenditure

Flexible Standardized Fast & easy setup

Owned by service provider

Pay per use Elastic

M12_VALA1629_09_GE_C12.indd 439 15/04/2020 11:51

440 PART IV DESIGN

when moving their infrastructure to the public cloud. The first consideration is which applications, services, or data to move to the cloud. Typically, there is no single cloud computing provider that can meet all needs of most organizations. Rather, organi- zations often have to partner with different service providers, selecting IaaS, PaaS, and SaaS models based on the business’ needs, often combining public and private clouds; as there is not one solution that fits all, organizations have to carefully weigh the benefits and downsides of cloud computing. In addition, organizations must care- fully consider which cloud services provider to choose. Some of the long-term, strate- gic issues that management should consider when evaluating different public cloud service providers include availability, reliability, scalability, viability, security, privacy, compliance, diversity of offerings, openness, and cost (Figure 12-12). These are dis- cussed next (see also Hofmann & Woods, 2010).

Availability/Reliability The availability of the service is a primary concern for most organizations. As shown by examples from Google, Amazon, or Microsoft, not even the largest public cloud computing providers are immune from failures, be it hard- ware failures, programming errors, or some network outage. Organizations thus have to evaluate which applications to move to the cloud, and how to ensure the availabil- ity of cloud-based applications. In addition to examining what the promised uptime of the application/system is, what backups are made to the servers and storage, or whether sufficient bandwidth will be provided to access large amounts of data, organi- zations have to implement their own precautionary measures. As it is often too costly (e.g., in terms of lost business or goodwill) to be affected by negative events, organi- zations should plan ahead and replicate their cloud-based infrastructure in different locations. Related to this, an important criterion to consider is the provider’s support policies. In case something does not work as promised, how will issues be resolved? One of the advantages of cloud computing is self-service, allowing clients to provision resources as needed. At the same time, this can be a potential downside, as there is not always the guarantee of having help available, if needed. Thus, organizations must ensure that acceptable support capabilities and personnel are available, especially for mission-critical applications, to rapidly solve technical issues when they arise.

Scalability One of the biggest promises of cloud computing is scalability, such that organizations can scale up or down their infrastructure as needed. Yet, not every pro- vider will be able to meet every organization’s demands. Thus, organizations have to carefully evaluate to what extent the provider will be able to meet current and future business needs in terms of data storage, transaction volumes, and so on.

Viability Another important issue is associated with the viability and stability of the provider in the long run. As an organization moves to a public cloud infrastructure, it puts much data and processing capabilities into the hands of an outside entity. If this outside entity happens to go out of business, this can have many repercussions for the organization, such as costs and efforts involved in setting up a new infrastructure, migrating applications, or transferring the data from the old provider to the new infrastructure.

FIGURE 12-12 Organizations have to consider various issues when managing their cloud infrastructure.

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Managing in the digital world (8th ed.) (p. 122). Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Viability

Costs Openness

Privacy

Security Availability Reliability

Compliance Diversity of Offerings

Scalability

M12_VALA1629_09_GE_C12.indd 440 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 441

Security, Privacy, and Compliance In addition to concerns related to avail- ability, reliability, scalability, and viability of the vendor, security, privacy, and compli- ance are critical aspects to consider when deciding which data and applications to move to the cloud, and which provider to select. Especially when sensitive data are concerned, organizations have to question how secure the data will be from out- side intruders, how the privacy of customer data will be protected, and whether the data storage complies with regulations such as the Sarbanes–Oxley Act, the Health Insurance Portability and Accountability Act (HIPAA), or standards such as the Pay- ment Card Industry Data Security Standard. In addition, many organizations are faced with responding to data requests as part of civil or criminal litigation. Without proper planning, responding to such data requests can end up costing many times the amount saved by utilizing cloud-based services. By definition, a public cloud infrastructure is shared among different companies, with different applications run- ning on the same hardware; as a result, it is impossible for organizations to know where exactly (physically) the data are located, and thus auditing who has access to the data is extremely difficult, if not impossible. Whereas in an in-house infrastruc- ture, a company has complete control over its own data, this control is lost in a cloud infrastructure, and organizations have less legal rights if their data are stored in the cloud. Similarly, cloud computing providers may be asked to hand over sensitive data stored on their servers to law enforcement, leaving the organization with little control. Especially for industries heavily concerned with privacy and data protection, such as firms in the medical or legal fields, these issues are of critical importance. On the other hand, public cloud computing providers are certainly aware of these issues, and organizations have to weigh which applications or data to move to the cloud, and which to keep in-house.

Issues such as availability, reliability, and security are normally covered in service- level agreements, which are contracts specifying the level of service provided in terms of performance (e.g., as measured by uptime), warranties, disaster recovery, and so on. A big caveat is that such service-level agreements do not guarantee the availability of resources; rather, they only promise certain service levels and provide for refunds or discounts if these promises are not met, and can thus be regarded mostly as a vehicle for resolving conflicts in case of problems.

For businesses, this poses a serious dilemma, as such refunds and discounts only cover the costs paid for the service, but can never offset the opportunity costs arising from lost business. On the other hand, when evaluating the benefits and drawbacks of moving the infrastructure to the public cloud, organizations also have to critically evaluate how they would be able to maintain certain uptime using an in-house infra- structure, and at what costs; often, organizations realize that even though certain SLAs may not be met by the provider, the provider can still offer better uptime than a poorly managed in-house infrastructure. In evaluating their options, organizations often choose a hybrid approach, having certain mission-critical applications in-house, while moving other, less demanding applications (in terms of uptime, etc.) to the public cloud.

Diversity of Offerings As discussed earlier, there are various providers of cloud computing services, ranging from IaaS to SaaS. As a larger number and diversity of providers is more difficult to manage, many organizations prefer to deal with fewer providers that can meet all needs. Thus, an important question to ask is which pro- vider can offer the services needed both currently and in the future.

Openness A related question organizations face is the issue of interoperability. Most cloud providers use different infrastructures, different ways to store data, and so on. This, however, makes migrating data between providers extremely difficult, and can lead a company to be locked in by a certain provider. In addition to dif- ferent infrastructures and storage models, existing network bandwidth (and data

M12_VALA1629_09_GE_C12.indd 441 15/04/2020 11:51

442 PART IV DESIGN

transmission costs) poses an additional limitation to interoperability, as moving tera- bytes of data from one provider to another, even using very high-speed networks, can prove extremely time consuming and expensive (as cloud computing providers often charge for transferring data into or out of their infrastructure).

Costs A final issue to consider when moving to a public cloud infrastructure is costs. The utility computing model used by cloud computing providers gives organizations control over the resources used and paid for—the organization only pays for the resources used, and can scale the resources up or down when needed. Thus, this provides the organization with much transparency over the cost of the resources. Yet, there is considerable disagreement over whether moving to the public cloud is cheaper than maintaining an in-house infrastructure. For example, the online game developer Zynga recently moved from a public cloud infrastructure to an in-house private cloud, and decided to own, rather than rent, its infrastructure. Comparing the costs of owning versus renting is not an easy feat. Whereas it is easy to calculate the costs per month of a server in Amazon’s EC2 cloud, many organizations do not know exactly how much it costs to run a comparable server in an in-house infrastructure, includ- ing the costs of the server itself, the fees for software licenses, the electricity, the data center, the staff, and so on. Thus, organizations have to carefully balance the benefits and costs of the flexibility and scalability the cloud offers, such as by using a cloud infrastructure only for periods of peak demand; needless to say, this adds another layer of complexity to the IT operations.

In sum, there are various issues to consider when moving to a cloud infrastruc- ture, and each organization has to make various informed choices about how to har- ness the opportunities the cloud offers while minimizing potential drawbacks. In the next section, we will provide a brief discussion of various other applications enabled by the cloud.

Service-Oriented Architecture

In order to achieve greater flexibility and agility, organizations have tried to move away from deploying large, monolithic applications in favor of a service-oriented architecture (SOA). Using SOA, business processes are broken down into individual components (or services) that are designed to achieve the desired results for the service consumer (which can either be an application, another service, or a person). To illustrate this concept, think about the next oil change for your car. As you can’t be an expert in everything, it is probably more effective to have someone change the oil for you. You may take your car to the dealership, you may go to an independent garage or oil change service, or you may ask your friend to do it for you. For you, all that matters is that the service will be provided at the expected level of quality and cost, but you typically do not care if different service providers do things differently or use different tools.

By breaking down business processes into individual services, organizations can more swiftly react to changing business needs. For example, using an SOA approach, multiple services (such as “check inventory” or “order supplies”) would be orches- trated to handle the individual tasks associated with processing customer orders and could be changed relatively easily if the business process changes.

To facilitate online collaboration with suppliers, business partners, and custom- ers, SOA uses and reuses individual services as “building blocks,” so that systems can be easily built and reconfigured as requirements change. To achieve these benefits, services have to follow three main principles:

1. Reusability. A service should be usable in many different applications. 2. Interoperability. A service should work with any other service. 3. Componentization. A service should be simple and modular.

Service-oriented architecture (SOA) A software architecture in which busi- ness processes are broken down into individual components (or services) that are designed to achieve the desired results for the service consumer (which can be either an application, another service, or a person).

M12_VALA1629_09_GE_C12.indd 442 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 443

Following these principles, multiple applications can invoke the same ser- vices. For example, both an organization’s point-of-sale system and e-commerce Website could invoke the service “process credit card,” and the executive dashboard could invoke the services “display products,” “display inventory,” and “display sales” ( Figure 12-13). Hosting and deploying such services in the cloud can help in build- ing applications using SOA. In addition, various services an organization may need are available in the cloud, eliminating the need to “reinvent the wheel.” However, whereas an SOA approach appears to be appealing for many companies, it requires tremendous effort and expertise to plan the architecture, select the right services from hundreds or thousands of available services, and orchestrate and deploy the services. Hence, while an SOA approach helps to increase flexibility, the integration of various services can be extremely complex and can be well beyond the means of small enterprises.

Web Services

The most common approach for deploying a SOA is through the use of Web services. A Web service is a method of communication between two electronic devices over a network (Web service, 2018). Most organizations today have a complex array of technologies that need to interact with many different types of systems and devices. Many of these systems need to exchange data, business logic, or processes with each other. A Web service is a method of communication that allows two software systems, which may have been written in different languages, to exchange this data over the Internet. The software system that makes a request is called a service requester, whereas the software system that would process the request and provide the response is called a service provider. Web services have specific rules governing the communication between systems, and utilize XML and JSON files for data exchange (both XML and JSON are described next). Likewise, Web services are not tied to any operating system or programming language to work together; no custom coding is needed. Because of this, Web services have become a common way to integrate Web-based applica- tions over the Internet. For instance, Web services allow separate organizations to communicate data without intimate knowledge of each other’s systems behind their respective firewalls.

eXtensible Markup Language, or XML, is a language that defines a set of rules for encoding documents in a format which is both human- and machine-readable

Web service A method of communication between two electronic devices over a network.

eXtensible Markup Language (XML) An Internet authoring language that allows designers to create customized tags, enabling the definition, transmis- sion, validation, and interpretation of data between applications.

FIGURE 12-13 Using SOA, multiple applications can invoke multiple services.

(Source: Valacich, J. & Schneider, C. (2018). Information systems today: Manag- ing in the digital world (8th ed.) (p. 124). Reprinted and electronically reproduced by permission of Pearson Education, Inc., New York, NY.)

Services Applications

Process Credit Card

Ship Product

Display Sales

Display Inventory

Display Product

E-commerce Website

Point-of-Sale System

Executive Dashboard

M12_VALA1629_09_GE_C12.indd 443 15/04/2020 11:51

444 PART IV DESIGN

and is used extensively for interchanging data over the Internet (see Fawcett, Ayers, & Quin, 2012; http://www.w3.org/XML/). XML is a lot like HTML, with tags, attri- butes, and values, but it also allows designers to create customized tags, enabling the definition, transmission, validation, and interpretation of data between appli- cations. Whereas HTML has a fixed set of tags, designers can create custom lan- guages—called vocabularies—for any type of application in XML. This ability to create customized languages is at the root of the power of XML; however, this power comes at a price. Whereas HTML is very forgiving on the formatting of tags, XML is very strict. Additionally, as mentioned earlier, XML documents do not contain any formatting information. XML tags simply define what the data mean. For this reason, many believe that HTML will remain a popular tool for develop- ing personal Web pages; XML has become the tool of choice for many commercial Internet applications.

A second, and an increasingly popular approach for formatting data within a Web service environment is JavaScript Object Notation, or JSON (pronounced J-SON). JSON is a lightweight data interchange approach that is relatively easy for humans to understand and for computers to generate or interpret. JSON is an alternative to XML and is considered much more efficient to transfer and process, and much easier for humans to understand. Because of these advantages, the use of JSON has dramatically increased.

There are two key technologies, SOAP and REST, which are used to assist in the communication within a Web services environment. The first, Simple Object Access Protocol (SOAP), facilitates the communication of XML between applications and the operating system. SOAP builds on existing standards to provide powerful com- munication capabilities, most notably, XML for formatting messages and Hypertext Transfer Protocol (HTTP) (see below for more information on HTTP) and Simple Mail Transfer Protocol (SMTP) for transmitting messages. In addition to leveraging Internet standard communication protocols like HTTP and SMTP, SOAP also pro- vides language and platform independence as well as the ability to navigate through proxies and firewalls. A drawback to SOAP, however, is that it is relatively verbose to compose and slower than alternative approaches to transmit and process. The second approach for facilitating the communication within Web services is called REST, or Representational State Transfer. REST is a simpler and faster alternative to SOAP, typically communicating over HTTP utilizing JSON for formatting information. Rela- tive to SOAP and XML, REST and JSON are much simpler to understand, easier for machines to process and generate, and easier for humans to design and implement. As such, REST and JSON are rapidly becoming a dominant standard within the development of Web services.

DESIGNING INTERNET SYSTEMS The vast majority of new systems development in organizations focuses on Internet- based applications. The Internet can be used for delivering internal organizational systems, business-to-business systems, or business-to-consumer systems. The rapid migration to Internet-based systems should not be a surprise; it is motivated by the desire to take advantage of the global computing infrastructure of the Internet and the comprehensive set of tools and standards that has been developed. However, as with any other type of system, there are numerous choices that have to be made when designing an Internet application. The design choices you make can greatly influence the ease of development and the future maintainability of any system. In this sec- tion, we focus on several fundamental issues that must be considered when designing Internet-based systems.

JavaScript Object Notation (JSON) A lightweight data interchange approach that is relatively easy for humans to understand and for comput- ers to generate or interpret.

Simple Object Access Protocol (SOAP) A protocol for communicating XML data between Web service applications and the operating system.

Representational State Transfer (REST) A relatively simple and fast protocol for communicating JSON data between Web service applications and the operating system.

M12_VALA1629_09_GE_C12.indd 444 15/04/2020 11:51

http://www.w3.org/XML/

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 445

Internet Design Fundamentals

Standards play a major role when designing Internet-based systems (Zeldman, 2009). In this section, we examine many fundamental and emerging building blocks of the Internet and how each of these pieces influences system design.

Standards Drive the Internet Designing Internet-based systems is much simpler than designing traditional client/server systems because of the use of standards. For example, information is located throughout the Internet via the use of the standard domain naming system (BIND) (the “B” in BIND refers to Berkeley, California, where the standard was first developed at the University of California [BIND stands for Berke- ley Internet Name Domain]; for more information see http://www.isc.org/prod- ucts/BIND/bind-history.html). BIND provides the ability to locate information using common domain names that are translated into corresponding Internet Protocol (IP) addresses. For example, the domain name http://www.arizona.edu translates to 128.196.133.50.

Universal user access on a broad variety of clients is achieved through a stan- dardized communication protocol: the Hypertext Transfer Protocol (HTTP). HTTP is the agreed-upon format for exchanging information on the World Wide Web (see http://www.w3.org/Protocols/ for more information). The HTTP protocol defines how messages are formatted and transmitted as well as how Web servers and brows- ers respond to commands. For example, when you enter a URL into your browser, an HTTP command is sent to the appropriate Web server requesting the desired Web page.

Beyond the naming standards of BIND and the transfer mechanism of HTTP, an Internet-based system has another advantage over other types of systems: the Hyper- text Markup Language (HTML). HTML is the standard language for representing content on the Web through the use of hundreds of command tags. Examples of command tags include those to bold text (…), to create tables (…), or to insert links onto a Web page (University of Arizona).

Having standardized naming (BIND), translating (HTTP), and formatting (HTML) enables designers to quickly craft systems because much of the complexity of the design and implementation is removed. These standards also free the designer from much of the worry of delivering applications over a broad range of computing devices and platforms. Together BIND, HTTP, and HTML provide a standard for designers when developing Internet-based applications. In fact, without these stan- dards, the Internet as we know it would not be possible.

Ongoing Evolution The infrastructure currently supporting HTML-based data exchange is the same infrastructure that will support the widespread use of XML, JSON, and other emerging standards. As we move beyond desktop computers and standard Web browsers, the greatest driver of change and evolution of Internet stan- dards will be the need to support wireless mobile computing devices. As discussed previously, wireless mobile computing devices are often referred to as thin-client technol- ogies. Thin clients such as network PCs, tablets, and smartphones are being designed to operate as clients in Internet-based environments (see Figure 12-14). Alternatively, a workstation that can provide significant amounts of client-side storage and processing is referred to as a fat client. Current PC workstations connected to the Internet can be thought of as fat clients. For desktop PC workstations, Internet browsers render content marked up in HTML documents. However, as thin clients gain in popularity, designing applications to receive, send, and process XML or JSON will enable content to be displayed more effectively on any client device, regardless of the screen size or resolution.

Domain naming system (BIND) A method for translating Internet domain names into Internet Protocol (IP) addresses. BIND stands for Berkeley Internet Name Domain.

Hypertext Transfer Protocol (HTTP) A communication protocol for exchang- ing information on the Internet.

Hypertext Markup Language (HTML) The standard language for representing content on the Web through the use of hundreds of command tags.

M12_VALA1629_09_GE_C12.indd 445 15/04/2020 11:51

http://www.isc.org/products/BIND/bind-history.html

http://www.arizona.edu

http://www.w3.org/Protocols/

446 PART IV DESIGN

Regardless of whether the device is a smartphone, tablet, or a desktop PC, the use of standards will drive Internet-based system design. A well-designed system will isolate the content presentation from the business logic and data, allowing any Inter- net-capable device to become part of the overall distributed system. Techniques to ensure the consistency of the site’s appearance for any type of device are discussed next.

Site Consistency

A consistent “look and feel” is fundamental to conveying the image that a site is profes- sionally designed. A site with high consistency is also much easier for users to navigate, and it is much easier for users to anticipate the meaning of links. From a practical standpoint, it is a poor design decision to not enforce a standard look and feel to an entire site. Development and maintenance can become a nightmare when implement- ing changes to colors, fonts, or other elements across thousands of Web pages within a site. In this section, we discuss ways to help you enforce design consistency across an entire site and to simplify page maintenance.

Cascading Style Sheets One of the biggest difficulties in developing a large-scale Website is maintaining consistency throughout the site with regard to color, back- ground, fonts, and other page elements. Experienced Website designers have found that the use of Cascading Style Sheets (CSSs) can greatly simplify site maintenance and also ensure that pages are consistent (see http://www.w3.org/Style/CSS/). CSSs are simply a set of style rules that tell a Web browser how to present a document. The best way to implement CSSs is through the use of linked style sheets. Using this method, through HTML’s LINK element, only a single file needs to be updated when changing style elements across an entire site. The LINK element indicates some sort of a relationship between an HTML document and some other object or file (see Figure 12-15). CSSs are the most basic way to implement a standard style design within a Website.

eXtensible Stylesheet Language A second and more sophisticated method for implementing standard page styles throughout a site is via the eXtensible Stylesheet Language (XSL). XSL is a specification for separating style from content when generating XML pages (see http://www.w3.org/TR/xsl/ for more information). XSL allows designers to apply single style templates to multiple pages in a manner similar to that of Cascading Style Sheets. XSL allows designers to dictate how XML should be displayed whether the client device is a Web browser, handheld device,

Cascading Style Sheets (CSSs) A set of style rules that tells a Web browser how to present a document.

eXtensible Stylesheet Language (XSL) A specification for separating style from content when generating XML pages.

FIGURE 12-14 Thin clients used to access the Internet

(Source: Sergey Peterman/Shutterstock, Africa Studio/Shutterstock, Andrey Mert- salov/Shutterstock, & Mr Aesthetics/ Shutterstock)

Wireless Internet

M12_VALA1629_09_GE_C12.indd 446 15/04/2020 11:51

http://www.w3.org/Style/CSS/

http://www.w3.org/TR/xsl/

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 447

speech output, or some other media. In other words, XSL provides designers with specifications that allow XML content to be seamlessly displayed on various client devices.

In practical terms, XSL allows designers to separate presentation logic from site content. This separation standardizes a site’s “look and feel” without having to custom- ize to the capabilities of individual devices. Given the rapid evolution of devices (e.g., desktop computers, mobile computing devices, and televisions), XSL is a powerful method to ensure that information is displayed in a consistent manner and uses the capabilities of the client device. XSL-based formatting consists of two parts:

1. Methods for transforming XML documents into a generic comprehensive form 2. Methods for formatting the generic comprehensive form into a device-specific

form

In other words, XML content, queried from a remote data source, is format- ted based on rules within an associated XSL style sheet (see Figure 12-16). This content is then translated to a device-specific format and displayed to the user. For example, if the user has made the request from a Web browser, the presentation

FIGURE 12-15 Using HTML’s link command for Cascad- ing Style Sheets

Sample Command :

LINK HREF=“style5.css” REL=StyleSheet TYPE=“text/css” TITLE=“Common Back- ground Style” MEDIA=“screen, print”>

Command Parameters:

HREF=“filename or URL” Indicate the location of the linked object or document.

REL=“relationship” Specify the type of relationship between the document and linked object or document.

TITLE=“object or document title” Declare the title of the linked object or document.

TYPE=“object to document type” Declare the type of linked object or document.

MEDIA=“type of media” Declare the type of medium or media to which the style sheet will be applied (e.g., screen, print, projection, aural, braille, tty, tv, all).

FIGURE 12-16 Combining XML data with XSL style sheet to format content

(Source: A-R-T/Shutterstock, Vectors Bang/Shutterstock, & Andrey Mertsalov/ Shutterstock)

XML Content Device-Specific Format

XSL Style Sheet

Generic “Comprehensive” Content Format XSL

Transformer XSL

Transformer

M12_VALA1629_09_GE_C12.indd 447 15/04/2020 11:51

448 PART IV DESIGN

layer will produce an HTML document. If the request has been made from a wireless mobile phone, the content will be delivered as a Wireless Markup Language (WML) document.

Design Issues Related to Site Management

Maintenance is part of the ongoing management of a system. Many design issues will significantly influence the long-term successful operation of a system. Therefore, in this section we will discuss those issues that are particularly important when designing an Internet-based system.

Customer Loyalty and Trustworthiness In order for your Website to become the preferred method for your customers to interact with you, they must feel that the site—and their data—are secure. There are many ways that the design of the site can convey trustworthiness to your users. Customers build trust from positive experi- ences gained while interacting with a site (McKnight, Choudhury, & Kacmar, 2002). According to Web design guru Jakob Nielsen (Nielsen, 1999), designers can convey trustworthiness in a Website in the following ways:

1. Design quality. A professional appearance and clear navigation convey respect for customers and an implied promise of good service.

2. Up-front disclosure. Immediately inform users of all aspects of the customer relation- ship (e.g., shipping charges, data privacy policy); this conveys an open and honest relationship.

3. Comprehensive, correct, and current content. Up-to-date content conveys a commit- ment to provide users with the most up-to-date information.

4. Connected to the rest of the Web. Linking to outside sites is a sign of confidence and lends credibility; an isolated site feels like it may have something to hide.

In addition to these methods, protecting your customers’ data will also be a significant factor for conveying trustworthiness. For example, many users are reluctant to disclose their e-mail address for fear of getting frequent unsolicited messages (spam). As a result, many users have learned to provide a secondary e-mail address—using services such as Gmail or Yahoo! mail—when trust has not yet been established. Consequently, if you need to gather a customer’s e-mail address or other information, you should disclose why this is being done and how this information will be used in the future (e.g., information will be used only for order confirmation). Failure to consider how you convey trust to your customers may result in a system design that is not a success.

Another way to increase loyalty and to convey trustworthiness to customers is to provide useful, personalized content (see Nielsen, 1998a; Nielsen and Loranger, 2006). Personalization refers to providing content to a user based upon knowledge of that customer. For example, once you register and place orders on Amazon.com, each time you visit you are presented with a customized page that is based upon your prior purchase behavior.

Personalization should not be confused with customization. Customization refers to sites that allow a user to customize the content and look of a site based on his or her personal preferences. For example, the popular Internet portals—Websites that offer a broad array of resources and services, such as Yahoo!, MSN, and many of the popular search engines—allow users to customize the site based on their preferences and interests. Many organizations, including universities, are also using the portal concept for delivering organization-specific information and applications (Nielsen, 2003; Nielsen & Loranger, 2006).

Because a personalized site knows you, each time you visit you are presented with new personalized content without having to enter any additional information.

Personalization Providing Internet content to a user based upon knowledge of that customer.

Customization Internet sites that allow users to cus- tomize the content and look of the site based on their personal preferences.

M12_VALA1629_09_GE_C12.indd 448 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 449

The site is able to personalize content because the system learns each customer’s preferences and builds a profile based upon this history. This method for personal- izing site content is a success because users do not have to do anything to set it up. For example, users typically view the personalized data from Amazon.com favorably. To personalize each customer’s content, Amazon compares a user’s prior purchases with the purchasing behavior of millions of other customers to reliably make pur- chase recommendations that may never have occurred to a customer. Amazon does a nice job of not making personalization recommendations too obtrusive so that if the system makes a bad guess at what the user might be interested in, the user isn’t annoyed by having the site trying to be smarter than it actually is. For example, many users visit Amazon.com to purchase books as gifts for friends; using these data to personalize the site may impede the user’s experience when shopping for personal items.

Links Must Live Forever For commercial Internet sites, your links must live for- ever. There are four primary reasons why professional developers have come to this conclusion (Nielsen, 1998b):

1. Customer bookmarks. Because customers may bookmark any page on your site, you cannot ever remove a page without running the risk of losing customers who would not find a working link if they encountered a dead link.

2. Links from other sites. Like your customers who bookmark pages, other sites may link directly to pages within your site; removing a page may result in losing customer referrals.

3. Search engine referrals. Because search engines are often slow to update their data- bases, this is another source for old and dead pages.

4. Old content adds value. In addition to these practical issues, many users may actually find value from old content. Old content can remain useful to users because of historic interest, old product support, or background information for recent events. Additionally, the cost of keeping old content is relatively small. However, it is important to maintain old content so that links do not die, and to correct or remove obsolete or misleading information. Finally, make sure that you explicitly date old content, provide disclaimers that point out what no longer applies or is accurate, and provide forward-pointing links to current pages.

You should not conclude from this discussion that Web content cannot change and evolve. However, you should now understand that the links them- selves cannot die. In other words, when users bookmark a page and return to your site, this link should return something useful to the user; otherwise, you run the risk of losing the customer. With a small amount of maintenance on your site’s old content, you will provide a valuable resource to your customers. It should be obvious that customers who visit your site infrequently should easily be able to find what they are looking for; otherwise, they will become frustrated, leave, and not come back.

System Security A paradox lies in the fact that, within a distributed system, secu- rity and ease of use are often in conflict with each other. A secure system is often much less “user-friendly,” whereas an easy-to-use system is often less secure. When designing an Internet-based system, successful sites strike an appropriate balance between security and ease of use. For example, many sites that require a password for site entry provide the functionality of “remember my password.” This feature will make a user’s experience at a site much more convenient and smooth, but it also results in a less secure environment. By remembering the password, anyone utilizing

M12_VALA1629_09_GE_C12.indd 449 15/04/2020 11:51

450 PART IV DESIGN

the user’s computer potentially has access to the initial user’s account and personal information.

In addition, if you must require customers to register to use your site and gain access via passwords, experienced designers have learned that it is best to delay cus- tomer registration and not to require registration to gain access to the top levels of the site. If you ask for registration too early, before you have demonstrated value to a new customer, you run the risk of turning away the customer (Nielsen, 1997; Nielsen & Loranger, 2006). Once a customer chooses to register on your site, make sure that the process is as simple as possible. Also, if possible, store user information in client- or server-side cookies rather than requiring users to re-enter information each time they visit your site. Of course, if your site requires high security (e.g., a stock trading site), you may want to require users to enter an explicit password at each visit. Security is clearly a double-edged sword. Too much and you might turn customers away; too little and you run the risk of losing customers because they do not trust the security of the site. Careful system design is needed to achieve the right balance between security and ease of use.

Website Content Management In the early days of the Internet, Websites were often maintained by a small group of overworked developers; sites were often filled with outdated information and inconsistent layouts. To gain consistency in Web- site appearance, organizations have utilized templates and stylesheets as described previously. To make sure Websites contain the most accurate and up-to-date infor- mation, often from multiple sources, many organizations have turned to using a content management system (CMS). A CMS is a special type of software application for collecting, organizing, and publishing Website content from multiple organi- zational data sources, such as data warehouses, personnel databases, inventories, and so on. This content is stored in a single repository along with templates for formatting any type of Web page within the organization’s Website. Because content and formatting is separated by the CMS, the same underlying content can be pre- sented differently to different audiences—customers, employees, or suppliers—as well as for different devices (see Figure 12-17). Popular CMSs include WordPress, Joomla, and Drupal.

Content management system (CMS) A special type of software application for collecting, organizing, and publish- ing Website content.

FIGURE 12-17 A content management system allows content from multiple sources to be stored separately from its formatting to ease Website management.

Source: M-O Vector/Shutterstock, Andrey Mertsalov/Shutterstock & A-R-T/ Shutterstock Content Sources

Templates Data

Internet

Content Management System

Organizational Web Server

M12_VALA1629_09_GE_C12.indd 450 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 451

PINE VALLEY FURNITURE

Additionally, a CMS allows numerous content developers and sources to provide updated information for a Website, without having to know anything about HTML. For example, a personnel manager could author a new job description and post it at the CMS server using a standard word-processing program like Microsoft Word. Once stored at the CMS server, the job posting text can be merged with a standard template that automatically formats it into a standard Web page. Once formatted, the Webmaster can review and approve the job posting before it is published onto the publicly (intranet, Internet, or extranet) viewed Website. In this way, organizations can facilitate timely updates to their Websites from throughout the organization, without having to wait for Web developers to author pages. This separation of content, appearance, and publish- ing greatly improves organizational workflow and site management. It is only through a CMS that organizations can deploy sophisticated Websites, containing thousands of pages with rapidly changing content (e.g., visit a popular Website with constantly chang- ing content like cnn.com and imagine how to keep this site up to date without a CMS).

ELECTRONIC COMMERCE APPLICATION: DESIGNING A DISTRIBUTED ADVERTISEMENT SERVER FOR PINE VALLEY FURNITURE’S WEBSTORE In this chapter, we have examined numerous issues to consider when designing Inter- net-based systems. As we saw in the prior two chapters, prototyping can be useful in conceptualizing the look and feel of a Website. The look and feel of a site is a function of the data presentation layer within an Internet-based application. Prototyping also provides a view of the transactions and processes within the system. Transactions and processes are managed by the middle layer, data analysis, of a three-tiered architec- ture. In this section, we will see how a distributed system, the advertisement rotation system, is integrated into PVF’s WebStore.

In the prior two chapters, you read how Jim Woo defined specifications for the forms and reports as well as the interface and dialogues for PVF’s WebStore. In this design work, he and his development team concluded that they wanted the human–computer interface of their site to have four key features:

1. Menu-driven navigation with cookie crumbs 2. Lightweight graphics 3. Form and data integrity rules 4. Stylesheet-based HTML

To demonstrate these features to the team, Jim built a prototype (see Figure 12-18).

Advertising on Pine Valley Furniture’s WebStore

Having reviewed Jim Woo’s throwaway prototype of the WebStore, Jackie Judson wanted to assess the feasibility of adding advertisements to the site. She came up with the following list of potential benefits for including advertising:

• Potential to increase revenue generated from the WebStore • Potential to create cross-promotions and alliances with other online commerce

systems • Potential to provide customers with improved service when looking for addi-

tional products that accessorize PVF’s product line

Jim agreed with the principles of advertising on the site and researched advertis- ing examples on an array of different Internet sites. He compiled the following list of

M12_VALA1629_09_GE_C12.indd 451 15/04/2020 11:51

452 PART IV DESIGN

potential concerns that need to be addressed in the system design in order to imple- ment a successful advertisement rotation system within the WebStore:

• Advertisements must be served quickly so that site performance is not affected. • Advertisements must be uniform in size and resolution, so they do not disrupt

the site layout. • Advertisement links must not redirect the user’s browser away from the

WebStore.

Designing the Advertising Component

To begin the process, Jim modified the style sheets of the initial prototype to include a space where the advertisement would appear. Because all advertisements would be approved by the marketing department before being included in the rotation, Jim could rely on the fact that they would be uniform in size and resolution. If an adver- tisement is clicked, a new, smaller window is opened and directed to the advertiser’s site. The link is not direct, though. It is first directed to the advertising server within the WebStore system, the same server the advertisement came from. This “click-thru” transaction is logged, and the user is sent to the appropriate destination.

Jim identified two distinct sets of data that would be generated by the advertisement rotation system: the number of advertisements served and the number of “ click-thrus.” The data being generated must be stored quickly and function transparently within the overall operation of the system. The transactional requirements of the advertisement system are the following:

1. Determine which advertisements apply, based on where the user is in the WebStore. 2. Personalize the advertisement if the identity of the user has been established and

his or her preferences are known. 3. Check for any seasonal or promotional advertisements. 4. Log the transaction.

These requirements are part of the business rules that govern the rotation sys- tem. Jim and Jackie want these parameters to be flexible and scalable so that future systems can incorporate these rules. To demonstrate how an advertisement might be

FIGURE 12-18 Initial prototype of the WebStore

M12_VALA1629_09_GE_C12.indd 452 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 453

placed on the WebStore, Jim modified the prototype to include a vertical banner ad along the right edge (see Figure 12-19).

Designing the Management Reporting Component

Once the transactional requirements of the system were established, Jackie turned her attention to what reports she and other upper-level managers would like to see gener- ated. Jim immediately began to write down all of the demographic information stored in the customer-tracking system and cross-referenced it to the information stored when an advertisement was clicked. This led Jim and Jackie to identify numerous potential analytical queries that tied information from the customer-tracking system with the transactional data in the advertisement rotation system. A few of the queries they came up with included the following:

• “How many women, when shopping for desks, clicked on an advertisement for lamps?”

• “How many advertisements were served to shoppers looking at filing cabinets?” • “How many people clicked on the first advertisement they saw?” • “How many people clicked on an advertisement and then purchased something

from the WebStore?”

Being able to analyze these and other results will provide critical feedback from targeted marketing campaigns, seasonal promotions, and product tie-ins. Using a distributed, transaction-based advertisement system in the WebStore will keep mainte- nance costs low and should increase the revenue generated from the site. Information derived from the analytical queries of advertisement transaction data increases the site’s value even further.

Jackie and Jim reviewed the advertising model with the entire marketing staff. Many of the client account reps expressed interest in seeking a partnership with fre- quent customers to do advertising on the site. Junior sales staff members were eager to sell advertising space with the knowledge that they could provide purchasers with feed- back on “click-thru” rates and overall advertisement views. One of the graphic design- ers even produced an advertisement on the spot for an upcoming product release. Everyone seemed to agree that the advertisement rotation system would increase the value of the WebStore to PVF.

FIGURE 12-19 Adding advertising to the WebStore prototype

M12_VALA1629_09_GE_C12.indd 453 15/04/2020 11:51

454 PART IV DESIGN

SUMMARY This chapter covered various issues and technologies involved in the sharing of systems and data by multiple people across space and time in distributed and Internet systems. You learned about the client/server architec- ture, which is being used to network personal computers and workstations and to replace older mainframe appli- cations. Components of the client/server architecture, including LANs, database servers, application program- ming interfaces, and application development tools, were described.

Two common types of LAN-based architectures—file server and client/server—were compared. It was shown that the newer client/server technologies have significant advantages over the older file servers. We also outlined the evolution of distributed systems and three-tiered client/ server technologies that are giving analysts more options for distributed system design.

Cloud computing uses a utility computing busi- ness model, where customers can draw on a variety of computing resources that can be accessed on demand, with minimal human interaction. Characteristics of cloud computing include on-demand self-service, rapid elasticity, broad network access, resource pooling, and measured service. Typical cloud computing service mod- els are infrastructure as a service, platform as a service, and software as a service. When considering the move to a public cloud-based infrastructure, organizations have to weigh issues such as availability, reliability, scalability, viability, security, privacy, compliance, openness, diversity of offerings, and, not least, cost. Cloud computing sup- ports service-oriented architectures and the use of Web services to more easily integrate systems and deploy them on a variety of devices.

When designing Internet-based systems, standardized location naming, content translating, and document for- matting enable designers to quickly craft systems because much of the complexity of the design and implementation is removed. These standards also free the designer from much of the worry of delivering applications over a broad range of computing devices and platforms. Many commercial Inter- net applications are vast and can contain thousands of dis- tinct pages. A consistent “look and feel” is fundamental to conveying the image that the site is professionally designed. A site with high consistency is also much easier for users to navigate and is much more intuitive so users can anticipate the meaning of links. Two techniques for enforcing consis- tency when designing large-scale Web applications are the use of CSSs and the XSL. Given the desire to deliver the Internet to a broader array of client devices, there is a trend to separate Web content from its delivery. Electronic com- merce applications are particularly embracing this trend and are adopting standards such as XML and JSON to author Web data and XSL to manage content formatting in addition to using style sheets to enforce consistency in the design of a Website across client devices. Finally, a successful design will make users feel that the site—and their data—are secure. Customers build trust from positive experiences interacting with a site. Taking steps to convey trustworthiness will help to attract and retain customers.

We did not have the space in this chapter to address several additional issues concerning distributed and Inter- net systems. Many of these issues are handled by other systems professionals, such as database administrators, tele- communications experts, and computer security specialists. Systems analysts must work closely with other professionals to build sound distributed systems.

KEY TERMS

12.1 Application program interface (API)

12.2 Application server 12.3 Cascading Style Sheets (CSSs) 12.4 Client 12.5 Client/server architecture 12.6 Content management system

(CMS) 12.7 Customization 12.8 Database engine 12.9 Domain naming system (BIND) 12.10 File server 12.11 Hypertext Markup Language

(HTML) 12.12 Hypertext Transfer Protocol

(HTTP)

12.13 Information systems infrastructure

12.14 Infrastructure as a service (IaaS) 12.15 JavaScript Object Notation

( JSON) 12.16 Local area network (LAN) 12.17 Middleware 12.18 Personalization 12.19 Platform as a service (PaaS) 12.20 Representational State Transfer

(REST) 12.21 Service-oriented architecture

(SOA) 12.22 Simple Object Access Protocol

(SOAP) 12.23 Software as a service (SaaS)

12.24 Thin client 12.25 Three-tiered client/server

architecture 12.26 Utility computing 12.27 Virtual machine 12.28 Virtualization 12.29 eXtensible Markup Language

(XML) 12.30 eXtensible Stylesheet Language

(XSL) 12.31 Web service

M12_VALA1629_09_GE_C12.indd 454 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 455

Match each of the key terms above to the definition that best fits it.

____ The cabling, hardware, and software used to connect workstations, computers, and file servers located in a con- fined geographical area (typically within one building or campus).

____ A software emulation of a physical computer system, both hardware and operating system, that allows more efficient sharing of physical hardware resources.

____ A device that manages file operations and is shared by each client PC attached to a LAN.

____ A cloud computing model in which a service provider offers applications via a cloud infrastructure.

____ A LAN-based computing environment in which a central database server or engine performs all database commands sent to it from client workstations, and application programs on each client concentrate on user interface functions.

____ The (back-end) portion of the client/sever database system running on the server that provides database processing and shared access functions.

____ The (front-end) portion of the client/server database sys- tem that provides the user interface and data manipulation functions.

____ Software building blocks that are used to ensure that com- mon system capabilities, such as user interfaces and print- ing, and modules are standardized to facilitate the data exchange between clients and servers.

____ A combination of hardware, software, and communication technologies that brings together data management, pre- sentation, and analysis into a three-tiered (or n-tiered) cli- ent/server environment.

____ A cloud computing model in which the customer can run his or her own applications that are typically designed using tools provided by the service provider; the customer has limited or no control over the underlying infrastructure.

____ A cloud computing model in which only the basic capabili- ties of processing, storage, and networking are provided.

____ A relatively simple and fast protocol for communicating JSON data between Web service applications and the oper- ating system.

____ A method for translating Internet domain names into Inter- net Protocol (IP) addresses.

____ A communications protocol for exchanging information on the Internet.

____ The standard language for representing content on the Web through the use of hundreds of command tags.

____ An Internet authoring language that allows designers to cre- ate customized tags, enabling the definition, transmission, validation, and interpretation of data between applications.

____ A protocol for communicating XML data between Web ser- vice applications and the operating system.

____ A client device designed so that most processing and data storage occur on the server.

____ A set of style rules that tell a Web browser how to present a document.

____ A specification for separating style from content when gen- erating XML pages.

____ Providing Internet content to users based upon knowledge of that customer.

____ Internet sites that allow users to customize information to their personal preferences.

____ A computing server where data analysis functions primarily reside.

____ Advanced client/server architectures in which there are three logical and distinct applications—data management, presentation, and analysis—that are combined to create a single information system.

____ A lightweight data interchange approach that is relatively easy for humans to understand and for computers to gener- ate or interpret.

____ A special type of software application for collecting, organiz- ing, and publishing Website content.

____ A method of communication between two electronic devices over a network.

____ A form of on-demand computing where resources in terms of processing, data storage, or networking are rented on an as-needed basis. The organization only pays for the services used.

____ A software architecture in which business processes are bro- ken down into individual components (or services) that are designed to achieve the desired results for the service con- sumer (which can be either an application, another service, or a person).

____ The act of creating virtual (rather than physical) versions of a variety of computing capabilities including hard- ware platforms, operating systems, storage devices, and networks.

____ The hardware, software, data, facilities, human resources, and services used by organizations to support their decision making, business processes, and competitive strategy.

M12_VALA1629_09_GE_C12.indd 455 15/04/2020 11:51

456 PART IV DESIGN

PROBLEMS AND EXERCISES 12.47 Under what circumstances would you recommend that

a file server approach, as opposed to a client/server approach, be used for a distributed information system application? What warnings would you give the prospective user of this file server approach? What factors would have to change for you to recommend the move to a client/ server approach?

12.48 Suppose you are responsible for the design of a new order entry and sales analysis system for a national chain of auto part stores. Each store has a PC that supports office func- tions. The company also has regional managers who travel from store to store working with the local managers to promote sales. There are four national offices for the regional managers, who each spend about 1 day a week in their office and 4 on the road. Stores place orders to replenish stock on a daily basis, based on sales history and inventory levels. The company uses the Internet to con- nect store PCs into the company’s main computer. Each regional manager has a laptop computer to also connect with stores and the main office. Recommend a technology architecture for supporting the business activities of the company.

12.49 In a project meeting regarding the development of an administrative system, a person mentions the “back-end” functionality of the system. What are they most likely refer- ring to?

12.50 Suppose you were designing applications for a standard file server environment. One issue discussed in this

chapter for this distributed processing environment is that the application software on each client PC must share in the responsibilities for data management. One data man- agement problem that can arise is that applications run- ning concurrently on two clients may want to update the same data at the same time. What could you do to manage this potential conflict? Is there any way this conflict might result in both PCs making no progress (in other words, going into an infinite loop)? How might you avoid such problems?

12.51 An extension of the three-tiered client/server archi- tecture is the n-tiered architecture, in which there are many specialized application servers and other functions (e.g., load balancers). Extend the reasons for utilizing the three-tiered architecture outlined in the chapter to an n-tiered architecture.

12.52 What is the primary reason for choosing advanced multi- tiered architectures over ordinary client/server solutions?

12.53 There is a strong movement toward wireless mobile com- puting using thin-client technology. Go to the Web and visit some of the major computer vendors that are produc- ing thin-client products such as smartphones and tablets. Investigate the features of each category of device and pre- pare a report that contrasts each type of device on at least the following criteria: screen size, networking options and speed, permanent memory, and applications.

12.54 Building on the research conducted in Problem and Exer- cise 12.53, what challenges does each device present for

REVIEW QUESTIONS 12.32 Contrast the following terms.

a. File server, client/server architecture, local area net- work (LAN)

b. Virtual Machine, Virtualization c. Infrastructure as a Service (IaaS), Platform as a Service

(PaaS), Software as a Service (SaaS) d. Private Cloud, Public Cloud e. Service-Oriented Architecture (SOA), Web Service f. Simple Object Access Protocol (SOAP), Representa-

tional State Transfer (REST) g. JavaScript Object Notation ( JSON), eXtensible Markup

Language (XML) h. Hypertext Markup Language (HTML), Hypertext

Transfer Protocol (HTTP), Domain Naming System (BIND)

i. Cascading Style Sheets (CSSs), eXtensible Stylesheet Language (XSL)

j. Personalization, Customization

12.33 Describe the limitations of a file server architecture.

12.34 Describe the advantages of a client/server architecture.

12.35 Summarize the reasons for using a three-tiered client/ server architecture.

12.36 What is an API?

12.37 Describe the characteristics of the cloud computing model.

12.38 Is a server conceptually different from a normal desktop computer?

12.39 What is the reason for working with virtual machines (also called a virtual server)?

12.40 What is the purpose of Web services? Name a few of the acronyms found in connection with Web services.

12.41 What is the difference between HTTP and HTML?

12.42 Why is it important to separate content from display when designing an Internet-based electronic commerce system?

12.43 According to HCI researcher Jakob Nielsen, what design principles can a designer use to establish a sense of trust?

12.44 Discuss how you can instill customer loyalty and trustwor- thiness when designing an Internet-based electronic com- merce system.

12.45 What is a CMS used for? Name a few popular CMSs.

12.46 What is the difference between HTML and server lan- guages? Name the major languages used on Web servers.

M12_VALA1629_09_GE_C12.indd 456 15/04/2020 11:51

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 457

designers when delivering an electronic commerce appli- cation? Are some devices more suitable for supporting some applications than others?

12.55 Having a number of different sizes of display for accessing online content poses a problem for Web designers and Web developers in general. Take a look at three newspaper Websites in your country. They usually have a lot of content and, thus, use rather wide pages (perhaps 1200 pixels). Look at how they have placed their different elements on the page—ads, content, banner, etc. Until a few years ago, these looked the same (but much smaller) on smart- phones and similar devices. With recent technologies, this has changed. View the same Website using a tablet (such as an iPad) and then a smartphone (the same effect can be achieved by making the window narrower). Which elements move, and which elements disappear completely (if any)?

12.56 Using the results from your study in the previous question, do you think that the newspaper Websites have made the right compromises? Has all important information been transferred to the devices with narrower windows?

12.57 Search the Internet for programming technologies and techniques that result in content being moved around on

the page (responsive design). In particular, search for the “media” element in CSS3 (CSS files are used for defining the layout of Web pages) and for the RelativePanel object in Microsoft Universal Windows Platform apps. What are the similarities and differences between the media ele- ment and the RelativePanel object?

12.58 Design consistency within an Internet site is an impor- tant way to build customer loyalty and trustworthiness. Visit one of your favorite Websites and analyze this site for design consistency. Your analysis should consider general layout, colors and fonts, labeling, links, and other such items.

12.59 As stated in the chapter, Web security is a double-edged sword. If the security measures are too high, customers may not bother accessing vital parts of the Website; and if the measures are too low, the Website and the underlying organization will probably soon run into problems. Discuss Websites that you are acquainted with that have some kind of obvious security measures, such as log-in pages. Do any of them seem too strict? Are any too dangerous to visit because of their lack of security?

FIELD EXERCISES 12.60 Visit an organization that has installed a LAN. Explore the

following questions.

a. Inventory all application programs that are delivered to client PCs using a file server architecture. How many users use each application? What are their professional and technical skills? What business processes are sup- ported by the application? What data are created, read, updated, or destroyed in each application? Could the same business processes be performed without using technology? If so, how? If not, why not?

b. Inventory all application programs that are delivered to client PCs using a client/server architecture. How many users use each application? What are their profes- sional and technical skills? What business processes are supported by the application? What data are created, read, updated, or destroyed in each application? Could the same business processes be performed without using technology? If so, how? If not, why not?

12.61 In this chapter, file servers were described as one way of providing information to users of a distributed informa- tion system. What file servers are available, and what are their relative strengths, weaknesses, and costs? What other types of servers are available and/or for what other uses are file servers employed (e.g., print servers)?

12.62 Search the Web for information related to Web services and the associated technology standards being utilized. Specifically, compare and contrast SOAP and REST using

the various characteristics you identify. Also, compare and contrast XML and JSON using a similar approach. Your analysis should include the advantages and disadvantages of each technology using common criteria.

12.63 A lot of Websites have members who can log in using usernames and passwords. Every now and again, there are reports of thousands of username–password combinations hijacked by hackers. This is especially problematic as most people use the same passwords on most sites they are reg- istered on. The reason the passwords can be retrieved is that they are stored as plain text in the Website’s database, and if a hacker gets into the database, they can access all the data stored. Try to find information on how to protect the passwords better but still enable users to sign in.

12.64 A number of companies, big and small, offer cloud-based hosting of data. Compare the cloud packages from major players such as Amazon (https://aws.amazon.com/ec2/) with much smaller ones, like City Network (www.citynet- work.se). How do their offers differ? Which solution seems more attractive to you?

12.65 The references in this chapter point to a number of sources that provide Website design guidelines (see addi- tional references in the References list). Visit these sites and summarize, in a report, guidelines not addressed in this chapter. Did you find inconsistencies or contradic- tions across the sites you studied? Why do these differences exist?

M12_VALA1629_09_GE_C12.indd 457 15/04/2020 11:51

https://aws.amazon.com/ec2/

http://www.citynetwork.se

http://www.citynet-work.se

458 PART IV DESIGN

Bass, L., Clements, P., & Kazman, R. (2012). Software architecture in practice (3rd ed.). Boston: Addison-Wesley.

DiMaggio, L. (2008). What is middleware? In plain English, please. Redhat Magazine. Retrieved April 10, 2018 from http://planet. jboss.org/post/what_is_middleware_in_plain_english_please.

Erl, T., Puttini, R., & Mahmood Z. (2013). Cloud computing: Con- cepts, technology & architecture. Upper Saddle River, NJ: Pren- tice Hall.

Fawcett, J., Ayers, D., & Quin, L. R. E. (2012). Beginning XML. Hoboken, NJ: Wrox.

Hoffer, J. A., Ramesh, V. & Topi, H. (2016). Modern database man- agement (12th ed.). Upper Saddle River, NJ: Prentice Hall.

Hofmann, P., & Woods, D. (2010, November/December). Cloud computing: The limits of public clouds for business applica- tions. IEEE Internet Computing, 90-93.

Kroenke, D.M., Auer, D.J., Vandenberg, S.L., & Yoder, R.C. (2017). Database concepts (8th ed.). New York: Pearson.

Marchioni, F. (2014). Enterprise application servers cookbook: Part 3: IBM websphere. Rome, Italy: ItBuzzPress.

McKnight, D. H., Choudhury, V., & Kacmar, C. (2002). Develop- ing and validating trust measures for e-commerce: An inte- grative typology. Information Systems Research, 13(3), 334–59.

Nielsen, J. (1997, August 1). Loyalty on the Web. Retrieved April 10, 2018 from http://www.nngroup.com/articles/ loyalty-on-the-web/.

Nielsen, J. (1998a, October 4). Personalization is over-rated. Retrieved April 10, 2018 from http://www.nngroup.com/ articles/personalization-is-over-rated/.

Nielsen, J. (1998b, November 29.) Web pages must live forever. Retrieved April 10, 2018 from http://www.nngroup.com/ articles/web-pages-must-live-forever/.

Nielsen, J. (1999, March 7). Trust or bust: Communicat- ing trustworthiness in web design. Retrieved April 10, 2018 from http://www.nngroup.com/articles/ trust-or-bust-communicating-trustworthiness-in-web-design/.

Nielsen, J. (2003, March 31). Intranet portals: A tool metaphor for corporate information. Retrieved April 10, 2018 from http://www.nngroup.com/articles/intranet-portals-a-tool- metaphor/.

Nielsen, J., & H. Loranger. (2006). Prioritizing web usability. Upper Saddle River, NJ: Prentice Hall.

NIST. (2011). The NIST definition of cloud computing. National Insti- tute of Standard and Technology. Retrieved April 10, 2018 from http://csrc.nist.gov/publications/nistpubs/800-145/ SP800-145.pdf.

Robbins, M. (2013). Thin client: 23 success secrets. Queensland, Australia: Emereo Publishing.

Valacich, J. S., & Schneider, C. (2018). Information systems today: Managing in the digital world (8th ed.). Upper Saddle River, NJ: Pearson.

Web service. (2018, April 5). In Wikipedia, The Free Encyclopedia. Retrieved 19:40, April 10, 2018, from https://en.wikipedia. org/w/index.php?title=Web_service&oldid=834330338

Zeldman, J. (2009). Designing with web standards (3rd ed.). India- napolis, IN: Peach Pit Press.

REFERENCES

M12_VALA1629_09_GE_C12.indd 458 15/04/2020 11:51

http://planet.jboss.org/post/what_is_middleware_in_plain_english_please

http://www.nngroup.com/articles/loyalty-on-the-web

http://www.nngroup.com/articles/personalization-is-over-rated

http://www.nngroup.com/articles/web-pages-must-live-forever

http://www.nngroup.com/articles/trust-or-bust-communicating-trustworthiness-in-web-design

http://www.nngroup.com/articles/intranet-portals-a-tool-metaphor/

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

https://en.wikipedia.org/w/index.php?title=Web_service&oldid=834330338

http://www.nngroup.com/articles/loyalty-on-the-web

http://www.nngroup.com/articles/personalization-is-over-rated

http://planet.jboss.org/post/what_is_middleware_in_plain_english_please

http://www.nngroup.com/articles/intranet-portals-a-tool-metaphor

http://www.nngroup.com/articles/web-pages-must-live-forever

http://www.nngroup.com/articles/trust-or-bust-communicating-trustworthiness-in-web-design

http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

https://en.wikipedia.org/w/index.php?title=Web_service&oldid=834330338

CHAPTER 12 DeSIgnIng DIStrIbuteD anD Internet SyStemS 459

site (http://www.nngroup.com). His site is extensive, with many short articles of helpful hints for making Websites usable.”

After visiting Nielsen’s site, the interns came up with the list of guidelines featured in PE Figure 12-1.

Case Questions

12.66 Visit the Nielsen Website and update PE Figure 12-1 based on guidelines and articles posted since this list was compiled. Add only elements you believe are essential and relevant to the design of “No Customer Escapes.”

12.67 Review Chapters 10 and 11. Combine into your answer to Case Question 12.66 guidelines from these chapters. How unique do you consider the human interface design guidelines for a Website to be from general application design guidelines? Justify your answer.

12.68 Search for other Web-based resources, besides the Nielsen Website, for Website design.(Hint: Look at the references at the end of this and prior chapters.) In what ways do the design guidelines you find con- tradict your answer to Case Question 12.67? Explain the differences.

12.69 This chapter introduced the concepts of loyalty and trustworthiness as necessary for customers to interact with a Website. What elements could be added to a customer loyalty site such as “No Customer Escapes” to improve the levels of loyalty and trustworthiness of Petrie’s customers?

PETRIE ELECTRONICS

Chapter 12: Designing Distributed and Internet Systems

Stephanie Welsh worked for Petrie’s database administra- tor. She had been overseeing two interns who were help- ing her translate conceptual database designs into physical designs. As they were finishing up the task she had assigned to them, she realized that they would soon need something else to do.

She called Sanjay Agarwal, one of the most talented inter- face designers in Petrie’s IT shop.

“Hi Sanjay, this is Stephanie. Got a minute?” “For you, I can make the time,” Sanjay replied. “Well, this is not about me, this is about my two interns.

They are about done with the database work I assigned them. They need something else to do, and I thought of you. Aren’t you starting work on some of the customized Web designs for ‘No Customer Escapes?’”

“Yep,” Sanjay said. “That’s next on my list of two thou- sand things I have to do this week.”

“So I can send them over? That will be great. They are both good workers and very bright, so I think you will get a lot out of them.”

“How much do they know about Web interface design?” Sanjay asked.

“Not much, I don’t think.” “Well, that’s not the answer I wanted. OK, I know what

I’ll do. I’ll have them derive a list of guiding principles for good Web interface design. They can start by looking at the Website design principles listed on Jakob Nielsen’s

PE FIGURE 12-1 Guidelines for design of Petrie’s “No Customer Escapes”

(Source: Adapted from the follow- ing sources: Jakob Nielsen Website http://www.nngroup.com, specifi- cally pages: http://www.nngroup. com/articles/drop-down-menus-use- sparingly/, http://www.nngroup. com/articles/top-10-mistakes-web- design/, http://www.nngroup.com/ articles/ten-usability-heuristics/, http://www.nngroup.com/articles/ reset-and-cancel-buttons/, and http://www.nngroup.com/articles/ top-ten-mistakes-revisited-three-years- later/.)

Feature Guideline

Interacting menus– When users select something on one menu, options change in other menus on the same page. These changing options confuse users. It’s hard to make a preferred option visible when it depends on a selection in another menu.

avoid

Very long menus– Long menus require users to scroll through them, and they can’t see all of their options at once. It’s better to break up the menu as a series of submenus or to represent some of the choices as hypertext links.

avoid

Menus of abbreviations– It is usually faster for users to simply type the abbreviation (e.g., a two-character state code) than to select it from a drop-down menu. Free-form input requires validation by a code on the Web page or on the server.

avoid

M12_VALA1629_09_GE_C12.indd 459 15/04/2020 11:51

http://www.nngroup.com

http://www.nngroup.com/articles/drop-down-menus-use-sparingly

http://www.nngroup.com/articles/top-10-mistakes-web-design

http://www.nngroup.com/articles/ten-usability-heuristics

http://www.nngroup.com/articles/reset-and-cancel-buttons

http://www.nngroup.com/articles/top-ten-mistakes-revisited-three-years-later

http://www.nngroup.com/articles/drop-down-menus-use-sparingly

http://www.nngroup.com/articles/top-10-mistakes-web-design

http://www.nngroup.com/articles/ten-usability-heuristics

http://www.nngroup.com/articles/reset-and-cancel-buttons

http://www.nngroup.com/articles/top-ten-mistakes-revisited-three-years-later

460 PART IV DESIGN

Language– Your site’s language should be natural and logical. It should be based on the users’ language, not system language. The site should feature words and concepts familiar to the user, following real-world conventions.

use user’s terms

Fixing mistakes– Users make mistakes and make bad choices. They need a way to exit from their mistakes without going through an extended dialogue. Your site should support undo, redo, and default settings. But a good design that minimizes errors is always better than a good design message.

make it easy

Actions– Make objects, actions, and options visible. Every part of the dialogue should be clear and independent of any other part. Instructions should be visible or easily accessible when appropriate.

make them obvious

Customize– Design the system for both novice and experienced users. Allow users to tailor the system to their frequent actions.for flexibility and e�ciency

Content– Every part of a dialogue should be relevant. Irrelevant information competes with necessary information and hence diminishes its visibility.

make it relevant

Cancel button – Users have come to rely on the Back button to get out of unintended or unpleasant situations. Using the Back button is not always the best way out. Include a Cancel button as well. Cancel provides an explicit way to quit, which allows a feeling of safety that goes beyond simply leaving a site.

use sparingly

Menus of well-known data– Selecting well-known data, such as month, city, or country, often breaks the flow of typing for users and creates other data entry problems.

avoid

Frames– Frames can be confusing when a user tries to print a page or when trying to link to another site. Frames can prevent a user from e-mailing a URL to other users and can be more clumsy for inexperienced users.

use sparingly

Moving page elements – Moving images have an overpowering e�ect on the human peripheral vision and can distract a user from productive use of other page content. Moving text may be di�cult to read.

Scrollings – minimize

Some users will not scroll beyond the information that is visible on the screen. Thus, critical content and navigation elements should be obvious (on the top of the page, possibly in a frame on the top of the page so that these elements never leave the page).

Context – emphasize

You know more about your site than users do. They have di�culty finding information, so the site should be designed to provide them the structure and sense of place they need. Try to design your site from the user’s perspective and relay this structure explicitly to users.

System status – make visible

The system should always provide information to users about what the system is doing. Reasonable feedback should be provided within a reasonable time frame.

use sparingly

M12_VALA1629_09_GE_C12.indd 460 15/04/2020 11:51

Chapter 13 System Implementation

Implementation and Maintenance

Chapter 14 Maintaining Information Systems

PA RT F I V E

461

M13A_VALA1629_09_GE_P05.indd 461 08/04/2020 17:35

462

Implementation and maintenance are the last two phases of the systems development life cycle. The purpose of implementation is to build a properly working system, install it in the organization, replace old systems and work methods, finalize system and user documentation, train users, and prepare support systems to assist users. Imple- mentation also involves closedown of the project, includ- ing evaluating personnel, reassigning staff, assessing the success of the project, and turning all resources over to those who will support and maintain the system. The pur- pose of maintenance is to fix and enhance the system to respond to problems and changing business conditions. Maintenance includes activities from all systems develop- ment phases. Maintenance also involves responding to requests to change the system, transforming requests into changes, designing the changes, and implementing them.

We address the variety of work done during system implementation in Chapter 13. For projects based on agile methodologies, coding and testing are done in con- cert with analysis and design, so systems resulting from such efforts will begin their implementation phases with coding and testing already completed. Projects based on traditional methodologies will begin implementation with detailed design specifications that are handed over to programming teams for coding and to quality assur- ance teams for testing. In Chapter 13, you will learn about testing systems and system components, and methods to ensure and measure software quality. Your role as a systems analyst may include developing a plan for testing, which includes developing all the test data required to exercise every part of the system. You start developing the test plan early in the project, usually during analysis, because test- ing requirements are highly related to system functional requirements. You also will learn how to document each test case and the results of each test. A testing plan usually follows a bottom-up approach, beginning with small mod- ules, followed by extensive alpha testing by the program- ming group, beta testing with users, and final acceptance testing. Testing ensures the quality of the software by using measures and methods such as structured walk-throughs.

Installing a new system involves more than making technical changes to computer systems. Managing installa- tion includes managing organizational changes as much as it does technical changes. We review several approaches to installation and several frameworks you can use to anticipate and control human and organizational resistance to change.

Documentation is extensive for any system. You have been developing most of the system documentation needed by system maintenance staff by keeping a thor- ough project workbook. You now need to finalize user

OVERVIEW

documentation. In Chapter 13, we provide a generic out- line for a user’s guide as well as a wide range of guidelines you can use to develop high-quality user documentation. Remember, documentation must be tested for complete- ness, accuracy, and readability.

While documentation is being finalized, user sup- port activities also need to be designed and implemented. Support includes training, whether through traditional, instructor-led classes; computer-based tutorials or e-learn- ing; or vendor-provided training. Electronic performance support systems deliver on-demand training. Many types of training are available from various sources over the Internet or corporate intranets. Once trained, users will still encoun- ter difficulties. Therefore, you, as an analyst, must consider ongoing support from help desks, newsletters, user groups, online bulletin boards, and other mechanisms, and these sources of support need to be tested and implemented. We conclude Chapter 13 with a brief review of project closedown activities because the end of implementation means the end of the project. We also provide an example of implementation for the Pine Valley Furniture WebStore.

After implementation, however, work on the system is just beginning. Today, as much as 80 percent of the life cycle cost of a system occurs after implementation. Maintenance handles updates to correct flaws and to accommodate new technologies as well as to meet new business conditions, regulations, and other requirements. In Chapter 14, you will learn about your role in systems maintenance.

There are four kinds of maintenance: corrective, adaptive, perfective, and preventive. You can help control the potentially monumental cost of a system by making systems maintainable. You can affect maintainability by reducing the number of defects, improving the skill of users, preparing high-quality documentation, and devel- oping a sound system structure.

You may also be involved in establishing a maintenance group for a system. You will learn about different organiza- tional structures for maintenance personnel and the reasons for each, and you will learn how to measure maintenance effectiveness. Configuration management and deciding how to handle change requests are important. You will learn how a systems librarian keeps track of baseline software modules, checks these out to maintenance staff, and then rebuilds systems. You will also learn about special issues for maintain- ing Websites and read about an example of a maintenance situation for the Pine Valley Furniture WebStore.

Chapter 13 includes the final installment of the Pet- rie Electronics project case. This final case segment helps you to understand implementation issues in an organiza- tional context.

PART FIVE

Implementation and Maintenance

M13A_VALA1629_09_GE_P05.indd 462 08/04/2020 17:35

463

After maintenance, the implementation phase of the systems development life cycle (SDLC) is the most expen- sive and time-consuming phase of the entire life cycle. Implementation is expensive because so many people are involved in the process; it is time consuming because of all the work that has to be completed. In a traditional plan- driven systems development project, physical design spec- ifications must be turned into working computer code, and the code must be tested until most of the errors have been detected and corrected. In a systems development project governed by agile methodologies, design, coding, and testing are done in concert, as you learned in previous chapters. Regardless of methodology used, once coding and testing are complete and the system is ready to “go live,” it must be installed (or put into production), user sites must be prepared for the new system, and users rely on the new system rather than the existing one to get their work done.

Implementing a new information system into an organizational context is not a mechanical process. The organizational context has been shaped and reshaped by the people who work in the organization. The work habits, beliefs, interrelationships, and personal goals of an organization’s members all affect the implementa- tion process. Although factors important to successful implementation have been identified, there are no sure

recipes you can follow. During implementation, you must be attuned to key aspects of the organizational context, such as history, politics, and environmental demands— aspects that can contribute to implementation failure if ignored.

In this chapter, you will learn about the many activities that the implementation phase comprises. We will discuss coding, testing, installation, documentation, user training, support for a system after it is installed, and implementa- tion success. Our intent is not to teach you how to program and test systems—most of you have already learned about writing and testing programs in the courses you took before this one. Rather, this chapter shows you where coding and testing fit in the overall scheme of implementation, espe- cially in a traditional, plan-driven context. The chapter stresses the view of implementation as an organizational change process that is not always successful.

In addition, you will learn about providing documen- tation about the new system for the information systems personnel who will maintain the system and for the sys- tem’s users. These same users must be trained to use what you have developed and installed in their workplace. Once training has ended and the system has become institution- alized, users will have questions about the system’s imple- mentation and how to use it effectively. You must provide a means for users to get answers to these questions and to identify needs for further training.

13.5 explain why system implementation sometimes fails;

13.6 describe the threats to system security and rem- edies that can be applied; and

13.7 show how traditional implementation issues apply to electronic commerce applications.

Learning Objectives After studying this chapter, you should be able to:

13.1 provide an overview of the system implementation process;

13.2 describe how software applications are tested;

13.3 apply four installation strategies: direct, parallel, single-location, and phased installation;

13.4 list the deliverables for documenting the system and for training and supporting users;

System Implementation13

Introduction

M13B_VALA1629_09_GE_C13.indd 463 08/04/2020 17:36

464 PART V IMPLEMENTATION AND MAINTENANCE

As a member of the system development team that developed and implemented the new system, your job is winding down now that installation and conversion are complete. The end of implementation marks the time for you to begin the process of project closedown. At the end of this chapter, we will turn to the topic of formally ending the systems development project.

After a brief overview of the coding, testing, and installation processes and the deliverables and outcomes from these processes, we will talk about software applica- tion testing. We then present the four types of installation: direct, parallel, single- location, and phased. You then will read about the process of documenting systems and training and supporting users as well as the deliverables from these processes. We then discuss the various types of documentation and numerous methods available for delivering training and support services. You will read about implementation as an organizational change process, with many organizational and people issues involved in the implementation effort. You will also read about the threats to security that orga- nizations face and some of the things that can be done to make systems more secure. Finally, you will see how the implementation of an electronic commerce application is similar to the implementation of more traditional systems.

SYSTEM IMPLEMENTATION System implementation is made up of many activities. The six major activities we are concerned with in this chapter are coding, testing, installation, documentation, training, and support (see Figure 13-1). The purpose of these steps is to convert the physical system specifications into working and reliable software and hardware, docu- ment the work that has been done, and provide help for current and future users and caretakers of the system. Coding and testing may have already been completed by this point if agile methodologies have been followed. Using a plan-driven methodology, coding and testing are often done by other project team members besides analysts, although analysts may do some programming. In any case, analysts are responsible for ensuring that all of these various activities are properly planned and executed. Next,

FIGURE 13-1 Systems development life cycle with the implementation phase highlighted

DesignImplementation

Planning

Maintenance Analysis

Coding Testing Installation Documentation Training Support

M13B_VALA1629_09_GE_C13.indd 464 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 465

we will briefly discuss these activities in two groups: (1) coding, testing, and installation and (2) documenting the system and training and supporting users.

Coding, Testing, and Installation Processes

Coding, as we mentioned before, is the process whereby the physical design specifi- cations created by the analysis team are turned into working computer code by the programming team. Depending on the size and complexity of the system, coding can be an involved, intensive activity. Regardless of the development methodology fol- lowed, once coding has begun, the testing process can begin and proceed in parallel. As each program module is produced, it can be tested individually, then as part of a larger program, and then as part of a larger system. You will learn about the different strategies for testing later in this chapter. We should emphasize that, although testing is done during implementation, you must begin planning for testing earlier in the project. Planning involves determining what needs to be tested and collecting test data. This is often done during the analysis phase because testing requirements are related to system requirements.

Installation is the process during which the current system is replaced by the new system. This includes conversion of existing data, software, documentation, and work procedures to those consistent with the new system. Users must give up the old ways of doing their jobs, whether manual or automated, and adjust to accomplishing the same tasks with the new system. Users will sometimes resist these changes, and you must help them adjust. However, you cannot control all the dynamics of user–system interaction involved in the installation process.

Deliverables and Outcomes from Coding, Testing, and Installation

Table 13-1 shows the deliverables from the coding, testing, and installation processes. Some programming languages include utilities to generate documentation automati- cally, while others require more effort on the part of the coder to establish good documentation. But even well-documented code can be mysterious to maintenance programmers who must maintain the system for years after the original system was written and the original programmers have moved on to other jobs. Therefore, clear, complete documentation for all individual modules and programs is crucial to the system’s continued smooth operation. The results of program and system testing are important deliverables from the testing process because they document the tests as well as the test results. For example, what type of test was conducted? What test data were used? How did the system handle the test? The answers to these questions can provide important information for system maintenance because changes will require retesting, and similar testing procedures will be used during the maintenance process.

The next two deliverables, user guides and the user training plan, result from the installation process. User guides provide information on how to use the new system, and the training plan is a strategy for training users so that they can quickly learn

1. Coding a. Code b. Program documentation

2. Testing a. Test scenarios (test plan) and

test data b. Results of program and system

testing

3. Installation a. User guides b. User training plan c. Installation and conversion plan

i. Software and hardware installation schedule

ii. Data conversion plan iii. Site and facility remodeling plan

TABLE 13-1 Deliverables for Coding, Testing, and Installation

M13B_VALA1629_09_GE_C13.indd 465 08/04/2020 17:36

466 PART V IMPLEMENTATION AND MAINTENANCE

the new system. The development of the training plan probably began earlier in the project, and some training, on the concepts behind the new system, may have already taken place. During the early stages of implementation, the training plans are finalized and training on the use of the system begins. Similarly, the installation plan lays out a strategy for moving from the old system to the new, from the beginning to the end of the process. Installation includes installing the system (hardware and software) at central and user sites. The installation plan answers such questions as when the new system will be installed, which installation strategies will be used, who will be involved, what resources are required, which data will be converted and cleansed, and how long the installation process will take. It is not enough that the system is installed; users must actually use it.

As an analyst, your job is to ensure that all of these deliverables are produced and are done well. You may produce some of the deliverables, such as test data, user guides, and an installation plan; for other deliverables, such as code, you may only supervise or simply monitor their production or accomplishment. The extent of your implementation responsibilities will vary according to the size and standards of the organization you work for, but your ultimate role includes ensuring that all the imple- mentation work leads to a system that meets the specifications developed in earlier project phases.

The Processes of Documenting the System, Training Users, and Supporting Users Although the process of documentation proceeds throughout the life cycle, it receives formal attention during the implementation phase because the end of implementation largely marks the end of the analysis team’s involvement in systems development. As the team is getting ready to move on to new projects, you and the other analysts need to prepare documents that reveal all of the important information you have accumulated about this system during its development and implementation. There are two audiences for this final documentation: (1) the information systems personnel who will maintain the system throughout its productive life, and (2) the people who will use the system as part of their daily lives. The analysis team in a large organization can get help in preparing documentation from specialized staff in the information systems department.

Larger organizations also tend to provide training and support to computer users throughout the organization. Some of the training and support is very specific to particular application systems, whereas the rest is general to particular operating systems or off-the-shelf software packages. For example, it is common to find courses on Microsoft Windows in organization-wide training facilities. Analysts are mostly uninvolved with general training and support, but they do work with corporate train- ers to provide training and support tailored to particular computer applications they have helped to develop. Centralized information system training facilities tend to have specialized staff who can help with training and support issues. In smaller organiza- tions that cannot afford to have well-staffed centralized training and support facilities, fellow users are the best source of training and support that users have, whether the software is customized or off the shelf.

Deliverables and Outcomes from Documenting the System, Training Users, and Supporting Users

Table 13-2 shows the deliverables from documenting the system, training users, and supporting users. At the very least, the development team must prepare user doc- umentation. For most modern information systems, documentation includes any online help designed as part of the system interface. The development team should think through the user training process: Who should be trained? How much train- ing is adequate for each training audience? What do different types of users need to learn during training? The training plan should be supplemented by actual training

M13B_VALA1629_09_GE_C13.indd 466 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 467

modules, or at least outlines of such modules, that at a minimum address the three questions stated previously. Finally, the development team should also deliver a user support plan that addresses issues such as how users will be able to find help once the information system has become integrated into the organization. The development team should consider a multitude of support mechanisms and modes of delivery. Each deliverable is addressed in more detail later in this chapter.

SOFTWARE APPLICATION TESTING As we mentioned previously, in traditional plan-driven systems development projects, analysts prepare system specifications that are passed on to programmers for coding. Although coding takes considerable effort and skill, the practices and processes of writing code do not belong in this text. However, because software application testing is an activity that analysts plan (beginning in the analysis phase) and sometimes super- vise, depending on organizational standards, you need to understand the essentials of the testing process. Although this section of the text focuses on testing from the perspective of traditional development practices, many of the same types of tests can be used during the analyze–design–code–test cycle common to the agile methodolo- gies. Coding and testing in eXtreme Programming will be discussed briefly toward the end of this section on testing.

Software testing begins early in the SDLC, even though many of the actual test- ing activities are carried out during implementation. During analysis, you develop a master test plan. During design, you develop a unit test plan, an integration test plan, and a system test plan. During implementation, these various plans are put into effect and the actual testing is performed.

The purpose of these written test plans is to improve communication among all the people involved in testing the application software. The plan specifies what each person’s role will be during testing. The test plans also serve as checklists you can use to determine whether the master test plan has been completed. The master test plan is not just a single document, but a collection of documents. Each of the component documents represents a complete test plan for one part of the system or for a particular type of test. Presenting a complete master test plan is far beyond the scope of this book. To give you an idea of what a master test plan involves, we present an abbreviated table of contents of one in Table 13-3.

A master test plan is a project within the overall systems development project. Because at least some of the system testing will be done by people who have not been involved in the system development so far, the Introduction provides general information about the system and the need for testing. The Overall Plan and Testing Requirements sections are like a Baseline Project Plan for testing, with a schedule of events, resource requirements, and standards of practice outlined. Procedure Con- trol explains how the testing is conducted, including how changes to fix errors will be documented. The fifth and final section explains each specific test necessary to validate that the system performs as expected.

1. Documentation a. System documentation b. User documentation

2. User Training Plan a. Classes b. Tutorials

3. User Training Modules a. Training materials b. Computer-based training aids

4. User Support Plan a. Help desk b. Online help c. Bulletin boards and other support mechanisms

TABLE 13-2 Deliverables for Documenting the System, Training, and Supporting Users

M13B_VALA1629_09_GE_C13.indd 467 08/04/2020 17:36

468 PART V IMPLEMENTATION AND MAINTENANCE

Some organizations have specially trained personnel who supervise and sup- port testing. Testing managers are responsible for developing test plans, establishing testing standards, integrating testing and development activities in the life cycle, and ensuring that test plans are completed. Testing specialists help develop test plans, create test cases and scenarios, execute the actual tests, and analyze and report test results.

Seven Different Types of Tests

Software application testing is an umbrella term that covers several types of tests. Mosley (1993) organizes the types of tests according to whether they employ static or dynamic techniques and whether the test is automated or manual. Static testing means that the code being tested is not executed. The results of running the code are not an issue for that particular test. Dynamic testing, on the other hand, involves execution of the code. Automated testing means the computer conducts the test, whereas manual testing means that people complete the test. Using this framework, we can categorize the different types of tests, as shown in Table 13-4.

Let’s examine each type of test in turn. Inspections are formal group activities where participants manually examine code for occurrences of well-known errors. Syn- tax, grammar, and some other routine errors can be checked by automated inspection software, so manual inspection checks are used for more subtle errors. Each program- ming language lends itself to certain types of errors that programmers make when coding, and these common errors are well-known and documented. Code inspection

Inspections A testing technique in which participants examine program code for predictable language-specific errors.

1. Introduction a. Description of system to be tested b. Objectives of the test plan c. Method of testing d. Supporting documents

2. Overall Plan a. Milestones, schedules, and

locations b. Test materials

i. Test plans ii. Test cases iii. Test scenarios iv. Test log

3. Testing Requirements a. Hardware b. Software c. Personnel

4. Procedure Control a. Test initiation b. Test execution c. Test failure d. Access/change control e. Document control

5. Test-Specific or Component-Specific Test Plans a. Objectives b. Software description c. Method d. Milestones, schedule, progression,

and locations e. Requirements f. Criteria for passing tests g. Resulting test materials h. Execution control i. Attachments

(Source: Adapted from Mosley, 1993.)

TABLE 13-3 Table of Contents of a Master Test Plan

Manual Automated

Static Inspections Syntax checking Dynamic Walk-throughs Unit test

Desk checking Integration test System test

(Source: Adapted from Mosley, 1993.)

TABLE 13-4 A Categorization of Test Types

M13B_VALA1629_09_GE_C13.indd 468 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 469

participants compare the code they are examining with a checklist of well-known errors for that particular language. Exactly what the code does is not investigated in an inspection. It has been estimated that code inspections detect from 60 to 90 percent of all software defects as well as provide programmers with feedback that enables them to avoid making the same types of errors in future work (Fagan, 1986). The inspection process can also be used for tasks such as design specifications.

Unlike inspections, what the code does is an important question in a walk- through. The use of structured walk-throughs is a very effective method of detecting errors in code. As you saw in Chapter 5, structured walk-throughs can be used to review many systems development deliverables, including logical and physical design specifications as well as code. Whereas specification walk-throughs tend to be for- mal reviews, code walk-throughs tend to be informal. Informality tends to make pro- grammers less apprehensive about walk-throughs and helps increase their frequency. According to Yourdon (1989), code walk-throughs should be done frequently when the pieces of work reviewed are relatively small and before the work is formally tested. If walk-throughs are not held until the entire program is tested, the programmer will have already spent too much time looking for errors that the programming team could have found much more quickly. The programmer’s time will have been wasted, and the other members of the team may become frustrated because they will not find as many errors as they would have if the walk-through had been conducted earlier. Further, the longer a program goes without being subjected to a walk-through, the more defensive the programmer becomes when the code is reviewed. Although each organization that uses walk-throughs conducts them differently, there is a basic struc- ture that you can follow that works well (see Figure 13-2).

It should be stressed that the purpose of a walk-through is to detect errors, not to correct them. It is the programmer’s job to correct the errors uncovered in a walk- through. Sometimes it can be difficult for the reviewers to refrain from suggesting ways to fix the problems they find in the code, but increased experience with the process can help change a reviewer’s behavior.

What the code does is important in desk checking, an informal process in which the programmer or someone else who understands the logic of the program works through the code with a paper and pencil. The programmer executes each instruc- tion, using test cases that may or may not be written down. In one sense, the reviewer acts as the computer, mentally checking each step and its results for the entire set of computer instructions.

Among the list of automated testing techniques in Table 13-4, only one tech- nique is static—syntax checking. Syntax checking is typically done by a compiler. Errors in syntax are uncovered but the code is not executed. For the other three automated techniques, the code is executed.

Desk checking A testing technique in which the pro- gram code is sequentially executed manually by the reviewer.

FIGURE 13-2 Steps in a typical walk-through

(Source: Based on Yourdon, 1989.)

GUIDELINES FOR CONDUCTING A CODE WALK-THROUGH 1. Have the review meeting chaired by the project manager or chief programmer, who is

also responsible for scheduling the meeting, reserving a room, setting the agenda, inviting participants, and so on.

2. The programmer presents his or her work to the reviewers. Discussion should be general during the presentation.

3. Following the general discussion, the programmer walks through the code in detail, focusing on the logic of the code rather than on specific test cases. Reviewers ask to walk through specific test cases.4.

5. The chair resolves disagreements if the review team members cannot reach agreement among themselves and assigns duties, usually to the programmer, for making specific changes. A second walk-through is then scheduled if needed.6.

M13B_VALA1629_09_GE_C13.indd 469 08/04/2020 17:36

470 PART V IMPLEMENTATION AND MAINTENANCE

Unit testing, sometimes called module testing, is an automated technique whereby each module is tested alone in an attempt to discover any errors that may exist in the module’s code. But because modules coexist and work with other modules in pro- grams and the system, they must also be tested together in larger groups. Combining modules and testing them is called integration testing. Integration testing is gradual. First you test the coordinating module and only one of its subordinate modules. After the first test, you add one or two other subordinate modules from the same level. Once the program has been tested with the coordinating module and all of its immediately subordinate modules, you add modules from the next level and then test the program. You continue this procedure until the entire program has been tested as a unit. System testing is a similar process, but instead of integrating modules into programs for test- ing, you integrate programs into systems. System testing follows the same incremental logic that integration testing does. Under both integration and system testing, not only do individual modules and programs get tested many times, so do the interfaces between modules and programs.

Current practice calls for a top-down approach to writing and testing modules. Under a top-down approach, the coordinating module is written first. Then the mod- ules at the next level in the structure chart are written, followed by the modules at the next level, and so on, until all of the modules in the system are done. Each module is tested as it is written. Because top-level modules contain many calls to subordinate modules, you may wonder how they can be tested if the lower-level modules haven’t been written yet. The answer is stub testing. Stubs are two or three lines of code writ- ten by a programmer to stand in for the missing modules. During testing, the coordi- nating module calls the stub instead of the subordinate module. The stub accepts control and then returns it to the coordinating module.

System testing is more than simply expanded integration testing where you are testing the interfaces between programs in a system rather than testing the interfaces between modules in a program. System testing is also intended to demonstrate whether a system meets its objectives. This is not the same as testing a system to deter- mine whether it meets requirements—that is the focus of acceptance testing, which will be discussed later. To verify that a system meets its objectives, system testing involves using nonlive test data in a nonlive testing environment. Nonlive means that the data and situation are artificial, developed specifically for testing purposes, although both the data and the environment are similar to what users would encoun- ter in everyday system use. The system test is typically conducted by information sys- tems personnel and led by the project team leader, although it can also be conducted by users under MIS guidance. The scenarios that form the basis for system tests are prepared as part of the master test plan.

The Testing Process

Up to this point, we have talked about the master test plan and seven different types of tests for software applications. We haven’t said very much about the process of testing itself. There are two important things to remember about testing information systems:

1. The purpose of testing is to confirm that the system satisfies requirements. 2. Testing must be planned.

These two points have several implications for the testing process, regardless of the type of test being conducted. First, testing is not haphazard. You must pay attention to many different aspects of a system, such as response time, response to boundary data, response to no input, response to heavy volumes of input, and so on. You must test anything (within resource constraints) that could go wrong or be wrong with a system. At a minimum, you should test the most frequently used parts of the system and as many other paths throughout the system as time permits. Planning gives analysts and programmers an opportunity to think through all the potential problem

Unit testing The process of testing each module alone in an attempt to discover any errors in its code.

Integration testing The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typi- cally integrated in a top-down, incre- mental fashion.

System testing The bringing together of all of the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion.

Stub testing A technique used in testing modules, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substi- tute for subordinate modules.

M13B_VALA1629_09_GE_C13.indd 470 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 471

areas, list these areas, and develop ways to test for problems. As indicated previously, one part of the master test plan is creating a set of test cases, each of which must be carefully documented (see Figure 13-3 for an outline of a test case description).

A test case is a specific scenario of transactions, queries, or navigation paths that represent a typical, critical, or abnormal use of the system. A test case should be repeatable so that it can be rerun as new versions of the software are tested. This is important for all code, whether written in-house, developed by a contractor, or pur- chased. Test cases need to determine that new software works with other existing soft- ware with which it must share data. Even though analysts often do not do the testing, systems analysts, because of their intimate knowledge of applications, often make up or find test data. The people who create the test cases should not be the same people as those who coded and tested the system. In addition to a description of each test case, there must also be a description of the test results, with an emphasis on how the actual results differed from the expected results (see Figure 13-4). This description will indicate why the results were different and what, if anything, should be done to change the software. This description will then suggest the need for retesting, possibly introducing new tests to discover the source of the differences.

One important reason to keep such a thorough description of test cases and results is so that testing can be repeated for each revision of an application. Although new versions of a system may necessitate new test data to validate new features of the application, previous test data usually can and should be reused. Results from the use of the test data with prior versions are compared to new versions to show that changes have not introduced new errors and that the behavior of the system, including

FIGURE 13-3 Test case description form

(Source: Adapted from Mosley, 1993.)

Pine Valley Furniture Company Test Case Description

Test Case Number: Date: Test Case Description:

Program Name: Testing State: Test Case Prepared By:

Test Administrator:

Description of Test Data:

Expected Results:

Actual Results:

M13B_VALA1629_09_GE_C13.indd 471 08/04/2020 17:36

472 PART V IMPLEMENTATION AND MAINTENANCE

response time, is no worse. A second implication for the testing process is that test cases must include illegal and out-of-range data. The system should be able to handle any possibility, no matter how unlikely; the only way to find out is to test.

Testing often requires a great deal of labor. Manual code reviews can be very time consuming and tedious work; and, most importantly, are not always the best solution. As such, special purpose testing software, called a testing harness, is being developed for a variety of environments to help designers automatically review the quality of their code. In many situations, a testing harness will greatly enhance the testing process because it can automatically expand the scope of the tests beyond the current development platform as well as be run every time there is a new version of the software. For instance, with the testing harness called Costello, a developer can answer questions such as how stable is the code? Does the code follow standard rules? Will the code work across multiple platforms? When deploying large-scale, multi-platform projects, automatic code review systems have become a necessity.

Combining Coding and Testing

Although coding and testing are in many ways part of the same process, it is not uncommon in large and complicated systems development environments to find the two practices separated from each other. Big companies and big projects often have dedicated testing staffs that develop test plans and then use the plans to test software after it has been written. You have already seen how many different types of testing there are, and you can deduce from that how elaborate and extensive testing can be.

Testing harness An automated testing environment used to review code for errors, standards vio- lations, and other design flaws.

FIGURE 13-4 Test case results form

(Source: Adapted from Mosley, 1993.) Pine Valley Furniture Company Test Case Results

Test Case Number: Date:

Program Name: Module Under Test:

Suggestions for next steps:

M13B_VALA1629_09_GE_C13.indd 472 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 473

As you recall, with eXtreme Programming (XP) (Beck & Andres, 2004) and other agile methodologies, coding and testing are intimately related parts of the same pro- cess, and the programmers who write the code also write the tests. The general idea is that code is tested soon after it is written.

After testing, all of the code that works may be integrated at the end of each working day, and working versions of the system will be released frequently, as often as once per week in some cases. XP developers design and build working systems in very little time (relative to traditionally organized methods).

One particular technique used in XP to continually improve system quality is refactoring. Refactoring is nothing more than simplifying a system, typically after a new feature or set of features has been added. As more features are added to a system, it becomes more complex, and this complexity will be reflected in the code. After a time of increasing complexity, XP developers stop and redesign the system. The sys- tem must still pass the test cases written for it after it has been simplified, so rework continues until the tests can be passed. Different forms of refactoring include simpli- fying complex statements, abstracting solutions from reusable code, and removing duplicate code. Refactoring and the continuing simplification it implies reflect the iterative nature of XP and the other Agile Methodologies. As development progresses and the system gets closer to being ready for production, the iterations and the evolu- tion of the system slow, a process Beck (2000) calls “productionizing.” A system ready to go into production is ready to be released to users, either customers ready to buy the software or internal users.

Acceptance Testing by Users

Once the system tests have been satisfactorily completed, the system is ready for acceptance testing, which is testing the system in the environment where it will eventually be used. Acceptance refers to the fact that users typically sign off on the system and “accept” it once they are satisfied with it. The purpose of acceptance testing is for users to determine whether the system meets their requirements. The extent of acceptance testing will vary with the organization and with the system in question. The most complete acceptance testing will include alpha testing, in which simulated but typical data are used for system testing; beta testing, in which live data are used in the users’ real working environment; and a system audit conducted by the organization’s internal auditors or by members of the quality assurance group.

During alpha testing, the entire system is implemented in a test environment to discover whether the system is overtly destructive to itself or to the rest of the environ- ment. The types of tests performed during alpha testing include the following:

• Recovery testing—forces the software (or environment) to fail in order to verify that recovery is properly performed.

• Security testing—verifies that protection mechanisms built into the system will protect it from improper penetration.

• Stress testing—tries to break the system (e.g., what happens when a record is written to the database with incomplete information or what happens under extreme online transaction loads or with a large number of concurrent users).

• Performance testing—determines how the system performs in the range of possible environments in which it may be used (e.g., different hardware configurations, networks, operating systems, and so on); often the goal is to have the system perform with similar response time and other performance measures in each environment.

In beta testing, a subset of the intended users runs the system in the users’ own environments using their own data. The intent of the beta test is to determine whether the software, documentation, technical support, and training activities work

Refactoring Making a program simpler after adding a new feature.

Acceptance testing The process whereby actual users test a completed information system, the end result of which is the users’ acceptance of it.

Alpha testing User testing of a completed information system using simulated data.

Beta testing User testing of a completed information system using real data in the real user environment.

M13B_VALA1629_09_GE_C13.indd 473 08/04/2020 17:36

474 PART V IMPLEMENTATION AND MAINTENANCE

as intended. In essence, beta testing can be viewed as a rehearsal of the installation phase. Problems uncovered in alpha and beta testing in any of these areas must be corrected before users can accept the system. Systems analysts can tell many stories about long delays in final user acceptance due to system bugs.

INSTALLATION The process of moving from the current information system to the new one is called installation. All employees who use a system, whether they were consulted during the development process or not, must give up their reliance on the current system and begin to rely on the new system. Four different approaches to installation have emerged over the years: direct, parallel, single-location, and phased (Figure 13-5). The approach an organization decides to use will depend on the scope and com- plexity of the change associated with the new system and the organization’s risk aversion.

Direct Installation

The direct, or abrupt, approach to installation (also called “cold turkey”) is as sudden as the name indicates: The old system is turned off and the new system is turned on (Figure 13-5a). Under direct installation, users are at the mercy of the new system. Any errors resulting from the new system will have a direct impact on the users and how they do their jobs and, in some cases—depending on the centrality of the system to the organization—on how the organization performs its business. If the new system fails, considerable delay may occur until the old system can again be made operational and business transactions are re-entered to make the database up to date. For these reasons, direct installation can be very risky. Further, direct installation requires a complete installation of the whole system. For a large system, this may mean a long time until the new system can be installed, thus delaying system benefits or even miss- ing the opportunities that motivated the system request. On the other hand, it is the least expensive installation method, and it creates considerable interest in making the installation a success. Sometimes, a direct installation is the only possible strategy if there is no way for the current and new systems to coexist, which they must do in some way in each of the other installation approaches.

Parallel Installation

Parallel installation is as riskless as direct installation is risky. Under parallel installa- tion, the old system continues to run alongside the new system until users and man- agement are satisfied that the new system is effectively performing its duties and the old system can be turned off (Figure 13-5b). All of the work done by the old system is concurrently performed by the new system. Outputs are compared (to the greatest extent possible) to help determine whether the new system is performing as well as the old. Errors discovered in the new system do not cost the organization much, if anything, because errors can be isolated and the business can be supported with the old system. Because all work is essentially done twice, a parallel installation can be very expensive; running two systems implies employing (and paying) two staffs to not only operate both systems, but also to maintain them. A parallel approach can also be confusing to users because they must deal with both systems. As with direct installa- tion, there can be a considerable delay until the new system is completely ready for installation. A parallel approach may not be feasible, especially if the users of the system (such as customers) cannot tolerate redundant effort or if the size of the system (number of users or extent of features) is large.

Installation The organizational process of changing over from the current information sys- tem to a new one.

Direct installation Changing over from the old informa- tion system to a new one by turning off the old system when the new one is turned on.

Parallel installation Running the old information system and the new one at the same time until man- agement decides the old system can be turned off.

M13B_VALA1629_09_GE_C13.indd 474 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 475

Single-Location Installation

Single-location installation, also known as location or pilot installation, is a middle-of-the- road approach compared with direct and parallel installation. Rather than convert all of the organization at once, single-location installation involves changing from the cur- rent to the new system in only one place or in a series of separate sites over time. (Figure 13-5c depicts this approach for a simple situation of two locations.) The single location may be a branch office, a single factory, or one department, and the actual approach

Single-location installation Trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization.

FIGURE 13-5 Comparison of installation strategies (a) Direct installation

Current System

Time

Install New System

New System

(b) Parallel installation Current System

Time

Install New System

New System

Install New System

Location 1

Current System

Install New System

Location 2

New System

(d) Phased installation

(Source: Adapted from Bell and Evans, 1989.)

Current System

New Module 1

. . .

Install Module 1

Install Module 2

Current System Without Module 1 Current System Without Modules 1 & 2

New Module 2 . . .

M13B_VALA1629_09_GE_C13.indd 475 08/04/2020 17:36

476 PART V IMPLEMENTATION AND MAINTENANCE

used for installation in that location may be any of the other approaches. The key advan- tage to single-location installation is that it limits potential damage and potential cost by limiting the effects to a single site. Once management has determined that installa- tion has been successful at one location, the new system may be deployed in the rest of the organization, possibly continuing with installation at one location at a time. Success at the pilot site can be used to convince reluctant personnel at other sites that the system can be worthwhile for them as well. Problems with the system (the actual software as well as documentation, training, and support) can be resolved before deployment to other sites. Even though the single-location approach may be simpler for users, it still places a large burden on information systems (IS) staff to support two versions of the system. On the other hand, because problems are isolated at one site at a time, IS staff members can devote all of their efforts to success at the pilot site. Also, if different loca- tions require sharing of data, extra programs will need to be written to synchronize the current and new systems; although this will happen transparently to users, it is extra work for IS staff. As with each of the other approaches (except phased installation), the whole system is installed; however, some parts of the organization will not get the ben- efits of the new system until the pilot installation has been completely tested.

Phased Installation

Phased installation, also called staged installation, is an incremental approach. With phased installation, the new system is brought online in functional components; dif- ferent parts of the old and new systems are used in cooperation until the whole new system is installed. (Figure 13-5d shows the phase-in of the first two modules of a new system.) Phased installation, like single-location installation, is an attempt to limit the organization’s exposure to risk, whether in terms of cost or disruption of the business. By converting gradually, the organization’s risk is spread out over time and place. Also, a phased installation allows for some benefits from the new system before the whole system is ready. For example, new data-capture methods can be used before all reporting modules are ready. For a phased installation, the new and replaced systems must be able to coexist and probably share data. Thus, bridge programs connecting old and new databases and programs often must be built. Sometimes, the new and old systems are so incompatible (built using totally different structures) that pieces of the old system cannot be incrementally replaced, so this strategy is not feasible. A phased installation is akin to bringing out a sequence of releases of the system. Thus, a phased approach requires careful version control, repeated conversions at each phase, and a long period of change, which may be frustrating and confusing to users. On the other hand, each phase of change is smaller and more manageable for all involved.

Planning Installation

Each installation strategy involves converting not only software, but also data and (potentially) hardware, documentation, work methods, job descriptions, offices and other facilities, training materials, business forms, and other aspects of the system. For example, it is necessary to recall or replace all the current system documentation and business forms, which suggests that the IS department must keep track of who has these items so that they can be notified and receive replacement items. In practice, you will rarely choose a single strategy to the exclusion of all others; most installations will rely on a combination of two or more approaches. For example, if you choose a single-location strategy, you have to decide how installation will proceed there and at subsequent sites. Will it be direct, parallel, or phased?

Of special interest in the installation process is the conversion of data. Because existing systems usually contain data required by the new system, current data must be made error free, unloaded from current files, combined with new data, and loaded into new files. Data may need to be reformatted to be consistent with more advanced data types supported by newer technology used to build the new system. New data

Phased installation Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extend- ing the installation to cover the whole new system.

M13B_VALA1629_09_GE_C13.indd 476 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 477

fields may have to be entered in large quantities so that every record copied from the current system has all the new fields populated. Manual tasks, such as taking a physical inventory, may need to be done in order to validate data before they are transferred to the new files. The total data conversion process can be tedious. Furthermore, this process may require that current systems be shut off while the data are extracted so that updates to old data, which would contaminate the extract process, cannot occur.

Any decision that requires the current system to be shut down, in whole or in part, before the replacement system is in place must be done with care. Typically, off-hours are used for installations that require a lapse in system support. Whether a lapse in service is required or not, the installation schedule should be announced to users well in advance to let them plan their work schedules around outages in service and periods when their system support might be erratic. Successful installation steps should also be announced, and special procedures put in place so that users can eas- ily inform you of problems they encounter during installation periods. You should also plan for emergency staff to be available in case of system failure so that business operations can be recovered and made operational as quickly as possible. Another consideration is the business cycle of the organization. Most organizations face heavy workloads at particular times of year and relatively light loads at other times. A well- known example is the retail industry, where the busiest time of year is the fall, right before the year’s major gift-giving holidays. You wouldn’t want to schedule installation of a new point-of-sale system to begin December 1 for a department store. Make sure you understand the cyclical nature of the business you are working with before you schedule installation.

Planning for installation may begin as early as the analysis of the organization supported by the system. Some installation activities, such as buying new hardware, remodeling facilities, validating data to be transferred to the new system, and col- lecting new data to be loaded into the new system, must be done before the software installation can occur. Often the project team leader is responsible for anticipating all installation tasks and assigns responsibility for each to different analysts.

Each installation process involves getting workers to change the way they work. As such, installation should be looked at not as simply installing a new computer system, but as an organizational change process. More than just a computer system is involved— you are also changing how people do their jobs and how the organization operates.

DOCUMENTING THE SYSTEM In one sense, every systems development project is unique and will generate its own unique documentation. The approach taken by the development team, whether more traditional and plan-oriented or more agile, will also determine the amount and type of documentation that is generated. System development projects do have many simi- larities, however, which dictate that certain activities be undertaken and which of those activities must be documented. Bell and Evans (1989) illustrate how a generic SDLC maps onto a generic list of when specific systems development documentation elements are finalized (Table 13-5). As you compare the generic life cycle in Table 13-5 with the life cycle presented in this book, you will see that there are differences, but the general structure of both life cycles is the same because both include the basic phases of analy- sis, design, implementation, and project planning. Specific documentation will vary depending on the life cycle you are following, and the format and content of the docu- mentation may be mandated by the organization for which you work. However, a basic outline of documentation can be adapted for specific needs, as shown in Table 13-5. Note that this table indicates when documentation is typically finalized; you should start developing documentation elements early, as the information needed is captured.

We can simplify the situation even more by dividing documentation into two basic types, system documentation and user documentation. System documentation records detailed information about a system’s design specifications, its internal work- ings, and its functionality. In Table 13-5, all of the documentation listed (except for

System documentation Detailed information about a system’s design specifications, its internal work- ings, and its functionality.

User documentation Written or other visual information about an application system, how it works, and how to use it.

M13B_VALA1629_09_GE_C13.indd 477 08/04/2020 17:36

478 PART V IMPLEMENTATION AND MAINTENANCE

System Delivery) would qualify as system documentation. Whereas system documen- tation is intended primarily for maintenance programmers (see Chapter 14), user documentation is intended primarily for users. An organization may have definitive standards on system documentation. These standards may include the outline for the project dictionary and specific pieces of documentation within it. Standards for user documentation are not as explicit.

User Documentation

User documentation consists of written or other visual information about an applica- tion system, how it works, and how to use it. An excerpt of online user documentation for Microsoft Word appears in Figure 13-6. The information provided shows how a user can create newsletter columns in a Word file. Such presentation methods have become standard for help files in online PC documentation.

Figure 13-6 shows a help file, which is just one type of user documentation. Other types of user documentation include reference guides, quick reference guides, release descriptions, system administrator’s guides, and acceptance sign-offs (Table 13-5). A reference guide consists of an exhaustive list of a system’s functions and commands,

FIGURE 13-6 An example document from Microsoft Word Help

(Source: Microsoft Corporation)

Generic Life-Cycle Phase Generic Document

Requirements Specification System Requirements Specification Resource Requirements Specification

Project Control Structuring Management Plan Engineering Change Proposal

System Development Architectural design Architecture Design Document Prototype design Prototype Design Document Detailed design and implementation Detailed Design Document Test specification Test Specifications Test implementation Test Reports

System Delivery User’s Guide Release Description System Administrator’s Guide Reference Guide Acceptance Sign-Off

(Source: Adapted from Bell & Evans, 1989.)

TABLE 13-5 SDLC and Generic Documentation Corresponding to Each Phase

M13B_VALA1629_09_GE_C13.indd 478 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 479

usually in alphabetic order. Reference guides are very good for locating specific infor- mation; they are not as good for learning the broader picture of how to perform all of the steps required for a given task. A quick-reference guide provides essential information about operating a system in a short, concise format. When computer resources are shared, and many users perform similar tasks on the same machines (as with airline reservation or mail-order catalog clerks), quick-reference guides are often printed on index cards or as small books and mounted on or near the computer terminal. An outline for a generic user’s guide (from Bell & Evans, 1989) is shown in Table 13-6. The purpose of such a guide is to provide information on how users can use a computer system to perform specific tasks. The information in a user’s guide is typically ordered by how often tasks are performed and by their complexity.

In Table 13-6, sections with an “n” and a title in square brackets mean that there are many such sections, each for a different topic. For example, for an accounting application, sections 4 and beyond might address topics such as entering a transaction in the ledger, closing the month, and printing reports. The items in parentheses are optional, included as necessary. An index becomes more important for larger user’s guides. Figure 13-7 shows a quick start guide for Microsoft Excel. This particular refer- ence guide is intended for people who have never used Excel before. The organization of user’s guides differs from one software product to the next. User guides also differ depending on the intended audience, whether novice or expert. You may want to compare the guide in Figure 13-7 with ones for other packages to identify differences.

A release description contains information about a new system release, includ- ing a list of documentation for the new release, features and enhancements, known problems and how they have been dealt with in the new release, and information about installation. A system administrator’s guide is intended primarily for those who will install and administer a new system. It contains information about the network on which the system will run, software interfaces for peripherals such as printers, troubleshooting, and setting up user accounts. Finally, an acceptance sign-off allows users to test for proper system installation and then signify their acceptance of the new system with their signatures.

TRAINING AND SUPPORTING USERS Training and support are critical for the success of an information system. As the person whom the user holds responsible for the new system, you and other analysts on the project team must ensure that high-quality training and support are available. Although training and support can be talked about as if they are two separate things,

Support Providing ongoing educational and problem-solving assistance to infor- mation system users. For in-house developed systems, support materials and jobs will have to be prepared or designed as part of the implementation process.

Preface

1. Introduction 1.1. Configurations 1.2 Function flow

2. User interface 2.1 Display screens 2.2 Command types

3. Getting started 3.1 Login 3.2 Logout 3.3 Save 3.4 Error recovery 3.n [Basic procedure name]

n. [Task name] Appendix A—Error Messages

([Appendix]) Glossary

Terms Acronyms

Index

(Source: Adapted from Bell & Evans, 1989.)

TABLE 13-6 Outline of a Generic User’s Guide

FIGURE 13-7 A quick start guide for Excel

(Source: Microsoft Corporation)

M13B_VALA1629_09_GE_C13.indd 479 08/04/2020 17:36

480 PART V IMPLEMENTATION AND MAINTENANCE

in organizational practice the distinction between the two is not all that clear because the two sometimes overlap. After all, both deal with learning about computing.

Training Information Systems Users

Computer use requires skills, and training people to use computer applications can be expensive for organizations. Training of all types is a major activity in American corpo- rations, but information systems training is often neglected. Many organizations tend to underinvest in computing skills training. It is true that some organizations institutionalize high levels of information system training, but many others offer no systematic training at all.

The type of training needed will vary by system type and user expertise. The list of potential topics from which you will determine if training will be useful includes the following:

• Use of the system (e.g., how to enter a class registration request) • General computer concepts (e.g., computer files and how to copy them) • Information system concepts (e.g., batch processing) • Organizational concepts (e.g., FIFO inventory accounting) • System management (e.g., how to request changes to a system) • System installation (e.g., how to reconcile current and new systems during

phased installation)

As you can see from this partial list, many potential topics go beyond simply how to use the new system. It may be necessary for you to develop training for users in other areas so that users will be ready, conceptually and psychologically, to use the new system. Some training, such as concept training, should begin early in the proj- ect because this training can assist in the “unfreezing” (helping users let go of long- established work procedures) element of the organizational change process.

Each element of training can be delivered in a variety of ways. Table 13-7 lists the most common training methods used by information system departments. The most common delivery method for corporate training remains traditional instructor-led classroom training (U.S. GAO, 2003). Many times, users turn to the resident expert and to fellow users for training. Users are more likely to turn to local experts for help than to the organization’s technical support staff because the local expert understands the users’ primary work and the computer systems they use. Given their dependence on fellow users for training, it should not be surprising that end users describe their most common mode of computer training as self-training.

One conclusion from the experience with user training methods is that an effec- tive strategy for training on a new system is to first train a few key users and then orga- nize training programs and support mechanisms that involve these users to provide further training, both formal and on demand. Often, training is most effective if you customize it to particular user groups, and the lead trainers from these groups are in the best position to provide this training to their colleagues.

Corporations also rely heavily on e-learning as a key delivery mode for training. E-learning generally means the same thing as distance learning; that is, a formalized learning system designed to be carried out remotely, using computer-based electronic communication. You may have taken a distance-learning course at your school, or you may have experience in on-campus classes with some of the dominant software pack- ages used in e-learning, such as Canvas, Blackboard, or Moodle. E-learning courses can be delivered over the Internet or over company intranets. Such courses can be pur- chased from vendors or prepared by the corporation’s in-house training staff. E-learn- ing is relatively inexpensive compared to traditional classroom training, and it has the additional advantage of being available anytime from just about anywhere. Students can also learn at their own pace. E-learning systems can make available several different elements that enhance the learning experience, including simulations, online access to mentors and experts, e-books, net meetings, and video on demand. Another trend in corporate training is blended learning, the combining of e-learning with instructor-led

Resident expert Traditional instructor-led classroom

training E-learning/distance learning Blended learning (combination of

instructor-led and e-learning) Software help components External sources, such as vendors

TABLE 13-7 Types of Training Methods

M13B_VALA1629_09_GE_C13.indd 480 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 481

classroom training. A recent survey reported that 77 percent of respondents offered online corporate training programs to train their employees (Patten, 2018). The global e-learning market is expected to grow to US$325 billion by 2025 (Kelly, 2017).

Another training method listed in Table 13-7 is software help components. Figure 13-8 shows the e-learning resources that are available for Microsoft’s Power- Point presentation software. Several different video training sessions are available for users who want to learn and master PowerPoint. Users can go through the tutorials at their own pace, whenever they want, stopping and starting it as necessary.

Supporting Information Systems Users

Historically, computing support for users has been provided in one of a few forms: on paper, through online versions of paper-based support, by third-party vendors, or by other people who work for the same organization. As we stated earlier, support, whatever its form, has often been inadequate for users’ needs. Yet users consider sup- port to be extremely important.

As computing spread throughout organizations, especially with the advent of personal computers, the need for support increased as more and more employees came to rely on computing to do their jobs. As organizations moved to client/server architectures, their need for support increased even more, and organizations began to rely more and more on vendor support (Crowley, 1993). This increased need for support came in part from the lack of standards governing client/server products and the resulting need to make equipment and software from different vendors compat- ible. Vendors are able to provide the necessary support, but as they have shifted their offerings from primarily expensive mainframe packages to inexpensive off-the-shelf software, they find they can no longer bear the cost of providing the support for free. Most vendors now charge for support, and many have instituted 900 numbers or sell customers unlimited support for a given monthly or annual charge.

Automating Support In an attempt to cut the costs of providing support and to catch up with the demand for additional support services, vendors have automated many of their support offerings. Online support forums provide users access to infor- mation on new releases, bugs, and tips for more effective usage. Forums are offered over the Internet or over company intranets. Voice-response systems allow users to navigate option menus that lead to prerecorded messages about usage, problems, and

FIGURE 13-8 E-learning resources available for Pow- erPoint 2016

(Source: Microsoft Corporation)

M13B_VALA1629_09_GE_C13.indd 481 08/04/2020 17:36

482 PART V IMPLEMENTATION AND MAINTENANCE

workarounds. Organizations have established similar support mechanisms for systems developed or purchased by the organization. Internal e-mail and office automation can be used to support such capabilities within an organization.

Vendors may offer support that enables users to access a vendor’s knowledge bases, including electronic support services, a single point of contact, and priority access to vendor support personnel (Schneider, 1993). Product knowledge bases include all of the technical and support information about vendor products and pro- vide additional information for on-site personnel to use in solving problems. Vendors routinely supply complete user and technical documentation via the Internet, includ- ing periodic updates, so that a user organization can provide this library of documen- tation, bug reports, workaround notices, and notes on undocumented features online to all internal users. Electronic support services include all of the vendor support services discussed earlier, but they are tailored specifically for the corporation. The single point of contact is a system engineer who is often based on-site and serves as a liaison between the corporation and the vendor. Finally, priority access means that corporate workers can always get help via telephone or e-mail from a person at the vendor company, usually within a prespecified response time of four hours or less.

Such vendor-enhanced support is especially appropriate in organizations where a wide variety of a particular vendor’s products is in use, or where most in-house appli- cation development either uses the vendor’s products as components of the larger system or where the vendor’s products are themselves used as the basis for applica- tions. An example of the former would be the case where an organization has set up a client/server architecture based on a particular vendor’s SQL server and APIs. Which applications are developed in-house to run under the client/server architec- ture depends heavily on the server and APIs, and direct vendor support dealing with problems in these components would be very helpful to the enterprise information systems staff. An example of the second would include order entry and inventory con- trol application systems developed using Microsoft’s Access or Excel. In this case, the system developers and users, who are sometimes the same people for such package- based applications, can benefit considerably from directly questioning vendor repre- sentatives about their products.

Providing Support through a Help Desk Whether assisted by vendors or going it alone, the center of support activities for a specific information system in many orga- nizations is the help desk. A help desk is an information systems department function and is staffed by IS personnel. The help desk is the first place users should call when they need assistance with an information system. The help desk staff members either deal with the users’ questions or refer the users to the most appropriate person.

Help desk personnel need to be good at communicating with users, listening to their problems, and intelligently communicating potential solutions. These person- nel also need to understand the technology they are helping users with. It is crucial, however, that help desk personnel know when new systems and releases are being implemented and when users are being trained for new systems. Help desk personnel should be well trained on new systems. One sure recipe for disaster is to train users on new systems but not train the help desk personnel these same users will turn to for their support needs.

ORGANIZATIONAL ISSUES IN SYSTEMS IMPLEMENTATION Despite the best efforts of the systems development team to design and build a quality system and to manage the change process in the organization, the implementation effort sometimes fails. Sometimes employees will not use the new system that has been developed for them or, if they do use it, their level of satisfaction with it is very low. Why do systems implementation efforts fail? This question has been the subject of information systems research for over 60 years. In the first part of this section, we will try to provide some answers, looking at the factors that research has identified as

Help desk A single point of contact for all user inquiries and problems about a particu- lar information system or for all users in a particular department.

M13B_VALA1629_09_GE_C13.indd 482 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 483

important to implementation success. In the second part of this section, you will read about another important organizational issue for information systems, security. You will read about the various threats to the security of organizational systems and some of the remedies that can be applied to help deal with the problem.

Why Implementation Sometimes Fails

The conventional wisdom that has emerged over the years is that there are at least two conditions necessary for a successful implementation effort: management support of the system under development and the involvement of users in the development pro- cess (Ginzberg, 1981b). Conventional wisdom holds that if both of these conditions are met, you should have a successful implementation. But despite the support and active participation of management and users, information systems implementation sometimes fails (see the box “System Implementation Failures” for examples).

Management support and user involvement are important to implementation success, but they may be overrated compared to other factors that are also important. Research has shown that the link between user involvement and implementation suc- cess is sometimes weak (Ives & Olson, 1984). User involvement can help reduce the risk of failure when the system is complex, but user participation in the development process only makes failure more likely when there are financial and time constraints in the development process (Tait & Vessey, 1988). Information systems implementation failures are too common, and the implementation process is too complicated, for the conventional wisdom to be completely correct.

Over the years, other studies have found evidence of additional factors that are important to a successful implementation process. Three such factors are: com- mitment to the project, commitment to change, and the extent of project definition and planning (Ginzberg, 1981b). Commitment to the project involves managing the systems development project so that the problem being solved is well understood and the system being developed to deal with the problem actually solves it. Commitment to change involves being willing to change behaviors, procedures, and other aspects of the organization. The extent of project definition and planning is a measure of how well the project was planned. The more extensive the planning effort is, the less likely implementation failure is. Still another important factor related to implementa- tion success is user expectations (Ginzberg, 1981a). The more realistic a user’s early expectations about a new system and its capabilities are, the more likely it is that the user will be satisfied with the new system and actually use it.

Although there are many ways to determine if an implementation has been successful, the two most common and trusted are the extent to which the system is

On February 24, 2016, a new Canadian federal payroll system went live. The system, called Phoenix, was custom designed by IBM for the Canadian government. There were problems almost immediately. Some employees did not get paid enough, others got paid too much, and others did not get paid at all. The development and implementation costs of the system actually came in $2 million under budget, at C$307 million. Two years after the system went live, in February 2018, the total costs for implementation and for fixing the problems approached $900 million. Initially, it was projected that 550 employees would be needed to operate Phoenix, but that number grew to over 1500. Despite the costs, the Canadian government announced

it would “eventually move away from Phoenix and begin development of the next generation of the federal government’s pay system.” The government allocated $16 million in new spending to begin planning for the system that would replace Phoenix.

Sources: Burgess, S. (2018). Phoenix fix approaching $1B as feds look at scrapping system. CBC News. Retrieved May 1, 2018 from http://www.cbc.ca/news/canada/ottawa/ phoenix-eventually-replaced-federal-budget-2018-1.4554399. Ireton, J. (2017). Phoenix payroll system under budget? Sounds like creative accounting to expert. CBC News. Retrieved May 1, 2018 from http://www.cbc.ca/news/canada/ottawa/ phoenix-government-psac-payroll-1.4300801.

An Example of a System Implementation Failure

M13B_VALA1629_09_GE_C13.indd 483 08/04/2020 17:36

http://www.cbc.ca/news/canada/ottawa/phoenix-eventually-replaced-federal-budget-2018-1.4554399

http://www.cbc.ca/news/canada/ottawa/phoenix-government-psac-payroll-1.4300801

http://www.cbc.ca/news/canada/ottawa/phoenix-eventually-replaced-federal-budget-2018-1.4554399

http://www.cbc.ca/news/canada/ottawa/phoenix-government-psac-payroll-1.4300801

484 PART V IMPLEMENTATION AND MAINTENANCE

used, and the users’ satisfaction with the system (Lucas, 1997). Lucas, who has studied information systems implementation in depth, identified six factors that influence the extent to which a system is used (1997):

1. User’s personal stake. How important the domain of the system is for the user; in other words, how relevant the system is to the work the user performs. The user’s personal stake in the system is itself influenced by the level of support manage- ment provides for implementation and by the urgency to the user of the problem addressed by the system. The higher the level of management support and the more urgent the problem, the higher the user’s personal stake in the system.

2. System characteristics. Includes aspects of the system’s design such as ease of use, reliability, and relevance to the task the system supports.

3. User demographics. Characteristics of the user, such as age and degree of computer experience.

4. Organizational support. These are the same issues of support you read about ear- lier in this chapter. The better the system support, the more likely an individual will be to use the system.

5. Performance. What individuals can do with a system to support their work will have an impact on extent of system use. The more users can do with a system and the more creative ways they can develop to benefit from the system, the more they will use it. The relationship between performance and use goes both ways. The higher the levels of performance, the more use. The more use, the greater the performance.

6. Satisfaction. Use and satisfaction also represent a two-way relationship. The more satisfied the users are with the system, the more they will use it. The more they use it, the more satisfied they will be.

The factors identified by Lucas and the relationships they have to each other are shown in the model in Figure 13-9. In the model, it is easier to see the relationships among the various factors, such as how management support and problem urgency affect the user’s personal stake in the system. Notice also that the arrows that show the relationships between use and performance and satisfaction have two heads, illustrat- ing the two-way relationships between these factors.

It should be clear that, as an analyst and as someone responsible for the success- ful implementation of an information system, you have more control over some fac- tors than others. For example, you will have considerable influence over the system’s characteristics, and you may have some influence over the levels of support that will be provided for users of the system. You have no direct control over a user’s demo- graphics, personal stake in the system, management support, or the urgency of the problem to the user. This doesn’t mean you can ignore factors that you can’t change. On the contrary, you need to understand these factors very well because you will have

FIGURE 13-9 Implementation success

(Source: From Lucas, H. C. (1997). Information technology for management. New York: McGraw-Hill. Reprinted by permission.)

Management Support

System Characteristics

Performance

Problem Urgency

User’s Personal

Stake Use Satisfaction

User Demographics

Organizational Support

M13B_VALA1629_09_GE_C13.indd 484 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 485

to balance them with the factors you can change in your system design and in your implementation strategy. You may not be able to change a user’s demographics or personal stake in a system, but you can help design the system and your implementa- tion strategy with these factors in mind.

The factors mentioned so far are straightforward. For example, a lack of com- puter experience can make a user hesitant, inefficient, and ineffective with a system, leading to a system that is not providing its full potential benefit. If top management does not seem to care about the system, why should subordinates care? However, addi- tional factors can be categorized as political and might be more hidden, difficult to affect, and even unrelated to the system that is being implemented, yet instrumental to the system’s success.

The basis for political factors is that individuals who work in an organization have their own self-interested goals, which they pursue in addition to the goals of their departments and of their organizations. For example, people might act to increase their own power relative to that of their co-workers; at other times, people will act to prevent co-workers with more power (such as bosses) from using that power or from gaining more. Because information is power, information systems often are seen as instruments of one’s ability to influence and exert power. It is helpful to understand the history and politics around an information system, and to deal with negative politi- cal factors as well as the more objective and operational ones. Sometimes political interpretations provide better explanations for the implementation process and why events took the course they did.

Once an information system has been successfully implemented, the importance of documentation grows. A successfully implemented system becomes part of the daily work lives of an organization’s employees. Many of those employees will use the system, but others will maintain it and keep it running.

Security Issues

The security of information systems has become an increasingly important issue for organizations and their management. Hard numbers about losses due to security breaches are difficult to obtain because most companies that have suffered breaches are too embarrassed to admit it, and they are certainly too embarrassed to communi- cate the actual dollar value of any losses. One estimate for how much security breaches cost companies comes from a survey on security conducted by IBM Security and the Ponemon Institute. For 2017, the reported estimated annual average financial loss due to a data breach incident was US$3.62 million. However, we can be sure the actual amount of loss across the entire global economy is much, much more. Most firms do not like to admit financial losses due to security breaches, and those that do are hesitant to report the actual true amounts.

If organizations are victims of security breaches, what are the sources of these threats? Table 13-8 provides some of the answers. As you might expect, a majority of firms report that they have been victims of external threats, including malware (malicious software) and hacking. Other external security threats include phishing attacks, exploitation of applications, denial of service, and theft of computing or stor- age devices. Denial of service is a popular tactic used to prevent access to a Website, orchestrated through sending the Website server more messages than it can handle in a short period of time. Note that although external threats are common, internal threats are common as well. Internal actors were responsible for over one-quarter of recorded data breaches. Employee abuse includes such seemingly innocent activi- ties as sending personal e-mail on company systems or surfing the Internet for per- sonal use during work hours. Although these activities may not damage company systems, they do use company resources that may be needed for work. Downloading large music or video files during work hours on company equipment could actually impede work because downloading large files can consume bandwidth and slow work

M13B_VALA1629_09_GE_C13.indd 485 08/04/2020 17:36

486 PART V IMPLEMENTATION AND MAINTENANCE

processes. Unauthorized access to information or privilege escalation by insiders is more devious, as these activities are committed with the intent to harm the firm.

Companies can act, and most do, to deal with information security issues. On average, most companies spend more on systems security than the average loss due to cybersecurity for their company type. When companies and individuals start to think about systems security, they first think about technological solutions to the problem (Schneider, 2000). Common solutions include firewalls, e-mail security and spam fil- tering software, antivirus software, virtual private networks, and data encryption.

A firewall is a set of related programs that protects the resources of a network from users from other networks. Basically, a firewall works closely with a router pro- gram to examine each network packet to determine whether to forward it toward its destination. A firewall is often installed in a specially designated computer separate from the rest of the network so that no incoming request can get directly at private network resources.

Yet the weakest link in any computer defense is the people who use the computer system. For example, many system users fail to use good passwords: they may tell other people (including strangers) their passwords, or write their passwords on sticky notes they post on their computer monitors. The best defensive technology in the world can- not overcome human laziness and negligence. Experts argue that the human aspect of computer security can be dealt with through the implementation of procedures and policies regarding user behaviors (Denning, 1999; Mitnick & Simon, 2002). Such

Percent of Organization’s Budget Allocated to Information Security, 2017

Less than 1 % 7 % 1 % to 5 % 22 % 6 % to 10 % 26 %

Biggest IT Security Challenges, 2017

Assessing Risk 35 % Enforcing Security Policies 34 % Managing the Complexity of Security 33 % Preventing Data Breaches from Outside Attackers 29 %

Average Financial Losses due to Data Breaches, 2017

United States $7.35 million Middle East $4.94 million Canada $4.31 million

Who’s Behind Recorded Data Breaches, 2017

Outsiders 73 % Internal Actors 28 % Organized Criminal Groups 50 % Nation-State or State-Affiliated Actors 12 %

Top Five Tactics Utilized in Data Breaches, 2017

Hacking 48 % Malware 30 % Errors as Causal Events 17 % Social Attacks 17 % Privilege Misuse 11 %

Victims of Data Breaches, 2017

Healthcare Organizations 24 % Accommodation and Food Services 15 % Public Sector Entities 14 %

TABLE 13-8 Selected Statistics on IT Security (Data compiled from Vijayan, 2017 & Verizon, 2018.)

M13B_VALA1629_09_GE_C13.indd 486 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 487

policies involve system users not giving out passwords, changing passwords regularly, keeping operating system and virus detection software updated, and so on. Sound systems security practice demands the effective use of appropriate information tech- nologies as well as the diligent involvement of employees and decision makers in the defense of organization information technology assets.

ELECTRONIC COMMERCE APPLICATION: SYSTEM IMPLEMENTATION AND OPERATION FOR PINE VALLEY FURNITURE’S WEBSTORE Like many other analysis and design activities, system implementation and operation of an Internet-based electronic commerce application is no different than the pro- cesses followed for other types of applications. Previously, you read how Jim Woo and the Pine Valley Furniture (PVF) development team transformed the conceptual data model for the WebStore into a set of normalized relations. Here we will examine how the WebStore system was tested before it was installed and brought online.

The programming of all WebStore software modules has been completed. The programmers have extensively tested each unique module, and it is now time to per- form a systemwide test of the WebStore. In this section, we will examine how test cases were developed, how bugs were recorded and fixed, and how alpha and beta testing were conducted.

Developing Test Cases for the WebStore

To begin the systemwide testing process, Jim and the PVF development team devel- oped test cases to examine every aspect of the system. Jim knew that system testing, like all other aspects of the SDLC, needed to be a very structured and planned process. Before opening the WebStore to the general public, every module and component of the system needed to be tested within a controlled environment. Based on his experi- ence in implementing other systems, Jim felt that they would need to develop approxi- mately 150 to 200 separate test cases to fully examine the WebStore. To help focus the development of test cases and to assign primary responsibility to members of his team to specific areas of the system, Jim developed the following list of testing categories:

• Simple functionality: Add to cart, list section, calculate tax, change personal data

• Multiple functionality: Add item to cart and change quantity, create user account, change address

• Function chains: Add item to cart, check out, create user account, purchase • Elective functions: Returned items, lost shipments, item out of stock • Emergency/crisis: Missing orders, hardware failure, security attacks

The development group broke into five separate teams, each working to develop an extensive set of cases for each of the testing categories. Each team had one day to develop their test cases. Once developed, each team would lead a walk-through so that everyone would know the totality of the testing process and to facilitate exten- sive feedback to each team so that the testing process would be as comprehensive as possible. To make this point, Jim stated, “What happens when a customer repeatedly enters the same product into the shopping cart? Can we handle that? What happens when the customer repeatedly enters and then removes a single product? Can we handle that? Although some of these things are unlikely to ever occur, we need to be confident that the system is robust to any type of customer interaction. We must develop every test case necessary to give us confidence that the system will operate as intended, 24-7-365!”

A big part of successful system testing is to make sure that no information is lost and that all tests are described in a consistent way. To achieve this, Jim provided all

PINE VALLEY FURNITURE

M13B_VALA1629_09_GE_C13.indd 487 08/04/2020 17:36

488 PART V IMPLEMENTATION AND MAINTENANCE

teams with standard forms for documenting each case and for recording the results of each test. This form had the following sections:

• Test Case ID • Category/Objective of Test • Description • System Version • Completion Date • Participant(s) • Machine Characteristics (processor, operating system, memory, browser, etc.) • Test Result • Comments

The teams also developed standard codes for each general type of test, and these were used to create the Test Case ID. For example, all tests related to “Simple Functionality” were given an ID with SF as a prefix and a number as the suffix (e.g., SF001). The teams also developed standards for categorizing tests, listing objectives, and writing other test form contents. Establishing these standards ensured that the testing process would be consistently documented.

Bug Tracking and System Evolution An outcome of the testing process is the identification of system bugs. Consequently, in addition to setting a standard method for writing and documenting test cases, Jim and the teams established several other rules to ensure a smooth testing process. Experienced developers have long known that an accurate bug-tracking process is essential for rapid troubleshooting and repair during the testing process. You can think of bug tracking as creating a “paper trail” that makes it much easier for programmers to find and repair the bug. To make sure that all bugs were documented in a similar way, the team developed a bug-tracking form that had the following categories:

• Bug Number (simple incremental number) • Test Case ID That Generated the Bug • Is the Bug Replicable? • Effects • Description • Resolution • Resolution Date • Comments

The PVF development team agreed that bug fixes would be made in batches because all test cases would have to be redone every time the software was changed. The redoing of all the test cases each time the software is changed is done to ensure that in the process of fixing the bug, no other bugs are introduced into the system. As the system moves along in the testing process—as batches of bugs are fixed—the version number of the software is incremented. During the development and testing phases, the version is typically below the “1.0” first release version.

Alpha and Beta Testing the WebStore

After completing all system test cases and resolving all known bugs, Jim moved the WebStore into the alpha-testing phase, in which the entire PVF development team as well as personnel around the company would put the WebStore through its paces. To motivate employees throughout the company to actively participate in testing the WebStore, several creative promotions and giveaways were held. All employees were given a T-shirt that said, “I shop at the WebStore, do you?” Additionally, all employees were given $100 to shop at the WebStore and were offered a free lunch for their entire department if they found a system bug while shopping on the system. Also during alpha testing, the development team conducted extensive recovery, security, stress, and performance testing. Table 13-9 provides a sample of the types of tests performed.

M13B_VALA1629_09_GE_C13.indd 488 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 489

After completing alpha testing, PVF recruited several of their established cus- tomers to help in beta testing the WebStore. As real-world customers used the system, Jim was able to monitor the system and fine-tune the servers for optimal system per- formance. As the system moved through the testing process, fewer and fewer bugs were found. After several days of “clean” usage, Jim felt confident that it was time to open the WebStore for business.

WebStore Installation

Throughout the testing process, Jim kept PVF management aware of each success and failure. Fortunately, because Jim and the development team followed a structured and disciplined development process, there were far more successes than failures. In fact, he was confident that the WebStore was ready to go online and would recommend to PVF’s top management that it was time to “flip the switch” and let the world enter the WebStore.

PROJECT CLOSEDOWN In Chapter 3, you learned about the various phases of project management, from proj- ect initiation to closing down the project. If you are the project manager and you have successfully guided your project through all of the phases of the SDLC presented so far in this book, you are now ready to close down your project. Although the maintenance phase is just about to begin, the development project itself is over. As you will see in the next chapter, maintenance can be thought of as a series of smaller development projects, each with its own series of project management phases.

As you recall from Chapter 3, your first task in closing down the project involves many different activities, from dealing with project personnel to planning a celebra- tion of the project’s ending. You will likely have to evaluate your team members, reassign most to other projects, and perhaps terminate others. As project manager, you will also have to notify all of the affected parties that the development project is ending and that you are now switching to maintenance mode.

Your second task is to conduct post-project reviews with both your management and your customers. In some organizations, these post-project reviews will follow for- mal procedures and may involve internal or EDP (electronic data processing) auditors. The point of a project review is to critique the project, its methods, its deliverables, and its management. You can learn many lessons to improve future projects from a thorough post-project review.

The third major task in project closedown is closing out the customer contract. Any contract that has been in effect between you and your customers during the project (or as the basis for the project) must be completed, typically through the consent of all contractually involved parties. This may involve a formal “signing off” by the clients stating that your work is complete and acceptable. The mainte- nance phase will typically be covered under new contractual agreements. If your

Test Type Tests Performed

Recovery • Unplug main server to test power backup system • Switch off main server to test the automatic switching to backup server

Security • Try to purchase without being a customer • Try to examine server directory files both within the PVF domain and when

connecting from an outside Internet service provider Stress • Have multiple users simultaneously establish accounts, process purchases,

add to shopping cart, remove from shopping cart, and so on Performance • Examine response time using different connection speeds, processors,

memory, browsers, and other system configurations • Examine response time when backing up server data

TABLE 13-9 Sample of Tests Conducted on the WebStore during Alpha Testing

M13B_VALA1629_09_GE_C13.indd 489 08/04/2020 17:36

490 PART V IMPLEMENTATION AND MAINTENANCE

customer is outside your organization, you will also likely negotiate a separate sup- port agreement.

As an analyst member of the development team, your job on this particular project ends during project closedown. You will likely be reassigned to another project dealing with an organizational problem. Maintenance on your new system will begin and continue without you. To complete our consideration of the SDLC, however, we will cover the maintenance phase and its component tasks in Chapter 14.

SUMMARY This chapter presented an overview of the various aspects of the systems implementation process. You studied seven different types of testing: (1) code inspections, in which the code is examined for well-known errors; (2) walk- throughs, when a group manually examines what the code is supposed to do; (3) desk checking, when an individual mentally executes the computer instructions; (4) syntax checking, typically done by a compiler; (5) unit or mod- ule testing; (6) integration testing, in which modules are combined and tested together until the entire program has been tested as a whole; and (7) system testing, in which programs are combined to be tested as a system and where the system’s meeting of its objectives is examined. You also learned about acceptance testing, in which users test the system for its ability to meet their requirements, using live data in a live environment.

You read about four types of installation: (1) direct, when the old system is shut off just as the new one is turned on; (2) parallel, when both old and new systems are run together until it is clear the new system is ready to be used exclusively; (3) single-location, when one site is selected to test the new system; and (4) phased, when the system is installed bit by bit.

You learned about two types of documentation: (1) system documentation, which describes in detail the design of a system and its specifications; and (2) user documen- tation, which describes a system and how to use it for the system’s users.

Computer training has typically been provided in classes and tutorials. Although there is some evidence that lectures have their place in teaching people about computing and information systems, the current empha- sis in training is on automated delivery methods, such as online reference facilities, and multimedia training. The

latter embed training in the applications themselves in an attempt to make training a seamless part of using an application for daily operations. The emphasis in support is also on providing online delivery, including online sup- port forums. As organizations move toward client/server architectures, they rely more on vendors for support. Ven- dors provide many online support services, and they work with customers to bring many aspects of online support in-house. A help desk provides aid to users in a particular department or for a particular system.

You saw how information systems researchers have been trying to explain what constitutes a successful imple- mentation. If there is a single main point in this chapter, it is that implementation is a complicated process, from managing programmer teams, to the politics that influ- ence what happens to a system after it has been successfully implemented, to planning and implementing useful train- ing and support mechanisms. Analysts have many factors to identify and manage for a successful system implementa- tion. Successful implementation rarely happens by accident or occurs in a totally predictable manner. The first step in a successful implementation effort may be realizing just that fact. Once systems are implemented, organizations have to deal with threats from both inside and outside the organiza- tion to the systems’ security. Although technology such as virus-detection software and firewalls can be employed to help secure systems, good security also requires policies and procedures that guide employees in proper system usage.

In many ways, the implementation of an Internet- based system is no different. Just as much careful attention, if not more, has to be paid to the details of an Internet implementation as to a traditional system. Successful implementation for an Internet-based system is not an accident either.

KEY TERMS

13.1 Acceptance testing 13.2 Alpha testing 13.3 Beta testing 13.4 Desk checking 13.5 Direct installation 13.6 Help desk 13.7 Inspections

13.8 Installation 13.9 Integration testing 13.10 Parallel installation 13.11 Phased installation 13.12 Refactoring 13.13 Single-location installation 13.14 Stub testing

13.15 Support 13.16 System documentation 13.17 System testing 13.18 Testing harness 13.19 Unit testing 13.20 User documentation

M13B_VALA1629_09_GE_C13.indd 490 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 491

REVIEW QUESTIONS 13.21 What are the six major activities that make up the imple-

mentation phase of a systems development project?

13.22 As a systems analyst, what would your principal respon- sibility be during the implementation phase?

13.23 What are structured walk-throughs for code? What is their purpose? How are they conducted? How are they different from code inspections?

13.24 What are the four approaches to installation? Which is the most expensive? Which is the most risky? How does an organization decide which approach to use?

13.25 Who are the intended audience for the documentation created during the implementation phase?

13.26 List and define the factors that are important to success- ful implementation efforts.

13.27 Who would find system documentation useful?

13.28 What is the difference between system documentation and user documentation?

13.29 What are the common methods of computer training?

13.30 Users often turn to their colleagues for help with fea- tures of a new system rather than to the IT support department. What is the reason for this?

13.31 According to Ginzberg, there are at least two conditions necessary for a successful implementation effort: man- agement support and user involvement. What would you consider as another major prerequisite for a system developed after the SDLC model?

13.32 This chapter states that the distinction between training and support becomes more and more blurred. What is the reason for this?

13.33 What are the common strategies for software vendors when it comes to handling support for organizations, and why has there been a change over the decades?

13.34 Describe the delivery methods many vendors employ for providing support.

13.35 Describe the various roles typically found in a help desk function.

13.36 What are the common security threats to systems? How can they be addressed?

Match each of the key terms above with the definition that best fits it.

____ A testing technique in which participants examine program code for predictable language-specific errors.

____ A testing technique in which the program code is sequen- tially executed manually by the reviewer.

____ Written or other visual information about an application system, how it works, and how to use it.

____ Changing over from the old information system to a new one by turning off the old system when the new one is turned on.

____ The process of testing each module alone in an attempt to discover any errors in its code; also called module testing.

____ The organizational process of changing over from the cur- rent information system to a new one.

____ The process whereby actual users test a completed informa- tion system, the end result of which is the users’ acceptance of it.

____ Detailed information about a system’s design specifications, its internal workings, and its functionality.

____ Running the old information system and the new one at the same time until management decides the old system can be turned off.

____ The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typi- cally integrated in a top-down, incremental fashion.

____ A technique used in testing modules, especially modules that are written and tested in a top-down fashion, where

a few lines of code are used to substitute for subordinate modules.

____ Changing from the old information system to the new one incrementally, starting with one or a few functional compo- nents and then gradually extending the installation to cover the whole new system.

____ Bringing together all of the programs that a system com- prises for testing purposes. Programs are typically inte- grated in a top-down, incremental fashion.

____ Providing ongoing educational and problem-solving assis- tance to information system users. Support material and jobs must be designed along with the associated informa- tion system.

____ User testing of a completed information system using real data in the real user environment.

____ Trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization.

____ User testing of a completed information system using simu- lated data.

____ A single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department.

____ Making a program simple after adding a new feature.

____ An automated testing environment used to review code for errors, standards violations, and other design flaws.

M13B_VALA1629_09_GE_C13.indd 491 08/04/2020 17:36

492 PART V IMPLEMENTATION AND MAINTENANCE

FIELD EXERCISES 13.51 Interview someone you know or have access to who

works for a medium to large organization. Ask for details on a specific instance of organizational change: What changed? How did it happen? Was it well planned or ad hoc? How were people in the organization affected? How easy was it for employees to move from the old situ- ation to the new one?

13.52 Re-examine the data you collected in the interview in Field Exercise 1. This time, analyze the data from a political perspective. How well does the political model explain how the organization dealt with change? Explain why the political model does or does not fit.

13.53 Find a person working as an author of educational mate- rial, such as user manuals, videos, or software for user training. What is this person’s opinion on the different methods? Which is best suited to which circumstance? Which of these kinds of materials is usually the most expensive to produce?

13.54 Prepare a research report on successful and unsuc- cessful information system implementations. After you have found information on two or three examples of both successful and unsuccessful system implemen- tations, try to find similarities and differences among the examples of each type of implementation. Do you detect any patterns? Can you add any factors important to success that were not mentioned in this chapter?

13.55 Talk with people you know who use computers in their work. Ask them to get copies of the user documentation they rely on for the systems they use at work. Analyze the documentation. Would you consider it good or bad? Support your answer. Whether good or bad, how might you improve it?

13.56 Volunteer to work for a shift at a help desk at your school’s computer center. Keep a journal of your expe- riences. What kind of users did you have to deal with?

PROBLEMS AND EXERCISES 13.37 Discuss the merits and possible problems with e-learning

(in the form of self-studies) as opposed to traditional classroom learning.

13.38 Which installation strategy would you recommend for PVF’s Purchasing Fulfillment System? Which would you recommend for Hoosier Burger’s inventory control sys- tem? If you recommended different approaches, please explain why. How is PVF’s case different from Hoosier Burger’s?

13.39 Develop a table that compares the four installation strat- egies, showing the pros and cons of each. Try to make a direct comparison when a pro of one is a con of another.

13.40 Nicholas works as a project manager in Lyon, France. The proposed client complains a bit about the budget, which seems unnecessarily large. For one thing, the client questions the amount of money spent on user training. Imagine that you are Nicholas. What would your response be?

13.41 You have been a user of many information systems including, possibly, a class registration system at your school, a bank account system, a word-processing system, and an airline reservation system. Pick a system you have used and assume you were involved in the beta testing of that system. What criteria would you have used to judge whether this system was ready for general distribution?

13.42 Rico has recently been made responsible for user train- ing and support for a systems development project in Bologna, Italy. The project leader has given him a budget of €500,000 to support the users of the system with documentation, training, and support for a period between one and two years. How would you advise him to allocate this money among the various activities involved in user training and support, and why?

13.43 The six major activities of the implementation phase involve a large number of roles, such as coders, analysts,

and manual authors. In many organizations, these roles must be taken on by just a few people, meaning that a programmer might also be responsible for writing user documentation, for example.

13.44 It is recommended that, where possible, test cases be developed by analysts, not by programmers. Why is this?

13.45 It is further recommended that regardless of whether test cases and other kinds of formal test are used, test- ing should be performed by individuals other than the programmer responsible for the code in question. What might be the reason for this?

13.46 Suppose you were responsible for establishing a training program for users of Hoosier Burger’s inventory control system (described in previous chapters). Which forms of training would you use? Why?

13.47 Suppose you were responsible for establishing a help desk for users of Hoosier Burger’s inventory control sys- tem (described in previous chapters). Which support system elements would you create to help users be effec- tive? Why?

13.48 Your university or school probably has some form of microcomputer center or help desk for students. What functions does this center perform? How do these func- tions compare to those outlined in this chapter?

13.49 Suppose you were responsible for organizing the user documentation for Hoosier Burger’s inventory control system (described in previous chapters). Write an out- line that shows the documentation you would suggest be created, and generate the table of contents or outline for each element of this documentation.

13.50 The best measure of success for a system is probably whether it will be used. List some major factors that you think may decide whether a system will in fact be used (by happy users) or not.

M13B_VALA1629_09_GE_C13.indd 492 08/04/2020 17:36

CHAPTER 13 SyStem ImplementatIon 493

REFERENCES Beck, K. & Andres, C. (2004). eXtreme Programming eXplained.

Upper Saddle River, NJ: Addison-Wesley. Bell, P., & C. Evans. (1989). Mastering documentation. New York:

John Wiley & Sons. Denning, D. E. (1999). Information warfare and security. Boston:

Addison-Wesley. Fagan, M. E. (1986). Advances in software inspections. IEEE Trans-

actions on Software Engineering, 12(7), 744–51. Ginzberg, M. J. (1981a). Early diagnosis of MIS implementation

failure: Promising results and unanswered questions. Manage- ment Science, 27(4), 459–78.

Ginzberg, M. J. (1981b). Key recurrent issues in the MIS imple- mentation process. MIS Quarterly, 5(2), 47–59.

Ives, B., & M. H. Olson. (1984). User involvement and MIS success: A review of research. Management Science, 30(5), 586–603.

Kelly, B. (2017). Corporate training market growth is great news for online learning content Providers. ThoughtIndustries. Retrieved May 1, 2018 from http://blog.thoughtindustries. com/new-blog/licensing-content-to-corporate-customers.

Lucas, H. C. (1997). Information technology for management. New York: McGraw-Hill.

Mitnick, K. D., & Simon, W. L. (2002). The art of deception. New York: John Wiley & Sons.

Mosley, D. J. (1993). The handbook of MIS application software testing. Upper Saddle River, NJ: Prentice Hall/Yourdon Press.

Patten, B. (2018). How e-learning can increase employee training in your company.” TrainingIndustry. Retrieved May 1, 2018 https://trainingindustry.com/articles/e-learning/how-e- learning-can-increase-employee-training-in-your-company/.

Ponemon Institute Research Report. (2017). 2017 cost of data breach study. Retrieved April 30, 2018 from http://www.ibm. com/security/data-breach.

Schneider, J. (1993, November 15). Shouldering the burden of support. PC Week, 10, 123, 129.

Tait, P., & Vessey, I. (1988). The effect of user involvement on sys- tem success: A contingency approach.” MIS Quarterly, 12(1), 91–108.

United States General Accounting Office (U.S. GAO). (2003). Information technology training: Practices of leading private- sector companies.” Retrieved April 5, 2015 from http://www. gao.gov/products/GAO-03-390.

Verizon. (2018). 2018 data breach investigations report. Retrieved April 10, 2018 from http://www.verizonenterprise.com/ verizon-insights-lab/dbir/.

Vijayan, J. (2017). How enterprises are attacking the IT security problem. DarkReading Reports. Retrieved April 30, 2018 http://www.darkreading.com/.

Yourdon, E. (1989). Managing the structured techniques (4th ed). Upper Saddle River, NJ: Prentice Hall.

What kinds of questions did you get? Do you think help desk work is easy or hard? What skills are needed by someone in this position?

13.57 Let’s say your professor has asked you to help him or her train a new secretary on how to prepare class notes for

electronic distribution to class members. Your professor uses word-processing software and an e-mail package to prepare and distribute the notes. Assume the secretary knows nothing about either package. Prepare a user task guide that shows the secretary how to complete this task.

M13B_VALA1629_09_GE_C13.indd 493 08/04/2020 17:36

http://blog.thoughtindustries.com/new-blog/licensing-content-to-corporate-customers

https://trainingindustry.com/articles/e-learning/how-e-learning-can-increase-employee-training-in-your-company/

http://www.ibm.com/security/data-breach

http://www.gao.gov/products/GAO-03-390

http://www.verizonenterprise.com/verizon-insights-lab/dbir

http://www.darkreading.com/

http://blog.thoughtindustries.com/new-blog/licensing-content-to-corporate-customers

http://www.ibm.com/security/data-breach

http://www.gao.gov/products/GAO-03-390

http://www.verizonenterprise.com/verizon-insights-lab/dbir

494 PART V IMPLEMENTATION AND MAINTENANCE

As if that wasn’t enough, Juanita Lopez was now telling Jim that she would not be ready to let the team pilot the sys- tem in her Irvine store. Juanita was saying her store would not be ready by the end of July. Maybe that wouldn’t matter, since they were going to miss the go-live date for the pilot. But Juanita was hinting she would not be ready for months after that. It seemed as if she didn’t want her store to be used for the pilot at all. Jim didn’t understand it. But maybe he should try to find another store to use as the pilot site.

Jim was almost at his exit. Soon he would be at the office, and he would have to call Ella Whinston and tell her the status of the project. He would have to tell her that they would miss the go-live date, but in a way it didn’t matter since he didn’t have a pilot location to go live at. In addi- tion to going over schedule, he was going to have to go over budget, too. He didn’t see any way they would be ready for the pilot anywhere close to when they had scheduled, unless he hired the consultants Sanjay wanted. And he would have to stop the latest change request filed by mar- keting. Even more important, he would have to keep the rumored change request, about using coupons for online purchases, from being submitted in the first place.

Maybe, just maybe, if he could hire the consultants, fight off the change requests, and get Juanita to cooperate, they might be ready to go live with a pilot in Irvine on October 15. That gave him four months to complete the project. He and the team were going to have to work hard to make that happen.

Jim realized he had missed his exit. Great, he thought, I hope it gets better from here.

Case Questions

13.58 Why don’t information systems projects work out as planned? What causes the differences between the plan and reality?

13.59 Why is it important to document change requests? What happens if a development team doesn’t?

13.60 When a project is late, do you think that adding more people to do the work helps or not? Justify your answer.

13.61 What is the role of a pilot project in information systems analysis? Why do you think Petrie’s team decided to do a pilot project before rolling out the customer loyalty system for everyone?

13.62 Information systems development projects are said to fail if they are late, go over budget, or do not contain all of the functionality they were designed to have. Is the customer loyalty program a failure? Justify your answer. If not, how can failure be prevented? Is it important to avert failure? Why or why not?

Chapter 13: System Implementation

Jim Watanabe was in his new car, driving down I-5, on his way to work. He dreaded the phone call he knew he was going to have to make.

The original go-live date for a pilot implementation of Petrie Electronics’ new customer relationship management (CRM) system was July 31. That was only six weeks away, and Jim knew there was no way they were going to be ready. The XRA CRM they were licensing turned out to be a lot more complex than they had thought. They were behind schedule in implementing it. Sanjay Agarwal, who was a member of Jim’s team and was in charge of systems integra- tion for Petrie, wanted Jim to hire some consultants with XRA experience to help with implementation. So far, Jim had been able to stay under budget, but missing his dead- lines and hiring some consultants would push him over his budget limit.

It didn’t help that John Smith, head of marketing, kept submitting requests for changes to the original specifica- tions for the customer loyalty program. As specified in the project charter, the new system was supposed to track customer purchases, assign points for cumulative pur- chases, and allow points to be redeemed for “rewards” at local stores. The team had determined that those rewards would take the form of dollars-off coupons. Customers who enrolled in the program would be given accounts which they could access from Petrie’s website. When they signed on, they could check their account activity to see how many points they had accumulated. If they had earned enough points, they were rewarded with a coupon. If they wanted to use the coupon, they would have to print it out on their home printers and bring it in to a store to use on a purchase. The team had decided long ago that keeping everything electronic saved Petrie the considerable costs of printing and mailing coupons to customers.

But now marketing had put in a change request that would give customers a choice of having coupons mailed to them automatically or printing them from the Website at home. This option, although nice for customers, added complexity to the XRA system implementation, and it added to the costs of operation. Jim had also learned yes- terday from the marketing representative on his team, Sally Fukuyama, that now Smith wanted another change. Now he wanted customers to be able to use the coupons for online purchases from Petrie’s Website. This change added a whole new layer of complexity, affecting Petrie’s exist- ing systems for ordering online, in addition to altering yet again the implementation of the XRA CRM.

PETRIE ELECTRONICS

M13B_VALA1629_09_GE_C13.indd 494 08/04/2020 17:36

495

In this chapter, we discuss systems maintenance, the largest systems development expenditure for many orga- nizations. In fact, more programmers today work on maintenance activities than work on new development. Your first job after graduation may very well be as a main- tenance programmer/analyst. This disproportionate distribution of maintenance programmers is interesting because software does not wear out in a physical manner as do buildings and machines.

There is no single reason why software is main- tained; however, most reasons relate to a desire to evolve system functionality in order to overcome internal processing errors or to better support changing busi- ness needs. Thus, maintenance is a fact of life for most systems. This means that maintenance can begin soon after the system is installed. As with the initial design of a system, maintenance activities are not limited only to software changes, but include changes to hardware and business procedures. A question many people have about maintenance relates to how long organizations should maintain a system. Five years? Ten years? Longer? There is no simple answer to this question, but it is most often an issue of economics. In other words, at what point does it make financial sense to discontinue evolving an older system and build or purchase a new one? The focus of a great deal of upper IS management attention is devoted to assessing the trade-offs between maintenance and new development. In this chapter, we will provide you with a better understanding of the maintenance process and

describe the types of issues that must be considered when maintaining systems.

In this chapter, we also briefly describe the systems maintenance process and the deliverables and outcomes from this process. This is followed by a detailed discus- sion contrasting the types of maintenance and an over- view of critical management issues. Finally, we describe the process of maintaining Web-based applications, including an example for the Pine Valley Furniture’s (PVF’s) WebStore application.

MAINTAINING INFORMATION SYSTEMS Once an information system is installed, the system is essentially in the maintenance phase of the systems devel- opment life cycle (SDLC). When a system is in the mainte- nance phase, some person within the systems development group is responsible for collecting maintenance requests from system users and other interested parties, such as system auditors, data center and network management staff, and data analysts. Once collected, each request is analyzed to better understand how it will alter the system and what business benefits and necessities will result from such a change. If the change request is approved, a system change is designed and then implemented. As with the initial development of the system, implemented changes are formally reviewed and tested before installation into operational systems.

14.3 describe maintenance management issues, including alternative organizational structures, quality measurement, processes for handling change requests, and configuration management.

Learning Objectives After studying this chapter, you should be able to

14.1 explain and contrast four types of maintenance;

14.2 describe several factors that influence the cost of maintaining an information system and apply these factors to the design of maintainable systems; and

Maintaining Information Systems14

Introduction

M14_VALA1629_09_GE_C14.indd 495 08/04/2020 17:36

496 PART V IMPLEMENTATION AND MAINTENANCE

The Process of Maintaining Information Systems

As we can see in Figure 14-1, the maintenance phase is the last phase of the SDLC. It is here that the SDLC becomes a cycle, with the last activity leading back to the first. This means that the process of maintaining an information system is the process of returning to the beginning of the SDLC and repeating development steps until the change is implemented.

Also shown in Figure 14-1, four major activities occur within maintenance:

1. Obtaining maintenance requests 2. Transforming requests into changes 3. Designing changes 4. Implementing changes

Obtaining maintenance requests requires that a formal process be established whereby users can submit system change requests. Earlier in this book, we presented a user request document called a System Service Request (SSR), which is shown in Figure 14-2. Most companies have some sort of document like an SSR to request new development, to report problems, or to request new features within an existing system. When developing the procedures for obtaining maintenance requests, organizations must also specify an individual within the organization to collect these requests and manage their dispersal to maintenance personnel. The process of collecting and dis- persing maintenance requests is described in much greater detail later in this chapter.

Once a request is received, analysis must be conducted to gain an understanding of the scope of the request. It must be determined how the request will affect the cur- rent system and how long such a project will take. As with the initial development of a system, the size of a maintenance request can be analyzed for risk and feasibility (see Chapter 5). Next, a change request can be transformed into a formal design change, which can then be fed into the maintenance implementation phase. Thus, many similarities exist between the SDLC and the activities within the maintenance process. Figure 14-3 equates SDLC phases to the maintenance activities described previously. The first phase of the SDLC—planning—is analogous to the maintenance process of obtaining a maintenance request (step 1). The SDLC analysis phase is analogous to the maintenance process of transforming requests into a specific system change (step 2). The SDLC design phase, of course, equates to the designing changes process (step 3). Finally, the SDLC phase implementation equates to step 4, implementing changes. This similarity between the maintenance process and the SDLC is no accident. The concepts and techniques used to initially develop a system are also used to maintain it.

FIGURE 14-1 Systems development life cycle

DesignImplementation

Planning

Maintenance Analysis Obtaining Maintenance Requests Transforming Requests into Changes Designing Changes Implementing Changes

M14_VALA1629_09_GE_C14.indd 496 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 497

Deliverables and Outcomes

Because the maintenance phase of the SDLC is basically a subset of the activities of the entire development process, the deliverables and outcomes from the process are the development of a new version of the software and new versions of all design docu- ments developed or modified during the maintenance process. This means that all documents created or modified during the maintenance effort, including the system itself, represent the deliverables and outcomes of the process. Those programs and documents that did not change may also be part of the new system. Because most organizations archive prior versions of systems, all prior programs and documents must be kept to ensure the proper versioning of the system. This enables prior versions of the system to be re-created if needed. A more detailed discussion of configuration management and change control is presented later in this chapter.

Because of the similarities among the steps, deliverables, and outcomes of new development and maintenance, you may be wondering how to distinguish between these two processes. One difference is that maintenance reuses most existing system modules in producing the new system version. Other distinctions are that a new system is developed when there is a change in the hardware or software platform or when fundamental assumptions and properties of the data, logic, or process models change.

FIGURE 14-2 System Service Request for purchasing fulfillment system (Pine Valley Furniture)

Pine Valley Furniture System Service Request

REQUESTED BY

DEPARTMENT

LOCATION

CONTACT

TYPE OF REQUEST

PROBLEM STATEMENT

Juanita Lopez

Purchasing, Manufacturing Support

Headquarters, 1-322

Tel: 4-3267 FAX: 4-3270 e-mail: jlopez

URGENCY

DATE November 5, 2020

[

[ [

]

] ]

[

[ [

]

] ]

New System

System Enhancement System Error Correction

Immediate—Operations are impaired or opportunity lost Problems exist, but can be worked around Business losses can be tolerated until new system is installed

Sales growth at PVF has caused greater volume of work for the manufacturing support unit within Purchasing. Further, more concentration on customer service has reduced manufacturing lead times, which puts more pressure on purchasing activities. In addition, cost-cutting measures force Purchasing to be more aggressive in negotiating terms with vendors, improving delivery times, and lowering our investments in inventory. The current modest systems support for manufacturing purchasing is not responsive to these new business conditions. Data are not available, information cannot be summarized, supplier orders cannot be adequately tracked, and commodity buying is not well supported. PVF is spending too much on raw materials and not being responsive to manufacturing needs.

SERVICE REQUEST

IS LIAISON

SPONSOR

TO BE COMPLETED BY SYSTEMS PRIORITY BOARD [

[ [ [

]

] ] ]

Request approved

Recommend revision Suggest user development Reject for reason

Assigned to Start date

Chris Martin (Tel: 4-6204 FAX: 4-6200 e-mail: cmartin)

Sal Divario, Director, Purchasing

M14_VALA1629_09_GE_C14.indd 497 08/04/2020 17:36

498 PART V IMPLEMENTATION AND MAINTENANCE

CONDUCTING SYSTEMS MAINTENANCE A significant portion of the expenditures for information systems within organiza- tions does not go to the development of new systems but to the maintenance of exist- ing systems. We will describe various types of maintenance, factors influencing the complexity and cost of maintenance, and alternatives for managing maintenance. Given that maintenance activities consume the majority of information-systems-related expenditures, gaining an understanding of these topics will yield numerous benefits to your career as an information systems professional.

Types of Maintenance

You can perform several types of maintenance on an information system (see Table 14-1). By maintenance, we mean the fixing or enhancing of an information system. Corrective maintenance refers to changes made to repair defects in the design, cod- ing, or implementation of the system. For example, if you had recently purchased a new home, corrective maintenance would involve repairs made to things that had never worked as designed, such as a faulty electrical outlet or a misaligned door. Most corrective maintenance problems surface soon after installation. When corrective maintenance problems surface, they are typically urgent and need to be resolved to curtail possible interruptions in normal business activities. Of all types of main- tenance, corrective accounts for as much as 75 percent of all maintenance activity (Andrews & Leventhal, 1993; Pressman, 2005). This is unfortunate because corrective maintenance adds little or no value to the organization; it simply focuses on removing defects from an existing system without adding new functionality (see Figure 14-4).

Adaptive maintenance involves making changes to an information system to evolve its functionality to changing business needs or to migrate it to a different oper- ating environment. Within a home, adaptive maintenance might be adding storm windows to improve the cooling performance of an air conditioner. Adaptive mainte- nance is usually less urgent than corrective maintenance because business and techni- cal changes typically occur over some period of time. Contrary to corrective maintenance, adaptive maintenance is generally a small part of an organization’s maintenance effort, but it adds value to the organization.

Perfective maintenance involves making enhancements to improve processing performance or interface usability or to add desired, but not necessarily required, system features (“bells and whistles”). In our home example, perfective maintenance

Maintenance Changes made to a system to fix or enhance its functionality.

Corrective maintenance Changes made to a system to repair flaws in its design, coding, or implementation.

Adaptive maintenance Changes made to a system to evolve its functionality to changing business needs or technologies.

Perfective maintenance Changes made to a system to add new features or to improve performance.

FIGURE 14-3 Maintenance activities parallel those of the SDLC

Design

Planning

Implementation Analysis

The Maintenance Process

1. Obtaining Maintenance Requests

2. Transforming Requests into Changes

3. Designing Changes

4. Implementing Changes

Maintenance

Type Description

Corrective Repair design and programming errors

Adaptive Modify system to environmental changes

Perfective Evolve system to solve new problems or take advantage of new opportunities

Preventive Safeguard system from future problems

TABLE 14-1 Types of

M14_VALA1629_09_GE_C14.indd 498 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 499

would be adding a new room. Many systems professionals feel that perfective mainte- nance is not really maintenance but rather new development.

Preventive maintenance involves changes made to a system to reduce the chance of future system failure. An example of preventive maintenance might be to increase the number of records that a system can process far beyond what is currently needed or to generalize how a system sends report information to a printer so that the system can easily adapt to changes in printer technology. In our home example, preventive maintenance could be painting the exterior to better protect the home from severe weather conditions. As with adaptive maintenance, both perfective and preven- tive maintenance are typically a much lower priority than corrective maintenance. Over the life of a system, corrective maintenance is most likely to occur after initial system installation or after major system changes. This means that adaptive, perfective, and preventive maintenance activities can lead to corrective maintenance activities if not carefully designed and implemented.

The Cost of Maintenance

Information systems maintenance costs are a significant expenditure. For some orga- nizations, as much as 60 to 80 percent of their information systems budget is allocated to maintenance activities (Kaplan, 2002). These huge maintenance costs are due to the fact that many organizations have accumulated more and more older so-called legacy systems that require more and more maintenance (see Figure 14-5). More maintenance means more maintenance work for programmers. For systems devel- oped in-house, on average, 52 percent of a company’s programmers are assigned

Preventive maintenance Changes made to a system to avoid possible future problems.

FIGURE 14-4 Value and non-value adding of different types of maintenance

(Sources: Based on Andrews & Leventhal, 1993; Pressman, 2005.)

Corrective—adds no value

Preventive Perfective

Adaptive

Maintenance Type

FIGURE 14-5 New development versus maintenance as a percentage of the software budget over the years

(Source: Based on Pressman, 2005.)

0 1960s–1970s 1980s–1990s 2000–present

Maintenance New Development

M14_VALA1629_09_GE_C14.indd 499 08/04/2020 17:36

500 PART V IMPLEMENTATION AND MAINTENANCE

to maintain existing software (Lytton, 2001). In situations where a company has not developed its systems in-house but instead has licensed software, as in the case of ERP systems, maintenance costs remain high. The standard cost of maintenance for most ERP vendors is 22 percent annually (Nash, 2010). In addition, about one-third of the costs of establishing and keeping a presence on the Web go to programming mainte- nance (Legard, 2000). These high costs associated with maintenance mean that you must understand the factors influencing the maintainability of systems. Maintainability is the ease with which software can be understood, corrected, adapted, and enhanced. Systems with low maintainability result in uncontrollable maintenance expenses.

Numerous factors influence the maintainability of a system. These factors, or cost elements, determine the extent to which a system has high or low maintainability. Of these factors, three are most significant: the number of latent defects, the number of customers, and documentation quality. The others—personnel, tools, and software structure—have noticeable, but less, influence.

• Latent defects. This is the number of unknown errors existing in the system after it is installed. Because corrective maintenance accounts for most mainte- nance activity, the number of latent defects in a system influences most of the costs associated with maintaining a system.

• Number of customers for a given system. In general, the greater the number of customers, the greater the maintenance costs. For example, if a system has only one customer, problem and change requests will come from only one source. Also, training, error reporting, and support will be simpler. Maintenance requests are less likely to be contradictory or incompatible.

• Quality of system documentation. Without quality documentation, maintenance efforts can increase exponentially. For example, Figure 14-6 shows that the system maintenance effort takes 400 percent longer with poor-quality documentation. High-quality documentation leads to an 80 percent reduction in the system maintenance effort when compared with average-quality documentation. In other words, quality documentation makes it easier to find code that needs to be changed and to understand how the code needs to be changed. Good documentation also explains why a system does what it does and why alternatives were not feasible, which saves wasted maintenance efforts.

• Maintenance personnel. In some organizations, the best programmers are assigned to maintenance. Highly skilled programmers are needed because the

Maintainability The ease with which software can be understood, corrected, adapted, and enhanced.

FIGURE 14-6 Quality documentation eases maintenance

(Source: Based on Hanna, M. (1992, December). Using documentation as a life-cycle tool. Software Magazine, 41–46.)

400

300

200

100

–100

P er

ce n t

C h an

g e

in M

ai n te

n an

ce E

� o

rt f

ro m

N o

Poor Average High

Documentation Technical Quality

400

200

125

30 0 –15

–35 – 48 –50 –80

Norm

Normal maintenance e�ort required for average documentation quality

M14_VALA1629_09_GE_C14.indd 500 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 501

maintenance programmer is typically not the original programmer and must quickly understand and carefully change the software.

• Tools. Tools that can automatically produce system documentation where none exists can also lower maintenance costs. Also, tools that can automatically generate new code based on system specification changes can dramatically reduce maintenance time and costs.

• Well-structured programs. Well-designed programs are easier to understand and fix.

Packaged application software still requires maintenance, even though it was not developed in-house. Although vendors of packaged software charge an annual maintenance fee for updates, these charges are more predictable and lower than for custom-developed systems (Worthen, 2003). However, internal maintenance work may still be necessary when using packages. One major maintenance task is to make the packaged software compatible with other packages and internally developed sys- tems with which it must cooperate. When new releases of the purchased packages appear, maintenance may be needed to make all the packages continue to share and exchange data.

Managing Maintenance

As maintenance activities consume more and more of the systems development bud- get, maintenance management has become increasingly important. Today, far more programmers worldwide are working on maintenance than on new development. In other words, maintenance is the largest segment of programming personnel, and this implies the need for careful management. We will address this concern by discussing several topics related to the effective management of systems maintenance.

Managing Maintenance Personnel One concern with managing maintenance relates to personnel management. Historically, many organizations had a “mainte- nance group” that was separate from the “development group.” With the increased number of maintenance personnel, the development of formal methodologies and tools, changing organizational forms, end-user computing, and the widespread use of very high-level languages for the development of some systems, organizations have rethought the organization of maintenance and development personnel. In other words, should the maintenance group be separated from the development group? Or should the same people who build the system also maintain it? A third option is to let the primary end users of the system in the functional units of the business have their own maintenance personnel. The advantages and disadvantages to each of these organizational structures are summarized in Table 14-2.

In addition to the advantages and disadvantages listed in Table 14-2, there are numerous other reasons why organizations should be concerned with how they manage and assign maintenance personnel. One key issue is that many sys- tems professionals don’t want to perform maintenance because they feel that it is more exciting to build something new than change an existing system (Martin, Brown, DeHayes, Hoffers, & Perkins, 2008). In other words, maintenance work is often viewed as “cleaning up someone else’s mess.” Also, organizations have historically provided greater rewards and job opportunities to those performing new development, thus making people shy away from maintenance-type careers. As a result, no matter how an organization chooses to manage its maintenance group—separate, combined, or functional—it is now common to rotate individu- als in and out of maintenance activities. This rotation is believed to lessen the negative feelings about maintenance work and to give personnel a greater under- standing of the difficulties of and relationships between new development and maintenance.

M14_VALA1629_09_GE_C14.indd 501 08/04/2020 17:36

502 PART V IMPLEMENTATION AND MAINTENANCE

Measuring Maintenance Effectiveness A second management issue is the mea- surement of maintenance effectiveness. As with the effective management of person- nel, the measurement of maintenance activities is fundamental to understanding the quality of the development and maintenance efforts. To measure effectiveness, you must measure the following factors:

• Number of failures • Time between each failure • Type of failure

Measuring the number of and time between failures will provide you with the basis to calculate a widely used measure of system quality. This metric is referred to as the mean time between failures (MTBF). As its name implies, the MTBF metric shows the average length of time between the identification of one system failure and the next. Over time, you should expect the MTBF value to rapidly increase after a few months of use (and corrective maintenance) of the system (see Figure 14-7 for an example of the relationship between MTBF and age of a system). If the MTBF does not rapidly increase over time, it will be a signal to management that major problems exist within the system that are not being adequately resolved through the mainte- nance process.

Mean time between failures (MTBF) A measurement of error occurrences that can be tracked over time to indicate the quality of a system.

Type Advantages Disadvantages

Separate Formal transfer of systems between groups improves the system and documentation quality.

All things cannot be documented, so the maintenance group may not know critical information about the system.

Combined Maintenance group knows or has access to all assumptions and decisions behind the system’s original design.

Documentation and testing thorough- ness may suffer due to a lack of a formal transfer of responsibility.

Functional Personnel have a vested interest in effectively maintaining the system and have a better understanding of functional requirements.

Personnel may have limited job mobility and lack access to adequate human and technical resources.

TABLE 14-2 Advantages and Disadvantages of Different Maintenance Organizational Structures

FIGURE 14-7 How the mean time between failures should change over time

A ve

ra g

e D

ay s

B et

w ee

n a

F ai

lu re

0 1 2 3 4 5 6 Months Since System Was Installed

M14_VALA1629_09_GE_C14.indd 502 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 503

A more revealing method of measurement is to examine the failures that are occurring. Over time, logging the types of failures will provide a very clear picture of where, when, and how failures occur. For example, knowing that a system repeatedly fails to log new account information to the database when a particular customer is using the system can provide invaluable information to the maintenance personnel. Were the users adequately trained? Is there something unique about this user? Is there something unique about an installation that is causing the failure? What activities were being performed when the system failed?

Tracking the types of failures also provides important management information for future projects. For example, if a higher frequency of errors occurs when a par- ticular development environment is used, such information can help guide personnel assignments; training courses; or the avoidance of a particular package, language, or environment during future development. The primary lesson here is that without measuring and tracking maintenance activities, you cannot gain the knowledge to improve or know how well you are doing relative to the past. To effectively manage and to continuously improve, you must measure and assess performance over time.

Controlling Maintenance Requests Another maintenance activity is managing maintenance requests. There are various types of maintenance requests—some cor- rect minor or severe defects in the systems, whereas others improve or extend system functionality. From a management perspective, a key issue is deciding which requests to perform and which to ignore. Because some requests will be more critical than others, some method of prioritizing requests must be determined.

Figure 14-8 shows a flowchart that suggests one possible method you could apply for dealing with maintenance change requests. First, you must determine the type of request. If, for example, the request is an error—that is, a corrective maintenance request—then the flowchart shows that the request is placed in the queue of tasks waiting to be performed on the system. For an error of high severity, repairs to remove it must be made as soon as possible. If, however, the error is considered “non-severe,” then the change request can be categorized and prioritized based upon its type and relative importance.

If the change request is not an error, then you must determine whether the request is to adapt the system to technology changes and/or business requirements, perfect its operation in some way, or enhance the system so that it will provide new business functionality. Enhancement-type requests must first be evaluated to see

FIGURE 14-8 How to prioritize maintenance requests

Not Needed Needed

Adaptive/PerfectiveEnhancement

Other Corrective

Change Request

Type?

Evaluate

Terminate Request and

Notify Requester

Select Next Task from

Queue

Categorize/ Prioritize

M14_VALA1629_09_GE_C14.indd 503 08/04/2020 17:36

504 PART V IMPLEMENTATION AND MAINTENANCE

whether they are aligned with future business and information systems’ plans. If not, the request will be rejected and the requester will be informed. If the enhancement appears to be aligned with business and information systems plans, it can then be prioritized and placed into the queue of future tasks. Part of the prioritization pro- cess includes estimating the scope and feasibility of the change. Techniques used for assessing the scope and feasibility of entire projects should be used when assessing maintenance requests (see Chapter 5).

Managing the queue of pending tasks is an important activity. The queue of maintenance tasks for a given system is dynamic—growing and shrinking based upon business changes and errors. In fact, some lower-priority change requests may never be accomplished because only a limited number of changes can be accom- plished at a given time. In other words, changes in business needs between the time the request was made and when the task finally rises to the top of the queue may result in the request being deemed unnecessary or no longer important given cur- rent business directions. Thus, managing the queue of pending tasks is an impor- tant activity.

To better understand the flow of a change request, see Figure 14-9. Initially, an organizational group that uses the system will make a request to change the system. This request flows to the project manager of the system (labeled 1). The project manager evaluates the request in relation to the existing system and pending changes and forwards the results of this evaluation to the system priority board (labeled 2). This evaluation will also include a feasibility analysis that includes estimates of project scope, resource requirements, risks, and other relevant factors. The board evaluates, categorizes, and prioritizes the request in relation to both the strategic and informa- tion systems plans of the organization (labeled 3). If the board decides to kill the request, the project manager informs the requester and explains the rationale for the decision (labeled 4). If the request is accepted, it is placed in the queue of pending tasks. The project manager then assigns tasks to maintenance personnel based upon their availability and task priority (labeled 5). On a periodic basis, the project man- ager prepares a report of all pending tasks in the change request queue. This report is forwarded to the priority board where they re-evaluate the requests in light of the current business conditions. This process may result in removing some requests or reprioritizing others.

Although each change request goes through the approval process depicted in Figure 14-9, changes are usually implemented in batches, forming a new release of the

FIGURE 14-9 How a maintenance request moves through an organization

System Priority Board

1. Change Request

Project Manager

Maintenance Sta�

System Users

2. Change Request

3. Decision 4. Noti�cation

5. Maintenance Task

M14_VALA1629_09_GE_C14.indd 504 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 505

software. It is too difficult to manage a lot of small changes. Further, batching changes can reduce maintenance work when several change requests affect the same or highly related modules. Frequent releases of new system versions may also confuse users if the appearance of displays, reports, or data entry screens changes.

Configuration Management A final aspect of managing maintenance is configuration management, which is the process of ensuring that only authorized changes are made to a system. Once a system has been implemented and installed, the programming code used to construct the system represents the baseline modules of the system. The baseline modules are the software modules for the most recent version of a system whereby each module has passed the organization’s quality assurance process and documentation standards. A system librarian controls the checking out and checking in of the baseline source code modules. If maintenance personnel are assigned to make changes to a system, they must first check out a copy of the baseline system modules—no one is allowed to directly modify the baseline modules. Only those modules that have been tested and have gone through a formal check-in process can reside in the library. Before any code can be checked back in to the librarian, the code must pass the quality control procedures, testing, and documentation standards established by the organization.

When various maintenance personnel working on different maintenance tasks complete each task, the librarian notifies those still working that updates have been made to the baseline modules. This means that all tasks being worked on must now incorporate the latest baseline modules before being approved for check-in. Following a formal process of checking modules out and in, a system librarian helps to ensure that only tested and approved modules become part of the baseline system. It is also the responsibility of the librarian to keep copies of all prior versions of all system modules, including the build routines needed to construct any version of the system that has ever existed. It may be important to reconstruct old versions of the system if new ones fail or to support users that cannot run newer versions on their computer system.

Special software systems have been created to manage system configuration and version control activities (see the box “Configuration Management Tools”). This soft- ware is becoming increasingly necessary as the change control process becomes ever more complicated in organizations deploying several different networks, operating systems, languages, and database management systems in which there may be many concurrent versions of an application, each for a different platform. One function of this software is to control access to modules in the system library. Each time a module is checked out or in, this activity is recorded after being authorized by the librarian. This software helps the librarian to track that all necessary steps have been followed before a new module is released to production, including all integration tests, docu- mentation updates, and approvals.

Configuration management The process of ensuring that only autho- rized changes are made to a system.

Baseline modules Software modules that have been tested, documented, and approved to be included in the most recently created version of a system.

System librarian A person responsible for controlling the checking out and checking in of base- line modules for a system when a system is being developed or maintained.

Build routines Guidelines that list the instructions to construct an executable system from the baseline source code.

There are two general kinds of configuration management tools: revision control and source code control. With revision control tools, each system module file is “frozen” (unchangeable) to a specific version level or is designated as “floating” (changeable), meaning a programmer may check out, lock, and modify a specific system module. Only the most recent version of a module—and the specific changes made to it—are stored in the library; all previous versions of a module can be reconstructed, if needed, by applying any changes to the module in reverse order.

Source code control tools extend revision control to not only a single module, but to any interrelated files to the module being changed. Configuration management tools have become invaluable to the system maintenance process by facilitating the rebuilding of any historic version of a system by recompiling the proper source code modules. Configuration management tools allow you to trace an executable code module back to its original source code version, greatly speeding the identification of programming errors.

Configuration Management Tools

M14_VALA1629_09_GE_C14.indd 505 08/04/2020 17:36

506 PART V IMPLEMENTATION AND MAINTENANCE

Role of Automated Development Tools in Maintenance

In traditional systems development, much of the time is spent on coding and testing. When software changes are approved, code is first changed and then tested. Once the functionality of the code is assured, the documentation and specification documents are updated to reflect system changes. Over time, the process of keeping all system documentation “current” can be a very boring and time-consuming activity that is often neglected. This neglect makes future maintenance by the same or different pro- grammers difficult at best.

A primary objective of using automated tools for systems development and main- tenance is to radically change the way in which code and documentation are modified and updated. When using an integrated development environment, analysts maintain design documents such as data flow diagrams and screen designs, not source code. In other words, design documents are modified and then code generators automati- cally create a new version of the system from these updated designs. Also, because the changes are made at the design specification level, most documentation changes, such as an updated data flow diagram, will have already been completed during the maintenance process itself. Thus, one of the biggest advantages to using automated tools, for example, is its usefulness in system maintenance.

In addition to using general automated tools for maintenance, two special-pur- pose tools, reverse engineering and re-engineering tools, are used to maintain older systems that have incomplete documentation. These tools are often referred to as design recovery tools because their primary benefit is to create high-level design docu- ments of a program by reading and analyzing its source code.

Reverse engineering tools are those that can create a representation of a system or program module at a design level of abstraction. For example, reverse engineering tools read program source code as input; perform an analysis; and extract information such as program control structures, data structures, and data flow. Once a program is represented at a design level using both graphical and textual representations, the design can be more effectively restructured to current business needs or programming practices by an analyst. For example, NetBeans, an open source software tool, can be used to reverse engineer Java applications into UML diagrams (see Figure 14-10).

Similarly, re-engineering tools extend reverse engineering tools by automatically (or interactively with a systems analyst) altering an existing system in an effort to improve its quality or performance. As reverse and re-engineering capabilities are included in more popular development environments, the ability to extend the life and evolve the capabilities of existing systems will be enhanced (Orr, 2005).

WEBSITE MAINTENANCE All of the discussion on maintenance in this chapter applies to any type of information system, no matter what platform it runs on. However, some special issues and proce- dures apply to Websites, based on their special nature and operational status. These issues and procedures include the following:

• 24/7/365. Most Websites are never purposely unavailable. In fact, an e-commerce Website has the advantage of continuous operation. Thus, mainte- nance of pages and the overall site usually must be done without taking the site offline. However, it may be necessary to lock out use of pages in a portion of a Website while changes are made to those pages. This can be done by inserting a “Temporarily Out of Service” notice on the main page of the section being maintained and disabling all links within that segment. Alternatively, references to the main page of the section can be temporarily rerouted to an alternative location where the current pages are kept while maintenance is performed to create new versions of those pages. The really tricky part is keeping the site

Reverse engineering Automated tools that read program source code as input and create graphical and textual representations of design-level information such as pro- gram control structures, data structures, logical flow, and data flow.

Re-engineering Automated tools that read program source code as input; perform an analy- sis of the program’s data and logic; and then automatically, or interactively with a systems analyst, alter an existing sys- tem in an effort to improve its quality or performance.

M14_VALA1629_09_GE_C14.indd 506 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 507

consistent for a user during a session; that is, it can be confusing to a user to see two different versions of a page during the same online session. Browser caching functions may bring up an old version of a page even when that page changes during the session. One precaution against this confusion is locking, as explained previously. Another approach is to not lock a page being changed, but to include a date and time stamp of the most recent change. This gives the page visitor an indication of the change, which may reduce confusion.

• Check for broken links. Arguably the most common maintenance issue for any Website (besides changing the content of the site) is validating that links from site pages (especially for links that go outside the source site) are still accurate. Periodic checks need to be performed to make sure active pages are found from all links—this can be done via software such as LinkAlarm (http://www .linkalarm.com) and Doctor HTML (http://www.fixingyourwebsite.com). Note the irony of any potentially changing URL in a published paper or textbook! In addition, periodic human checks need to be performed to make sure that the content found at a still-existing referenced page is still the intended content.

• HTML validation. Before modified or new pages are published, these pages should be processed by a code validation routine to ensure that all the code, including applets, works. If you are using HTML, XML, script, or another editor, such a feature is likely built into the software.

• Reregistration. It may be necessary to reregister a Website with search engines when the content of your site changes significantly. Reregistration may be neces- sary in order for visitors to find your site based on the new or changed content.

• Future editions. One of the most important issues to address to ensure effective Website use is to avoid confusing visitors. In particular, frequent visitors can become confused if the site is constantly changing. To avoid confusion, you can post indications of future enhancements to the site and, as with all information systems, you can batch changes to reduce the frequency of site changes.

In addition, various Website design decisions can greatly influence a site’s main- tainability; refer to Chapter 12 to review guidelines for effective Website design.

FIGURE 14-10 NetBeans IDE can reverse engi- neer Java applications into UML diagrams

(Source: Microsoft Corporation.)

M14_VALA1629_09_GE_C14.indd 507 08/04/2020 17:36

http://www.linkalarm.com

http://www.fixingyourwebsite.com

508 PART V IMPLEMENTATION AND MAINTENANCE

ELECTRONIC COMMERCE APPLICATION: MAINTAINING AN INFORMATION SYSTEM FOR PINE VALLEY FURNITURE’S WEBSTORE In this chapter, we examined various aspects of conducting system maintenance. Main- tenance is a natural part of the life of any system. In this section, we conclude our discussion of PVF’s WebStore by examining a maintenance activity for this system.

Maintaining Pine Valley Furniture’s WebStore

Early on a Saturday evening, Jackie Judson, vice president of marketing at PVF, was reviewing new-product content that was recently posted on the company’s electronic commerce Website, the WebStore. She was working on Saturday evening because she was leaving the next day for a long-overdue, two-week vacation to the Black Hills of South Dakota. Before she could leave, however, she wanted to review the appearance and layout of the pages.

Midway through the review process, pages from the WebStore began to load very slowly. Finally, after requesting detailed information on a particular product, the Web- Store simply stopped working. The title bar on her Web browser reported the error:

Cannot Find Server

Given that her plane for Rapid City left in less than 12 hours, Jackie wanted to review the content and needed to figure out some way to overcome this catastrophic system error. Her first thought was to walk over to the offices of the information systems development group within the same building. When she did, she found no one there. Her next idea was to contact Jim Woo, senior systems analyst and the project manager for the WebStore system. She placed a call to Jim’s home and found that he was at the grocery store but would be home soon. Jackie left a message for Jim to call her ASAP at the office.

Within 30 minutes, Jim returned the call and was on his way into the office to help Jackie. Although not a common occurrence, this was not the first time that Jim had gone into the office to assist users when systems failed during off hours. Before leaving for the office, he connected to the Internet and also found the WebStore to be unavailable. Because PVF outsourced the hosting of the WebStore to an outside vendor, Jim immediately notified the vendor that the WebStore was down. The vendor was a local Internet service provider (ISP) that had a long-term relationship with PVF to provide Internet access, but it had limited experience with hosting commercial Websites. Jim was informed that a system “glitch” was responsible for the outage and that the WebStore would be online within the next hour or so. Unfortunately, this was not the first time the WebStore had failed, and Jim felt powerless. More than ever before, he believed that PVF needed to find a better way to learn about system fail- ures and, more important, it needed an improved confidence that the system would operate reliably.

On Monday morning, Jim requested a meeting with several senior PVF manag- ers. At this meeting, he posed the following questions:

• How much is our Website worth? • How much does it cost our company when our Website goes down? • How reliable does our Website need to be?

These questions encouraged a spirited discussion. Everyone agreed that the WebStore was “critical” to PVF’s future and unanimously agreed that it was “unac- ceptable” for the site to be down. One manager summarized the feeling of the group by stating, “I cannot think of a single valid excuse for the system to crash … our

PINE VALLEY FURNITURE

M14_VALA1629_09_GE_C14.indd 508 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 509

customers have incredibly high expectations of us … one major mishap could prove disastrous for PVF.”

Jim outlined to the group what he felt the next steps needed to be. “I believe that the root of our problem is with our contract with our Web hosting company. Specifically, we need to renegotiate our contract, or find a different vendor, so that it includes wording to reflect our expectations of service. Our current agreement does not address how emergencies are responded to or what remedies we have for continued system failures. The question we must also address is the cost differences between having a site that operates 99 percent of the time versus one that operates 99.999 percent of the time. I believe,” he continued, “that it could increase our costs tens of thousands of dollars per month to guarantee extremely high levels of system reliability.”

At the conclusion of the meeting, the senior managers unanimously agreed that Jim should immediately develop a plan for addressing the WebStore’s service level problems. To begin this process, Jim prepared a detailed list of specific vendor services they desired. He felt a very specific list was needed so that the relative costs for differ- ent services and varying levels of service (e.g., response times for system failures and penalties for noncompliance) could be discussed.

When asked by a colleague what type of maintenance was being performed on the WebStore to improve system reliability, Jim had to pause and think. “Well, it is clearly adaptive in that we plan to migrate the system to a more reliable environment. It is also perfective and preventive. … It is perfective in that we want to make some opera- tional changes that will improve system performance, and it is also preventive given that one of our objectives is to reduce the likelihood of system failures.” Through this discussion it became clear to Jim that the system was much larger than simply the HTML used to construct the WebStore; it also included the hardware, system software, procedures, and response team in place to deal with unforeseen events. Although he had heard it said many times before, Jim now understood that a successful system reflected all of its various aspects.

SUMMARY Maintenance is the final phase in the SDLC. During main- tenance, systems are changed to rectify internal processing errors or to extend the functionality of the system. Mainte- nance is where a majority of the financial investment in a system occurs and can span more than 20 years. More and more information systems professionals have devoted their careers to systems maintenance and, as more systems move from initial development into operational use, it is likely that even more professionals will in the future.

It is during maintenance that the SDLC becomes a life cycle because requests to change a system must first be approved, planned, analyzed, designed, and then imple- mented. In some special cases, when business operations are impaired due to an internal system error, quick fixes can be made. This, of course, circumvents the normal maintenance process. After quick fixes are made, mainte- nance personnel must back up and perform a thorough analysis of the problem to make sure that the correction conforms to normal systems development standards for design, programming, testing, and documentation. Main- tenance requests can be one of four types: corrective, adap- tive, perfective, and preventive.

How a system is designed and implemented can greatly impact the cost of performing maintenance. The number of unknown errors in a system when it is installed is a primary factor in determining the cost of maintenance. Other factors, such as the number of separate customers and the quality of documentation, significantly influence maintenance costs.

Another maintenance management issue relates to understanding how to measure the quality of the main- tenance effort. Most organizations track the frequency, time, and type of each failure and compare performance over time. Because limited resources preclude organiza- tions from performing all maintenance requests, some formal process for reviewing requests must be established to make sure that only those requests deemed consistent with organizational and information systems plans are per- formed. A central source, usually a project manager, is used to collect maintenance requests. When requests are submitted, this person forwards each request to a com- mittee charged with assessing its merit. Once assessed, the project manager assigns higher-priority activities to main- tenance personnel.

M14_VALA1629_09_GE_C14.indd 509 08/04/2020 17:36

510 PART V IMPLEMENTATION AND MAINTENANCE

Maintenance personnel must be prevented from making unapproved changes to a system. To do this, most organizations assign one member of the maintenance staff, typically a senior programmer or analyst, to serve as the sys- tem librarian. The librarian controls the checking out and checking in of system modules to ensure that appropriate procedures for performing maintenance, such as adequate testing and documentation, are adhered to.

Automated tools are actively employed during main- tenance to enable maintenance to be performed on design documents rather than on low-level source code. Reverse

engineering and re-engineering tools are used to recover design specifications of older systems. Once recovered, these older systems can then be changed at the design level rather than the source code level, yielding a signifi- cant improvement in maintenance personnel productivity.

Website maintenance involves some special attention, including: 24-7-365 operation, checking for broken exter- nal links, validating code changes before publishing new or revised pages, reregistration of the Website for search engines, and avoiding visitor confusion by previewing future changes.

REVIEW QUESTIONS 14.14 Contrast the following terms:

a. Adaptive maintenance, corrective maintenance, perfective maintenance, preventive maintenance

b. Baseline modules, build routines, system librarian c. Maintenance, maintainability

14.15 A Webmaster begins the process of moving a high-traffic Website to a new version of the Web server. The argument for undertaking this task is that the new Web server has several newly added features that would make the Web- site more stable and handle more user simultaneous user requests. What kind of maintenance is this an example of?

14.16 A plug-in (small application) used in the Website in the previous problem ceases to work after the move to the new

Web server. Steps are taken to find another plug-in and replace the old one. What kind of maintenance is this an example of?

14.17 After the update has been completed and a new plug-in has been acquired, installed, and thoroughly tested, everything works fine. However, it is discovered that a competitor’s Website works better on small screens (smart phones and tablets). This is because the contents of that particular Website move around to compensate for the narrower width. Thus, work begins on CSS and HTML coding to give users a better experience on smart- phones and tablets. What kind of maintenance is this an example of ?

Match each of the key terms above with the definition that best fits it.

____ Changes made to a system to fix or enhance its functionality.

____ Changes made to a system to repair flaws in its design, cod- ing, or implementation.

____ Changes made to a system to evolve its functionality to changing business needs or technologies.

____ Changes made to a system to add new features or to improve performance.

____ Changes made to a system to avoid possible future problems.

____ The ease with which software can be understood, corrected, adapted, and enhanced.

____ A measurement of error occurrences that can be tracked over time to indicate the quality of a system.

____ The process of ensuring that only authorized changes are made to a system.

____ Software modules that have been tested, documented, and approved to be included in the most recently created ver- sion of a system.

____ A person responsible for controlling the checking out and checking in of baseline modules for a system when a system is being developed or maintained.

____ Guidelines that list the instructions to construct an execut- able system from the baseline source code.

____ Automated tools that read program source code as input and create graphical and textual representations of design- level information such as program control structures, data structures, logical flow, and data flow.

____ Automated tools that read program source code as input; perform an analysis of the program’s data and logic; and then automatically, or interactively with a systems analyst, alter an existing system in an effort to improve its quality or performance.

KEY TERMS

14.1 Adaptive maintenance 14.2 Baseline modules 14.3 Build routines 14.4 Configuration management 14.5 Corrective maintenance

14.6 Maintainability 14.7 Maintenance 14.8 Mean time between failures

(MTBF) 14.9 Perfective maintenance

14.10 Preventive maintenance 14.11 Re-engineering 14.12 Reverse engineering 14.13 System librarian

M14_VALA1629_09_GE_C14.indd 510 08/04/2020 17:36

CHAPTER 14 MaIntaInIng InforMatIon SySteMS 511

REFERENCES Andrews, D. C., & Leventhal, N. S. (1993). Fusion: Integrating IE,

CASE, JAD: A handbook for reengineering the systems organization. Upper Saddle River, NJ: Prentice Hall.

Hanna, M. (1992, December). Using documentation as a life-cycle tool. Software Magazine, 6, 41–46.

14.18 Describe three ways for organizing maintenance person- nel and contrast the advantages and disadvantages of each approach.

14.19 Why is managing the queue of pending tasks an important activity?

14.20 In some organizations, some of the best programmers are assigned to maintenance duties. What is the line of think- ing here?

14.21 A software tool analyzes source code and then creates sche- matics (UML diagram or the like) of a selected part of an

application. Does this tool support reverse engineering or reengineering?

14.22 What does the term “baseline module” refer to?

14.23 Describe the process of updating baseline modules using a process for sending e-mails as an example.

14.24 Corrective maintenance accounts for about 75 percent of a system’s maintenance costs. Why is this unfortunate?

14.25 Following on the previous question, how much of a system development project’s entire budget might go to system maintenance, and how can this figure be lowered?

PROBLEMS AND EXERCISES 14.26 Maintenance has been presented as both the final stage

of the SDLC (see Figure 14-1) and as a process similar to the SDLC (see Figure 14-3). Why does it make sense to talk about maintenance in both of these ways? Do you see a conflict in looking at maintenance in both ways?

14.27 Discuss the graph found in Figure 14-5. What does it show? Does the difference in cost surprise you? How big is the largest difference between the dots shown on the diagram? What are its consequences for maintenance as well as the entire SDLC?

14.28 According to Figure 14-4, corrective maintenance is by far the most frequent form of maintenance. What can you do as a systems analyst to reduce this form of maintenance?

14.29 What other or additional information should be col- lected on a System Service Request (see Figure 14-2) for maintenance?

14.30 A fictional information system is accompanied by a dedi- cated support system, and there are two people responding

to users’ requests. Unfortunately, the requests start piling up, and this is a problem for users as well as to the systems manager. Given that the support budget is limited, what would you recommend the manager do?

14.31 A large hospital can have more than 1,500 IT systems run- ning, and many nurses and doctors may need to log in to up to a dozen different systems. How much strain do you think this situation puts on the IT support personnel? In your opinion, what should be done to try to make things easier and less expensive?

14.32 Re-read the passage about the maintenance problem that the PVF Website was facing. If you were Joe, what would you do?

14.33 What six maintenance activities are especially related to Website management? Discuss the importance of every activity and rate their importance according to your discussion.

FIELD EXERCISES 14.34 Study an information systems department with which you

are familiar or to which you have access. How does this department organize for maintenance? Has this depart- ment adopted one of the three approaches outlined in Table 14-2 or does it use some other approach? Talk with a senior manager in this department to discover how well this maintenance organization structure works.

14.35 Interview a person working in IT support for users. What are the most common questions and comments they receive? What kinds of questions take the most time to work on? Do the questions relate mostly to hardware (like configuring an iPad to function in a Windows-based orga- nization) or software (like how to install a new printer driver)? To what degree are the questions repeated, and if many questions are asked a lot, are they posted to a FAQ Web page or something similar? How does IT support

communicate with its users (helpdesk, e-mail, phone, chat, etc.)? Do you find this way of communicating efficient and helpful?

14.36 Consider the four sorts of maintenance activities. How does the IT support group at your university or workplace distribute the time they have available for these tasks? Interview a person involved in coding for the mainte- nance of the organization’s systems. Explain the four sorts of maintenance activities and ask them to estimate how much time is spent on these.

14.37 Interview a manager of an IT support department. Show the manager Figure 14-8. Does this manager agree with the figure or do they see a danger in using this model without much reflection? What is your own opinion on this? Do you see a danger in using the model without a lot of forethought?

M14_VALA1629_09_GE_C14.indd 511 08/04/2020 17:36

512 PART V IMPLEMENTATION AND MAINTENANCE

Kaplan, S. (2002, March 15). Now is the time to pull the plug on your legacy apps.” CIO Magazine. Retrieved April 4, 2015 from http://www.cio.com.au/article/180065/now_time_ pull_plug_your_legacy_apps/.

Legard, D. (2000, November 9). Study: Online maintenance costs just keep growing.” PCWorld. Retrieved April 4, 2015 from http://www.pcworld.com/article/34502/article.html.

Lytton, N. (2001, July 16). Maintenance dollars at work. ComputerWorld. Retrieved April 4, 2015 from http://www .computerworld.com/ article/2582502/it-management/ maintenance-dollars-at-work.html.

Martin, E. W., Brown, C. V., DeHayes, D. W. Hoffer, J. A. & Perkins, W.C. (2008). Managing information technology: What managers need to know (6th ed.). Upper Saddle River, NJ: Prentice Hall.

Nash, K. (2010). ERP: How and why you need to manage it dif- ferently. Retrieved April 5, 2015 from http://www.cio.com/ article/526213/ERP_How_and_Why_You_Need_to_Manage_ It_Differently?page=1&taxonomyId=3000

Orr, S. (2005, March 7). Design and generate code with Visio. Dotnetjunkies. Retrieved April 4, 2015 from http://www .drdobbs.com/windows/design-and-generate-code-with- visio/219200253.

Pressman, R. S. (2005). Software engineering (6th ed.). New York: McGraw-Hill.

Worthen, B. (2003, July 1). No tolerance for high maintenance. CIO Magazine. Retrieved April 4, 2015 from http://www.cio .com.au/article/184546/no_tolerance_high_maintenance/.

M14_VALA1629_09_GE_C14.indd 512 08/04/2020 17:36

http://www.cio.com.au/article/180065/now_time_pull_plug_your_legacy_apps

http://www.pcworld.com/article/34502/article.html

http://www.computerworld.com/article/2582502/it-management/maintenance-dollars-at-work.html

http://www.cio.com/article/526213/ERP_How_and_Why_You_Need_to_Manage_It_Differently?page=1&taxonomyId=3000

http://www.drdobbs.com/windows/design-and-generate-code-with-visio/219200253

http://www.cio.com.au/article/184546/no_tolerance_high_maintenance

http://www.cio.com.au/article/180065/now_time_pull_plug_your_legacy_apps

http://www.computerworld.com/article/2582502/it-management/maintenance-dollars-at-work.html

http://www.cio.com/article/526213/ERP_How_and_Why_You_Need_to_Manage_It_Differently?page=1&taxonomyId=3000

http://www.drdobbs.com/windows/design-and-generate-code-with-visio/219200253

http://www.cio.com.au/article/184546/no_tolerance_high_maintenance

513 513

Abstract class A class that has no direct instance, but whose descendents may have direct instances. (8)

Abstract operation Defines the form or protocol of the operation, but not its implementation. (8)

Acceptance testing The process whereby actual users test a completed information system, the end result of which is the users’ acceptance of it. (13)

Action stubs That part of a decision table that lists the actions that result for a given set of conditions. (7)

Activity In business process modeling, an action that must take place for a process to be completed. (7)

Activity diagram Shows the conditional logic for the sequence of system activities needed to accomplish a business process. (7)

Actor An external entity that interacts with a system. (7)

Adaptive maintenance Changes made to a system to evolve its functionality to changing business needs or technologies. (14)

Aggregation A part-of relationship between a component object and an aggregate object. (8)

Alpha testing User testing of a completed information system using simulated data. (13)

Analysis The second phase of the SDLC in which system requirements are studied and structured. (1)

Application program interface (API) Software building blocks that are used to ensure that common system capabilities, such as user interfaces and printing, as well as modules are standardized to facilitate data exchange between clients and servers. (12)

Application server A computing server where data analysis functions primarily reside. (12)

Application software Computer software designed to support organizational functions or processes. (1)

Association A named relationship between or among object classes. (8)

Association role The end of an association where it connects to a class. (8)

Associative class An association that has attributes or operations of its own or that participates in relationships with other classes. (8)

Associative entity An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances; also called a gerund. (8)

Attribute A named property or characteristic of an entity that is of interest to the organization. (8)

Balancing The conservation of inputs and outputs to a DFD process when that process is decomposed to a lower level. (7)

Baseline modules Software modules that have been tested, documented, and approved to be included in the most recently created version of a system. (14)

Baseline Project Plan (BPP) A major outcome and deliverable from the project initiation and planning phase that contains the best estimate of a project’s scope, benefits, costs, risks, and resource requirements. (5)

Behavior Represents how an object acts and reacts. (8)

Beta testing User testing of a completed information system using real data in the real user environment. (13)

Binary relationship A relationship between instances of two entity types. This is the most common type of relationship encountered in data modeling. (8)

Break-even analysis A type of cost-benefit analysis to identify at what point (if ever) benefits equal costs. (5)

Build routines Guidelines that list the instructions to construct an executable system from the baseline source code. (14)

Business case The justification for an information system, presented in terms of the tangible and intangible economic benefits and costs and the technical and organizational feasibility of the proposed system. (5)

Business process re-engineering (BPR) The search for, and implementation of, radical change in business processes to achieve breakthrough improvements in products and services. (6)

Business rules Specifications that preserve the integrity of the logical data model. (8)

Calculated field A field that can be derived from other database fields. Also known as a computed field or a derived field. (9)

Candidate key An attribute (or combination of attributes) that uniquely identifies each instance of an entity type. (8)

Cardinality The number of instances of entity B that can (or must) be associated with each instance of entity A. (8)

Cascading Style Sheets (CSSs) A set of style rules that tells a Web browser how to present a document. (12)

Class diagram Shows the static structure of an object-oriented model; the object classes, their internal structure, and the relationships in which they participate. (8)

Class-scope attribute An attribute of a class that specifies a value common to an entire class, rather than a specific value for an instance. (8)

Class-scope operation An operation that applies to a class rather than an object instance. (8)

Client The (front-end) portion of the client/server database system that provides the user interface and data manipulation functions. (12)

Closed-ended questions Questions in interviews that ask those responding to choose from among a set of specified responses. (6)

COCOMO The Constructive Cost Model (COCOMO) is an automated software estimation model that uses historical project

Glossary of Terms

Z01_VALA1629_09_GE_GLOS.indd 513 08/04/2020 17:37

514 Glossary of Terms data and current as well as future project characteristics to estimate project costs. (3)

Command language interaction A human–computer interaction method whereby users enter explicit statements into a system to invoke operations. (11)

Competitive strategy The method by which an organization attempts to achieve its mission and objectives. (4)

Composite attribute An attribute that has meaningful component parts. (8)

Composition A part-of relationship in which parts belong to only one whole object, and the parts live and die with the whole object. (8)

Conceptual data model A detailed model that captures the overall structure of organizational data that is independent of any database management system or other implementation considerations. (8)

Concrete class A class that can have direct instances. (8)

Condition stubs That part of a decision table that lists the conditions relevant to the decision. (7)

Configuration management The process of ensuring that only authorized changes are made to a system. (14)

Constructor operation An operation that creates a new instance of a class. (8)

Content management system (CMS) A special type of software application for collecting, organizing, and publishing Website content. (12)

Cookie crumbs The technique of placing “tabs” or sequenced links on a Web page that show a user where he or she is within a site and where he or she has been. (11)

Corporate strategic planning An ongoing process that defines the mission, objectives, and strategies of an organization. (4)

Corrective maintenance Changes made to a system to repair flaws in its design, coding, or implementation. (14)

Critical path The shortest time in which a project can be completed. (3)

Critical path scheduling A scheduling technique whose order and duration of a sequence of task activities directly affect the completion date of a project. (3)

Customization Internet sites that allow users to customize the content and look of the site based on their personal preferences. (12)

Data flow diagram (DFD) A picture of the movement of data between external entities and the processes and data stores within a system. (7)

Data store Data at rest, which may take the form of many different physical representations. (7)

Data type A coding scheme recognized by system software for representing organizational data. (9)

Database engine The (back-end) portion of the client/server database system running on the server that provides database processing and shared access functions. (12)

Decision table A matrix representation of the logic of a decision; it specifies the possible conditions for the decision and the resulting actions. (7)

Default value A value a field will assume unless an explicit value is entered for that field. (9)

Degree The number of entity types that participate in a relationship. (8)

Deliverable An end product of an SDLC phase. (3)

Denormalization The process of splitting or combining normalized relations into physical tables based on affinity of use of rows and fields. (9)

Derived attribute An attribute whose value can be computed from related attribute values. (8)

Design The third phase of the SDLC in which the description of the recommended solution is converted into logical and then physical system specifications. (1)

Desk checking A testing technique in which the program code is sequentially executed manually by the reviewer. (13)

DFD completeness The extent to which all necessary components of a DFD have been included and fully described. (7)

DFD consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels. (7)

Dialogue The sequence of interaction between a user and a system. (11)

Dialogue diagramming A formal method for designing and representing human–computer dialogues using box and line diagrams. (11)

Direct installation Changing over from the old information system to a new one by turning off the old system when the new one is turned on. (13)

Discount rate The rate of return used to compute the present value of future cash flows. (5)

Disjoint rule Specifies that if an entity instance of the supertype is a member of one subtype, it cannot simultaneously be a member of any other subtype. (8)

Disruptive technologies Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes. (6)

Domain The set of all data types and values that an attribute can assume. (8)

Domain naming system (BIND) A method for translating Internet domain names into Internet Protocol (IP) addresses. BIND stands for Berkeley Internet Name Domain. (12)

Drop-down menu A menu-positioning method that places the access point of the menu near the top line of the display; when accessed, menus open by dropping down onto the display. (11)

Economic feasibility A process of identifying the financial benefits and costs associated with a development project. (5)

Efficiency A usability dimension concerned with how quickly users can perform tasks once they know how to perform them. (10)

Electronic commerce (EC) Internet-based communication to support day-to-day government, business, and consumer activities. (4)

Encapsulation The technique of hiding the internal implementation details of an object from its external view. (8)

Enterprise resource planning (ERP) system A system that integrates individual traditional business functions into a series of modules so that a single transaction occurs seamlessly within a single information system rather than several separate systems. (2)

Entity instance A single occurrence of an entity type. Also known as an instance. (8)

Entity type A collection of entities that share common properties or characteristics. (8)

Entity-relationship data model (E-R model) A detailed, logical representation of the entities, associations, and data elements for an organization or business area. (8)

Entity-relationship diagram (E-R diagram) A graphical representation of an E-R model. (8)

Z01_VALA1629_09_GE_GLOS.indd 514 08/04/2020 17:37

Glossary of Terms 515 Error rate A usability dimension concerned with how many errors a user might encounter, and how easy it is to recover from those errors. (10)

Event In business process modeling, a trigger that initiates the start of a process. (7)

Extend relationship An association between two use cases where one adds new behaviors or actions to the other. (7)

eXtensible Markup Language (XML) An Internet authoring language that allows designers to create customized tags, enabling the definition, transmission, validation, and interpretation of data between applications. (12)

eXtensible Stylesheet Language (XSL) A specification for separating style from content when generating XML pages. (12)

Extension The set of behaviors or functions in a use case that follow exceptions to the main success scenario. (7)

Feasibility study A study that determines if the proposed information system makes sense for the organization from an economic and operational standpoint. (3)

Field The smallest unit of named application data recognized by system software. (9)

File organization A technique for physically arranging the records of a file. (9)

File server A device that manages file operations and is shared by each client PC attached to a LAN. (12)

Flow In business process modeling, it shows the sequence of action in a process. (7)

Foreign key An attribute that appears as a nonprimary key attribute in one relation and as a primary key attribute (or part of a primary key) in another relation. (9)

Form A business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance of a form is typically based on one database record. (10)

Form interaction A highly intuitive human–computer interaction method whereby data fields are formatted in a manner similar to paper-based forms. (11)

Formal system The official way a system works as described in organizational documentation. (6)

Functional dependency A constraint between two attributes in which the value of one attribute is determined by the value of another attribute. (9)

Gantt chart A graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion. (3)

Gap analysis The process of discovering discrepancies between two or more sets of DFDs or discrepancies within a single DFD. (7)

Gateway In business process modeling, a decision point. (7)

Hashed file organization A file organization in which the address of each row is determined using an algorithm. (9)

Help desk A single point of contact for all user inquiries and problems about a particular information system or for all users in a particular department. (13)

Homonym A single attribute name that is used for two or more different attributes. (9)

Hypertext Markup Language (HTML) The standard language for representing content on the Web through the use of hundreds of command tags. (12)

Hypertext Transfer Protocol (HTTP) A communication protocol for exchanging information on the Internet. (12)

Icon Graphical picture that represents specific functions within a system. (11)

Identifier A candidate key that has been selected as the unique, identifying characteristic for an entity type. (8)

Implementation The fourth phase of the SDLC, in which the information system is coded, tested, installed, and supported in the organization. (1)

Include relationship An association between two use cases where one use case uses the functionality contained in the other. (7)

Incremental commitment A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of the project is rejustified. (4)

Index A table used to determine the location of rows in a file that satisfy some condition. (9)

Indexed file organization A file organization in which rows are stored either sequentially or nonsequentially, and an index is created that allows software to locate individual rows. (9)

Indifferent condition In a decision table, a condition whose value does not affect which actions are taken for two or more rules. (7)

Informal system The way a system actually works. (6)

Information systems analysis and design The complex organizational process whereby computer-based information systems are developed and maintained. (1)

Information systems infrastructure The hardware, software, networks, data, facilities, human resources, and services used by organizations to support their decision making, business processes, and competitive strategy. (12)

Information systems planning (ISP) An orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs. (4)

Infrastructure as a service (IaaS) A cloud computing model in which only the basic capabilities of processing, storage, and networking are provided. (12)

Inspections A testing technique in which participants examine program code for predictable language-specific errors. (13)

Installation The organizational process of changing over from the current information system to a new one. (13)

Intangible benefit A benefit derived from the creation of an information system that cannot be easily measured in dollars or with certainty. (5)

Intangible cost A cost associated with an information system that cannot be easily measured in terms of dollars or with certainty. (5)

Integration testing The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in a top-down, incremental fashion. (13)

Interface A method by which users interact with an information system. (11)

Internet A large, worldwide network of networks that use a common protocol to communicate with each other. (4)

Internet-of-Things (IoT) A broad class of physical objects that feature an Internet address and connectivity that communicate between these objects and other Internet-enabled devices and systems. (4)

JAD session leader The trained individual who plans and leads Joint Application Design sessions. (6)

Z01_VALA1629_09_GE_GLOS.indd 515 08/04/2020 17:37

516 Glossary of Terms JavaScript Object Notation ( JSON) A lightweight data interchange approach that is relatively easy for humans to understand and for computers to generate or interpret. (12)

Joint Application Design ( JAD) A structured process in which users, managers, and analysts work together for several days in a series of intensive meetings to specify or review system requirements. (6)

Key business processes The structured, measured set of activities designed to produce a specific output for a particular customer or market. (6)

Learnability A usability dimension concerned with how difficult it is for the user to perform a task for the first time. (10)

Legal and contractual feasibility The process of assessing potential legal and contractual ramifications due to the construction of a system. (5)

Level Perspective from which a use case description is written, typically ranging from high level to extremely detailed. (7)

Level-0 diagram A DFD that represents a system’s major processes, data flows, and data stores at a high level of detail. (7)

Level-n diagram A DFD that is the result of n nested decompositions from a process on a level-0 diagram. (7)

Lightweight graphics The use of small, simple images to allow a Web page to be displayed more quickly. (10)

Logical design The part of the design phase of the SDLC in which all functional features of the system chosen for development in analysis are described independently of any computer platform. (1)

Maintainability The ease with which software can be understood, corrected, adapted, and enhanced. (14)

Maintenance The final phase of the SDLC, in which an information system is systematically repaired and improved. (1) (14)

Mean time between failures (MTBF) A measurement of error occurrences that can be tracked over time to indicate the quality of a system. (14)

Memorability A usability dimension concerned with how easy it is to remember how to accomplish a task when revising the system after a period of time. (10)

Menu interaction A human–computer interaction method in which a list of system options is provided and a specific command is invoked by user selection of a menu option. (11)

Method The implementation of an operation. (8)

Minimal guarantee The least amount promised to the stakeholder by a use case. (7)

Mission statement A statement that makes it clear what business a company is in. (4)

Multiplicity A specification that indicates how many objects participate in a given relationship. (8)

Multivalued attribute An attribute that may take on more than one value for each entity instance. (8)

Natural language interaction A human–computer interaction method whereby inputs to and outputs from a computer-based application are in a conventional spoken language such as English. (11)

Network diagram A diagram that depicts project tasks and their interrelationships. (3)

Nominal Group Technique (NGT) A facilitated process that supports idea generation by groups. At the beginning of the process, group members work alone to generate ideas, which are then pooled under the guidance of a trained facilitator. (6)

Normalization The process of converting complex data structures into simple, stable data structures. (9)

Null value A special field value, distinct from zero, blank, or any other value, that indicates that the value for the field is missing or otherwise unknown. (9)

Object class A logical grouping of objects that have the same (or similar) attributes, relationships, and behaviors; also called class. (1) (8)

Object-based interaction A human–computer interaction method in which symbols are used to represent commands or functions. (11)

Objective statements A series of statements that express an organization’s qualitative and quantitative goals for reaching a desired future position. (4)

Object-oriented analysis and design (OOAD) Systems development methodologies and techniques based on objects rather than data or processes. (1)

One-time cost A cost associated with project start-up and development or system start-up. (5)

Open-ended questions Questions in interviews that have no prespecified answers. (6)

Operation A function or a service that is provided by all the instances of a class. (8)

Operational feasibility The process of assessing the degree to which a proposed system solves business problems or takes advantage of business opportunities. (5)

Optional attribute An attribute that may not have a value for every entity instance. (8)

Outsourcing The practice of turning over responsibility for some to all of an organization’s information systems applications and operations to an outside firm. (2)

Overlap rule Specifies that an entity instance can simultaneously be a member of two (or more) subtypes. (8)

Paper prototype A series of mock screens that can be used to test content, look and feel, as well as the task flow and other usability factors. (10)

Parallel installation Running the old information system and the new one at the same time until management decides the old system can be turned off. (13)

Partial specialization rule Specifies that an entity instance of the supertype does not have to belong to any subtype. (8)

Perfective maintenance Changes made to a system to add new features or to improve performance. (14)

Personalization Providing Internet content to a user based upon knowledge of that customer. (12)

PERT (Program Evaluation Review Technique) A technique that uses optimistic, pessimistic, and realistic time estimates to calculate the expected time for a particular task. (3)

Phased installation Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system. (13)

Physical design The part of the design phase of the SDLC in which the logical specifications of the system from logical design

Z01_VALA1629_09_GE_GLOS.indd 516 08/04/2020 17:37

Glossary of Terms 517 are transformed into technology-specific details from which all programming and system construction can be accomplished. (1)

Physical file A named set of table rows stored in a contiguous section of secondary memory. (9)

Physical table A named set of rows and columns that specifies the fields in each row of the table. (9)

Planning The first phase of the SDLC in which an organization’s total information system needs are identified, analyzed, prioritized, and arranged. (1)

Platform as a service (PaaS) A cloud computing model in which the customer can run his or her own applications that are typically designed using tools provided by the service provider; the customer has limited or no control over the underlying infrastructure. (12)

Pointer A field of data that can be used to locate a related field or row of data. (9)

Political feasibility The process of evaluating how key stakeholders within the organization view the proposed system. (5)

Polymorphism The same operation may apply to two or more classes in different ways. (8)

Pool In business process modeling, a way to encapsulate a process that has two or more participants. (7)

Pop-up menu A menu-positioning method that places a menu near the current cursor position. (11)

Preconditions Things that must be true before a use case can start. (7)

Present value The current value of a future cash flow. (5)

Preventive maintenance Changes made to a system to avoid possible future problems. (14)

Primary key An attribute (or combination of attributes) whose value is unique across all occurrences of a relation. (9)

Primitive DFD The lowest level of decomposition for a DFD. (7)

Process The work or actions performed on data so that they are transformed, stored, or distributed. (7)

Project A planned undertaking of related activities to reach an objective that has a beginning and an end. (3)

Project closedown The final phase of the project management process that focuses on bringing a project to an end. (3)

Project execution The third phase of the project management process in which the plans created in the prior phases (project initiation and planning) are put into action. (3)

Project initiation The first phase of the project management process in which activities are performed to assess the size, scope, and complexity of the project and to establish procedures to support later project activities. (3)

Project management A controlled process of initiating, planning, executing, and closing down a project. (3)

Project manager A systems analyst, with a diverse set of skills— management, leadership, technical, conflict management, and customer relationship—who is responsible for initiating, planning, executing, and closing down a project. (3)

Project planning The second phase of the project management process that focuses on defining clear, discrete activities and the work needed to complete each activity within a single project. (3)

Project Scope Statement (PSS) A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project. (5)

Project workbook An online repository for all project-related documents that is used for performing project audits, orienting new team members, communicating with management and customers, identifying future projects, and performing post-project reviews. (3)

Prototyping An iterative process of systems development in which requirements are converted to a working system that is continually revised through close collaboration between an analyst and users. (6)

Query operation An operation that accesses the state of an object but does not alter the state. (8)

Rapid Application Development (RAD) Systems development methodology created to radically decrease the time needed to design and implement information systems. RAD relies on extensive user involvement, prototyping, integrated CASE tools, and code generators. (1)

Recurring cost A cost resulting from the ongoing evolution and use of a system. (5)

Recursive foreign key A foreign key in a relation that references the primary key values of that same relation. (9)

Re-engineering Automated tools that read program source code as input; perform an analysis of the program’s data and logic; and then automatically, or interactively with a systems analyst, alter an existing system in an effort to improve its quality or performance. (14)

Refactoring Making a program simpler after adding a new feature. (13)

Referential integrity A rule that states that either each foreign key value must match a primary key value in another relation or the foreign key value must be null (i.e., have no value). (9)

Relation A named, two-dimensional table of data. Each relation consists of a set of named columns and an arbitrary number of unnamed rows. (9)

Relational database model Data represented as a set of related tables or relations. (9)

Relationship An association between the instance of one or more entity types that is of interest to the organization. (8)

Repeating group A set of two or more multivalued attributes that are logically related. (8)

Report A business document that contains only predefined data; it is a passive document used solely for reading or viewing. A report typically contains data from many unrelated records or transactions. (10)

Representational State Transfer (REST) A relatively simple and fast protocol for communicating JSON data between Web service applications and the operating system. (12)

Request for proposal (RFP) A document provided to vendors that asks them to propose hardware and system software that will meet the requirements of a new system. (2)

Required attribute An attribute that must have a value for every entity instance. (8)

Resources Any person, group of people, piece of equipment, or material used in accomplishing an activity. (3)

Reuse The use of previously written software resources, especially objects and components, in new applications. (2)

Reverse engineering Automated tools that read program source code as input and create graphical and textual representations of design- level information such as program control structures, data structures, logical flow, and data flow. (14)

Rules That part of a decision table that specifies which actions are to be followed for a given set of conditions. (7)

Z01_VALA1629_09_GE_GLOS.indd 517 08/04/2020 17:37

518 Glossary of Terms Satisfaction and aesthetics A usability dimension concerned with how enjoyable a system’s visual appeal is and how enjoyable the system is to use. (10)

Scribe The person who makes detailed notes of the happenings at a Joint Application Design session. (6)

Second normal form (2NF) A relation is in second normal form if every nonprimary key attribute is functionally dependent on the whole primary key. (9)

Secondary key One or a combination of fields for which more than one row may have the same combination of values. (9)

Sequential file organization A file organization in which rows in a file are stored in sequence according to a primary key value. (9)

Service-oriented architecture (SOA) A software architecture in which business processes are broken down into individual components (or services) that are designed to achieve the desired results for the service consumer (which can be either an application, another service, or a person). (12)

Simple Object Access Protocol (SOAP) A protocol for communicating XML data between Web service applications and the operating system. (12)

Single-location installation Trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization. (13)

Slack time The amount of time that an activity can be delayed without delaying the project. (3)

Software as a service (SaaS) A cloud computing model in which a service provider offers applications via a cloud infrastructure. (12)

Source/sink The origin and/or destination of data; sometimes referred to as external entities. (7)

Stakeholder People who have a vested interest in the system being developed. (7)

State Encompasses an object’s properties (attributes and relationships) and the values of those properties. (8)

Stub testing A technique used in testing modules, especially where modules are written and tested in a top-down fashion, where a few lines of code are used to substitute for subordinate modules. (13)

Stylesheet-Based HTML A Web design approach that separates content from the way in which it is formatted and presented, making ongoing maintenance easier and site-wide consistency much higher. (10)

Subtype A subgrouping of the entities in an entity type that is meaningful to the organization and that shares common attributes or relationships distinct from other subgroupings. (8)

Success guarantee What a use case must do effectively in order to satisfy stakeholders. (7)

Supertype A generic entity type that has a relationship with one or more subtypes. (8)

Support Providing ongoing educational and problem-solving assistance to information system users. For in-house developed systems, support materials and jobs will have to be prepared or designed as part of the implementation process. (13)

Swimlane In business process modeling, a way to visually encapsulate a process. (7)

Synonym Two different names that are used for the same attribute. (9)

System documentation Detailed information about a system’s design specifications, its internal workings, and its functionality. (13)

System librarian A person responsible for controlling the checking out and checking in of baseline modules for a system when a system is being developed or maintained. (14)

System testing Bringing together of all of the programs that a system comprises for testing purposes. Programs are typically integrated in a top-down, incremental fashion. (13)

Systems analyst The organizational role most responsible for the analysis and design of information systems. (1)

Systems development life cycle (SDLC) The traditional methodology used to develop, maintain, and replace information systems. (1)

Systems development methodology A standard process followed in an organization to conduct all the steps necessary to analyze, design, implement, and maintain information systems. (1)

Tangible benefit A benefit derived from the creation of an information system that can be measured in dollars and with certainty. (5)

Tangible cost A cost associated with an information system that can be measured in dollars and with certainty. (5)

Technical feasibility A process of assessing the development organization’s ability to construct a proposed system. (5)

Ternary relationship A simultaneous relationship among instances of three entity types. (8)

Testing harness An automated testing environment used to review code for errors, standards violations, and other design flaws. (13)

Thin client A client device designed so that most processing and data storage occur on the server. (12)

Third normal form (3NF) A relation is in second normal form and has no functional (transitive) dependencies between two (or more) nonprimary key attributes. (9)

Three-tiered client/server architecture Advanced client/ server architectures in which there are three logical and distinct applications—data management, presentation, and analysis—that are combined to create a single information system. (12)

Time value of money (TVM) The concept that money available today is worth more than the same amount tomorrow. (5)

Top-down planning A generic information systems planning methodology that attempts to gain a broad understanding of the information systems needs of the entire organization. (4)

Total cost of ownership (TCO) The cost of owning and operating a system, including the total cost of acquisition, as well as all costs associated with its ongoing use and maintenance. (5)

Total specialization rule Specifies that each entity instance of the supertype must be a member of some subtype of the relationship. (8)

Trigger Event that initiates a use case. (7)

Triggering operation (trigger) An assertion or rule that governs the validity of data manipulation operations such as insert, update, and delete; also called a trigger. (8)

Unary relationship A relationship between instances of one entity type; also called recursive relationship. (8)

Unit testing The process of testing each module alone in an attempt to discover any errors in its code. (13)

Update operation An operation that alters the state of an object. (8)

Usability An overall evaluation of how a system performs in supporting a particular user for a particular task. (10)

Use case A depiction of a system’s behavior or functionality under various conditions as the system responds to requests from users. (7)

Use case diagram A picture showing system behavior, along with the key actors that interact with the system. (7)

User documentation Written or other visual information about an application system, how it works, and how to use it. (13)

Z01_VALA1629_09_GE_GLOS.indd 518 08/04/2020 17:37

Glossary of Terms 519 Utility computing A form of on-demand computing where resources in terms of processing, data storage, or networking are rented on an as-needed basis. The organization only pays for the services used. (12)

Virtual machine A software emulation of a physical computer system, both hardware and operating system, that allows more efficient sharing of physical hardware resources. (12)

Virtualization The act of creating virtual (rather than physical) versions of a variety of computing capabilities including

hardware platforms, operating systems, storage devices, and networks. (12)

Walk-through A peer group review of any product created during the systems development process; also called a structured walk-through. (5)

Web service A method of communication between two electronic devices over a network. (12)

Well-structured relation A relation that contains a minimum amount of redundancy and that allows users to insert, modify, and delete the rows without error or inconsistencies; also known as a table. (9)

Wireframe A simple design to show the placement of information elements on a screen and the space needed for each element. (10)

Work breakdown structure The process of dividing the project into manageable tasks and logically ordering them to ensure a smooth evolution between tasks. (3)

Z01_VALA1629_09_GE_GLOS.indd 519 08/04/2020 17:37

Glossary of Acronyms 2NF Second Normal Form

3NF Third Normal Form

API Application Program Interface

ASP Application Service Provider

BEA Break-Even Analysis

BEC Broadway Entertainment Company, Inc.

BIND Berkeley Internet Name Domain

BPMN Business Process Modeling Notation

BPP Baseline Project Plan

BPR Business Process Re-engineering

BSP Business Systems Planning

CASE Computer-Aided Software Engineering

CERT/CC Computer Emergency Readiness Team/Coordination Center

CIO Chief Information Officer

CMS Content Management System

COCOMO Constructive Cost Model

CSS Cascading Style Sheet

CTS Customer Tracking System

DBMS Database Management System

DFD Data Flow Diagram

DOS Disk Operating System

EDW Enterprise Data Warehouse

EECT Earliest Expected Completion Time

EER Extended Entity Relationship

EF Early Finish

ER Entity Relationship

ERP Enterprise Resource Planning

ET Estimated Time

GUI Graphical User Interface

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IaaS Infrastructure as a Service

IDS Intrusion Detection Software

IE Information Engineering

I/O Input/Output

IP Internet Protocol

IS Information Systems

ISP Internet Service Provider

IT Information Technology

JAD Joint Application Design

JSON JavaScript Object Notation

LAN Local Area Network

LDM Logical Data Model

LECT Latest Expected Completion Time

LF Late Finish

MIS Management Information Systems

MTBF Mean Time Between Failures

NGT Nominal Group Technique

NPV Net Present Value

ODBC Open Database Connectivity

OLAP Online Analytical Processing

OLTP Online Transaction Processing

OOAD Object-Oriented Analysis and Design

PaaS Platform as a Service

PDA Personal Digital Assistant

PE Petrie Electronics

PERT Program Evaluation Review Technique

PIP Project Initiation and Planning

POS Point-of-Sale

PSS Project Scope Statement

PVF Pine Valley Furniture

RAM Random Access Memory

REST Representational State Transfer

RFP Request for Proposal

RFQ Request for Quote

ROI Return on Investment

RUP Rational Unified Process

SaaS Software as a Service

SAP Systems, Applications, and Products

SDLC Systems Development Life Cycle

SNA System Network Architecture

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SPTS Sales Promotion Tracking System

SQL Structured Query Language

SSR System Service Request

SysML Systems Modeling Language

TVM Time Value of Money

UML Unified Modeling Language

WBS Work Breakdown Structure

WML Wireless Markup Language

XML eXtensible Markup Language

XSL eXtensible Stylesheet Language

520

Z02_VALA1629_09_GE_ACRO.indd 520 08/04/2020 17:38

521 521

A Abstract class, 307 Abstract operation, 308–309 Acceptance testing, 473–474 Access, Microsoft, 305, 324, 350 Action stubs, 223 Activity, in business process modeling, 258 Activity diagrams, 252–255 Actor, in use case, 238–239 Adaptive maintenance, 498 Ad-hoc reports, 365 Ad hoc reuse, 59–60 Advertising, 451–453 Aesthetics and satisfaction, 383 Affinity clustering, 124 Aggregation, 309–310 Agile methodologies

advantages of, 38–39 Agile Usage-Centered Design, 192–193 analysis–design–code–test loop, 35–36, 44, 191–192 continual user involvement, 191–192 development of, 28, 38–39 eXtreme programming, 39–41, 192–194, 473 manifesto for, 38 Planning Game, 192–194 in practice, 41–42 in requirements determination, 191–194 Scrum, 40–41 traditional approaches versus, 39, 40

Agile Usage-Centered Design, 192–193 Airbnb, 436–437 Alpha testing, 473, 488–489 Amazon Web Services (AWS), 436–437, 438 Analysis. See also Data requirements structuring;

Object-oriented analysis and design; Requirements determination

analysis–design–code–test loop, 35–36, 44, 191–192 analysis phase, 33, 35 break-even, 144–145 cost–benefit, 78–79, 137 DFDs in, 219–223 gap, 221 matrix, 124 of procedures and documents in requirements

determination, 178–183 value chain, 112–113 weighted multicriteria, 114

Analysis–design–code–test loop, 35–36, 44, 191–192 Application program interface (API), 432 Application server, 433 Application software, 27–28, 29, 34, 47, 501.

See also Software Artificial intelligence, 399–400 Association, of object classes, 303–305 Associative classes, 305–306 Associative entities, 345–346 Attributes

class-scope, 308 in database design, 324, 329, 341 in E–R modeling, 274–276 stereotypes represented for, 306

AWS (Amazon Web Services), 436–437, 438 Axure, 366 Azure, 53, 439

B Back-end applications, 432 Balancing, 214–216 Basel II, 343 Baseline modules, 505 Baseline Project Plan (BPP)

deliverables and outcomes, 135–136 feasibility assessment in, 153 introduction and outline, 149–151 management issues in, 153 presentation of, 158 project execution and, 79–82 reviewing, 154–158 system description in, 151–152

BEA (break-even analysis), 144–145 BEC (Broadway Entertainment Company), 63 Beck, Kent, 38, 192, 473 Behavior, of an object, 301–302 Benefit

in cost–benefit analysis, 78–79, 137 tangible versus intangible, 137, 139–140

Berkeley Internet Name Domain (BIND), 445 Beta testing, 474, 488–489 Bill-of-materials structure, 280 Binary relationships, 280, 333–336 BIND (domain naming system), 445 Blended learning, 480–481 Boeing, 191 Bookmarks, customer, 449 Bottom up approach, 271–272 Bottom-up planning, 120 Bottom-up source, 112, 115, 120 BPP. See Baseline Project Plan BPR. See Business Process Reengineering Break-even analysis (BEA), 144–145 Broadway Entertainment Company (BEC), 63 Budget, preliminary, 78–79 Bug tracking, 488 Build routines, 505 Business case, 135, 137 Business forms, 180–181 Business process modeling, 257–261 Business Process Modeling Notation (BPMN),

257–261 Business Process Reengineering (BPR)

DFDs in, 222–223 overview, 168 in requirements determination, 188–190

Business rules, 286–289 Business Systems Planning, 120 Business-to-Business (B2B), 27, 126 Business-to-Consumer (B2C), 126 Business-to-Government (B2G), 126

C Calculated fields, 343 Candidate keys, 275–276

Cardinality, 281–282 Cascading Style Sheets (CSSs), 446–447 CASE. See Computer-aided software engineering Case, in formatting, 375 China, 49 Chrome Web browser, 413 Clam level use cases, 243–244 Class diagramming

aggregation in, 309–310 associations in, 303–305 associative classes in, 305–306 attribute stereotypes in, 306 definitions, 301–302 examples, 267, 302 generalization in, 306–309 for Hoosier Burger, 310–313 operation types, 302–303

Class-scope attribute, 308 Class-scope operation, 303 Class/subclass relationships, 338 Client, 432, 435 Client/server architecture

definition, 431 distributed and Internet systems design for,

431–435 LAN systems design, 429–431 three-tiered, 433

Closed-ended questions, 173, 175 Closedown, 82–83, 489–490 Cloud characteristics

broad network access, 437 infrastructure as a service, 438 measured service, 438 on-demand self-service, 437 platform as a service, 438–439 private versus public, 439 rapid elasticity, 437 resource pooling, 438 service models, 438 software as a service, 439

Cloud computing, 435–444 characteristics of, 437–438 cloud management, 439–442 cloud types, 439 definition of, 53 information systems infrastructure and, 435 overview of, 435–437 security in, 54 service models, 438–439 service-oriented architecture, 442–443 software applications from, 52–54, 55 Web services, 443–444

Cloud managing, 439–442 availability/reliability, 440 costs, 442 diversity of offerings, 441 openness, 441–442 scalability, 440 security, privacy, and compliance, 441 viability and stability, 440

CMS (content management system), 450–451

Index

Z03_VALA1629_09_GE_IDX.indd 521 15/04/2020 12:04

522 Index COBIT (Control Objectives for Information and

Related Technologies), 343 COCOMO (COnstructive COst MOdel), 76 Coding

in agile methodologies, 40 in analysis–design–code–test loop, 35–36, 44,

191–192 code control tools, 505 code walk-through, 468–469 in database design, 324, 342–343, 352 in implementation, 34 in OOAD, 43 sheets, 366–367 testing combined with, 472–473

Color, 374–375 Command language interaction, 393 Communication plan, 77–78, 81–82, 153–154 Competitive strategy, 118–119 Complete keyword, 308 Completeness, DFD, 219 Component-based development, 58 Composite attribute, 277 Composite partitioning, 345 Composition, 309–310 Compression techniques, 343 Computer-aided software engineering (CASE)

business rules and, 289 in conceptual data modeling, 267, 278 in systems analysis and design, 29–30 tools, 29–30

Conceptual data modeling associative entities, 283–285 cardinalities in relationships, 281–282 in CASE, 267, 278 in data requirements structuring, 267–270,

278–285 definition of, 267–268 deliverables and outcomes, 269–270 in electronic commerce, 291–295 E-R model and, 278–285 gathering information for, 270–272 for Hoosier Burger, 310–313 naming and defining relationships, 282–283 packaged models for databases, 290–291 process overview, 268–269 for PVF, 271–272, 291–295 relationship degree, 279–281

Concrete class, 307 Condition stubs, 223 Configuration management, 505 Connections, in use cases, 239 Consistency

in DFDs, 220 in distributed and Internet systems design,

446–448 in forms and reports, 381 in menus, 397

Constantine, Larry, 192 Constraints, 114–115, 123, 125 COnstructive COst MOdel (COCOMO), 76 Constructor operation, 302 Consumer-to-Consumer (C2C), 126 Content management system (CMS), 450–451 Context, in form and report design, 381–382 Context diagram, 207–208 Context-level data flow diagram, 153 Continual user involvement, 191–192 Contract, closing of, 83 Cookie crumbs, 421–422 Corporate restructuring, 427 Corporate strategic planning, 117–119

Corrective maintenance, 498 Cost

capital, 142 maintenance, 499–501 one-time versus recurring, 141 preliminary budget, 78–79 software, 56 tangible versus intangible, 139–140 total, of ownership, 141

Cost–benefit analysis, 78–79, 137. See also Economic feasibility

Costello testing harness, 472 Critical path, 88–89, 90 Critical path scheduling, 85, 88–89 Critical success factors, 117 CSSs (Cascading Style Sheets), 446–447 Customer bookmarks, 449 Customer information, 196 Customer loyalty, 448–449 Customer loyalty project. See Petrie Electronics Customer relationship management, 70, 439 Customization, 448

D Data. See also Conceptual data modeling; Data

flow diagram; Data requirements structuring audit trails, 408 in database design, 324–325, 343–344 data entry structure, 405–407 data stores, 206, 211 errors, 407–408 flow, 205–206, 211 input control, 407–408 integrity controls, 343–344 redundancy, 116 reference, 346–347 relations, 327 stores, 206, 211 type, 323, 342–343

Database engine, 432 management of, 29, 321–322, 408, 432 packaged data models for, 290–291 relational, 322, 350

Database design, 321–357 data integrity control in, 343–344 data types in, 342–343 deliverables and outcomes, 324–327 electronic commerce application, 353–356 E-R diagrams transformed into relations in,

331–336 fields designed in, 341–342 file controls in, 351–352 for Hoosier Burger, 338–341, 352–353 introduction to, 321–322 logical, 321, 323, 325 merging relations in, 336–338 normalization and, 328–331 for Petrie Electronics, 361–362 physical, 321, 322–324, 352–353 physical file, 347–351 physical tables in, 344–347 process of, 322–324 purposes of, 321 for PVF, 324, 353–356 relational model, 322, 324, 327–328, 350 steps of, 321–322 storage technologies, 321, 324 summary, 356–357 table rows in, 347–351, 377

technical file and, 321 well-structured relations, 327–328

Data Entity-to-Function matrix, 123 Data Entity-to-Information System matrix, 122 Data flow diagram (DFD)

in analysis process, 219–223 balancing, 214–216 in business process reengineering, 222–223 completeness, 219 consistency, 220 data modeling and, 269–270 decomposition of, 211–214, 220–221 definitions and symbols, 205–207 description of, 203–204 development example, 207–210 flowchart versus, 205 in gap analysis, 221 Hoosier Burger example, 216–219 iterative development, 220 level-0 diagram, 209, 211, 214–215, 217–218, 220 level-n diagram, 213–215 primitive, 211, 220–221 in process modeling, 204–205 rules for diagramming, 210–211, 212, 216,

219–221 timing, 220

Data requirements structuring, 266–313. See also Conceptual data modeling; Entity–relationship data model

conceptual data modeling, 267–270, 277–285 data gathering for, 270–272 data model importance, 266–267 E-R diagramming, 269–270 introduction, 266–267 PVF example, 271–272 summary, 295, 313

Deadlines, 37 Decision tables

definition of, 311 Hoosier Burger, 310–312 logic modeling with, 223–227 rules, 223–224

Decomposition, functional, 211–214 Default value, 343 Degree of a relationship, 279, 304 Deliverables

in Baseline Project Plan, 135–136 in conceptual data modeling, 269–270 in database design, 324–327 definition of, 66–67 in distributed and Internet systems design,

428–429 in form and report design, 366–370 in identification and selection of projects, 115–116 in implementation, 465–467 in interface and dialogue design, 392 in process modeling, 204–205 in project initiation and planning, 135–136 in requirements determination, 171–172 in system maintenance, 497

DeMarco and Yourdon symbol set, 206–207 Denormalization, 345–347, 353 Department of Justice SDLC, 32 Derived attribute, 277 Design. See also Database design; Distributed and

Internet systems design; Form and report design; Interface and dialogue design

in analysis–design–code–test loop, 35–36, 44, 191–192

logical, 32, 33 phase, 32, 35

Z03_VALA1629_09_GE_IDX.indd 522 15/04/2020 12:04

Index 523 physical, 33–34 specifications, 367–370, 393

Designed reuse, 60 Design recovery tools, 506 Desk checking, 469 DFD. See Data flow diagram Dialogue box (pop-up menu), 396–397 Dialogue diagramming, 414–415 Dialogues. See also Interface and dialogue design

definition of, 412 design guidelines, 412–413, 414 diagramming, 414–415, 416 in electronic commerce, 419–422 in graphical interface design, 419 prototypes and usability assessment, 415–416 sequence design, 413–415

Direct installation, 474 Directly observation, 177–178, 183 Discount rate, 142 Disjoint keyword, 308 Disjoint rule, 286 Disruptive technologies, 190–191 Distributed and Internet systems design, 427–454.

See also Cloud computing advertising, 451–453 client/server architecture, 431–435 consistency in, 446–448 deliverables and outcomes, 428–429 “distributed” meaning, 427 in electronic commerce, 451–453 Internet system design fundamentals, 445–446 introduction to, 427 LANs and, 429–431 management in, 448–451 for Petrie Electronics, 459–460 process of, 427–428 PVF advertisement server, 451–453 single-location systems versus, 427–428 summary, 454

Doctor HTML, 507 Documentation

implementation, 477–479 quality, 500, 502 software, 56–57, 500 user, 477, 478–479

Domain naming system (BIND), 445 Domains, 287–288 Double-confirmation technique, 413 Drill-down reports, 365 Drop-down menu, 396–397

E EC. See Electronic commerce Economic feasibility. See also Feasibility assessment

benefits determination, 137, 139 break-even analysis, 144–145 definition of, 137 project costs determination, 139–142, 159–160 time value of money, 142–145

Efficiency, 382 Elastic Compute Cloud (EC26), 436 e-learning, 480–481 Electronic commerce (EC). See also Pine Valley

Furniture (PVF) WebStore conceptual data modeling example, 291–295 database design application, 353–356 definition, 126 distributed advertisement server, 451–453 form and report design for, 383–385 implementation application, 487–489

interface and dialogue design, 419–422 maintenance of information system in, 508–509 process modeling example, 227–228 project identification and selection, 126–127 project initiation and planning, 159–160 requirements determination for, 194–197 use case diagramming for, 245–247 written use case for, 247–249

Encapsulation, 302 Enterprise resource planning (ERP) systems

in identifying projects, 109 logical data models for, 291 maintenance for, 500 software for, 50, 52, 55–57

Entity class, 272–274, 332, 336 Entity instance, 273–274 Entity–relationship diagram (E–R diagram), 272,

331–336 Entity–relationship data model (E–R model), 267

associative entities, 283–285 attributes, 274–276 business rules, 286–289 candidate keys and identifiers, 275–276 conceptual data modeling and, 269–270,

278–285 definition of, 272 entities in, 272–274 for Hoosier Burger, 338–339 notation for, 272–273 relationships, 277–278, 279–283 representing supertypes and subtypes, 285–286 transformed into relations, 331–336

Entity type, 272–274, 332, 336 E–R model. See Entity–relationship data model ERP (enterprise resource planning) systems. See

Enterprise resource planning (ERP) systems Errors

in data input, 407–408 error messages, 410 error rate, 382 in syntax, 469

Event, in business process modeling, 258 Evolutionary prototyping, 187, 196 Exception reports, 365 Execution, project, 79–82 Expected time durations, 85–86 Extend relationship, 239–240 eXtensible Markup Language (XML), 443–444, 447 eXtensible Stylesheet Language (XSL), 446–448 Extensions, 244 eXtreme Programming (XP), 39–41, 192–194, 473

F Facilitated reuse, 59–60 Failure, in implementation, 483–485 Feasibility. See also Feasibility assessment

economic, 137, 139–145, 159–160 legal and contractual, 148–149 operational, 148 political, 149 schedule, 148 technical, 145–148

Feasibility assessment in Baseline Project Plan, 153 definition of, 67 economic feasibility, 137–145 factors in, 136–137 in initiation and planning phase, 134 legal and contractual feasibility, 148–149 operational feasibility, 148

political feasibility, 149 for PVF, 67, 74, 159–160 schedule feasibility, 148, 160 technical risk assessment, 145–148

Feedback, in interface and dialogue design, 408–410

Fields calculated, 343 design of, 341–343

File organization, 323, 348–351 File restoration, 351–352 File servers, 429–431, 433 Firewalls, 486 Flexibility, software, 56 Flow, in business process modeling, 258–260 Foreign keys, 331, 335, 350 Formal systems, 180 Form and report design, 363–385

data integrity rules, 384–385 deliverables and outcomes, 366–370 design specifications, 367–370 electronic commerce application, 383–385 formatting, 370–381, 384 introduction to, 363–365 paper versus electronic reports, 379–381 for Petrie Electronics, 389–390 process of, 365–366 for PVF WebStore, 383–385 summary, 385 usability assessment, 381–383

Formatting. See also Form and report design color versus no color, 374–375 displaying text, 375–376 general guidelines, 370–372 highlighting information, 372–374 table and list design, 375–379

Forms. See also Form and report design business, 180–181 color in, 374–375 definition of, 364 electronic, 383–385 interaction, 399 paper, 402–404 review, 155–156

Free slack, 89 Front-end applications, 432 Functional decomposition, 211–214 Functional dependency, 329 Functionality, software, 56 Function key assignments, 394 Function-to-Data Entity matrix, 122 Function-to-Objective matrix, 122 Function-to-Process matrix, 122

G G2B (Government-to-Business), 126 G2C (Government-to-Citizen), 126 Gane and Sarson symbol set, 206–207 Gantt chart

in feasibility assessment, 153 network diagrams versus, 83–84 in project execution, 80 in project planning, 74–75, 86–89 in reviewing project progress, 92

Gap analysis, 221 Gateway, in business process modeling, 258 General Electric payroll system, 47 Gerund (associative entity), 283–285 Google Advanced Search Engine, 399 Government-to-Business (G2B), 126

Z03_VALA1629_09_GE_IDX.indd 523 15/04/2020 12:04

524 Index Government-to-Citizen (G2C), 126 Graphical interface design (GUI), 417–419 Graphical user interface (GUI), 417–419 Graphics tablet, 401–402 Graphs, formatting, 378–379 Group interviews, 176–177 GUI (graphical interface design), 417–419

H Hacking, 485–486 Hard problem completion, 98–100 Hashed file organization, 349, 351 Hash partitioning, 345 Health Insurance Portability and Accountability

Act (HIPAA), 441 Help

in cloud management, 440 data entry fields, 406 in implementation, 478–479 in interface and dialogue design, 410–412, 413 screen design, 376, 394 types of, 412 in user support, 482

Help desk, 482 Hierarchies, menu, 394–396 Highlighting, 372–374, 397 HIPAA (Health Insurance Portability and

Accountability Act), 441 Homonyms, 337–338 Hoosier Burger

conceptual data modeling, 310–313 database design, 338–341, 352–353 decision tables for, 225–227 DFD example of, 207–210 DFD of food ordering, 207–210, 211–216 DFD of inventory system, 216–219 logical database design for, 338–341 physical database design for, 352–353 use case diagram for, 241–242

HPE (company), 50–51 HTTP. See Hypertext Transfer Protocol Hypertext Markup Language (HTML)

definition of, 445 LINK command, 446, 447 stylesheet-based, 385 validation, 507 in Web services, 444

Hypertext Transfer Protocol (HTTP), 445 Hyphenation, in formatting, 375

I IaaS (infrastructure as a service), 438 IBM, 49–50, 53, 269 IBM Credit Corporation, 222–223 Icons, 399 Identification and selection of projects, 109–132

classifying and ranking, 112–113 corporate strategic planning and, 117–119 deliverables and outcomes, 115–116 for electronic commerce, 126–127 identifying potential projects, 109–111 importance of, 116–117 information systems planning, 119–125 selecting, 113–115

Identifiers, 276 Identity, of objects, 301 IE (Information Engineering), 120 Impartiality, 170 Impertinence, 170 Implementation, 463–490

activities in, 464–465 coding in, 34 deliverables and outcomes, 465–467 documenting the system, 466–467 electronic commerce application, 487–489 failure of, 483–485 help in, 478–479 installation, 474–477 introduction to, 463–464 master test plan, 467–468 overview, 464–467 at Petrie Electronics, 494 phase of, 34–35, 463 project closedown and, 489–490 at PVF, 487–489 reasons for failure, 483–485 security issues, 485–487 software application testing, 467–474, 487–488 stages of, 197 summary, 490 system documentation, 477–479 training and supporting users, 464, 466–467,

479–482 user’s guide, 478–479

Inception phase, 101–102 Include relationship, 240–242 Incomplete keyword, 308 Incremental commitment, 115, 158 Index, 348, 350, 353 Indexed file organization, 348–351 India, 49 Indifferent condition, 224 Industry-specific data models, 290 Informal systems, 180 Information Engineering (IE), 120 Information systems analysis and design,

27–28, 44. See also Systems development Information systems infrastructure, 435 Information systems maintenance. See

Maintenance Information systems planning (ISP), 119–125

definition of, 119 describing target situation, trends, and

constraints, 123–124 describing the current situation, 120–123 developing transition strategy and plans, 124–125 matrix analysis, 124 matrix types in, 122–123 outline of, 125 three-step process in, 119–120

Information System-to-Objective matrix, 122 Information technology (IT), 27, 48, 49–50 Infrastructure as a service (IaaS), 438 Inheritance, definition of, 42 Initiation. See Project initiation and planning Inspections, 468–469 Installation, 34, 474–477, 489 Intangible benefits, 139, 140 Intangible cost, 139–140 Integration problems, 337–338 Integration testing, 470 Interaction menus, 393–399 Interaction methods and devices, 392–402

command language interaction, 393 form interaction, 399 hardware options for, 400–402 menu interaction, 393–399 natural language interaction, 399–400 object-based interaction, 399

Interface, definition of, 392 Interface and dialogue design, 391–422

data entry design, 405–407 data input control, 407–408 deliverables and outcomes, 391 dialogue prototype and usability, 415–416 dialogue sequence, 412–415 electronic commerce application, 419–422 feedback provision, 408–410 in graphical environments, 417–419 help provision, 410–412 interaction methods, 392–400 interface design, 402–412 introduction, 391 layout design, 402–405 for Petrie Electronics, 425–426 process of, 391 for PVF, 419–422 summary, 422

Internet. See also Distributed and Internet systems design

basics, 126–127 definition, 126 incorporation of, 27–28 naming standards on, 445 ongoing evolution of, 445–446

Internet of “Everything”, 126–127 Internet-of-Things (IoT), 126 Internet systems design

content management systems, 450–451 customer loyalty and trustworthiness, 448 design fundamentals, 445–446 link permanence, 449 site consistency, 446–448 site management and, 448–451 system security, 449–450

Interviewing groups, 176–177 guidelines for, 172–173, 174–175 questions for, 173, 175 writing up notes, 175

Intranet, 68, 78, 154 Inventory information, WebStore, 196 Invoice, 181 IoT (Internet-of-Things), 126 ISP. See Information systems planning IS steering committee, 132 IT (information technology), 27, 48, 49–50 Iterative development, 98, 100–102, 220 ITIL (IT Infrastructure Library), 343 IT services firms, 49–50

J JAD, 184–186, 195–197 JavaScript Object Notation ( JSON), 444 J. Lyons & Sons, 47 Joint Application Design ( JAD), 184–186, 195–197 Joystick, 401–402 JSON ( JavaScript Object Notation), 444 Justice Department SDLC, 32 Justification, in formatting, 375

K Keyboards, 400–402 Key business processes, 189–190 Key-indicator reports, 365 Kia Motors, 118–119

L Labeling, 377 LAN, 429–431. See also Client/server architecture Layout, 195, 402–405

Z03_VALA1629_09_GE_IDX.indd 524 15/04/2020 12:04

Index 525 LDM (logical data model), 290–291 Learnability, 382 Legal and contractual feasibility, 148–149 Level, in written use cases, 243–244 Level-0 diagram, 209, 211, 214–215, 217–218, 220,

292 Level-n diagram, 213–215 Librarian, 505 Light pen, 401–402 Lightweight graphics, 384 LinkAlarm, 507 Linux, 54 Listening, 172, 175–176, 244 List formatting, 375–379 Local area network (LAN), 429–431. See also

Client/server architecture Location (single-location) installation, 475–476 Location-to-Function matrix, 122 Location-to-Unit matrix, 122 Locking, 507 Logical database design. See Database design Logical data model (LDM), 290–291 Logical design, 33 Logic modeling with decision tables, 223–227 Long-term planning, 124, 127 Lopez, Juanita, 66, 68 Low-cost producer strategy, 118 Loyalty, 448–449 Lucas, H. C., 484

M Maintainability, 500–501 Maintenance of information systems, 495–510

automated development tools in, 506 configuration management, 505 controlling requests for, 503–505 cost of, 499–501 definition of, 498 deliverables and outcomes, 497 in electronic commerce, 508–509 introduction to, 495 maintenance phase, 34–35 management of, 501–505 measurement of effectiveness, 502–503 personnel for, 500–502 process of, 496–497 in PVF, 508–509 summary, 509 System Service Request in, 66–67, 113, 496–497 types of, 498–499 Website maintenance, 506–507

Maintenance oracle, 155 Maintenance phase, 34–35 Malaysia, 49 Malware, 485 Managed reuse, 60 Management Issues, 153 Mandatory cardinality, 281 Mandatory participants, 281 Many-to-many relationship, 345–347 Margins, in formatting, 375 Martin, Chris, 66, 68 Master test plan, 467–468 Matrices

communication, 153–154 planning, 122–124 risk, 147 task responsibility, 154 VisualBasic.NET for building, 398–399

Matsutoya Corporation, 63

Maximum cardinality, 281–282 Mean time between failures (MTBF), 502–503 Memorability, 383 Menus

configurations, 395 consistency in, 397 drop-down, 396–397 hierarchies, 394–396 interaction, 393–399 ribbon, 394 system, 419

Merge, 252 Method, 308–309 Methodologies, 28. See also Agile methodologies Microsoft

Access, 305, 324, 350 Azure, 53, 439 Office, 305, 350, 361 packaged software from, 50–51 PowerPoint, 158, 394, 481 Project, 84, 85, 86, 90–92 Snipping tool, 400 Visio, 269, 272, 275, 283–284, 318 Visual Basic.NET, 366, 368, 398, 415 Word, 478

Middleware, 433–434 Minimal guarantee, 244 Minimum cardinality, 281–282 Mission statement, 117 Modality, 419 Module testing, 470 Mouse, 401–402 MTBF (mean time between failures), 502–503 Multiplicity, 303 Multivalued attribute, 276–277

N Natural language interaction, 399–400 Navigation

characteristics, 195 cookie crumbs in, 421–422 in form and report design, 370, 402, 404–405

Nearshoring, 49 NetBeans IDE, 507 Netflix, 438 Net present value (NPV), 143–145 Network diagram

description of, 76–77 in estimating time requirements, 85–89 in Feasibility Assessment, 153 Gantt charts versus, 83–84 in reviewing project progress, 92

Network diagrams in, 76–77, 83–84, 85–86 Niche strategy, 118 Nominal Group Technique (NGT), 176–177 Nonkeys, dependencies in, 338, 345–346, 350 Normalization

database design and, 322–323 denormalization, 345–347, 353 E–R diagrams and, 332, 336 functional dependency in, 329 physical tables and, 344 rules of, 329 second normal form, 330 third normal form, 330–331

Normalized relations, 324 Normalized tables, 321 NPV (net present value), 143–145 n-tiered architecture, 433 Null value, 344

O Object, 42, 301–302 Object-based interaction, 399 Object class (class), 301–305 Objective statements, 117–118 Object Management Group (OMG), 257 Object modeling

aggregation in, 309–310 associations in, 303–305 associative classes in, 305–306 attribute stereotypes, 306 definitions, 301–302 generalization in, 306–309 operation types, 302–303 summary, 313

Object-oriented analysis and design (OOAD). See also Use cases

activity diagrams, 252–255 class diagrams, 301–313 defining system as set of components, 98 description of, 42–44 evolving activity focus in, 102–103 hard problems completed first, 98–99 object modeling, 301–313 project management, 98–103 reuse of, 58

Observation, 177–178, 183 Office, Microsoft, 305, 350, 361 Off-the-shelf software producers, 50–52, 55 OMG (Object Management Group), 257 One-time costs, 141 One-to-one relationship, 345, 347 Online support forums, 481 OOAD. See Object-oriented analysis and design OOSAD. See Object-oriented analysis and design Open-ended questions, 173 Open-source software, 54, 55 Operational feasibility, 148 Operations, 301–303 Optional attribute, 277 Optional cardinality, 281–282 Optional participant, 281, 283 Oracle, 50, 52, 109, 275, 322, 342, 345, 350 Outback Steakhouse, 439 Outcomes

in Baseline Project Plan, 135–136 in conceptual data modeling, 269–270 in database design, 324–327 in distributed and Internet systems design,

428–429 in form and report design, 366–370 in identification and selection of projects,

115–116 in implementation, 465–467 in interface and dialogue design, 392 in process modeling, 204–205 in project initiation and planning, 135–136 in requirements determination, 171–172 for system maintenance, 497

Outsourcing, 48–49 Overlapping keyword, 307 Overlap rule, 286

P PaaS (platform as a service), 438–439 Packaged conceptual data models, 290–291 Packaged software producers, 50–52, 55 Paper forms, 402–404 Paper prototype, 366 Parallel installation, 474–475

Z03_VALA1629_09_GE_IDX.indd 525 15/04/2020 12:04

526 Index Partial specialization rule, 286 Partitioning, 345 Passwords, 449–450, 486–487 Patton, Jeff, 192 Payment Card Industry Data Security Standard,

441 PeopleSoft, Inc., 52 Perfective maintenance, 498–499 Performance testing, 473 Personalization, 448–449 PERT (Program Evaluation Review Technique),

85–86 Petrie Electronics

database design, 361–362 distributed and Internet systems design,

459–460 form and report design, 389–390 identifying and selecting systems development

projects, 132 information systems project management, 105 initiating and planning systems development

projects, 165–166 interface and dialogue design, 425–426 introduction, 63 origins of software, 63 requirements determination, 201–202 structuring system data requirements, 316–318 structuring system process requirements,

264–265 system implementation, 494

Phased installation, 475, 476 Phoenix, 483 Physical database design, 321, 322–324, 352–353 Physical design, 33–34 Physical file, 347–351 Physical tables, 344–347 Pilot (single-location) installation, 475–476 Pine Valley Furniture (PVF). See also Pine Valley

Furniture (PVF) WebStore background and organization, 64–66 Baseline Project Plan for, 151–152 conceptual data model for, 271–272, 291–295 corporate mission statement, 117 database design, 324, 353–356 Data Entity-to-Function matrix, 123 data gathering for data modeling, 271–272 data requirements structuring, 271–272 dialogue design, 413–415 distributed and Internet systems design,

451–453 feasibility assessment for, 137–139, 141–144 form and report design for, 368–369, 371–372,

383–385 Gantt chart and network diagram for, 86–89 information systems planning information,

121–122 interface and dialogue design, 419–422 maintenance of information system for,

508–509 project charter, 72, 73 project execution, 79–81 project initiation, 70–72 project management for, 66–68 project planning, 74–79 project workbook, 71–72 requirements determination, 195–197 scheduling, 160 SSR for a purchasing fulfillment system, 66–68 statement of objectives, 118 system implementation and operation, 487–489 technical risk assessment, 147–148

test case, 471–472, 487–489 use case diagram for, 245–247 walk-through, 155–157 written use case for, 247–249

Pine Valley Furniture (PVF) WebStore conceptual data modeling, 291–295 distributed advertisement server for, 451–453 electronic commerce exploration, 127 form and report design, 383–385 initiating and planning projects, 159–160 interfaces and dialogues design, 419–422 maintaining information system, 508–509 process modeling for, 227–228 process modeling using DFD, 227–228 process modeling using use cases, 245–249 system implementation and operation, 487–489 system requirements determination, 195–197

PIP. See Project initiation and planning Planning. See also Baseline Project Plan; Project

initiation and planning bottom-up, 120 business systems planning, 120 communication plan, 77–78, 81–82, 153–154 elements of, 135–136 ERP systems, 50, 52, 55, 57, 109, 291 information systems planning, 119–125 long-term, 124, 127 phase, 32–33, 35 presentation, 158 resources for, 75–76 short-term, 124–125 summary, 128 top-down, 120–121

Planning Game, 192–194 Platform as a service (PaaS), 438–439 Pointer, 348, 350 Political feasibility, 149 Polymorphism, 308–309 Pool, in business process modeling, 260–261 Pooling ideas, 176–177 Pop-up menu, 396–397 Porter, Michael, 118 Postproject reviews, 83 PowerPoint, 158, 394, 481 Preconditions, in written use cases, 244 Preliminary investigation, 33 Presentations, 158 Present value, 142–143 Preventive maintenance, 499 Primary key, 324, 327, 328, 350–351 Primitive DFD, 211, 220–221 Printers, 379–381 Privacy, in cloud computing, 441 Procedures

analysis of, in requirements determination, 178–183

in project initiation and planning, 78, 153 Project Standards and Procedures, 78, 153 work, 168–169

Process, 206 Process modeling

BPMN example, 261 Business Process Modeling Notation, 257–261 decision tables, 223–227 deliverables and outcomes, 204–205 DFD balancing, 214–216 DFD decomposition, 211–214 DFD development example, 207–210 DFD diagramming rules, 210–211 DFD example, 207–210 DFD mechanics in, 205–207

electronic commerce application, 227–228 for structured analysis, 204 summary, 229, 262

Process requirements structuring. See also Process modeling

in the analysis process, 219–223 data flow diagramming example, 216–219 data flow diagramming mechanics, 204–216 decision tables in, 222–227 electronic commerce application, 227–228 summary, 229

Process-to-Data Entity matrix, 122 Process-to-Information System matrix, 122 Product differentiation, 118 Product focus strategy, 118 Program Evaluation Review Technique (PERT),

85–86 Programming languages, 29, 42 Project. See also Identification and selection of

projects; Project initiation and planning; Project management

benefits, 137–139 charter, 72, 73 closedown, 82–83, 489–490 costs, 139–142 definition of, 66 execution, 79–82 iterations, 98, 100–102 reports, 91–92 scope, 74, 78–79, 135–136 standards and procedures, 78 start date, 90 status, 82, 84 structure, 146–147 tasks, 74–77, 80, 90–91 workbook, 70–72, 80–82, 81

Project, Microsoft, 84, 85, 86, 90–92 Project Communication matrix, 153–154 Project initiation and planning (PIP), 72–79,

133–161. See also Project management Baseline Project Plan, 79–82, 135–136, 149–158 communication plan, 77–78, 81–82, 153–154 deciding level of effort for, 133–134 deliverables and outcomes, 135–136 for electronic commerce, 159–160 feasibility assessment, 136–149 initiation activities, 70–72 network diagrams in, 76–77, 83–84, 85–86 planning activities, 74–79 preliminary budget, 78–79 preliminary schedule, 76–77 process of, 134–136 project charter, 72, 73 project initiation definition, 70 project planning definition, 72 project schedule charts, 81, 84–85, 160 project scope, 74 Project Scope Statement, 78–79, 135–136 project workbook, 71–72, 81 resource plan, 75–76 standards and procedures, 78, 153 summary, 161 task definition, 74–75 tools for representing plans, 83–85

Project management. See also Identification and selection of projects; Project initiation and planning

assigning task relationships, 89–90 closedown, 82–83, 489–490 customer contract, 83 execution of, 79–82

Z03_VALA1629_09_GE_IDX.indd 526 15/04/2020 12:04

Index 527 postproject reviews, 83 project charter, 72, 73 project management software in, 89–92 representing and scheduling in, 83–89 reviewing interim project reports, 91–92 start date, 90–91 summary, 93

Project manager activities and skills of, 69 definition of, 66 in project initiation, 70–72 project types, 64 for PVF, 66–68 representing and scheduling project plans,

83–89 Project Scope Statement (PSS), 78–79, 135–136 Project Standards and Procedures, 78, 153 Prompting cues, 409–410 Prototyping

in dialogue design, 415–416 evolutionary, 187, 196, 488 in form and report design, 366 in requirements determination, 186–188, 196 throwaway, 187–188

PSS (Project Scope Statement), 78–79, 135–136 PVF. See Pine Valley Furniture PVF WebStore. See Pine Valley Furniture (PVF)

WebStore

Q Query operation, 302–303 Questions, in interviews, 173, 175

R Random access memory (RAM), 431 Range control, 343 Range partitioning, 345 Ranking, 112–113 Rational Unified Process (RUP), 43–44 Recovery testing, 473 Recurring cost, 141 Recursive foreign key, 335 Recursive relationship, 279–280 Redundancy, 116 Re-engineering, 506 Refactoring, 473 Reference data, 346–347 Referential integrity, 331, 343–344 Reframing, 171 Regular entity, 332–333, 336 Relation

definition of, 327 E–R diagrams transformed into, 331–336 merging, 336–338 second normal form, 329, 330 third normal form, 329, 330–331 well-structured, 327–328

Relational database model, 322, 324, 327–328, 350 Relationships

binary, 280, 333–336 cardinalities in, 281–282 class/subclass, 338 definition, 277 degree of, 279–281, 304 extend, 239–240 include, 240–242 labeling, 277–278 naming and defining, 282–283 representation of, 332–336 simultaneous, 280–281

ternary, 280–281 unary, 279–280, 333, 335–336

Relax constraints, 170 Repeating group, 276–277 Reports. See also Form and report design

definition of, 364–365 exception, 365 financial, 181–182 paper versus electronic, 379–381 project, 91–92 summary, 325 types of, 365 user-centered, 365

Representational State Transfer (REST), 444 Request for proposal (RFP), 57 Request for quote (RFQ), 57 Required attribute, 277 Requirements determination, 168–197

agile methodologies in, 191–194 business process reengineering in, 188–190 contemporary methods for, 183–188 deliverables and outcomes, 171–172 directly observing users, 177–178, 183 disruptive technologies, 190–191 for electronic commerce applications, 194–197 group interviews, 176–177 interviewing and listening, 172–175 Joint Application Design, 184–186 procedures and documents examination for,

178–183 process and characteristics, 170–171 prototyping in, 186–188, 196 summary, 197–198

Requirements structuring. See Data requirements structuring

Reregistration, 507 Resources

availability of, 112–113 definition of, 85 planning for, 75–76 for representing project plans, 83–85

Response time, of vendors, 56–57 REST (Representational State Transfer), 444 Return on investment (ROI), 144–145 Reuse, software, 58–60 Reverse engineering, 506 Revision control, 505 RFP (request for proposal), 57 RFQ (request for quote), 57 Ribbon menus, 394 Risk. See also Feasibility; Feasibility assessment

assessment, 54 factors, 146 identifying, 74 matrix, 147 technical, 145–148

ROI (return on investment), 144–145 Rolls-Royce, 118–119 Rows, table, 348–351, 377 Royce, W. W., 36 Rules, in decision tables, 223–224 RUP (Rational Unified Process), 43–44

S SaaS (software as a service), 439 Sales Promotion Tracking System (SPTS), 86–89 SAP AG, 50, 51, 52 Sarbanes–Oxley Act (SOX), 54, 343, 441 Satisfaction and aesthetics, 383 Scheduled reports, 365

Scheduling charts, 83–85 critical path, 85 PERT in, 85–86 preliminary, 76–77 of project plan, 83–89 of PVF WebStore, 160 schedule feasibility, 148

Schuster, Alex, 65 Scribe, 184 Scrum, 40–41 SDLC. See Systems development life cycle Search engines, reregistration with, 507 Secondary key, 348 Second normal form (2NF), 329, 330 Secretary, 155 Security

in cloud computing, 54, 441 in database design, 351–352 in implementation, 485–487 in Internet site management, 449–450 password remembering, 449–450 testing, 473

Self-adaptive software development, 38–39 Sequence, dialogue, 413–415 Sequential file organization, 348–349, 351 Service-level agreements (SLAs), 441 Service models, 438–440 Service-oriented architecture (SOA), 442–444 Service provider, 443 Service requester, 443 Short-term planning, 124–125 Simple Mail Transfer Protocol (SMTP), 444 Simple Object Access Protocol (SOAP), 444 Simple Storage Service (S3), 436 Simultaneous relationship, 280–281 Single-location installation, 475–476 Slack time, 88–89, 90 SLAs (service-level agreements), 441 SMTP (Simple Mail Transfer Protocol), 444 SOA (service-oriented architecture), 442–444 SOAP (Simple Object Access Protocol), 444 Soft drink sales observation, 178 Software. See also Computer-aided software

engineering application, 27–28, 29, 34, 47, 501 for cloud computing, 52–54, 55 criteria for off-the-shelf, 55–57 for e-learning, 480 enterprise resource planning systems, 50, 52,

55, 57 flexibility, 56 in-house development, 54–55 leading firms, specialization, 49–50, 55 open-source, 54, 55 outsourcing and, 48–49 packaged software producers, 50–52, 55 for project management, 89–92 reuse, 58–60 security, 54 sources, 47, 49–55 summary, 60 validating information about, 57–58

Software application testing, 467–474 acceptance testing by users, 473–474 bug testing and system evolution, 488 coding and testing combined, 472–473 desk checking, 469 inspections, 468–469 integration testing, 470 master test plan, 467–468

Z03_VALA1629_09_GE_IDX.indd 527 15/04/2020 12:04

528 Index Software application testing (Continued)

stub testing, 470 syntax checking, 469 system testing, 470 testing process, 470–472 unit testing, 470

Software as a service (SaaS), 439 Source/sink, 206–207, 208, 211 SOX (Sarbanes–Oxley Act), 54, 343, 441 Spacing, 375 Sponsor, 184 Sprint, 41 SPTS (Sales Promotion Tracking System), 86–89 SQL (Structured Query Language), 324 SSR (System Service Request), 66–67, 113, 496–497 Staged (phased) installation, 475, 476 Stakeholders, 243–244 Standards bearer, 155 State, of an object, 301–302 Status information, 409 Steering committee, 110, 111–112 Story Cards, 193–194 Strategic alignment, 112 Stress testing, 473 Structured Query Language (SQL), 324 Structured walk-through, 154–158, 469 Stub testing, 470 Stylesheet-based HTML, 385 Subtypes, in E-R modeling, 285–286, 336 Success guarantee, 244 Superclasses, 306 Supertypes, in E-R modeling, 285–286, 336 Support

in implementation, 464, 466–467, 479–482 user, 479–480 vendors, 56

Swimlane, 253, 260–261 Synonyms, 337 Syntax checking, 469 System boundary, 239 System description, in BPP, 150, 151–152 System documentation, 477–478 System engineers, in user support, 482 System evolution, 187, 196, 488 System layout, 195 System librarian, 505 System menu, 419 Systems acquisition. See Software Systems analyst

primary role of, 28–29 as project manager, 64 in RUP phases, 43–44 in SDLC phases, 32–35

Systems development analysis–design–code–test loop in, 35–36, 44 definition of, 27–28 evolution of, 29–30 heart of, 35–37 methodology, 28, 30–31, 38–39 modern approach to, 29–30 organizational approach to, 28 summary, 104 systems analysis and design versus, 44

Systems development life cycle (SDLC). See also Analysis; Design; Identification and selection of projects; Implementation; Maintenance; Planning

CASE in, 29–30 circular process of, 30–31 criticisms of, 44 data modeling and, 268–269 definition of, 30

phases in, 32–35 summary, 45 traditional waterfall, 36–37 U.S. Department of Justice’s system, 32

System Service Request (SSR), 66–67, 113, 496–497 Systems implementation. See Implementation Systems integration, 30 System testing. See Testing

T Tables

decision, 223–227, 310–312 formatting of, 375–379 row arrangement, 348–351, 377

Tablespace, 345 Tangible benefits, 137, 139 Tangible cost, 139 Target situation, 123 Task Cards, 194 Task definition, 75 Task responsibility matrix, 154 Team configuration, 153 Technical feasibility, 145–148 Techniques, 28 “Temporarily Out of Service” notice, 506 Ternary relationships, 280–281 Test case, 471–472, 487–489 Testing. See also Software application testing

acceptance, 473–474 alpha, 473, 488–489 beta, 474, 488–489 coding and, 472–473 integration, 470 module, 470 performance, 473 recovery, 473 security, 473 stress, 473 stub, 470 test cases, 471–472, 487–489 unit, 470

Testing harness, 472 Thin clients, 435, 446 Thing-to-Thing (T2T), 126 Third normal form (3NF), 329, 330–331, 338 Three-tiered client/server architecture, 433 Throwaway prototyping, 187–188 Time value of money (TVM), 142–145 Titles, 370–372 Tools, 28 Top-down approach, 270–271 Top-down planning, 120–121 Top-down source, 112, 115, 119 Total cost of ownership (TCO), 141 Total slack, 89 Total specialization rule, 286 Touch screen, 401–402 Trackball, 401–402 Traditional waterfall SDLC, 36–37 Training systems users, 479–481 Trends, 123–124 Trigger, in written use cases, 244 Triggering operations (trigger), 288, 289 Trustworthiness, 448–449 Turnkey systems, 52 TVM (time value of money), 142–145

U Unary relationships, 279–280, 333, 335–336 Unbalanced DFD, 214–216 Unified modeling language (UML), 269

Unit testing, 470 Unit-to-Function matrix, 122 Universal data models, 290 Update operation, 303 Usability, of forms and reports, 381–383 Use cases, 237–249

definitions and symbols, 239–242 diagram, 238–239, 241–242, 245–247 for Hoosier Burger, 241–242 overview, 237–238 for PVF, 245–247 summary of, 250 summary use cases, 243–244 written, 242–245, 247–249

User-centered design, 365 User documentation, 477, 478–479 User-friendliness, 382 Users

actors versus, 238 continual involvement of, 191 direct observation of, 177–178, 183 documentation for, 477, 478–479 expectations of, 483 groups, 146–147 supporting, 481–482 training, 479–481

User’s guides, 477–479 Utility computing, 435–436

V Value chain analysis, 112–113 Vendor support, 56 View integration, 323 Virtualization, 433 Virtual machine, 433 Visio, Microsoft, 269, 272, 275, 283–284, 318 Visual Basic.NET, 366, 368, 398, 415 Vocabularies, 444 Voice commands, 401

W Walk-throughs, 154–158, 159–160, 469 Warning messages, 410 Waterfall SDLC, 36–37 Weak entity, 336 Web page design, 383–385. See also Form and

report design common errors in, 384, 420 forms and data integrity rules, 384–385 guidelines for, 383 interface and dialogue design, 419–422 lightweight graphics in, 384 stylesheet-based HTML in, 385

Web services, 443–444 Website maintenance, 506–507 Weighted multicriteria analysis, 114 Well-structured relations, 327–328 Wireframe, 366, 368, 415, 417 Wireless Markup Language (WML), 448 Word, Microsoft, 478 Workbook, project, 71–72, 81 Work breakdown structure, 74–75, 153 Work procedures, written, 168–169 Work results, 81 Written use cases, 242–245, 247–249

X XML (eXtensible Markup Language),

443–444, 447 XSL (eXtensible Stylesheet Language),

446–66

Z03_VALA1629_09_GE_IDX.indd 528 15/04/2020 12:04

Cover
Title Page
Copyright Page
Brief Contents
Contents
Preface��
PART ONE Foundations for Systems Development

AN OVERVIEW OF PART ONE��
1 The Systems Development Environment

Learning Objectives��
Introduction��
A Modern Approach to Systems Analysis and Design��
Developing Information Systems and the Systems Development Life Cycle��
The Heart of the Systems Development Process��

The Traditional Waterfall SDLC��

Agile Methodologies��

eXtreme Programming��
Scrum��
Agile in Practice��

Object-Oriented Analysis and Design��
Our Approach to Systems Development��
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��

2 The Origins of Software��

Learning Objectives��
Introduction��
Systems Acquisition��

Outsourcing��
Sources of Software��
Choosing Off-the-Shelf Software��
Validating Purchased Software Information��

Reuse��
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: THE ORIGINS OF SOFTWARE

Case Questions��

3 Managing the Information Systems Project��

Learning Objectives��
Introduction��
Pine Valley Furniture Company Background��
Managing the Information Systems Project��

Initiating a Project��
Planning the Project��
Executing the Project��
Closing Down the Project��

Representing and Scheduling Project Plans��

Representing Project Plans��
Calculating Expected Time Durations Using PERT��
Constructing a Gantt Chart and Network Diagram at Pine Valley Furniture��

Using Project Management Software��

Establishing a Project Start Date��
Entering Tasks and Assigning Task Relationships��
Selecting a Scheduling Method to Review Project Reports��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
Appendix: Object-Oriented Analysis and Design: Project Management��

Learning Objectives��
Unique Characteristics of an OOSAD Project��
Define the System as a Set of Components��

Complete Hard Problems First��
Using Iterations to Manage the Project��
Don't Plan Too Much Up Front
How Many and How Long Are Iterations?��
Project Activity Focus Changes Over the Life of a Project��

Summary��
Review Question��
Problems and Exercises��
BEC CASE: MANAGING THE INFORMATION SYSTEMS PROJECT

Case Questions��

PART TWO Planning

AN OVERVIEW OF PART TWO��
4 Identifying and Selecting Systems Development Projects

Learning Objectives��
Introduction��
Identifying and Selecting Systems Development Projects��

The Process of Identifying and Selecting IS Development Projects��
Deliverables and Outcomes��

Corporate and Information Systems Planning��

Corporate Strategic Planning��
Information Systems Planning��

Electronic Commerce Applications: Identifying and Selecting Systems Development Projects��

Internet Basics��
Pine Valley Furniture WebStore��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: IDENTIFYING AND SELECTING SYSTEMS DEVELOPMENT PROJECTS
Case Questions��

5 Initiating and Planning Systems Development Projects��

Learning Objectives��
Introduction��
Initiating and Planning Systems Development Projects��
The Process of Initiating and Planning is Development Projects

Deliverables and Outcomes��

Assessing Project Feasibility��

Assessing Economic Feasibility��
Assessing Technical Feasibility��
Assessing Other Feasibility Concerns��

Building and Reviewing the Baseline Project Plan��

Building the Baseline Project Plan��
Reviewing the Baseline Project Plan��

Electronic Commerce Applications: Initiating and Planning Systems Development Projects��

Initiating and Planning Systems Development Projects for Pine Valley Furniture's WebStore

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: INITIATING AND PLANNING SYSTEMS DEVELOPMENT PROJECTS

Case Questions��

PART THREE Analysis

AN OVERVIEW OF PART THREE��
6 Determining System Requirements��

Learning Objectives��
Introduction��
Performing Requirements Determination��

The Process of Determining Requirements��
Deliverables and Outcomes��

Traditional Methods for Determining Requirements��

Interviewing and Listening��
Interviewing Groups��
Directly Observing Users��
Analyzing Procedures and Other Documents��

Contemporary Methods for Determining System Requirements��

Joint Application Design��
Using Prototyping During Requirements Determination��

Radical Methods for Determining System Requirements��

Identifying Processes to Reengineer��
Disruptive Technologies��

Requirements Determination Using Agile Methodologies��

Continual User Involvement��
Agile Usage-Centered Design��
The Planning Game from eXtreme Programming��

Electronic Commerce Applications: Determining System Requirements��

Determining System Requirements for Pine Valley Furniture's WebStore

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: DETERMINING SYSTEM REQUIREMENTS

Case Questions��

7 Structuring System Process Requirements

Learning Objectives��
Introduction��
Process Modeling��

Modeling a System's Process for Structured Analysis
Deliverables and Outcomes��

Data Flow Diagramming Mechanics��

Definitions and Symbols��
Developing DFDs: An Example��
Data Flow Diagramming Rules��
Decomposition of DFDs��
Balancing DFDs��

An Example DFD��
Using Data Flow Diagramming in the Analysis Process��

Guidelines for Drawing DFDs��
Using DFDs as Analysis Tools��
Using DFDs in Business Process Reengineering��

Modeling Logic with Decision Tables��
Electronic Commerce Application: Process Modeling Using Data Flow Diagrams

Process Modeling for Pine Valley Furniture's WebStore

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
Appendix 7A: Object-Oriented Analysis and Design: Use Cases��

Learning Objectives��
Introduction��
Use Cases��

What Is a Use Case?��
Use Case Diagrams��
Definitions and Symbols��

Written Use Cases��

Level��
The Rest of the Template��

Electronic Commerce Application: Process Modeling Using Use Cases��
Writing Use Cases for Pine Valley Furniture's WebStore
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercise��
References��

Appendix 7B: Object-Oriented Analysis and Design: Activity Diagrams��

Learning Objectives��
Introduction��
When to Use an Activity Diagram��
Problems and Exercises��
Reference��

Appendix 7C: Business Process Modeling��

Learning Objective��
Introduction��
Basic Notation��
Business Process Example��
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: STRUCTURING SYSTEM PROCESS REQUIREMENTS

Case Questions��

8 Structuring System Data Requirements��

Learning Objectives��
Introduction��
Conceptual Data Modeling��

The Conceptual Data Modeling Process��
Deliverables and Outcomes��

Gathering Information for Conceptual Data Modeling��
Introduction to E-R Modeling��

Entities��
Attributes��
Candidate Keys and Identifiers��
Other Attribute Types��
Relationships��

Conceptual Data Modeling and the E-R Model��

Degree of a Relationship��
Cardinalities in Relationships��
Naming and Defining Relationships��
Associative Entities��
Summary of Conceptual Data Modeling with E-R Diagrams��

Representing Supertypes and Subtypes��
Business Rules��

Domains��
Triggering Operations��

Role of Packaged Conceptual Data Models: Database Patterns��

Universal Data Models��
Industry-Specific Data Models��
Benefits of Database Patterns and Packaged Data Models��

Electronic Commerce Application: Conceptual Data Modeling��

Conceptual Data Modeling for Pine Valley Furniture's WebStore

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
Appendix: Object-Oriented Analysis and Design: Object Modeling—Class Diagrams

Learning Objectives��
Introduction��
Representing Objects and Classes��
Types of Operations��
Representing Associations��
Representing Associative Classes��
Representing Stereotypes for Attributes��
Representing Generalization��
Representing Aggregation��
An Example of Conceptual Data Modeling at Hoosier Burger��
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
References��
BEC CASE: STRUCTURING SYSTEM DATA REQUIREMENTS

Case Questions��

PART FOUR Design

AN OVERVIEW OF PART FOUR��
9 Designing Databases��

Learning Objectives��
Introduction��
Database Design��

The Process of Database Design��
Deliverables and Outcomes��
The Relational Database Model��
Well-Structured Relations��

Normalization��

Rules of Normalization��
Functional Dependence and Primary Keys��
Second Normal Form��
Third Normal Form��

Transforming E-R Diagrams into Relations��

Represent Entities��
Represent Relationships��
Summary of Transforming E-R Diagrams to Relations��

Merging Relations��

An Example of Merging Relations��
View Integration Problems��

Logical Database Design for Hoosier Burger��
Physical File and Database Design��

Designing Fields��
Choosing Data Types��
Controlling Data Integrity��
Designing Physical Tables��
Arranging Table Rows��
Designing Controls for Files��

Physical Database Design for Hoosier Burger��
Electronic Commerce Application: Designing Databases��

Designing Databases for Pine Valley Furniture's WebStore

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: DESIGNING DATABASES

Case Questions��

10 Designing Forms and Reports��

Learning Objectives��
Introduction��
Designing Forms and Reports��

The Process of Designing Forms and Reports��
Deliverables and Outcomes��

Formatting Forms and Reports��

General Formatting Guidelines��
Highlighting Information��
Color versus No Color��
Displaying Text��
Designing Tables and Lists��
Paper versus Electronic Reports��

Assessing Usability��

Usability Success Factors��
Measures of Usability��

Electronic Commerce Applications: Designing Forms and Reports for Pine Valley Furniture's WebStore

General Guidelines��
Designing Forms and Reports at Pine Valley Furniture��
Lightweight Graphics��
Forms and Data Integrity Rules��
Stylesheet-Based HTML��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: DESIGNING FORMS AND REPORTS

Case Questions��

11 Designing Interfaces and Dialogues��

Learning Objectives��
Introduction��
Designing Interfaces and Dialogues��

The Process of Designing Interfaces and Dialogues��
Deliverables and Outcomes��

Interaction Methods and Devices��

Methods of Interacting��
Hardware Options for System Interaction��

Designing Interfaces��

Designing Layouts��
Structuring Data Entry��
Controlling Data Input��
Providing Feedback��
Providing Help��

Designing Dialogues��

Designing the Dialogue Sequence��
Building Prototypes and Assessing Usability��

Designing Interfaces and Dialogues in Graphical Environments��

Graphical Interface Design Issues��
Dialogue Design Issues in a Graphical Environment��

Electronic Commerce Application: Designing Interfaces and Dialogues for Pine Valley Furniture's WebStore

General Guidelines��
Designing Interfaces and Dialogues at Pine Valley Furniture��
Menu-Driven Navigation with Cookie Crumbs��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: DESIGNING INTERFACES AND DIALOGUES

Case Questions��

12 Designing Distributed and Internet Systems��

Learning Objectives��
Introduction��
Designing Distributed and Internet Systems��

The Process of Designing Distributed and Internet Systems��
Deliverables and Outcomes��

Designing LAN and Client/Server Systems��

Designing Systems for LANs��
Designing Systems for a Client/Server Architecture��

Cloud Computing��

What Is Cloud Computing?��
Managing the Cloud��
Service-Oriented Architecture��
Web Services��

Designing Internet Systems��

Internet Design Fundamentals��
Site Consistency��
Design Issues Related to Site Management��

Electronic Commerce Application: Designing a Distributed Advertisement Server for Pine Valley Furniture's WebStore

Advertising on Pine Valley Furniture's WebStore
Designing the Advertising Component��
Designing the Management Reporting Component��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: DESIGNING DISTRIBUTED AND INTERNET SYSTEMS

Case Questions��

PART FIVE Implementation and Maintenance

AN OVERVIEW OF PART FIVE��
13 System Implementation��

Learning Objectives��
Introduction��
System Implementation��

Coding, Testing, and Installation Processes��
Deliverables and Outcomes from Coding, Testing, and Installation��
Deliverables and Outcomes from Documenting the System, Training Users, and Supporting Users��

Software Application Testing��

Seven Different Types of Tests��
The Testing Process��
Combining Coding and Testing��
Acceptance Testing by Users��

Installation��

Direct Installation��
Parallel Installation��
Single-Location Installation��
Phased Installation��
Planning Installation��

Documenting the System��

User Documentation��

Training and Supporting Users��

Training Information Systems Users��
Supporting Information Systems Users��

Organizational Issues in Systems Implementation��

Why Implementation Sometimes Fails��
Security Issues��

Electronic Commerce Application: System Implementation and Operation for Pine Valley Furniture's WebStore

Developing Test Cases for the WebStore��
Alpha and Beta Testing the WebStore��
WebStore Installation��

Project Closedown��
Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��
BEC CASE: SYSTEM IMPLEMENTATION

Case Questions��

14 Maintaining Information Systems��

Learning Objectives��
Introduction��
Maintaining Information Systems��

The Process of Maintaining Information Systems��
Deliverables and Outcomes��

Conducting Systems Maintenance��

Types of Maintenance��
The Cost of Maintenance��
Managing Maintenance��
Role of Automated Development Tools in Maintenance��

Website Maintenance��
Electronic Commerce Application: Maintaining an Information System for Pine Valley Furniture's WebStore

Maintaining Pine Valley Furniture's WebStore
Cannot Find Server��

Summary��
Key Terms��
Review Questions��
Problems and Exercises��
Field Exercises��
References��

GLOSSARY OF TERMS��
GLOSSARY OF ACRONYMS��
INDEX��