Visible Analyst is a “hands-on” tool for teaching students all aspects of analysis and design including dynamic rules, consistency checking, managing change, and understanding the integration issues across an IT project. Visible Analyst prepares students to enter the IT world as business or data architects, analysts, designers, and modelers.

Visit us at www.visible.com to learn more.

YOU CAN Start Today with the Visible Analyst!

Only takes 2 minutes to install! Save… 33% discount!

Please visit http://store.visible.com/Wiley.aspx to purchase and register with your information (see below) and obtain a valid license for your student edition of the software. To purchase the discounted software you will need to enter the following code:

978112014

Email support is provided to all registered students at support@visible.com. Your registration includes

the latest release of the Visible Analyst Student Edition (software)

the Visible Analyst eTutorial a preloaded Sample Instructional

Project access to Webcast “How to” and “Get

Started” Instructional Videos.

Visible Analyst Student Edition Educating tomorrow’s developers today

Disclaimer: The publisher of the textbook does not sponsor, review, or make decisions about Visible Analyst software, and will not be responsible for, or involved in, any changes to the software.

System Analysis & Design A n O bject -O riented A pproach with UML

Fift h Edition

Alan Dennis Indiana University

Barbara Haley Wixom Massachusetts Institute of Technology

David Tegarden Virginia Tech

With contributions by Elaine Seeman, East Carolina University

VP & EXECUTIVE PUBLISHER: Don Fowley EXECUTIVE EDITOR: Beth Lang Golub CONTENT EDITOR: Mary O’Sullivan ASSOCIATE EDITOR: Ellen Keohane MARKETING MANAGER: Christopher Ruel ASSOCIATE PRODUCTION MANAGER: Joyce Poh DESIGNER: Wendy Lai

Cover Image: © Christopher Boswell/Shutterstock

Th is book was set in 10/12 Minion pro by Aptara and printed and bound by Courier Kendallville. Th e cover was printed by Courier Kendallville.

Th is book is printed on acid-free paper .

Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfi ll their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global eff ort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifi cations and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our website: www.wiley.com/go/citizenship.

Copyright © 2015, 2012, 2009 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be repro- duced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photo- copying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923 (Web site: www.copyright.com). Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201) 748-6011, fax (201) 748-6008, or online at: www.wiley.com/go/permissions.

Evaluation copies are provided to qualifi ed academics and professionals for review purposes only, for use in their courses during the next academic year. Th ese copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instruc- tions and a free of charge return shipping label are available at: www.wiley.com/go/returnlabel. If you have chosen to adopt this textbook for use in your course, please accept this book as your complimentary desk copy. Outside of the United States, please contact your local sales representative.

Library of Congress Cataloging-in-Publication Data

Dennis, Alan. Systems analysis & design : an object-oriented approach with UML/Alan Dennis, Indiana University, Barbara Haley Wixom, Massachusetts Institute of Technology, David Tegarden, Virginia Tech; with contributions by Elaine Seeman, East Carolina University.–Fift h edition. pages cm Includes bibliographical references and index.

ISBN 978-1-118-80467-4 (pbk. : alk. paper) 1. System analysis. 2. System design. 3. UML (Computer science) I. Wixom, Barbara Haley, 1969-II. Tegarden, David Paul. III. Seeman, Elaine. IV. Title. V. Title: System analysis and design. QA402.D395 2015 004.2’1–dc23

2014048338

Printed in the United States of America

10 9 8 7 6 5 4 3 2 1

PURPOSE OF THIS BOOK Systems Analysis and Design (SAD) is an exciting, active fi eld in which analysts continually learn new techniques and approaches to develop systems more eff ectively and effi ciently. However, there is a core set of skills that all analysts need to know—no matter what approach or methodology is used. All information systems projects move through the four phases of planning, analysis, design, and implementation; all projects require analysts to gather requirements, model the business needs, and create blueprints for how the system should be built; and all projects require an understanding of organizational behavior con- cepts like change management and team building. Today, the cost of developing modern soft ware is composed primarily of the cost associated with the developers themselves and not the computers. As such, object-oriented approaches to developing information systems hold much promise in controlling these costs.

Today, the most exciting change to systems analysis and design is the move to object-oriented techniques, which view a system as a collection of self-contained objects that have both data and processes. Th is change has been accelerated through the crea- tion of the Unifi ed Modeling Language (UML). UML provides a common vocabulary of object-oriented terms and diagramming techniques that is rich enough to model any sys- tems development project from analysis through implementation.

Th is book captures the dynamic aspects of the fi eld by keeping students focused on doing SAD while presenting the core set of skills that we feel every systems analyst needs to know today and in the future. Th is book builds on our professional experience as systems analysts and on our experience in teaching SAD in the classroom.

Th is book will be of particular interest to instructors who have students do a major project as part of their course. Each chapter describes one part of the process, provides clear explanations on how to do it, gives a detailed example, and then has exercises for the students to practice. In this way, students can leave the course with experience that will form a rich foundation for further work as a systems analyst.

OUTSTANDING FEATURES

A Focus on Doing SAD Th e goal of this book is to enable students to do SAD—not just read about it, but under- stand the issues so that they can actually analyze and design systems. Th e book introduces each major technique, explains what it is, explains how to do it, presents an example, and provides Your Turn opportunities with each chapter for students to practice each new tech- nique before they do it for real in a project. Th e Your Turn boxes are posted online at www. wiley.com/college/dennis. Aft er reading each chapter, the student will be able to perform that step in the system development process.

P R E F A C E

vi Preface

Rich Examples of Success and Failure Th is book has a running online case study (accessible from www.wiley.com/go/dennis/ casestudy ) about a fi ctitious health care company called Patterson Superstore. Each chapter of the case study shows how the concepts are applied in situations at Patterson Superstore. In this way, the running case serves as a template that students can apply to their own work. Each chapter also includes numerous Concepts in Action boxes, which are posted online at www.wiley.com/college/dennis. Th ese boxes describe how real companies succeeded—and failed—in performing the activities in the chapter. Many of these examples are drawn from our own experiences as systems analysts.

Real World Focus The skills that students learn in a systems analysis and design course should mirror the work that they ultimately will do in real organizations. We have tried to make this book as “real” as possible by building extensively on our experience as professional sys- tems analysts for organizations, such as Arthur Andersen, IBM, the U.S. Department of Defense, and the Australian Army. We have also worked with a diverse industry advisory board of IS professionals and consultants in developing the book and have incorporated their stories, feedback, and advice throughout. Many students who use this book will eventually use the skills on the job in a business environment, and we believe they will have a competitive edge in understanding what successful practition- ers feel is relevant in the real world.

Project Approach We have presented the topics in this book in the order in which an analyst encounters them in a typical project. Although the presentation is necessarily linear (because students have to learn concepts in the way in which they build on each other), we emphasize the iterative, complex nature of SAD as the book unfolds. Th e presentation of the material should align well with courses that encourage students to work on projects because it presents topics as students need to apply them.

WHAT’S NEW IN THIS EDITION ■ A completely new, expanded case study on an integrated health clinic delivery

system has been written to accompany the fi ft h e dition. Th e entire case study is posted online. At the end of each chapter in the text, a short synopsis of the case is provided.

■ Th e text has been streamlined to focus on the essentials and therefore, to enhance student understanding. Selected m aterial s like the “Your Turn” and “Concepts in Action” boxes have been moved online and can be accessed at www.wiley.com/ college/dennis .

■ Th roughout the book , there is a greater emphasis on verifying, validating, and testing, as well as the incremental and iterative development of systems.

■ In Chapter 2, there is more content on Agile techniques , including scrum meet- ings, product backlog, and sprints.

■ In Chapter 3, we have increased focus on soft ware quality and user stories. ■ We have added new examples throughout the book and clarifi ed explanations to

help students learn some of the more diffi cult concepts.

Preface vii

■ Chapter 10 includes more coverage of mobile computing , including specifi cs on navigation, input, and output. Th is chapter also has a new section on games, multidimensional information visualization, augmented reality, and virtual reality.

■ Chapter 11 includes new material o n ubiquitous computing and the Internet of Th ings. ■ Testing has been expanded in Chapter 12.

ORGANIZATION OF THIS BOOK Th is book is loosely organized around the phases and workfl ows of the enhanced Unifi ed Process. Each chapter has been written to teach students specifi c tasks that analysts need to accomplish over the course of a project, and the deliverables that will be produced from the tasks. As students complete the chapters, they will realize the iterative and incremental nature of the tasks in object-oriented systems development.

Chapter 1 introduces the SDLC, systems development methodologies, roles and skills needed for a systems analyst, the basic characteristics of object-oriented systems, object-oriented systems analysis, the Unifi ed Process, and the UML. Chapter 2 presents topics related to the project management workfl ow of the Unifi ed Process, including pro- ject identifi cation, system request, feasibility analysis, project selection, traditional project management tools (including work breakdown structures, network diagrams, and PERT analysis), project eff ort estimation using use-case points, evolutionary work breakdown structures, iterative workplans, scope management, timeboxing, risk management, and staffi ng the project. Chapter 2 also addresses issues related to the Environment and Infra- structure management workfl ows of the Unifi ed Process.

Part One focuses on creating analysis models. Chapter 3 introduces students to an assort- ment of requirements analysis strategies a variety of requirements-gathering techniques that are used to determine the functional and nonfunctional requirements of the system, and to a system proposal. Chapter 4 focuses on constructing business process and functional models using use - case diagrams, activity diagrams, and use - case descriptions. Chapter 5 addresses producing structural models using CRC cards, class diagrams, and object diagrams. Chapter 6 tackles creating behavioral models using sequence diagrams, communication diagrams, behavioral state machines, and CRUDE analysis and matrices. Chapters 4 through 6 also cover the verifi cation and validation of the models described in each chapter.

Part Two addresses design modeling. In Chapter 7, students learn how to verify and validate the analysis models created during analysis modeling and to evolve the analysis models into design models via the use of factoring, partitions, and layers. Th e students also learn to create an alternative matrix that can be used to compare custom, packaged, and outsourcing alternatives. Chapter 8 concentrates on designing the individual classes and their respective methods through the use of contracts and method specifi cations. Chapter 9 presents the issues involved in designing persistence for objects. Th ese issues include the diff erent storage formats that can be used for object persistence, how to map an object- oriented design into the chosen storage format, and how to design a set of data access and manipulation classes that act as a translator between the classes in the application and the object persistence. Th is chapter also focuses on the nonfunctional requirements that impact the data management layer. Chapter 10 presents the design of the human–computer interaction layer, where students learn how to design user interfaces using use scenarios, windows navigation diagrams, storyboards, windows layout diagrams, user interface prototypes, real use cases, interface standards, and user interface templates; to perform user interface evaluations using heuristic evaluation, walkthrough evaluation, interactive evaluation, and formal usability testing; and to address nonfunctional requirements such

viii Preface

as user interface layout, content awareness, aesthetics, user experience, and consistency. Th is chapter also addresses issues related to mobile computing, social media, games, multi dimensional information visualizations, immersive environments, and international and cultural issues with regard to user interface design. Chapter 11 focuses on the phys- ical architecture and infrastructure design, which includes deployment diagrams and hardware/soft ware specifi cation. In today’s world, this also includes issues related to cloud computing, ubiquitous computing, the Internet of things, and green IT. Th is chapter, like the previous design chapters, covers the impact that nonfunctional requirements can have on the physical architecture layer.

Part Th ree provides material that is related to the construction, installation, and operations of the system. Chapter 12 focuses on system construction, where students learn how to build, test, and document the system. Installation and operations are covered in Chapter 13, where students learn about the conversion plan, change management plan, support plan, and project assessment. Additionally, these chapters address the issues related to developing systems in a fl at world, where developers and users are distributed throughout the world.

SUPPLEMENTS www.wiley.com/college/dennis

Instructor Book Companion Web s ite ■ PowerPoint slides : I nstructors can tailor the slides to their classroom needs .

S tudents can use them to guide their reading and studying activities. ■ Test Bank : I ncludes a variety of questions ranging from multiple-choice, true/

false, and short answer questions. A computerized, Respondus version of the Test Bank is also available.

■ Instructor’s Manual : P rovides resources to support the instructor both inside and out of the classroom. Th e manual includes short experiential exercises that instr uctors can use to help students experience and understand key topics in each chapter. Short stories have been provided by people working in both corpo- rate and consulting environments for instructors to insert into lectures to make concepts more colorful and real. Additional minicases for every chapter allow students to perform some of the key concepts that were learned in the chapter. Solutions to end of chapter questions and exercises are provided.

Student Book Companion Web s ite ■ A collection of templates and worksheets consisting of electronic versions of

selected fi gures from the book. ■ A completely new, expanded case study on an integrated health clinic delivery

system has been written to accompany the fi ft h edition. Th is case study is online only. It can be accessed at www.wiley.com/go/dennis/casestudy .

■ “Your Turn” and “Concepts in Action” boxes from the fourth edition have been moved online and can be accessed from the student companion site.

Wiley E-Text: Powered by VitalSource Th is Wiley e-text off ers students continuing access to materials for their course. Your students can access content on a mobile device, online from any Internet-connected computer, or by a computer via download. With dynamic features built into this e-text, students can search across content, highlight, and take notes that they can share with teachers and classmates.

Preface ix

Visible Analyst Wiley has partnered with Visible Analyst to give students a discounted price for Visible Analyst soft ware, an intuitive modeling tool for all aspects of traditional or object-oriented systems analysis and design. All new copies of the text will have a Key Code (printed on a page near the front of this text) that will provide a discount on Visible Analyst soft ware. To obtain the soft ware, students should visit http://store.visible.com/Wiley.aspx and enter their Key Code. Students who buy a new print text or digital e-book will receive one-third off the price of a downloadable edition of the soft ware with a 6-month license. With the soft ware, they will also receive tutorials, how-to videos, and a sample project. Students who buy used copies of this text may buy Visible Analyst at full price using the URL provided.

Project Management Soft ware You can download a 60-day trial of Microsoft Project Professional 2013 from the following Web site: www.microsoft .com/en-us/evalcenter/evaluate-project-professional-2013 . Note that Microsoft has changed its policy and no longer off ers the 120-day trial previously available.

Another option now available to education institutions adopting this Wiley titl e is a free introductory 3-year membership for DreamSpark Premium. DreamSpark Premium is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft soft ware available in labs, classrooms, and on student and instructor PCs. Microsoft Project soft ware is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualifi ed Wiley title. Each copy of Microsoft Project is the full version of the soft ware, with no time limitation, and can be used indefi nitely for educational purposes. Contact your Wiley sales representative for details. For more information about the DreamSpark Premium program, contact drmspkna@Microsoft .com .

ACKNOWLEDGMENTS Th anks to Elaine Seeman for her feedback on every chapter in this book as well as for her work writing the new online case study. We would like to thank the following reviewers for their helpful and insightful comments on the fi ft h edition: Mohammad Dadashzadeh, Oakland University; Xiaodong Deng, Oakland University ; Th omas W. Dillon, James Madison University; Bryan Goda, University of Washington, Tacoma; Kathleen S. Hartzel, Duquesne University; Rajkumar Kempaiah, Stevens Institute of Technology; Sung-kwan Kim, University of Arkansas at Little Rock; Richard McCarthy, Quinnipiac University; Donald McCracken, Grantham University; Osama A. Morad, Southern New Hampshire University; Fred Niederman, Saint Louis University; Linda Plotnick, Jacksonville State University; Vladimir V. Riabov, Rivier University ; Richard Schilhavy, Guilford College; Tod Sedbrook, University of Northern Colorado; Steven C. Shaff er, Penn State University; Michael Smith, Georgia Institute of Technology; and John Wetsch, Southern New Hampshire University.

We would also like to thank the following reviewers for their helpful and insight- ful comments on the fi rst, second, third , and fourth editions: Evans Adams, Fort Lewis College; Murugan Anandarajon, Drexel University; Ron Anson, Boise State University; Noushin Ashrafi , University of Massachusetts, Boston; Dirk Baldwin, University of Wisconsin-Parkside; Robert Barker, University of Louisville; Qing Cao, University of Missouri–Kansas City; David Champion, DeVry University, Columbus, OH campus; Jeff Cummings, Indiana University; Junhua Ding, East Carolina University; Robert Dollinger,

x Preface

University of Wisconsin-Stevens Point; Abhijit Dutt, Carnegie Mellon University; Terry Fox, Baylor University; Ahmad Ghafarian, North Georgia College & State U niversity; Donald Golden, Cleve land State University; Cleotilde Gonzalez, Carnegie Melon University; Daniel V. Goulet, University of Wisconsin–Stevens Point; Harvey Hayashi, Loyalist College of Applied Arts and Technology; Yujong Hwang, DePaul University; Scott James, Saginaw Valley State University; Zongliang Jiang, North Carolina A&T State University; Raymond Kirsch, La Salle University; Rajiv Kishore, State University of New York–Buff alo; Ravindra Krovi, University of Akron; Jean-Piere Kuilboer, University of Massachusetts, Boston; Gilliean Lee, Lander University; Leo Legorreta, California State University Sacramento; Diane Lending, James Madison University; Steve Machon, DeVry University; Fernando Maymí , West Point University; Daniel Mittleman, DePaulUniversity; Makoto Nakayama, DePaul University; Fred Niederman, Saint Louis University; Parasuraman Nurani, DeVry University; H. Robert Pajkowski, DeVry Institute of Technology, Scarborough, Ontario; June S. Park, University of Iowa; Graham Peace, West Virginia University; Tom Pettay, DeVry Institute of Technology, Columbus,Ohio; Selwyn Piramuthu, University of Florida; J. Drew Procaccino, Rider University; Neil Ramiller, Portland State University; Eliot Rich, University at Albany, State University of New York; Marcus Rothenberger, University of Wisconsin–Milwaukee; Carl Scott, University of Houston; Keng Siau,University of Nebraska–Lincoln; Ift ikhar Sikder , Cleveland State University; Jonathan Trower, Baylor University; June Verner, Drexel University; Anna Wachholz, Sheridan College; Bill Watson, Indiana University- Purdue University Indianapolis; Randy S.Weinberg, Carnegie Mellon University; Eli J.Weissman, DeVry Institute of Technology, Long Island City, NY; Heinz Roland Weistroff er, Virginia Commonwealth University; Amy Wilson, DeVry Institute of Technology, Decatur, GA; Amy Woszczynski, Kennesaw State University; Vincent C. Yen, Wright State University ; Fan Zhao, Florida Gulf Coast University; and Dan Zhu, Iowa State University.

C O N T E N T S

Preface v

Chapter 1

Introduction to Systems Analysis and Design 1 Introduction 1 The Systems Development Life Cycle 2

Planning 3 Analysis 3 Design 4 Implementation 4

Systems Development Methodologies 5 Structured Design 6 Rapid Application Development (RAD) 8 Agile Development 12 Selecting the Appropriate Development

Methodology 15 Typical Systems Analyst Roles and Skills 17

Business Analyst 18 Systems Analyst 18 Infrastructure Analyst 18 Change Management Analyst 19 Project Manager 19

Basic Characteristics of Object-Oriented Systems 19

Classes and Objects 19 Methods and Messages 20 Encapsulation and Information Hiding 20 Inheritance 21 Polymorphism and Dynamic Binding 22

Object-Oriented Systems Analysis and Design (OOSAD) 23

Use-Case Driven 24 Architecture-Centric 24 Iterative and Incremental 24 Benefi ts of Object-Oriented Systems

Analysis and Design 25 The Unified Process 25

Phases 26 Workfl ows 28 Extensions to the Unifi ed Process 30

The Unified Modeling Language 34 applying the concepts at patterson

superstore 36 Chapter Review 36

Chapter 2

Project Management 41 Introduction 41 Project Identification 43

System Request 44 Feasibility Analysis 45

Technical Feasibility 45 Economic Feasibility 46 Organizational Feasibility 51

Project Selection 53 Traditional Project Management Tools 54

Work Breakdown Structures 55 Gantt Chart 56 Network Diagram 57

Project Effort Estimation 58 Creating and Managing the Workplan 63

Evolutionary Work Breakdown Structures and Iterative Workplans 63

Managing Scope 67 Timeboxing 68 Refi ning Estimates 69 Managing Risk 70

Staffing the Project 71 Characteristics of a Jelled Team 71 Staffi ng Plan 73 Motivation 75 Handling Confl ict 76

Environment and Infrastructure Management 76

CASE Tools 77 Standards 77 Documentation 78

Applying the Concepts at Patterson Superstore 80

Chapter Review 80

■ PART ONE ANALYSIS MODELING 85 Chapter 3

Requirements Determination 86 Introduction 86 Requirements Determination 87

Defi ning a Requirement 87 Requirements Defi nition 89 Determining Requirements 89 Creating a Requirements Defi nition 91 Real-World Problems with Requirements

Determination 91 Requirements Analysis Strategies 92

Problem Analysis 92 Root Cause Analysis 92 Duration Analysis 93 Activity-Based Costing 94 Informal Benchmarking 94 Outcome Analysis 95 Technology Analysis 95 Activity Elimination 95

Requirements-Gathering Techniques 95 Interviews 96 Joint Application Development (JAD) 100 Questionnaires 104 Document Analysis 106 Observation 108 Selecting the Appropriate Techniques 108

Alternative Requirements Documentation Techniques 110

Concept Maps 110 User Stories 112

The System Proposal 113 Applying the Concepts at Patterson

Superstore 114 Chapter review 114

Chapter 4 Business Process and Functional Modeling 119 Introduction 119 Business Process Identification with Use

Cases and Use-Case Diagrams 121 Elements of Use-Case Diagrams 121 Identifying the Major Use Cases 126

Creating a Use-Case Diagram 127 Business Process Modeling with Activity

Diagrams 129 Elements of an Activity Diagram 131 Guidelines for Creating Activity

Diagrams 136 Creating Activity Diagrams 137

Business Process Documentation with Use Cases and Use-Case Descriptions 140

Types of Use Cases 141 Elements of a Use-Case Description 141 Guidelines for Creating Use-Case

Descriptions 145 Creating Use Case Descriptions 146

Verifying and Validating the Business Processes and Functional Models 153

Verifi cation and Validation through Walkthroughs 153

Functional Model Verifi cation and Validation 154

Applying the Concepts at Patterson Superstore 157

Chapter Review 157

Chapter 5

Structural Modeling 163 Introduction 163 Structural Models 164

Classes, Attributes, and Operations 164

Relationships 165 Object Identification 166

Textual Analysis 166 Brainstorming 167 Common Object Lists 169 Patterns 169

Crc Cards 172 Responsibilities and Collaborations 172 Elements of a CRC Card 173 Role-Playing CRC Cards with

Use Cases 174 Class Diagrams 176

Elements of a Class Diagram 176 Simplifying Class Diagrams 184 Object Diagrams 184

Creating Structural Models Using CRC Cards and Class Diagrams 185

Campus Housing Example 187 Library Example 187

xii Contents

Verifying and Validating the Structural Model 194

Applying the Concepts at Patterson Superstore 197

Chapter Review 198

Chapter 6

Behavioral Modeling 202 Introduction 202 Behavioral Models 203 Interaction Diagrams 204

Objects, Operations, and Messages 204 Sequence Diagrams 204 Communication Diagrams 216

Behavioral State Machines 221 States, Events, Transitions, Actions, and

Activities 221 Elements of a Behavioral State Machine 222 Creating a Behavioral State Machine 226

Crude Analysis 229 Verifying and Validating the Behavioral

Model 233 Applying the Concepts at Patterson

Superstore 235 Chapter Review 235

■ PART TWO DESIGN MODELING 239 Chapter 7

Moving on to Design 240 Introduction 240 Verifying and Validating the Analysis

Models 242 Balancing Functional and Structural

Models 242 Balancing Functional and Behavioral

Models 243 Balancing Structural and Behavioral

Models 251 Summary 254

Evolving the Analysis Models into Design Models 257

Factoring 257 Partitions and Collaborations 258 Layers 259

Packages and Package Diagrams 262 Guidelines for Creating Package

Diagrams 264 Creating Package Diagrams 266 Verifying and Validating Package

Diagrams 266 Design Strategies 268

Custom Development 268 Packaged Soft ware 269 Outsourcing 270 Selecting a Design Strategy 272

Selecting an Acquisition Strategy 273 Alternative Matrix 274

Applying the Concepts at Patterson Superstore 276

Chapter Review 276

Chapter 8

Class and Method Design 280 Introduction 280 Review of the Basic Characteristics

of Object Orientation 282 Classes, Objects, Methods, and Messages 282 Encapsulation and Information Hiding 282 Polymorphism and Dynamic Binding 282 Inheritance 284

Design Criteria 286 Coupling 286 Cohesion 289 Connascence 292

Object Design Activities 293 Adding Specifi cations 293 Identifying Opportunities for Reuse 294 Restructuring the Design 297 Optimizing the Design 298 Mapping Problem-Domain Classes to

Implementation Languages 300 Constraints and Contracts 304

Types of Constraints 306 Elements of a Contract 306

Method Specification 314 General Information 314 Events 314 Message Passing 315 Algorithm Specifi cations 316 Example 318

Verifying and Validating Class and Method Design 319

Contents xiii

Applying the Concepts at Patterson Superstore 322

Chapter review 322

Chapter 9

Data Management Layer Design 326 Introduction 326 Object Persistence Formats 327

Sequential and Random Access Files 327 Relational Databases 330 Object-Relational Databases 332 Object-Oriented Databases 332 NoSQL Data Stores 333 Selecting an Object Persistence Format 335

Mapping Problem Domain Objects to Object Persistence Formats 337

Mapping Problem Domain Objects to an OODBMS Format 338

Mapping Problem Domain Objects to an ORDBMS Format 341

Mapping Problem Domain Objects to a RDBMS Format 344

Optimizing Rdbms-Based Object Storage 346

Optimizing Storage Effi ciency 347 Optimizing Data Access Speed 351 Estimating Data Storage Size 356

Designing Data Access and Manipulation Classes 357

Nonfunctional Requirements and Data Management Layer Design 360

Verifying and Validating the Data Management Layer 361

Applying the Concepts at Patterson Superstore 362

Chapter Review 362

Chapter 10

Human–Computer Interaction Layer Design 367 Iintroduction 367 Principles for User Interface Design 368

Layout 369 Content Awareness 369

Aesthetics 370 User Experience 371 Consistency 371 Minimizing User Eff ort 372

User Interface Design Process 372 Use Scenario Development 373 Navigation Structure Design 375 Interface Standards Design 376 Interface Design Prototyping 377 Interface Evaluation 380 Common Sense Approach to User

Interface Design 382 Navigation Design 383

Basic Principles 383 Types of Navigation Controls 384 Messages 386 Navigation Design Documentation 387

Input Design 387 Basic Principles 387 Types of Inputs 390 Input Validation 391

Output Design 392 Basic Principles 392 Types of Outputs 394 Media 394

Mobile Computing and User Interface Design 395

Social Media and User Interface Design 398

Games, Multi-Dimensional Information Visualizations, and Immersive Environments 400

Games, Gamifi cation, and User Interface Design 400

Multidimensional Information Visualization Design 402

User Interface Design and Immersive Environments 404

International and Cultural Issues and User Interface Design 406

Multilingual Requirements 406 Color 407 Cultural Diff erences 407

Nonfunctional Requirements And Human- Computer Interaction Layer Design 410

Applying The Concepts At Patterson Superstore 411

Chapter review 411

xiv Contents

Chapter 11

Physical Architecture Layer Design 418 Introduction 418 Elements of the Physical Architecture

Layer 419 Architectural Components 419 Server-Based Architectures 420 Client-Based Architectures 420 Client–Server Architectures 421 Client–Server Tiers 422 Selecting a Physical Architecture 424

Cloud Computing 426 Ubiquitous Computing and the Internet

of Things 428 Green IT 431 Infrastructure Design 432

Deployment Diagram 432 Network Model 434

Hardware and System Software Specifications 438

Nonfunctional Requirements and Physical Architecture Layer Design 440

Operational Requirements 441 Performance Requirements 442 Security Requirements 444 Cultural and Political Requirements 447 Synopsis 448

Verifying and Validating the Physical Architecture Layer 449

Applying the Concepts at Patterson Superstore 450

Chapter Review 450

■ PART THREE CONSTRUCTION, INSTALLATION, AND OPERATIONS 455 Chapter 12

Construction 456 Introduction 456 Managing Programming 457

Assigning Programmers 457 Coordinating Activities 458

Managing the Schedule 458 Cultural Issues 460

Developing Documentation 462 Types of Documentation 463 Designing Documentation Structure 463 Writing Documentation Topics 465 Identifying Navigation Terms 465

Designing Tests 467 Testing and Object Orientation 468 Test Planning 469 Unit Tests 471 Integration Tests 475 System Tests 476 Acceptance Tests 477

Applying the Concepts at Patterson Superstore 478

Chapter Review 478

Chapter 13

Installation and Operations 481 Introduction 481 Cultural Issues and Information

Technology Adoption 483 Conversion 485

Conversion Style 486 Conversion Location 486 Conversion Modules 487 Selecting the Appropriate Conversion

Strategy 488 Change Management 489

Understanding Resistance to Change 490 Revising Management Policies 491 Assessing Costs and Benefi ts 492 Motivating Adoption 493 Enabling Adoption: Training 495

Post-Implementation Activities 497 System Support 497 System Maintenance 498 Project Assessment 500

Applying the Concepts at Patterson Superstore 502

Chapter Review 502

Index 507

Contents xv

Chapter 1 introduces the systems development life cycle (SDLC), the fundamental four- phase model (planning, analysis, design, and implementation) common to all information systems development projects. It describes the evolution of system development method- ologies and discusses the roles and skills required of a systems analyst. Th e chapter then overviews the basic characteristics of object-oriented systems and the fundamentals of object-oriented systems analysis and design and closes with a description of the Unifi ed Process and its extensions and the Unifi ed Modeling Language.

OBJECTIVES

■ Understand the fundamental systems development life cycle and its four phases ■ Understand the evolution of systems development methodologies ■ Be familiar with the diff erent roles played by and the skills of a systems analyst ■ Be familiar with the basic characteristics of object-oriented systems ■ Be familiar with the fundamental principles of object-oriented systems analysis

and design ■ Be familiar with the Unifi ed Process, its extensions, and the Unifi ed Modeling

Language

INTRODUCTION The systems development life cycle (SDLC) is the process of understanding how an infor- mation system (IS) can support business needs by designing a system, building it, and delivering it to users. If you have taken a programming class or have programmed on your own, this probably sounds pretty simple. Unfortunately, it is not. A 1996 survey by the Standish Group found that 42 percent of all corporate IS projects were abandoned before completion. A similar study conducted in 1996 by the General Accounting Office found 53 percent of all U.S. government IS projects were abandoned. Unfortunately, many of the systems that are not abandoned are delivered to the users significantly late, cost far more than planned, and have fewer features than originally planned. For exam- ple, IAG Consulting reports that 80 percent of the projects were over time, 72 percent were over budget, and 55 percent contained less than the full functionality; Panorama Consulting Solutions reports that 54 percent of the ERP projects were over time, 56 percent were over budget, and 48 percent delivered less than 50 percent of the initial benefi ts; and an IBM study reports that 59 percent of the projects missed one or more of on time, within budget, and quality constraints.1 Although we would like to promote this book as a silver bullet that will keep you from IS failures, we readily admit that a silver bullet that guarantees IS development success simply does not exist. Instead, this book provides you

C H A P T E R 1

Introduction to Systems Analysis and Design

2 Chapter 1 Introduction to Systems Analysis and Design

with several fundamental concepts and many practical techniques that you can use to improve the probability of success.

Th e key person in the SDLC is the systems analyst, who analyzes the business situation, identifi es opportunities for improvements, and designs an information system to implement them. Being a systems analyst is one of the most interesting, exciting, and challenging jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifi cally, they work with a team of systems analysts, programmers, and others on a com- mon mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a signifi cant business impact, knowing that they contributed unique skills to make that happen.

However, the primary objective of a systems analyst is not to create a wonderful sys- tem; instead, it is to create value for the organization, which for most companies means increasing profi ts (government agencies and not-for-profi t organizations measure value diff erently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fi t with an organi- zation’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment. Th e goal is not to acquire the tool, because the tool is simply a means to an end; the goal is to enable the organization to perform work better so that it can earn greater profi ts or serve its constit- uents more eff ectively.

Th is book introduces the fundamental skills a systems analyst needs. Th is pragmatic book discusses best practices in systems development; it does not present a general survey of systems development that covers everything about the topic. By defi nition, systems analysts do things and challenge the current way that organizations work. To get the most out of this book, you will need to actively apply to your own systems development project the ideas and concepts in the examples. Th is book guides you through all the steps for delivering a successful informa- tion system. By the time you fi nish the book, you won’t be an expert analyst, but you will be ready to start building systems for real.

THE SYSTEMS DEVELOPMENT LIFE CYCLE In many ways, building an information system is similar to building a house. First, the house (or the information system) starts with a basic idea. Second, this idea is transformed into a simple drawing that is shown to the customer and refi ned (oft en through several drawings, each improving on the last) until the customer agrees that the picture depicts what he or she wants. Th ird, a set of blueprints is designed that presents much more detailed information about the house (e.g., the type of water faucets or where the telephone jacks will be placed). Finally, the house is built following the blueprints, oft en with some changes directed by the customer as the house is erected.

Th e SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Diff erent projects might emphasize diff erent parts of the SDLC or approach the SDLC phases in diff erent ways, but all projects have elements of these four phases. Each phase is itself composed of a series of steps, which rely upon techniques that produce deliverables (specifi c documents and fi les that provide understanding about the project).

1 For more information on the problem, see Capers Jones, Patterns of Soft ware System Failure and Success (London: International Th ompson Computer Press, 1996); KeithEllis, Business Analysis Benchmark: Th e Impact of Business Requirements on the Success of Technology Projects (2008). Retrieved May 2014 from IAG Consulting, www.iag.biz; H. H. Jorgensen, L. Owen, and A. Neus, Making Change Work (2008). Retrieved May 2014 from IBM, www.ibm. com; Panorama Consulting Solutions, 2012 ERP Report (2012). Retrieved May 2014 from Panorama- Consulting.com.

The Systems Development Life Cycle 3

For example, in applying for admission to a university, all students go through the same phases: information gathering, applying, and accepting. Each of these phases has steps; for example, information gathering includes steps such as searching for schools, requesting infor- mation, and reading brochures. Students then use techniques (e.g., Internet searching) that can be applied to steps (e.g., requesting information) to create deliverables (e.g., evaluations of diff erent aspects of universities).

In many projects, the SDLC phases and steps proceed in a logical path from start to fi n- ish. In other projects, the project teams move through the steps consecutively, incrementally, iteratively, or in other patterns. In this section, we describe the phases, the actions, and some of the techniques that are used to accomplish the steps at a very high level.

For now, there are two important points to understand about the SDLC. First, you should get a general sense of the phases and steps through which IS projects move and some of the techniques that produce certain deliverables. Second, it is important to understand that the SDLC is a process of gradual refi nement. Th e deliverables produced in the analysis phase pro- vide a general idea of the shape of the new system. Th ese deliverables are used as input to the design phase, which then refi nes them to produce a set of deliverables that describes in much more detailed terms exactly how the system will be built. Th ese deliverables, in turn, are used in the implementation phase to produce the actual system. Each phase refi nes and elaborates on the work done previously.

Planning Th e planning phase is the fundamental process of understanding why an information sys- tem should be built and determining how the project team will go about building it. It has two steps:

1. During project initiation, the system’s business value to the organization is identifi ed: How will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area (e.g., from the marketing department, accounting department) in the form of a system request. A system request presents a brief summary of a business need, and it explains how a system that supports the need will create business value. Th e IS department works together with the person or department that generated the request (called the project sponsor) to conduct a feasibility analysis.

Th e system request and feasibility analysis are presented to an information sys- tems approval committee (sometimes called a steering committee), which decides whether the project should be undertaken.

2. Once the project is approved, it enters project management. During project man- agement, the project manager creates a workplan, staff s the project, and puts tech- niques in place to help the project team control and direct the project through the entire SDLC. Th e deliverable for project management is a project plan, which describes how the project team will go about developing the system.

Analysis Th e analysis phase answers the questions of who will use the system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifi es opportunities for improvement, and develops a concept for the new system. Th is phase has three steps:

1. An analysis strategy is developed to guide the project team’s eff orts. Such a strategy usually includes an analysis of the current system (called the as-is system) and its problems and then ways to design a new system (called the to-be system).

4 Chapter 1 Introduction to Systems Analysis and Design

2. Th e next step is requirements gathering (e.g., through interviews or questionnaires). Th e analysis of this information—in conjunction with input from the project sponsor and many other people—leads to the development of a concept for a new system. Th e system concept is then used as a basis to develop a set of business analysis models, which describe how the business will operate if the new system is developed.

3. Th e analyses, system concept, and models are combined into a document called the system proposal, which is presented to the project sponsor and other key deci- sion makers (e.g., members of the approval committee) who decide whether the project should continue to move forward.

Th e system proposal is the initial deliverable that describes what business requirements the new system should meet. Because it is really the fi rst step in the design of the new system, some experts argue that it is inappropriate to use the term “analysis” as the name for this phase; some argue a better name would be “analysis and initial design.” Most organizations continue to use the name analysis for this phase, however, so we use it in this book as well. Just keep in mind that the deliverable from the analysis phase is both an analysis and a high-level initial design for the new system.

Design Th e design phase decides how the system will operate, in terms of the hardware, soft ware, and network infrastructure; the user interface, forms, and reports; and the specifi c programs, databases, and fi les that will be needed. Although most of the strategic decisions about the system were made in the development of the system concept during the analysis phase, the steps in the design phase determine exactly how the system will operate. Th e design phase has four steps:

1. Th e design strategy is fi rst developed. It clarifi es whether the system will be devel- oped by the company’s own programmers, whether the system will be outsourced to another fi rm (usually a consulting fi rm), or whether the company will buy an existing soft ware package.

2. Th is leads to the development of the basic architecture design for the system, which describes the hardware, soft ware, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. Th e interface design specifi es how the users will move through the sys- tem (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use.

3. Th e database and fi le specifi cations are developed. Th ese defi ne exactly what data will be stored and where they will be stored.

4. Th e analyst team develops the program design, which defi nes the programs that need to be written and exactly what each program will do.

Th is collection of deliverables (architecture design, interface design, database and fi le specifi ca- tions, and program design) is the system specifi cation that is handed to the programming team for implementation. At the end of the design phase, the feasibility analysis and project plan are reexamined and revised, and another decision is made by the project sponsor and approval committee about whether to terminate the project or continue.

Implementation Th e fi nal phase in the SDLC is the implementation phase, during which the system is actually built (or purchased, in the case of a packaged soft ware design). Th is is the phase that usually

Systems Development Methodologies 5

2 Th e classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Englewood Cliff s, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engi- neering; see James Martin, Information Engineering, vols. 1–3 (Englewood Cliff s, NJ: Prentice Hall, 1989). A widely accepted standardized non–object-oriented methodology that balances processes and data is IDEF; see FIPS 183, Integration Defi nition for Function Modeling, Federal Information Processing Standards Publications, U.S. Depart- ment of Commerce, 1993. 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).

gets the most attention, because for most systems it is the longest and most expensive single part of the development process. Th is phase has three steps:

1. System construction is the fi rst step. Th e system is built and tested to ensure that it performs as designed. Because the cost of bugs can be immense, testing is one of the most critical steps in implementation. Most organizations give more time and attention to testing than to writing the programs in the fi rst place.

2. Th e system is installed. Installation is the process by which the old system is turned off and the new one is turned on. One of the most important aspects of conversion is the development of a training plan to teach users how to use the new system and help manage the changes caused by the new system.

3. Th e analyst team establishes a support plan for the system. Th is plan usually includes a formal or informal post-implementation review as well as a systematic way for identifying major and minor changes needed for the system.

SYSTEMS DEVELOPMENT METHODOLOGIES A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). Th ere are many diff erent systems development methodologies, and each one is unique, based on the order and focus it places on each SDLC phase. Some methodolo- gies are formal standards used by government agencies, whereas others have been developed by consulting fi rms to sell to clients. Many organizations have internal methodologies that have been honed over the years, and they explain exactly how each phase of the SDLC is to be performed in that company.

Th ere are many ways to categorize methodologies. One way is by looking at whether they focus on business processes or the data that support the business. A process-centered methodology emphasizes process models as the core of the system concept. In Figure 1-1, for example, process-centered methodologies would focus fi rst on defi ning the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data models as the core of the system concept. In Figure 1-1, data-centered methodologies would focus fi rst on defi ning the contents of the storage areas (e.g., refrigerator) and how the contents were organ- ized.2 By contrast, object-oriented methodologies attempt to balance the focus between process and data by incorporating both into one model. In Figure 1-1, these methodologies would focus fi rst on defi ning the major elements of the system (e.g., sandwiches, lunches) and look at the processes and data involved with each element.

Another important factor in categorizing methodologies is the sequencing of the SDLC phases and the amount of time and eff ort devoted to each.3 In the early days of computing, programmers did not understand the need for formal and well-planned life-cycle meth- odologies. Th ey tended to move directly from a very simple planning phase right into the construction step of the implementation phase—in other words, from a very fuzzy, not-well- thought-out system request into writing code. Th is is the same approach that you sometimes use when writing programs for a programming class. It can work for small programs that

6 Chapter 1 Introduction to Systems Analysis and Design

require only one programmer, but if the requirements are complex or unclear, you might miss important aspects of the problem and have to start all over again, throwing away part of the program (and the time and eff ort spent writing it). Th is approach also makes teamwork diffi cult because members have little idea about what needs to be accomplished and how to work together to produce a fi nal product. In this section, we describe three diff erent classes of system development methodologies: structured design, rapid application development, and agile development.

Structured Design Th e fi rst category of systems development methodologies is called structured design. Th ese methodologies became dominant in the 1980s, replacing the previous ad hoc and

FIGURE 1-1 A Simple Behavioral Model for Making a Simple Lunch

GetJelly

GetPeanutButter

GetCookies

GetBread

CreateSandwich

GetMilk

CreateLunch

GetLunchBag

PutLunchInBag

aParent aRefrigerator aCupboard aSandwich aLunch aLunchBag

Systems Development Methodologies 7

undisciplined approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Numerous pro- cess-centered and data-centered methodologies follow the basic approach of the two struc- tured design categories outlined next.

Waterfall Development Th e original structured design methodology (still used today) is waterfall development. With waterfall development-based methodologies, the analysts and users proceed in sequence from one phase to the next (see Figure 1-2). Th e key deliverables for each phase are typically very long (oft en hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase. Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins. Th is methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. Although it is possible to go backward in the SDLC (e.g., from design back to analysis), it is extremely diffi cult (imagine yourself as a salmon trying to swim upstream against a waterfall, as shown in Figure 1-2).

Structured design also introduced the use of formal modeling or diagramming tech- niques to describe the basic business processes and the data that support them. Traditional structured design uses one set of diagrams to represent the processes and a separate set of diagrams to represent data. Because two sets of diagrams are used, the systems analyst must decide which set to develop fi rst and use as the core of the system: process-model diagrams or data-model diagrams.

Th e two key advantages of the structured design waterfall approach are that it identi- fi es system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. Th e two key disadvantages are that the design must be completely specifi ed before programming begins and that a long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usu- ally many months or years). If the project team misses important requirements, expensive post-implementation programming may be needed (imagine yourself trying to design a car on paper; how likely would you be to remember interior lights that come on when the doors open or to specify the right number of valves on the engine?). A system can also require signifi cant rework because the business environment has changed from the time when the analysis phase occurred.

FIGURE 1-2 A Waterfall Development-Based Methodology

System

Planning

Analysis

Design

Implementation

8 Chapter 1 Introduction to Systems Analysis and Design

Parallel Development Parallel development methodology attempts to address the problem of long delays between the analysis phase and the delivery of the system. Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. Once all subprojects are complete, the separate pieces are integrated and the system is delivered (see Figure 1-3).

Th e primary advantage of this methodology is that it can reduce the time to deliver a system; thus, there is less chance of changes in the business environment causing rework. However, sometimes the subprojects are not completely independent; design decisions made in one subproject can aff ect another, and the end of the project can require signifi cant integration eff orts.

Rapid Application Development (RAD) A second category of methodologies includes rapid application development (RAD)-based methodologies. Th ese are a newer class of systems development methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system devel- oped quickly and into the hands of the users. In this way, the users can better understand the system and suggest revisions that bring the system closer to what is needed.4

4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996).

FIGURE 1-3 A Parallel Development-Based Methodology

System

Planning

Analysis

Design

Implementation

Design

Integration

Implementation

Design

Implementation

Design

Subproject 2

Subproject 1

Subproject 3

Systems Development Methodologies 9

Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as computer-aided soft ware engineering (CASE) tools, joint application design (JAD) sessions, fourth-generation or visual programming languages that simplify and speed up programming, and code generators that automatically produce programs from design specifi cations. Th e combination of the changed SDLC phases and the use of these tools and techniques improves the speed and quality of systems development. However, there is one possible subtle problem with RAD-based methodologies: managing user expectations. Owing to the use of the tools and techniques that can improve the speed and quality of systems development, user expectations of what is possible can change dramatically. As a user better understands the information tech- nology (IT), the systems requirements tend to expand. Th is was less of a problem when using methodologies that spent a lot of time thoroughly documenting requirements.

Phased Development A phased development-based methodology breaks an overall system into a series of versions that are developed sequentially. Th e analysis phase identifi es the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. Th e most important and fundamental requirements are bundled into the fi rst version of the system. Th e analysis phase then leads into design and implementation—but only with the set of requirements identifi ed for version 1 (see Figure 1-4).

Once version 1 is implemented, work begins on version 2. Additional analysis is per- formed based on the previously identifi ed requirements and combined with new ideas and issues that arose from the users’ experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. Th is process continues until the system is complete or is no longer in use.

Phased development-based methodologies have the advantage of quickly getting a useful system into the hands of the users. Although the system does not perform all the functions the users need at fi rst, it does begin to provide business value sooner than if the system were deliv- ered aft er completion, as is the case with the waterfall and parallel methodologies. Likewise, because users begin to work with the system sooner, they are more likely to identify important additional requirements sooner than with structured design situations.

Th e major drawback to phased development is that users begin to work with systems that are intentionally incomplete. It is critical to identify the most important and useful features and include them in the fi rst version and to manage users’ expectations along the way.

Prototyping A prototyping-based methodology performs the analysis, design, and imple- mentation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. With these methodologies, the basics of analysis and design are performed, and work immediately begins on a system prototype, a quick-and-dirty program that provides a minimal amount of features. Th e fi rst prototype is usually the fi rst part of the system that is used. Th is is shown to the users and the project sponsor, who provide com- ments. Th ese comments are used to reanalyze, redesign, and reimplement a second prototype, which provides a few more features. Th is process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. Aft er the prototype (now called the “system”) is installed, refi nement occurs until it is accepted as the new system (see Figure 1-5).

Th e key advantage of a prototyping-based methodology is that it very quickly provides a system with which the users can interact, even if it is not ready for widespread organizational use at fi rst. Prototyping reassures the users that the project team is working on the system (there are no long delays in which the users see little progress), and prototyping helps to more quickly refi ne real requirements.

10 Chapter 1 Introduction to Systems Analysis and Design

FIGURE 1-4 A Phased Development-Based Methodology

System version 1

Planning

Analysis

Implementation

Design

Analysis

Implementation

Design

Analysis

Implementation

Design

System version 2

System version 3

FIGURE 1-5 A Prototyping-Based Methodology

System prototype

System

Planning

Analysis

Design

Implementation

Systems Development Methodologies 11

Th e major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Oft en the prototype undergoes such signif- icant changes that many initial design decisions become poor ones. Th is can cause problems in the development of complex systems because fundamental issues and problems are not rec- ognized until well into the development process. Imagine building a car and discovering late in the prototyping process that you have to take the whole engine out to change the oil (because no one thought about the need to change the oil until aft er it had been driven 10,000 miles).

Throwaway Prototyping Th rowaway prototyping-based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes; how- ever, throwaway prototypes are done at a diff erent point in the SDLC. Th ese prototypes are used for a very diff erent purpose than those previously discussed, and they have a very diff er- ent appearance (see Figure 1-6).

Th e throwaway prototyping-based methodologies have a relatively thorough analy- sis phase that is used to gather information and to develop ideas for the system concept. However, users might not completely understand many of the features they suggest, and there may be challenging technical issues to be solved. Each of these issues is examined by analyz- ing, designing, and building a design prototype. A design prototype is not a working system; it is a product that represents a part of the system that needs additional refi nement, and it contains only enough detail to enable users to understand the issues under consideration. For example, suppose users are not completely clear on how an order-entry system should work. In this case, a series of mock-up screens appear to be a system, but they really do nothing. Or suppose that the project team needs to develop a sophisticated graphics program in Java. Th e team could write a portion of the program with pretend data to ensure that they could do a full-blown program successfully.

A system developed using this type of methodology relies on several design prototypes during the analysis and design phases. Each of the prototypes is used to minimize the risk associated with the system by confi rming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and implementa- tion. At this point, the design prototypes are thrown away, which is an important diff erence between these methodologies and prototyping methodologies, in which the prototypes evolve into the fi nal system.

FIGURE 1-6 A Throwaway Prototyping-Based Methodology

Design prototype

System

Analysis

Design

Implementation

Planning

Implementation

Design

12 Chapter 1 Introduction to Systems Analysis and Design

Th rowaway prototyping-based methodologies balance the benefi ts of well-thought-out analysis and design phases with the advantages of using prototypes to refi ne key issues before a system is built. It can take longer to deliver the fi nal system as compared to prototyping- based methodologies, but this type of methodology usually produces more stable and reliable systems.

Agile Development5 A third category of systems development methodologies is still emerging today: agile devel- opment. All agile development methodologies are based on the agile manifesto and a set of twelve principles. Th e emphasis of the manifesto is to focus the developers on the working conditions of the developers, the working soft ware, the customers, and addressing changing requirements instead of focusing on detailed systems development processes, tools, all- inclusive documentation, legal contracts, and detailed plans. Th ese programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. Th ese meth- odologies are typically based only on the twelve principles of agile soft ware. Th ese principles include the following:

■ Soft ware is delivered early and continuously through the development process, satis- fying the customer.

■ Changing requirements are embraced regardless of when they occur in the develop- ment process.

■ Working soft ware is delivered frequently to the customer. ■ Customers and developers work together to solve the business problem. ■ Motivated individuals create solutions; provide them the tools and environment they

need, and trust them to deliver. ■ Face-to-face communication within the development team is the most effi cient and

eff ective method of gathering requirements. ■ Th e primary measure of progress is working, executing soft ware. ■ Both customers and developers should work at a pace that is sustainable. Th at is, the

level of work could be maintained indefi nitely without any worker burnout. ■ Agility is heightened through attention to both technical excellence and good design. ■ Simplicity, the avoidance of unnecessary work, is essential. ■ Self-organizing teams develop the best architectures, requirements, and designs. ■ Development teams regularly refl ect on how to improve their development

processes. Based on these principles, agile methodologies focus on streamlining the system-development process by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Instead, projects emphasize simple, iterative application development.6 All agile development methodologies follow a simple cycle through the traditional phases of the systems development process (see Figure 1-7). Virtually all agile methodologies are used in conjunction with object-oriented technologies.

5 Th ree good sources of information on agile development and object-oriented systems are S. W. Ambler, Agile Modeling: Eff ective Practices for Extreme Programming and the Unifi ed Process (New York: Wiley, 2002); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); R. C. Martin, Agile Soft ware Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 6 See Agile Alliance, www.agilealliance.com.

Systems Development Methodologies 13

However, agile methodologies do have critics. One of the major criticisms deals with today’s business environment, where much of the actual information systems development is off shored, outsourced, and/or subcontracted. Given agile development methodologies requiring co-location of the development team, this seems to be a very unrealistic assump- tion. A second major criticism is that if agile development is not carefully managed, and by defi nition it is not, the development process can devolve into a prototyping approach that essentially becomes a “programmers gone wild” environment where programmers attempt to hack together solutions. A third major criticism, based on the lack of actual documen- tation created during the development of the soft ware, raises issues regarding the auditability of the systems being created. Without suffi cient documentation, neither the system nor the systems-development process can be assured. A fourth major criticism is based on whether agile approaches can deliver large mission-critical systems.

Even with these criticisms, given the potential for agile approaches to address the application backlog and to provide timely solutions to many business problems, agile approaches should be considered in some circumstances. Furthermore, many of the tech- niques encouraged by attending to the underlying purpose of the agile manifesto and the set of twelve agile principles are very useful in object-oriented systems development. Two of the more popular examples of agile development methodologies are extreme programming (XP) and Scrum.

Extreme Programming7 Extreme programming (XP) is founded on four core values: com- munication, simplicity, feedback, and courage. Th ese four values provide a foundation that XP developers use to create any system. First, the developers must provide rapid feedback to the end users on a continuous basis. Second, XP requires developers to follow the KISS principle.8 Th ird, developers must make incremental changes to grow the system, and they must not only accept change, they must embrace change. Fourth, developers must have a quality-fi rst mentality. XP also supports team members in developing their own skills. Th ree of the key principles that XP uses to create successful systems are continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build sys- tems very quickly.

7 For more information, see K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison- Wesley, 2000); C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004); M. Lippert, S. Roock, and H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (New York: Wiley, 2002); www.extremeprogramming.org. 8 Keep it simple, stupid.

FIGURE 1-7 Typical Agile Development Methodology

Implementation

Design

Analysis

System

Planning

14 Chapter 1 Introduction to Systems Analysis and Design

Testing and effi cient coding practices are the core of XP. Code is tested each day and is placed into an integrative testing environment. If bugs exist, the code is backed out until it is completely free of errors.

An XP project begins with user stories that describe what the system needs to do. Th en, programmers code in small, simple modules and test to meet those needs. Users are required to be available to clear up questions and issues as they arise. Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system.

XP adherents claim many strengths associated with developing soft ware using XP. Programmers work closely with all stakeholders, and communication among all stakehold- ers is improved. Continuous testing of the evolving system is encouraged. Th e system is developed in an evolutionary and incremental manner, which allows the requirements to evolve as the stakeholders understand the potential that the technology has in providing a solution to their problem. Estimation is task driven and is performed by the programmer who will implement the solution for the task under consideration. Because all programming is done in pairs, a shared responsibility for each soft ware component develops among the programmers. Finally, the quality of the fi nal product increases during each iteration.

For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fi ne. However, if the project is not small or the teams aren’t jelled,9 the suc- cess of an XP development eff ort is doubtful. Th is tends to throw into doubt the whole idea of bringing outside contractors into an existing team environment using XP.10 Th e chance of outsiders jelling with insiders might simply be too optimistic. XP requires a great deal of discipline, otherwise projects will become unfocused and chaotic. XP is recommended only for small groups of developers—no more than ten developers—and it is not advised for large mission-critical applications. Owing to the lack of analysis and design documentation, there is only code documentation associated with XP, so maintaining large systems built with XP may be impossible. And because mission-critical business information systems tend to exist for a long time, the utility of XP as a business information system development methodology is in doubt. Finally, the methodology needs a lot of on-site user input, something to which many business units cannot commit.11 However, some of the techniques associated with XP are useful in object-oriented systems development. For example, user stories, pair pro- gramming, and continuous testing are invaluable tools from which object-oriented systems development could benefi t.

Scrum12 Scrum is a term that is well known to rugby fans. In rugby, a scrum is used to restart a game. In a nutshell, the creators of the Scrum method believe that no matter how much you plan, as soon as the soft ware begins to be developed, chaos breaks out and the

9 A jelled team is one that has low turnover, a strong sense of identity, a sense of eliteness, a feeling that they jointly own the product being developed, and enjoyment in working together. For more information regarding jelled teams, see T. DeMarco and T. Lister, Peopleware: Productive Projects and Teams (New York: Dorset/House, 1987). 10 Considering the tendency for off shore outsourcing, this is a major obstacle for XP to overcome. For more infor- mation on off shore outsourcing, see P. Th ibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computerworld Morning Update (September 25, 2003); S. W. Ambler, “Chicken Little Was Right,” Soft ware Development (October 2003). 11 Many of the observations on the utility of XP as a development approach were based on conversations with Brian Henderson-Sellers. 12 For more information, see C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison- Wesley, 2004); K. Schwaber and M. Beedle, Agile Soft ware Development with Scrum (Upper Saddle River, NJ: Prentice Hall, 2001); R. Wysocki, Eff ective Project Management: Traditional, Agile, Extreme, 5th Ed. (Indianapolis, IN: Wiley Publishing, 2009).

Systems Development Methodologies 15

plans go out the window.13 Th e best you can do is to react to where the proverbial rugby ball squirts out. You then sprint with the ball until the next scrum. In the case of the Scrum methodology, a sprint lasts thirty working days. At the end of the sprint, a system is deliv- ered to the customer.

Of all systems development approaches, on the surface, Scrum is the most chaotic. To control some of the innate chaos, Scrum development focuses on a few key practices. Teams are self-organized and self-directed. Unlike other approaches, Scrum teams do not have a des- ignated team leader. Instead, teams organize themselves in a symbiotic manner and set their own goals for each sprint (iteration). Once a sprint has begun, Scrum teams do not consider any additional requirements. Any new requirements that are uncovered are placed on a back- log of requirements that still need to be addressed. At the beginning of every workday, a Scrum meeting takes place. At the end of each sprint, the team demonstrates the soft ware to the client. Based on the results of the sprint, a new plan is begun for the next sprint.

Scrum meetings are one of the most interesting aspects of the Scrum development pro- cess. Th e team members attend the meetings, but anyone can attend. However, with very few exceptions, only team members may speak. One prominent exception is management providing feedback on the business relevance of the work being performed by the specifi c team. In this meeting, all team members stand in a circle and report on what they accom- plished during the previous day, state what they plan to do today, and describe anything that blocked progress the previous day. To enable continuous progress, any block identifi ed is dealt with within one hour. From a Scrum point of view, it is better to make a “bad” deci- sion about a block at this point in development than to not make a decision. Because the meetings take place each day, a bad decision can easily be undone. Larman14 suggests that each team member should report any additional requirements that have been uncovered during the sprint and anything that the team member learned that could be useful for other team members to know.

One of the major criticisms of Scrum, as with all agile methodologies, is that it is ques- tionable whether Scrum can scale up to develop very large, mission-critical systems. A typical Scrum team size is no more than seven members. Th e only organizing principle put forth by Scrum followers to address this criticism is to organize a scrum of scrums. Each team meets every day, and aft er the team meeting takes place, a representative (not leader) of each team attends a scrum-of-scrums meeting. Th is continues until the progress of entire system has been determined. Depending on the number of teams involved, this approach to managing a large project is doubtful. However, as in XP and other agile development approaches, many of the ideas and techniques associated with Scrum development are useful in object-oriented systems development, such as the focus of a Scrum meeting, the evolutionary and incremen- tal approach to identifying requirements, and the incremental and iterative approach to the development of the system.

Selecting the Appropriate Development Methodology Because there are many methodologies, the fi rst challenge faced by analysts is selecting which methodology to use. Choosing a methodology is not simple, because no one methodology is always best. (If it were, we’d simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. You will fi nd that organizations range from

13 Scrum developers are not the fi rst to question the use of plans. One of President Eisenhower’s favorite maxims was, “In preparing for battle I have always found that plans are useless, but planning is indispensable.” M. Dobson, Streetwise Project Management: How to Manage People, Processes, and Time to Achieve the Results You Need (Avon, MA: F+W Publications, 2003), p. 43. 14 C. Larman, Agile & Iterative Development: A Manager’s Guide (Boston: Addison-Wesley, 2004).

16 Chapter 1 Introduction to Systems Analysis and Design

having one “approved” methodology to having several methodology options to having no formal policies at all.

Figure 1-8 summarizes some important criteria for selecting a methodology. One impor- tant item not discussed in this fi gure is the degree of experience of the analyst team. Many of the RAD-based methodologies require the use of new tools and techniques that have a signifi cant learning curve. Oft en these tools and techniques increase the complexity of the project and require extra time for learning. However, once they are adopted and the team becomes experienced, the tools and techniques can signifi cantly increase the speed at which the methodology can deliver a fi nal system.

Clarity of User Requirements When the user requirements for a system are unclear, it is diffi cult to understand them by talking about them and explaining them with written reports. Users normally need to interact with technology to really understand what a new system can do and how to best apply it to their needs. RAD and agile methodologies are usually more appropriate when user requirements are unclear.

Familiarity with Technology When the system will use new technology with which the ana- lysts and programmers are not familiar, early application of the new technology in the meth- odology will improve the chance of success. If the system is designed without some familiarity with the base technology, risks increase because the tools might not be capable of doing what is needed. Th rowaway prototyping-based methodologies are particularly appropriate if users lack familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks. Phased development-based methodologies create opportunities to investigate the technology in some depth before the design is complete. Also, owing to the programming-centric nature of agile methodologies, both XP and Scrum are appropriate. Although you might think prototyping-based methodologies are also appropriate, they are much less so because the early prototypes that are built usually only scratch the surface of the new technology. It is generally only aft er several prototypes and several months that the developers discover weaknesses or problems in the new technology.

System Complexity Complex systems require careful and detailed analysis and design. Th rowaway prototyping-based methodologies are particularly well suited to such detailed analysis and design, but prototyping-based methodologies are not. Th e traditional structured

Ability to Develop Systems

Structured Methodologies RAD Methodologies

Agile Methodologies

Waterfall Parallel Phased Prototyping Throwaway Prototyping XP SCRUM

With Unclear User Requirements Poor Poor Good Excellent Excellent Excellent Excellent

With Unfamiliar Technology Poor Poor Good Poor Excellent Good Good

That Are Complex Good Good Good Poor Excellent Good Good

That Are Reliable Good Good Good Poor Excellent Excellent Excellent

With a Short Time Schedule Poor Good Excellent Excellent Good Excellent Excellent

With Schedule Visibility Poor Poor Excellent Excellent Good Excellent Excellent

FIGURE 1-8 Criteria for Selecting a Methodology

Typical Systems Analyst Roles and Skills 17

design-based methodologies can handle complex systems, but without the ability to get the system or prototypes into the users’ hands early on, some key issues may be overlooked. Although phased development-based methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these tend to devote less attention to the analysis of the complete problem domain than they might using other meth- odologies. Finally, agile methodologies are a mixed bag when it comes to system complexity. If the system is going to be a large one, agile methodologies will perform poorly. However, if the system is small to medium size, then agile approaches will be excellent. We rate them good on these criteria.

System Reliability System reliability is usually an important factor in system development; aft er all, who wants an unreliable system? However, reliability is just one factor among several. For some applications, reliability is truly critical (e.g., medical equipment, mis- sile-control systems), whereas for other applications (e.g., games, Internet video) it is merely important. Because throwaway prototyping methodologies combine detailed analysis and design phases with the ability for the project team to test many diff erent approaches through design prototypes before completing the design, they are appropriate when system reliability is a high priority. Prototyping methodologies are generally not a good choice when reliability is critical because it lacks the careful analysis and design phases that are essential for depend- able systems. However, owing to the heavy focus on testing, evolutionary and incremental identifi cation of requirements, and iterative and incremental development, agile methods may be the best overall approach.

Short Time Schedules RAD-based and agile methodologies are excellent choices when timelines are short because they best enable the project team to adjust the functionality in the system based on a specifi c delivery date, and if the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under development. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow easy schedule changes.

Schedule Visibility One of the greatest challenges in systems development is determining whether a project is on schedule. Th is is particularly true of the structured design method- ologies because design and implementation occur at the end of the project. Th e RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check. However, given the daily progress meetings associated with Agile approaches, schedule visibility is always on the proverbial front burner.

TYPICAL SYSTEMS ANALYST ROLES AND SKILLS It is clear from the various phases and steps performed during the SDLC that the project team needs a variety of skills. Project members are change agents who identify ways to improve an organization, build an information system to support them, and train and motivate others to use the system. Understanding what to change and how to change it—and convincing others of the need for change—requires a wide range of skills. Th ese skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical.

Analysts must have the technical skills to understand the organization’s existing techni- cal environment, the technology that will make up the new system, and the way both can fi t into an integrated technical solution. Business skills are required to understand how IT can be

18 Chapter 1 Introduction to Systems Analysis and Design

applied to business situations and to ensure that the IT delivers real business value. Analysts are continuous problem solvers at both the project and the organizational level, and they put their analytical skills to the test regularly.

Analysts oft en need to communicate eff ectively one-on-one with users and business man- agers (who oft en have little experience with technology) and with programmers (who oft en have more technical expertise than the analyst). Th ey must be able to give presentations to large and small groups and write reports. Not only do they need to have strong interpersonal abilities, but they also need to manage people with whom they work and they need to manage the pressure and risks associated with unclear situations.

Homework is Completed By:

Writer	Writer Name	Amount	Client Comments & Rating
ONLINE	Instant Homework Helper 4.8 4305 Orders Completed	$36	She helped me in last minute in a very reasonable price. She is a lifesaver, I got A+ grade in my homework, I will surely hire her again for my next assignments, Thumbs Up! 5.00
Answer.docx Turnitin Report.pdf Contact Writer For Solution Contact Writer For Solution

Order & Get This Solution Within 3 Hours in $25/Page

Custom Original Solution And Get A+ Grades

100% Plagiarism Free
Proper APA/MLA/Harvard Referencing
Delivery in 3 Hours After Placing Order
Free Turnitin Report
Unlimited Revisions
Privacy Guaranteed

Order Now

Order & Get This Solution Within 6 Hours in $20/Page

Custom Original Solution And Get A+ Grades

100% Plagiarism Free
Proper APA/MLA/Harvard Referencing
Delivery in 6 Hours After Placing Order
Free Turnitin Report
Unlimited Revisions
Privacy Guaranteed

Order Now

Order & Get This Solution Within 12 Hours in $15/Page

Custom Original Solution And Get A+ Grades

100% Plagiarism Free
Proper APA/MLA/Harvard Referencing
Delivery in 12 Hours After Placing Order
Free Turnitin Report
Unlimited Revisions
Privacy Guaranteed

Order Now

6 writers have sent their proposals to do this homework:

Writer	Writer Name	Offer	Chat
ONLINE	Helping Engineer I can assist you in plagiarism free writing as I have already done several related projects of writing. I have a master qualification with 5 years’ experience in; Essay Writing, Case Study Writing, Report Writing. 4.8 4284 Orders Completed	$25	Chat With Writer
ONLINE	Top Grade Essay I find your project quite stimulating and related to my profession. I can surely contribute you with your project. 4.9 2121 Orders Completed	$39	Chat With Writer
ONLINE	Finance Homework Help I will be delighted to work on your project. As an experienced writer, I can provide you top quality, well researched, concise and error-free work within your provided deadline at very reasonable prices. 4.8 2499 Orders Completed	$46	Chat With Writer
ONLINE	Coursework Help Online I have read your project description carefully and you will get plagiarism free writing according to your requirements. Thank You 4.8 1491 Orders Completed	$49	Chat With Writer
ONLINE	Essay Writing Help I have read your project details and I can provide you QUALITY WORK within your given timeline and budget. 4.8 4746 Orders Completed	$18	Chat With Writer
ONLINE	Quick Mentor I reckon that I can perfectly carry this project for you! I am a research writer and have been writing academic papers, business reports, plans, literature review, reports and others for the past 1 decade. 4.1 210 Orders Completed	$34	Chat With Writer