利用UML进行系统分析和设计第三版


Systems Analysis Design UML Version 2.0 An Object-Oriented Approach Third Edition This page intentionally left blank System Analysis Design UML Version 2.0 An Object-Oriented Approach Third Edition Alan Dennis Indiana University Barbara Haley Wixom University of Virginia David Tegarden Virginia Tech John Wiley & Sons, Inc. Vice President & Executive Publisher Don Fowley Executive Editor Beth Golub Associate Editor Jen Devine Marketing Manager Carly DeCandia Design Director Harry Nolan Senior Designer Kevin Murphy Senior Production Editor Patricia McFadden Senior Media Editor Lauren Sapira Production Management Services This book was set in by Laserwords and printed and bound by RRD/Von Hoffmann. The cover was printed by RRD/Von Hoffmann. This book is printed on acid free paper. ∞ Copyright © 2009 John Wiley & Sons, Inc. 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, 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 autho- rization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc. 222 Rosewood Drive, Danvers, MA 01923, website 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, website http://www.wiley.com/go/permissions. To order books or for customer service please, call 1-800-CALL WILEY (225-5945). ISBN-13 9780470074787 Printed in the United States of America 10987654321 Aptara®, Inc. Lang Preface xiii Chapter 1 Introduction to Systems Analysis and Design 1 ■ PART ONE PROJECT INITIATION, PROJECT MANAGEMENT, AND REQUIREMENTS DETERMINATION 39 Chapter 2 Project Initiation 41 Chapter 3 Project Management 69 Chapter 4 Requirements Determination 110 ■ PART TWO ANALYSIS MODELING 155 Chapter 5 Functional Modeling 157 Chapter 6 Structural Modeling 207 Chapter 7 Behavioral Modeling 238 ■ PART THREE DESIGN MODELING 269 Chapter 8 Moving on to Design 271 BRIEF CONTENTS v Chapter 9 Class and Method Design 318 Chapter 10 Data Management Layer Design 361 Chapter 11 Human–Computer Interaction Layer Design 411 Chapter 12 Physical Architecture Layer Design 463 ■ PART FOUR CONSTRUCTION, INSTALLATION, AND OPERATIONS 503 Chapter 13 Construction 505 Chapter 14 Installation and Operations 533 Index 536 vi Brief Contents Preface xiii Chapter 1 Introduction to Systems Analysis and Design 1 Introduction 2 The Systems Development Life Cycle 3 Planning 4 Analysis 4 Design 5 Implementation 6 Systems Development Methodologies 6 Structured Design 8 Rapid Application Development (RAD) 10 Agile Development 14 Selecting the Appropriate Development Methodology 15 Object-Oriented Systems Analysis and Design (OOSAD) 17 Use-Case Driven 18 Architecture Centric 18 Iterative and Incremental 18 Benefits of Object-Oriented Systems Analysis and Design 19 The Unified Process 19 Phases 20 Workflows 22 Extensions to the Unified Process 24 The Unified Modeling Language 29 Project Team Roles and Skills 30 Business Analyst 32 Systems Analyst 32 Infrastructure Analyst 32 Change Management Analyst 32 Project Manager 32 Applying the Concepts at CD Selections 33 Summary 33 ■ PART ONE PROJECT INITIATION, PROJECT MANAGEMENT, AND REQUIRE- MENTS DETERMINATION 39 Chapter 2 Project Initiation 41 Introduction 41 Project Identification 43 System Request 44 Feasibility Analysis 44 Technical Feasibility 46 Economic Feasibility 48 Organizational Feasibility 56 Project Selection 58 Applying the Concepts at CD Selections 61 Project Identification and System Request 61 Feasibility Analysis 62 Project Selection 64 Summary 66 Chapter 3 Project Management 69 Introduction 69 Identifying Project Size 70 Function Point Approach 72 Creating and Managing the Workplan 77 CONTENTS vii Identifying Tasks 78 The Project Workplan 79 Gantt Chart 79 PERT Chart 81 Refining Estimates 82 Scope Management 83 Timeboxing 85 Evolutionary Work Breakdown Structures and Iterative Workplans 86 Staffing the Project 91 Staffing Plan 91 Motivation 94 Handling Conflict 94 Coordinating Project Activities 96 CASE Tools 96 Standards 97 Documentation 98 Managing Risk 98 Applying the Concepts at CD Selections 100 Staffing the Project 104 Coordinating Project Activities 105 Summary 106 Chapter 4 Requirements Determination 110 Introduction 110 Requirements Determination 111 Defining a Requirement 111 Requirements Definition 114 Determining Requirements 115 Creating a Requirements Definition 116 Requirements Analysis Strategies 117 Business Process Automation 117 Business Process Improvement 120 Business Process Reengineering 121 Selecting Appropriate Strategies 122 Requirements-Gathering Techniques 125 Interviews 125 Joint application development (JAD) 132 Questionnaires 136 Document Analysis 138 Observation 138 Other Techniques 140 Selecting the Appropriate Techniques 142 The System Proposal 144 Applying the Concepts at CD Selections 145 Requirements Analysis Strategies 145 Requirements-Gathering Techniques 146 Requirements Definition 146 System Proposal 148 Summary 149 ■ PART TWO ANALYSIS MODELING 155 Chapter 5 Functional Modeling 157 Introduction 158 Business Process Modeling with Activity Diagrams 159 Elements of an Activity Diagram 160 Guidelines for Creating Activity Diagrams 165 Use-Case Descriptions 166 Types of Use Cases 167 Elements of a Use-Case Description 168 Guidelines for Creating Use-Case Descriptions 171 Use-Case Diagrams 173 Actors 173 Association 175 Use Case 176 System Boundary 176 Creating Use-Case Descriptions and Use-Case Diagrams 178 Identifying the Major Use Cases 179 Expanding the Major Use Cases 180 Confirming the Major Use Cases 181 Creating a Use-Case Diagram 181 Refining Project Size and Effort Estimation Using Use-Case Points 182 Applying the Concepts at CD Selections 188 viii Contents Business Process Modeling with Activity Diagrams 188 Identifying the Major Use Cases 189 Expanding the Major Use Cases 191 Confirming the Major Use Cases 193 Creating the Use-Case Diagram 198 Refining Project Size and Effort Estimation Using Use-Case Points 198 Summary 201 Chapter 6 Structural Modeling 207 Introduction 207 Structural Models 208 Classes, Attributes, and Operations 209 Relationships 209 CRC Cards 211 Responsibilities and Collaborations 211 Elements of a CRC Card 212 Class Diagrams 213 Elements of a Class Diagram 213 Simplifying Class Diagrams 221 Object Diagrams 221 Creating CRC Cards and Class Diagrams 222 Object Identification 223 Building CRC Cards and Class Diagrams 225 Applying the Concepts at CD Selections 228 Step 1: Create CRC Cards 228 Step 2: Examine Common Object Lists 228 Step 3: Role-Play the CRC Cards 230 Step 4: Create the Class Diagram 231 Step 5: Review the Class Diagram 231 Step 6: Incorporate Patterns 231 Step 7: Review the Model 232 Summary 233 Chapter 7 Behavioral Modeling 238 Introduction 238 Behavioral Models 239 Interaction Diagrams 239 Objects, Operations, and Messages 240 Sequence Diagrams 240 Communication Diagrams 246 Behavioral State Machines 250 States, Events, Transitions, Actions, and Activities 250 Elements of a Behavioral State Machine 251 Building Behavioral State Machines 254 CRUD Analysis 256 Applying the Concepts at CD Selections 257 Sequence Diagrams 257 Communication Diagrams 260 Behavioral State Machines 261 CRUD Analysis 262 Summary 264 ■ PART THREE DESIGN MODELING 269 Chapter 8 Moving on to Design 271 Introduction 272 Verifying and Validating the Analysis Models 273 Verification and Validation through Walkthroughs 273 Functional Model Verification and Validation 275 Structural Model Verification and Validation 276 Behavioral Model Verification and Validation 278 Balancing the Analysis Models 280 Evolving the Analysis Models into Design Models 287 Factoring 290 Partitions and Collaborations 290 Layers 292 Packages and Package Diagrams 294 Identifying Packages and Creating Package Diagrams 297 Contents ix Verifying and Validating Package Diagrams 297 Design Strategies 299 Custom Development 299 Packaged Software 300 Outsourcing 302 Selecting a Design Strategy 304 Developing the Actual Design 306 Alternative Matrix 306 Applying the Concepts at CD Selections 308 Packages and Package Diagrams 308 Verifying and Validating the Analysis Models 310 Developing the Actual Design 311 Summary 312 Chapter 9 Class and Method Design 318 Introduction 318 Review of the Basic Characteristics of Object Orientation 320 Classes, Objects, Methods, and Messages 320 Encapsulation and Information Hiding 321 Polymorphism and Dynamic Binding 321 Inheritance 322 Design Criteria 325 Coupling 325 Cohesion 328 Connascence 331 Object Design Activities 332 Adding Specifications 332 Identifying Opportunities for Reuse 333 Restructuring the Design 335 Optimizing the Design 336 Mapping Problem-Domain Classes to Implementation Languages 339 Constraints and Contracts 343 Types of Constraints 343 Elements of a Contract 346 Method Specification 347 General Information 348 Events 349 Message Passing 349 Algorithm Specification 349 Applying the Concepts at CD Selections 351 Summary 354 Chapter 10 Data Management Layer Design 361 Introduction 362 Object-Persistence Formats 362 Sequential and Random Access Files 363 Relational Databases 366 Object-Relational Databases 368 Object-Oriented Databases 368 Selecting an Object-Persistence Format 369 Mapping Problem-Domain Objects to Object-Persistence Formats 372 Mapping Problem-Domain Objects to an OODBMS Format 372 Mapping Problem-Domain Objects to an ORDBMS Format 376 Mapping Problem-Domain Objects to an RDBMS Format 379 Optimizing RDBMS-Based Object Storage 382 Optimizing Storage Efficiency 382 Optimizing Data Access Speed 388 Estimating Data Storage Size 393 Nonfunctional Requirements and Data Management Layer Design 394 Designing Data Access and Manipulation Classes 395 Applying the Concepts at CD Selections 398 Select Object-Persistence Format 398 Map Problem-Domain Objects to Object-Persistence Format 399 Optimize Object Persistence and Estimate Its Size 400 Data Access and Manipulation Class Design 402 Summary 404 x Contents Chapter 11 Human–Computer Interaction Layer Design 411 Introduction 412 Principles for User Interface Design 412 Layout 413 Content Awareness 415 Aesthetics 417 User Experience 419 Consistency 419 Minimizing User Effort 420 User Interface Design Process 420 Use Scenario Development 421 Interface Structure Design 423 Interface Standards Design 424 Interface Design Prototyping 426 Interface Evaluation 428 Navigation Design 430 Basic Principles 430 Types of Navigation Controls 431 Messages 432 Navigation Design Documentation 435 Input Design 436 Basic Principles 436 Types of Inputs 439 Input Validation 441 Output Design 443 Basic Principles 443 Types of Outputs 445 Media 445 Nonfunctional Requirements and Human–Computer Interaction Layer Design 447 Applying the Concepts at CD Selections 448 Use Scenario Development 448 Interface Structure Design 448 Interface Standards Design 451 Interface Template Design 451 Interface Design Prototyping 453 Interface Evaluation 454 Navigation Design Documentation 455 Summary 456 Chapter 12 Physical Architecture Layer Design 463 Introduction 463 Elements of the Physical Architecture Layer 464 Architectural Components 464 Server-Based Architectures 465 Client-Based Architectures 466 Client–Server Architectures 466 Client–Server Tiers 468 Distributed Objects Computing 470 Selecting a Physical Architecture 471 Infrastructure Design 473 Deployment Diagram 473 Network Model 475 Nonfunctional Requirements and Physical Architecture Layer Design 480 Operational Requirements 481 Performance Requirements 482 Security Requirements 484 Cultural and Political Requirements 488 Synopsis 490 Hardware and Software Specification 492 Applying the Concepts at CD Selections 494 Summary 496 ■ PART FOUR CONSTRUCTION, INSTALLATION, AND OPERATIONS 503 Chapter 13 Construction 505 Introduction 505 Managing Programming 507 Assigning Programmers 507 Coordinating Activities 508 Managing the Schedule 509 Cultural Issues 510 Contents xi Designing Tests 512 Testing and Object Orientation 513 Test Planning 515 Unit Tests 517 Integration Tests 519 System Tests 520 Acceptance Tests 520 Developing Documentation 520 Types of Documentation 521 Designing Documentation Structure 522 Writing Documentation Topics 524 Identifying Navigation Terms 525 Applying the Concepts at CD Selections 526 Managing Programming 526 Testing 526 Developing User Documentation 528 Summary 530 Chapter 14 Installation and Operations 533 Introduction 533 Cultural Issues and Information Technology 535 Conversion 537 Conversion Style 538 Conversion Location 539 Conversion Modules 540 Selecting the Appropriate Conversion Strategy 541 Change Management 543 Understanding Resistance to Change 544 Revising Management Policies 546 Assessing Costs and Benefits 547 Motivating Adoption 549 Enabling Adoption: Training 550 Postimplementation Activities 552 System Support 552 System Maintenance 554 Project Assessment 555 Applying the Concepts at CD Selections 557 Conversion 557 Change Management 558 Postimplementation Activities 558 Summary 558 Index 00 Available on line at www.wiley.com/college/dennis Appendix 1 Appendix 2 Appendix 3 xii Contents PURPOSE OF THIS BOOK Systems Analysis and Design (SAD) is an exciting, active field in which analysts continually learn new techniques and approaches to develop systems more effectively and efficiently. 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 software 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. This change has been accelerated through the creation of the Uni- fied Modeling Language (UML). UML provides a common vocabulary of object-oriented terms and diagramming techniques that is rich enough to model any systems development project from analysis through implementation. This book captures the dynamic aspects of the field 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. This book builds on our professional experience as systems analysts and on our experience in teaching SAD in the classroom. This 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 stu- dents 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 The goal of this book is to enable students to do SAD—not just read about it, but under- stand the issues so they can actually analyze and design systems. The book introduces each major technique, explains what it is, explains how to do it, presents an example, and pro- vides opportunities for students to practice before they do it for real in a project. After read- ing each chapter, the student will be able to perform that step in the system development life cycle (SDLC) process. PREFACE xiii Rich Examples of Success and Failure The book includes a running case about a fictitious company called CD Selections. Each chapter shows how the concepts are applied in situations at CD Selections. Unlike running cases in other books, we have tried to focus these examples on planning, managing, and executing the activities described in the chapter, rather than on detailed dialogue between fictious actors. 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, many of which were written by Dr. Bruce White from Quinnipiac University, that describe how real companies succeeded—and failed—in performing the activities in the chapter. 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 systems 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 profes- sionals and consultants in developing the book and have incorporated their stories, feed- back, 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 practitioners feel is relevant in the real world. Project Approach We have presented the topics in this book in the SDLC order in which an analyst encoun- ters them in a typical project. Although the presentation is necessarily linear (because stu- dents 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. The presentation of the material should align well with courses that encourage students to work on projects because it pre- sents topics as students need to apply them. WHAT’S NEW IN THIS EDITION In this edition, we have increased the coverage of and better organized the text around the enhanced Unified Process; provided a greater focus on nonfunctional requirements; provided a greater emphasis on the iterative and incremental development associated with object- oriented analysis and design; added figures and examples, along with additional explanatory text that addresses some of the more difficult concepts to learn; better aligned the CD selec- tions case material; and did some minor reorganization. However, the biggest changes that have been included address the issues surrounding information systems development and the so-called flat world. The global economy has brought up the need for much greater under- standing of cultural issues, regulatory issues, and the need for testing. The third edition covers this type of material throughout the text. Details of the major changes are as follows: 1. To better align the text with a Unified Process–based methodology, all references to the MOOSAD methodology have been removed, the object-oriented systems analysis and design material and the short overview of UML 2.0 have been moved to Chapter 1, and “Basic Characteristics of Object-Oriented Systems” section is now included in an optional appendix. This last change was driven by the desire of instructors to have the flexibility to cover this material at the most appropriate time for the students based on the students’ backgrounds. In some cases, students xiv Preface may have had multiple object-oriented programming courses, whereas in other cases, students may not have had any programming courses at all. Either way, the material is not really necessary to understand until the functional modeling or the class and method design material is covered. Finally, we have tied the “Evolu- tionary Work Breakdown Structures and Iterative Workplans” section of the Pro- ject Management chapter to the enhanced Unified Process. This allowed us better to apply the iterative and incremental development characteristics of object- oriented systems development to the project management material. 2. With regards to the requirements determination, we introduced the idea that in today’s world, there are additional nonfunctional requirements, such as Sarbanes-Oxley, COBIT, ISO 9000, and CMM, being added to the set of non- functional requirements that the analyst must address. We also have introduced new requirements-gathering techniques, for example, throwaway prototyping, role-playing CRC cards, and mind/concept mapping. And, we have introduced the system proposal idea as a separate topic instead of only having it embedded in the CD Selections case. Furthermore, in the design chapters (data manage- ment layer design, human–computer interaction layer design, and physical architecture layer design), more emphasis has been placed on the impact of nonfunctional requirements on the design. 3. The material included within the functional, structural, and behavioral modeling chapters has been more tightly coupled. This is especially true with regard to the idea of iterative and incremental development. The text now emphasizes that sys- tems must be incrementally built by iterating over each of the models and over the intersection of the models. For example, the normal flow of events contained within a use-case description is associated with the activities on an activity dia- gram, the operations on a class diagram, the behaviors on the CRC cards, the messages on sequence and communication diagrams, and transitions on behav- ioral state machines. As such, any change to any one of these most likely will force changes in the others. Furthermore, we have promoted the use of CRUD analysis up to a behavioral modeling technique in and of itself instead of having it associated only with the communications diagram. 4. A major new section has been added to the Moving On to Design chapter that addresses the verification and validation of the analysis models. This section goes through great detail on how to verify and validate the analysis models developed during functional, structural, and behavioral modeling. Furthermore, there had been intentional oversights or errors placed in a couple of the earlier models. During this new section, those errors are uncovered and corrected. Furthermore, to enhance the coverage of testing material, we have added use-case testing as an integration-testing approach in the Construction chapter. 5. We have included material that addresses global concerns throughout the text. This includes material with regard to requirements determination, outsourcing, and class and method design. With regard to the construction chapter, a new sec- tion on cultural issues has been included with the managing programmers section. Finally, with the Installation and Operations chapter a new major section has been added to address cultural issues and information technology. This new section is based on the work of Geert Hofstede. 6. Additional figures and explanatory material have been added throughout the text. However, special attention was paid to the material contained in the struc- tural modeling, behavioral modeling, and the class and method design chapters. Preface xv 7. The CD Selections case has now been more closely aligned with each chapter. Each chapter simply has a section of the case associated with it. For example, the intro- duction to the case is now associated with Chapter 1. The case has been slightly modified to ensure that the case itself is more cohesive. Furthermore, in some situa- tions, the CD Selections case had introduced new content material. We have moved any new content material into the content of the corresponding chapter. ORGANIZATION OF THIS BOOK This book is organized by the phases of the Systems Development Life Cycle (SDLC). Each chapter has been written to teach students specific 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 book, tasks will be “checked off” and deliverables will be completed. Along the way, students will be reminded of their progress using roadmaps that indicate where their current task fits into the larger context of SAD. Chapter 1 introduces the SDLC, systems development methodologies, Object-oriented systems analysis, the Unified Process, UML 2.0, and describes the roles and skills needed for a project team. Part One contains material that in many ways goes across the phases of the traditional SDLC. Chapter 2 presents project initiation, with a focus on project identification, system request, feasibility analysis, and project selection. In Chapter 3, students learn about project management, with emphasis on the workplan, staffing plan, project charter, and risk assess- ment that are used to help manage and control the project. Chapter 4 introduces students to an assortment of analysis techniques to help with business automation, business improvement, and business process reengineering, a variety of requirements-gathering techniques that are used to determine the functional and nonfunctional requirements of the system, and to a system proposal. Part Two focuses on creating analysis models. Chapter 5 focuses on constructing func- tional models, Chapter 6 addresses producing structural models, and Chapter 7 tackles cre- ating behavioral models. Part Three addresses design modeling. In Chapter 8, students learn how to verify and val- idate the analysis models created during analysis modeling and to evolve the analysis models into design models via the use of factoring, partitions, and layers. The students also learn to create an alternative matrix that can be used to compare custom, packaged, and outsourcing alternatives. Chapter 9 concentrates on designing the individual classes and their respective methods through the use of contracts and method specifications. Chapter 10 presents the issues involved in designing persistence for objects. These issues include the different 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. This chapter also focuses on the nonfunctional requirements that impact the data management layer. Chapter 11 presents the design of the human–computer interaction layer, where stu- dents learn how to design user interfaces using use scenarios, windows navigation diagrams, storyboards, Windows layout diagrams, HTML 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 as user interface layout, content awareness, aesthetics, user experience, and consistency. Chapter 12 focuses on the physical architecture and infra- structure design, which includes deployment diagrams and hardware/software specification. This chapter, like the previous design chapters, covers the impact that nonfunctional require- ments can have on the physical architecture layer. xvi Preface Part Four provides material that is related to the construction, installation, and opera- tions of the system. Chapter 13 focuses on system construction, where students learn how to build, test, and document the system. Installation and operations are covered in Chapter 14, 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 flat world, where developers and users are distributed throughout the world. SUPPLEMENTS http://www.wiley.com/college/dennis Instructor’s Resources Web Site ■ PowerPoint slides, which instructors can tailor to their classroom needs and that students can use to guide their reading and studying activities ■ Test Bank, that includes a variety of questions ranging from multiple choice to essay style questions. A computerized version of the Test Bank will also be available. Online Instructor’s Manual The Instructor’s Manual provides resources to support the instructor both inside and out of the classroom: ■ Short experiential exercises that instructors can use to help students experience and understand key topics in each chapter. ■ Short stories have been provided by people working in both corporate and con- sulting 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 Website ■ Relevant Web links, including career resources Web site. ■ Web quizzes help students prepare for class tests. Cases in Systems Analysis and Design A separate Case Book on CD-ROM provides a set of more than a dozen cases that can be used to supplement the book and provide exercises for students to practice with. The cases are primarily drawn from the United States and Canada, but also include a number of international cases. We are always looking for new cases, so if you have a case that might be appropriate please contact us directly (or your local Wiley sales representative). Software Tools Three Software Tools can be purchased with the text in special packages: 1. Visible Systems Corporation’s Visible Analyst Student Edition. 2. Microsoft’s Visio. 3. Microsoft’s Project. A 60-day trial edition of Microsoft Project can be purchased with the textbook. Note that Microsoft has changed their policy and no longer offers the 120-day trial previously available. Preface xvii Another option now available to education institutions adopting this Wiley textbook is a free 3-year membership to the MSDN Academic Alliance. The MSDN AA is designed to provide the easiest and most inexpensive way for academic departments to make the latest Microsoft software available in labs, classrooms, and on student and instructor PCs. Microsoft Project 2007 software is available through this Wiley and Microsoft publishing partnership, free of charge with the adoption of any qualified Wiley text- book. Each copy of Microsoft Project is the full version of the software, with no time limitations, and can be used indefinitely for educational purposes. For more infor- mation about the MSDN AA program, go to http://msdn.microsoft.com/academic/. Contact your local Wiley sales representative for details, including pricing and ordering information. ACKNOWLEDGMENTS For the third edition, we would like to thank the students of the ACIS 3515: Information Sys- tems Development I and ACIS 3516: Information Systems Development II classes at Virginia Tech for giving many suggestions that drove most of the changes from the second edition to the third edition. Their feedback was invaluable in improving the text and examples. We would like to thank the following reviewers for their helpful and insightful com- ments on the third edition: Evans Adams, Fort Lewis College; Murugan Anandarajan, Drexel University; Rob Anson, Boise State University; Ravi Krovi, University of Akron; Leo Legorreta, California State University Sacramento; Diane Lending, James Madison Univer- sity; Major Fernando Maymi, West Point University; J. Drew Procaccino, Rider University; Bill Watson, Indiana University–Purdue University Indianapolis; and Amy B. Woszczynski, Kennesaw State University. We also thank the following reviewers from the first and second edition: Evans Adams, Fort Lewis College; Noushin Ashrafi, University of Massachusetts, Boston; Dirk Baldwin, University of Wisconsin-Parkside; Qing Cao, University of Missouri–Kansas City; Ahmad Ghafarian, North Georgia College & State University; Daniel V. Goulet, University of Wis- consin–Stevens Point; Harvey Hayashi, Loyalist College of Applied Arts and Technology; Jean-Piere Kuilboer, University of Massachusetts, Boston; Daniel Mittleman, DePaul Univer- sity; Fred Niederman, Saint Louis University; H. Robert Pajkowski, DeVry Institute of Tech- nology, Scarborough, Ontario; June S. Park, University of Iowa; Tom Pettay, DeVry Institute of Technology, Columbus, Ohio; Neil Ramiller, Portland State University; Eliot Rich, Univer- sity at Albany, State University of New York; Carl Scott, University of Houston; Keng Siau, University of Nebraska–Lincoln; Jonathan Trower, Baylor University; Anna Wachholz, Sheri- dan College; Randy S.Weinberg, Carnegie Mellon University; Eli J.Weissman, DeVry Institute of Technology, Long Island City, NY; Heinz Roland Weistroffer, Virginia Commonwealth University; Amy Wilson, DeVry Institute of Technology, Decatur, GA; Vincent C. Yen, Wright State University; Murugan Anandarajon, Drexel University; Ron Anson, Boise State University; Noushin Ashrafi, University of Massachusetts Boston; Dirk Baldwin, University of Wisconsin; Robert Barker, University of Louisville; Terry Fox, Baylor University; Donald Golden, Cleve- land State University; Cleotilde Gonzalez, Carnegie Melon University; Scott James, Saginaw Valley State University; Rajiv Kishore, State University of New York–Buffalo; Ravindra Krovi, University of Akron; Fernando Maymi, United States Military Academy at West Point; Fred Niederman, Saint Louis University; Graham Peace, West Virginia University; J. Drew Procac- cino, Rider University; Marcus Rothenberger,University of Wisconsin–Milwaukee; June Verner, Drexel University; Heinz Roland Weistroffer, Virginia Commonwealth University; and Amy Woszczynski, Kennesaw State University. xviii Preface 1 Chapter 1 first introduces the systems development life cycle (SDLC), the fundamental four-phase model (planning, analysis, design, and implementation) common to all infor- mation system development projects. Second, it describes the evolution of system develop- ment methodologies. Third, the chapter overviews object-oriented systems analysis and design and describes the Unified Process and its extensions. Finally, the chapter closes with a discussion of the roles and skills necessary within the project team. OBJECTIVES ■ Understand the fundamental systems development life cycle and its four phases. ■ Understand the evolution of systems development methodologies. ■ Be familiar with the Unified Process and its extensions. ■ Be familiar with the different roles on the project team. CHAPTER OUTLINE CHAPTER 1 Introduction to Systems Analysis and Design Introduction The Systems Development Life Cycle Planning Analysis Design Implementation Systems Development Methodologies Structured Design Rapid Application Development (RAD) Agile Development Selecting the Appropriate Development Methodology Object-Oriented Systems Analysis and Design (OOSAD) Use-Case Driven Architecture Centric Iterative and Incremental Benefits of Object-Oriented Systems Analysis and Design The Unified Process Phases Workflows Extensions to the Unified Process The Unified Modeling Language Project Team Roles and Skills Business Analyst Systems Analyst Infrastructure Analyst Change Management Analyst Project Manager Applying the Concepts at CD Selections Summary 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 done in 1996 by the General Accounting Office found 53 per- cent of all U.S. government IS projects were abandoned. Unfortunately, many of the sys- tems that aren’t abandoned are delivered to the users significantly late, cost far more than planned, and have fewer features than originally planned. Most of us would like to think that these problems only occur to “other” people or “other” organizations, but they happen in most companies. Even Microsoft has a history of failures and overdue projects (e.g., Windows 1.0, Windows 95).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 sim- ply does not exist. Instead, this book will provide you with several fundamental concepts and many practical techniques that you can use to improve the probability of success. The key person in the SDLC is the systems analyst, who analyzes the business situation, identifies opportunities for improvements, and designs an information system to imple- ment them. Being a systems analyst is one of the most interesting, exciting, and challeng- ing jobs around. Systems analysts work with a variety of people and learn how they conduct business. Specifically, they work with a team of systems analysts, programmers, and others on a common mission. Systems analysts feel the satisfaction of seeing systems that they designed and developed make a significant 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 profits (government agencies and not-for-profit organizations measure value differently). Many failed systems have been abandoned because the analysts tried to build a wonderful system without clearly understanding how the system would fit with an orga- nization’s goals, current business processes, and other information systems to provide value. An investment in an information system is like any other investment, such as a new machine tool. The 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 it can earn greater profits or serve its constituents more effectively. This book introduces the fundamental skills a systems analyst needs. This pragmatic book discusses best practices in systems development; it does not present a general survey of systems development that presents everything about the topic. By definition, systems ana- lysts do things and challenge the current way that organizations work. To get the most out of this book, you will need actively to apply the ideas and concepts in the examples and in the “Your Turn” exercises that are presented throughout to your own systems development pro- ject. This book guides you through all the steps for delivering a successful information sys- tem. Also, it illustrates how one organization (called CD Selections) applies the steps in one project (developing a Web-based CD sales system). By the time you finish the book, you won’t be an expert analyst, but you will be ready to start building systems for real. 2 Chapter 1 Introduction to Systems Analysis and Design 1 For more information on the problem, see Capers Jones, Patterns of Software System Failure and Success (London: International Thompson Computer Press, 1996); Capers Jones, Assessment and Control of Software Project Risks (Englewood Cliffs, NJ: Yourdon Press, 1994); Julia King, “IS Reins in Runaway Projects,” Computerworld (February 24, 1997). This chapter first introduces the basic SDLC that IS projects follow. This life cycle is common to all projects, although the focus and approach to each phase of the life cycle may differ. The next section describes three fundamentally different types of systems development methodologies: structured design, rapid application development, and agile development. The next three sections introduce the fundamental characteristics of object-oriented systems analysis and design, a specific object-oriented systems development methodology (The Unified Process), and a specific object-oriented systems development graphical nota- tion (The Unified Modeling Language). Finally, the chapter discusses one of the most chal- lenging aspects of systems development, the depth and breadth of skills required of systems analysts. Today, most organizations use project teams that contain members with unique, but complementary, skills. The chapter closes with a discussion of the key roles played by members of the systems development team. The Systems Development Life Cycle 3 A real-estate group in the federal government cospon- sored a data warehouse with the IT department. In the for- mal proposal written by IT, costs were estimated at $800,000, the project duration was estimated to be eight months, and the responsibility for funding was defined as the business unit’s. The IT department proceeded with the project before it even knew if the project had been accepted. The project actually lasted two years because require- ments gathering took nine months instead of one and a half, the planned user base grew from 200 to 2,500, and the approval process to buy technology for the project took a year. Three weeks prior to technical delivery, the IT director canceled the project. This failed endeavor cost the organization and taxpayers $2.5 million. Source: Hugh J. Watson et al., “Data Warehousing Failure: Case Studies and Findings,” The Journal of Data Warehousing 4, (no. 1) (1999): 44–54. Questions 1. Why did this system fail? 2. Why would a company spend money and time on a project and then cancel it? 3. What could have been done to prevent this? 1–A An Expensive False StartCONCEPTS IN ACTION 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 refined (often through several drawings, each improving on the last) until the customer agrees that the picture depicts what he or she wants. Third, a set of blueprints is designed that presents much more detailed information about the house (e.g., the type of water faucets, where the telephone jacks will be placed). Finally, the house is built following the blueprints, often with some changes directed by the customer as the house is erected. The SDLC has a similar set of four fundamental phases: planning, analysis, design, and implementation. Different projects may emphasize different parts of the SDLC or approach the SDLC phases in different 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 (specific documents and files that provide understanding about the project). For example, when you apply for admission to a university, all students go through the same phases: information gathering, applying, and accepting. Each of these phases has steps—information gathering includes steps such as searching for schools, requesting information, and reading brochures. Students then use techniques (e.g., Internet search- ing) that can be applied to steps (e.g., requesting information) to create deliverables (e.g., evaluations of different aspects of universities). In many projects, the SDLC phases and steps proceed in a logical path from start to finish. In other projects, the project teams move through the steps consecutively, incre- mentally, iteratively, or in other patterns. In this section, we describe the phases, actions, and some of the techniques that are used to accomplish the steps at a very high level. Not all organizations follow the SDLC in exactly the same way. As we shall shortly see, there are many variations on the overall SDLC. 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 under- stand that the SDLC is a process of gradual refinement. The deliverables produced in the analysis phase provide a general idea of the shape of the new system. These deliverables are used as input to the design phase, which then refines them to produce a set of deliverables that describes in much more detailed terms exactly how the system will be built. These deliverables, in turn, are used in the implementation phase to produce the actual system. Each phase refines and elaborates on the work done previously. Planning The planning phase is the fundamental process of understanding why an information system 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 identi- fied: how will it lower costs or increase revenues? Most ideas for new systems come from outside the IS area (from the marketing department, accounting department, etc.) 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. The IS department works together with the person or department that generated the request (called the project sponsor) to conduct a feasibility analysis. The feasibility analysis examines key aspects of the proposed project: ■ The idea’s technical feasibility (Can we build it?) ■ The economic feasibility (Will it provide business value?) ■ The organizational feasibility (If we build it, will it be used?) The 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, staffs the project, and puts tech- niques in place to help the project team control and direct the project through the entire SDLC. The deliverable for project management is a project plan, which describes how the project team will go about developing the system. Analysis The 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), identifies improvement opportunities, and develops a concept for the new system. 4 Chapter 1 Introduction to Systems Analysis and Design This phase has three steps: 1. An analysis strategy is developed to guide the project team’s efforts. Such a strat- egy 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). 2. The next step is requirements gathering (e.g., through interviews or question- naires). The analysis of this information—in conjunction with input from project sponsor and many other people—leads to the development of a concept for a new system. The 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. The set of models typically includes models that represent the data and processes necessary to support the underlying business process. 3. The 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. The system proposal is the initial deliverable that describes what business require- ments the new system should meet. Because it is really the first 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 organiza- tions continue use to 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 The design phase decides how the system will operate, in terms of the hardware, software, and network infrastructure; the user interface, forms and reports; and the specific programs, data- bases, and files 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. The design phase has four steps: 1. The design strategy is first developed. It clarifies whether the system will be devel- oped by the company’s own programmers, whether the system will be outsourced to another firm (usually a consulting firm), or whether the company will buy an existing software package. 2. This leads to the development of the basic architecture design for the system, which describes the hardware, software, and network infrastructure to be used. In most cases, the system will add or change the infrastructure that already exists in the organization. The interface design specifies how the users will move through the system (e.g., navigation methods such as menus and on-screen buttons) and the forms and reports that the system will use. 3. The database and file specifications are developed. These define exactly what data will be stored and where they will be stored. 4. The analyst team develops the program design, which defines the programs that need to be written and exactly what each program will do. This collection of deliverables (architecture design, interface design, database and file specifications, and program design) is the system specification that is handed to the pro- gramming 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. The Systems Development Life Cycle 5 Implementation The final phase in the SDLC is the implementation phase, during which the system is actu- ally built (or purchased, in the case of a packaged software design). This is the phase that usually gets the most attention, because for most systems it is the longest and most expensive single part of the development process. This phase has three steps: 1. System construction is the first step. The system is built and tested to ensure it per- forms 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 first place. 2. The system is installed. Installation is the process by which the old system is turned off and the new one is turned on. It may include a direct cutover approach (in which the new system immediately replaces the old system), a parallel conversion approach (in which both the old and new systems are operated for a month or two until it is clear that there are no bugs in the new system), or a phased conversion strategy (in which the new system is installed in one part of the organization as an initial trial and then gradually installed in others). 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. The analyst team establishes a support plan for the system. This 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. 6 Chapter 1 Introduction to Systems Analysis and Design Consumer electronics is a very competitive business. What might be the success story of the year one year is a forgotten item two years later. Rapid product commoditi- zation makes the consumer electronic marketplace very competitive. Getting the right products to market at the right time with the right components is an ongoing chal- lenge for telecommunications and consumer electronic goods companies. Questions 1. What external data analysis should a consumer electronics company use to determine marketplace needs and its abilities to compete effectively in a marketplace? 2. Staying one step ahead of competitors requires a corporate strategy and the support of information systems. How can information systems and systems analysts contribute to an aggressive corporate strategy? 1–B Keeping Up with Consumer ElectronicsCONCEPTS IN ACTION SYSTEMS DEVELOPMENT METHODOLOGIES A methodology is a formalized approach to implementing the SDLC (i.e., it is a list of steps and deliverables). There are many different systems development methodologies, and each one is unique, based on the order and focus it places on each SDLC phase. Some method- ologies are formal standards used by government agencies, whereas others have been developed by consulting firms to sell to clients. Many organizations have internal method- ologies that have been honed over the years, and they explain exactly how each phase of the SDLC is to be performed in that company. There 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 first on defining the processes (e.g., assemble sandwich ingredients). Data-centered methodologies emphasize data mod- els as the core of the system concept. In Figure 1-1 data-centered methodologies would focus first on defining the contents of the storage areas (e.g., refrigerator) and how the con- tents were organized.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 Systems Development Methodologies 7 2 The classic modern process-centered methodology is that by Edward Yourdon, Modern Structured Analysis (Englewood Cliffs, NJ: Yourdon Press, 1989). An example of a data-centered methodology is information engi- neering; see James Martin, Information Engineering, vols. 1–3 (Englewood Cliffs, NJ: Prentice Hall, 1989). A widely accepted standardized non–object-oriented methodology that balances processes and data is IDEF; see FIPS 183, Integration Definition for Function Modeling, Federal Information Processing Standards Publications, U.S. Department of Commerce, 1993. aParent aRefrigerator aCupboard aSandwich aLunch aLunchBag GetJelly GetPeanutButter GetCookies GetBread CreateSandwich GetMilk CreateLunch GetLunchBag PutLunchInBag FIGURE 1-1 A Simple Behavioral Model for Making Lunch methodologies would focus first on defining the major elements of the system (e.g., sand- wiches, 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 effort devoted to each.3 In the early days of com- puting, programmers did not understand the need for formal and well-planned life cycle methodologies. They 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. This is the same approach that you sometimes use when writing programs for a pro- gramming class. It can work for small programs that require only one programmer, but if the requirements are complex or unclear, you may miss important aspects of the problem and have to start all over again, throwing away part of the program (and the time and effort spent writing it). This approach also makes teamwork difficult because members have lit- tle idea about what needs to be accomplished and how to work together to produce a final product. Structured Design The first category of systems development methodologies is called structured design. These methodologies became dominant in the 1980s, replacing the previous, ad hoc, and undis- ciplined approach. Structured design methodologies adopt a formal step-by-step approach to the SDLC that moves logically from one phase to the next. Numerous process-centered and data-centered methodologies follow the basic approach of the two structured design categories outlined next. Waterfall Development The 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). The key deliv- erables for each phase are typically very long (often 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. This 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 pos- sible 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 first and use as the core of the system—process-model diagrams or data-model diagrams. There is much debate over which should come first, the processes or the data, because both are important to the system. As a result, several dif- ferent structured design methodologies have evolved that follow the basic steps of the waterfall model but use different modeling approaches at different times. Those that attempt to emphasize process-model diagrams as the core of the system are process cen- tered, whereas those that emphasize data-model diagrams as the core of the system con- cept are data centered. 8 Chapter 1 Introduction to Systems Analysis and Design 3 A good reference for comparing systems development methodologies is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996). The two key advantages of the structured design waterfall approach are that it iden- tifies system requirements long before programming begins and it minimizes changes to the requirements as the project proceeds. The two key disadvantages are that the design must be completely specified 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 (usually many months or years). Lengthy deliverables often result in poor com- munication; the result is that important requirements can be overlooked in the volumi- nous documentation. Users are rarely prepared for their introduction to the new system, which occurs long after the initial idea for the system was introduced. 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 num- ber of valves on the engine?). A system may also require significant rework because the business environment has changed from the time that the analysis phase occurred. When changes do occur, it means going back to the initial phases and following the change through each of the subsequent phases in turn. Parallel Development Parallel development methodology attempts to address the prob- lem 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, there is a final integration of the separate pieces, and the system is delivered (see Figure 1-3). The primary advantage of this methodology is that it can reduce the schedule time to deliver a system; thus, there is less chance of changes in the business environment causing rework. However, the approach still suffers from problems caused by paper documents. It also adds a new problem: Sometimes the subprojects are not completely independent; design decisions made in one subproject may affect another, and the end of the project may require significant integration efforts. Systems Development Methodologies 9 System Planning Analysis Design Implementation FIGURE 1-2 A Waterfall Development–based Methodology Rapid Application Development (RAD) A second category of methodologies includes rapid application development (RAD)–based methodologies. These 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 developed 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 Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, such as CASE tools, joint application design (JAD) sessions, fourth-generation/visual program- ming languages that simplify and speed up programming (e.g., Visual Basic), and code generators that automatically produce programs from design specifications. The combi- nation 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. Due to the use of the tools and techniques that can improve the speed and quality of systems develop- ment, user expectations of what is possible may dramatically change. As a user better 10 Chapter 1 Introduction to Systems Analysis and Design System Planning Analysis Design Implementation Design Integration Implementation Design Implementation Design Subproject 2 Subproject 1 Subproject 3 FIGURE 1-3 A Parallel Development–based Methodology 4 One of the best RAD books is Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996). understands the information technology, the systems requirements tend to expand. This was less of a problem when using methodologies that spent a lot of time thoroughly documenting requirements. Process-centered, data-centered, and object-oriented methodologies that follow the basic approaches of the three RAD categories are described in the following sections. Phased Development A phased development–based methodology breaks an overall system into a series of versions, which are developed sequentially. The analysis phase identifies the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. The most important and fundamental require- ments are bundled into the first version of the system. The analysis phase then leads into design and implementation—but only with the set of requirements identified 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 identified requirements and combined with new ideas and Systems Development Methodologies 11 System version 1 Planning Analysis Analysis Implementation Design Analysis Implementation Design Analysis Implementation Design System version 2 System version 3 FIGURE 1-4 A Phased Development–based Methodology 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. This 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 first, it does begin to provide business value sooner than if the system were delivered after 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. The 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 first 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. The first prototype is usually the first part of the system that is used. This is shown to the users and the project sponsor, who pro- vide comments. These comments are used to reanalyze, redesign, and reimplement a sec- ond prototype, which provides a few more features. This 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. After the prototype (now called the system) is installed, refinement occurs until it is accepted as the new system (see Figure 1-5). The 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 organiza- tional use at first. 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 refine real requirements. Rather than attempting to understand a sys- tem specification on paper, the users can interact with the prototype to better understand what it can and cannot do. The major problem with prototyping is that its fast-paced system releases challenge attempts to conduct careful, methodical analysis. Often the prototype undergoes such sig- nificant changes that many initial design decisions become poor ones. This can cause 12 Chapter 1 Introduction to Systems Analysis and Design System prototype System Planning Analysis Design Implementation Implementation FIGURE 1-5 A Prototyping-based Methodology problems in the development of complex systems because fundamental issues and prob- lems are not recognized 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 after it had been driven 10,000 miles). Throwaway Prototyping Throwaway prototyping–based methodologies are similar to prototyping-based methodologies in that they include the development of prototypes; however, throwaway prototypes are done at a different point in the SDLC. These prototypes are used for a very different purpose than those previously discussed, and they have a very different appearance (see Figure 1-6). The throwaway prototyping–based methodologies have a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept. How- ever, users may 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 ana- lyzing, designing, and building a design prototype. A design prototype is not a working sys- tem; it is a product that represents a part of the system that needs additional refinement, and it contains only enough detail to enable users to understand the issues under consid- eration. For example, suppose users are not completely clear on how an order entry system should work. The analyst team might build a series of HTML pages viewed using a Web browser to help the users visualize such a system. 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. The 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 probably relies on several design prototypes during the analysis and design phases. Each of the prototypes is used to mini- mize the risk associated with the system by confirming that important issues are under- stood before the real system is built. Once the issues are resolved, the project moves into design and implementation. At this point, the design prototypes are thrown away, which is an important difference between these methodologies and prototyping methodologies, in which the prototypes evolve into the final system. Systems Development Methodologies 13 Design prototype System Analysis Analysis Design Implementation Planning Implementation Design FIGURE 1-6 A Throwaway Prototyping–based Methodology Throwaway prototyping–based methodologies balance the benefits of well-thought- out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built. It may take longer to deliver the final system as compared to prototyping-based methodologies (because the prototypes do not become the final system), 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. These programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. They focus on streamlining the SDLC by eliminating much of the modeling and documentation overhead and the time spent on those tasks. Instead, projects emphasize simple, iterative application development. Examples of agile develop- ment methodologies include extreme programming, Scrum, and the Dynamic Systems Development Method (DSDM). The agile development approach, as described next, typi- cally is used in conjunction with object-oriented methodologies. Extreme Programming6 Extreme programming (XP) is founded on four core values: communication, simplicity, feedback, and courage. These four values provide a founda- tion 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.7 Third, developers must make incremental changes to grow the sys- tem, and they must not only accept change, they must embrace change. Fourth, developers must have a quality-first mentality. XP also supports team members in developing their own skills. Three 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 systems very quickly. After a superficial planning process, projects perform analysis, design, and implementation phases iteratively (see Figure 1-7). 14 Chapter 1 Introduction to Systems Analysis and Design 5 Two good sources of information on agile development and object-oriented systems is S. W. Ambler, Agile Modeling: Effective Practices for Extreme Programming and The Unified Process (New York: Wiley, 2002), and R. C. Martin, Agile Software Development: Principles, Patterns, and Practices (Upper Saddle River, NJ: Prentice Hall, 2003). 6 For more information, see K. Beck, eXtreme Programming Explained: Embrace Change (Reading, MA: Addison- Wesley, 2000), M. Lippert, S. Roock, and H. Wolf, eXtreme Programming in Action: Practical Experiences from Real World Projects (New York: Wiley, 2002), or www.extremeprogramming.com. 7 Keep It Simple, Stupid. Implementation Design Analysis System Planning FIGURE 1-7 The Extreme Programming Methodology Testing and efficient coding practices are core to XP.In fact, 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. XP relies heavily on refactoring, which is a disciplined way to restructure code to keep it simple. An XP project begins with user stories that describe what the system needs to do. Then, 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. For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine. However, if the project is not small or the teams aren’t jelled,8 then the success of an XP development effort is doubtful. This tends to throw the whole idea of bringing outside contractors into an existing team environment using XP into doubt.9 The chance of outsiders “jelling” with insiders may simply be too optimistic. XP requires a great deal of discipline; otherwise projects will become unfocused and chaotic. Furthermore, it is recommended only for small groups of developers—no more than ten developers, and it is not advised for large mission-critical applications. Due 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 informa- tion 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.10 Selecting the Appropriate Development Methodology Because there are many methodologies, the first challenge faced by analysts is to select 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 find that organi- zations range from having one “approved” methodology to having several methodology options to having no formal policies at all. Figure 1-8 summarizes some important methodology selection criteria. One impor- tant item not discussed in this figure 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 significant learning curve. Often 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 significantly increase the speed in which the methodology can deliver a final system. Clarity of User Requirements When the user requirements for a system are unclear, it is difficult to understand them by talking about them and explaining them with written reports. Systems Development Methodologies 15 8 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). 9 Considering the tendency for offshore outsourcing, this is a major obstacle for XP to overcome. For more infor- mation on offshore outsourcing, see P. Thibodeau, “ITAA Panel Debates Outsourcing Pros, Cons,” Computer- world Morning Update (September 25, 2003), and S. W.Ambler,“Chicken Little Was Right,”Software Development (October 2003). 10 Many of the observations described on the utility of XP as a development approach were based on conversa- tions with Brian Henderson-Sellers. 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. Prototyping- and throwaway prototyping–based RAD methodologies are usually more appropriate when user requirements are unclear because they provide prototypes for users to interact with early in the SDLC. Familiarity with Technology When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first Web development project with Java), early application of the new technology in the methodology 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. Throwaway 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 are good as well, because they create opportunities to investigate the technology in some depth before the design is complete. 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 after 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. Throwaway prototyping–based methodologies are particularly well suited to such detailed analysis and design, as opposed to prototyping-based methodologies, which are not. The traditional structured design–based methodologies can handle complex systems, but with- out 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 methodologies. System Reliability System reliability is usually an important factor in system development— after 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, missile control systems), whereas for other applications (e.g., games, Internet video) it is merely important. Throwaway prototyping methodologies are the most appropriate when system 16 Chapter 1 Introduction to Systems Analysis and Design With Unclear User Requirements Poor Poor Good Excellent Excellent Excellent With Unfamiliar Technology Poor Poor Good Poor Excellent Poor That Are Complex Good Good Good Poor Excellent Poor That Are Reliable Good Good Good Poor Excellent Good With a Short Time Schedule Poor Good Excellent Excellent Good Excellent With Schedule Visibility Poor Poor Excellent Excellent Good Good Agile Structured Methodologies RAD Methodologies Methodologies Ability to Develop Throwaway Systems Waterfall Parallel Phased Prototyping Prototyping XP FIGURE 1-8 Criteria for Selecting a Methodology reliability is a high priority, because it combines detailed analysis and design phases with the ability for the project team to test many different approaches through design proto- types before completing the design. 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 dependable systems. Short Time Schedules Projects that have short time schedules are well suited for RAD- based methodologies. This is due to them being designed to increase the speed of develop- ment. Prototyping and phased development–based methodologies are excellent choices when timelines are short because they best enable the project team to adjust the function- ality in the system based on a specific delivery date, and if the project schedule starts to slip, it can be readjusted by removing functionality from the version or prototype under devel- opment. Waterfall-based methodologies are the worst choice when time is at a premium because they do not allow for easy schedule changes. Schedule Visibility One of the greatest challenges in systems development is determin- ing whether a project is on schedule. This is particularly true of the structured design methodologies because design and implementation occur at the end of the project. The 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. Object-Oriented Systems Analysis and Design (OOSAD) 17 Suppose you are an analyst for the Roanoke Software Consulting Company (RSCC), a large consulting firm with offices around the world. The company wants to build a new knowledge management system that can identify and track the expertise of individual consultants anywhere in the world based on their education and the various consulting projects on which they have worked. Assume that this is a new idea that has never before been attempted in RSCC or elsewhere. RSCC has an international network, but the offices in each country may use somewhat different hardware and software. RSCC management wants the system up and running within a year. Question 1. What type of methodology would you recommend RSCC use? Why? 1-1 Selecting a MethodologyYOUR TURN OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN (OOSAD) Object-oriented approaches to developing information systems, technically speaking, can use any of the traditional methodologies (waterfall development, parallel development, phased development, prototyping, and throwaway prototyping). However, the object- oriented approaches are most associated with a phased development RAD methodology. The primary difference between a traditional approach like structured design and an object- oriented approach is how a problem is decomposed. In traditional approaches, the problem decomposition process is either process centric or data centric. However, processes and data are so closely related that it is difficult to pick one or the other as the primary focus. Based on this lack of congruence with the real world, new object-oriented methodologies have emerged that use the RAD-based sequence of SDLC phases but attempt to balance the emphasis between process and data by focusing the decomposition of problems on objects that contain both data and processes. Both approaches are valid approaches to developing information systems. In this book, we focus only on object-oriented approaches.11 According to the creators of the Unified Modeling Language (UML), Grady Booch, Ivar Jacobson, and James Rumbaugh,12 any modern object-oriented approach to developing information systems must be (1) use-case driven, (2) architecture-centric, and (3) iterative and incremental. Use-Case Driven Use-case driven means that use cases are the primary modeling tools defining the behavior of the system. A use case describes how the user interacts with the system to perform some activity, such as placing an order, making a reservation, or searching for information. The use cases are used to identify and to communicate the requirements for the system to the programmers who must write the system. Use cases are inherently simple because they focus on only one activity at a time. In contrast, the process model diagrams used by traditional structured and RAD methodolo- gies are far more complex because they require the system analyst and user to develop models of the entire system. With traditional methodologies, each business activity is decomposed into a set of subprocesses, which are, in turn, decomposed into further sub- processes, and so on. This goes on until no further process decomposition makes sense, and it often requires dozens of pages of interlocking diagrams. In contrast, use cases focus on only one activity at a time, so developing models is much simpler.13 Architecture Centric Any modern approach to systems analysis and design should be architecture centric. Archi- tecture centric means that the underlying software architecture of the evolving system spec- ification drives the specification, construction, and documentation of the system. Modern object-oriented systems analysis and design approaches should support at least three sep- arate but interrelated architectural views of a system: functional, static, and dynamic. The functional, or external, view describes the behavior of the system from the perspective of the user. The structural, or static, view describes the system in terms of attributes, methods, classes, and relationships. The behavioral, or dynamic, view describes the behavior of the system in terms of messages passed among objects and state changes within an object. Iterative and Incremental Modern object-oriented systems analysis and design approaches emphasize iterative and incre- mental development that undergoes continuous testing and refinement throughout the life of the project. This implies that the systems analysts develop their understanding of a user’s prob- lem by building up the three architectural views little by little. The systems analyst does this by 18 Chapter 1 Introduction to Systems Analysis and Design 11 See Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth, Systems Analysis and Design: An Applied Approach, 3rd ed. (New York: Wiley, 2006) for a description of the traditional approaches. 12 Grady Booch, Ivar Jacobson, and James Rumbaugh, The Unified Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). 13 For those of you that have experience with traditional structured analysis and design, this will be one of the most unusual aspects of object-oriented analysis and design using UML. Structured approaches emphasize the decomposition of the complete business process into subprocesses and sub-subprocesses. Object-oriented approaches stress focusing on just one use-case activity at a time and distributing that single use case over a set of communicating and collaborating objects. Therefore, use-case modeling may seem initially unsettling or counterintuitive, but in the long run this single focus does make analysis and design simpler. working with the user to create a functional representation of the system under study. Next, the analyst attempts to build a structural representation of the evolving system. Using the structural representation of the system, the analyst distributes the functionality of the system over the evolving structure to create a behavioral representation of the evolving system. As an analyst works with the user in developing the three architectural views of the evolving system, the analyst will iterate over each of and among the views. That is, as the analyst better understands the structural and behavioral views, the analyst will uncover missing requirements or misrepresentations in the functional view. This, in turn, can cause changes to be cascaded back through the structural and behavioral views. All three archi- tectural views of the system are interlinked and dependent on each other (see Figure 1-9). As each increment and iteration is completed, a more complete representation of the user’s real functional requirements are uncovered. Benefits of Object-Oriented Systems Analysis and Design Concepts in the object-oriented approach enable analysts to break a complex system into smaller, more manageable modules, work on the modules individually, and easily piece the modules back together to form an information system. This modularity makes system development easier to grasp, easier to share among members of a project team, and easier to communicate to users, who are needed to provide requirements and confirm how well the system meets the requirements throughout the SDLC. By modularizing system devel- opment, the project team actually is creating reusable pieces that can be plugged into other systems efforts or used as starting points for other projects. Ultimately, this can save time because new projects don’t have to start completely from scratch. Many people argue that “object-think” is a much more realistic way to think about the real world. Users typically do not think in terms of data or process; instead, they see their business as a collection of logical units that contain both—so communicating in terms of objects improves the interaction between a user and an analyst or developer. THE UNIFIED PROCESS The Unified Process is a specific methodology that maps out when and how to use the var- ious UML techniques for object-oriented analysis and design. The primary contributors were Grady Booch, Ivar Jacobsen, and James Rumbaugh of Rational. Whereas the UML provides structural support for developing the structure and behavior of an information system, the Unified Process provides the behavioral support. The Unified Process, of course, is use-case driven, architecture centric, and iterative and incremental. The Unified Process 19 Functional view Structural view Behavioral view Object-Oriented AnalysisFIGURE 1-9 Iterative and Incremental Development The Unified Process is a two-dimensional systems development process described by a set of phases and workflows. The phases are inception, elaboration, construction, and tran- sition. The workflows include business modeling, requirements, analysis, design, imple- mentation, test, deployment, project management, configuration and change management, and environment. In the remainder of this section, we describe the phases and workflows of the Unified Process.14 Figure 1-10 depicts the Unified Process. Phases The phases of the Unified Process support an analyst in developing information systems in an iterative and incremental manner. The phases describe how an information system evolves through time. Depending on which development phase the evolving system is 20 Chapter 1 Introduction to Systems Analysis and Design 14 The material in this section is based on Khawar Zaman Ahmed and Cary E. Umrysh, Developing Enterprise Java Applications with J2EE and UML (Boston, MA: Addison-Wesley, 2002); Jim Arlow and Ila Neustadt, UML and The Unified Process: Practical Object-Oriented Analysis & Design (Boston, MA: Addison-Wesley, 2002); Peter Eeles, Kelli Houston, Wojtek Kozacynski, Building J2EE Applications with the Rational Unified Process, (Boston, MA: Addison-Wesley, 2003); Ivar Jacobson, Grady Booch, and James Rumbaugh, The Unified Software Development Process (Reading, MA: Addison-Wesley, 1999); Phillipe Krutchten, The Rational Unified Process: An Introduction, 2nd ed. (Boston, MA: Addison-Wesley, 2000). Phases Business Modeling Inception Engineering Workflows Elaboration Construction Transition Phases Inception Supporting Workflows Elaboration Construction Transition Requirements Analysis Design Implementation Configuration and Change Management Iter 1 … Iter i Iter i + 1 … Iter j Iter j + 1 … Iter k Iter k + 1 … Iter m Project Management Environment Test Deployment FIGURE 1-10 The Unified Process currently in, the level of activity will vary over the workflows. The curve in Figure 1-10 asso- ciated with each workflow approximates the amount of activity that takes place during the specific phase. For example, the inception phase primarily involves the business modeling and requirements workflows, while practically ignoring the test and deployment work- flows. Each phase contains a set of iterations, and each iteration uses the various workflows to create an incremental version of the evolving information system. As the system evolves through the phases, it improves and becomes more complete. Each phase has objectives, a focus of activity over the workflows, and incremental deliverables. Each of the phases is described next. Inception In many ways, the inception phase is very similar to the planning phase of a traditional SDLC approach. In this phase, a business case is made for the proposed system. This includes feasibility analysis that should answer questions such as the following: Do we have the technical capability to build it (technical feasibility)? If we build it, will it provide business value (economic feasibility)? If we build it, will it be used by the organization (organizational feasibility)? To answer these questions, the development team performs work related primarily to the business modeling, requirements, and analysis workflows. In some cases, depending on the technical difficulties that could be encountered during the development of the system, a throwaway prototype is developed. This implies that the design, implementation, and test workflows could also be involved. The project management and environment supporting workflows are very relevant to this phase. The primary deliverables from the inception phase are (1) a vision document that sets the scope of the project, identifies the primary requirements and constraints, sets up an initial project plan, and describes the feasibility of and risks associated with the project, and (2) the adoption of the necessary environment to develop the system. Elaboration When we typically think about object-oriented systems analysis and design, the activities related to the elaboration phase of the Unified Process are the most relevant. The analysis and design workflows are the primary focus during this phase. The elaboration phase continues with developing the vision document, including finalizing the business case, revising the risk assessment, and completing a project plan in sufficient detail to allow the stakeholders to be able to agree with constructing the actual final system. It deals with gathering the requirements, building the UML structural and behavioral models of the problem domain, and detailing how the problem domain models fit into the evolving sys- tem architecture. Developers are involved with all but the deployment engineering workflow in this phase. As the developers iterate over the workflows, the importance of addressing configuration and change management becomes apparent. Also, the development tools acquired during the inception phase become critical to the success of the project during this phase.15 The primary deliverables of this phase include (1) the UML structure and behavior diagrams and (2) an executable of a baseline version of the evolving information system. The baseline version serves as the foundation for all later iterations. By providing a solid foundation at this point in time, the developers have a basis for completing the system in the construction and transition phases. The Unified Process 21 15 With UML comprising fourteen different, related diagramming techniques, keeping the diagrams coordinated and the different versions of the evolving system synchronized is typically beyond the capabilities of a mere mor- tal systems developer. These tools typically include project management and CASE (Computer-Aided Software Engineering) tools. We describe the use of these tools in Chapter 3. Construction The construction phase focuses heavily on programming the evolving infor- mation system. As such, it is primarily concerned with the implementation workflow.However, the requirements workflow and the analysis and design workflows also are involved with this phase. It is during this phase that missing requirements are uncovered, and the analysis and design models are finally completed. Typically, there are iterations of the workflows during this phase, and during the last iteration, the deployment workflow kicks into high gear. The con- figuration and change management workflow, with its version control activities, becomes extremely important during the construction phase. At times, an iteration may have to be rolled back. Without good version controls, rolling back to a previous version (incremental implementation) of the system is nearly impossible. The primary deliverable of this phase is an implementation of the system that can be released for beta and acceptance testing. Transition Like the construction phase, the transition phase addresses aspects typically associated with the implementation phase of a traditional SDLC approach. Its primary focus is on the testing and deployment workflows. Essentially, the business modeling, require- ments, and analysis workflows should have been completed in earlier iterations of the evolv- ing information system. Depending on the results from the testing workflow, it is possible that some redesign and programming activities on the design and implementation work- flows could be necessary, but they should be minimal at this point in time. From a manage- rial perspective, the project management, configuration and change management, and environment are involved. Some of the activities that take place are beta and acceptance test- ing, fine-tuning the design and implementation, user training, and the actual rolling out of the final product onto a production platform. Obviously, the primary deliverable is the actual executable information system. The other deliverables include user manuals, a plan to support the users, and a plan for upgrading the information system in the future. Workflows The workflows describe the tasks or activities that a developer performs to evolve an infor- mation system over time. The workflows of the Unified Process are grouped into two broad categories: engineering and supporting. Engineering Workflows Engineering workflows include business modeling, requirements, analysis, design, implementation, test, and deployment workflows. The engineering workflows deal with the activities that produce the technical product (i.e., the information system). Business Modeling Workflow The business modeling workflow uncovers problems and identifies potential projects within a user organization. This workflow aids management in understanding the scope of the projects that can improve the efficiency and effectiveness of a user organization. The primary purpose of business modeling is to ensure that both developer and user organizations understand where and how the to-be-developed information system fits into the business processes of the user organization. This workflow is primarily executed during the inception phase to ensure that we develop information systems that make business sense. The activities that take place on this workflow are most closely associated with the plan- ning phase of the traditional SDLC; however, requirements gathering and use-case and busi- ness process modeling techniques also help to understand the business situation. Requirements Workflow In the Unified Process, the requirements workflow includes eliciting both functional and nonfunctional requirements. Typically, requirements are gathered from project stakeholders, such as end users, managers within the end user orga- nization, and even customers. There are many different ways to capture requirements, 22 Chapter 1 Introduction to Systems Analysis and Design including interviews, observation techniques, joint application development, document analysis, and questionnaires. The requirements workflow is utilized the most during the inception and elaboration phases. The identified requirements are very helpful for devel- oping the vision document and the use cases used throughout the development process. Additional requirements tend to be discovered throughout the development process. In fact, only the transition phase tends to have few, if any, additional requirements identified. Analysis Workflow The analysis workflow primarily addresses the creation of an analysis model of the problem domain. In the Unified Process, the analyst begins designing the archi- tecture associated with the problem domain; using the UML, the analyst creates structural and behavioral diagrams that depict a description of the problem domain classes and their interactions. The primary purpose of the analysis workflow is to ensure that both the devel- oper and user organizations understand the underlying problem and its domain without overanalyzing. If they are not careful, analysts can create analysis paralysis, which occurs when the project becomes so bogged down with analysis that the system is never actually designed or implemented. A second purpose of the analysis workflow is to identify useful reusable classes for class libraries. By reusing predefined classes, the analyst can avoid “reinventing the wheel” when creating the structural and behavioral diagrams. The analysis workflow is pre- dominantly associated with the elaboration phase, but like the requirements workflow, it is possible that additional analysis will be required throughout the development process. Design Workflow The design workflow transitions the analysis model into a form that can be used to implement the system: the design model. Whereas the analysis workflow con- centrated on understanding the problem domain, the design workflow focuses on devel- oping a solution that will execute in a specific environment. Basically, the design workflow simply enhances the description of the evolving information system by adding classes that address the environment of the information system to the evolving analysis model. As such, the design workflow uses activities such as user interface design, database design, physical architecture design, detailed problem domain class design, and the optimization of the evolving information system. The design workflow is associated primarily with the elabo- ration and construction phases of the Unified Process. Implementation Workflow The primary purpose of the implementation workflow is to create an executable solution based on the design model (i.e., programming). This includes not only writing new classes but also incorporating reusable classes from executable class libraries into the evolving solution. As with any programming activity, testing of the new classes and their interactions with the incorporated reusable classes must occur. Finally, in the case of multiple groups performing the implementation of the information system, the implementers also must integrate the separate, individually tested modules to create an executable version of the system. The implementation workflow is associated primarily with the elaboration and construction phases. Testing Workflow The primary purpose of the testing workflow is to increase the quality of the evolving system. As such, testing goes beyond the simple unit testing associated with the implementation workflow. In this case, testing also includes testing the integration of all modules used to implement the system, user acceptance testing, and the actual alpha testing of the software. Practically speaking, testing should go on throughout the development of the system; testing of the analysis and design models occurs during the elaboration and construction phases, whereas implementation testing is performed primarily during the con- struction and, to some degree, transition phases. Basically, at the end of each iteration during the development of the information system, some type of test should be performed. The Unified Process 23 Deployment Workflow The deployment workflow is most associated with the transition phase of the Unified Process. The deployment workflow includes activities, such as soft- ware packaging, distribution, installation, and beta testing. When actually deploying the new information system into a user organization, the developers may have to convert the current data, interface the new software with the existing software, and provide end user training on the use of the new system. Supporting Workflows The supporting workflows include the project management, configuration and change management, and the environment workflows. The supporting workflows focus on the managerial aspects of information system development. Project Management Workflow Whereas the other workflows associated with the Unified Process are technically active during all four phases, the project management workflow is the only truly cross-phase workflow. The development process supports incremental and iterative development, so information systems tend to grow or evolve over time. At the end of each iteration, a new incremental version of the system is ready for delivery. The project management workflow is quite important due to the complexity of the two-dimensional development model of the Unified Process (workflows and phases). This workflow’s activ- ities include risk identification and management, scope management, estimating the time to complete each iteration and the entire project, estimating the cost of the individual iter- ation and the whole project, and tracking the progress being made toward the final version of the evolving information system. Configuration and Change Management Workflow The primary purpose of the con- figuration and change management workflow is to keep track of the state of the evolving sys- tem. In a nutshell, the evolving information system comprises a set of artifacts, including, for example, diagrams, source code, and executables. During the development process, these artifacts are modified. A substantial amount of work—and, hence, dollars—is involved in the development of the artifacts. As such, the artifacts themselves should be handled as any expensive asset would be handled—access controls must be put into place to safeguard the artifacts from being stolen or destroyed. Furthermore, because the artifacts are modified on a regular, if not continuous, basis, good version control mechanisms should be established. Finally, a good deal of project management information needs to be captured (e.g., author, time, and location of each modification). The configuration and change management work- flow is associated mostly with the construction and transition phases. Environment Workflow During the development of an information system, the devel- opment team needs to use different tools and processes. The environment workflow addresses these needs. For example, a computer-aided software engineering tool that sup- ports the development of an object-oriented information system via the UML could be required. Other tools necessary include programming environments, project management tools, and configuration management tools. The environment workflow involves acquir- ing and installing these tools. Even though this workflow can be active during all of the phases of the Unified Process, it should be involved primarily with the inception phase. Extensions to the Unified Process As large and as complex as the Unified Process is, many authors have pointed out a set of critical weaknesses. First, the Unified Process does not address staffing, budgeting, or contract management issues. These activities were explicitly left out of the Unified Process. Second, the Unified Process does not address issues relating to maintenance, operations, or support of the product once it has been delivered. As such, it is not a 24 Chapter 1 Introduction to Systems Analysis and Design complete software process; it is only a development process. Third, the Unified Process does not address cross- or interproject issues. Considering the importance of reuse in object-oriented systems development and the fact that in many organizations employees work on many different projects at the same time, leaving out interproject issues is a major omission. To address these omissions, Ambler and Constantine suggest the addition of a pro- duction phase and two workflows: the operations and support workflow and the infra- structure management workflow (see Figure 1-11).16 In addition to these new workflows, The Unified Process 25 Phases Business Modeling Inception Engineering Workflows Elaboration Construction Transition Phases Inception Supporting Workflows Elaboration Construction Transition Production Production Requirements Analysis Design Implementation Configuration and Change Management Infrastructure Management Project Management Environment Operations and Support Iter 1 … Iter i Iter i + 1 … Iter j Iter j + 1 … Iter k Iter k + 1 … Iter m Test Deployment FIGURE 1-11 The Enhanced Unified Process 16 S. W. Ambler and L. L. Constantine, The Unified Process Inception Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Elaboration Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Construction Phase: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2000); S. W. Ambler and L. L. Constantine, The Unified Process Transition and Production Phases: Best Practices in Implementing the UP (Lawrence, KS: CMP Books, 2002). the test, deployment, and environment workflows are modified, and the project manage- ment and configuration and change management workflows are extended into the pro- duction phase. These extensions are based on alternative object-oriented software processes: the OPEN process and the Object-Oriented Software Process.17 The new phase, new workflows, and the modifications and extensions to the existing workflows are described next. Production Phase The production phase is concerned primarily with issues related to the software product after it has been successfully deployed. This phase focuses on issues related to updating, maintaining, and operating the software. Unlike the previous phases, there are no iterations or incremental deliverables. If a new release of the software is to be developed, then the developers must begin a new run through the first four phases. Based on the activities that take place during this phase, no engineering workflows are relevant. The supporting workflows that are active during this phase include the configuration and change management workflow, the project management workflow, the new operations and support workflow, and the infrastructure management workflow. Operations and Support Workflow The operations and support workflow, as you might guess, addresses issues related to supporting the current version of the software and oper- ating the software on a daily basis. Activities include creating plans for the operation and support of the software product once it has been deployed, creating training and user documentation, putting into place necessary backup procedures, monitoring and optimizing the performance of the software, and performing corrective maintenance on the software. This workflow becomes active during the construction phase; its level of activity increases throughout the transition and, finally, the production phase. The workflow finally drops off when the current version of the software is replaced by a new version. Many developers are under the false impression that once the software has been delivered to the customer, their work is finished. In most cases, the work of supporting the software product is much more costly and time consuming than the original development. As such, the developer’s work may have just begun. Infrastructure Management Workflow The infrastructure management workflow’s primary purpose is to support the development of the infrastructure necessary to develop object-oriented systems. Activities such as development and modification of libraries, standards, and enterprise models are very important. When the development and maintenance of a problem domain architecture model goes beyond the scope of a single project and reuse is going to occur, the infrastructure management workflow is essential. Another very important set of cross-project activities is the improvement of the software development process. Because the activities on this workflow tend to affect many projects and the Unified Process focuses only on a specific project, the Unified Process tends to ignore these activities (i.e., they are simply beyond the scope and pur- pose of the Unified Process). 26 Chapter 1 Introduction to Systems Analysis and Design 17 S. W. Ambler, Process Patterns—Building Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1998); S. W. Ambler, More Process Patterns—Delivering Large-Scale Systems Using Object Technology (Cambridge, UK: SIGS Books/Cambridge University Press, 1999); I. Graham, B. Henderson-Sellers, and H. Younessi, The OPEN Process Specification (Harlow, UK: Addison-Wesley, 1997); B. Henderson-Sellers and B. Unhelkar, OPEN Modeling with UML (Harlow, UK: Addison-Wesley, 2000). Existing Workflow Modifications and Extensions In addition to the workflows that were added to address deficiencies contained in the Unified Process, existing workflows had to be modified and/or extended into the production phase. These workflows include the test, deployment, environment, project management, and configuration and change man- agement workflows. Test Workflow For high-quality information systems to be developed, testing should be done on every deliverable, including those created during the inception phase. Otherwise, less than quality systems will be delivered to the customer. Deployment Workflow Legacy systems exist in most corporations today, and these sys- tems have databases associated with them that must be converted to interact with the new systems. Due to the complexity of deploying new systems, the conversion requires signifi- cant planning. As such, the activities on the deployment workflow need to begin in the inception phase instead of waiting until the end of the construction phase, as suggested by the Unified Process. Environment Workflow The environment workflow needed to be modified to include activities related to setting up the operations and production environment. The actual work performed is similar to the work related to setting up the development environment that was performed during the inception phase. In this case, the additional work is per- formed during the transition phase. Project Management Workflow Even though the project management workflow does not include staffing the project, managing the contracts among the customers and ven- dors, and managing the project’s budget, these activities are crucial to the success of any software development project. As such, we suggest extending project management to include these activities. Furthermore, this workflow should additionally occur in the pro- duction phase to address issues such as training, staff management, and client relation- ship management. Configuration and Change Management Workflow The configuration and change management workflow is extended into the new production phase. Activities performed during the production phase include identifying potential improvements to the opera- tional system and assessing the potential impact of the proposed changes. Once developers have identified these changes and understood their impact, they can schedule the changes to be made and deployed with future releases. Figure 1-12 shows the chapters in which the Enhanced Unified Process’s phases and workflows are covered. Given the offshore outsourcing and automation of information technology,18 in this textbook, we focus primarily on the elaboration phase and the busi- ness modeling, requirements, analysis, design, and project management workflows of the Enhanced Unified Process. However, as Figure 1-12 shows, the other phases and workflows are covered. In many object-oriented systems development environments today, code gen- eration is supported. Thus, from a business perspective, we believe the activities associated with these workflows are the most important. The Unified Process 27 18 See Thomas L. Friedman, The World Is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Edition (New York: Farrar, Straus, and Giroux, 2006); and Daniel H. Pink, A Whole New Mind: Why Right-Brainers Will Rule the Future (New York: Riverhead Books, 2006). 28 Chapter 1 Introduction to Systems Analysis and Design Inception 2–5 Elaboration 4–12 Construction 9, 13 Transition 13, 14 Production 14 Business Modeling 2, 4–6 Requirements 4–6, 11 Analysis 5–7 Design 8–12 Implementation 10, 13 Test 8, 13 Deployment 14 Project Management 2, 3, 5, 14 Configuration and 2, 14 Change Management Environment 3 Operations and Support 14 Infrastructure 3 Management Enhanced UP Phases Chapters Enhanced UP Chapters Engineering Workflows Enhanced UP Chapters Supporting Workflows FIGURE 1-12 The Enhanced Unified Process and the Textbook Organization Review Figures 1-10, 1-11, and 1-12. Based on your understanding of the UP and the EUP, suggest a set of steps for an alternative object-oriented systems development method. Be sure that the steps are capable of delivering an executable and maintainable system. 1-2 OO Systems Analysis and Design MethodologyYOUR TURN THE UNIFIED MODELING LANGUAGE Until 1995, object concepts were popular but implemented in many different ways by differ- ent developers. Each developer had his or her own methodology and notation (e.g., Booch, Coad, Moses, OMT, OOSE, SOMA.)19 Then in 1995, Rational Software brought three indus- try leaders together to create a single approach to object-oriented systems development. Grady Booch, Ivar Jacobson, and James Rumbaugh worked with others to create a standard set of diagramming techniques known as the Unified Modeling Language (UML). The objec- tive of UML was to provide a common vocabulary of object-oriented terms and diagram- ming techniques rich enough to model any systems development project from analysis through implementation. In November 1997, the Object Management Group (OMG) for- mally accepted UML as the standard for all object developers. During the following years, the UML has gone through multiple minor revisions. The current version of UML, Version 2.0, was accepted by the members of the OMG during their spring and summer meetings of 2003. Version 2.0 of the UML defines a set of fourteen diagramming techniques used to model a system. The diagrams are broken into two major groupings: one for modeling structure of a system and one for modeling behavior. Structure diagrams provide a way to represent the data and static relationships in an information system. The structure diagrams include class, object, package, deployment, component, and composite structure diagrams. Behavior diagrams provide the analyst with a way to depict the dynamic relationships among the instances or objects that represent the business information system. They also allow the modeling of the dynamic behavior of individual objects throughout their lifetime. The behavior diagrams support the analyst in modeling the functional requirements of an evolv- ing information system. The behavior modeling diagrams include activity, sequence, com- munication, interaction overview, timing, behavior state machine, protocol state machine, and use-case diagrams.20 Figure 1-13 provides an overview of these diagrams. Depending on where in the development process the system is, different diagrams play a more important role. In some cases, the same diagramming technique is used throughout the development process. In that case, the diagrams start off very conceptual and abstract. As the system is developed, the diagrams evolve to include details that ultimately lead to code gen- eration and development. In other words, the diagrams move from documenting the require- ments to laying out the design. Overall, the consistent notation, integration among the diagramming techniques, and application of the diagrams across the entire development process makes the UML a powerful and flexible language for analysts and developers. Later chapters provide more detail on using a subset of the UML in object-oriented systems analy- sis and design. In particular, these chapters describe activity, use-case, class, object, sequence, communication, and package diagrams and the behavioral state machines. The Unified Modeling Language 29 19 See Grady Booch, Object-Oriented Analysis and Design with Applications, 2nd ed. (Redwood City, CA: Benjamin/Cummings, 1994); Peter Coad and Edward Yourdon, Object-Oriented Analysis, 2nd ed. (Englewood Cliffs, NJ: Yourdon Press, 1991); Peter Coad and Edward Yourdon, Object-Oriented Design (Englewood Cliffs, NJ: Yourdon Press, 1991); Brian Henderson-Sellers and Julian Edwards, Book Two of Object-Oriented Knowledge: The Working Object (Sydney, Australia: Prentice Hall, 1994); James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, Object-Oriented Modeling and Design (Englewood Cliffs, NJ: Prentice Hall, 1991); Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Approach (Wokingham, England: Addison-Wesley, 1992); Ian Graham, Migrating to Object Technology (Wokingham, England: Addison-Wesley, 1994). 20 The material contained in this section is based on the Unified Modeling Language: Superstructure Version 2.0, ptc/03-08-02 (www.uml.org). Additional useful references include Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies (Indianapolis, IN: Wiley, 2003); Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado, UML 2 Toolkit (Indianapolis, IN: Wiley, 2004); and Kendall Scott, Fast Track UML 2.0 (Berkeley, CA: Apress, 2004). For a complete description of all diagrams, see www.uml.org. 30 Chapter 1 Introduction to Systems Analysis and Design Structure Diagrams Class Illustrate the relationships between classes modeled Analysis, Design in the system. Object Illustrate the relationships between objects modeled Analysis, Design in the system. Used when actual instances of the classes will better communicate the model. Package Group other UML elements together to form Analysis, Design, higher-level constructs. Implementation Deployment Show the physical architecture of the system. Can also Physical Design, be used to show software components being deployed Implementation onto the physical architecture. Component Illustrate the physical relationships among the software Physical Design, components. Implementation Composite Structure Illustrate the internal structure of a class, i.e., the Analysis, Design relationships among the parts of a class. Behavioral Diagrams Activity Illustrate business workflows independent of classes, the Analysis, Design flow of activities in a use case, or detailed design of a method. Sequence Model the behavior of objects within a use case. Analysis, Design Focuses on the time-based ordering of an activity. Communication Model the behavior of objects within a use case. Analysis, Design Focuses on the communication among a set of collaborating objects of an activity. Interaction Overview Illustrate an overview of the flow of control of a process. Analysis, Design Timing Illustrate the interaction that takes place among Analysis, Design a set of objects and the state changes in which they go through along a time axis. Behavioral State Machine Examine the behavior of one class. Analysis, Design Protocol State Machine Illustrates the dependencies among the different Analysis, Design interfaces of a class. Use-Case Capture business requirements for the system and to Analysis illustrate the interaction between the system and its environment. FIGURE 1-13 UML 2.0 Diagram Summary PROJECT TEAM 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. Leading a successful organizational change effort is one of the most difficult jobs that someone can do. Understanding what to change and how to change it—and convincing others of the need for change—requires a wide range of skills. These skills can be broken down into six major categories: technical, business, analytical, interpersonal, management, and ethical. Diagram Name Used to… Primary Phase Analysts must have the technical skills to understand the organization’s existing technical environment, the technology that will comprise the new system, and the way in which both can be fit into an integrated technical solution. Business skills are required to understand how IT can be 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 often need to communicate effectively one-on-one with users and busi- ness managers (who often have little experience with technology) and with program- mers (who often have more technical expertise than the analyst). They 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. Finally, analysts must deal fairly, honestly, and ethically with other project team mem- bers, managers, and system users. Analysts often deal with confidential information or information that, if shared with others, could cause harm (e.g., dissent among employees); it is important to maintain confidence and trust with all people. In addition to these six general skill sets, analysts require many specific skills associated with roles performed on a project. In the early days of systems development, most organi- zations expected one person, the analyst, to have all the specific skills needed to conduct a systems development project. Some small organizations still expect one person to perform many roles, but because organizations and technology have become more complex, most large organizations now build project teams containing several individuals with clearly defined responsibilities. Different organizations divide the roles differently, but Figure 1-14 presents one commonly used set of project team roles. Most IS teams include many other individuals, such as the programmers, who actually write the programs that make up the system, and technical writers, who prepare the help screens and other documentation (e.g., users manuals and systems manuals). Project Team Roles and Skills 31 Business analyst Analyzing the key business aspects of the system Identifying how the system will provide business value Designing the new business processes and policies Systems analyst Identifying how technology can improve business processes Designing the new business processes Designing the information system Ensuring that the system conforms to information systems standards Infrastructure analyst Ensuring the system conforms to infrastructure standards Identifying infrastructure changes needed to support the system Change management analyst Developing and executing a change management plan Developing and executing a user training plan Project manager Managing the team of analysts, programmers, technical writers, and other specialists Developing and monitoring the project plan Assigning resources Serving as the primary point of contact for the project Role Responsibilities FIGURE 1-14 Project Team Roles Business Analyst A business analyst focuses on the business issues surrounding the system. These issues include identifying the business value that the system will create, developing ideas and suggestions for how the business processes can be improved, and designing the new processes and policies in conjunction with the systems analyst. This individual will likely have business experience and some type of professional training (e.g., the business analyst for accounting systems will likely be a CPA [in the United States] or a CA [in Canada]). He or she represents the interests of the project sponsor and the ultimate users of the system. A business analyst assists in the plan- ning and design phases but is most active in the analysis phase. Systems Analyst A systems analyst focuses on the IS issues surrounding the system. This person develops ideas and suggestions for how information technology can improve business processes, designs the new business processes with help from the business analyst, designs the new information system, and ensures that all IS standards are maintained. A systems analyst will likely have significant training and experience in analysis and design, programming, and even areas of the business. He or she represents the interests of the IS department and works intensively through the project but perhaps less so during the implementation phase. Infrastructure Analyst An infrastructure analyst focuses on the technical issues surrounding how the system will interact with the organization’s technical infrastructure (e.g., hardware, software, networks, and databases). An infrastructure analyst’s tasks include ensuring that the new information system conforms to organizational standards and identifying infrastructure changes needed to support the system. This individual will probably have significant training and experience in networking, database administration, and various hardware and software products. He or she represents the interests of the organization and IS group that will ultimately have to operate and support the new system once it has been installed. An infrastructure analyst works throughout the project but perhaps less so during planning and analysis phases. Change Management Analyst A change management analyst focuses on the people and management issues surrounding the system installation. The roles of this person include ensuring that the adequate documentation and support are available to users, providing user training on the new system, and developing strategies to overcome resistance to change. This individual should have significant training and experience in organizational behavior in general and change management in particular. He or she represents the interests of the project sponsor and users for whom the system is being designed. A change management analyst works most actively during the implementa- tion phase but begins laying the groundwork for change during the analysis and design phases. Project Manager A project manager is responsible for ensuring that the project is completed on time and within budget and that the system delivers all benefits intended by the project sponsor. The role of the project manager includes managing the team members, developing the project plan, assigning resources, and being the primary point of contact when people outside the team have questions about the project. This individual will likely have significant experi- ence in project management and has probably worked for many years as a systems analyst beforehand. He or she represents the interests of the IS department and the project sponsor. The project manager works intensely during all phases of the project. 32 Chapter 1 Introduction to Systems Analysis and Design APPLYING THE CONCEPTS AT CD SELECTIONS Throughout this book, many new concepts about object-oriented systems analysis and design are introduced. As a way to make these new concepts more relevant, we apply them to a fictitious company called CD Selections. CD Selections is a chain of fifty music stores located in California, with headquarters in Los Angeles. Annual sales last year were $50 million, and they have been growing at about 3 to 5 percent per year for the past few years. However, the firm has been interested in expanding their presence beyond California. Margaret Mooney, vice president of marketing, has recently become both excited by and concerned with the rise of Internet sites selling CDs. She believes that the Internet has great potential, but she wants to use it in the right way. Rushing into e-commerce without considering things such as its effect on existing brick-and-mortar stores and the implications on existing systems at CD Selections could cause more harm than good. Currently, CD Selections has a Web site that provides basic information about the company and about each of its stores (e.g., map, operating hours, phone number, etc.). The Web site was developed by an Internet consulting firm and is hosted by a prominent local Internet service provider (ISP) in Los Angeles. The IT department at CD Selections has become experienced with Internet technology as it has worked with the ISP to maintain the site; however, it still has a lot to learn when it comes to conducting business over the Web. As such, Margaret is interested in investigating the possibility of creating an e-commerce site that will work with the current systems used by CD Selec- tions. In future chapters, we revisit CD Selections to see how the concepts introduced in the individual chapters impact Margaret and CD Selections. SUMMARY The Systems Development Life Cycle All systems development projects follow essentially the same fundamental process, called the system development life cycle (SDLC). SDLC starts with a planning phase in which the project team identifies the business value of the system, conducts a feasibility analysis, and plans the project. The second phase is the analysis phase, in which the team develops an analysis strategy, gathers information, and builds a set of analysis models. In the next phase, the design phase, the team develops the physical design, architecture design, interface design, database and file specifications, and program design. In the final phase, implemen- tation, the system is built, installed, and maintained. Summary 33 Suppose you decide to become an analyst after you grad- uate. Decide what type of analyst you would most prefer to be and what type of courses you should take before you graduate. Then decide the type of summer job or internship you should seek. Question Develop a short plan that describes how you will prepare for your career as an analyst. 1-3 Being an AnalystYOUR TURN The Evolution of Systems Development Methodologies System development methodologies are formalized approaches to implementing an SDLC. System development methodologies have evolved over the decades. Structured design methodologies, such as waterfall and parallel development, emphasize decomposition of a problem by either focusing on process decomposition (process-centric methodologies) or data decomposition (data decomposition). They produce a solid, well-thought-out system but can overlook requirements because users must specify them early in the design process before seeing the actual system. RAD-based methodologies attempt to speed up develop- ment and make it easier for users to specify requirements by having parts of the system developed sooner either by producing different versions (phased development) or by using prototypes (prototyping, throwaway prototyping) through the use of CASE tools and fourth-generation/visual programming languages. However, RAD-based methodologies still tend to be either process-centric or data-centric. Agile development methodologies, such as XP, focus on streamlining the SDLC by eliminating many of the tasks and time associated with requirements definition and documentation. Several factors influence the choice of a methodology: clarity of the user requirements; familiarity with the base tech- nology; system complexity; need for system reliability; time pressures; and the need to see progress on the time schedule. Object-Oriented Systems Analysis and Design Object-oriented systems analysis and design (OOSAD) is most associated with a phased- development RAD-based methodology, where the time spent in each phase is very short. OOSAD uses a use-case-driven, architecture-centric, iterative, and incremental informa- tion systems development approach. It supports three different views of the evolving system: functional, static, and dynamic. OOSAD allows the analyst to decompose complex problems into smaller, more manageable components using a commonly accepted set of notations. Also, many people believe that users do not think in terms of data or processes but instead think in terms of a collection of collaborating objects. As such, object-oriented systems analysis and design allows the analyst to interact with the user with objects from the user’s environment instead of a set of separate processes and data. One of the most popular approaches to object-oriented systems analysis and design is the Unified Process. The Unified Process is a two-dimensional systems development process described with a set of phases and workflows. The phases consist of the incep- tion, elaboration, construction, and transition phases. The workflows are organized into two subcategories: engineering and supporting. The engineering workflows include busi- ness modeling, requirements, analysis, design, implementation, test, and deployment workflows, and the supporting workflows comprise the project management, configura- tion and change management, and environment workflows. Depending on which devel- opment phase the evolving system is currently in, the level of activity will vary over the workflows. The Unified Modeling Language The Unified Modeling Language, or UML, is a standard set of diagramming techniques that provide a graphical representation rich enough to model any systems development project from analysis through implementation. Today most object-oriented systems analysis and design approaches use the UML to depict an evolving system. The UML uses a set of different diagrams to portray the various views of the evolving system. The diagrams are grouped into two broad classifications: structure and behavior. The struc- ture diagrams include class, object, package, deployment, component, and composite 34 Chapter 1 Introduction to Systems Analysis and Design structure diagrams. The behavior diagrams include activity, sequence, communication, interaction overview, timing, behavior state machine, protocol state machine, and use case diagrams. Project Team Roles and Skills The project team needs a variety of skills. All analysts need to have general skills, such as change management, ethics, communications, and technical. However, different kinds of analysts require specific skills in addition to these. Business analysts usually have business skills that help them to understand the business issues surrounding the system, whereas systems analysts also have significant experience in analysis and design and programming. The infrastructure analyst focuses on technical issues surrounding how the system will interact with the organization’s technical infrastructure, and the change management analyst focuses on people and management issues surrounding the system installation. In addition to analysts, project teams will include a project manager, programmers, technical writers, and other specialists. KEY TERMS Key Terms 35 Agile development Analysis model Analysis paralysis Analysis phase Analysis strategy Analysis workflow Approval committee Architecture centric Architecture design As-is system Behavior diagrams Behavioral view Business analyst Business modeling workflow Change agent Change management analyst Configuration and change management workflow Construction Construction phase Database and file specification Data-centered methodology Deliverable Deployment workflow Design model Design phase Design prototype Design strategy Design workflow Dynamic view Elaboration phase Engineering workflow Environment workflow External view Extreme programming (XP) Feasibility analysis Functional view Gradual refinement Implementation phase Implementation workflow Inception phase Incremental Infrastructure analyst Infrastructure management workflow Interface design Iterative Methodology Object management group (OMG) Object-oriented methodologies Operations and support workflow Parallel development Phased development Phases Planning phase Process-centered methodology Production phase Program design Programmer Project management Project management workflow Project manager Project plan Project sponsor Prototyping Rapid application development (RAD) Requirements gathering Requirements workflow Static view Structural view Structure diagrams Structured design Support plan Systems development life cycle (SDLC) System proposal System prototype System request System specification Systems analyst Technical writer Testing workflow Throwaway prototyping Training plan Transition phase Unified Modeling Language (UML) Use case Use-case driven Version Waterfall development Workflows Workplan QUESTIONS 36 Chapter 1 Introduction to Systems Analysis and Design 1. Compare and contrast phases, steps, techniques, and deliverables. 2. Describe the major phases in the SDLC. 3. Describe the principal steps in the planning phase. What are the major deliverables? 4. Describe the principal steps in the analysis phase. What are the major deliverables? 5. Describe the principal steps in the design phase. What are the major deliverables? 6. Describe the principal steps in the implementation phase. What are the major deliverables? 7. What are the roles of a project sponsor and the approval committee? 8. What does gradual refinement mean in the context of SDLC? 9. Compare and contrast process-centered methodolo- gies with data-centered methodologies. 10. Compare and contrast structured design-based methodologies in general to RAD-based methodolo- gies in general. 11. Compare and contrast extreme programming and throwaway prototyping. 12. Describe the major elements and issues with waterfall development. 13. Describe the major elements and issues with parallel development. 14. Describe the major elements and issues with phased development. 15. Describe the major elements and issues with prototyping. 16. Describe the major elements and issues with throw- away prototyping. 17. What are the key factors in selecting a methodology? 18. What is a use case? 19. What is meant by use-case driven? 20. What is the Unified Modeling Language? 21. Who is the Object Management Group? 22. What is the primary purpose of structure diagrams? Give some examples of structure diagrams. 23. For what are behavior diagrams used? Give some examples of behavior diagrams. 24. Why is it important for an OOSAD approach to be architecture centric? 25. What does it mean for an OOSAD approach to be incremental and iterative? 26. What are the phases and workflows of the Unified Process? 27. Compare the phases of the Unified Process with the phases of the waterfall model. 28. What are the major roles on a project team? 29. Compare and contrast the role of a systems analyst, business analyst, and infrastructure analyst. 30. Which phase in the SDLC is most important? Why? 31. Describe the major elements and issues with an object-oriented approach to developing information systems. EXERCISES A. Suppose you are a project manager using a waterfall development–based methodology on a large and complex project. Your manager has just read the latest article in Computerworld that advocates replacing this methodology with prototyping and comes to your office requesting that you switch. What would you say? B. The basic types of methodologies discussed in this chapter can be combined and integrated to form new hybrid methodologies. Suppose you were to combine throwaway prototyping with the use of waterfall development. What would the methodology look like? Draw a picture (similar to those in Figures 1–2 through 1–7). How would this new methodology compare to the others? C. Investigate IBM’s Rational Unified Process (RUP) on the Web. RUP is a commercial version that extends aspects of the Unified Process. Write a brief memo describing how it is related to the Unified Process as described in this chapter. (Hint: A good Web site with which to begin is www.306.ibm.com/software/ awdtools/rup/.) D. Suppose you are a project manager who typically has been using a waterfall development–based methodology on a large and complex project. Your manager has just read the latest article in Computer- world that advocates replacing this methodology with the Unified Process and comes to your office request- ing you to switch. What do you say? E. Suppose you are an analyst working for a small com- pany to develop an accounting system. Would you use the Unified Process to develop the system, or would you prefer one of the traditional approaches? Why? F. Suppose you are an analyst developing a new infor- mation system to automate the sales transactions and manage inventory for each retail store in a large chain. The system would be installed at each store and exchange data with a mainframe computer at the company’s head office. Would you use the Unified Process to develop the system or would you prefer one of the traditional approaches? Why? G. Suppose you are an analyst working for a small com- pany to develop an accounting system. What type of methodology would you use? Why? H. Suppose you are an analyst developing a new executive information system intended to provide key strategic information from existing corporate databases to senior executives to help in their decision making. What type of methodology would you use? Why? I. Investigate the Unified Modeling Language on the Web. Write a paragraph news brief describing the cur- rent state of the UML. (Hint: A good Web site with which to begin is www.uml.org.) J. Investigate the Object Management Group (OMG) on the Web. Write a report describing the purpose of the OMG and what it is involved with besides the UML. (Hint: A good Web site with which to begin is www.omg.org.) K. Using the Web, find a set of CASE tools that support the UML. A couple of examples include Rational Rose and Visual Paradigm. Find at least two more. Write a short report describing how well they support the UML, and make a recommendation as to which one you believe would be best for a project team to use in developing an object-oriented information system using the UML. L. Look in the classified section of your local newspaper. What kinds of job opportunities are available for people who want analyst positions? Compare and contrast the skills that the ads ask for to the skills that we presented in this chapter. M. Think about your ideal analyst position. Write a news- paper ad to hire someone for that position. What requirements would the job have? What skills and experience would be required? How would an appli- cant be able to demonstrate having the appropriate skills and experience? Minicases 37 MINICASES 1. Barbara Singleton, manager of western regional sales at the WAMAP Company, requested that the IS department develop a sales force management and tracking system that would enable her to better mon- itor the performance of her sales staff. Unfortunately, due to the massive backlog of work facing the IS department, her request was given a low priority. After six months of inaction by the IS department, Barbara decided to take matters into her own hands. Based on the advice of friends, Barbara purchased a PC and simple database software and constructed a sales force management and tracking system on her own. Although Barbara’s system has been “com- pleted” for about six weeks, it still has many features that do not work correctly, and some functions are full of errors. Barbara’s assistant is so mistrustful of the system that she has secretly gone back to using her old paper-based system, since it is much more reliable. Over dinner one evening, Barbara complained to a systems analyst friend, “I don’t know what went wrong with this project. It seemed pretty simple to me. Those IS guys wanted me to follow this elaborate set of steps and tasks, but I didn’t think all that really applied to a PC-based system. I just thought I could build this system and tweak it around until I got what I wanted without all the fuss and bother of the methodology the IS guys were pushing. I mean, doesn’t that just apply to their big, expensive systems?” Assuming you are Barbara’s systems analyst friend, how would you respond to her complaint? 2. Marcus Weber, IS project manager at ICAN Mutual Insurance Co., is reviewing the staffing arrangements for his next major project, the development of an expert system-based underwriters assistant. This new system will involve a whole new way for the under- writers to perform their tasks. The underwriters assis- tant system will function as sort of an underwriting supervisor, reviewing key elements of each applica- tion, checking for consistency in the underwriter’s decisions, and ensuring that no critical factors have been overlooked. The goal of the new system is to improve the quality of the underwriters’ decisions and to improve underwriter productivity. It is expected that the new system will substantially change the way the underwriting staff do their jobs. Marcus is dismayed to learn that due to budget constraints, he must choose between one of two avail- able staff members. Barry Filmore has had considerable experience and training in individual and organiza- tional behavior. Barry has worked on several other pro- jects in which the end users had to make significant adjustments to the new system, and Barry seems to have a knack for anticipating problems and smoothing the transition to a new work environment. Marcus had hoped to have Barry’s involvement in this project. Marcus’s other potential staff member is Kim Danville. Prior to joining ICAN Mutual, Kim had con- siderable work experience with the expert system tech- nologies that ICAN has chosen for this expert system project. Marcus was counting on Kim to help integrate the new expert system technology into ICAN’s systems environment, and also to provide on-the-job training and insights to the other developers on this team. Given that Marcus’s budget will only permit him to add Barry or Kim to this project team, but not both what choice do you recommend for him? Justify your answer. 3. Joe Brown, the president of Roanoke Manufacturing, requested that Jack Jones, the MIS department man- ager, investigate the viability of selling their products over the Web. Currently, the MIS department is still using an IBM mainframe as their primary deployment environment. As a first step, Jack contacted his friends at IBM to see if they had any suggestions as to how Roanoke Manufacturing could move toward support- ing sales in an electronic commerce environment while keeping their mainframe as their main system. His friends explained that IBM (www.ibm.com) now sup- ports Java and Linux on their mainframes. Further- more, Jack learned that IBM owns Rational (www.rational.com), the creator of the UML and the Unified Process. As such, they suggested that Jack inves- tigate using object-oriented systems as a basis for devel- oping the new system. They also suggested that using the Rational Unified Process (RUP), Java, and virtual Linux machines on his current mainframe as a way to support the movement toward a distributed electronic commerce system would protect his current investment in his legacy systems while allowing the new system to be developed in a more modern manner. Even though Jack’s IBM friends were very persua- sive, Jack is still a little wary about moving his opera- tion from a structured systems approach to this new object-oriented approach. Assuming that you are one of Jack’s IBM friends, how would you convince him to move toward using an object-oriented systems devel- opment method, such as RUP,and using Java and Linux as a basis for developing and deploying the new system on Roanoke Manufacturing’s current mainframe. 38 Chapter 1 Introduction to Systems Analysis and Design Project Charter Risk Assessment Staffing Plan Workplan System Proposal Requirements Definition Feasibility Analysis System Request PART ONE Project Initiation, Project Management, and Requirements Determination The Planning Phase is the fundamental process of understanding why an information system should be built, and determining how the project team will build it. The deliverables are combined into a system request which is presented to the project sponsor and approval committee. They decide whether it is advisable to proceed with the system. If the request is approved, detailed workplans, staffing plans, risk assessments, and a project charter is created. Finally, the detailed requirements are identified and a system proposal is created. The activities described in this section are continuously revisited throughout the life- time of the system. CHAPTER 2 Project Initiation CHAPTER 3 Project Management CHAPTER 4 Requirements Determination This page intentionally left blank 41 This chapter describes Project Initiation, the point at which an organization creates and assesses the original goals and expectations for a new system. The first step in the process is to identify a project that will deliver value to the business and to create a system request that provides basic information about the proposed system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system; if appropriate, the system is selected and the development project begins. OBJECTIVES ■ Understand the importance of linking the information system to business needs. ■ Be able to create a system request. ■ Understand how to assess technical, economic, and organizational feasibility. ■ Be able to perform a feasibility analysis. ■ Understand how projects are selected in some organizations. CHAPTER OUTLINE CHAPTER 2 Project Initiation Introduction Project Identification System Request Feasibility Analysis Technical Feasibility Economic Feasibility Organizational Feasibility Project Selection Applying the Concepts at CD Selections Project Identification and System Request Feasibility Analysis Project Selection Summary INTRODUCTION The first step in any new development project is for someone—a manager, staff member, sales representative, or systems analyst—to see an opportunity to improve the business. New systems start first and foremost from a business need or opportunity. Many ideas for new systems or improvements to existing ones arise from the application of a new tech- nology, but an understanding of technology is usually secondary to a solid understanding of the business and its objectives. This idea may sound like common sense, but, unfortunately, many projects are started without a clear understanding of how the system will improve the business. The IS field is filled with thousands of buzzwords, fads, and trends (e.g., customer relationship manage- ment (CRM), mobile computing, data mining). The promise of these innovations can appear so attractive that organizations begin projects even if they are not sure what value they offer because they believe that the technologies are somehow important in their own right. A 1996 survey by the Standish Group found that 42 percent of all corporate IS projects were abandoned before completion; a similar 1996 study by the General Accounting Office found 53 percent of all U.S. government IS projects were abandoned. Problems can usually be traced back to the very beginning of the SDLC, where too little attention was given to the identify- ing business value and understanding the risks associated with the project. This does not mean that technical people should not recommend new systems projects. In fact, the ideal situation is for both IT people (i.e., the experts in systems) and the business people (i.e., the experts in business) to work closely to find ways for technology to support business needs. In this way, organizations can leverage the exciting technologies that are avail- able while ensuring that projects are based upon real business objectives, such as increasing sales, improving customer service, and decreasing operating expenses. Ultimately, informa- tion systems need to affect the organization’s bottom line (in a positive way!). In general, a project is a set of activities with a starting point and an ending point meant to create a system that brings value to the business. Project initiation begins when someone (or some group) in the organization (called the project sponsor) identifies some business value that can be gained from using information technology. The proposed pro- ject is described briefly using a technique called the system request, which is submitted to an approval committee for consideration. The approval committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposal or not. If so, the next step is the feasibility analysis. A feasibility analysis plays an important role in deciding whether to proceed with an information systems development project. It examines the technical, economic, and orga- nizational pros and cons of developing the system, and it gives the organization a slightly more detailed picture of the advantages of investing in the system as well as any obstacles that could arise. In most cases, the project sponsor works together with an analyst (or ana- lyst team) to develop the feasibility analysis for the approval committee. Once the feasibility analysis has been completed, it is submitted to the approval com- mittee, along with a revised system request. The committee then decides whether to approve the project, decline the project, or table it until additional information is available. Projects are selected by weighing risks and return and by making trade-offs at the organizational level. 42 Chapter 2 Project Initiation A CIO needs to have a global view when identifying and selecting projects for her organization. I would get lost in the trees if I were to manage on a project-by-project basis. Given this, I categorize my projects according to my three roles as a CIO, and the mix of my project portfolio changes depending on the current business environment. My primary role is to keep the business running. That means every day when each person comes to work, he or she can perform his or her job efficiently. I measure this using various service level, cost, and productivity mea- sures. Projects that keep the business running could have a high priority if the business were in the middle of a merger or a low priority if things were running smoothly and it were “business as usual.” My second role is to push innovation that creates value for the business. I manage this by looking at our lines of business and asking which lines of business create the most value for the company. These are the areas for which I should be providing the most value. For example, if we had a highly innovative marketing strategy, I would push for innovation there. If operations were running smoothly, I would push less for innovation in that area. My third role is strategic, to look beyond today and find new opportunities for both IT and the business of providing energy. This may include investigating process systems, such as automated meter reading or looking into the possibilities of wireless technologies. —Lyn McDermid 2-A Interview with Lyn McDermid, CIO, Dominion Virginia PowerCONCEPTS IN ACTION PROJECT IDENTIFICATION A project is identified when someone in the organization identifies a business need to build a system. This could occur within a business unit or IT, come from a steering com- mittee charged with identifying business opportunities, or evolve from a recommenda- tion made by external consultants. Examples of business needs include supporting a new marketing campaign, reaching out to a new type of customer, or improving interactions with suppliers. Sometimes, needs arise from some kind of “pain” within the organization, such as a drop in market share, poor customer service levels, or increased competition. Other times, new business initiatives and strategies are created, and a system is required to enable them. Business needs also can surface when the organization identifies unique and compet- itive ways of using IT. Many organizations keep an eye on emerging technology, which is technology that is still being developed and is not yet viable for widespread business use. For example, if companies stay abreast of technology such as the Internet, smart cards, and scent-technology in their earliest stages, they can develop business strategies that leverage the capabilities of these technologies and introduce them into the marketplace as a first mover. Ideally, they can take advantage of this first-mover advantage by making money and continuing to innovate while competitors trail behind. The project sponsor is someone who recognizes the strong business need for a sys- tem and has an interest in seeing the system succeed. He or she will work throughout the SDLC to make sure that the project is moving in the right direction from the perspective of the business. The project sponsor serves as the primary point of contact for the sys- tem. Usually, the sponsor of the project is from a business function, such as marketing, accounting, or finance; however, members of the IT area also can sponsor or cosponsor a project. The size or scope of a project determines the kind of sponsor needed. A small, departmental system may require sponsorship from only a single manager; however, a large, organizational initiative may need support from the entire senior management team and even the CEO. If a project is purely technical in nature (e.g., improvements to the existing IT infrastructure or research into the viability of an emerging technology), then sponsorship from IT is appropriate. When projects have great importance to the business yet are technically complex, joint sponsorship by both the business and IT may be necessary. The business need drives the high-level business requirements for the system. Require- ments are what the information system will do, or the functionality it will contain. They need to be explained at a high level so that the approval committee and, ultimately, the pro- ject team understand what the business expects from the final product. Business require- ments are the features and capabilities the information system will have to include, such as the ability to collect customer orders online or the ability for suppliers to receive inventory information as orders are placed and sales are made. The project sponsor also should have an idea of the business value to be gained from the system, both in tangible and intangible ways. Tangible value can be quantified and measured easily (e.g., 2 percent reduction in operating costs). An intangible value results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization (e.g., improved customer service or a better competitive position). Once the project sponsor identifies a project that meets an important business need and he or she can identify the system’s business requirements and value, it is time to for- mally initiate the project. In most organizations, project initiation begins with a tech- nique called a system request. Project Identification 43 System Request A system request is a document that describes the business reasons for building a sys- tem and the value that the system is expected to provide. The project sponsor usually completes this form as part of a formal system project selection process within the orga- nization. Most system requests include five elements: project sponsor, business need, business requirements, business value, and special issues (see Figure 2-1). The sponsor describes the person who will serve as the primary contact for the project, and the busi- ness need presents the reasons prompting the project. The business requirements of the project refer to the business capabilities that the system will need to have, and the busi- ness value describes the benefits that the organization should expect from the system. Special issues are included on the document as a catch-all for other information that should be considered in assessing the project. For example, the project may need to be completed by a specific deadline. Project teams need to be aware of any special circum- stances that could affect the outcome of the system. Figure 2-2 shows a template for a system request. The completed system request is submitted to the approval committee for consideration. This approval committee could be a company steering committee that meets regularly to make information systems decisions, a senior executive who has control of organizational resources, or any other decision-making body that governs the use of business investments. The committee reviews the system request and makes an initial determination, based on the information provided, of whether to investigate the proposal or not. If so, the next step is to conduct a feasibility analysis. Feasibility Analysis Once the need for the system and its business requirements have been defined, it is time to create a more detailed business case to better understand the opportunities and limitations 44 Chapter 2 Project Initiation Dominion Virginia Power is one of the nation’s ten largest investor-owned electric utilities. The company delivers power to more than two million homes and businesses in Virginia and North Carolina. In 1997, the company over- hauled some of its core processes and technology. The goal was to improve customer service and cut operations costs by developing a new workflow and geographic information system. When the project was finished, ser- vice engineers who had sifted through thousands of paper maps could use computerized searches to pinpoint the locations of electricity poles. The project helped the utility improve management of all its facilities, records, maps, scheduling, and human resources. That, in turn, helped increase employee productivity, improve customer response times, and reduce the costs of operating crews. Source: Computerworld (November 11, 1997). Questions 1. What kinds of things does Dominion Virginia Power do that require it to know power pole locations? How often does it do these things? Who benefits if the company can locate power poles faster? 2. Based on your answers to question 1, describe three tangible benefits that the company can receive from its new computer system. How can these be quantified? 3. Based on your answers to question 1, describe three intangible benefits that the company can receive from its new computer system. How can these be quantified? 2-1 Identify Tangible and Intangible ValueYOUR TURN Project Identification 45 FIGURE 2-1 Elements of the System Request Form Project Sponsor The person who initiates the Several members of the Finance project and who serves as the department primary point of contact for the Vice President of Marketing project on the business side. IT Manager Steering committee CIO CEO Business Need The business-related reason for Increase sales initiating the system. Improve market share Improve access to information Improve customer service Decrease product defects Streamline supply acquisition Processes Business Requirements The business capabilities that the Provide onIine access to information system will provide. Capture customer demographic information Include product search capabilities Produce management reports Include online user support Business Value The benefits that the system will 3 percent increase in sales create for the organization. 1 percent increase in market share Reduction in headcount by 5 FTEs* $200,000 cost savings from decreased supply costs $150,000 savings from removal of existing system Special Issues or Issues that are relevant to the Government-mandated deadline for Constraints implementation of the system May 30 and decisions made by the System needed in time for the committee about the project. Christmas holiday season Top-level security clearance needed by project team to work with data * = Full-time equivalent Element Description Examples Project Sponsor: Name of project sponsor Business Need: Short description of business need Business Requirements: Description of business requirements Business Value: Expected value that the system will provide Special Issues or Constraints: Any additional information that may be relevant to the stakeholders System Request—Name of Project FIGURE 2-2 System Request Template associated with the proposed project. Feasibility analysis guides the organization in determining whether or not to proceed with a project. Feasibility analysis also identi- fies the important risks associated with the project that must be addressed if the pro- ject is approved. As with the system request, each organization has its own process and format for the feasibility analysis, but most include three techniques: technical feasibility, 46 Chapter 2 Project Initiation At Sprint, network projects originate from two vantage points—IT and the business units. IT projects usually address infrastructure and support needs. The business unit projects typically begin after a business need is identified locally, and a business group informally collaborates with IT regard- ing how a solution can be delivered to meet customer expectations. Once an idea is developed, a more formal request process begins, and an analysis team is assigned to inves- tigate and validate the opportunity. This team includes members from the user community and IT, and they scope out at a high level what the project will do; create estimates for technology, training, and development costs; and create a business case. This business case con- tains the economic value-add and the net present value of the project. Of course, not all projects undergo this rigorous process. The larger the project, the more time is allocated to the analysis team. It is important to remain flexible and not let the process consume the organization. At the begin- ning of each budgetary year, specific capital expenditures are allocated for operational improvements and mainte- nance. Moreover, this money is set aside to fund quick pro- jects that deliver immediate value without going through the traditional approval process. —Don Hallacy 2-B Interview with Don Hallacy, President, Technology Services, Sprint CorporationCONCEPTS IN ACTION Think about your own university or college, and choose an idea that could improve student satisfaction with the course enrollment process. Currently can students enroll for classes from anywhere? How long does it take? Are directions simple to follow? Is online help available? Next, think about how technology can help support your idea. Would you need completely new technology? Can the current system be changed? Question Create a system request that you could give to the administration that explains the sponsor, business need, business requirements, and potential value of the pro- ject. Include any constraints or issues that should be considered. 2–2 Create a System RequestYOUR TURN economic feasibility, and organizational feasibility. The results of these techniques are combined into a feasibility study deliverable, which is given to the approval committee at the end of project initiation (see Figure 2-3). Although we now discuss feasibility analysis within the context of project initiation, most project teams will revise their feasibility study throughout the SDLC and revisit its contents at various checkpoints during the project. If at any point the project’s risks and limitations outweigh its benefits, the project team may decide to cancel the project or make necessary improvements. Technical Feasibility The first technique in the feasibility analysis is to assess the technical feasibility of the pro- ject, the extent to which the system can be successfully designed, developed, and installed by the IT group. Technical feasibility analysis is in essence a technical risk analysis that strives to answer this question: Can we build it?1 1 We use build it in the broadest sense. Organizations can also choose to buy a commercial software package and install it, in which case, the question might be, can we select the right package and successfully install it? Many risks can endanger the successful completion of a project. First and foremost is the users’ and analysts’ lack of familiarity with the functional area. When analysts are unfamiliar with the business functional area, they have a greater chance of misunder- standing the users or of missing opportunities for improvement. The risk increases dramatically when the users themselves are less familiar with an application, such as with the development of a system to support a business innovation (e.g., Microsoft starting up a new Internet dating service). In general, the development of new systems is riskier than extensions to an existing system because existing systems tend to be better understood. Familiarity with the technology is another important source of technical risk. When a system uses technology that has not been used before within the organization, there is a greater chance that problems will occur and delays will be incurred because of the need to learn how to use the technology. Risk increases dramatically when the technology itself is new (e.g., a new Java development toolkit). Project size is an important consideration, whether measured as the number of people on the development team, the length of time it will take to complete the project, or the num- ber of distinct features in the system. Larger projects present more risk, both because they are more complicated to manage and because there is a greater chance that important sys- tem requirements will be overlooked or misunderstood. The extent to which the project is highly integrated with other systems (which is typical of large systems) can cause problems because complexity increases when many systems must work together. Finally, project teams need to consider the compatibility of the new system with the technology that already exists in the organization. Systems are rarely built in a vacuum— they are built in organizations that already have numerous systems in place. New technol- ogy and applications need to be able be integrated with the existing environment for many reasons. They may rely on data from existing systems, they may produce data that feed other applications, and they may have to use the company’s existing communications infra- structure. A new CRM system, for example, has little value if it does not use customer data found across the organization in existing sales systems, marketing applications, and cus- tomer service systems. Project Identification 47 Technical Feasibility: Can We Build It? • Familiarity with Functional area: Less familiarity generates more risk • Familiarity with Technology: Less familiarity generates more risk • Project Size: Large projects have more risk • Compatibility: The harder it is to integrate the system with the company’s existing technology, the higher the risk Economic Feasibility: Should We Build It? • Development costs • Annual operating costs • Annual benefits (cost savings and revenues) • Intangible costs and benefits Organizational Feasibility: If We Build It, Will They Come? • Project champion(s) • Senior management • Users • Other stakeholders • Is the project strategically aligned with the business? FIGURE 2-3 Feasibility Analysis Assessment Factors The assessment of a project’s technical feasibility is not cut and dried because in many cases, some interpretation of the underlying conditions is needed (e.g., how large a pro- ject needs to grow before it becomes less feasible). One approach is to compare the pro- ject under consideration with prior projects undertaken by the organization. Another option is to consult with experienced IT professionals in the organization or external IT consultants; often they will be able to judge whether a project is feasible from a technical perspective. 48 Chapter 2 Project Initiation Health care is a big industry in the United States. And with the baby boomers born in the late 1940s and 1950s (after World War II) starting to retire, there will be huge demands for senior health care. The desire is for better technologies to allow grandpa and grandma to live inde- pendently in their own homes or apartments longer— and not to use the more expensive options of nursing homes and assisted living centers. Some technologies include vital sign monitoring and reporting; motion detectors that sense if somebody has fallen; sensors to turn off the stove that may have been left on; and inter- net portals so that family members can check on the health of their loved ones. Questions 1. How can technology assist with keeping retirees healthy? 2. How can technology help keep retirees out of expensive nursing homes and centers? 2-C Caring for Grandpa and GrandmaCONCEPTS IN ACTION Economic Feasibility The second element of a feasibility analysis is to perform an economic feasibility analysis (also called a cost–benefit analysis), which identifies the financial risk associated with the project. It attempts to answer this question: Should we build the system? Economic feasi- bility is determined by identifying costs and benefits associated with the system, assigning values to them, and then calculating the cash flow and return on investment for the pro- ject. The more expensive the project, the more rigorous and detailed the analysis should be. Figure 2-4 lists the steps in performing a cost benefit analysis; each step is described in the following sections. Identifying Costs and Benefits The first task when developing an economic feasibility analysis is to identify the kinds of costs and benefits the system will have and list them along the left-hand column of a spreadsheet. Figure 2-5 lists examples of costs and bene- fits that may be included. Costs and benefits can be broken down into four categories: (1) development costs, (2) operational costs, (3) tangible benefits, and (4) intangibles. Development costs are those tangible expenses incurred during the construction of the system, such as salaries for the project team, hardware and software expenses, consultant fees, training, and office space and equipment. Development costs are usually thought of as one-time costs. Operational costs are those tangible costs required to operate the system, such the salaries for operations staff, software licensing fees, equipment upgrades, and communications charges. Opera- tional costs are usually thought of as ongoing costs. Project Identification 49 1. Identifing Costs and Benefits List the tangible costs and benefits for the pro- ject. Include both one-time and recurring costs. 2. Assigning Values to Costs and Benefits Work with business users and IT professionals to create numbers for each of the costs and bene- fits. Even intangibles should be valued if at all possible. 3. Determining Cash Flow Project what the costs and benefits will be over a period of time, usually three to five years. Apply a growth rate to the numbers, if necessary. 4. Determining Net Present Value Calculate what the value of future costs and benefits are if measured by today’s standards. You will need to select a rate of growth to apply the NPV formula. 5. Determining Return on Investment Calculate how much money the organization will receive in return for the investment it will make using the ROI formula. 6. Determining the Break-Even Point Find the first year in which the system has greater benefits than costs. Apply the break- even formula using figures from that year. This will help you understand how long it will take before the system creates real value for the organization. 7. Graphing the Break-Even Point Plot the yearly costs and benefits on a line graph. The point at which the lines cross is the break-even point. FIGURE 2-4 Steps for Conducting Economic Feasibility FIGURE 2-5 Example Costs and Benefits for Economic Feasibility Development Team Salaries Software Upgrades Consultant Fees Software Licensing Fees Development Training Hardware Repairs Hardware and Software Hardware Upgrades Vendor Installation Operational Team Salaries Office Space and Equipment Communications Charges Data Conversion Costs User Training Increased Sales Increased Market Share Reductions in Staff Increased Brand Recognition Reductions in Inventory Higher Quality Products Reductions in IT Costs Improved Customer Service Better Supplier Prices Better Supplier Relations Development Costs Operational Costs Tangible Benefits Intangible Benefits Revenues and cost savings are the tangible benefits the system enables the organi- zation to collect or the tangible expenses the system enables the organization to avoid. Tangible benefits may include increased sales, reductions in staff, and reductions in inventory. Of course, a project also can affect the organization’s bottom line by reaping intangible benefits or incurring intangible costs. Intangible costs and benefits are more difficult to incorporate into the economic feasibility because they are based on intuition and belief rather than “hard numbers.” Nonetheless, they should be listed in the spreadsheet along with the tangible items. Assigning Values to Costs and Benefits Once the types of costs and benefits have been identified, analysts assign specific dollar values to them. This may seem impossible; how can someone quantify costs and benefits that haven’t happened yet? And how can those predictions be realistic? Although this task is very difficult, they have to do the best they can to come up with reasonable numbers for all the costs and benefits. Only then can the approval committee make an educated decision about whether or not to move ahead with the project. The best strategy for estimating costs and benefits is to rely on the people who have the clearest understanding of them. For example, costs and benefits related to the technology or the project itself can be provided by the company’s IT group or external consultants, and business users can develop the numbers associated with the business (e.g., sales projections, order levels). Analysts can also consider past projects, industry reports, and vendor infor- mation, although these approaches probably will be a bit less accurate. All the estimates will probably be revised as the project proceeds. Sometimes, it is acceptable for analysts to list intangible benefits, such as improved customer service, without assigning a dollar value; whereas other times they have to make estimates regarding the value of an intangible benefit. If at all possible, they should quantify intangible costs or benefits. Otherwise, it will not be apparent whether they have been realized. Consider a system that is supposed to improve customer ser- vice. This is intangible, but assume that the greater customer service will decrease the number of customer complaints by 10 percent each year over three years and that $200,000 is spent on phone charges and phone operators who handle complaint calls. Suddenly there are some very tangible numbers with which to set goals and measure the original intangible benefit. 50 Chapter 2 Project Initiation I conducted a case study at Carlson Hospitality, a global leader in hospitality services, encompassing more than 1,300 hotel, resort, restaurant, and cruise ship operations in seventy-nine countries. One of its brands, Radisson Hotels & Resorts, researched guest stay information and guest satisfaction surveys. The company was able to quantify how much of a guest’s lifetime value can be attributed to his or her perception of the stay experience. As a result, Radisson knows how much of the collective future value of the enterprise is at stake given the per- ceived quality of stay experience. Using this model, Radisson can confidently show that a 10 percent increase in customer satisfaction among the 10 percent of highest-quality customers will capture a one-point market share for the brand. Each point in market share for the Radisson brand is worth $20 million in additional revenue. —Barbara Wixom Question How can a project team use this information to help determine the economic feasibility of a system? 2-D Intangible Value at Carlson HospitalityCONCEPTS IN ACTION Figure 2-6 shows costs and benefits along with assigned dollar values. Notice that the customer service intangible benefit has been quantified based on fewer customer com- plaint phone calls. The intangible benefit of being able to offer services that competitors currently offer was not quantified, but it was listed so that the approval committee will con- sider the benefit when assessing the system’s economic feasibility. Determining Cash Flow A formal cost benefit analysis usually contains costs and ben- efits over a selected number of years (usually three to five years) to show cash flow over time (see Figure 2-7). When using this cash flow method, the years are listed across the top of the spreadsheet to represent the time period for analysis, and numeric values are entered in the appropriate cells within the spreadsheet’s body. Sometimes fixed amounts are entered into the columns. For example, Figure 2-7 lists the same amount for customer complaint calls and inventory costs for all five years. Usually amounts are augmented by some rate of growth to adjust for inflation or business improvements, as shown by the 6 percent increase that is added to the sales numbers in the sample spreadsheet. Finally, totals are added to determine what the overall benefits will be; the higher the overall total, the more feasible the solution is in terms of its economic feasibility. Determining Net Present Value and Return on Investment There are several problems with the cash flow method because it does not consider the time value of money (i.e., a dol- lar today is not worth a dollar tomorrow), and it does not show the overall “bang for the buck” that the organization is receiving from its investment. Therefore, some project teams add additional calculations to the spreadsheet to provide the approval committee with a more accurate picture of the project’s worth. Project Identification 51 Benefitsa Increased sales 500,000 Improved customer serviceb 70,000 Reduced inventory costs 68,000 Total benefits 638,000 Development costs 2 servers @ $125,000 250,000 Printer 100,000 Software licenses 34,825 Server software 10,945 Development labor 1,236,525 Total development costs 1,632,295 Operational costs Hardware 54,000 Software 20,000 Operational labor 111,788 Total operational costs 185,788 Total costs 1,818,083 a An important yet intangible benefit will be the ability to offer ser- vices that our competitors currently offer. b Customer service numbers have been based on reduced costs for customer complaint phone calls. FIGURE 2-6 Assigning Values to Costs and Benefits 52 Chapter 2 Project Initiation FIGURE 2-7 Cost–Benefit Analysis Increased sales 500,000 530,000 561,800 595,508 631,238 Reduction in customer complaint calls 70,000 70,000 70,000 70,000 70,000 Reduced inventory costs 68,000 68,000 68,000 68,000 68,000 TOTAL BENEFITS: 638,000 668,000 699,800 733,508 769,238 PV OF BENEFITS: 619,417 629,654 640,416 651,712 663,552 3,204,752 PV OF ALL BENEFITS: 619,417 1,249,072 1,889,488 2,541,200 3,204,752 2 Servers @ $125,000 250,000 0 0 0 0 Printer 100,000 0 0 0 0 Software licenses 34,825 0 0 0 0 Server software 10,945 0 0 0 0 Development labor 1,236,525 0 0 0 0 TOTAL DEVELOPMENT COSTS: 1,632,295 0 0 0 0 Hardware 54,000 81,261 81,261 81,261 81,261 Software 20,000 20,000 20,000 20,000 20,000 Operational labor 111,788 116,260 120,910 125,746 130,776 TOTAL OPERATIONAL COSTS: 185,788 217,521 222,171 227,007 232,037 TOTAL COSTS: 1,818,083 217,521 222,171 227,007 232,037 PV OF COSTS: 1,765,129 205,034 203,318 201,693 200,157 2,575,331 PV OF ALL COSTS: 1,765,129 1,970,163 2,173,481 2,375,174 2,575,331 TOTAL PROJECT BENEFITS Ϫ COSTS: (1,180,083) 450,479 477,629 506,501 537,201 YEARLY NPV: (1,145,712) 424,620 437,098 450,019 463,395 629,421 CUMULATIVE NPV: (1,145,712) (721,091) (283,993) 166,026 629,421 RETURN ON INVESTMENT: 24.44% (629,421/2,575,331) BREAK-EVEN POINT: 3.63 years [break-even occurs in year 4; (450,019 Ϫ 166,026)/450,019 ϭ 0.63] INTANGIBLE BENEFITS: This service is currently provided by competitors Improved customer satisfaction 2008 2009 2010 2011 2012 Total Net present value (NPV) is used to compare the present value of future cash flows with the investment outlay required to implement the project. Consider the table in Figure 2-8, which shows the future worth of a dollar investment today, given different numbers of years and different rates of change. If you have a friend who owes you a dollar today but instead gives you a dollar three years from now, you’ve been had! Given a 10 percent increase in value, you’ll be receiving the equivalent of 75 cents in today’s terms. NPV can be calculated in many different ways, some of which are extremely complex. Figure 2-9 shows a basic calculation that can be used to in your cash flow analysis to get more relevant values. In Figure 2-7, the present value of the costs and benefits are calcu- lated first (i.e., they are shown at a discounted rate). Then, net present value is calculated, and it shows the discounted rate of the combined costs and benefits. The return on investment (ROI) is a calculation listed somewhere on the spread- sheet that measures the amount of money an organization receives in return for the money it spends. A high ROI results when benefits far outweigh costs. ROI is deter- mined by finding the total benefits less the costs of the system and dividing that num- ber by the total costs of the system (see Figure 2-9). ROI can be determined per year or for the entire project over a period of time. One drawback of ROI is that it considers only the end points of the investment, not the cash flow in between, so it should not be used as the sole indicator of a project’s worth. The spreadsheet in Figure 2-7 show a ROI figure. Determining the Break–Even Point If the project team needs to perform a rigorous cost benefit analysis, it may need to include information about the length of time before the project will break even, or when the returns will match the amount invested in the project. The greater the time it takes to break even, the riskier the project. The break–even point is determined by looking at the cash flow over time and identifying the year in which the benefits are larger than the costs (see Figure 2-7). Then, the difference between the yearly and cumulative NPV for that year is divided by the yearly NPV to determine how far into the year the break-even point will occur. See Figure 2-9 for the break-even calculation. Project Identification 53 1 0.943 0.909 0.870 2 0.890 0.826 0.756 3 0.840 0.751 0.572 4 0.792 0.683 0.497 This table shows how much a dollar today is worth 1–4 years from now in today’s terms using different interest rates. Number of years 6% 10% 15% FIGURE 2-8 The Value of a Future Dollar Today Present Value (PV) The amount of an investment today Amount compared to that same amount in the future, taking into account inflation and time. (1 ϩ interest rate)n n ϭ number of years in future Net Present Value (NPV) The present value of benefit less the present PV Benefits Ϫ PV Costs value of costs. Return on Investment (ROI) The amount of revenues or cost savings results Total benefits Ϫ Total costs from a given investment. Total costs Break-Even Point The point in time at which the costs of the Yearly NPV* Ϫ Cumulative NPV project equal the value it has delivered. Yearly NPV* *Use the Yearly NPV amount from the first year in which the project has a positive cash flow. Add the above amount to the year in which the project has a positive cash flow. Calculation Definition Formula FIGURE 2-9 Financial Calculations Used For Cost–Benefit Analysis The break-even point also can be depicted graphically, as shown in Figure 2-10. The cumulative present value of the costs and benefits for each year are plotted on a line graph; the point at which the lines cross is the break-even point. Alternatives to Traditional Cost–Benefit Analysis Concerns have been raised as to the appropriateness of using traditional cost–benefit analysis with NPV and ROI to determine economic feasibility of an IT project. One of the major problems of using traditional cost– benefit analysis to determine the economic feasibility of an IT investment is that traditional cost–benefit analysis is based on the assumption that the investor must either invest now or not invest at all. However, in most IT investment decisions, the decision to invest is not a now-or-never decision. In most situations, an information system is already in place. As 54 Chapter 2 Project Initiation Break-even Point 123 54 0 500,000 1,000,000 1,500,000 2,000,000 Dollars 2,500,000 3,500,000 Years 3,000,000 Costs Benefits FIGURE 2-10 Break-even Graph The FBI’s failure to roll out an expanded computer system that would help agents investigate criminals and terrorists is the latest in a series of costly technology blunders by the government over more than a decade. Experts blame poor planning, rapid industry advances, and the massive scope of some complex projects, whose price tags can run into billions of dollars at U.S. agencies with tens of thousands of employees. “There are very few success sto- ries,” said Paul Brubaker, former deputy chief information officer at the Pentagon. “Failures are very common, and they’ve been common for a long time.” The FBI said ear- lier this month it might shelve its custom-built, $170 mil- lion “Virtual Case File” project because it is inadequate and outdated. The system was intended to help agents, analysts, and others around the world share information without using paper or time-consuming scanning of doc- uments. Officials said commercial software might accom- plish some of what the FBI needs. The bureau’s mess—the subject of an investigation by the Justice Department and an upcoming congressional hearing—was the latest black eye among ambitious technology upgrades by the gov- ernment since the 1990s. Questions Some systems like this are very complex. They must have security, and they must interface between the FBI, CIA, and other government agencies as well as state and local law enforcement groups. Such complexity can take years to build—and is almost guaranteed to fail because of newer technologies that have come along during the wait. How might you keep a complex project on track? What commercial software might work in this case (as mentioned in the case?) Source: www.securityfocus.com/news/10383 2-E The FBI Pulls the Plug on a ProjectCONCEPTS IN ACTION such, the decision to replace or upgrade the current information system can usually be delayed. Different proposals have been made to overcome some of the weaknesses in tradi- tional cost–benefit analysis. For example, economic production models, activity-based costing, and balanced score cards have been suggested.2 However, in this section, we describe the primary alternative that has been proposed for object-oriented systems: option pricing models (OPMs).3 At this point in time, OPMs have had limited use in economic feasibility analysis for IT investment decisions in industry. In fact, there is some controversy as to whether an instrument created for a traded asset (stock) can be used in evaluating IT investment opportunities. However, the preliminary research results demonstrate that their use in IT investment evaluations may be warranted. OPMs have shown promise in evaluating the potential future value of an investment in IT. In many cases in which traditional cost–benefit analysis of investments in IT has predicted that the investment would be a failure, OPMs have shown that it may indeed be feasible. With object-oriented systems, where classes are designed not only for the current application but also for use in future development efforts, an investment in developing a class or a set of classes may pay dividends well beyond the original system development effort. Furthermore, with the iterative and incremental development emphasis in object- oriented systems development approaches, an object-oriented project can be viewed as a sequence of smaller projects. As such, you might treat investments in an object-oriented project much as you would an investment in a call option in finance. A call option is essen- tially a contract that gives the right to purchase an amount of stock for a given price for a specified period of time to the purchaser of the call option. However, a call option does not create an obligation to buy the stock. Treating an IT investment as a call option allows management, at a relevant point in the future, to determine whether additional investment into the evolving system is reasonable. This gives management the flexibility to determine the economic feasibility of a project to decide whether to continue with the development as planned, to aban- don the project, to expand the scope of the project, to defer future development, or to shrink the current development effort. In many ways, treating IT investments as call options simply allows management to delay investment decisions until more informa- tion is available. Once the decision is made to invest (i.e., the call option is exercised) the decision is considered irreversible. The idea of irreversible decisions is one of the fundamental Project Identification 55 2 See, for example, Q. Hu, R. Plant, and D. Hertz, “Software Cost Estimation Using Economic Production Models,” Journal of MIS 15, no. 1 (Summer 1998): 143–163; G. Ooi and C. Soh, “Developing an Activity-based Approach for System Development and Implementation,” ACM Data Base for Advances in Information Systems 34, no. 3 (Summer 2003): 54–71, and K. Milis and R. Mercken, “The Use of the Balanced Scorecard for the Evaluation of Information and Communication Technology Projects,” International Journal of Project Management 22 (2004): 87–97. 3 For more information regarding the use of option pricing models in evaluating economic feasibility of infor- mation systems, see M. Benaroch and R. Kauffman, “A Case for Using Real Options Pricing Analysis to Evaluate Information Technology Project Investments,” Information Systems Research 10, no. 1 (March 1999): 70–86; M. Benaroch and R. Kauffman, “Justifying Electronic Banking Network Expansion Using Real Options Analysis,” MIS Quarterly 24, no. 2 (June 2000): 197–225; Q. Dai, R. Kauffman, and S. March, “Analyzing Investments in Object-Oriented Middleware,” Ninth Workshop on Information Technologies and Systems (December 1999): 45–50; A. Kambil, J. Henderson, and H. Mohsenzadeh, Strategic Management of Information Technology Invest- ments: An Options Perspective, in R. D. Banker, R. J. Kauffman, and M. A. Mahmood (eds.), Strategic Informa- tion Technology Management: Perspectives on Organizational Growth and Competitive Advantage (Idea Group, 1993); A. Taudes, “Software Growth Options,” Journal of Management Information Systems 15, no. 1 (Summer 1998): 165–185; A. Taudes, M. Feurstein, and A. Mild, “Options Analysis of Software Platform Decisions: A Case Study,” MIS Quarterly 24, no. 2 (June 2000): pp. 227–243. assumptions on which OPMs are based. This assumption fits quite well with modern object-oriented systems development approaches, in which, once an iteration has begun, an increment is completed before another investment decision is made. Researchers have studied many different OPMs in terms of their applicability to IT investment.4 However, all OPMs share a common thread: both the direct benefit of the pro- posed project and the indirect value (option value) must be computed to determine eco- nomic feasibility of an IT investment using an OPM. The direct benefit can be computed using the traditional NPV, whereas the value of the option can be computed using one of the OPMs in the literature. Given that the minimum expected value of an option is always zero, the minimum estimated value for investing using an OPM will be the same as the value given by the traditional approach. However, when the expected value of the option (e.g., future iterations or projects) exceeds zero, an OPM will give an estimated value greater than the traditional approach. The actual calculation of the value of an option is quite complex and, as such, is beyond the scope of this book. However, given how well the OPMs fit the object-oriented systems development approaches, it seems reasonable that OPMs should be considered as alternatives to evaluating IT investments in object-oriented systems. Organizational Feasibility The final technique used for feasibility analysis is to assess the organizational feasibility of the system, how well the system ultimately will be accepted by its users and incorpo- rated into the ongoing operations of the organization. There are many organizational factors that can have an impact on the project, and seasoned developers know that orga- nizational feasibility can be the most difficult feasibility dimension to assess. In essence, an organizational feasibility analysis attempts to answer this question: If we build it, will they come? One way to assess the organizational feasibility of the project is to understand how well the goals of the project align with business objectives. Strategic alignment is the fit between the project and business strategy—the greater the alignment, the less risky the project will be from an organizational feasibility perspective. For example, if the marketing department has decided to become more customer focused, then a CRM project that produces inte- grated customer information would have strong strategic alignment with marketing’s goal. Many IT projects fail when the IT department initiates them, because there is little or no alignment with business unit or organizational strategies. A second way to assess organizational feasibility is to conduct a stakeholder analysis.5 A stakeholder is a person, group, or organization that can affect (or will be affected by) a new system. In general, the most important stakeholders in the introduction of a new system are the project champion, system users, and organizational management (see Figure 2-11), but systems sometimes affect other stakeholders as well. For example, the IS department can be a stakeholder of a system because IS jobs or roles may be changed significantly after its implementation. One key stakeholder outside of the champion, users, and management in Microsoft’s project that embedded Internet Explorer as a standard part of Windows was the U.S. Department of Justice. 56 Chapter 2 Project Initiation 4 Two of the more important OPMs used for evaluating IT investments are the binomial OPM and the Black- Scholes OPM. For more information on these models see J. C. Hull, Options, Futures, and Other Derivative Securities (Englewood Cliffs, NJ: Prentice-Hall, 1993). 5 A good book that presents a series of stakeholder analysis techniques is R. O. Mason and I. I. Mittroff, Challenging Strategic Planning Assumptions: Theory, Cases, and Techniques (New York: Wiley, 1981). The champion is a high-level, noninformation systems executive who is usually, but not always, the project sponsor who created the system request. The champion supports the project with time, resources (e.g., money), and political support within the organiza- tion by communicating the importance of the system to other organizational decision makers. More than one champion is preferable because if the champion leaves the organi- zation, the support could leave as well. Whereas champions provide day-to-day support for the system, organizational man- agement also needs to support the project. Such management support conveys to the rest of the organization the belief that the system will make a valuable contribution and that necessary resources will be made available. Ideally, management should encourage people in the organization to use the system and to accept the many changes that the system will likely create. A third important group of stakeholders are the system users who will ultimately use the system once it has been installed in the organization. Too often, the project team meets with users at the beginning of a project and then disappears until after the system is cre- ated. In this situation, rarely does the final product meet the expectations and needs of those who are supposed to use it because needs change and users become savvier as the project progresses. User participation should be promoted throughout the development process to make sure that the final system will be accepted and used by getting users actively involved in the development of the system (e.g., performing tasks, providing feedback, making decisions). Finally, the feasibility study helps organizations make wiser investments regarding infor- mation systems because it forces project teams to consider technical, economic, and orga- nizational factors that can impact their projects. It protects IT professionals from criticism by keeping the business units educated about decisions and positioned as the leaders in the decision-making process. Remember, the feasibility study should be revised several times during the project at points where the project team makes critical decisions about the sys- tem (e.g., before the design begins). It can be used to support and explain the critical choices that are made throughout the SDLC. Project Identification 57 Champion A champion: • Make a presentation about the objectives of the • Initiates the project project and the proposed benefits to those executives • Promotes the project who will benefit directly from the system • Allocates his or her time to project • Create a prototype of the system to demonstrate its • Provides resources potential value Organizational Organizational managers: • Make a presentation to management about the Management • Know about the project objectives of the project and the proposed benefits • Budget enough money for the project • Market the benefits of the system using memos and • Encourage users to accept and use the system organizational newsletters • Encourage the champion to talk about the project with his or her peers System Users Users: • Assign users official roles on the project team • Make decisions that influence the project • Assign users specific tasks to perform with clear • Perform hands-on activities for the project deadlines • Ultimately determine whether the project is • Ask for feedback from users regularly (e.g., at successful by using or not using the system weekly meetings) Role Techniques for improvement FIGURE 2-11 Some Important Stakeholders for Organizational Feasibility 58 Chapter 2 Project Initiation PROJECT SELECTION Once the feasibility analysis has been completed, it is submitted to the approval committee, along with a revised system request. The committee then decides whether to approve the project, decline the project, or table it until additional information is available. At the pro- ject level, the committee considers the value of the project by examining the business need (found in the system request) and the risks of building the system (presented in the feasi- bility analysis). Before approving the project, however, the committee also considers the project from an organizational perspective; it has to keep in mind the company’s entire portfolio of pro- jects. This way of managing projects is called portfolio management. Portfolio management takes into consideration the different kinds of projects that exist in an organization—large and small, high risk and low risk, strategic and tactical. (See Figure 2-12 for the different ways of classifying projects.) A good project portfolio will have the most appropriate mix of projects for the organization’s needs. The committee acts as portfolio manager with the goal of maximizing the cost/benefit performance and other important factors of the pro- jects in their portfolio. For example, an organization may want to keep high-risk projects to less than 20 percent of its total project portfolio. Think about the idea that you developed in Your Turn 2-2 to improve your university or college course enrollment. Questions 1. List three things that influence the technical feasibility of the system. 2. List three things that influence the economic feasi- bility of the system. 3. List three things that influence the organizational feasibility of the system. 4. How can you learn more about the issues that affect the three kinds of feasibility? 2-3 Create a Feasibility AnalysisYOUR TURN Size What is the size? How many people are needed to work on the project? Cost How much will the project cost the organization? Purpose What is the purpose of the project? Is it meant to improve the technical infrastructure? Support a current business strategy? Improve operations? Demonstrate a new innovation? Length How long will the project take before completion? How much time will go by before value is delivered to the business? Risk How likely is it that the project will succeed or fail? Scope How much of the organization is affected by the system? A department? A division? The entire corporation? Return on investment How much money does the organization expect to receive in return for the amount the project costs? FIGURE 2-12 Ways to Classify Projects Project Selection 59 The approval committee must be selective about where to allocate resources, because the organization has limited funds. This involves trade-offs, in which the orga- nization must give up something in return for something else to keep its portfolio well balanced. If there are three potentially high-payoff projects, yet all have very high risk, then perhaps only one of the projects will be selected. Also, there are times when a sys- tem at the project level makes good business sense, but it does not make sense at the organization level. Thus, a project may show a very strong ROI and support important business needs for a part of the company; however, it is not selected. This could happen for many reasons—because there is no money in the budget for another system, the organization is about to go through some kind of change (e.g., a merger or an imple- mentation of a companywide system like an ERP), projects that meet the same business requirements already are underway, or the system does not align well with current or future corporate strategy. It seems hard to believe that an approval committee would not select a project that meets real business needs, has a high potential ROI, and has a positive feasibility analysis. Think of a company you have worked for or know about. Describe a scenario in which a project may be very attractive at the project level but not at the orga- nization level. 2-4 To Select or Not to SelectYOUR TURN At Marriott, we don’t have IT projects—we have business initiatives and strategies that are enabled by IT. As a result, the only time a traditional “IT project” occurs is when we have an infrastructure upgrade that will lower costs or leverage better functioning technology. In this case, IT has to make a business case for the upgrade and prove its value to the company. The way IT is involved in business projects in the organization is twofold. First, senior IT positions are filled by people with good business understanding. Sec- ond, these people are placed on key business commit- tees and forums where the real business happens, such as finding ways to satisfy guests. Because IT has a seat at the table, we are able to spot opportunities to support business strategy. We look for ways in which IT can enable or better support business initiatives as they arise. Therefore, business projects are proposed, and IT is one component of them. These projects are then evalu- ated the same as any other business proposal, such as a new resort—by examining the return on investment and other financial measures. At the organizational level, I think of projects as must- do’s, should-do’s, and nice-to-do’s. The must-do’s are required to achieve core business strategy, such as guest pref- erence. The should-do’s help grow the business and enhance the functionality of the enterprise. These can be somewhat untested, but good drivers of growth. The nice-to-do’s are more experimental and look farther out into the future. The organization’s project portfolio should have a mix of all three kinds of projects, with a much greater pro- portion devoted to the must-do’s. —Carl Wilson 2-F Interview with Carl Wilson, CIO, Marriott CorporationCONCEPTS IN ACTION 60 Chapter 2 Project Initiation Hygeia Travel Health is a Toronto-based health insurance company whose clients are the insurers of foreign tourists to the United States and Canada. Its project selection process is relatively straightforward. The project evalua- tion committee, consisting of six senior executives, splits into two groups. One group includes the CIO, along with the heads of operations and research and development, and it analyzes the costs of every project. The other group consists of the two chief marketing officers and the head of business development, and they analyze the expected benefits. The groups are permanent, and to stay objective, they don’t discuss a project until both sides have evalu- ated it. The results are then shared, both on a spreadsheet and in conversation. Projects are then approved, passed over, or tabled for future consideration. Last year, the marketing department proposed pur- chasing a claims database filled with detailed information on the costs of treating different conditions at different facil- ities. Hygeia was to use this information to estimate how much money insurance providers were likely to owe on a given claim if a patient was treated at a certain hospital as opposed to any other. For example, a 45-year-old man suf- fering a heart attack may accrue $5,000 in treatment costs at hospital A but only $4,000 at hospital B. This information would allow Hygeia to recommend the cheaper hospital to its customer. That would save the customer money and help differentiate Hygeia from its competitors. The benefits team used the same three-meeting process to discuss all the possible benefits of implementing the claims database. Members of the team talked to cus- tomers and made a projection using Hygeia’s past experi- ence and expectations about future business trends. The verdict: The benefits team projected a revenue increase of $210,000. Client retention would rise by 2 percent. And overall, profits would increase by 0.25 percent. The costs team, meanwhile, came up with large esti- mates: $250,000 annually to purchase the database and an additional $71,000 worth of internal time to make the information usable. Putting it all together, it was a finan- cial loss of $111,000 in the first year. The project still could have been good for marketing— maybe even good enough to make the loss acceptable. But some of Hygeia’s clients were also in the claims infor- mation business and therefore were potential competi- tors. This, combined with the financial loss, was enough to make the company reject the project. Source: Ben Worthen, “Two Teams are Better than One” CIO Magazine, (July 15, 2001). 2-G A Project That Does Not Get SelectedCONCEPTS IN ACTION In April 1999, one of Capital Blue Cross’s health-care insurance plans had been in the field for three years but hadn’t performed as well as expected. The ratio of premi- ums to claims payments wasn’t meeting historic norms. In order to revamp the product features or pricing to boost performance, the company needed to understand why it was underperforming. The stakeholders came to the dis- cussion already knowing they needed better extraction and analysis of usage data in order to understand product shortcomings and recommend improvements. After listening to input from the user teams, the stake- holders proposed three options. One was to persevere with the current manual method of pulling data from flat files via ad hoc reports and retyping it into spreadsheets. The second option was to write a program to dynami- cally mine the needed data from Capital’s customer infor- mation control system (CICS). While the system was processing claims, for instance, the program would pull out up-to-the-minute data at a given point in time for users to analyze. The third alternative was to develop a decision sup- port system to allow users to make relational queries from a data mart containing a replication of the relevant claims and customer data. Each of these alternatives was evalu- ated on cost, benefits, risks and intangibles. Questions 1. What are three costs, benefits, risks, and intangibles associated with each project? 2. Based on your answer to question 1, which project would you choose? Source: Richard Pastore, “Capital Blue Cross,” CIO Magazine (February 15, 2000). 2-5 Project SelectionYOUR TURN APPLYING THE CONCEPTS AT CD SELECTIONS So far we have introduced the concepts of identifying a project, creating a system request, performing a feasibility analysis, and selecting a project. Now we see how CD Selections performs these tasks. Project Identification and System Request At CD Selections, all potential IT projects are reviewed and approved by a project steering committee that meets quarterly. The committee has representatives from IT as well as from the major areas of the business. For Margaret, the first step was to prepare a system request for the committee. Using the system request template (see Figure 2-2), Margaret prepared a system request (see Figure 2-13). Of course, the sponsor is Margaret, and the business needs are to increase sales and to better service retail customers. Notice that the need does not focus on the technology, such as the need “to upgrade our Web page.” The focus is on the business aspects: sales and customer service. Applying the Concepts at CD Selections 61 System Request—Internet Order Project Project sponsor: Margaret Mooney, Vice President of Marketing Business Need: This project has been initiated to reach new Internet customers and to better serve existing customers using Internet sales support. Business Requirements: Using the Web, customers should be able to search for products and identify the brick-and-mor- tar stores that have them in stock. They should be able to put items on hold at a store location or place an order for items that are not carried or are not in stock. The functionality that the system should have is as follows: • Search through the CD Selections inventory of products. • Identify the retail stores that have the product in stock. • Put a product on hold at a retail store and schedule a time to pick up the product. • Place an order for products not currently in stock or not carried by CD Selections. • Receive confirmation that an order can be placed and when the item will be in stock. Business Value: We expect that CD Selections will increase sales by reducing lost sales due to out-of-stock or nonstocked items and by reaching out to new customers through its Internet presence. We expect the improved services will reduce customer complaints, primarily because 50% of all customer complaints stem from out-of-stocks or nonstocked items. Also, CD Selections should benefit from improved customer satisfaction and increased brand recognition due to its Internet presence. Conservative estimates of tangible value to the company include: • $750,000 (75% of $1,000,000) in sales from new customers • $1,875,000 (75% of $2,500,000) in sales from existing customers • $50,000 in sales from customers not facing “out-of-stock or nonstocked” items Special Issues or Constraints: • The Marketing Department views this as a strategic system. This Internet system will add value to our current business model, and it also will serve as a proof-of-concept for future Internet endeavors. For example, in the future, CD Selections may want to sell products directly over the Internet. • The system should be in place for the holiday shopping season next year. FIGURE 2-13 System Request for CD Selections For now, the business requirements are described at a very high level of detail. In this case, Margaret’s vision for the requirements includes the ability to help brick-and- mortar stores reach out to new customers. Specifically, customers should be able to search for products over the Internet, locate a retail store that contains the product, put a product on hold for later store pickup, and order products that are not currently being stocked. The business value describes how the requirements will affect the business. Margaret found identifying intangible business value to be fairly straightforward in this case. The Internet is a “hot” area, so she expects the Internet to improve customer recognition and satisfaction. Estimating tangible value is more difficult. She expects that Internet ordering will increase sales in the retail stores, but by how much? Margaret decided to have her marketing group do some market research to learn how many retail customers do not complete purchases because the store does not carry the item they want. They learned that stores lose approximately 5 percent of total sales from “out- of-stocks and nonstocks.” This number gave Margaret some idea of how much sales could increase from the existing customer base (i.e., about $50,000 per store), but it does not indicate how many new customers the system will generate. Estimating how much revenue CD Selections should anticipate from new Internet cus- tomers was not simple. One approach was to use some of CD Selections’ standard models for predicting sales of new stores. Retail stores average about $1 million in sales per year (after they have been open a year or two), depending upon location factors such as city population, average incomes, proximity to universities, and so on. Margaret estimated that adding the new Internet site would have an effect similar to adding a new store. This would suggest ongoing revenues of $1 million, give or take several hundred thousand dollars, after the Web site had been operating for a few years. Together, the sales from existing customers ($2.5 million) and new customers ($1 million) totaled approximately $3.5 million. Margaret created conservative and opti- mistic estimates by reducing and increasing this figure by 25 percent. This created a possi- ble range of values from $2,625,000 to $4,375,000. Margaret is conservative, so she decided to include the lower number as her sales projection. Figure 2-13 shows the completed system request. Feasibility Analysis Once Margaret and her marketing group completed the system request, they submitted it to the steering committee for their next meeting. When the steering committee met, they placed the Internet Order project high on its list of projects. A senior systems ana- lyst, Alec Adams, was assigned to help Margaret conduct a feasibility analysis because of his familiarity with CD Selections’ sales and distribution systems. He also was an avid user of the Web and had been offering suggestions for the improvement of CD Selec- tions’ Web site. Alec and Margaret worked closely together over the next few weeks on the feasibility analysis. Figure 2-14 presents the executive summary page of the feasibility analysis; the report itself was about 10 pages long, and it provided additional detail and supporting documentation. As shown in Figure 2-14, the project is somewhat risky from a technical perspective. CD Selections has minimal experience with the proposed application and the technology because the ISP has been managing most of the website technology to date. One solution may be to hire a consultant with e-commerce experience to work with the IT department and to offer guidance. Further, the new system would have to exchange order information 62 Chapter 2 Project Initiation Applying the Concepts at CD Selections 63 Internet Order Feasibility Analysis Executive Summary Margaret Mooney and Alec Adams created the following feasibility analysis for the CD Selections Internet Order System Project. The System Proposal is attached, along with the detailed feasibility study. The highlights of the feasibility analysis are as follows: Technical Feasibility The Internet Order System is feasible technically, although there is some risk. CD Selections’ risk regarding familiarity with Internet order applications is high • The Marketing Department has little experience with Internet-based marketing and sales. • The IT Department has strong knowledge of the company’s existing order systems; however, it has not worked with Web-enabled order systems. • Hundreds of retailers that have Internet Order applications exist in the marketplace. CD Selections’ risk regarding familiarity with the technology is medium. • The IT Department has relied on external consultants and an Information Service Provider to develop its existing Web environment. • The IT Department has gradually learned about Web systems by maintaining the current Web site. • Development tools and products for commercial Web application development are available in the marketplace, although the IT depart- ment has little experience with them. • Consultants are readily available to provide help in this area. The project size is considered medium risk. • The project team likely will include fewer than ten people. • Business user involvement will be required. • The project timeframe cannot exceed a year because of the holiday season implementation deadline, and it should be much shorter. The compatibility with CD Selections’ existing technical infrastructure should be good. • The current Order System is a client-server system built using open standards. An interface with the Web should be possible. • Retail stores already place and maintain orders electronically. • An Internet infrastructure already is in place at retail stores and at the corporate headquarters. • The ISP should be able to scale their services to include a new Order System. Economic Feasibility A cost–benefit analysis was performed; see attached spreadsheet for details. A conservative approach shows that the Internet Order System has a good chance of adding to the bottom line of the company significantly. ROI over 3 years: 229 percent Total benefit after three years: $3.5 million (adjusted for present value) Break-even occurs: after 1.32 years Intangible Costs and Benefits • Improved customer satisfaction • Greater brand recognition Organizational Feasibility From an organizational perspective, this project has low risk. The objective of the system, which is to increase sales, is aligned well with the senior management’s goal of increasing sales for the company. The move to the Internet also aligns with Marketing’s goal to become more savvy in Internet marketing and sales. The project has a project champion, Margaret Mooney, Vice President of Marketing. Margaret is well positioned to sponsor this project and to educate the rest of the senior management team when necessary. To date, much of senior management is aware of and supports the initiative. The users of the system, Internet consumers, are expected to appreciate the benefits of CD Selections’ Web presence. And, management in the retail stores should be willing to accept the system, given the possibility of increased sales at the store level. Additional Comments • The Marketing Department views this as a strategic system. This Internet system will add value to our current business model, and it also will serve as a proof of concept for future Internet endeavors. • We should consider hiring a consultant with expertise in similar applications to assist with the project. • We will need to hire new staff to operate the new system, from both the technical and business operations aspects. FIGURE 2-14 Feasibility Analysis for CD Selections TEMPLATE can be found at www.wiley.com /college/dennis with the company’s brick-and-mortar order system. Currently, individual retail stores submit orders electronically, so receiving orders and exchanging information with the Internet systems should be possible. The economic feasibility analysis includes refined assumptions that Margaret made in the system request. Figure 2-15 shows the summary spreadsheet that lead to the con- clusions on the feasibility analysis. Development costs are expected to be about $250,000. This is a very rough estimate, because Alec has had to make some assump- tions about the amount of time it will take to design and program the system. These estimates will be revised after a detailed workplan has been developed and as the pro- ject proceeds.6 Traditionally, operating costs include the costs of the computer opera- tions. In this case, CD Selections has had to include the costs of business staff because they are creating a new business unit, resulting in a total of about $450,000 each year. Margaret and Alec have decided to use a conservative estimate for revenues, although they note the potential for higher returns. This shows that the project can still add sig- nificant business value, even if the underlying assumptions prove to be overly opti- mistic. The spreadsheet was projected over three years, and the ROI and break-even point were included. The organizational feasibility is presented in Figure 2-14. There is a strong champion, well placed in the organization to support the project. The project originated in the busi- ness or functional side of the company, not the IT department, and Margaret has carefully built up support for the project among the senior management team. This is an unusual system in that the ultimate end users are the consumers external to CD Selections. Margaret and Alec have not done any specific market research to see how well potential customers will react to the CD Selections system, so this is a risk. An additional stakeholder in the project is the management team responsible for the operations of the traditional stores and the store managers. They should be quite supportive, given the added service that they now can offer. However, Margaret must convince them that the Internet Sales System will not be viewed as a threat to stores’ future sales. As such, Margaret and Alec need to make sure that the management team and store managers are included in the development of the system so that they can incorporate the system into their business processes. Project Selection The approval committee met and reviewed the Internet Sales System project along with two other projects—one calling for the implementation of a corporate Intranet and another proposing in-store kiosks that would provide customers with information about the CDs that the store carried. Unfortunately, the budget would allow for only one pro- ject to be approved, so the committee carefully examined the costs, expected benefits, risks, and strategic alignment of all three projects. Currently, a primary focus of upper management is increasing sales in the retail stores and the Internet system and kiosk project best aligned with that goal. Given that both projects had equal risk but that the Internet Order project expected a much greater return, the committee decided to fund the Internet Sales System. 64 Chapter 2 Project Initiation 6 Some of the salary information may seem high. Most companies use a “full-cost” model for estimating salary cost, in which all benefits (e.g., health insurance, retirement, and payroll taxes) are included in salaries when esti- mating costs. Applying the Concepts at CD Selections 65 Increased sales from new customers 0 750,000 772,500 Increased sales from existing customers 0 1,875,000 1,931,250 Reduction in customer complaint calls 0 50,000 50,000 TOTAL BENEFITS: 0 2,675,000 2,753,750 PV of BENEFITS: 0 2,521,444 2,520,071 5,041,515 PV of ALL BENEFITS: 0 2,521,444 5,041,515 Labor: Analysis and Design 42,000 0 0 Labor: Implementation 120,000 0 0 Consultant Fees 50,000 0 0 Training 5,000 0 0 Office Space and Equipment 2,000 0 0 Software 10,000 0 0 Hardware 25,000 0 0 TOTAL DEVELOPMENT COSTS: 254,000 0 0 Labor: Webmaster 85,000 87,550 90,177 Labor: Network Technician 60,000 61,800 63,654 Labor: Computer Operations 50,000 51,500 53,045 Labor: Business Manager 60,000 61,800 63,654 Labor: Assistant Manager 45,000 46,350 47,741 Labor: 3 Staff 90,000 92,700 95,481 Software Upgrades 1,000 1,000 1,000 Software Licenses 3,000 1,000 1,000 Hardware Upgrades 5,000 3,000 3,000 User Training 2,000 1,000 1,000 Communications Charges 20,000 20,000 20,000 Marketing Expenses 25,000 25,000 25,000 TOTAL OPERATIONAL COSTS: 446,000 452,700 464,751 TOTAL COSTS: 700,000 452,700 464,751 PV of COSTS: 679,612 426,713 425,313 1,531,638 PV of ALL COSTS: 679,612 1,106,325 1,531,638 Total Project Benefits Ϫ Costs : (700,000) 2,222,300 2,288,999 Yearly NPV: (679,612) 2,094,731 2,094,758 3,509,878 Cumulative NPV: (679,612) 1,415,119 3,509,878 Return on Investment: 229.16% (3,509,878/1,531,638) Break-even Point: 1.32 years (Break-even occurs in year 2; (2,094,731 Ϫ 1,415,119]/2,094,731 ϭ 0.32) Intangible Benefits: Greater brand recognition Improved customer satisfaction 2008 2009 2010 Total FIGURE 2-15 Economic Feasibility Analysis for CD Selections SUMMARY Project Initiation Project initiation is the point at which an organization creates and assesses the original goals and expectations for a new system. The first step in the process is to identify the busi- ness value for the system by developing a system request that provides basic information about the proposed system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and organizational feasibility of the system; if appropriate, the sys- tem is approved, and the development project begins. Feasibility Analysis A feasibility analysis is then used to provide more detail about the risks associated with the proposed system, and it includes technical, economic, and organizational feasibilities. The technical feasibility focuses on whether the system can be built by examining the risks asso- ciated with the users’ and analysts’ familiarity with the functional area, familiarity with the technology, and project size. The economic feasibility addresses whether the system should be built. It includes a cost–benefit analysis of development costs, operational costs, tangi- ble benefits, and intangible costs and benefits. Finally, the organizational feasibility assesses how well the system will be accepted by its users and incorporated into the ongoing oper- ations of the organization. The strategic alignment of the project and a stakeholder analysis can be used to assess this feasibility dimension. Project Selection Once the feasibility analysis has been completed, it is submitted to the approval committee, along with a revised system request. The committee then decides whether to approve the project, decline the project, or table it until additional information is available. The project selection process uses portfolio management to take into account all the projects in the organization. The approval committee weighs many factors and makes trade-offs before a project is selected. KEY TERMS 66 Chapter 2 Project Initiation Approval committee Break-even point Business need Business requirement Business value Call option Cash flow method Champion Compatibility Cost–benefit analysis Development costs Economic feasibility Emerging Technology Familiarity with the functional area Familiarity with the technology Feasibility analysis Feasibility study First mover Functionality Intangible benefits Intangible costs Intangible value Net present value (NPV) Operational costs Option pricing models (OPMs) Organizational feasibility Organizational management Portfolio management Project Project initiation Project size Project sponsor Return on investment (ROI) Risks Special issues Stakeholder Stakeholder analysis Strategic alignment System request System users Tangible benefits Tangible value Technical feasibility Technical risk analysis Trade-offs Minicases 67 QUESTIONS 1. Give three examples of business needs for a system. 2. What is the purpose of an approval committee? Who is usually on this committee? 3. Why should the system request be created by a busi- nessperson as opposed to an IS professional? 4. What is the difference between intangible value and tangible value? Give three examples of each. 5. What are the purposes of the system request and the feasibility analysis? How are they used in the project selection process? 6. Describe two special issues that may be important to list on a system request. 7. Describe the three techniques for feasibility analysis. 8. What factors are use to determine project size? 9. Describe a risky project in terms of technical feasibility. Describe a project that would not be considered risky. 10. What are the steps for assessing economic feasibility? Describe each step. 11. List two intangible benefits. Describe how these bene- fits can be quantified. 12. List two tangible benefits and two operational costs for a system. How would you determine the values that should be assigned to each item? 13. Explain the net present value and return on invest- ment for a cost benefit analysis. Why would these cal- culations be used? 14. What is the break-even point for the project? How is it calculated? 15. What is stakeholder analysis? Discuss three stakeholders that would be relevant for most projects. EXERCISES A. Locate a news article in an IT trade magazine (e.g., Computerworld) about an organization that is imple- menting a new computer system. Describe the tangi- ble and intangible value that the organization is likely to realize from the new system. B. Car dealers have realized how profitable it can be to sell automobiles using the Web. Pretend you work for a local car dealership that is part of a large chain such as CarMax. Create a system request you might use to develop a Web-based sales system. Remember to list special issues that are relevant to the project. C. Supposed that you are interested in buying a new computer. Create a cost-benefit analysis that illustrates the return on investment that you would receive from making this purchase. Computer-related Web sites (e.g., Dell Computers, Compaq Computers) should have real tangible costs that you can include in your analysis. Project your numbers out to include a three- year period of time and provide the net present value of the final total. D. Consider the Amazon.com Web site. The management of the company decided to extend their Web-based system to include products other than books (e.g., wine and specialty gifts). How would you have assessed the feasibility of this venture when the idea first came up? How risky would you have considered the project that implemented this idea? Why? E. Interview someone who works in a large organization and ask him or her to describe the approval process that exists for approving new development projects. What do they think about the process? What are the problems? What are the benefits? F. Reread Your Turn 2-1. (Identify Tangible and Intan- gible Value). Create a list of the stakeholders that should be considered in a stakeholder analysis of this project. MINICASES 1. The Amberssen Specialty Company is a chain of twelve retail stores that sell a variety of imported gift items, gourmet chocolates, cheeses, and wines in the Toronto area. Amberssen has an IS staff of three people who have created a simple but effective information system of networked point-of-sale registers at the stores and a centralized accounting system at the com- pany headquarters. Harry Hilman, the head of Amberssens IS group, has just received the following memo from Bill Amberssen, Sales Director (and son of Amberssen’s founder). 68 Chapter 2 Project Initiation Harry—it’s time Amberssen Specialty launched itself on the Internet. Many of our competitors are already there, selling to customers without the expense of a retail storefront, and we should be there too. I pro- ject that we could double or triple our annual revenues by selling our products on the Internet. I’d like to have this ready by Thanksgiving, in time for the prime hol- iday gift-shopping season. Bill After pondering this memo for several days, Harry scheduled a meeting with Bill so that he could clarify Bill’s vision of this venture. Using the standard content of a system request as your guide, prepare a list of questions that Harry needs to have answered about this project. 2. The Decker Company maintains a fleet of ten service trucks and crews that provide a variety of plumbing, heating, and cooling repair services to residential cus- tomers. Currently, it takes on average about six hours before a service team responds to a service request. Each truck and crew averages twelve service calls per week, and the average revenue earned per service call is $150. Each truck is in service fifty weeks per year. Due to the difficulty in scheduling and routing, there is considerable slack time for each truck and crew dur- ing a typical week. In an effort to more efficiently schedule the trucks and crews and improve their productivity, Decker man- agement is evaluating the purchase of a prewritten rout- ing and scheduling software package. The benefits of the system will include reduced response time to service requests and more productive service teams, but man- agement is having trouble quantifying these benefits. One approach is to make an estimate of how much service response time will decrease with the new sys- tem, which then can be used to project the increase in the number of service calls made each week. For example, if the system permits the average service response time to fall to four hours, management believes that each truck will be able to make sixteen service calls per week on average—an increase of four calls per week. With each truck making four addi- tional calls per week and the average revenue per call at $150, the revenue increase per truck per week is $600 (4 ϫ $150).With ten trucks in service fifty weeks per year, the average annual revenue increase will be $300,000 ($600 ϫ 10 ϫ 50). Decker Company management is unsure whether the new system will enable response time to fall to four hours on average, or will be some other number. Therefore, management has developed the following range of outcomes that may be possible outcomes of the new system, along with probability estimates of each outcome occurring. New Response Time # Calls/Truck/Week Likelihood 2 hours 20 20% 3 hours 18 30% 4 hours 16 50% Given these figures, prepare a spreadsheet model that computes the expected value of the annual revenues to be produced by this new system. 69 This chapter describes the important steps of project management, which begins in planning and continues throughout the SDLC. First, the project manager estimates the size of the project and identifies the tasks that need to be performed. Next, he or she staffs the project and puts several activities in place to help coordinate project activities. These steps produce important project management deliverables, including the workplan, staffing plan, and standards list. OBJECTIVES ■ Become familiar with estimation. ■ Be able to create a project workplan. ■ Understand why project teams use timeboxing. ■ Become familiar with how to staff a project. ■ Understand how computer-aided software engineering, standards, and documentation improve the efficiency of a project. ■ Understand how to reduce risk on a project. CHAPTER OUTLINE CHAPTER 3 Project Management Introduction Identifying Project Size Function Point Approach Creating and Managing the Workplan Identifying Tasks The Project Workplan Gantt Chart PERT Chart Refining Estimates Scope Management Timeboxing Evolutionary Work Breakdown Structures and Iterative Workplans Staffing the Project Staffing Plan Motivation Handling Conflict Coordinating Project Activities CASE Tools Standards Documentation Managing Risk Applying the Concepts at CD Selections Staffing the Project Coordinating Project Activities Summary INTRODUCTION Think about major projects that occur in people’s lives, such as throwing a big party, like a wedding or graduation celebration. Months are spent in advance identifying and performing all the tasks that need to get done, such as sending out invitations and selecting a menu, and time and money are carefully allocated among them. Along the way, decisions are recorded, problems are addressed, and changes are made. The increasing popularity of the party planner, a person whose sole job is to coordinate a party, suggests how tough this job can be. In the end, the success of any party has a lot to do with the effort that went into planning along the way. System development projects can be much more complicated than the projects we encounter in our personal lives—usually, more people are involved (e.g., the organization), the costs are higher, and more tasks need to be completed. Therefore, it is not surprising that “party plan- ners” exist for information system projects; they are called project managers. Project management is the process of planning and controlling the development of a system within a specified time frame at a minimum cost with the right functionality.1 A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated. Today, project management is an actual profes- sion, and analysts spend years working on projects prior to tackling the management of them. In a 1999 Computerworld survey, more than half of 103 companies polled said they now offer formal project management training for information technology (IT) project teams. There also is a variety of project management software available, such as Microsoft Project, PlanView, and PMOffice, which support project management activities. Although training and software are available to help project managers, unreasonable demands set by project sponsors and business managers can make project management very difficult. Too often, the approach of the holiday season, the chance at winning a pro- posal with a low bid, or a funding opportunity pressures project managers to promise sys- tems long before they are able to deliver them. These overly optimistic timetables are thought to be one of the biggest problems that projects face; instead of pushing a project forward faster, they result in delays. Thus, a critical success factor for project management is to start with a realistic assess- ment of the work that needs to be accomplished and then manage the project according to that assessment. This can be achieved by carefully following the four steps presented in this chapter: identifying the project size, creating and managing the workplan, staffing the pro- ject, and coordinating project activities. The project manager ultimately creates a work- plan, staffing plan, and standards list, which are used and refined throughout the entire system development lifecycle. IDENTIFYING PROJECT SIZE The science (or art) of project management is in making trade-offs among three important concepts: the size of the system (in terms of what it does), the time to complete the project (when the project will be finished), and the cost of the project. Think of these three things as interdependent levers that the project manager controls throughout the SDLC. When- ever one lever is pulled, the other two levers are affected in some way. For example, if a pro- ject manager needs to readjust a deadline to an earlier date, then the only solutions are to decrease the size of the system (by eliminating some of its functions) or to increase costs by adding more people or having them work overtime. Often, a project manager will have to work with the project sponsor to change the goals of the project, such as developing a 70 Chapter 3 Project Management 1 The following are good books on project management for object-oriented projects: Grady Booch, Object Solutions: Managing the Object-Oriented Project (Menlo Park, CA: Addison-Wesley, 1996); Murray R. Cantor, Object-Oriented Project Management with UML (New York, NY: Wiley, 1998); Alistair Cockburn, Surviving Object-Oriented Projects: A Manager’s Guide (Reading, MA: Addison-Wesley, 1998); and Walker Royce, Software Project Management: A Uni- fied Framework (Reading, MA: Addison-Wesley, 1998). Also, the Project Management Institute (www.pmi.org) and the Information Systems Special Interest Group of the Project Management Institute (www.pmi-issig.org) have valuable resources on project management in information systems. system with less functionality or extending the deadline for the final system, so that the project has reasonable goals that can be met. Therefore, in the beginning of the project, the manager needs to estimate each of these levers and then continuously assess how to roll out the project in a way that meets the orga- nization’s needs. Estimation2 is the process of assigning projected values for time and effort, and it can be performed manually or with the help of estimation software packages such as Costar and Construx—there are more than fifty available on the market. The estimates developed at the start of a project are usually based on a range of possible values (e.g., the design phase will take three to four months) and gradually become more specific as the project moves forward (e.g., the design phase will be completed on March 22). The numbers used to calculate these estimates can come from several sources. They can be provided with the methodology that is used, taken from projects with similar tasks and technologies, or provided by experienced developers. Generally speaking, the numbers should be conservative. A good practice is to keep track of the actual values for time and effort during the SDLC so that numbers can be refined along the way and the next project can benefit from real data. One of the greatest strengths of systems consulting firms is the past experience they offer to a project; they have estimates and methodologies that have been developed and honed over time and applied to hundreds of projects. There are a variety of ways to estimate the time required to build a system. For example, it is possible to use the function point approach, a task-decomposition approach using work breakdown structures, and the timeboxing approach. Each of these is described later in this chapter. However, the simplest method uses the amount of time spent in the planning phase to predict the time required for the entire project. The idea is that a simple project will require little planning and a complex project will require more planning, so using the amount of time spent in the planning phase is a reasonable way to estimate overall project time requirements. Identifying Project Size 71 2 A good book for further reading on software estimation is that by Capers Jones, Estimating Software Costs (New York: McGraw-Hill, 1989). I was once on a project to develop a system that should have taken a year to build. Instead, the business need demanded that the system be ready within five months— impossible! On the first day of the project, the project manager drew a triangle on a white board to illustrate some trade-offs that he expected to occur over the course of the project. The corners of the triangle were labeled Functionality, Time, and Money. The manager explained, “We have too little time. We have an unlimited budget. We will not be measured by the bells and whistles that this system contains. So over the next several weeks, I want you as developers to keep this tri- angle in mind and do everything it takes to meet this five- month deadline.” At the end of the five months, the project was deliv- ered on time; however, the project was incredibly over budget, and the final product was “thrown away” after it was used because it was unfit for regular usage. Remark- ably, the business users felt that the project was very suc- cessful because it met the very specific business needs for which it was built. They believed that the trade-offs that were made were worthwhile. —Barbara Wixom Questions 1. What are the risks in stressing only one corner of the triangle? 2. How would you have managed this project? Can you think of another approach that might have been more effective? 3-A Trade-offsCONCEPTS IN ACTION With this approach, you take the time spent in (or estimated for) the planning phase and use industry standard percentages (or percentages from the organization’s own expe- riences) to calculate estimates for the other SDLC phases. Industry standards suggest that a typical business application system spends 15 percent of its effort in the planning phase, 20 percent in the analysis phase, 35 percent in the design phase, and 30 percent in the implementation phase. This would suggest that if planning a project takes 4 months, then the rest of the project will probably take a total of 22.67 person-months [(4 Ϭ 0.15) Ϫ 4 ϭ 22.67]. These same industry percentages are then used to estimate the amount of time in each phase (Figure 3-1). The obvious limitation of this approach is that it can be difficult to take into account the specifics of your individual project, which may be simpler or more difficult than the typical project. Function Point Approach3 The function point approach to estimation uses a more complex—and, it is hoped, more reliable—three-step process (Figure 3-2). First, the project manager estimates the size of the project in terms of the number of lines of code the new system will require. This size estimate is then converted into the amount of effort required to develop the system in terms of a number of person-months. The esti- mated effort is then converted into an estimated schedule time in terms of the number of months from start to finish. Step 1: Estimate System Size The first step is to estimate the size of a project using function points, a concept devel- oped in 1979 by Allen Albrecht of IBM. A function point is a measure of program size based on the system’s number and complexity of inputs, outputs, queries, files, and pro- gram interfaces. 72 Chapter 3 Project Management 3 Two good books that focus on function points are J. Brian Dreger, Function Point Analysis (Englewood Cliffs, NJ: Prentice Hall, 1989) and C. R. Symons, Software Sizing and Estimating: MK II FPA (New York: Wiley, 1991). Additional information on function point analysis can be found at www.ifpug.org. We introduce a variation on function points, use-case points, in Chapter 5. Typical industry 15% 20% 35% 30% standards for business applications Estimates based Actual: Estimated: Estimated: Estimated: on actual figures 4 person- 5.33 person- 9.33 person- 8 person- for first stages months months months months of SDLC SDLC = systems development life cycle. Planning Analysis Design Implementation FIGURE 3-1 Estimating Project Time Using the Planning Phase Approach (months) (person-months) Estimate effort required Estimate time required (function points and lines of code) Estimate system size FIGURE 3-2 Estimating Project Time Using the Function Point Approach Identifying Project Size 73 To calculate the function points for a project, components are listed on a worksheet to represent the major elements of the system. For example, data entry screens are kinds of inputs, reports are outputs, and database queries are kinds of queries (see Figure 3-3). The project manager records the total number of each component that the system will include, and then he or she breaks down the number to show the number of components that have low, medium, and high complexity. In Figure 3-3, there are nineteen outputs that need to be developed for the system, four of which have low complexity, ten that have medium complexity, and five that are very complex. After each line is filled in, a total number of points is calculated per line by multiplying each number by a complexity index. The line totals are added to determine the total unadjusted function points (TUFP) for the project. The complexity of the overall system is greater than the sum of its parts. Things such as the familiarity of the project team with the business area and the technology that will be used to implement the project may also influence how complex a project will be. A project that is very complex for a team with little experience might have little complexity for a team with lots of experience. To create a more realistic size for the project, a number of addi- tional system factors, such as end user efficiency, reusability, and data communications, are assessed in terms of their effect on the project’s complexity (see Figure 3-3). These assess- ments are totaled and placed into a formula to calculate an adjusted project complexity (APC) score. The TUFP value is multiplied by the APC value to determine the ultimate size of the project in terms of total adjusted function points (TAFP). This number should give the project manager a reasonable idea as to how big the project will be. Sometimes a shortcut is used to determine the complexity of the project. Instead of calculating the complexity for the fourteen factors listed in Figure 3-3, project managers choose to assign an APC value that ranges from .65 for very simple systems, to 1.00 for nor- mal systems, to as much as 1.35 for complex systems; then, they multiply the value to the TUFP score. For example, a very simple system that has 200 unadjusted function points Nielsen Media used function point analysis (FPA) for an upgrade to the Global Sample Management System (GSMS) for Nielsen Media/NetRatings, which keeps track of the Internet rating sample, a group of 40,000 homes nationwide that volunteer to participate in ongoing ratings. In late fall of 1998, Nielsen Media did an FP count based on the current GSMS. (FPA is always easier and more accurate for an existing system.) Nielsen Media had its counters—three quality assurance staff—do their FPA and then input their count into KnowledgePlan, a productivity modeling tool. In early 1999, seven programmers began writing code for the system, which they were expected to complete in ten months. As November approached, the project was adding staff to try to meet the deadline. When it became evident that the deadline would not be met, a new FP count was conducted. The GSMS had grown to 900 FPs. Besides the original 500 plus 20 percent, there were 300 FPs attributable to features and functions that had crept into the project. How did that happen? The way it always does: The developers and users had added a button here and a new feature there, and soon the project was much larger than it was originally. But Nielsen Media had put a stake in the ground at the beginning from which they could measure growth along the way. The best practice is to run the FPA and productivity model at the project’s launch and again when there is a full list of functional requirements. Then do another analysis any time there is a major modification in the functional definition of the project. Source: Bill Roberts, “Ratings Game,” CIO Magazine (October 2000). 3-B Function Points at NielsenCONCEPTS IN ACTION 74 Chapter 3 Project Management Description System Components: Inputs Outputs Queries Files Program Interfaces 23 101 39 150 25 338 1 × 6 5 × 7 3 × 6 0 × 15 2 × 10 2 × 4 10 × 5 0 × 4 15 × 10 0 × 7 3 × 3 4 × 4 7 × 3 0 × 7 1 × 5 6 19 10 15 3 Total Unadjusted Function Points (TUFP): Total Number Low Complexity Medium High Total Overall System: Data communications Heavy use configuration Transaction rate End-user efficiency Complex processing Installation ease Multiple sites Performance Distributed functions Online data entry Online update Reusability Operational ease Extensibility (0 = no effect on processing complexity; 5 = great effect on processing complexity) Total Processing Complexity (PC): 3 0 0 0 0 0 0 0 2 2 0 0 0 0 7 Adjusted Processing Complexity (APC): 0.65 + (0.01 x 7 ) = 0.72 Total Adjusted Function Points (TAFP): 0.72 (APC) x 338 (TUFP) = 243 (TAFP) FIGURE 3-3 Function Point Estimation Worksheet TEMPLATE can be found at www.wiley.com /college/dennis would have a size of 130 adjusted function points (200 * .65 ϭ 130). However, if the system with 200 unadjusted function points were very complex, its function point size would be 270 (200 * 1.35 ϭ 270). In planning, the exact nature of the system has not yet been determined, so it is impos- sible to know exactly how many inputs, outputs, and so forth, will be in the system. It is up to the project manager to make an intelligent guess. Some people feel that using function points early on in a project is not practical for this reason. We believe function points can be a useful tool for understanding a project’s size at any point in the SDLC. Later in the pro- ject, once more is known about the system, the project manager will revise the estimates using this better knowledge to produce more accurate results. Once you have estimated the number of function points, you need to convert the num- ber of function points into the lines of code that will be required to build the system. The num- ber of lines of code depends on the programming language you decide to use. Figure 3-4 presents a very rough conversion guide for some popular languages. For example, the system in Figure 3-3 has 243 total adjusted function points. To develop the system in C would typically require approximately 35,964 (148 * 243) lines of code to write it. Conversely, Visual Basic would typically take 12,150 (50 * 243) lines of code. Developing the system using a package such as Excel or Access would take between 11,421 (47 * 243) and 8,505 (35 * 243) lines of code, respectively. There is a great range for packages because different packages enable you to do different things, and not all systems can be built using certain packages. Sometimes lots of extra code must be written to do some simple function because the package does not have the needed capabilities. There is also a very important message from the data in this figure. Because there is a direct relationship between lines of code and the amount of effort and time required to develop a system, the choice of development language has a significant impact on the time and cost of projects. FIGURE 3-4 Converting from Function Points to Lines of Code Access 35 ASP 69 C 148 Cϩϩ 60 C# 59 COBOL 73 Excel 47 HTML 43 Java 60 Javascript 56 JSP 59 Lotus Notes 21 Smalltalk 35 SQL 39 Visual Basic 50 Source: QSM Function Point Programming Languages Table, http://www.qsm.com/FPGearing.html Average Number of Lines of Language Code per Function Point Identifying Project Size 75 Step 2: Estimate Required Effort Once an understanding is reached about the size of a system, the next step is to estimate the effort required to build it. Effort is a function of the sys- tem size combined with production rates (how much work someone can complete in a given time). Much research has been done on software production rates. One of the most popular algorithms, the COCOMO4 model, was designed by Barry W.Boehm to convert a lines-of-code estimate into a person–month estimate. There are different versions of the COCOMO model, which vary based on the complexity of the software, the size of the system, the expe- rience of the developers, and the type of software being developed (e.g., business applica- tion software such as the registration system at a university; commercial software such as Word; or system software such as Windows). For small- to moderate-sized business software projects (i.e., 100,000 lines of code and ten or fewer programmers), the model is quite simple: effort (in person-months) ϭ 1.4 * thousands of lines of code For example, to develop a business software system requiring 10,000 lines of code would typically take 14 person-months to complete. If the system in Figure 3-3 were developed in C (which equates to 35,964 lines of code), it would require about 50.35 person-months of effort. Step 3: Estimate Time Required Once the effort is understood, the optimal schedule for the project can be estimated. Historical data or estimation software can be used as aids. One rule of thumb is to determine schedule using the following equation: schedule time (months) ϭ 3.0 * person-months1/3 76 Chapter 3 Project Management Imagine that job hunting has been going so well that you need to develop a system to support your efforts. The system should allow you to input information about the companies with which you interview, the interviews and office visits that you have scheduled, and the offers you receive. It should be able to produce reports, such as a company con- tact list, an interview schedule, and an office visit schedule, as well as produce thank-you letters to be brought into a word processor to customize. You also need the system to answer queries, such as the number of interviews by city and your average offer amount. Questions 1. Determine the number of inputs, outputs, inter- faces, files, and queries that this system requires. For each element, determine if the complexity is low, medium, or high. Record this information on a worksheet similar to the one in Figure 3-3. 2. Calculate the total function points for each line on your worksheet by multiplying the number of each element with the appropriate complexity score. 3. Sum up the total unadjusted function points. 4. Suppose the system will be built by you using Visual Basic (VB). Given your VB skills, multiply the TUFP score by the APC score that best estimates how complex the system will be for you to develop (.65 ϭ simple, 1 ϭ average, 1.35 ϭ complex), and calculate a TAFP value. 5. Using the table in Figure 3-4, determine the number of lines of code that correspond to VB. Multiply this number with the TAFP to find the total lines of code that your system will require. 3-1 Calculating System SizeYOUR TURN 4 The original COCOMO model is presented by Barry W. Boehm in Software Engineering Economics (Engle- wood Cliffs, NJ: Prentice-Hall, 1981). Since then, much additional research has been done. The latest version of COCOMO, COCOMO II, is described in B.W. Boehm, C. Abts, A.W. Brown, S. Chulani, B.K. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, Software Cost Estimation with COCOMO II (Upper Saddle River, NJ: Prentice Hall PTR, 2000). For the latest updates on COCOMO, see http://sunset.usc.edu/csse/research/ COCOMOII/ cocomo_main.html. This equation is widely used, although the specific numbers vary (e.g., some estimators may use 3.5 or 2.5 instead of 3.0). The equation suggests that a project that has an effort of 14 person-months should be scheduled to take a little more than 7 months to complete. Continuing the example of Figure 3-3, 50.35 person-months would require very slightly more than 11 months. It is important to note that this estimate is for the analysis, design, and implementation; it does not include the planning. Creating and Managing the Workplan 77 Refer to the project size and lines of code that you calculated in Your Turn 3-1. Questions 1. Determine the effort of your project in person- months by multiplying your lines of code (in thou- sands) by 1.4. 2. Calculate the schedule time in months for your project using the formula 3.0 * person-months1/3. 3. Based on your numbers, how much time will it take to complete the project if you are the developer? 3-2 Calculating Effort and Schedule TimeYOUR TURN CREATING AND MANAGING THE WORKPLAN Once a project manager has a general idea of the size and approximate schedule for the pro- ject, he or she creates a workplan, which is a dynamic schedule that records and keeps track of all the tasks that need to be accomplished over the course of the project. The workplan lists each task, along with important information about it, such as when it needs to be completed, the person assigned to do the work, and any deliverables that will result (Figure 3-5). The level of detail and the amount of information captured by the workplan depend on the needs of the project (and the detail usually increases as the project progresses). The workplan is usually the main component of the project management software mentioned earlier. To create a workplan, the project manager first identifies the tasks that need to be accomplished and determines how long they will take. Then the tasks are organized within a workplan and presented graphically using Gantt and PERT charts. All these techniques help a project manager understand and manage the project’s progress over time. Name of the task Perform economic feasibility Start date Jan 05, 2010 Completion date Jan 19, 2010 Person assigned to the task Project sponsor: Mary Smith Deliverable(s) Cost–benefit analysis Completion status Open Priority High Resources that are needed Spreadsheet software Estimated time 16 hours Actual time 14.5 hours Workplan Information Example FIGURE 3-5 Workplan Information Identifying Tasks The overall objectives for the system should be listed on the system request, and it is the project manager’s job to identify all the tasks that need to be accomplished to meet those objectives. This sounds like a daunting task—how can someone know everything that needs to be done to build a system that has never been built before? One approach for identifying tasks is to get a list of tasks that has already been devel- oped and to modify it. There are standard lists of tasks, or methodologies, that are available for use as a starting point. As we stated in Chapter 1, a methodology is a formalized approach to implementing an SDLC (i.e., it is a list of steps and deliverables). A project manager can take an existing methodology, select the steps and deliverables that apply to the current pro- ject, and add them to the workplan. If an existing methodology is not available within the organization, methodologies can be purchased from consultants or vendors, or books such as this textbook can serve as a guide. Using an existing methodology is the most popular way to create a workplan because most organizations have a methodology they use for projects. If a project manager prefers to begin from scratch, he or she can use a structured, top- down approach whereby high-level tasks are first defined and then broken down into sub- tasks. For example, Figure 3-6 shows a list of high-level tasks needed to implement a new IT training class. Some of the main steps in the process include identifying vendors, creating and administering a survey, and building new classrooms. Each step is then broken down in turn and numbered in a hierarchical fashion. There are eight subtasks (i.e., 7.1–7.8) for creating and administering a survey, and there are three subtasks (7.2.1–7.2.3) that comprise the review initial survey task. A list of tasks hierarchically numbered in this way is called a work breakdown structure (WBS), and it is the backbone of the project workplan. The number of tasks and level of detail depend on the complexity and size of the project. The larger the 78 Chapter 3 Project Management 1 Identify vendors 2 Complete 2 Review training materials 6 1 Complete 3 Compare vendors 2 2 In Progress 4 Negotiate with vendors 3 3 Open 5 Develop communications information 4 1 In Progress 6 Disseminate information 2 5 Open 7 Create and administer survey 4 6 Open 7.1 Create initial survey 1 Open 7.2 Review initial survey 1 7.1 Open 7.2.1 Review by Director of IT Training 1 Open 7.2.2 Review by Project Sponsor 1 Open 7.2.3 Review by Representative Trainee 1 Open 7.3 Pilot test initial survey 1 7.1 Open 7.4 Incorporate survey changes 1 7.2, 7.3 Open 7.5 Create distribution list 0.5 Open 7.6 Send survey to distribution list 0.5 7.4, 7.5 Open 7.7 Send follow-up message 0.5 7.6 Open 7.8 Collect completed surveys 1 7.6 Open 8 Analyze results and choose vendor 2 4, 7 Open 9 Build new classrooms 11 1 In Progress 10 Develop course options 3 8, 9 Open FIGURE 3-6 Work Breakdown Structure Task Duration Number Task Name (in weeks) Dependency Status project, the more important it becomes to define tasks at a low level of detail so that essential steps are not overlooked. There are two basic approaches to organizing a WBS: by SDLC phase or by product. For example, if a firm decided that it needed to develop a Web site, the firm could create a WBS based on the SDLC: planning, analysis, design, and implementation. In this case, a typical task that would take place during planning would be feasibility analysis. This task would be broken down into the different types of feasibility analysis: technical, economic, and organizational. Each of these would be further broken down into a set of subtasks. Alternatively, the firm could organize the workplan along the lines of the different products to be developed. For example, in the case of a Web site, the products could include applets, application servers, database servers, the various sets of Web pages to be designed, a site map, and so on. Then these would be further decomposed into the different tasks associated with the phases of the SDLC. As described previously, Figure 3-6 depicts the tasks necessary for creating a new IT training class. Either way, once the overall structure is determined, tasks are identified and included in the WBS of the workplan. We return to the topic of WBS and their use in iterative planning later in this chapter. The Project Workplan The project workplan is the mechanism that is used to manage the tasks that are listed in the work breakdown structure. It is the project manager’s primary tool for managing the project. Using it, the project manager can tell if the project is ahead or behind schedule, how well the project was estimated, and what changes need to be made to meet the project deadline. Basically, the workplan is a table that lists all the tasks in the WBS, along with impor- tant task information, such as the people who are assigned to perform the tasks, the actual hours that the tasks took, and the variances between estimated and actual completion times (see Figure 3-6). At a minimum, the information should include the duration of the task, the current statuses of the tasks (i.e., open, complete), and the task dependencies, which occur when one task cannot be performed until another task is completed. For example, Figure 3-6 shows that incorporating changes to the survey (task 7.4) takes a week to perform, but it cannot occur until after the survey is reviewed (task 7.2) and pilot tested (task 7.3). Key milestones, or important dates, are also identified on the workplan. Presentations to the approval committee, the start of end user training, a company retreat, and the due date of the system prototype are the types of milestones that may be important to track. Gantt Chart A Gantt chart is a horizontal bar chart that shows the same task information as the project workplan but in a graphical way. Sometimes a picture really is worth a thousand words, and the Gantt chart can communicate the high-level status of a project much faster and easier than the workplan. Creating a Gantt chart is simple and can be done using a spreadsheet package, graphics software (e.g., Microsoft VISIO), or a project management package. First, tasks are listed as rows in the chart, and time is listed across the top in increments based on the needs of the projects (see Figure 3-7). A short project may be divided into hours or days; whereas, a medium-sized project may be represented using weeks or months. Horizontal bars are drawn to represent the duration of each task; the bar’s begin- ning and end mark exactly when the task will begin and end. As people work on tasks, the appropriate bars are filled in proportionately to how much of the task is finished. Too many tasks on a Gantt chart can become confusing, so it’s best to limit the number of tasks to around twenty or thirty. If there are more tasks, break them down into subtasks and create Gantt charts for each level of detail. Creating and Managing the Workplan 79 There are many things a project manager can see by quickly looking at a Gantt chart. In addition to seeing how long tasks are and how far along they are, the project manager also can tell which tasks are sequential, which tasks occur at the same time, and which tasks overlap in some way. He or she can get a quick view of tasks that are ahead of schedule and behind schedule by drawing a vertical line on today’s date. If a bar is not filled in and is to the left of the line, that task is behind schedule. There are a few special notations that can be placed on a Gantt chart. Project mile- stones are shown using upside-down triangles or diamonds. Arrows are drawn between the task bars to show task dependencies. Sometimes, the names of people assigned to each task are listed next to the task bars to show what human resources have been allo- cated to the tasks. 80 Chapter 3 Project Management ID 1 2 3 4 5 Identify vendors Review training materials Compare vendors Negotiate with vendors Develop communications information Disseminate information Create and administer survey Analyze results and choose Build new classroom Develop course options Budget Meeting Software Installation 6 7 8 9 10 11 12 2 wks Wed 1/1/10 Wed 1/1/10 Wed 2/12/10 Wed 2/26/10 Wed 1/15/10 Wed 2/12/10 Wed 2/26/10 Wed 3/26/10 Wed 1/15/10 Wed 4/9/10 Wed 1/15/10 Tue 4/1/10 6 wks Barbara Barbara Barbara Alan Alan Alan Alan Alan David D 2 wks 3 wks 4 wks 2 wks 4 wks 2 wks 11 wks 3 wks 2 3 1 5 6 4, 7 1 8, 9 1 day 1 day Task Name Duration Start Tue 1/14/10 Tue 2/11/10 Tue 2/25/10 Tue 3/18/10 Tue 2/11/10 Tue 2/25/10 Tue 3/25/10 Tue 4/8/10 Tue 4/1/10 Tue 4/29/10 Wed 1/15/10 Tue 4/1/10 Finish 12/29 1/5 1/12 1/15 4/1 1/19 1/26 2/2 2/9 2/16 2/23 3/2 3/9 3/16 3/23 3/30 4/6 4/13 4/20 4/27 Prede January February March April M FIGURE 3-7 Gantt Chart Pert Chart A second graphical way to look at project workplan information is the PERT chart, which lays out the project tasks in a flowchart (see Figure 3-8). PERT, which stands for program evaluation and review technique, is a network analysis technique that can be used when the individual task time estimates are fairly uncertain. Instead of simply putting a point esti- mate for the duration estimate, PERT uses three time estimates: optimistic, most likely, and a pessimistic. It then combines the three estimates into a single weighted average estimate using the following formula: PERT weighted average ϭ optimistic estimate ϩ (4 * most likely estimate) + pessimistic estimate 6 Creating and Managing the Workplan 81 Identify vendors 1 Wed 1/1/10 2 wks Tue 1/14/10 Build new classroom 9 Wed 1/15/10 11 wks Tue 4/1/10 Compare vendors 3 Wed 2/12/10 2 wks Tue 2/25/10 Negotiate with vendors 4 Wed 2/26/10 3 wks Tue 3/18/10 Review training materials 2 Wed 1/1/10 6 wks Tue 2/11/10 Develop communications Information 5 Wed 1/15/10 4 wks Tue 2/11/10 Budget meeting 11 Wed 1/15/10 1 day Wed 1/15/10 Software installation 12 Tue 4/1/10 1 day Tue 4/1/10 Disseminate information 6 Wed 2/12/10 2 wks Tue 2/25/10 Create and administer survey 7 Wed 2/26/10 4 wks Tue 3/25/10 Analyze results and choose vendor 8 Wed 3/26/10 2 wks Tue 4/8/10 Develop course options 10 Wed 4/9/10 3 wks Tue 4/29/10 FIGURE 3-8 Pert Chart The PERT chart is drawn as a node-and-arc type of graph that shows time estimates in the nodes and task dependencies on the arcs. Each node represents an individual task, and a line connecting two nodes represents the dependency between two tasks. Partially completed tasks are usually displayed with a diagonal line through the node, and completed tasks con- tain crossed lines. Milestone tasks are emphasized in some way; in Figure 3-8, for example, the milestone tasks have solid blue borders. PERT charts are the best way to communicate task dependencies because they lay out the tasks in the order in which they need to be completed. The critical path method (CPM) simply allows the identification of the critical path in the network. The critical path is the longest path from the project inception to completion. The critical path shows all the tasks that must be completed on schedule for a project as a whole to finish on schedule. If any tasks on the critical path take longer than expected, the entire project will fall behind. Each task on the critical path is a critical task, and they are usually depicted in a unique way; in Figure 3-8 they are shown with double borders. CPM can be used with or without PERT. The benefit of using project management software packages such as Microsoft Project is that the workplan can be input once, and then the software can display the information in many different formats. The user can toggle between the workplan, a Gantt chart, and a PERT chart, depending on project management needs. Refining Estimates The estimates that are produced during planning need to be refined as the project pro- gresses. This does not mean that estimates were poorly done at the start of the project; rather, it is virtually impossible to develop an exact assessment of the project’s schedule before the analysis and design phases are conducted. A project manager should expect to be satisfied with broad ranges of estimates that become more and more specific as the project’s product becomes better defined. In many respects, estimating what an IS development project will cost, how long it will take, and what the final system will actually do follows a hurricane model. When storms and hurricanes first appear in the Atlantic or Pacific, forecasters watch their behavior and, on the basis of minimal information about them (but armed with lots of data on previous storms), attempt to predict when and where the storms will hit and what damage they will do when they arrive. As storms move closer to North America, forecasters refine their tracks and develop better predictions about where and when they are most likely to hit and their force when they do. The predictions become more and more accurate as the storms approach a coast, until they finally arrive. In planning, when a system is first requested, the project sponsor and project manager attempt to predict how long the SDLC will take, how much it will cost, and what it will ulti- mately do when it is delivered (i.e., its functionality). However, the estimates are based on very little knowledge of the system. As the system moves into the analysis, more informa- tion is gathered, the system concept is developed, and the estimates become even more accurate and precise. As the system moves closer to completion, the accuracy and precision increase, until the final system is delivered (see Figure 3-9). According to one of the leading experts in software development,5 a well-done project plan (prepared at the end of planning) has a 100 percent margin of error for project cost and a 25 percent margin of error for schedule time. In other words, if a carefully done pro- ject plan estimates that a project will cost $100,000 and take twenty weeks, the project will actually cost between $0 and $200,000 and take between fifteen and twenty-five weeks. Figure 3-10 presents typical margins of error for other stages in the project. It is important to note that these margins of error apply only to well-done plans; a plan developed without much care has a much greater margin of error. What happens if you overshoot an estimate (e.g., analysis ends up lasting two weeks longer than expected)? There are a number of ways to adjust future estimates. If the project team finishes a step ahead of schedule, most project managers shift the deadlines sooner by the same amount but do not adjust the promised completion date. The challenge, 82 Chapter 3 Project Management 5 Barry W. Boehm et al., “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0,” in J. D. Arthur and S. M. Henry (eds.), Annals of Software Engineering: Special Volume on Software Process and Product Measurement (Amsterdam: J. C. Baltzer AG Science Publishers, 1995). however, occurs when the project team is late in meeting a scheduled date. Three possi- ble responses to missed schedule dates are presented in Figure 3-11. If an estimate proves too optimistic early in the project, planners should not expect to make up for lost time— very few projects end up doing this. Instead, they should change future estimates to include an increase similar to the one that was experienced. For example, if the first phase was completed 10 percent over schedule, planners should increase the rest of their estimates by 10 percent. Scope Management An analyst may assume that a project will be safe from scheduling problems because he or she carefully estimated and planned the project up front. However, the most common rea- son for schedule and cost overruns—scope creep—occurs after the project is underway. Scope creep happens when new requirements are added to the project after the original project scope was defined and “frozen.”It can happen for many reasons: users may suddenly Creating and Managing the Workplan 83 Planning (project plan) Size of circle indicates estimated cost Estimated schedule time Analysis (system proposal) Design (system specification) Implementation (system installation) Project schedule time (Time needed to complete project) Stage at which estimate is made FIGURE 3-9 Hurricane Model Planning System request 400 60 Project plan 100 25 Analysis System proposal 50 15 Design System specifications 25 10 Source: Barry W. Boehm et al., “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0,” in J. D. Arthur and S. M. Henry (eds.) Annals of Software Engineering Special Volume on Software Process and Product Measurement (Amsterdam: J. C. Baltzer AG Science Publishers, 1995). Typical Margins of Error for Well-Done Estimates Phase Deliverable Cost (%) Schedule Time (%) FIGURE 3-10 Margins of Error in Cost and Time Estimates understand the potential of the new system and realize new functionality that would be use- ful; developers may discover interesting capabilities to which they become very attached; a senior manager may decide to let this system support a new strategy that was developed at a recent board meeting. Unfortunately, after the project begins, it becomes increasingly difficult to address changing requirements. The ramifications of change become more extensive, the focus is removed from original goals, and there is at least some impact on cost and schedule. There- fore, the project manager plays a critical role in managing this change to keep scope creep to a minimum. The keys are to identify the requirements as well as possible in the beginning of the project and to apply analysis techniques effectively. For example, if needs are fuzzy at the project’s onset, a combination of intensive meetings with the users and prototyping would allow users to “experience” the requirements and better visualize how the system could sup- port their needs. In fact, the use of meetings and prototyping has been found to reduce scope creep to less than 5 percent on a typical project. Of course, some requirements may be missed no matter what precautions are taken, but several practices can help control additions to the task list. First, the project manager should allow only absolutely necessary requirements to be added after the project begins. Even at that point, members of the project team should carefully assess the ramifications of the addition and present the assessment to the users. For example, it may require two more person-months of work to create a newly defined report, which would throw off the entire project deadline by several weeks. Any change that is 84 Chapter 3 Project Management If you assume the rest of the project is Do not change schedule. High risk simpler than the part that was late and is also simpler than believed when the original schedule estimates were made, you can make up lost time. If you assume the rest of the project is Increase the entire schedule by the Moderate risk simpler than the part that was late total amount of time that you are and is no more complex than the behind (e.g., if you missed the original estimate assumed, you can’t scheduled date by two weeks, move make up the lost time, but you will the rest of the schedule dates to two not lose time on the rest of the weeks later). If you included padded project. time at the end of the project in the original schedule, you may not have to change the promised system delivery date; you’ll just use up the padded time. If you assume that the rest of the Increase the entire schedule by the Low risk project is as complex as the part percentage of weeks that you are that was late (your original estimates behind (e.g., if you are two weeks too optimistic), then all the scheduled late on part of the project that was dates in the future underestimate the supposed to take eight weeks, you real time required by the same need to increase all remaining percentage as the part that was late. time estimates by 25 percent). If this moves the new delivery date beyond what is acceptable to the project sponsor, the scope of the project must be reduced. Assumptions Actions Level of Risk FIGURE 3-11 Possible Actions When a Schedule Date Is Missed implemented should be carefully tracked so that an audit trail exists to measure the change’s impact. Sometimes changes cannot be incorporated into the present system even though they truly would be beneficial. In this case, these additions to scope should be recorded as future enhancements to the system. The project manager can offer to provide functionality in future releases of the system, thus getting around telling someone no. Timeboxing Another approach to scope management is a technique called timeboxing. Up until now, we have described task-oriented projects. In other words, we have described projects that have a schedule driven by the tasks that need to be accomplished, so the greater number of tasks and requirements, the longer the project will take. Some companies have little patience for development projects that take a long time, and these companies take a time- oriented approach that places meeting a deadline above delivering functionality. Think about the use of word processing software. For 80 percent of the time, only 20 percent of the features, such as the spelling checker, boldfacing, and cutting and past- ing, are used. Other features, such as document merging and creation of mailing labels, may be nice to have, but they are not a part of day-to-day needs. The same goes for other software applications; most users rely on only a small subset of their capabilities. Ironically, most developers agree that typically 75 percent of a system can be provided relatively quickly, with the remaining 25 percent of the functionality demanding most of the time. To resolve this incongruency, the technique of timeboxing has become quite popular, especially when using RAD methodologies. This technique sets a fixed deadline for a pro- ject and delivers the system by that deadline no matter what, even if functionality needs to be reduced. Timeboxing ensures that project teams don’t get hung up on the final finishing touches that can drag out indefinitely, and it satisfies the business by providing a product within a relatively fast time frame. There are several steps involved in implementing timeboxing on a project (see Fig- ure 3-12). First, set the date of delivery for the proposed goals. The deadline should not be impossible to meet, so it is best to let the project team determine a realistic due date. Next, build the core of the system to be delivered; you will find that timeboxing helps create a sense of urgency and helps keep the focus on the most important features. Because the schedule is absolutely fixed, functionality that cannot be completed needs to be postponed. It helps if the team prioritizes a list of features beforehand to keep track of what functionality the users absolutely need. Quality cannot be compromised, regardless of other constraints, so it is important that the time allocated to activities is not shortened unless the requirements are changed (e.g., don’t reduce the time allocated to testing without reducing features). At the end of the time period, a high-quality sys- tem is delivered, but it is likely that future iterations will be needed to make changes and enhancements. In that case, the timeboxing approach can be used once again. Creating and Managing the Workplan 85 1. Set the date for system delivery. 2. Prioritize the functionality that needs to be included in the system. 3. Build the core of the system (the functionality ranked as most important). 4. Postpone functionality that cannot be provided within the time frame. 5. Deliver the system with core functionality. 6. Repeat steps 3 through 5 to add refinements and enhancements. FIGURE 3-12 Steps for Timeboxing Evolutionary Work Breakdown Structures and Iterative Workplans Because object-oriented systems approaches to systems analysis and design support incre- mental and iterative development, any project planning approach for object-oriented sys- tems development also requires an incremental and iterative process. In the description of the enhanced Unified Process in Chapter 1, the development process was organized around iterations, phases, and workflows. In many ways, a workplan for an incremental and itera- tive development process is organized in a similar manner. For each iteration, there are dif- ferent tasks executed on each workflow. This section describes an incremental and iterative process using evolutionary WBSs for project planning that can be used with objects-oriented systems development. According to Royce,6 most approaches to developing conventional WBSs tend to have three underlying problems: 1. They tend to be focused on the design of the information system being developed. As such, the creation of the WBS forces the premature decomposition of the system design and the tasks associated with creating the design of the system. Where the problem domain is well understood, tying the structure of the work- plan to the product to be created makes sense. However, in cases where the problem domain is not well understood, the analyst must commit to the archi- tecture of the system being developed before the requirements of the system are fully understood. 2. They tend to force too many levels of detail very early on in the SDLC for large projects or they tend to allow too few levels of detail for small projects. Because the primary purpose of a WBS is to allow cost estimation and scheduling to take place, in conventional approaches to planning, the WBS must be done correctly and completely at the beginning of the SDLC. To say the least, this is 86 Chapter 3 Project Management Travelers Insurance Company of Hartford Connecticut has adopted agile development methodologies. The insur- ance field can be competitive, and Travelers wanted to have the shortest “time to implement” in the field. Travelers set up development teams of six people: two systems ana- lysts, two representatives from the user group (such as claim services), a project manager, and a clerical support person. In the agile approach, the users are physically assigned to the development team for the project. Although at first it might seem that the users might just be sitting around drinking coffee and watching the develop- ers come up with appropriate software solutions, that is not the case. The rapport that is developed within the team allows for instant communication. The interaction is very deep and profound. The resulting software product is delivered quickly—and generally with all the features and nuances that the users wanted. Questions 1. Could this be done differently, such as by using JAD sessions or having the users review the program on a weekly basis rather than taking the users away from their real job to work on development? 2. What mind-set does an analyst need to work on such an approach? 3-C Faster Products to Market—with ITCONCEPTS IN ACTION 6 Walker Royce, Software Project Management: A Unified Framework (Reading, MA: Addison-Wesley, 1998). a very difficult task to accomplish with any degree of validity. In such cases, it is no wonder that cost and schedule estimation for many information systems development projects tend to be wildly inaccurate. 3. Because they are project specific, they are very difficult to compare across projects. This leads to ineffective learning across the organization. Without some standard approach to create WBSs, it is difficult for project managers to learn from previ- ous projects managed by others. This tends to encourage the “reinventing of the wheel” and allows managers to make the same mistakes that previous managers have made. Evolutionary WBSs allow the analyst to address all three problems by allowing the development of an iterative workplan. First, evolutionary WBSs are organized in a stan- dard manner across all projects: by workflows, phases, and then tasks. This decouples the structure of an evolutionary WBS from the structure of the design of the product. This prevents prematurely committing to a specific architecture of a new system. Second, evo- lutionary WBSs are created in an incremental and iterative manner. The first evolutionary WBS is typically only done for the aspects of the project understood by the analyst. Later on, as the analyst understands more about the evolving development process, more details are added to the WBS. This encourages a more realistic view of both cost and schedule estimation. Third, because the structure of an evolutionary WBS is not tied to any specific project, evolutionary WBSs enable the comparison of the current project to earlier projects. This supports learning from past successes and failures. In the case of the enhanced Unified Process, the workflows are the major points listed in the WBS. Next, each workflow is decomposed along the phases of the enhanced Unified Process. After that, each phase is decomposed along the tasks that are to be completed to create the deliverables associated with the phase. The tasks listed for each workflow depend upon the level of activity on the workflow during each phase (see Figure 1-11). For example, typical activities for the inception phase of the requirements workflow would be to interview stakeholders, develop a vision document, and develop use cases, whereas there are probably no tasks associated with the inception phase of the operations and support workflow. The template for the first two levels of an evolutionary WBS for the enhanced Unified Process would look like Figure 3-13. As each iteration through the development process is completed, additional tasks are added to the WBS to reflect the current understanding of the remaining tasks to be completed (i.e., the WBS evolves along with the evolving information system). As such, the workplan is developed in an incre- mental and iterative manner. 7 A sample evolutionary WBS for the planning of the incep- tion phase of the enhanced Unified Process, based on Figures 1-11 and 3-13, is shown in Figure 3-14. Notice that the last two tasks for the project management workflow are “cre- ate workplan for first iteration of the elaboration phase” and “assess the inception phase;” that is, the last two things to do are to plan for the next iteration in the development of the evolving system and to assess the current iteration. As the project moves through the later phases, each workflow has tasks added. For example, the analysis workflow will have the creation of the functional, structural, and behavioral models created during the elab- oration phase. This approach allows the workplan to evolve through the iterations and phases of the development process. Creating and Managing the Workplan 87 7 A set of good sources that help explain this approach are Phillippe Krutchen, “Planning an Iterative Project,” The Rational Edge (October 2002); and Eric Lopes Cordoza and D.J. de Villiers, “Project Planning Best Practices,” The Rational Edge (August 2003). 88 Chapter 3 Project Management I. Business Modeling a. Inception 1. Understand current business situation 0.50 days 2. Uncover business process problems 0.25 days 3. Identify potential projects 0.25 days b. Elaboration c. Construction d. Transition e. Production II. Requirements a. Inception 1. Identify appropriate requirements analysis technique 0.25 days 2. Identify appropriate requirements gathering techniques 0.25 days 3. Identify functional and nonfunctional requirements II.a.1, II.a.2 A. Perform JAD sessions 3 days B. Perform document analysis 5 days II.a.3.A Duration Dependency I. Business Modeling a. Inception b. Elaboration c. Construction d. Transition e. Production II. Requirements a. Inception b. Elaboration c. Construction d. Transition e. Production III. Analysis a. Inception b. Elaboration c. Construction d. Transition e. Production IV. Design a. Inception b. Elaboration c. Construction d. Transition e. Production V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production VI. Test a. Inception b. Elaboration c. Construction d. Transition e. Production VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production VIII. Configuration and Change Management a. Inception b. Elaboration c. Construction d. Transition e. Production IX. Project Management a. Inception b. Elaboration c. Construction d. Transition e. Production X. Environment a. Inception b. Elaboration c. Construction d. Transition e. Production XI. Operations and Support a. Inception b. Elaboration c. Construction d. Transition e. Production XII. Infrastructure Management a. Inception b. Elaboration c. Construction d. Transition e. Production FIGURE 3-13 Evolutionary WBS Template for the Enhanced Unified Process FIGURE 3-14 Evolutionary WBS for a Single Iteration–based Inception Phase Creating and Managing the Workplan 89 C. Conduct interviews II.a.3.A 1. Interview project sponsor 0.5 days 2. Interview inventory system contact 0.5 days 3. Interview special order system contact 0.5 days 4. Interview ISP contact 0.5 days 5. Interview CD Selection Web contact 0.5 days 6. Interview other personnel 1 day D. Observe retail store processes 0.5 days II.a.3.A 4. Analyze current systems 4 days II.a.1, II.a.2 5. Create requirements definition II.a.3, II.a.4 A. Determine requirements to track 1 day B. Compile requirements as they are elicited 5 days II.a.5.A C. Review requirements with sponsor 2 days II.a.5.B b. Elaboration c. Construction d. Transition e. Production III. Analysis a. Inception 1. Identify business processes 3 days 2. Identify use cases 3 days III.a.1 b. Elaboration c. Construction d. Transition e. Production IV. Design a. Inception 1. Identify potential classes 3 days III.a b. Elaboration c. Construction d. Transition e. Production V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production VI. Test a. Inception b. Elaboration c. Construction d. Transition e. Production Duration Dependency FIGURE 3-14 Continued 90 Chapter 3 Project Management VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production VIII. Configuration and Change Management a. Inception 1. Identify necessary access controls for developed artifacts 0.25 days 2. Identify version control mechanisms for developed artifacts 0.25 days b. Elaboration c. Construction d. Transition e. Production IX. Project Management a. Inception 1. Create workplan for the inception phase 1 day 2. Create system request 1 day 3. Perform feasibility analysis IX.a.2 A. Perform technical feasibility analysis 1 day B. Perform economic feasibility analysis 2 days C. Perform organizational feasibility analysis 2 days 4. Identify project size 0.50 days IX.a.3 5. Identify staffing requirements 0.50 days IX.a.4 6. Compute cost estimate 0.50 days IX.a.5 7. Create workplan for first iteration of the elaboration phase 1 day IX.a.1 8. Assess inception phase 1 day I.a, II.a, III.a IV.a, V.a, VI.a VII.a, VIII.a, IX.a, X.a, XI.a XII.a b. Elaboration c. Construction d. Transition e. Production X. Environment a. Inception 1. Acquire and install CASE tool 0.25 days 2. Acquire and install programming environment 0.25 days 3. Acquire and install configuration and change management tools 0.25 days 4. Acquire and install project management tools 0.25 days b. Elaboration c. Construction Duration Dependency FIGURE 3-14 Continued Staffing the Project 91 d. Transition e. Production XI. Operations and Support a. Inception b. Elaboration c. Construction d. Transition e. Production XII. Infrastructure Management a. Inception 1. Identify appropriate standards and enterprise models 0.25 days 2. Identify reuse opportunities, such as patterns, frameworks, and libraries 0.50 days 3. Identify similar past projects 0.25 days b. Elaboration c. Construction d. Transition e. Production Duration Dependency STAFFING THE PROJECT Staffing the project includes determining how many people should be assigned to the pro- ject, matching people’s skills with the needs of the project, motivating them to meet the project’s objectives, and minimizing the conflict that will occur over time. The deliverables for this part of project management are a staffing plan, which describes the number and kinds of people who will work on the project, the overall reporting structure, and the pro- ject charter, which describes the project’s objectives and rules. Staffing Plan The first step to staffing is determining the average number of staff needed for the project. To calculate this figure, divide the total person-months of effort by the optimal schedule. So to complete a forty-person-month project in ten months, a team should have an aver- age of four full-time staff members, although this may change over time as different spe- cialists enter and leave the team (e.g., business analysts, programmers, technical writers). Many times, the temptation is to assign more staff to a project to shorten the project’s length, but this is not a wise move. Adding staff resources does not translate into increased productivity; staff size and productivity share a disproportionate relationship, mainly because it is more difficult to coordinate a large number of staff members. The more a team grows, the more difficult it becomes to manage. Imagine how easy it is to work on a two-person project team: the team members share a single line of communication. But adding two people increases the number of communication lines to six, and greater increases lead to more dramatic gains in communication complexity. Figure 3-15 illustrates the impact of adding team members to a project team. One way to reduce efficiency losses on teams is to understand the complexity that is cre- ated in numbers and to build in a reporting structure that tempers its effects. The rule of thumb is to keep team sizes of fewer than eight to ten people; therefore, if more people are needed, FIGURE 3-14 Continued 92 Chapter 3 Project Management FIGURE 3-15 Increasing Complexity with Larger Teams Two-person team Four-person team Eight-person teamSix-person team create subteams. In this way, the project manager can keep the communication effective within small teams, which, in turn, communicate to contact at a higher level in the project. After the project manager understands how many people are needed for the project, he or she creates a staffing plan that lists the roles that are required for the project and the proposed reporting structure for the project. Typically, a project will have one project manager, who oversees the overall progress of the development effort, with the core of the team comprising the various types of analysts described in Chapter 1. A functional lead is usually assigned to manage a group of analysts, and a technical lead oversees the progress of a group of programmers and more technical staff members. There are many structures for project teams; Figure 3-16 illustrates one possible con- figuration of a project team. After the roles are defined and the structure is in place, the project manager needs to think about which people can fill each role. Often, one person fills more than one role on a project team. When you make assignments, remember that people have technical skills and interper- sonal skills, and both are important on a project. Technical skills are useful when working with technical tasks (e.g., programming in Java) and in trying to understand the various roles that technology plays in the particular project (e.g., how a Web server should be configured on the basis of a projected number of hits from customers). Interpersonal skills, on the other hand, include interpersonal and communication abilities that are used when dealing with business users, senior management executives, and other members of the project team. They are particularly critical when performing the requirements- gathering activities and when addressing organizational feasibility issues. Each project will require unique technical and interpersonal skills. For example, a Web-based project may require Internet experience or Java programming knowledge, whereas a highly controversial project may need analysts who are particularly adept at managing political or volatile situations. Ideally, project roles are filled with people who have the right skills for the job. How- ever, the people who fit the roles best may not be available; they may be working on other projects, or they may not exist in the company. Therefore, assigning project team members really is a combination of finding people with the appropriate skill sets and finding people who are available. When the skills of the available project team members do not match what is actually required by the project, the project manager has several options to improve the situation. First, people can be pulled off other projects, and resources can be shuffled around. This is the most disruptive approach from the organization’s perspective. Another approach is to use outside help—such as a consultant or contractor—to train team mem- bers and start them off on the right foot. Training classes are usually available for both tech- nical and interpersonal instruction if time is available. Mentoring may also be an option; a project team member can be sent to work on another similar project so that he or she can return with skills to apply to the current job. Staffing the Project 93 Functional lead Project manager ProgrammerAnalyst Analyst Analyst Programmer Technical lead FIGURE 3-16 Possible Reporting Structure Now it is time to staff the project that was described in Your Turn 3-1. On the basis of the effort required for the project (Your Turn 3-2), how many people will be needed on the project? Given this number, select classmates who will work with you on your project. Questions 1. What roles will be needed to develop the project? List them and write short descriptions for each of these roles, almost as if you had to advertise the posi- tions in a newspaper. 2. Which roles will each classmate perform? Will some people perform multiple roles? 3. What will the reporting structure be for the project? 3-3 Staffing PlanYOUR TURN Motivation Assigning people to tasks isn’t enough; project managers need to motivate the people to make the project a success. Motivation has been found to be the number one influence on people’s performance,8 but determining how to motivate the team can be quite difficult. You may think that good project managers motivate their staff by rewarding them with money and bonuses, but most project managers agree that this is the last thing that should be done. The more often managers reward team members with money, the more they expect it—and most times monetary motivation won’t work. Assuming that team members are paid a fair salary, technical employees on project teams are much more motivated by recognition, achievement, the work itself, responsibility, advancement, and the chance to learn new skills.9 If a manager feels a need to give some kind of reward for motivational purposes, he or she might try a pizza or free dinner or even a kind letter or award. These rewards often have much more effective results than money. Figure 3-17 lists some other motivational don’ts to avoid to ensure that motivation on the project is as high as possible. Handling Conflict The third component of staffing is organizing the project to minimize conflict among group members. Group cohesiveness (the attraction that members feel to the group and to other members) contributes more to productivity than do project members’ individual capabili- ties or experiences.10 Clearly defining the roles on the project and holding team members 94 Chapter 3 Project Management 8 Barry W. Boehm, Software Engineering Economics (Englewood Cliffs, NJ: Prentice Hall, 1981). One of the best books on managing project teams is that by Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (New York: Dorset House, 1987). 9 F. H. Hertzberg, “One More Time: How Do You Motivate Employees?” Harvard Business Review (January– February 1968). 10 B. Lakhanpal, “Understanding the Factors Influencing the Performance of Software Development Groups: An Exploratory Group-Level Analysis,” Information and Software Technology 35, no. 8 (1993): 468–473. Assign unrealistic deadlines Few people will work hard if they realize that a deadline is impossible to meet. Ignore good efforts People will work harder if they feel like their work is appreciated. Often, all it takes is public praise for a job well done. Create a low-quality product Few people can be proud of working on a project that is of low quality. Give everyone on the project If everyone is given the same reward, then high-quality a raise people will believe that mediocrity is rewarded—and they will resent it. Make an important decision Buy-in is very important. If the project manager needs to without the team’s input make a decision that greatly affects the members of her team, she should involve them in the decision-making process. Maintain poor working conditions A project team needs a good working environment or motivation will go down the tubes. This includes lighting, desk space, technology, privacy from interruptions, and reference resources. Source: Steve McConnell, Adapted Rapid Development (Redmond, WA: Microsoft Press, 1996). Don’ts Reasons FIGURE 3-17 Motivational Don’ts accountable for their tasks is a good way to begin mitigating potential conflict on a project. Some project managers develop a project charter, which lists the project’s norms and ground rules. For example, the charter may describe when the project team should be at work, when staff meetings will be held, how the group will communicate with each other, and the pro- cedures for updating the workplan as tasks are completed. Figure 3-18 lists additional tech- niques that can be used at the start of a project to keep conflict to a minimum. Staffing the Project 95 Some animals are extremely valuable. For centuries, horse thieves have stolen horses, so now most horses have tattoos in their mouths. Likewise, purebred pets, such as dog show winners, are valuable animals. What if there were a better way to positively identify valuable animals? Radio frequency identification (or RFID) has been used for many years in airplanes and on toll roads (like EZPass and FaneLane in the United States) as well as in libraries so that books and materials are not taken out of the library without being checked out. With RFID, a low- frequency radio transmitter, when bombarded with a radio wave, replies with a unique signal. Some animal owners have inserted RFID chips into their pets’ shoulders so that they can be identified. The code is unique and cannot be changed. It would be possible to track a stolen race horse if the horse came into range of an RFID device. Likewise, a pet shop or a veterinarian could identify a valuable pet. Questions 1. If you were working for a state consumer-protection agency, what requirements might you place on pet shops to ensure that animals for sale have not been stolen? 2. What technological requirements might be needed in the system proposal? 3. What ethical issues might be involved? 4. If your system project team did not have the correct technical background, what might you do? 3-D RFID—Promising Technology?CONCEPTS IN ACTION • Clearly define plans for the project. • Make sure the team understands how the project is important to the organization. • Develop detailed operating procedures and communicate these to the team members. • Develop a project charter. • Develop schedule commitments ahead of time. • Forecast other priorities and their possible impact on project. Source: H. J. Thamhain and D. L. Wilemon, “Conflict Management in Project Life Cycles,” Sloan Management Review (Spring 1975). FIGURE 3-18 Conflict-Avoidance Strategies Get together with several of your classmates and pretend that you are all staffed on the project described in Your Turn 3-1. Discuss what would most motivate each of you to perform well on the project. List three potential sources of conflict that could surface as you work together. Question Develop a project charter that lists five rules that all team members will need to follow. How might these rules help avoid potential team conflict? 3-4 Project CharterYOUR TURN COORDINATING PROJECT ACTIVITIES Like all project management responsibilities, the act of coordinating project activities con- tinues throughout the entire project, until a system is delivered to the project sponsor and end users. This step includes putting efficient development practices in place and mitigating risk. These activities occur over the course of the entire SDLC, but it is at this point in the project when the project manager needs to put them in place. Ultimately, these activities ensure that the project stays on track and that the chance of failure is kept at a minimum. Case Tools Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process. Some CASE software packages are used primarily during the analysis phase to create integrated diagrams of the system and to store information regarding the system components (often called upper CASE), whereas others are design- phase tools that create the diagrams and then generate code for database tables and system functionality (often called lower CASE). Integrated CASE, or I-CASE, contains functionality found in both upper CASE and lower CASE tools in that it supports tasks that happen throughout the SDLC. CASE comes in a wide assortment of flavors in terms of complexity and functionality, and there are many good programs available in the marketplace (e.g., Visible Analyst Workbench, Oracle Designer/2000, Rational Rose, Logic Works suite). The benefits of using CASE are numerous. With CASE tools, tasks can be completed and altered much faster, development information is centralized, and information is illustrated through diagrams, which are typically easier to understand. Potentially, CASE can reduce maintenance costs, improve software quality, and enforce discipline, and some project teams even use CASE to assess the magnitude of changes to the project. Of course, like anything else, CASE should not be considered a silver bullet for project development. The advanced CASE tools are complex applications that require significant training and experience to achieve real benefits. Often, CASE serves only as a glorified dia- gramming tool. Our experience has shown that CASE is a helpful way to support the com- munication and sharing of project diagrams and technical specifications—as long as it is used by trained developers who have applied CASE on past projects. The central component of any CASE tool is the CASE repository, otherwise known as the information repository or data dictionary. The CASE repository stores the diagrams and other project information, such as screen and report designs, and it keeps track of how the diagrams fit together. For example, most CASE tools will warn you if you place a field on a screen design that doesn’t exist in your data model. As the project evolves, project team members perform their tasks using CASE. As you read through the textbook, we will indi- cate when and how the CASE tool can be used so that you can see how CASE supports the project tasks. 96 Chapter 3 Project Management Select a CASE tool—either one that you will use for class, a program that you own, or a tool that you can examine over the Web. Create a list of the capabilities that are offered by the CASE tool. Question Would you classify the CASE as upper CASE, lower CASE, or I-CASE? Why? 3-5 Computer-Aided Software Engineering Tool AnalysisYOUR TURN Standards Members of a project team need to work together, and most project management soft- ware and CASE tools provide access privileges to everyone working on the system. When people work together, however, things can get pretty confusing. To make matters worse, people sometimes are reassigned in the middle of a project. It is important that their pro- ject knowledge does not leave with them and that their replacements can get up to speed quickly. One way to make certain that everyone is performing tasks in the same way and fol- lowing the same procedures is to create standards that the project team must follow. Standards can range from formal rules for naming files to forms that must be completed when goals are reached to programming guidelines. Figure 3-19 shows some examples of the types of standards that a project may create. When a team forms standards and then follows them, the project can be completed faster because task coordination becomes less complex. Standards work best when they are created at the beginning of each major phase of the project and communicated clearly to the entire project team. As the team moves forward, new standards are added when necessary. Some standards (e.g., file naming conventions, status Coordinating Project Activities 97 FIGURE 3-19 A Sampling of Project Standards Documentation standards The date and project name should appear as a header on all documentation. All margins should be set to 1 inch. All deliverables should be added to the project binder and recorded in its table of contents. Coding standards All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code. Indentation should be used to indicate loops, if-then-else statements, and case statements. On average, every program should include one line of comments for every five lines of code. Procedural standards Record actual task progress in the work plan every Monday morning by 10 AM. Report to project update meeting on Fridays at 3:30 PM. All changes to a requirements document must be approved by the project manager. Specification requirement standards Name of program to be created Description of the program’s purpose Special calculations that need to be computed Business rules that must be incorporated into the program Pseudocode Due date User interface design standards Labels will appear in boldface text, left-justified, and followed by a colon. The tab order of the screen will move from top left to bottom right. Accelerator keys will be provided for all updatable fields. Types of Standards Examples reporting) are applied to the entire SDLC, whereas others (e.g., programming guidelines) are appropriate only for certain tasks. Documentation A final technique that project teams put in place during the planning phase is good docu- mentation, which includes detailed information about the tasks of the SDLC. Often, the documentation is stored in project binder(s) that contain all the deliverables and all the internal communication that takes place—the history of the project. A poor project management practice is waiting until the last minute to create documentation; this typically leads to an undocumented system that no one under- stands. In fact, many problems that companies had updating their systems to handle the year 2000 crisis were the result of the lack of documentation. Good project teams learn to document a system’s history as it evolves while the details are still fresh in their memory. The first step to setting up documentation is to get some binders and include dividers with which to separate content according to the major phases of the project. An additional divider should contain internal communication, such as the minutes from status meetings, written standards, letters to and from the business users, and a dictionary of relevant busi- ness terms. Then, as the project moves forward, the deliverables from each task can be put into the project binder with descriptions so that someone outside of the project will be able to understand it. Also, a table of contents should be kept up to date with the content that is added. Documentation takes time up front, but it is a good investment that will pay off in the long run. 98 Chapter 3 Project Management I once started on a small project (four people) in which the original members of the project team had not set up any standards for naming electronic files. Two weeks into the project, I was asked to write a piece of code that would be referenced by other files that had already been written. When I finished my piece, I had to go back to the other files and make changes to reflect my new work. The only problem was that the lead programmer decided to name the files using his initials (e.g., GG1.prg, GG2.prg, GG3.prg)—and there were more than 200 files! I spent two days opening every one of those files because there was no way to tell what their contents were. Needless to say, from then on, the team created a code for file names that provided basic information regarding the file’s contents, and they kept a log that recorded the file name, its purpose, the date of the last update, and the programmer for every file on the project. —Barbara Wixom Question Think about a program that you have written in the past. Would another programmer be easily able to make changes to it? Why or why not? 3-E Poor Naming StandardsCONCEPTS IN ACTION Managing Risk One final facet of project management is risk management, the process of assessing and addressing the risks that are associated with developing a project. Many things can cause risks: weak personnel, scope creep, poor design, and overly optimistic estimates. The pro- ject team must be aware of potential risks so that problems can be avoided or controlled well ahead of time. Typically, project teams create a risk assessment, or a document that tracks potential risks along with an evaluation of the likelihood of each risk and its potential impact on the project (Figure 3-20). A paragraph or two is also included to explain potential ways that the risk can be addressed. There are many options: the risk could be publicized, avoided, or even eliminated by dealing with its root cause. For example, imagine that a project team plans to use new technology but its members have identified a risk in the fact that its mem- bers do not have the right technical skills. They believe that tasks may take much longer to perform because of a high learning curve. One plan of attack could be to eliminate the root cause of the risk—the lack of technical experience by team members—by finding the time and resources needed to provide proper training to the team. Most project managers keep abreast of potential risks, even prioritizing them accord- ing to their magnitude and importance. Over time, the list of risks will change as some items are removed and others surface. The best project managers, however, work hard to keep risks from having an impact on the schedule and costs associated with the project. Coordinating Project Activities 99 Dawn Adams, Senior Manager with Asymetrix Consult- ing, has renamed the SDLC phases: 1. Pudding (Planning) 2. Silly Putty (Analysis) 3. Concrete (Design) 4. Touch-this-and-you’re-dead-sucker (Implementation) Adams also uses icons, such as a skull and crossbones for the implementation phase. The funny labels lend a new depth of interest to a set of abstract concepts. But her names have had another benefit. “I had one partici- pant who adopted the names wholeheartedly,” she says, “including my icons. He posted an icon on his office door for the duration of each of the phases, and he found it much easier to deal with requests for changes from the client, who could see the increasing difficulty of the changes right there on the door.” Source: Learning Technology Shorttakes 1, no. 2 (Wednesday, August 26, 1998). Question What would you do if your project sponsor demanded that an important change be made during the “touch-this- and-you’re-dead-sucker” phase? 3-F The Real Names of the SDLC PhasesCONCEPTS IN ACTION Risk Assessment RISK 1: The development of this system likely will be slowed considerably because project team members have not programmed in Java prior to this project. Likelihood of risk: High probability of risk. Potential impact on the project: This risk will probably increase the time to complete programming tasks by 50 percent. Ways to address this risk: It is very important that time and resources are allocated to up-front training in Java for the programmers who are used for this project. Adequate training will reduce the initial learning curve for Java when programming begins. Additionally, outside Java expertise should be brought in for at least some part of the early programming tasks. This person should be used to provide experiential knowledge to the project team so that JAVA-related issues (of which novice Java programmers would be unaware) are overcome. RISK 2: … FIGURE 3-20 Sample Risk Assessment APPLYING THE CONCEPTS AT CD SELECTIONS Alec Adams was very excited about managing the Internet Sales System project at CD Selec- tions, but he realized that his project team would have very little time to deliver at least some parts of the system because the company wanted the application developed in time for the holiday season. Therefore, he decided that the project should follow an enhanced Unified Process–based approach (see Figure 1-11). In this way, he could be sure that some version of the product would be in the hands of the users within several months, even if the completed system would be delivered at a later date. As project manager, Alec had to estimate the project’s size, effort, and schedule—some of his least favorite jobs because of how tough they are to do at the very beginning of a pro- ject. But he knew that the users would expect at least general ranges for a product delivery date. He began by attempting to estimate the size of the project using function points and the function point estimation worksheet in Figure 3-3. For the Web part of the system to be used by customers, he could think of four main queries (searching by artist, by CD title, by song title, and by ad hoc criteria), three input screens (selecting a CD, entering information to put 100 Chapter 3 Project Management As Seattle University’s David Umphress has pointed out, watching most organizations develop systems is like watching reruns of Gilligan’s Island. At the beginning of each episode, someone comes up with a cockamamie scheme to get off the island that seems to work for a while, but something goes wrong and the castaways find themselves right back where they started—stuck on the island. Similarly, most companies start new projects with grand ideas that seem to work, only to make a classic mis- take and deliver the project behind schedule, over bud- get, or both. Here we summarize four classic mistakes in the planning and project management aspects of the pro- ject and discuss how to avoid them: 1. Overly optimistic schedule: Wishful thinking can lead to an overly optimistic schedule that causes analysis and design to be cut short (missing key requirements) and puts intense pressure on the programmers, who produce poor code (full of bugs). Solution: Don’t inflate time estimates; instead, explicitly schedule slack time at the end of each phase to account for the variability in estimates, using the margins of error from Figure 3-10. 2. Failing to monitor the schedule: If the team does not regularly report progress, no one knows if the pro- ject is on schedule. Solution: Require team members to report progress (or the lack or progress) honestly every week. There is no penalty for reporting a lack of progress, but there are immediate sanctions for a misleading report. 3. Failing to update the schedule: When a part of the schedule falls behind (e.g., information gathering uses all the slack in item 1 plus 2 weeks), a project team often thinks it can make up the time later by working faster. It can’t. This is an early warning that the entire schedule is too optimistic. Solution: Immediately revise the schedule and inform the project sponsor of the new end date or use timeboxing to reduce functionality or move it into future versions. 4. Adding people to a late project: When a project misses a schedule, the temptation is to add more people to speed it up. This makes the project take longer because it increases coordination problems and requires staff to take time to explain what has already been done. Solution: Revise the schedule, use timeboxing, throw away bug-filled code, and add people only to work on an isolated part of the project. Source: Adapted from Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996), pp. 29–50. Avoiding Classic Planning MistakesPRACTICAL TIP Complexity Description Total Number Low Medium High Total Inputs 6 0 * 3 4 * 4 2 * 6 28 Outputs 7 2 * 4 4 * 5 1 * 7 35 Queries 8 3 * 3 4 * 4 1 * 6 31 Files 4 0 * 7 4 * 10 0 * 15 40 Program Interfaces 3 0 * 5 2 * 7 1 * 10 24 Total Unadjusted Function Points (TUFP): 158 a CD on hold, and a special-order screen), four output screens (the home page with general information, information about CDs, information about the customer’s special order, and the hold status), three files (CD information, inventory information, and customer orders), and two program interfaces (one to the company’s special-order system and one that com- municates hold information to the retail store systems). For the part of the system to be used by CD Selections staff (to maintain the marketing materials), he identified three additional inputs, three outputs, four queries, one file, and one program interface. Based on the complex- ity of each, he entered the numbers into the upper portion of the worksheet (see Figure 3-21). Based on the computation, there were 158 total unadjusted function points (TUFP). Rather than attempt to assess the complexity of the system in detail, Alec chose to use a value of 1.20 for the adjusted processing complexity (APC). He reasoned that the system was of medium complexity and that the project team had little experience with Internet- based systems. This produced a total adjusted function points (TAFP) of about 190. Converting function points into lines of code was challenging. The project would use a combination of Java (for most programs) and HTML for the Web screens. Alec decided to assume that about 75 percent of the function points would be Java and 25 percent would be HTML. Using the table in Figure 3-4, Alec estimated that there would be about 10,600 lines of code. Using the COCOMO formula, he found that this translated into about 15 person- months of effort. This in turn suggested a schedule time of about 7.5 months. Because the development team had very little experience in developing this type of system, Alec was not very sure of the estimate. After much deliberation, Alec decided to pad the estimate by 33 percent. As such, Alec estimated that the project would take about 10 months. Once the estimation was underway, Alec began to create an evolutionary work break- down structure and iterative workplan to identify the tasks that would be needed to com- plete the system. He started by reviewing the enhanced Unified Process phases and workflows (see Figure 1-11) and the evolutionary work breakdown structure template (see Figure 3-14). At that point in time, Alec did not know enough to create a complete work- plan. As such, he included as much detail as he knew to be correct (see Figure 3-22). Applying the Concepts at CD Selections 101 FIGURE 3-21 Size and Effort Estimate for the Internet Sales System System Components Assumed project adjusted processing complexity (APC) ϭ 1.2 Total adjusted function points (TAFP): 1.2 * 158 ϭ 189.6 Estimated lines of code: (.75 * 190 * 60) ϩ (.25 * 190 * 43) ϭ 10,600 lines of code COCOMO effort estimate: (1.4 * 10.6) ϭ 15 person-months Estimated schedule: 3.0 * 151/3 ϭ 7.5 months Final effort estimate after pad: 1.34 * 7.5 ϭ 10 months Final personnel estimate: 15/10 ϭ 1.5 102 Chapter 3 Project Management I. Business Modeling a. Inception 1. Understand current business situation 2. Uncover business process problems 3. Identify potential projects b. Elaboration c. Construction d. Transition e. Production II. Requirements a. Inception 1. Identify appropriate requirements analysis technique 2. Identify appropriate requirements gathering techniques 3. Identify functional and nonfunctional requirements II.a.1, II.a.2 4. Analyze current systems II.a.1, II.a.2 5. Create requirements definition II.a.3, II.a.4 A. Determine requirements to track B. Compile requirements as they are elicited II.a.5.A C. Review requirements with sponsor II.a.5.B b. Elaboration c. Construction d. Transition e. Production III. Analysis a. Inception 1. Identify business processes 2. Identify use cases III.a.1 b. Elaboration c. Construction d. Transition e. Production IV. Design a. Inception 1. Identify potential classes III.a b. Elaboration c. Construction d. Transition e. Production V. Implementation a. Inception b. Elaboration c. Construction d. Transition e. Production VI. Test a. Inception b. Elaboration Duration Dependency FIGURE 3-22 Evolutionary Work Breakdown Structure for the Inception Phase for CD Selections. Applying the Concepts at CD Selections 103 c. Construction d. Transition e. Production VII. Deployment a. Inception b. Elaboration c. Construction d. Transition e. Production VIII. Configuration and change management a. Inception 1. Identify necessary access controls for developed artifacts 2. Identify version control mechanisms for developed artifacts b. Elaboration c. Construction d. Transition e. Production IX. Project management a. Inception 1. Create workplan for the inception phase 2. Create system request 3. Perform feasibility analysis IX.a.2 A. Perform technical feasibility analysis B. Perform economic feasibility analysis C. Perform organizational feasibility analysis 4. Identify project size IX.a.3 5. Identify staffing requirements IX.a.4 6. Compute cost estimate IX.a.5 7. Create workplan for first iteration of the elaboration phase IX.a.1 8. Assess inception phase I.a, II.a, III.a IV.a, V.a, VI.a VII.a, VIII.a, IX.a, X.a, XI.a XII.a b. Elaboration c. Construction d. Transition e. Production X. Environment a. Inception 1. Acquire and install CASE tool 2. Acquire and install programming environment 3. Acquire and install configuration and change management tools 4. Acquire and install project management tools b. Elaboration Duration Dependency (Continued) For example, Alec felt confident about the estimation of time needed to create the require- ments definition and to elicit the requirements. However, he would not know how long it will take to develop the functional, structural, or behavioral analysis models until after he had a better idea of the actual requirements. Until this determination can be made, any estimation as to the time required would be simply a guess. As time passes, Alec would expect to know much more about the development process and would add much more detail to the workplan. (Remember that the development process and the project manage- ment processes are iterative and incremental in nature.) Staffing the Project Alec next turned to the task of how to staff his project. On the basis of his earlier estimates, it appeared that about two people would be needed to deliver the system by the holidays (fifteen person–months over ten months of calendar time means two people, rounded up). First, he created a list of the various roles that he needed to fill. He thought he would need a couple of analysts to work with the analysis and design of the system as well as an infrastruc- ture analyst to manage the integration of the Internet sales system with CD Selections’ existing technical environment. Alec also needed people who had good programmer skills and who could be responsible for ultimately implementing the system. Anne and Brian are two analysts with strong technical and interpersonal skills (although Anne is less balanced, having greater technical than interpersonal abilities), and Alec believed that they were available to bring onto this project. He wasn’t certain if they had experience with the actual Web technology that would be used on the project, but he decided to rely on vendor training or an external consultant to build those skills when they were needed. The project was so small that Alec envisioned all the team members reporting to him because he would be serving as the project’s manager. Alec created a staffing plan that captured this information, and he included a special incentive structure in the plan (Figure 3–23). Meeting the holiday deadline was very 104 Chapter 3 Project Management c. Construction d. Transition e. Production XI. Operations and Support a. Inception b. Elaboration c. Construction d. Transition e. Production XII. Infrastructure Management a. Inception 1. Identify appropriate standards and enterprise models 2. Identify reuse opportunities, such as patterns, frameworks, and libraries 3. Identify similar past projects b. Elaboration c. Construction d. Transition e. Production Duration Dependency FIGURE 3-22 Continued important to the project’s success, so he decided to offer a day off to the team members who contributed to meeting that date. He hoped that this incentive would motivate the team to work very hard. Alec also planned to budget money for pizza and sodas for times when the team worked long hours. Before he left for the day, Alec drafted a project charter, to be fine-tuned after the team got together for its kickoff meeting (i.e., the first time the project team gets together). The charter listed several norms that Alec wanted to put in place from the start to eliminate any misunderstanding or problems that could come up otherwise (Figure 3–24). Coordinating Project Activities Alec wanted the Internet sales system project to be well coordinated, so he immediately put several practices in place to support his responsibilities. First, he acquired the CASE tool used at CD Selections and set up the product so that it could be used for the analysis tasks (e.g., drawing the functional, structural, and behavioral models). The team members would probably start creating diagrams and defining components of the system fairly early on. He pulled out some standards that he has used on all development projects and made a note to review them with his project team at the kickoff meeting for the system. He also had his assistant set up binders for the project deliverables that would start rolling in. Already, he was able to include the system request, feasibility analysis, initial workplan, staffing plan, project charter, standards list, and risk assessment. Applying the Concepts at CD Selections 105 Project Manager Oversees the project to ensure that it meets its Alec objectives in time and within budget. Infrastructure Analyst Ensures the system conforms to infrastructure Anne standards at CD Selections. Ensures that the CD Selections infrastructure can support the new system. Systems Analyst Designs the information system—with a focus Anne on interfaces with the distribution system. Systems Analyst Designs the information system—with a focus Brian on the data models and system performance. Programmer Codes system. Anne Reporting Structure: All project team members will report to Alec. Special Incentives: If the deadline for the project is met, all team members who contributed to this goal will receive a free day off to be taken over the holiday season. Role Description Assigned To FIGURE 3-23 Staffing Plan for the Internet Sales System Project objective: The Internet order system project team will create a working Web-based system to sell CDs to CD Selections’ customers in time for the holiday season. The Internet order system team members will: 1. Attend a staff meeting each Friday at 2 PM. to report on the status of assigned tasks. 2. Update the workplan with actual data each Friday by 5 PM. 3. Discuss all problems with Alec as soon as they are detected. 4. Agree to support each other when help is needed, especially for tasks that could hold back the progress of the project. 5. Post important changes to the project on the team bulletin board as they are made. FIGURE 3-24 Project Charter for the Internet Order System SUMMARY Project Management Project management is the second major component of planning of the SDLC, and it includes four steps: identifying the project size, creating and managing the workplan, staffing the project, and coordinating project activities. Project management is important in ensuring that a system is delivered on time, within budget, and with the desired functionality. Identifying Project Size The project manager estimates the amount of time and effort that will be needed to com- plete the project. First, the size is estimated by relying on past experiences or industry stan- dards or by calculating the function points, a measure of program size based on the number and complexity of inputs, outputs, queries, files, and program interfaces. Next, the project manager calculates the effort for the project, which is a function of size and pro- duction rates. Algorithms such as the COCOMO model can be used to determine the effort value. Third, the optimal schedule for the project is estimated. Creating And Managing the Workplan Once a project manager has a general idea of the size and approximate schedule for the project, he or she creates a workplan, which is a dynamic schedule that records and keeps track of all the tasks that need to be accomplished over the course of the project. To create a workplan, the project manager first identifies the work breakdown structure, or the tasks that need to be accomplished, and then he or she determines how long the tasks will take. Important information about each task is entered into a workplan. The workplan information can be presented graphically using Gantt and PERT charts. In the Gantt chart, horizontal bars are drawn to represent the duration of each task, and as people work on tasks, the appropriate bars are filled in proportionately to how much of the task is finished. PERT charts are the best way to communicate task dependencies because they lay out the tasks as a flowchart in the order in which they need to be completed. The longest path from the project inception to completion is referred to as the critical path. Estimating what an IS development project will cost, how long it will take, and what the final system will actually do follows a hurricane model. The estimates become more accurate as the project progresses. One threat to the reliability of the estimates is scope creep, which occurs when new requirements are added to the project after the original project scope was defined and “frozen.” If the final schedule will not result in delivery of the system in a timely fashion, timeboxing can be used. Timeboxing sets a fixed deadline for a project and delivers the system by that deadline no matter what, even if functionality must be reduced. Evolutionary work breakdown structures and iterative workplans better fit the typical methodologies associated with object-oriented systems development. They allow the pro- ject manager to provide more realistic estimates for each iteration, or build, of a system. Furthermore, they allow the workplan to be decoupled from the architecture of the system, thus allowing projects to be comparable. By supporting comparability among projects, evolutionary WBSs enable organizational learning to take place. Staffing the Project Staffing involves determining how many people should be assigned to the project, assigning project roles to team members, developing a reporting structure for the team, and matching people’s skills with the needs of the project. Staffing also includes motivating the team to meet the project’s objectives and minimizing conflict among team members. Both motivation 106 Chapter 3 Project Management and cohesiveness have been found to greatly influence performance of team members in project situations. Team members are motivated most by such nonmonetary things as recognition, achievement, and the work itself. Conflict can be minimized by clearly defining the roles on a project and holding team members accountable for their tasks. Some man- agers create a project charter that lists the project’s norms and ground rules. Coordinating Project Activities Coordinating project activities includes putting efficient development practices in place and mitigating risk, and these activities occur over the course of the entire SDLC. Three techniques are available to help coordinate activities on a project: CASE, standards, and documentation. CASE is a category of software that automates all or part of the develop- ment process; standards are formal rules or guidelines that project teams must follow dur- ing the project; and documentation includes detailed information about the tasks of the SDLC. Often, documentation is stored in project binders that contain all the deliverables and all the internal communication that takes place—the history of the project. A risk assessment is used to mitigate risk because it identifies potential risks and evaluates the likelihood of risk and its potential impact on the project. Questions 107 KEY TERMS Adjusted project complexity (APC) Complexity Computer-aided software engineering (CASE) CASE repository COCOMO model Critical path method Critical task Documentation Effort Estimation Evolutionary WBS Function point Function point approach Functional lead Gantt chart Group cohesiveness Hurricane model Integrated CASE Iterative workplan Interpersonal skills Kickoff meeting Lower CASE Methodology Milestone Motivation Node PERT Chart Project binder Project charter Project management Project management software Project manager Reporting structure Risk assessment Risk management Scope creep Staffing plan Standards Task dependency Technical lead Technical skills Timeboxing Total adjusted function points (TAFP) Total unadjusted function points (TUFP) Trade-offs Upper CASE Work breakdown structure (WBS) Workplan QUESTIONS 1. Why do many projects end up having unreasonable deadlines? How should a project manager react to unreasonable demands? 2. What are the trade-offs that project managers must manage? 3. What are two basic ways to estimate the size of a project? 4. What is a function point and how is it used? 5. Describe the three steps of the function point approach. 6. What is the formula for calculating the effort for a project? 7. Name two ways to identify the tasks that need to be accomplished over the course of a project. 8. What is the difference between a methodology and a workplan? How are the two terms related? 108 Chapter 3 Project Management 9. Compare and contrast the Gantt chart with the PERT chart. 10. Describe the hurricane model. 11. What is scope creep, and how can it be managed? 12. What is timeboxing, and why is it used? 13. What are the problems associated with conventional WBSs? 14. What is an evolutionary WBS? How does it address the problems associated with a conventional WBS? 15. What is an iterative workplan? 16. Describe the differences between a technical lead and a functional lead. How are they similar? 17. Describe three technical skills and three interpersonal skills that would be very important to have on any project. 18. What are the best ways to motivate a team? What are the worst ways? 19. List three techniques to reduce conflict. 20. What is the difference between upper CASE and lower CASE? 21. Describe three types of standards and provide exam- ples of each. 22. What belongs in the project binder? How is the project binder organized? 23. Create a list of potential risks that could affect the out- come of a project. 24. Some companies hire consulting firms to develop the initial project plans and manage the project but use their own analysts and programmers to develop the system. Why do you think some companies do this? EXERCISES A. Visit a project management Web site, such as the Pro- ject Management Institute (www.pmi.org). Most have links to project management software products, white papers, and research. Examine some of the links for project management to better understand a variety of Internet sites that contain information related to this chapter. B. Select a specific project management topic such as CASE, project management software, or timeboxing and search for information on that topic using the Web. The URL listed in exercise A or any search engine (e.g., Yahoo!,AltaVista, Excite, InfoSeek) can provide a starting point for your efforts. C. Pretend that the career services office at your univer- sity wants to develop a system that collects student résumés and makes them available to students and recruiters over the Web. Students should be able to input their résumé information into a standard résumé template. The information then is presented in a résumé format, and it also is placed in a database that can be queried using an online search form. You have been placed in charge of the project. Develop a plan for estimating the project. How long do you think it would take for you and three other students to com- plete the project? Provide support for the schedule that you propose. D. Refer to the situation in exercise C. You have been told that recruiting season begins a month from today and that the new system must be used. How would you approach this situation? Describe what you can do as the project manager to make sure that your team does not burn out from unreasonable deadlines and commitments. E. Consider the system described in exercise C. Create a workplan listing the tasks that will need to be com- pleted to meet the project’s objectives. Create a Gantt chart and a PERT chart in a project management tool (e.g., Microsoft Project) or using a spreadsheet pack- age to graphically show the high level tasks of the project. F. Suppose that you are in charge of the project that is described in exercise C and the project will be staffed by members of your class. Do your classmates have all the right skills to implement such a project? If not, how will you go about making sure that the proper skills are available to get the job done? G. Consider the application that is used at your school to register for classes. Complete a function point work- sheet to determine the size of such an application. You will need to make some assumptions about the appli- cation’s interfaces and the various factors that affect its complexity. H. Read Your Turn 3-1. Create a risk assessment that lists the potential risks associated with performing the pro- ject, along with ways to address the risks. I. Pretend that your instructor has asked you and two friends to create a Web page to describe the course to potential students and provide current class infor- mation (e.g., syllabus, assignments, readings) to cur- rent students. You have been assigned the role of Minicases 109 leader, so you will need to coordinate your activities and those of your classmates until the project is completed. Describe how you would apply the pro- ject management techniques that you have learned in this chapter in this situation. Include descriptions of how you would create a workplan, staff the pro- ject, and coordinate all activities—yours and those of your classmates. J. Select two project management software packages and research them using the Web or trade magazines. Describe the features of the two packages. If you were a project manager, which one would you use to help support your job? Why? K. Select two estimation software packages and research them using the Web or trade magazines. Describe the features of the two packages. If you were a project manager, which one would you use to help support your job? Why? L. In 1997, Oxford Health Plans had a computer prob- lem that caused the company to overestimate rev- enue and underestimate medical costs. Problems were caused by the migration of its claims processing system from the Pick operating system to a UNIX- based system that uses Oracle database software and hardware from Pyramid Technology. As a result, Oxford’s stock price plummeted, and fixing the sys- tem became the number-one priority for the com- pany. Suppose that you have been placed in charge of managing the repair of the claims processing system. Obviously, the project team will not be in good spir- its. How will you motivate team members to meet the project’s objectives? MINICASES 1. Emily Pemberton is an IS project manager facing a dif- ficult situation. Emily works for the First Trust Bank, which has recently acquired the City National Bank. Prior to the acquisition, First Trust and City National were bitter rivals, fiercely competing for market share in the region. Following the acrimonious takeover, numerous staff were laid off in many banking areas, including IS. Key individuals were retained from both banks’ IS areas, however, and were assigned to a new consolidated IS department. Emily has been made project manager for the first significant IS project since the takeover, and she faces the task of integrating staffers from both banks on her team. The project they are undertaking will be highly visible within the orga- nization, and the time frame for the project is some- what demanding. Emily believes that the team can meet the project goals successfully, but success will require that the team become cohesive quickly and that potential conflicts be avoided. What strategies do you suggest that Emily implement in order to help assure a successfully functioning project team? 2. Tom, Jan, and Julie are IS majors at Great State Univer- sity. These students have been assigned a class project by one of their professors, requiring them to develop a new Web-based system to collect and update informa- tion on the IS program’s alumni. This system will be used by the IS graduates to enter job and address infor- mation as they graduate and then make changes to that information as they change jobs and/or addresses. Their professor also has a number of queries that she is interested in being able to implement. Based on their preliminary discussions with their professor, the stu- dents have developed this list of system elements: Inputs: 1, low complexity; 2, medium complexity; 1, high complexity Outputs: 4, medium complexity Queries: 1, low complexity; 4, medium complexity; 2, high complexity Files: 3, medium complexity Program Interfaces: 2, medium complexity Assume that an adjusted program complexity of 1.2 is appropriate for this project. Calculate the total adjusted function points for this project. One of the first activities of an analyst is to determine the business requirements for a new system. This chapter begins by presenting the requirements definition, a document that lists the new system’s capabilities. It then describes how to analyze requirements using business process automation, business process improvement, and business process reengineering techniques and how to gather requirements using interviews, JAD sessions, questionnaires, document analysis, and observation. OBJECTIVES ■ Understand how to create a requirements definition. ■ Become familiar with requirements analysis techniques. ■ Understand when to use each requirements analysis technique. ■ Understand how to gather requirements using interviews, JAD sessions, question- naires, document analysis, and observation. ■ Understand when to use each requirements-gathering technique. CHAPTER OUTLINE CHAPTER 4 Requirements Determination Introduction Requirements Determination Defining a Requirement Requirements Definition Determining Requirements Creating a Requirements Definition Requirements Analysis Strategies Business Process Automation Business Process Improvement Business Process Reengineering Selecting the Appropriate Strategies Requirements-Gathering Techniques Interviews Joint Application Development Questionnaires Document Analysis Observation Other Techniques Selecting Appropriate Techniques The System Proposal Applying the Concepts at CD Selections Requirements Analysis Strategies Requirements-Gathering Techniques Requirements Definition System Proposal Summary INTRODUCTION SDLC is the process by which an organization moves from the current system (often called the as-is system) to the new system (often called the to-be system). The output of planning, discussed in Chapters 3 and 4, is the system request, which provides general ideas for the to-be system, defines the project’s scope, and provides the initial workplan. The analysis 110 phase takes the general ideas in the system request and refines them into a detailed requirements definition (this chapter), functional models (Chapter 5), structural models (Chapter 6), and behavioral models (Chapter 7) that together form the system proposal. The system proposal also includes revised project management deliverables, such as the feasi- bility analysis (Chapter 2) and the workplan (Chapter 3). The system proposal is presented to the approval committee, who decides if the project is to continue. This usually happens at a system walkthrough, a meeting at which the con- cept for the new system is presented to the users, managers, and key decision makers. The goal of the walkthrough is to explain the system in moderate detail so that the users, man- agers, and key decision makers clearly understand it, can identify needed improvements, and are able to make a decision about whether the project should continue. If approved, the system proposal moves into the design phase, and its elements (requirements definition, functional, structural, and behavioral models) are used as inputs to the steps in design. This further refines them and defines in much more detail how the system will be built. The line between analysis and design is very blurry. This is because the deliverables created during analysis are really the first step in the design of the new system. Many of the major design decisions for the new system are found in the analysis deliverables. In fact, a better name for analysis is really analysis and initial design, but because this is a rather long name and because most organizations simply call it analysis, we do too. Nonetheless, it is important to remember that the deliverables from analysis are really the first step in the design of the new system. In many ways, the requirements determination step is the single most critical step of the entire SDLC because it is here that the major elements of the system first begin to emerge. During requirements determination, the system is easy to change because little work has been done yet. As the system moves through the other phases in the SDLC, it becomes harder and harder to return to requirements determination and to make major changes because of all of the rework that is involved. Several studies have shown that more than half of all system failures are due to problems with the requirements.1 This is why the iterative approaches of many object-oriented methodologies are so effective—small batches of requirements can be identified and implemented in incremental stages, allowing the overall system to evolve over time. In this chapter, we focus on the requirements deter- mination step of analysis. We begin by explaining what a requirement is and the overall process of requirements gathering and requirements analysis. We then present a set of tech- niques that can be used to analyze and gather requirements. REQUIREMENTS DETERMINATION The purpose of the requirements determination step is to turn the very high-level explanation of the business requirements stated in the system request into a more precise list of require- ments that can be used as inputs to the rest of analysis (creating functional, structural, and behavioral models). This expansion of the requirements ultimately leads to the design phase. Defining a Requirement A requirement is simply a statement of what the system must do or what characteristic it must have. During analysis, requirements are written from the perspective of the busi- nessperson, and they focus on the “what” of the system. Because they focus on the needs of the business user, they are usually called business requirements (and sometimes user Requirements Determination 111 1For example, see The Scope of Software Development Project Failures (Dennis, MA: The Standish Group, 1995). requirements). Later in design, business requirements evolve to become more technical, and they describe how the system will be implemented. Requirements in design are written from the developer’s perspective, and they are usually called system requirements. Before we continue, we want to stress that there is no black-and-white line dividing a business requirement and a system requirement—and some companies use the terms interchangeably. The important thing to remember is that a requirement is a statement of what the system must do, and requirements will change over time as the project moves from analysis to design to implementation. Requirements evolve from detailed statements of the business capabilities that a system should have to detailed statements of the technical way in which the capabilities will be implemented in the new system. Requirements can be either functional or nonfunctional in nature. A functional require- ment relates directly to a process a system has to perform or information it needs to contain. For example, requirements that state that a system must have the ability to search for avail- able inventory or to report actual and budgeted expenses are functional requirements. Func- tional requirements flow directly into the next steps of analysis (functional, structural, and behavioral models) because they define the functions that the system must have. Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability. The ability to access the system using a Web browser is considered a nonfunctional requirement. Nonfunctional requirements may influence the rest of analysis (functional, structural, and behavioral models) but often do so only indirectly; nonfunctional requirements are used primarily in design when decisions are made about the user interface, the hardware and software, and the system’s underlying physical architecture. Figure 4-1 lists different kinds of nonfunctional requirements and examples of each kind. Notice that the nonfunctional requirements describe a variety of characteristics regarding the system: operational, performance, security, and cultural and political. For example, the project team needs to know if a system must be highly secure, requires sub- second response time, or has to reach a multicultural customer base. These characteristics do not describe business processes or information, but they are very important in understanding what the final system should be like. Nonfunctional requirements primarily impact decisions that will be made during the design of a system. As such, we will return to this topic later in the book when we discuss design. The goal in this chapter is to identify any major issues. Four topics that have recently influenced information system requirements are the Sarbanes-Oxley Act, COBIT compliance, ISO 9000 compliance, and Capability Maturity Model compliance. Depending on the system being considered, these four topics could impact the definition of a system’s functional requirements, nonfunctional requirements, or both. The Sarbanes-Oxley Act, for example, mandates additional functional and non- functional requirements. These include additional security concerns (nonfunctional) and specific information requirements that management must now provide (functional). As such, when developing financial information systems, information system developers should be sure to include Sarbanes-Oxley expertise within the development team. In another exam- ple, a client could insist on COBIT compliance, ISO 9000 compliance, or that a specific Capability Maturity Model level had been reached for the firm to be considered as a possi- ble vendor to supply the system under consideration. Obviously, these types of require- ments add to the nonfunctional requirements. However, further discussion of these topics is beyond the scope of this book.2 112 Chapter 4 Requirements Determination 2 A concise discussion of the Sarbanes-Oxley Act is presented in G. P.Lander, What is Sarbanes-Oxley? (New York: McGraw-Hill, 2004). A good reference for Sarbanes-Oxley Act–based security requirements is D. C. Brewer, Secu- rity Controls for Sarbanes-Oxley Section 404 IT Compliance: Authorization, Authentication, and Access (Indianapolis, IN: Wiley, 2006). For detailed information on COBIT, see www.isaca.org; for ISO 9000, see www.iso.org; and for details on the Capability Maturity Model, see www.sei.cmu.edu/cmmi/. Another recent topic that influences requirements for some systems is the whole area of globalization. The idea of having a global information supply chain brings to bear a large number of additional nonfunctional requirements. For example, if the necessary opera- tional environments do not exist for a mobile solution to be developed, it is important to adapt the solution to the local environment. Or, it may not be reasonable to expect to deploy a high-technology-based solution in an area that does not have the necessary power and communications infrastructure. In some cases, we may need to consider some parts of the global information supply chain to be supported with manual—rather than automated— information systems. Manual systems have an entirely different set of requirements that cre- ate different performance expectations and additional security concerns. Furthermore, cultural and political concerns are potentially paramount. A simple example that impacts the design of user interfaces is the proper use of color on forms (on a screen or paper). Dif- ferent cultures interpret different colors differently. In other words, in a global, multicultural business environment, addressing cultural concerns goes well beyond simply having a multi- lingual user interface. As such, we must be able to adapt the global solution to the local realities. Friedman refers to these concerns as glocalization.3 Otherwise, we will simply create another example of a failed information system development project. Requirements Determination 113 Operational The physical and technical environments in ■ The system should be able to fit in a pocket or purse. which the system will operate ■ The system should be able to integrate with the existing inventory system. ■ The system should be able to work on any Web browser. Performance The speed, capacity, and reliability of the system ■ Any interaction between the user and the system should not exceed 2 seconds. ■ The system should receive updated inventory infor- mation every 15 minutes. ■ The system should be available for use 24 hours per day, 365 days per year. Security Who has authorized access to the system under ■ Only direct managers can see personnel records what circumstances of staff. ■ Customers can see their order history only during business hours. Cultural and political Cultural, political factors and legal requirements ■ The system should be able to distinguish between that affect the system United States and European currency. ■ Company policy says that we buy computers only from Dell. ■ Country managers are permitted to authorize cus- tomer user interfaces within their units. ■ The system shall comply with insurance industry standards. Source: The Atlantic Systems Guild, http://www.systemsguild.com/GuildSite/Robs/Template.html FIGURE 4-1 Nonfunctional Requirements Nonfunctional Requirement Description Examples 3 T. L. Friedman, The World is Flat: A Brief History of the Twenty-First Century, Updated and Expanded Ed. (New York: Farrar, Straus, and Giroux, 2006). For a criticism of Friedman’s view, see R. Aronica and M. Ramdoo, The World is FLAT? A Critical Analysis of Thomas L. Friedman’s New York Times Bestseller (Tampa,FL: Meghan-Kiffer Press, 2006). 114 Chapter 4 Requirements Determination One of the most common mistakes by new analysts is to confuse functional and nonfunctional requirements. Pre- tend that you received the following list of requirements for a sales system. Requirements for Proposed System The system should 1. be accessible to Web users; 2. include the company standard logo and color scheme; 3. restrict access to profitability information; 4. include actual and budgeted cost information; 5. provide management reports; 6. include sales information that is updated at least daily; 7. have two-second maximum response time for pre- defined queries and ten-minute maximum response time for ad hoc queries; 8. include information from all company subsidiaries; 9. print subsidiary reports in the primary language of the subsidiary; 10. provide monthly rankings of salesperson performance. Questions 1. Which requirements are functional business requirements? Provide two additional examples. 2. Which requirements are nonfunctional business requirements? What kind of nonfunctional require- ments are they? Provide two additional examples. 4-1 Identifying RequirementsYOUR TURN I once worked on a consulting project in which my man- ager created a requirements definition without listing non- functional requirements. The project was then estimated based on the requirements definition and sold to the client for $5,000. In my manager’s mind, the system that we would build for the client would be a very simple stand- alone system running on current technology. It shouldn’t take more than a week to analyze, design, and build. Unfortunately, the clients had other ideas. They wanted the system to be used by many people in three dif- ferent departments, and they wanted the ability for any number of people to work on the system concurrently. The technology they had in place was antiquated; nonetheless, they wanted the system to run effectively on the existing equipment. Because we didn’t set the project scope properly by including our assumptions about nonfunctional require- ments in the requirements definition, we basically had to do whatever they wanted. The capabilities they wanted took weeks to design and program. The project ended up taking four months, and the final project cost was $250,000. Our company had to pick up the tab for everything except the agreed- upon $5,000. This was by far the most frustrating project situation I ever experienced. Barbara Wixom 4-A What Can Happen If You Ignore Nonfunctional RequirementsCONCEPTS IN ACTION Requirements Definition The requirements definition report—usually just called the requirements definition—is a straightforward text report that simply lists the functional and nonfunctional require- ments in an outline format. Figure 4-2 shows a sample requirements definition for a word processing program designed to compete against software such as Microsoft Word. The requirements are numbered in a legal or outline format so that each requirement is clearly identified. The requirements are first grouped into functional and nonfunctional requirements; within each of those headings, they are further grouped by the type of non- functional requirement or by function. Sometimes, business requirements are prioritized on the requirements definition. They can be ranked as having high, medium, or low importance in the new system, or they can be labeled with the version of the system that will address the requirement (e.g., release 1, release 2, release 3). This practice is particularly important when using object-oriented methodologies because they deliver requirements in batches by developing incremental versions of the system. The most obvious purpose of the requirements definition is to provide the information needed by the other deliverables in analysis, which include functional, structural, and behav- ioral models, and to support activities in the design phase. The most important purpose of the requirements definition, however, is to define the scope of the system. The document describes to the analysts exactly what the system needs to end up doing. When discrepancies arise, the document serves as the place to go for clarification. Determining Requirements Determining requirements for the requirements definition is both a business task and an information technology task. In the early days of computing, there was a presumption that the systems analysts, as experts with computer systems, were in the best position to define Requirements Determination 115 C. Functional Requirements 1. Printing 1.1. The user can select which pages to print. 1.2. The user can view a preview of the pages before printing. 1.3. The user can change the margins, paper size (e.g., letter, A4) and orientation on the page. 2. Spell Checking 2.1. The user can check for spelling mistakes; the system can operate in one of two modes as selected by the users. 2.1.1. Mode 1 (Manual): The user will activate the spell checker and it will move the user to the next misspelled word. 2.1.2. Mode 2 (Automatic): As the user types, the spell checker will flag misspelled words so the user immediately see the misspelling. 2.2. The user can add words to the dictionary. 2.3. The user can mark words as not misspelled but not add them to the dictionary. D. Nonfunctional Requirements 1. Operational Requirements 1.1. The system will operate in Windows and Macintosh environments. 1.2. The system will be able to read and write Word documents, RTF, and HTML. 1.3. The system will be able to import Gif, Jpeg, and BMP graphics files. 2. Performance Requirements 2.1. No special performance requirements are anticipated. 3. Security Requirements 3.1. No special security requirements are anticipated. 4. Cultural and Political Requirements 4.1. No special cultural and political requirements are anticipated. FIGURE 4-2 Sample Requirements Definition how a computer system should operate. Many systems failed because they did not ade- quately address the true business needs of the users. Gradually, the presumption changed so that the users, as the business experts, were seen as being the best position to define how a computer system should operate. However, many systems failed to deliver performance benefits because users simply automated an existing inefficient system, and they failed to incorporate new opportunities offered by technology. A good analogy is building a house or an apartment. We have all lived in a house or apartment, and most of us have some understanding of what we would like to see in one. However, if we were asked to design one from scratch, it would be a challenge because we lack appropriate design skills and technical engineering skills. Likewise, an architect acting alone would probably miss some of our unique requirements. Therefore, the most effective approach is to have both business people and analysts working together to determine business requirements. Sometimes, however, users don’t know exactly what they want, and analysts need to help them discover their needs. Three kinds of techniques have become popular to help analysts do this: business process automation (BPA), business process improvement (BPI), and business process reengineering (BPR). Analysts can use these tools when they need to guide the users in explaining what is wanted from a system. The three kinds of techniques work similarly. They help users critically examine the current state of systems and processes (the as-is system), identify exactly what needs to change, and develop a concept for a new system (the to-be system). A different amount of change is associated with each technique; BPA creates a small amount of change, BPI creates a moderate amount of change, and BPR creates significant change that impacts much of the organization. All three are described in greater detail later in the chapter. Although BPA, BPI, and BPR enable the analyst to help users create a vision for the new system, they are not sufficient for extracting information about the detailed business require- ments that are needed to build it. Therefore, analysts use a portfolio of requirements-gathering techniques to acquire information from users. The analyst has many gathering techniques from which to choose: interviews, questionnaires, observation, JAD,(joint application develop- ment) and document analysis. The information gathered using these techniques is critically analyzed and used to craft the requirements definition report. The final section of this chapter describes each of the requirements-gathering techniques in greater depth. Creating a Requirements Definition Creating a requirements definition is an iterative and ongoing process whereby the analyst collects information with requirements-gathering techniques (e.g., interviews, document analysis), critically analyzes the information to identify appropriate business requirements for the system, and adds the requirements to the requirements definition report. The requirements definition is kept up to date so that the project team and business users can refer to it and get a clear understanding of the new system. To create a requirements definition, the project team first determines the kinds of functional and nonfunctional requirements that they will collect about the system (of course, these may change over time). These become the main sections of the document. Next, the analysts use a variety of requirements-gathering techniques (e.g., interviews, observation) to collect information, and they list the business requirements that were iden- tified from that information. Finally, the analysts work with the entire project team and the business users to verify, change, and complete the list and to help prioritize the importance of the requirements that were identified. This process continues throughout analysis, and the requirements definition evolves over time as new requirements are identified and as the project moves into later phases of the SDLC. Beware: the evolution of the requirements definition must be carefully managed. The 116 Chapter 4 Requirements Determination project team cannot keep adding to the requirements definition, or the system will keep grow- ing and growing and never get finished. Instead, the project team carefully identifies require- ments and evaluates which ones fit within the scope of the system. When a requirement reflects a real business need but is not within the scope of the current system or current release, it is either added on a list of future requirements or given a low priority. The manage- ment of requirements (and system scope) is one of the hardest parts of managing a project. REQUIREMENTS ANALYSIS STRATEGIES Before the project team can determine what requirements are appropriate for a given sys- tem, they need to have a clear vision of the kind of system that will be created and the level of change that it will bring to the organization. The basic process of analysis is divided into three steps: understanding the as-is system, identifying improvements, and developing requirements for the to-be system. Sometimes the first step (i.e., understanding the as-is system) is skipped or done in a cur- sory manner. This happens when no current system exists, if the existing system and processes are irrelevant to the future system, or if the project team is using a RAD or agile development methodology in which the as-is system is not emphasized. Users of traditional design methods such as waterfall and parallel development (see Chapter 1) typically spend significant time understanding the as-is system and identifying improvements before moving to capture requirements for the to-be system. However, newer RAD, agile, and object-oriented method- ologies, such as phased development, prototyping, throwaway prototyping, and extreme pro- gramming (see Chapters 1 and 2) focus almost exclusively on improvements and the to-be system requirements, and they spend little time investigating the current as-is system. Three requirements analysis strategies—business process automation, business process improvement, and business process reengineering—help the analyst lead users through the three (or two) analysis steps so that the vision of the system can be developed. Requirements analysis strategies and requirements-gathering techniques go hand-in-hand. Analysts need to use requirements-gathering techniques to collect information; requirements analysis strategies drive the kind of information that is gathered and how it is ultimately analyzed. Although we now focus on the analysis strategies and then discuss requirements gathering at the end of the chapter, they happen concurrently and are complementary activities. The choice of analysis technique to be used is based on the amount of change the system is meant to create in the organization. BPA is based on small change that improves process efficiency, BPI creates process improvements that lead to better effectiveness, and BPR revamps the way things work so that the organization is transformed on some level. To move the users “from here to there,” an analyst needs strong critical thinking skills. Critical thinking is the ability to recognize strengths and weaknesses and recast an idea in an improved form, and critical thinking skills are needed to really understand issues and develop new business processes. These skills are also needed to thoroughly examine the results of requirements gathering, to identify business requirements, and to translate those requirements into a concept for the new system. Business Process Automation BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work. BPA can make the organization more efficient but has the least impact on the business. Planners in BPA projects spend a significant time under- standing the current as-is system before moving on to improvements and to-be system requirements. Problem analysis and root cause analysis are two popular BPA techniques. Requirements Analysis Strategies 117 Problem Analysis The most straightforward (and probably the most commonly used) requirements analysis technique is problem analysis. Problem analysis means asking the users and managers to identify problems with the as-is system and to describe how to solve them in the to-be system. Most users have a very good idea of the changes they would like to see, and most will be quite vocal about suggesting them. Most changes tend to solve problems rather than capitalize on opportunities, but the latter is possible as well. Improve- ments from problem analysis tend to be small and incremental (e.g., provide more space in which to type the customer’s address; provide a new report that currently does not exist). This type of improvement often is very effective at improving a system’s efficiency or ease of use. However, it often provides only minor improvements in business value—the new system is better than the old, but it may be hard to identify significant monetary benefits from the new system. Root Cause Analysis The ideas produced by problem analysis tend to be solutions to problems. All solutions make assumptions about the nature of the problem, assumptions that may or may not be valid. In our experience, users (and most people in general) tend to quickly jump to solutions without fully considering the nature of the problem. Sometimes the solutions are appropriate, but many times they address a symptom of the problem, not the true problem or root cause itself.4 For example, suppose we notice that a lightbulb is burned out above our front door. We buy a new bulb, get out a ladder, and replace the bulb. A month later, we see that the 118 Chapter 4 Requirements Determination 4 Two good books that discuss the difficulty in finding the root causes to problems are: E. M. Goldratt and J. Cox, The Goal (Croton-on-Hudson, NY: North River Press, 1986); and E. M. Goldratt, The Haystack Syndrome (Croton-on-Hudson, NY: North River Press, 1990). In the gold rush days of the late 1990s, getting on the Internet was a hot topic. There were many companies (many of which no longer exist) that created computers for the home Internet market (many with built-in dial-up connectivity and con- tracts for that connectivity. The AtHome company made such an Internet appliance. Taken out of the box, connected to a phone line, and provided with initial start-up, it “phoned home” (made the connection to an Internet service provider). But, the days of the Internet appliance were short lived. Consumers wanted more than just Internet access—they wanted to be able to have and share files, photos, and materi- als with others. The basic AtHome Internet Appliance did not have any storage and was useful only for connecting to the Internet (by phone modem) and browsing the Internet. The stock price dropped and sales dropped; even with prices that were comparable to giving away the device, con- sumers were not longer interested as 2001 came to an end. When faced with such a situation, what does a company do? The company faced a real challenge—go out of business or reorganize. In this case AtHome, which had expertise in hardware and telecommunications, restructured into a security company. With September 11, 2001, bringing calls for better security, AtHome scrambled to create a hardware device that would sit between the Internet connection and a business net- work. To keep their stock listed on the New York Stock Exchange, AtHome did a 15-to-1 reverse stock split and changed their name to indicate a new focus. Having been burned by consumers’ whims, they set their goals on captur- ing major corporate business. It took two long years before their device started to be noticed—and just paying the employees almost ate up the available funds before sales of the new device started to kick in. The reorganized company is now recognized as a leader in the intrusion-prevention field. A company that falls from consumer favor cannot always restructure itself to become successful in an alternative area. In this case, there was success from failure. Questions 1. When should a company that has lost in the consumer marketplace re-create itself for the corporate market? 2. How might a systems analyst for the AtHome company learn to change with the times and adapt to the new environment? 4-B Success from FailureCONCEPTS IN ACTION Requirements Analysis Strategies 119 Lightbulb burns out frequently Buy better bulbs Fix bad fixture Fix bad wiring Control power surges Left on when not needed Left on when needed Bulb burns out at end of rated life Bulb burns out prematurely Change procedure to have bulb turned off Develop ways to automatically turn off bulb Find way to simplify changing Buy a bulb with a longer-rated life Find other means to deliver light Find other ways to achieve what light does FIGURE 4-3 Root-Cause Analysis for the Example of the Burned-out Lightbulb same bulb is burned out, so we buy a new bulb, haul out the ladder, and replace it again. This happens several times. At this point, we have two choices. We can buy a large package of lightbulbs and a fancy lightbulb changer on a long pole so we don’t need to haul the ladder out each time (thus saving a lot of trips to the store for new bulbs and a lot of effort in working with the ladder). Or, we can fix the light fixture that is causing the light to burn out in the first place. Buying the bulb changer is treating the symptom (the burned-out bulb), whereas fixing the fixture is treating the root cause. In the business world, the challenge lies in identifying the root cause—few problems are as simple as the lightbulb problem. The solutions that users propose (or systems that analysts think of) may either address symptoms or root causes, but without a careful analysis, it is difficult to tell which one is addressed. And finding out that we just spent a million dollars on a new lightbulb changer is a horrible feeling! Root cause analysis, therefore, focuses on problems, not solutions. The analyst starts by having the users generate a list of problems with the current system and then prioritize the problems in order of importance. Starting with the most important, the users and/or the analysts then generate all the possible root causes for the problems. Each possible root cause is investigated (starting with the most likely or easiest to check) until the true root causes are identified. If any possible root causes are identified for several problems, those should be investigated first, because there is a good chance they are the real root causes influencing the symptom problems. In our lightbulb example, there are several possible root causes. A decision tree some- times helps with the analysis. As Figure 4-3 shows, there are many possible root causes, so buying a new fixture may or may not address the true root cause. In fact, buying a lightbulb changer may actually address the root cause. The key point in root cause analysis is always to challenge the obvious. Business Process Improvement BPI makes moderate changes to the way in which the organization operates to take advan- tage of new opportunities offered by technology or to copy what competitors are doing. BPI can improve efficiency (i.e., doing things right) and improve effectiveness (i.e., doing the right things). Planners of BPI projects also spend time understanding the as-is system, but much less time than with BPA projects; their primary focus is on improving business processes, so time is spent on the as-is only to help with the improvement analyses and the to-be system requirements. Duration analysis, activity-based costing, and informal bench- marking are three popular BPI activities. Duration Analysis Duration analysis requires a detailed examination of the amount of time it takes to perform each process in the current as-is system. The analysts begin by determining the total amount of time it takes, on average, to perform a set of business processes for a typical input. They then time each of the individual steps (or sub- processes) in the business process. The time to complete the basic steps are then totaled and compared to the total for the overall process. A significant difference between the two—and in our experience the total time often can be 10 or even 100 times longer than the sum of the parts—indicates that this part of the process is badly in need of a major overhaul. For example, suppose that the analysts are working on a home mortgage system and discover that on average, it takes thirty days for the bank to approve a mortgage. They then look at each of the basic steps in the process (e.g., data entry, credit check, title search, appraisal, etc.) and find that the total amount of time actually spent on each mortgage is about eight hours. This is a strong indication that the overall process is badly broken, because it takes thirty days to perform one day’s work. These problems probably occur because the process is badly fragmented. Many different people must perform different activities before the process finishes. In the mortgage example, the application probably sits on many people’s desks for long periods of time before it is processed. Processes in which many different people work on small parts of the inputs are prime candidates for process integration or parallelization. Process integration means changing the fundamental process so that fewer people work on the input, which often 120 Chapter 4 Requirements Determination A group of executives from a Fortune 500 company used duration analysis to discuss their procurement process. Using a huge wall of Velcro and a handful of placards, a facilitator mapped out the company’s process for procuring a $50 software upgrade. Having quantified the time it took to complete each step, she then assigned costs based on the salaries of the employees involved. The fifteen-minute exercise left the group stunned. Their procurement process had gotten so convoluted that it took eighteen days, count- less hours of paperwork, and nearly $22,000 in employee time to get the product ordered, received, and up and run- ning on the requester’s desktop. Source: “For Good Measure” Debby Young, CIO Magazine (March 1, 1999). 4-C Duration AnalysisCONCEPTS IN ACTION requires changing the processes and retraining staff to perform a wider range of duties. Process parallelization means changing the process so that all the individual steps are performed at the same time. For example, in the mortgage application case, there is probably no reason that the credit check cannot be performed at the same time as the appraisal and title check. Activity-Based Costing Activity-based costing is a similar analysis, which examines the cost of each major process or step in a business process rather than the time taken.5 The analysts identify the costs associated with each of the basic functional steps or processes, identify the most costly processes, and focus their improvement efforts on them. Assigning costs is conceptually simple. Analysts simply examine the direct cost of labor and materials for each input. Materials costs are easily assigned in a manufacturing process, whereas labor costs are usually calculated based on the amount of time spent on the input and the hourly cost of the staff. However, as you may recall from a managerial accounting course, there are indirect costs such as rent, depreciation, and so on, that also can be included in activity costs. Informal Benchmarking Benchmarking refers to studying how other organizations per- form a business process in order to learn how your organization can do something better. Benchmarking helps the organization by introducing ideas that employees may never have considered but have the potential to add value. Informal benchmarking is fairly common for “customer-facing” business processes (i.e., processes that interact with the customer). With informal benchmarking, the managers and analysts think about other organizations or visit them as customers to watch how the business process is performed. In many cases, the business studied may be a known leader in the industry or simply a related firm. For example, suppose the team is developing a Web site for a car dealer. The project sponsor, key managers, and key team members would likely visit the Web sites of competitors as well as those of others in the car industry (e.g., man- ufacturers, accessories suppliers) and those in other industries that have won awards for their Web sites. Business Process Reengineering BPR means changing the fundamental way in which the organization operates, “obliter- ating” the current way of doing business and making major changes to take advantage of new ideas and new technology. Planners of BPR projects spend little time understanding the as-is, because their goal is to focus on new ideas and new ways of doing business. Outcome analysis, technology analysis, and activity elimination are three popular BPR activities. Outcome Analysis Outcome analysis focuses on understanding the fundamental out- comes that provide value to customers. Although these outcomes sound as though they should be obvious, they often aren’t. For example, suppose you consider an insurance com- pany. One of its customers has just had a car accident. What is the fundamental outcome Requirements Analysis Strategies 121 5Many books have been written on activity-based costing. Useful ones include K. B. Burk and D. W. Webster, Activity-Based Costing (Fairfax, VA: American Management Systems, 1994); and D. T. Hicks, Activity-Based Costing: Making It Work for Small and Mid-sized Companies (New York: Wiley, 1998). The two books by Eli Goldratt men- tioned previously (The Goal and The Haystack Syndrome) also offer unique insights into costing. from the customer’s perspective? Traditionally, insurance companies have answered this question by assuming the customer wants to receive the insurance payment quickly. To the customer, however, the payment is only a means to the real outcome: a repaired car. The insurance company might benefit by extending its view of the business process past its traditional boundaries to include not paying for repairs, but performing the repairs or contracting with an authorized body shop to do them. With this approach, system analysts encourage the managers and project sponsor to pretend they are customers and to think carefully about what the organization’s prod- ucts and services enable the customers to do—and what they could enable the customer to do. Technology Analysis Many major changes in business over the past decade have been enabled by new technologies. Technology analysis starts by having the analysts and man- agers develop a list of important and interesting technologies. Then the group systemati- cally identifies how each and every technology could be applied to the business process and identifies how the business would benefit. For example, one useful technology is the Internet. Saturn, the car manufacturer, took this idea and developed an extranet application for its suppliers. Rather than ordering parts for its cars, Saturn makes its production schedule available electronically to its suppliers, who ship the parts Saturn needs so that they arrive at the plant just in time. This saves Saturn significant costs because it eliminates the need for people to monitor the production schedule and issue purchase orders. Activity Elimination Activity elimination is exactly what it sounds like. The analysts and managers work together to identify how the organization could eliminate each and every activity in the business process, how the function could operate without it, and what effects are likely to occur. Initially, managers are reluctant to conclude that processes can be elim- inated, but this is a “force-fit” exercise in that they must eliminate each activity. In some cases the results are silly; nonetheless, participants must address each and every activity in the business process. For example, in the home mortgage approval process discussed earlier, the man- agers and analysts would start by eliminating the first activity, entering the data into the mortgage company’s computer. This leads to two obvious possibilities: (1) eliminate the use of a computer system or (2) make someone else do the data entry (e.g., the customer over the Web). They would then eliminate the next activity, the credit check. Silly, right? After all, making sure the applicant has good credit is critical in issuing a loan. Not really. The real answer depends upon how many times the credit check identifies bad applications. If all or almost all applicants have good credit and are seldom turned down by a credit check, then the cost of the credit check may not be worth the cost of the few bad loans it prevents. Eliminating it may actually result in lower costs, even with the cost of bad loans. Selecting Appropriate Strategies Each technique discussed in this chapter has its own strengths and weaknesses (see Figure 4-4). No one technique is inherently better than the others, and in practice most projects use a combination of techniques. Potential Business Value Potential business value varies with the analysis strategy. Although BPA has the potential to improve the business, most of the benefits from BPA are 122 Chapter 4 Requirements Determination tactical and small in nature. Because BPA does not seek to change the business processes, it can only improve their efficiency. BPI usually offers moderate potential benefits, depend- ing upon the scope of the project, because it seeks to change the business in some way. It can increase both efficiency and effectiveness. BPR creates large potential benefits because it seeks to radically improve the nature of the business. Requirements Analysis Strategies 123 IBM Credit was a wholly owned subsidiary of IBM responsible for financing mainframe computers sold by IBM. Although some customers bought mainframes out- right or obtained financing from other sources, financing computers provided significant additional profit. When an IBM sales representative made a sale, he or she would immediately call IBM Credit to obtain a financing quote. The call was received by a credit officer, who would record the information on a request form. The form would then be sent to the credit department to check the customer’s credit status. This information would be recorded on the form, which was then sent to the business practices department, who would write a contract (some- times reflecting changes requested by the customer). The form and the contract would then go to the pricing department, which used the credit information to estab- lish an interest rate and recorded it on the form. The form and contract were then sent to the clerical group, where an administrator would prepare a cover letter quoting the interest rate and send the letter and contract via Federal Express to the customer. The problem at IBM Credit was a major one. Getting a financing quote took anywhere for four to eight days (six days on average), giving the customer time to rethink the order or find financing elsewhere. While the quote was being prepared, sales representatives would often call to find out where the quote was in the process so they could tell the customer when to expect it. However, no one at IBM Credit could answer the question because the paper forms could be in any department, and it was impossible to locate one without physically walking through the departments and going through the piles of forms on everyone’s desk. IBM Credit examined the process and changed it so that each credit request was logged into a computer sys- tem and each department could record an application’s status as they completed it and sent it to the next depart- ment. In this way, sales representatives could call the credit office and quickly learn the status of each applica- tion. IBM used some sophisticated management science queuing theory analysis to balance workloads and staff across the different departments so none would be over- loaded. They also introduced performance standards for each department (e.g., the pricing decision had to be completed within one day after that department received an application). However, process times got worse, even though each department was achieving almost 100 percent compli- ance on its performance goals. After some investigation, managers found that when people got busy, they conve- niently found errors that forced them to return credit requests to the previous department for correction, thereby removing it from their time measurements. Questions 1. What techniques can you use to identify improvements? 2. Choose one technique and apply it to this situation. What improvements did you identify? Source: M. Hammer and J. Champy, Reengineering the Corporation (1993). New York, NY: Harper Business. 4-2 IBM CreditYOUR TURN Potential business value Low–moderate Moderate High Project cost Low Low–moderate High Breadth of analysis Narrow Narrow–moderate Very broad Risk Low–moderate Low–moderate Very high Business Process Business Process Business Process Automation Improvement Reengineering FIGURE 4-4 Characteristics of Analysis Strategies Project Cost Project cost is always important. In general, BPA has the lowest cost because it has the narrowest focus and seeks to make the fewest number of changes. BPI can be moderately expensive, depending upon the scope of the project. BPR is usually expensive, both because of the amount of time required of senior managers and the amount of redesign to business processes. Breadth of Analysis Breadth of analysis refers to the scope of analysis, or whether analysis includes business processes within a single business function, processes that cross the organization, or processes that interact with those in customer or supplier organizations. BPR takes a broad perspective, often spanning several major business processes, even across multiple organizations. BPI has a much narrower scope that usually includes one or several business functions. BPA typically examines a single process. Risk One final issue is risk of failure, which is the likelihood of failure due to poor design, unmet needs, or too much change for the organization to handle. BPA and BPI have low to moderate risk because the to-be system is fairly well defined and understood, and its potential impact on the business can be assessed before it is implemented. BPR projects, on the other hand, are less predictable. BPR is extremely risky and is not some- thing to be undertaken unless the organization and its senior leadership are committed to making significant changes. Mike Hammer, the father of BPR, estimates that 70 percent of BPR projects fail. 124 Chapter 4 Requirements Determination Suppose you are the analyst charged with developing a new Web site for a local car dealer who wants to be very innovative and try new things. What analysis strategies would you recommend? Why? 4-3 Analysis StrategyYOUR TURN A major retail store recently spent $24 million on a large private satellite communication system. The system pro- vides state-of-the-art voice, data, and video transmission between stores and regional headquarters. When an item is sold, the scanner software updates the inventory system in real time. As a result, store transactions are passed on to regional and national headquarters instantly, which keeps inventory records up to date. One of their major competi- tors has an older system, where transactions are uploaded at the end of a business day. The first company feels such instant communication and feedback allows them to react more quickly to changes in the market and gives them a competitive advantage. For example, if an early winter snowstorm causes stores across the upper Midwest to start selling high-end (and high-profit) snowblowers, the near- est warehouse can quite quickly prepare next-day ship- ments to maintain a good inventory balance, whereas the competitor may not move quite as quickly and thus will lose out on such quick inventory turnover. Questions 1. Do you think a $24 million investment in a private satellite communication system could be justified by a cost–benefit analysis? Could this be done with a standard communication line (with encryption)? 2. How might the competitor in this example attempt to close the information gap? 4-D Implementing a Satellite Data NetworkCONCEPTS IN ACTION REQUIREMENTS-GATHERING TECHNIQUES An analyst is very much like a detective (and business users are sometimes like elusive sus- pects). He or she knows that there is a problem to be solved and therefore must look for clues that uncover the solution. Unfortunately, the clues are not always obvious (and often missed), so the analyst needs to notice details, talk with witnesses, and follow leads just as Sherlock Holmes would have done. The best analysts will thoroughly gather requirements using a variety of techniques and make sure that the current business processes and the needs for the new system are well understood before moving into design. Analysts don’t want to discover later that they have key requirements wrong—such surprises late in the SDLC can cause all kinds of problems. The requirements-gathering process is used for building political support for the project and establishing trust and rapport between the project team building the system and the users who ultimately will choose to use or not use the system. Involving someone in the process implies that the project teams view that person as an important resource and value his or her opinions. All the key stakeholders (the people who can affect the system or who will be affected by the system) must be included in the requirements-gathering process. The stakeholders might include managers, employees, staff members, and even some customers and suppliers. If a key person is not involved, that individual may feel slighted, which can cause problems during implementation (e.g., How could they have developed the system without my input?). The second challenge of requirements gathering is choosing the way(s) in which infor- mation is collected. There are many techniques for gathering requirements that vary from asking people questions to watching them work. In this chapter, we focus on the five most commonly used techniques: interviews, JAD sessions (a special type of group meeting), questionnaires, document analysis, and observation. Each technique has its own strengths and weaknesses, many of which are complementary, so most projects use a combination of techniques, probably most often interviews, JAD sessions, and document analysis.6 Interviews An interview is the most commonly used requirements-gathering technique. After all, it is natural— if you need to know something, you usually ask someone. In general, interviews are conducted one-on-one (one interviewer and one interviewee), but sometimes, due to time constraints, several people are interviewed at the same time. There are five basic steps to the interview process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postinterview follow-up.7 Selecting Interviewees The first step in interviewing is to create an interview schedule listing all the people who will be interviewed, when, and for what purpose (see Figure 4-5). The schedule can be an informal list that is used to help set up meeting times or a formal list that is incorporated into the workplan. The people who appear on the interview schedule are selected based on the analyst’s information needs. The project sponsor, key business users, and other members of the project team can help the analyst determine who in the organization can best provide important information about requirements. These people are listed on the interview schedule in the order in which they should be interviewed. Requirements-Gathering Techniques 125 6 Some excellent books that address the importance of gathering requirements and various techniques include Alan M. Davis, Software Requirements: Objects, Functions, & States, Revision (Englewood Cliffs, NJ: Prentice Hall, 1993); Gerald Kotonya and Ian Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); and Dean Leffingwell and Don Widrig, Managing Software Requirements: A Unified Approach (Reading, MA: Addison-Wesley, 2000). 7A good book on interviewing is that by Brian James, The Systems Analysis Interview (Manchester, England: NCC Blackwell, 1989). People at different levels of the organization will have different perspectives on the system, so it is important to include both managers who manage the processes and staff who actually perform the processes to gain both high-level and low-level perspectives on an issue. Also, the kinds of interview subjects needed may change over time. For example, at the start of the pro- ject, the analyst has a limited understanding of the as-is business process. It is common to begin by interviewing one or two senior managers to get a strategic view and then to move to midlevel managers, who can provide broad, overarching information about the business process and the expected role of the system being developed. Once the analyst has a good understanding of the “big picture,”lower-level managers and staff members can fill in the exact details of how the process works. Like most other things about systems analysis, this is an iterative process— starting with senior managers, moving to midlevel managers, then staff members, back to midlevel managers, and so on, depending upon what information is needed along the way. It is quite common for the list of interviewees to grow, often by 50 to 75 percent. As people are interviewed, more information that is needed and additional people who can provide the information will probably be identified. 126 Chapter 4 Requirements Determination Andria McClellan Director, Accounting Strategic vision for new Mon., March 1 accounting system 8:00–10:00 AM Jennifer Draper Manager, Accounts Current problems with Mon., March 1 Receivable accounts receivable 2:00–3:15 PM process; future goals Mark Goodin Manager, Accounts Current problems with Mon., March 1 Payable accounts payable 4:00–5:15 PM process; future goals Anne Asher Supervisor, Data Entry Accounts receivable and Wed., March 3 payable processes 10:00–11:00 AM Fernando Merce Data Entry Clerk Accounts receivable and Wed., March 3 payable processes 1:00–3:00 PM Purpose of Name Position Interview Meeting FIGURE 4-5 Sample Interview Schedule In 1990, I led a consulting team for a major development project for the U.S. Army. The goal was to replace eight existing systems used on virtually every Army base across the United States. The as-is process and data models for these systems had been built, and our job was to identify improvement opportunities and develop to-be process models for each of the eight systems. For the first system, we selected a group of midlevel managers (captains and majors) recommended by their commanders as being the experts in the system under construction. These individuals were the first- and sec- ond-line managers of the business function. The indi- viduals were expert at managing the process but did not know the exact details of how the process worked. The resulting to-be process model was very general and nonspecific. Alan Dennis Question Suppose you were in charge of the project. What interview schedule for the remaining seven projects would you use? 4-E Selecting the Wrong PeopleCONCEPTS IN ACTION Designing Interview Questions There are three types of interview questions: closed- ended questions, open-ended questions, and probing questions. Closed-ended questions are those that require a specific answer. They are similar to multiple-choice or arithmetic questions on an exam (see Figure 4-6). Closed-ended questions are used when an analyst is looking for specific, precise information (e.g., how many credit card requests are received per day). In general, precise questions are best. For example, rather than asking, Do you handle a lot of requests? it is better to ask, How many requests do you process per day? Closed-ended questions enable analysts to control the interview and obtain the infor- mation they need. However, these types of questions don’t uncover why the answer is the way it is, nor do they uncover information that the interviewer does not think to ask ahead of time. Open-ended questions are those that leave room for elaboration on the part of the interviewee. They are similar in many ways to essay questions that you might find on an exam (see Figure 4-6 for examples). Open-ended questions are designed to gather rich information and give the interviewee more control over the information that is revealed during the interview. Sometimes the information that the interviewee chooses to discuss uncovers information that is just as important as the answer (e.g., if the interviewee talks only about other departments when asked for problems, it may suggest that he or she is reluctant to admit his or her own problems). The third type of question is the probing question. Probing questions follow up on what has just been discussed in order to learn more, and they often are used when the inter- viewer is unclear about an interviewee’s answer. They encourage the interviewee to expand on or to confirm information from a previous response, and they signal that the inter- viewer is listening and interested in the topic under discussion. Many beginning analysts are reluctant to use probing questions because they are afraid that the interviewee might be offended at being challenged or because they believe it shows that they didn’t understand what the interviewee said. When done politely, probing questions can be a powerful tool in requirements gathering. In general, an interviewer should not ask questions about information that is readily available from other sources. For example, rather than asking what information is used to perform to a task, it is simpler to show the interviewee a form or report (see the section on document analysis) and ask what information on it is used. This helps focus the interviewee on the task and saves time, because the interviewee does not need to describe the informa- tion detail—he or she just needs to point it out on the form or report. Requirements-Gathering Techniques 127 Closed-ended questions • How many telephone orders are received per day? • How do customers place orders? • What information is missing from the monthly sales report? Open-ended questions • What do you think about the current system? • What are some of the problems you face on a daily basis? • What are some of the improvements you would like to see in a new system? Probing questions • Why? • Can you give me an example? • Can you explain that in a bit more detail? Types of Questions Examples FIGURE 4-6 Three Types of Questions No type of question is better than another, and a combination of questions is usually used during an interview. At the initial stage of an IS development project, the as-is process can be unclear, so the interview process begins with unstructured interviews, interviews that seek broad and roughly defined information. In this case, the interviewer has a general sense of the information needed but has few close-ended questions to ask. These are the most challenging interviews to conduct because they require the interviewer to ask open- ended questions and probe for important information “on the fly.” As the project progresses, the analyst comes to understand the business process much better and needs very specific information about how business processes are performed (e.g., exactly how a customer credit card is approved). At this time, the analyst conducts structured interviews, in which specific sets of questions are developed prior to the inter- views. There usually are more close-ended questions in a structured interview then in the unstructured approach. No matter what kind of interview is being conducted, interview questions must be organized into a logical sequence so that the interview flows well. For example, when try- ing to gather information about the current business process, it can be useful to move in logical order through the process or from the most important issues to the least important. There are two fundamental approaches to organizing the interview questions: top- down or bottom-up (see Figure 4-7). With the top-down interview, the interviewer starts with broad, general issues and gradually works towards more specific ones. With the bottom-up interview, the interviewer starts with very specific questions and moves to broad questions. In practice, analysts mix the two approaches, starting with broad general issues, moving to specific questions, and then returning to general issues. The top-down approach is an appropriate strategy for most interviews (it is certainly the most common approach). The top-down approach enables the interviewee to become accustomed to the topic before he or she needs to provide specifics. It also enables the inter- viewer to understand the issues before moving to the details because the interviewer may not have sufficient information at the start of the interview to ask very specific questions. Perhaps most importantly, the top-down approach enables the interviewee to raise a set of big-picture issues before becoming enmeshed in details, so the interviewer is less likely to miss important issues. One case in which the bottom-up strategy may be preferred is when the analyst already has gathered a lot of information about issues and just needs to fill in some holes with details. Or, bottom-up interviewing may be appropriate if lower-level staff members feel threatened 128 Chapter 4 Requirements Determination High-level: Very general Top-Down Bottom-Up Medium-level: Moderately specific Low-level: Very specific How can order processing be improved? How can we reduce the number of times that customers return items they’ve ordered? How can we reduce the number of errors in order processing (e.g., shipping the wrong products)? FIGURE 4-7 Top-Down and Bottom-up Questioning Strategies or unable to answer high-level questions. For example, How can we improve customer ser- vice? may be too broad a question for a customer service clerk, whereas a specific question is readily answerable (e.g., How can we speed up customer returns?). In any event, all interviews should begin with noncontroversial questions and then gradually move into more con- tentious issues after the interviewer has developed some rapport with the interviewee. Preparing for the Interview It is important to prepare for the interview in the same way that you would prepare to give a presentation. The interviewer should have a general interview plan listing the questions to be asked in the appropriate order; should anticipate possible answers and provide follow-up with them; and should identify segues between related topics. The interviewer should confirm the areas in which the interviewee has knowledge in order not to ask questions that he or she cannot answer. Review the topic areas, the questions, and the interview plan, and clearly decide which have the greatest priority in case time runs short. In general, structured interviews with closed-ended questions take more time to pre- pare than unstructured interviews. So, some beginning analysts prefer unstructured inter- views, thinking that they can “wing it.”This is very dangerous and often counterproductive, because any information not gathered in the first interview will require follow-up efforts, and most users do not like to be interviewed repeatedly about the same issues. The interviewer should be sure to prepare the interviewee as well. When the interview is scheduled, the interviewee should be told the reason for the interview and the areas that will be discussed far enough in advance so that he or she has time to think about the issues and organize his or her thoughts. This is particularly important when the interviewer is an outsider to the organization and for lower-level employees, who often are not asked for their opinions and who may be uncertain about why they are being interviewed. Conducting the Interview In starting the interview, the first goal is to build rapport with the interviewee, so that he or she trusts the interviewer and is willing to tell the whole truth, not just give the answers that he or she thinks are wanted. The interviewer should appear to be professional and an unbiased, independent seeker of information. The interview should start with an explanation of why the interviewer is there and why he or she has chosen to interview the person; then the interviewer should move into the planned interview questions. It is critical to carefully record all the information that the interviewee provides. In our experience, the best approach is to take careful notes—write down everything the interviewee says, even if it does not appear immediately relevant. The interviewer shouldn’t be afraid to ask the person to slow down or to pause while writing, because this is a clear indication that the interviewee’s information is important. One potentially controversial issue is whether or not to tape-record an interview. Recording ensures that the interviewer does not miss impor- tant points, but it can be intimidating for the interviewee. Most organizations have policies or generally accepted practices about the recording of interviews, so they should be deter- mined before an interview. If the interviewer is worried about missing information and can- not tape the interview, then he or she can bring along a second person to take detailed notes. As the interview progresses, it is important to understand the issues that are discussed. If the interviewer does not understand something, he or she should be sure to ask. The interviewer should not be afraid to ask dumb questions, because the only thing worse than appearing dumb is to be dumb by not understanding something. If the interviewer doesn’t understand something during the interview, he or she certainly won’t understand it afterwards. Jargon should be recognized and defined; any jargon not understood should be clarified. One good strategy to increase understanding during an interview is to periodi- cally summarize the key points that the interviewee is communicating. This avoids misun- derstandings and also demonstrates that the interviewer is listening. Requirements-Gathering Techniques 129 130 Chapter 4 Requirements Determination 5-1 Developing Interpersonal Skills Finally, facts should be separated from opinion. The interviewee may say, for example, We process too many credit card requests. This is an opinion, and it is useful to follow this up with a probing question requesting support for the statement (e.g., Oh, how many do you process in a day?). It is helpful to check the facts because any differences between the facts and the interviewee’s opinions can point out key areas for improve- ment. Suppose the interviewee complains about a high or increasing number of errors, but the logs show that errors have been decreasing. This suggests that errors are viewed as a very important problem that should be addressed by the new system, even if they are declining. As the interview draws to a close, the interviewee should have time to ask questions or provide information that he or she thinks is important but was not part of the interview plan. In most cases, the interviewee will have no additional concerns or information, but in some cases this will lead to unanticipated, but important, information. Likewise, it can be useful to ask the interviewee if there are other people who should be interviewed. The interview should end on time (if necessary, some topics can be omitted or another inter- view can be scheduled). As a last step in the interview, the interviewer should briefly explain what will happen next (see the next section). The interviewer shouldn’t prematurely promise certain features in the new system or a specific delivery date, but he or she should reassure the interviewee that his or her time was well spent and very helpful to the project. Interpersonal skills are those skills that enable you to develop rapport with others, and they are very important for interviewing. They help you to communicate with others effectively. Some people develop good interper- sonal skills at an early age; they simply seem to know how to communicate and interact with others. Other people are less lucky and need to work hard to develop their skills. Interpersonal skills, like most skills, can be learned. Here are some tips: • Don’t worry, be happy. Happy people radiate confi- dence and project their feelings on others. Try inter- viewing someone while smiling and then interviewing someone else while frowning and see what happens. • Pay attention. Pay attention to what the other per- son is saying (which is harder than you might think). See how many times you catch yourself with your mind on something other than the conversa- tion at hand. • Summarize key points. At the end of each major theme or idea that someone explains, repeat the key points back to the speaker (e.g., Let me make sure I understand. The key issues are. . . .”). This demonstrates that you consider the information important—and also forces you to pay attention (you can’t repeat what you didn’t hear). • Be succinct. When you speak, be succinct. The goal in interviewing (and in much of life) is to learn, not to impress. The more you speak, the less time you give to others. • Be honest. Answer all questions truthfully, and if you don’t know the answer, say so. • Watch body language (yours and theirs). The way a person sits or stands conveys much information. In general, a person who is interested in what you are saying sits or leans forward, makes eye contact, and often touches his or her face. A person leaning away from you or with an arm over the back of a chair is disinterested. Crossed arms indicate defen- siveness or uncertainty, while steepling (sitting with hands raised in front of the body with fingertips touching) indicates a feeling of superiority. PRACTICAL TIP Postinterview Follow-up After the interview is over, the analyst needs to prepare an interview report that describes the information from the interview (Figure 4-8). The report contains interview notes, information that was collected over the course of the interview and is summarized in a useful format. In general, the interview report should be written within forty-eight hours of the interview, because the longer the interviewer waits, the more likely he or she is to forget information. Often, the interview report is sent to the interviewee with a request to read it and inform the analyst of clarifications or updates. The interviewee needs to be convinced that the interviewer genuinely want his or her corrections to the report. Usually there are few changes, but the need for any significant changes suggests that a second interview will be required. Never distribute someone’s information without prior approval. Requirements-Gathering Techniques 131 Interviewing is not as simple as it first appears. Select two people from class to go to the front of the room to demon- strate an interview. (This also can be done in groups.) Have one person be the interviewer and the other be the interviewee. The interviewer should conduct a five- minute interview regarding the school’s course registra- tion system. Gather information about the existing system and how the system can be improved. If there is time, repeat with another pair. Questions 1. What was the body language of the interview pair like? 2. What kind of interview was conducted? 3. What kinds of questions were asked? 4. What was done well? How could the interview be improved? 4-4 Interview PracticeYOUR TURN Interview Notes Approved by: Linda Estey Person Interviewed: Linda Estey, Director, Human Resources Interviewer: Barbara Wixom Purpose of Interview: • Understand reports produced for Human Resources by the current system • Determine information requirements for future system Summary of Interview: • Sample reports of all current HR reports are attached to this report. The information that is not used and missing information are noted on the reports. • Two biggest problems with the current system are: 1. The data are too old (the HR Department needs information within two days of month end; currently information is provided to them after a three-week delay) 2. The data are of poor quality (often reports must be reconciled with departmental HR database) • The most common data errors found in the current system include incorrect job level information and missing salary information. Open Items: • Get current employee roster report from Mary Skudrna (extension 4355). • Verify calculations used to determine vacation time with Mary Skudrna. • Schedule interview with Jim Wack (extension 2337) regarding the reasons for data quality problems. Detailed Notes: See attached transcript. FIGURE 4-8 Interview Report Joint Application Development (JAD) JAD is an information-gathering technique that allows the project team, users, and manage- ment to work together to identify requirements for the system. IBM developed the JAD tech- nique in the late 1970s, and it is often the most useful method for collecting information from users.8 Capers Jones claims that JAD can reduce scope creep by 50 percent, and it avoids the requirements for a system being too specific or too vague, both of which cause trouble dur- ing later stages of the SDLC.9 JAD is a structured process in which ten to twenty users meet together under the direction of a facilitator skilled in JAD techniques. The facilitator is a per- son who sets the meeting agenda and guides the discussion but does not join in the discus- sion as a participant. He or she does not provide ideas or opinions on the topics under discussion in order to remain neutral during the session. The facilitator must be an expert in both group process techniques and systems analysis and design techniques. One or two scribes assist the facilitator by recording notes, making copies, and so on. Often the scribes will use computers and CASE tools to record information as the JAD session proceeds. The JAD group meets for several hours, several days, or several weeks until all the issues have been discussed and the needed information is collected. Most JAD sessions take place in a specially prepared meeting room, away from the participants’ offices so that they are not inter- rupted. The meeting room is usually arranged in a U-shape so that all participants can easily see each other (see Figure 4-9). At the front of the room (the open part of the U), are whiteboard, flip chart and/or overhead projector for use by the facilitator leading the discussion. One problem with JAD is that it suffers from the traditional problems associated with groups; sometimes people are reluctant to challenge the opinions of others (particularly their boss), a few people often dominate the discussion, and not everyone participates. In a fifteen-member group, for example, if everyone participates equally, then each person can talk for only four minutes each hour and must listen for the remaining fifty-six minutes— not a very efficient way to collect information. A new form of JAD called electronic JAD,or e-JAD, attempts to overcome these prob- lems by using groupware. In an e-JAD meeting room, each participant uses special software on a networked computer to send anonymous ideas and opinions to everyone else. In this way, all participants can contribute at the same time without fear of reprisal from people with differing opinions. Initial research suggests that e-JAD can reduce the time required to run JAD sessions by 50 to 80 percent.10 Selecting Participants Selecting JAD participants is done in the same basic way as select- ing interview participants. Participants are selected based on the information they can con- tribute, to provide a broad mix of organizational levels, and to build political support for the new system. The need for all JAD participants to be away from their office at the same time can be a major problem. The office may need to be closed or operate with a skeleton staff until the JAD sessions are complete. Ideally, the participants who are released from regular duties to attend the JAD sessions should be the very best people in that business unit. However, without strong management support, JAD sessions can fail because those selected to attend the JAD session are people who are less likely to be missed (i.e., the least competent people). 132 Chapter 4 Requirements Determination 8More information on JAD can be found in J. Wood and D. Silver, Joint Application Development (New York: Wiley, 1989); and Alan Cline, “Joint Application Development for Requirements Collection and Management,” http://www.carolla.com/wp-jad.htm. 9See Kevin Strehlo, “Catching up with the Jones and ‘Requirement’ Creep,” InfoWorld (July 29, 1996); and Kevin Strehlo, “The Makings of a Happy Customer: Specifying Project X,” InfoWorld (November 11, 1996). 10 For more information on e-JAD, see A. R. Dennis, G. S. Hayes, and R. M. Daniels, “Business Process Modeling with Groupware,” Journal of Management Information Systems 15, no. 4 (1999): 115–142. The facilitator should be someone who is an expert in JAD or e-JAD techniques and, ideally, someone who has experience with the business under discussion. In many cases, the JAD facilitator is a consultant external to the organization because the organization may not have a recurring need for JAD or e-JAD expertise. Developing and maintaining this expertise in-house can be expensive. Designing a JAD Session JAD sessions can run from as little as half a day to several weeks, depending upon the size and scope of the project. In our experience, most JAD sessions tend to last five to ten days, spread over a three-week period. Most e-JAD sessions tend to last one to four days in a one-week period. JAD and e-JAD sessions usually go beyond the collection of information and move into analysis. For example, the users and the analysts collectively can create analysis deliverables, such as the functional models, structural models, or the requirements definition. Requirements-Gathering Techniques 133 Flip chart sheets Whiteboard Screen Computers Projectors Printer Name cards Name cards FIGURE 4-9 JAD Meeting Room As with interviewing, success depends upon a careful plan. JAD sessions usually are designed and structured using the same principles as interviews. Most JAD sessions are designed to collect specific information from users, and this requires the development of a set of questions prior to the meeting. One difference between JAD and interviewing is that all JAD sessions are structured—they must be carefully planned. In general, closed- ended questions are seldom used because they do not spark the open and frank discus- sion that is typical of JAD. In our experience, it is better to proceed top-down in JAD sessions when gathering information. Typically thirty minutes is allocated to each sepa- rate agenda item, and frequent breaks are scheduled throughout the day because partic- ipants tire easily. Preparing for a JAD Session As with interviewing, it is important to prepare the ana- lysts and participants for a JAD session. Because the sessions can go beyond the depth of a typical interview and are usually conducted off-site, participants can be more concerned about how to prepare. It is important that the participants understand what is expected of them. If the goal of the JAD session, for example, is to develop an understanding of the current system, then participants can bring procedure manuals and documents with them. If the goal is to identify improvements for a system, then they can think about how they would improve the system prior to the JAD session. Conducting a JAD Session Most JAD sessions try to follow a formal agenda, and most have formal ground rules that define appropriate behavior. Common ground rules include following the schedule, respecting others’ opinions, accepting disagreement, and ensuring that only one person talks at once. The role of a JAD facilitator can be challenging. Many participants come to a JAD session with strong feelings about the system to be discussed. Channeling these feelings so that the session moves forward in a positive direction and getting participants to recognize and accept—but not necessarily agree on—opinions and situations different from their own requires significant expertise in systems analysis and design, JAD, and interpersonal skills. Few systems analysts attempt to facilitate JAD sessions without being trained in JAD techniques, and most apprentice with a skilled JAD facilitator before they attempt to lead their first session. The JAD facilitator performs three key functions. First, he or she ensures that the group sticks to the agenda. The only reason to digress from the agenda is when it becomes clear to the facilitator, project leader, and project sponsor that the JAD session has pro- duced some new information that is unexpected and requires the JAD session (and perhaps the project) to move in a new direction. When participants attempt to divert the discussion away from the agenda, the facilitator must be firm but polite in leading discussion back to the agenda and getting the group back on track. Second, the facilitator must help the group understand the technical terms and jargon that surround the system development process, and help the participants understand the spe- cific analysis techniques used. Participants are experts in their area, or their part of the busi- ness, but they are not experts in systems analysis. The facilitator must, therefore, minimize the learning required and teach participants how to effectively provide the right information. Third, the facilitator records the group’s input on a public display area, which can be a whiteboard, flip chart, or computer display. He or she structures the information that the group provides and helps the group recognize key issues and important solutions. Under no circumstance should the facilitator insert his or her opinions into the discussion. The facilitator must remain neutral at all times and simply help the group through the process. The moment the facilitator offers an opinion on an issue, the group will see him or her not as a neutral party, but rather as someone who could be attempting to sway the group into some predetermined solution. 134 Chapter 4 Requirements Determination However, this does not mean that the facilitator should not try to help the group resolve issues. For example, if two items appear to be the same to the facilitator, the facilitator should not say, “I think these may be similar.”Instead, the facilitator should ask, “Are these similar?” If the group decides they are, the facilitator can combine them and move on. However, if the group decides they are not similar (despite what the facilitator believes), the facilitator should accept the decision and move on. The group is always right, and the facilitator has no opinion. Requirements-Gathering Techniques 135 Managing Problems in JAD Sessions I have run more than a hundred JAD sessions and have learned several standard “facilitator tricks.” Here are some common problems and some ways to deal with them. • Domination. The facilitator should ensure that no one person dominates the group discussion. The only way to deal with someone who dominates is head on. During a break, approach the person, thank him or her for his or her insightful comments, and ask the person to help you make sure that others also participate. • Noncontributors. Drawing out people who have par- ticipated very little is challenging because you want to bring them into the conversation so that they will contribute again. The best approach is to ask a direct factual question that you are certain they can answer. And it helps to ask the question in a long way to give them time to think. For example, Pat, I know you’ve worked shipping orders a long time. You’ve probably been in the shipping department longer than anyone else. Could you help us understand exactly what happens when an order is received in shipping? • Side discussions. Sometimes participants engage in side conversations and fail to pay attention to the group. The easiest solution is simply to walk close to the people and continue to facilitate right in front of them. Few people will continue a side conver- sion when you are two feet from them and the entire group’s attention is on you and them. • Agenda merry-go-round. The merry-go-round occurs when a group member keeps returning to the same issue every few minutes and won’t let go. One solution is to let the person have five minutes to ramble on about the issue while you carefully write down every point on a flip chart or computer file. This flip chart or file is then posted conspicu- ously on the wall. When the person brings up the issue again, you interrupt them, walk to the paper and ask them what to add. If they mention some- thing already on the list, you quickly interrupt, point out that it is there, and ask what other infor- mation to add. Don’t let them repeat the same point, but write any new information. • Violent agreement. Some of the worst disagree- ments occur when participants really agree on the issues but don’t realize that they agree because they are using different terms. An example is arguing whether a glass is half empty or half full; they agree on the facts but can’t agree on the words. In this case, the facilitator has to translate the terms into different words and find common ground so the parties recognize that they really agree. • Unresolved conflict. In some cases, participants don’t agree and can’t understand how to determine what alternatives are better. You can help by struc- turing the issue. Ask for criteria by which the group will identify a good alternative (e.g., Suppose this idea really did improve customer service. How would I recognize the improved customer service?). Then once you have a list of criteria, ask the group to assess the alternatives using them. • True conflict. Sometimes, despite every attempt, participants just can’t agree on an issue. The solution is to postpone the discussion and move on. Docu- ment the issue as an open issue and list it promi- nently on a flip chart. Have the group return to the issue hours later. Often the issue will have resolved itself by then and you haven’t wasted time on it. If the issue cannot be resolved later, move it to the list of issues to be decided by the project sponsor or some other more senior member of management. • Humor. Humor is one of the most powerful tools a facilitator has and thus must be used judiciously. The best JAD humor is always in context; never tell jokes but take the opportunity to find the humor in the situation. Alan Dennis PRACTICAL TIP Post-JAD Follow-up As with interviews, a JAD postsession report is prepared and circu- lated among session attendees. The postsession report is essentially the same as the interview report in Figure 4-8. Because the JAD sessions are longer and provide more information, it usually takes a week or two after the JAD session before the report is complete. Questionnaires A questionnaire is a set of written questions used to obtain information from individuals. Questionnaires are often used when there is a large number of people from whom informa- tion and opinions are needed. In our experience, questionnaires are a common technique with systems intended for use outside the organization (e.g., by customers or vendors) or for systems with business users spread across many geographic locations. Most people automat- ically think of paper when they think of questionnaires, but today more questionnaires are being distributed in electronic form, either via e-mail or on the Web. Electronic distribution can save a significant amount of money as compared to distributing paper questionnaires. Selecting Participants As with interviews and JAD sessions, the first step is to identify the individuals to whom the questionnaire will be sent. However, it is not usual to select every person who could provide useful information. The standard approach is to select a sample, or subset, of people who are representative of an entire group. Sampling guidelines are dis- cussed in most statistics books, and most business schools include courses that cover the topic, so we do not discuss it here. The important point in selecting a sample, however, is to realize that not everyone who receives a questionnaire will actually complete it. On average, only 30 to 50 percent of paper and e-mail questionnaires are returned. Response rates for Web-based questionnaires tend to be significantly lower (often only 5 to 30 percent). Designing a Questionnaire Developing good questions is critical for questionnaires because the information on a questionnaire cannot be immediately clarified for a confused respondent. Questions on questionnaires must be very clearly written and leave little room for misunderstanding, so closed-ended questions tend to be most commonly used. Ques- tions must clearly enable the analyst to separate facts from opinions. Opinion questions often ask the respondent the extent to which they agree or disagree (e.g., Are network prob- lems common?), whereas factual questions seek more precise values (e.g., How often does a network problem occur: once an hour, once a day, once a week?). See Figure 4-10 for guidelines on questionnaire design. Perhaps the most obvious issue—but one that is sometimes overlooked—is to have a clear understanding of how the information collected from the questionnaire will be ana- lyzed and used. This issue must be addressed before the questionnaire is distributed, because it is too late afterward. 136 Chapter 4 Requirements Determination Organize yourselves into groups of four to seven people, and pick one person in each group to be the JAD facilita- tor. Using a blackboard, whiteboard or flip chart, gather information about how the group performs some process (e.g., working on a class assignment, making a sandwich, paying bills, getting to class). Questions 1. How did the JAD session go? 2. Based on your experience, what are pros and cons of using JAD in a real organization? 4-5 JAD PracticeYOUR TURN Requirements-Gathering Techniques 137 Questions should be relatively consistent in style, so that the respondent does not have to read instructions for each question before answering it. It is generally good practice to group related questions together to make them simpler to answer. Some experts suggest that questionnaires should start with questions important to respondents, so that the ques- tionnaire immediately grabs their interest and induces them to answer it. Perhaps the most important step is to have several colleagues review the questionnaire and then pretest it with a few people drawn from the groups to whom it will be sent. It is surprising how often seemingly simple questions can be misunderstood. Administering the Questionnaire The key issue in administering the questionnaire is get- ting participants to complete the questionnaire and send it back. Dozens of marketing research books have been written about ways to improve response rates. Commonly used techniques include clearly explaining why the questionnaire is being conducted and why the respondent has been selected; stating a date by which the questionnaire is to be returned; offering an inducement to complete the questionnaire (e.g., a free pen); and offering to supply a summary of the questionnaire responses. Systems analysts have additional techniques to improve response rates inside the organization, such as personally handing out the questionnaire and personally contacting those who have not returned them after a week or two, as well as request- ing the respondents’ supervisors to administer the questionnaires in a group meeting. Questionnaire Follow-up It is helpful to process the returned questionnaires and develop a questionnaire report soon after the questionnaire deadline. This ensures that the analysis process proceeds in a timely fashion and that respondents who requested copies of the results receive them promptly. • Begin with nonthreatening and interesting questions. • Group items into logically coherent sections. • Do not put important items at the very end of the questionnaire. • Do not crowd a page with too many items. • Avoid abbreviations. • Avoid biased or suggestive items or terms. • Number questions to avoid confusion. • Pretest the questionnaire to identify confusing questions. • Provide anonymity to respondents. FIGURE 4-10 Good Questionnaire Design Organize yourselves into small groups. Have each person develop a short questionnaire to collect information about how often group members perform some process (e.g., work- ing on a class assignment, making a sandwich, paying bills, getting to class), how long it takes them, how they feel about the process, and opportunities for improving the process. Once everyone has completed his or her question- naire, ask each member to pass it to the right and then complete his or her neighbor’s questionnaire. Pass the questionnaire back to the creator when it is completed. Questions 1. How did the questionnaire you completed differ from the one you created? 2. What are the strengths of each questionnaire? 3. How would you analyze the survey results if you had received fifty responses? 4. What would you change about the questionnaire that you developed? 4-6 Questionnaire PracticeYOUR TURN Document Analysis Project teams often use document analysis to understand the as-is system. Under ideal cir- cumstances, the project team that developed the existing system will have produced docu- mentation, which was then updated by all subsequent projects. In this case, the project team can start by reviewing the documentation and examining the system itself. Unfortunately, most systems are not well documented because project teams fail to document their projects along the way, and when the projects are over, there is no time to go back and document. Therefore, there may not be much technical documentation about the current systems available, or it may not contain updated information about recent sys- tem changes. However, there are many helpful documents that do exist in an organization: paper reports, memorandums, policy manuals, user-training manuals, organization charts, forms, and, of course, the user interface with the existing system. But these documents tell only part of the story. They represent the formal system that the organization uses. Quite often, the real, or informal, system differs from the formal one, and these differences, particularly large ones, give strong indications of what needs to be changed. For example, forms or reports that are never used should probably be elimi- nated. Likewise, boxes or questions on forms that are never filled in (or are used for other purposes) should be rethought. See Figure 4-11 for an example of how a document can be interpreted. The most powerful indication that the system needs to be changed is when users create their own forms or add additional information to existing ones. Such changes clearly demonstrate the need for improvements to existing systems. Thus, it is useful to review both blank and completed forms to identify these deviations. Likewise, when users access multiple reports to satisfy their information needs, it is a clear sign that new information or new information formats are needed. Observation Observation, the act of watching processes being performed, is a powerful tool for gathering information about the as-is system because it enables the analyst to see the reality of a situation, rather than listening to others describe it in interviews or JAD 138 Chapter 4 Requirements Determination At my neighborhood Publix grocery store, the cashiers always hand-write the total amount of the charge on every credit-card charge form, even though it is printed on the form. Why? Because the “back office” staff people who reconcile the cash in the cash drawers with the amount sold at the end of each shift find it hard to read the small print on the credit-card forms. Writing in large print makes it easier for them to add the values up. How- ever, cashiers sometimes make mistakes and write the wrong amount on the forms, which causes problems. Barbara Wixom Questions 1. What does the credit-card charge form indicate about the existing system? 2. How can you make improvements with a new system? 4-F Publix Credit-Card FormsCONCEPTS IN ACTION sessions. Several research studies have shown that many managers really do not remember how they work and how they allocate their time. (Quick, how many hours did you spend last week on each of your courses?) Observation is a good way to check the validity of information gathered from indirect sources such as interviews and questionnaires. In many ways, the analyst becomes an anthropologist as he or she walks through the organization and observes the business system as it functions. The goal is to keep a low profile, to not interrupt those working, and to not influence those being observed. Nonetheless, it is important to understand that what analysts observe may not be the normal day-to-day routine because people tend to be extremely careful in their behavior when they are being watched. Even though normal practice may be to break formal Requirements-Gathering Techniques 139 Name: Buffy Pat Smith Pet’s Name: Buffy Collie 7/6/99 Address: 100 Central Court. Apartment 10 Toronto, Ontario K7L 3N6 Phone Number: 555-3400 416- Do you have insurance: yes Insurance Company: Pet’s Mutual Policy Number: KA-5493243 CENTRAL VETERINARY CLINIC Patient Information Card The staff had to add additional information about the type of animal and the animal’s date of birth. This information should be added to the new form in the to-be system. The customer made a mistake. This should be labeled Owner’s Name to prevent confusion. The customer did not include area code in the phone number. This should be made more clear. FIGURE 4-11 Performing a Document Analysis organizational rules, the observer is unlikely to see this. (Remember how you drove the last time a police car followed you?) Thus, what you see may not be what you get. Observation is often used to supplement interview information. The location of a per- son’s office and its furnishings give clues as to the person’s power and influence in the orga- nization and can be used to support or refute information given in an interview. For example, an analyst might become skeptical of someone who claims to use the existing computer system extensively if the computer is never turned on while the analyst visits. In most cases, observation will support the information that users provide in interviews. When it does not, it is an important signal that extra care must be taken in analyzing the business system. Other Techniques Some other very useful requirements-gathering techniques include throwaway prototyping, role-playing CRC cards with use case–based scenarios, and mind/concept mapping. Throwaway prototyping was described in Chapter 1. In essence, throwaway prototypes are created to better understand some aspect of the new system. In many cases, they are used to test out some technical aspect of a nonfunctional requirement, such as connecting a client workstation to a server. If you have never done this before, it will be a lot easier to develop a very small example system to test out the necessary design of the connection from the client workstation to the server instead of trying to do it the first time with the full blown system. As such, throwaway prototyping is very useful when designing the physical architecture of the system (see Chapter 12). Throwaway prototyping can also be very useful in designing user interfaces (see Chapter 11). Role-playing CRC cards with use case–based scenarios are very useful when creating functional (see Chapter 5), structural (see Chapter 6), and behavioral (see Chapter 7) models. We describe this approach in Chapter 6. Concept mapping is an educational psychology technique that has been used in schools, corporations, and health-care agencies to facilitate learning, understanding, and knowledge creation.11 Concept maps represent meaningful relationships between concepts. 140 Chapter 4 Requirements Determination Visit the library at your college or university and observe how the book checkout process occurs. First watch several students checking books out, and then check one out your- self. Prepare a brief summary report of your observations. When you return to class, share your observations with others. Questions 1. Why might the reports present different information? 2. How would the information be different had you used the interview or JAD technique? 4-7 Observation PracticeYOUR TURN 11For more information on concept mapping, see J. D. Novak and D. B. Gowin, Learning How to Learn (Cambridge, UK: Cambridge University Press, 1984); and J. D. Novak, Learning, Creating, and Using Knowl- edge: Concept MapsTM as Facilitative Tools in Schools and Corporations (Mahwah, NL: Lawrence Erlbaum Asso- ciates, Publishers, 1998). Also, a concept mapping tool is available from the Institute of Human and Machine Cognition at cmap.ihmc.us. They are useful for focusing individuals on the small number of key ideas on which they should concentrate. A concept map is essentially a node-and-arc representation, where the nodes represent the individual requirements and the arcs represent the relationships among the requirements. Each arc is labeled with a relationship name. Concept maps also have been recommended as a possible technique to support modeling requirements for object-oriented systems development and knowledge management systems.12 The advantage of the concept mapping approach to representing requirements over the typ- ical textual approach (see Figure 4-2) is that a concept map is not limited to a hierar- chical representation. Concept maps allow the relationships among the functional and nonfunctional requirements to be explicitly represented. For example, Figure 4-12 Requirements-Gathering Techniques 141 include include include include impact include include include Requirements Spell Checking Manual Mode Automatic Mode Printing Nonfunctional Requirements Cultural and Political Requirements Mark words as not mispelled, but do not add to dictionary Read/Write multiple file formats, e.g., .doc, .rtf, .htm Performance Requirements Security Requirements Operational Requirements Functional Requirements Print Preview Page Formatting Spell Check Add words to dictionary Mac and Windows environment support Select Pages Import multiple graphics file formats, e.g., .gif, .jpg, .bmp FIGURE 4-12 Sample Concept Map 12 See B. Henderson-Sellers, A. Simons, and H. Younessi, The OPEN Toolbox of Techniques (Harlow, England: Addison-Wesley, 1998) shows a concept map that portrays the information contained in the requirements def- inition shown in Figure 4-1. As is demonstrated, concept maps provide a very simple approach for linking nonfunctional requirements to functional requirements. This is very difficult to represent in a text-only version of the requirements definition. By combining both text and concept map representation, it is possible to leverage the strength of both textual and graphical representations to more completely represent the requirements. Selecting the Appropriate Techniques Each of the requirements-gathering techniques discussed earlier has strengths and weaknesses. No one technique is always better than the others, and in practice most projects use a combination of techniques. Thus, it is important to understand the strengths and weaknesses of each technique and when to use each (see Figure 4-13). One issue not discussed is that of the analysts’ experience. In general, document analy- sis and observation require the least amount of training, whereas JAD sessions are the most challenging. Type of Information The first characteristic is type of information. Some techniques are more suited for use at different stages of the analysis process, whether understanding the as-is system, identifying improvements, or developing the to-be system. Interviews and JAD are commonly used in all three stages. In contrast, document analysis and observation usually are most helpful for understanding the as-is, although occasionally they provide information about current problems that need to be improved. Questionnaires are often used to gather information about the as-is system as well as general information about improvements. Depth of Information The depth of information refers to how rich and detailed the information is that the technique usually produces and the extent to which the technique is useful for obtaining not only facts and opinions, but also an understanding of why those facts and opinions exist. Interviews and JAD sessions are very useful for providing a good depth of rich and detailed information and helping the analyst to understand the reasons behind them. At the other extreme, document analysis and observation are use- ful for obtaining facts, but little beyond that. Questionnaires can provide a medium depth of information, soliciting both facts and opinions with little understanding of why they exist. 142 Chapter 4 Requirements Determination FIGURE 4-13 Table of Requirements-Gathering Techniques Type of information As-is, improvements, As-is, improvements, As-is, improvements As-is As-is to-be to-be Depth of information High High Medium Low Low Breadth of information Low Medium High High Low Integration of information Low High Low Low Low User involvement Medium High Low Low Low Cost Medium Low–Medium Low Low Low–Medium Joint Application Document Interviews Design Questionnaires Analysis Observation Breadth of Information Breadth of information refers to the range of information and information sources that can be easily collected using the chosen technique. Question- naires and document analysis are both easily capable of soliciting a wide range of informa- tion from a large number of information sources. In contrast, interviews and observation require the analyst to visit each information source individually and, therefore, take more time. JAD sessions are in the middle because many information sources are brought together at the same time. Integration of Information One of the most challenging aspects of requirements gath- ering is the integration of information from different sources. Simply put, different peo- ple can provide conflicting information. Combining this information and attempting to resolve differences in opinions or facts is usually very time consuming because it means contacting each information source in turn, explaining the discrepancy, and attempting to refine the information. In many cases, the individual wrongly perceives that the ana- lyst is challenging his or her information, when in fact it is another user in the organiza- tion who is doing so. This can make the user defensive and make it hard to resolve the differences. All techniques suffer integration problems to some degree, but JAD sessions are designed to improve integration because all information is integrated when it is collected, not afterwards. If two users provide conflicting information, the conflict becomes imme- diately obvious, as does the source of the conflict. The immediate integration of informa- tion is the single most important benefit of JAD that distinguishes it from other techniques, and this is why most organizations use JAD for important projects. User Involvement User involvement refers to the amount of time and energy the intended users of the new system must devote to the analysis process. It is generally agreed that as users become more involved in the analysis process, the chance of success Requirements-Gathering Techniques 143 Colleges and universities need to stay current with tech- nologies. Many campuses have gone with laptop pro- grams, where students are expected to purchase or lease a particular model of laptop that will be preloaded with appropriate software and used for the students’ collegiate careers. Likewise, the campuses need to update their infrastructure—such as increasing bandwidth (to handle more video, such as YouTube)—and to provide wireless communication. The University of Northern Wisconsin is a campus that is trying to remain current with technology. Campus budgets are almost always tight. UNW offers programs from its Superior, Wisconsin, main campus as well as programs on two satellite campuses in Ashland and Rhinelander. Users on the two satellite campuses frequently do not get the same level of service as students on the main campus. Internet access is generally slower and not all the software is the same. For example, students at the main campus have access to Blomberg systems for analy- sis of financial trading data. The campus opted to build an Internet portal for all students to get to the same software and systems, set up by student ID and student profiles and permissions. Questions 1. What technologies would be needed to make your campus a premier technology-oriented school? 2. How might a college campus be like a business with multiple locations and software needs? 4-G Campus Technology UpdatesCONCEPTS IN ACTION increases. However, user involvement can have a significant cost, and not all users are willing to contribute valuable time and energy. Questionnaires, document analysis, and observation place the least burden on users, whereas JAD sessions require the greatest effort. Cost Cost is always an important consideration. In general, questionnaires, document analysis, and observation are low-cost techniques (although observation can be quite time consuming). The low cost does not imply that they are more or less effective than the other techniques. Interviews and JAD sessions generally have moderate costs. In general, JAD sessions are much more expensive initially, because they require many users to be absent from their offices for significant periods of time, and they often involve highly paid consultants. However, JAD sessions significantly reduce the time spent in information integration and thus cost less in the long term. Combining Techniques In practice, requirements gathering combines a series of dif- ferent techniques. Most analysts start by using interviews with senior manager(s) to gain an understanding of the project and the big-picture issues. From these interviews, it becomes clear whether large or small changes are anticipated. These interviews are often followed with analysis of documents and policies to gain some understanding of the as- is system. Usually interviews come next to gather the rest of the information needed for the as-is picture. In our experience, identifying improvements is most commonly done using JAD sessions because the JAD session enables the users and key stakeholders to work together through an analysis technique and come to a shared understanding of the possibilities for the to-be system. Occasionally, these JAD sessions are followed by questionnaires sent to a much wider set of users or potential users to see whether the opinions of those who participated in the JAD sessions are widely shared. Developing the concept for the to-be system is often done through interviews with senior managers, followed by JAD sessions with users of all levels to make sure the key needs of the new system are well understood. THE SYSTEM PROPOSAL A system proposal brings together into a single comprehensive document the material created during planning and analysis. The system proposal typically includes an executive summary, the system request, the workplan, the feasibility analysis, the requirements defi- nition, and the evolving models that describe the new system.13 The executive summary provides all critical information in a very concise form. It can be thought of as a summary of the complete proposal. Its purpose is to allow a busy executive to quickly read through it and determine which parts of the proposal that they need to go through more thor- oughly. Figure 4-14 provides a template for a system proposal and references to where the other sections of the proposal are described. 144 Chapter 4 Requirements Determination 13Depending on the client, much more detailed specifications may be required; for example Department of Defense, NASA, IEEE/ANSI, and the Naval Research Laboratory all have very specific formats that must be followed. For more information on these more detailed specifications see A. M Davis, Software Requirements, Revision (Upper Saddle River, NJ: Prentice Hall, 1993); G. Kotonya and I. Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); and R. H. Thayer and M. Dorfman (eds.), Software Requirements Engineering, 2nd ed. (Los Alamitos, CA: IEEE Computer Society Press, 1997). APPLYING THE CONCEPTS AT CD SELECTIONS Once the CD Selections steering committee approved the system proposal and feasibility analysis, the project team began performing analysis activities. These included gathering requirements using a variety of techniques, and analyzing the requirements that were gathered. An Internet marketing and sales consultant, Chris Campbell, was hired to advise Alec, Margaret, and the project team during the inception phase. Some highlights of the project team’s activities are presented next. Requirements Analysis Strategies Margaret suggested that the project team conduct several JAD sessions with store man- agers, marketing analysts, and Web-savvy members of the IT staff. Together, the groups could work through some BPI strategies and brainstorm how improvements could be made to the current order process using a new Web-based system. Alec facilitated three JAD sessions that were conducted over the course of a week. Alec’s past facilitation experience helped the eight-person meetings run smoothly and stay on track. First, Alec used technology analysis and suggested several important Web technologies that could be used for the system. The JAD session generated ideas about how CD Selections could apply each of the technologies to the Internet order project. Applying the Concepts at CD Selections 145 FIGURE 4-14 System Proposal Template 1. Table of Contents 2. Executive Summary A summary of all the essential information in the proposal so a busy executive can read it quickly and decide what parts of the plan to read in more depth. 3. System Request The revised system request form (see Chapter 2). 4. Workplan The original workplan, revised after having completed the analysis phase (see Chapter 3). 5. Feasibility Analysis A revised feasibility analysis, using the information from the analysis phase (see Chapter 2). 6. Requirements Definition A list of the functional and nonfunctional business requirements for the system (this chapter). 7. Functional Model An activity diagram, a set of use case descriptions, and a use case diagram that illustrate the basic processes or external functionality that the system needs to support (see Chapter 5). 8. Structural Models A set of CRC cards, class diagram and object diagrams that describe the structural aspects of the to-be system (see Chapter 6). This may also include structural models of the current as-is system that will be replaced. 9. Behavioral Models A set of sequence diagrams, communication diagrams, behavioral state machines, and a CRUD matrix that describe the internal behavior of the to-be system (see Chapter 7). This may include behavioral models of the as-is system that will be replaced. Appendices These contain additional material relevant to the proposal, often used to support the recom- mended system. This might include results of a questionnaire survey or interviews, industry reports and statistics, and so on. 146 Chapter 4 Requirements Determination 14 This JAD session was not originally planned. As such, the workplan (see Figure 3-22) should be modified. Alec had the group categorize the ideas into three sets: definite ideas that would have a good probability of providing business value; possible ideas that might add business value; and unlikely ideas. Next, Alec applied informal benchmarking by introducing the Web sites of several leading retailers and pointing out the features that they offered online. He selected some sites based on their success with Internet sales and others based on their similarity to the vision for CD Selections’ new system. The group discussed the features that were common across most retailers versus unique functionality, and they created a list of suggested busi- ness requirements for the project team. Requirements-Gathering Techniques Alec believed that it would be important to understand the order processes and systems that already existed in the organization because they would have to be closely integrated with the Web order system. Three requirements-gathering techniques proved to be helpful in understanding the current systems and processes—document analysis, interviews, and observation. First, the project team collected existing reports (e.g., order forms, screenshots of the online order screens) and system documentation (functional, structural, and behavioral models) that shed light on the as-is system. They were able to gather a good amount of information about the brick-and-mortar order processes and systems in this way. When questions arose, they conducted short interviews with the person who provided the docu- mentation for clarification. Next, Alec interviewed the senior analysts for the order and inventory systems to get a better understanding of how those systems worked. He asked if they had any ideas for the new system as well as for any integration issues that would need to be addressed. Alex also interviewed a contact from the ISP and the IT person who supported CD Selections’ current Web site; both provided information about the existing communications infrastructure at CD Selections and its Web capabilities. Finally, Alex spent a half day visiting two of the retail stores and observing exactly how the order and hold processes worked in the brick-and- mortar facilities. Requirements Definition Throughout all these activities, the project team collected information and tried to identify the business requirements for the system from the information. As the project progressed, requirements were added to the requirements definition and grouped by requirement type. When questions arose, the team worked with Margaret, Chris, and Alec to confirm that requirements were within the scope. The requirements that fell outside of the scope of the current system were typed into a separate document that would be saved for future use. After gathering and documenting the requirements, the requirements definition was distributed to Margaret, two marketing employees who would work with the system on the business side, and several retail store managers. This group then met for a two-day JAD session to clarify, finalize, and prioritize business requirements.14 The project team spent time creating functional, structural and behavioral models (Chapters 5, 6, and 7) that depicted the objects in the future system. Members of market- ing and IT departments reviewed the documents during interviews with the project team. Figure 4-15 shows a portion of the final requirements definition, and Figure 4-16 repre- sents the requirements in the form of a concept map. Applying the Concepts at CD Selections 147 Nonfunctional Requirements 1. Operational Requirements 1.1 The Internet sales system will draw information from the main CD information database, which contains basic information about CDs (e.g., title, artist, ID number, price, quantity in inventory). The Internet sales system will not write information to the main CD information database. 1.2 The Internet sales system will store orders for new CDs in the special order system and will rely on the special order system to complete the special orders generated. 1.3 A new module for the in-store system will be written to manage the “holds” generated by the Internet sales system. The requirements for this new module will be documented as part of the Internet sales system because they are necessary for the Internet sales system to function. 2. Performance Requirements No special performance requirements are anticipated. 3. Security Requirements No special security requirements are anticipated. 4. Cultural and Political Requirements. No special cultural and political requirements are anticipated. Functional Requirements 1. Maintain CD Information 1.1 The Internet sales system will need a database of basic information about the CDs that it can sell over the Internet, similar to the CD database at each of the retail stores (e.g., title, artist, ID number, price, quantity in inventory). 1.2 Every day, the Internet sales system will receive an update from the distribution system that will be used to update this CD database. Some new CDs will be added, some will be deleted, and others will be revised (e.g., a new price). 1.3 The electronic marketing (EM) manager (a position that will need to be created) will also have the ability to update information (e.g., prices for sales). 2. Maintain CD Marketing Information 2.1 The Internet sales system provides an additional opportunity to market CDs to current and new customers. The system will provide a database of marketing materials about selected CDs that will help Web users learn more about them (e.g., music reviews, links to Web sites, artist information, and sample sound clips). When information about a CD that has additional marketing information is displayed, a link will be provided to the additional information. 2.2 Marketing materials will be supplied primarily by vendors and record labels so that we can better promote their CDs. The EM manager of the marketing department will determine what marketing materials will be placed in the system and will be responsible for adding, changing, and deleting the materials. 3. Place CD Orders 3.1 Customers will access the Internet sales system to look for CDs of interest. Some customers will search for specific CDs or CDs by specific artists, whereas other customers will want to browse for interesting CDs in certain categories (e.g., rock, jazz, classical). 3.2 When the customer has found all the CDs he or she wants, the customer will "check out" by providing personal information (e.g., name, e-mail, address, credit card), and information regarding the order (e.g., the CDs to purchase, and the quantity for each item). 3.3 The system will verify the customer's credit card information with an online credit card clearance center and either accept the order or reject it. 3.4 Customers will also be able check to see if their preferred stores have the CDs in stock. They will use zip code to find stores close to their location. If the CD is available at a preferred store, a customer can immediately place a hold on the CD in stock and then come into the store and pick it up. 3.5 If the CD is not available in the customer’s preferred store, the customer can request that the CD be special ordered to that store for later pickup. The customer will be notified by e-mail when the requested CD arrives at the requested store; the CD will be placed on hold (which will again expire after 7 days). This process will work similarly to the current special order systems already available in the regular stores. 3.6 Alternatively, the customer can mail order the CD (see requirement 4). 4. Fill Mail Orders 4.1 When a CD is mail-ordered, the Internet sales system will send the mail order to the mail order distribution system. 4.2 The mail-order distribution system will handle the actual sending of CDs to customers; it will notify the Internet sales system and e-mail the customer. 4.3 Weekly reports can be run by the EM manager to check the order status. FIGURE 4-15 CD Selections Requirements Definition 148 Chapter 4 Requirements Determination System Proposal Alec reviewed the requirements definition and the other deliverables that the project team created during the inception phase. Given Margaret’s desire to have the system operating before next year’s Christmas season, Alec decided to timebox the project, and he determined what functionality could be included in the system by that schedule dead- line (see Chapter 3). He suggested that the project team develop the system in three ver- sions rather than attempting to develop a complete system that provided all the features initially. The first version, to be operational well before the holidays, would implement a basic system that would have the standard order features of other Internet retailers. The second version, planned for late spring or early summer, would have several features unique to CD Selections. The third version would add more advanced features, such as the ability to listen to a sample of music over the Internet, to find similar CDs, and to write reviews. Alec revised the workplan accordingly, and he worked with Margaret and the folks in marketing to review the feasibility analysis and update it where appropriate. Using the system proposal template in Figure 4-14, Alec combined all of the deliverables from the project and submitted a system proposal to the steering committee for approval. Figure 4-17 shows the outline of the CD Selections system proposal. Margaret and Alec met with the committee and presented the highlights of what was learned during the FIGURE 4-16 Concept Map Requirements Model include include include Maintain CD Marketing Information requiresCreationOf mayImplyAdditional impliesAdditional Cultural and Political Requirements requiresUseOf requiresAccessTo Requirements Fill Mail Orders Place CD Orders CD DB "Hold" System Functional Requirements Nonfunctional Requirements Performance Requirements Security Requirements Operational Requirements SpecialOrderSystem Maintain CD Information Summary 149 inception phase and the final concept of the new system. Based on the proposal and pre- sentation, the steering committee decided that they would continue to fund the Inter- net sales system. SUMMARY Requirements Determination Requirements determination is the part of analysis whereby the project team turns the very high-level explanation of the business requirements stated in the system request into a more precise list of requirements. A requirement is simply a statement of what the system must do or what characteristic it needs to have. Business requirements describe the what of the systems, and system requirements describe how the system will be implemented. A functional-requirement relates directly to a process the system has to perform or informa- tion it needs to contain. Nonfunctional requirements refer to behavioral properties that the system must have, such as performance and usability. All the functional and nonfunctional business requirements that fit within the scope of the system are written in the require- ments definition, which is used to create other analysis deliverables and leads to the initial design for the new system. 1. Table of Contents 2. Executive Summary To be completed once everything else is done. 3. System Request See Figure 2-13. 4. Workplan See Figure 3-22. 5. Feasibility Analysis See Figures 2-14 and 2-15. 6. Requirements Definition See Figure 4-15. 7. Functional Model To be completed in the future (see Chapter 5). 8. Structural Models To be completed in the future (see Chapter 6). 9. Behavioral Model To be completed in the future (see Chapter 7). Appendices A. Size and Effort Estimate See Figure 3-21. B. Staffing Plan See Figure 3-23. C. Project Charter See Figure 3-24. FIGURE 4-17 Outline of the CD Selections System Proposal 150 Chapter 4 Requirements Determination Requirements Analysis Strategies The basic process of analysis is divided into three steps: understanding the as-is system, identifying improvements, and developing requirements for the to-be system. Three requirements analysis strategies—BPA, BPI, and BPR—help the analyst lead users through the three (or two) analysis steps so that the vision of the system can be developed. BPA means leaving the basic way in which the organization operates unchanged and using com- puter technology to do some of the work. Problem analysis and root-cause analysis are two popular BPA techniques. BPI means making moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing. Duration analysis, activity-based costing, and informa- tion benchmarking are three popular BPI activities. BPR means changing the fundamental way in which the organization operates. Outcome analysis, technology analysis, and activity elimination are three popular BPR activities. Requirements-Gathering Techniques Five techniques can be used to gather the business requirements for the proposed sys- tem: interviews, joint application development, questionnaires, document analysis, and observation. Interviews involve meeting one or more people and asking them questions. There are five basic steps in the interview process: selecting interviewees, designing interview questions, preparing for the interview, conducting the interview, and postin- terview follow-up. JAD allows the project team, users, and management to work together to identify requirements for the system. Electronic JAD attempts to overcome common problems associated with groups by using groupware. A questionnaire is a set of written questions for obtaining information from individuals. Questionnaires are often used when there is a large number of people from whom information and opin- ions are needed. Document analysis entails reviewing the documentation and examin- ing the system itself. It can provide insights into the formal and informal system. Observation, the act of watching processes being performed, is a powerful tool for gath- ering information about the as-is system because it enables the analyst to see the reality of a situation firsthand. The System Proposal The system proposal documents the results of the planning and analysis activities in a single, comprehensive document. The actual format of the system proposal depends some- what on the client. For example, the federal government has very specific requirements that a system proposal must meet, whereas a small locally owned bike shop would be willing to use a much simpler format. KEY TERMS Activity elimination Activity-based costing Analysis As-is system Benchmarking Bottom-up interview Breadth of analysis Business process automation (BPA) Business process improvement (BPI) Business process reengineering (BPR) Business requirements Closed-ended question Critical thinking skills Document analysis Duration analysis Exercises 151 QUESTIONS 1. What are the key deliverables that are created during the analysis phase? What is the final deliverable from the analysis phase, and what does it contain? 2. What is the difference between an as-is system and a to-be system? 3. What is the purpose of the requirements definition? 4. What are the three basic steps of the analysis process? Which step is sometimes skipped or done in a cursory fashion? Why? 5. Compare and contrast the business goals of BPA, BPI, and BPR. 6. Compare and contrast problem analysis and root-cause analysis. Under what conditions would you use prob- lem analysis? Under what conditions would you use root-cause analysis? 7. Compare and contrast duration analysis and activity- based costing. 8. Assuming time and money were not important con- cerns, would BPR projects benefit from additional time spent understanding the as-is system? Why or why not? 9. What are the important factors in selecting an appro- priate analysis strategy? 10. Describe the five major steps in conducting interviews. 11. Explain the difference between a closed-ended ques- tion, an open-ended question, and a probing question. When would you use each? 12. Explain the differences between unstructured inter- views and structured interviews. When would you use each approach? 13. Explain the difference between a top-down and bottom- up interview approach. When would you use each approach? 14. How are participants selected for interviews and JAD sessions? 15. How can you differentiate between facts and opin- ions? Why can both be useful? 16. Describe the five major steps in conducting JAD sessions. 17. How does a JAD facilitator differ from a scribe? 18. What are the three primary things that a facilitator does in conducting the JAD session? 19. What is e-JAD and why might a company be inter- ested in using it? 20. How does designing questions for questionnaires dif- fer from designing questions for interviews or JAD sessions? 21. What are typical response rates for questionnaires and how can you improve them? 22. What is document analysis? 23. How does the formal system differ from the informal system? How does document analysis help you under- stand both? 24. What are the key aspects of using observation in the information gathering process? 25. Explain factors that can be used to select information gathering techniques. Electronic JAD (e-JAD) Facilitator Formal system Functional requirements Ground rules Informal benchmarking Informal system Interpersonal skills Interview Interview notes Interview report Interview schedule JAD (joint application development) Nonfunctional requirements Observation Open-ended question Outcome analysis Parallelization Process Integration Postsession report Potential business value Probing question Problem analysis Project cost Questionnaire Requirement Requirements definition Requirements determination Risk Root cause Root-cause analysis Sample Scribe Structured interview System proposal System requirements Technology analysis To-be system Top-down interview Unstructured interview Walkthrough 152 Chapter 4 Requirements Determination MINICASES 1. The State Firefighter’s Association has a membership of 15,000. The purpose of the organization is to pro- vide some financial support to the families of deceased member firefighters and to organize a conference each year bringing together firefighters from all over the state. Members are billed dues and calls annually. Calls are additional funds required to take care of payments made to the families of deceased members. The book- keeping work for the association is handled by the elected treasurer, Bob Smith, although it is widely known that his wife, Laura, does all the work. Bob runs unopposed each year at the election, because no one EXERCISES A. Review the Amazon.com Web site. Develop the require- ments definition for the site. Create a list of functional business requirements that the system meets. What dif- ferent kinds of non-functional business requirements does the system meet? Provide examples for each kind. B. Suppose you are going to build a new system that auto- mates or improves the interview process for the career services department of your school. Develop a require- ments definition for the new system. Include both functional and nonfunctional system requirements. Pretend you will release the system in three different versions. Prioritize the requirements accordingly. C. Describe in very general terms the as-is business process for registering for classes at your university. What BPA technique would you use to identify improvements? With whom would you use the BPA technique? What requirements-gathering technique would help you apply the BPA technique? List some examples of improvements that you would expect to find. D. Describe in very general terms the as-is business process for registering for classes at your university. What BPI technique would you use to identify improvements? With whom would you use the BPI technique? What requirements-gathering technique would help you apply the BPI technique? List some examples of improvements that you would expect to find. E. Describe in very general terms the as-is business process for registering for classes at your university. What BPR technique would you use to identify improvements? With whom would you use the BPR technique? What requirements gathering technique would help you apply the BPR technique? List some examples of improve- ments that you would expect to find. F. Suppose your university is having a dramatic increase in enrollment and is having difficulty finding enough seats in courses for students. Perform a technology analysis to identify new ways to help students com- plete their studies and graduate. G. Suppose you are the analyst charged with developing a new system for the university bookstore so students can order books online and have them delivered to their dorms or off-campus housing. What requirements- gathering techniques will you use? Describe in detail how you would apply the techniques. H. Suppose you are the analyst charged with developing a new system to help senior managers make better strategic decisions. What requirements-gathering techniques will you use? Describe in detail how you would apply the techniques. I. Find a partner and interview each other about what tasks each did in the last job you held (full-time, part-time, past, or current). If you haven’t worked before, then assume your job is being a student. Before you do this, develop a brief interview plan. After your partner interviews you, identify the type of interview, inter- view approach, and types of questions used. J. Find a group of students and run a 60-minute JAD ses- sion on improving alumni relations at your university. Develop a brief JAD plan, select two techniques that will help identify improvements, and then develop an agenda. Conduct the session using the agenda, and write your postsession report. K. Find a questionnaire on the Web that has been created to capture customer information. Describe the pur- pose of the survey, the way questions are worded, and how the questions have been organized. How can it be improved? How will the responses be analyzed? L. Develop a questionnaire that will help gather information regarding processes at a popular restaurant, or the college cafeteria (e.g., ordering, customer service). Give the ques- tionnaire to ten to fifteen students, analyze the responses, and write a brief report that describes the results. M. Contact the career services department at your univer- sity and find all the pertinent documents designed to help students find permanent and/or part-time jobs. Analyze the documents and write a brief report. Minicases 153 wants to take over the tedious and time-consuming job of tracking memberships. Bob is paid a stipend of $8,000 per year, but his wife spends well over twenty hours per week on the job. The organization, however, is not happy with their performance. A computer system is used to track the billing and receipt of funds. This system was developed in 1984 by a computer science student and his father. The system is a DOS-based system written using dBase 3. The most immediate problem facing the treasurer and his wife is the fact that the software package no longer exists, and there is no one around who knows how to maintain the system. One query, in particular, takes seventeen hours to run. Over the years, they have just avoided running this query, although the information in it would be quite useful. Questions from members concerning their statements cannot easily be answered. Usually Bob or Laura just jots down the inquiry and returns a call with the answer. Sometimes it takes three to five hours to find the information needed to answer the question. Often, they have to perform calculations manually because the system was not programmed to handle certain types of queries. When member infor- mation is entered into the system, each field is pre- sented, one at a time, which makes it very difficult to return to a field and correct a value that was entered. Sometimes a new member is entered but disappears from the records. The report of membership used in the conference materials does not alphabetize members by city. Only cities are listed in the correct order. What requirements analysis strategy or strategies would you recommend for this situation? Explain your answer. 2. Brian Callahan, IS project manager, is just about ready to depart for an urgent meeting called by Joe Campbell, manager of manufacturing operations. A major BPI project sponsored by Joe recently cleared the approval hurdle, and Brian helped bring the project through project initiation. Now that the approval committee has given the go-ahead, Brian has been working on the project’s analysis plan. One evening, while playing golf with a friend who works in the manufacturing operations department, Brian learned that Joe wants to push the project’s time frame up from Brian’s original estimate of 13 months. Brian’s friend overheard Joe say,“I can’t see why that IS project team needs to spend all that time analyzing things. They’ve got two weeks scheduled just to look at the existing system! That seems like a real waste. I want that team to get going on building my system.” Because Brian has a little inside knowledge about Joe’s agenda for this meeting, he has been considering how to handle Joe. What do you suggest Brian tell Joe? 3. Barry has recently been assigned to a project team that will be developing a new retail store management system for a chain of submarine sandwich shops. Barry has several years of experience in programming, but he has not done much analysis in his career. He was a little nervous about the new work he would be doing, but was confident he could handle any assign- ment he was given. One of Barry’s first assignments was to visit one of the submarine sandwich shops and prepare an obser- vation report on how the store operates. Barry planned to arrive at the store around noon, but he chose a store in an area of town he was unfamiliar with, and due to traffic delays and difficulty in finding the store, he did not arrive until 1:30. The store manager was not expecting him and refused to let a stranger behind the counter until Barry had her contact the project spon- sor (the director of store management) at company headquarters to verify who he was and what his pur- pose was. After finally securing permission to observe, Barry stationed himself prominently in the work area behind the counter so that he could see everything. The staff had to maneuver around him as they went about their tasks, but there were only minor occasional collisions. Barry noticed that the store staff seemed to be going about their work very slowly and deliberately, but he supposed that was because the store wasn’t very busy. At first, Barry questioned each worker about what he or she was doing, but the store manager eventually asked him not to interrupt their work so much—he was interfering with their service to the customers. By 3:30, Barry was a little bored. He decided to leave, figuring he could get back to the office and pre- pare his report before 5:00 that day. He was sure his team leader would be pleased with his quick comple- tion of his assignment. As he drove, he reflected, There really won’t be much to say in this report. All they do is take the order, make the sandwich, collect the pay- ment, and hand over the order. It’s really simple! Barry’s confidence in his analytical skills soared as he anticipated his team leader’s praise. Back at the store, the store manager shook her head, commenting to her staff, “He comes here at the slowest time of day on the slowest day of the week. He never even looked at all the work I was doing in the back room while he was here—summarizing yesterday’s 154 Chapter 4 Requirements Determination sales, checking inventory on hand, making up resup- ply orders for the weekend ...plus he never even con- sidered our store-opening and -closing procedures. I hate to think that the new store management system is going to be built by someone like that. I’d better con- tact Chuck (the director of store management) and let him know what went on here today.” Evaluate Barry’s conduct of the observation assignment. 4. Anne has been given the task of conducting a survey of sales clerks who will be using a new order-entry system being developed for a household products catalog com- pany. The goal of the survey is to identify the clerks’ opinions on the strengths and weaknesses of the current system. There are about 50 clerks who work in three dif- ferent cities, so a survey seemed like an ideal way of gath- ering the needed information from the clerks. Anne developed the questionnaire carefully and pretested it on several sales supervisors who were available at corporate headquarters. After revising it based on their suggestions, she sent a paper version of the questionnaire to each clerk, asking that it be returned within one week. After one week, she had only three completed questionnaires returned. After another week, Anne received just two more completed questionnaires. Feeling somewhat desperate, Anne then sent out an e-mail version of the questionnaire, again to all the clerks, asking them to respond to the questionnaire by e-mail as soon as possible. She received two e-mail questionnaires and three messages from clerks who had completed the paper version expressing annoyance at being bothered with the same questionnaire a second time. At this point, Anne has just a 14 percent response rate, which she is sure will not please her team leader. What suggestions do you have that could have improved Anne’s response rate to the questionnaire? Behavioral Models Structural Models Functional Models PART TWO Analysis Modeling Analysis modeling 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 proj- ect team will learn about the system. The team then produces the functional model (activity diagrams, use-case descriptions and diagram), structural model (CRC cards and class and object diagrams), and be- havioral models (sequence diagrams, communica- tion diagrams, behavioral state machines, and a CRUD matrix). CHAPTER 5 Functional Modeling CHAPTER 6 Structural Modeling CHAPTER 7 Behavioral Modeling This page intentionally left blank 157157 CHAPTER 5 Functional Modeling Functional models describe business processes and the interaction of an information system with its environment. In object-oriented systems development, two types of models are used to describe the functionality of an information system: activity diagrams and use cases. Activity diagrams support the logical modeling of business processes and workflows. Use cases are used to describe the basic functions of the information system. Both activity diagrams and use cases can be used to describe the current as-is system and the to-be system being devel- oped. This chapter describes functional modeling as a means to document and understand requirements and to understand the function or external behavior of the system. This chapter also introduces use case points as a basis for project size estimation. OBJECTIVES ■ Understand the rules and style guidelines for activity diagrams. ■ Understand the rules and style guidelines for use cases and use-case diagrams. ■ Understand the process used to create use cases and use-case diagrams ■ Be able to create functional models using activity diagrams, use cases, and use-case diagrams. CHAPTER OUTLINE Introduction Business Process Modeling with Activity Diagrams Elements of an Activity Diagram Guidelines for Creating Activity Diagrams Use-Case Descriptions Types of Use Cases Elements of a Use-Case Description Guidelines for Creating Use-Case Descriptions Use-Case Diagrams Actors Association Use Case System Boundary Creating Use-Case Descriptions and Use-Case Diagrams Identifying the Major Use Cases Expanding the Major Use Cases Confirming the Major Use Cases Creating a Use-Case Diagram Refining Project Size and Effort Estimation Using Use-Case Points Applying the Concepts at CD Selections Business Process Modeling with Activity Diagrams Identifing the Major Use Cases Expanding the Major Use Cases Confirming the Major Use Cases Creating the Use-Case Diagram Refining Project Size and Effort Estimation Using Use-Case Points Summary INTRODUCTION The previous chapter discussed the more popular requirements-gathering techniques, such as interviewing, JAD, and observation. Using these techniques, the analyst deter- mined the requirements and created a requirements definition. The requirements defini- tion defined what the system is to do. In this chapter, we discuss how the information that is gathered using these techniques is organized and presented in the form of activity dia- grams and use cases. Because UML has been accepted as the standard notation by the OMG, almost all object-oriented development projects today utilize activity diagrams and use cases to document and organize the requirements that are obtained during the analysis phase.1 An activity diagram can be used for any type of process-modeling activity.2 In this chapter, we describe their use in the context of business process modeling. Process models depict how a business system operates. They illustrate the processes or activities that are performed and how objects (data) move among them. A process model can be used to document a current system (i.e., as-is system) or a new system being developed (i.e., to-be system), whether computerized or not. There are many different process-modeling techniques in use today:3 A use case is a formal way of representing the way in which a business system interacts with its environment. It illustrates the activities performed by the users of the system. As such, use-case modeling is often thought of as an external or functional view of a business process in that it shows how the users view the process, rather than the internal mecha- nisms by which the process and supporting systems operate. Like activity diagrams, use cases can document the current system (i.e., as-is system) or the new system being devel- oped (i.e., to-be system). Activity diagrams and use cases are logical models—models that describe the busi- ness domain’s activities without suggesting how they are conducted. Logical models are sometimes referred to as problem domain models. Reading an activity diagram or use case, in principle, should not indicate if an activity is computerized or manual; if a piece of information is collected by paper form or via the Web; or if information is placed in a filing cabinet or a large database. These physical details are defined during design when the logical models are refined into physical models. These models provide information that is needed to ultimately build the system. By focusing on logical activities first, ana- lysts can focus on how the business should run without being distracted with imple- mentation details. As a first step, the project team gathers requirements from the users (see Chapter 4). Next, using the gathered requirements, the project team models the overall business process using activity diagrams. Next the team uses the identified activities to pinpoint the use cases that occur in the business. They then prepare use-case descriptions and use-case diagrams 158 Chapter 5 Functional Modeling 1 Other similar techniques that are commonly used in non-UML projects are task modeling—see Ian Graham, Migrating to Object Technology (Reading, MA: Addison-Wesley, 1995); and Ian Graham, Brian Henderson-Sellers, and Houman Younessi, The OPEN Process Specification, (Reading, MA: Addison-Wesley, 1997)—and scenario- based design—see John M. Carroll, Scenario-Based Design: Envisioning Work and Technology in System Development (New York: Wiley, 1995). 2 We actually used an activity diagram to describe a simple process in Chapter 1 (see Figure 1-1). 3 Another commonly used process-modeling technique is IDEF0. IDEF0 is used extensively throughout the U.S. federal government. For more information about IDEF0, see FIPS 183: Integration Definition for Function Modeling (IDEF0), Federal Information Processing Standards Publications (Washington, DC: U.S. Department of Commerce, 1993). Also, from an object-oriented perspective, a good book that utilizes the UML to address business process modeling is Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML (New York: Wiley, 2000). for each use case. Use cases are the discrete activities that the users perform, such as selling CDs, ordering CDs, and accepting returned CDs from customers. Users work closely with the project team to create the business process models in the form of activity diagrams and use-case descriptions that contain all the information needed to start modeling the system. Once the activity diagrams and use-case descriptions are prepared, the systems analysts transform them into a use-case diagram, which portrays the external behavioral or func- tional view of the business process. Next, the analyst typically creates class diagrams (see Chapter 6) to create a structural model of the business problem domain. In this chapter, we first describe business process modeling and activity diagrams. Second we describe use cases, their elements, and a set of guidelines for creating use cases. Third, we describe use-case diagrams and how to create them. Fourth, using use cases as a basis, we revisit the topic of project size estimation. BUSINESS PROCESS MODELING WITH ACTIVITY DIAGRAMS Business process models describe the different activities that, when combined together, support a business process. Business processes typically cut across functional depart- ments (e.g., the creation of a new product will involve many different activities that will combine the efforts of many employees in many departments). Furthermore, from an object-oriented perspective, they cut across multiple objects. As such, many of the earlier object-oriented systems development approaches tended to ignore business process modeling. Instead, they focused only on modeling processes via use cases (see later in this chapter) and behavioral models (see Chapter 7). However, today we realize that modeling business processes themselves is a very constructive activity that can be used to make sense out of the gathered requirements (see Chapter 4). The one potential problem of building business process models, from an object-oriented systems development per- spective, is that they tend to reinforce a functional decomposition mindset. However, as long as they are used properly, they are a very powerful tool for communicating the analyst’s current understanding of the requirements with the user. In this section of the chapter, we introduce the use of UML 2.0’s activity diagrams as a means to build busi- ness process models. Activity diagrams are used to model the behavior in a business process independent of objects. In many ways, activity diagrams can be viewed as sophisticated data flow diagrams that are used in conjunction with structured analysis.4 However, unlike data flow diagrams, activity diagrams include notation that addresses the modeling of parallel, concurrent activ- ities and complex decision processes. As such, activity diagrams can be used to model every- thing from a high-level business workflow that involves many different use cases, to the details of an individual use case, all the way down to the specific details of an individual method. In a nutshell, activity diagrams can be used to model any type of process.5 In this chapter, we restrict our coverage of activity diagrams to the modeling of high-level business processes. Business Process Modeling with Activity Diagrams 159 4 For a good introduction to data flow diagrams and structured approaches to systems analysis and design, see Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth, Systems Analysis & Design, 3rd ed. (New York: Wiley, 2006). 5 Technically speaking, activity diagrams combine process modeling ideas from many different techniques includ- ing event models, statecharts, and Petri nets. However, UML 2.0’s activity diagram has more in common with Petri nets than the other process modeling techniques. For a good description of using Petri nets to model busi- ness workflows, see Wil van der Aalst and Kees van Hee, Workflow Management: Models, Methods, and Systems (Cambridge, MA: MIT Press, 2002). Elements of An Activity Diagram Activity diagrams portray the primary activities and the relationships among the activities in a process. Figure 5-1 shows the syntax of an activity diagram. Figure 5-2 presents a simple activity diagram that represents part of an appointment system for a doctor’s office.6 160 Chapter 5 Functional Modeling An action: ■ Is a simple, nondecomposable piece of behavior. ■ Is labeled by its name. Action An activity: ■ Is used to represent a set of actions. ■ Is labeled by its name. An object node: ■ Is used to represent an object that is connected to a set of object flows. ■ Is labeled by its class name. A decision node: ■ Is used to represent a test condition to ensure that the control flow or object flow only goes down one path. ■ Is labeled with the decision criteria to continue down the specific path. A control flow: ■ Shows the sequence of execution. An object flow: ■ Shows the flow of an object from one activity (or action) to another activity (or action). A final-activity node: ■ Is used to stop all control flows and object flows in an activity (or action). A merge node: ■ Is used to bring back together different decision paths that were created using a decision node. An initial node: ■ Portrays the beginning of a set of actions or activities. A final-flow node: ■ Is used to stop a specific control flow or object flow. Activity Class Name [Decision Criteria] [Decision Criteria] FIGURE 5-1 Syntax for an Activity Diagram 6 Due to the actual complexity of the syntax of activity diagrams, we follow a minimalist philosophy in our coverage [see John M. Carrol, The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill (Cambridge, MA: MIT Press, 1990)]. However, the material contained in this section is based on the Unified Modeling Language: Superstructure Version 2.0, ptc/03-08-02 (www.uml.org). Additional useful references include Michael Jesse Chonoles and James A. Schardt, UML 2 for Dummies (Indianapolis, IN: Wiley, 2003); Hans-Erik Eriksson, Magnus Penker, Brian Lyons, and David Fado, UML 2 Toolkit (Indianapolis, IN: Wiley, 2004); and Kendall Scott, Fast Track UML 2.0 (Berkeley, CA: Apress, 2004). For a complete description of all diagrams, see www.uml.org. Actions and Activities Actions and activities are performed for some specific business reason. Actions and activities can represent manual or computerized behavior. They are depicted in an activity diagram as a rounded rectangle (See Figure 5-1). Furthermore, they should have a name that begins with a verb and ends with a noun (e.g., Make Appoint- ment or Make Payment Arrangements). Names should be short, yet contain enough infor- mation so that the reader can easily understand exactly what they do. The only difference between an action and an activity is that an activity can be decomposed further into a set of activities and/or actions, whereas an action represents a simple nondecomposable piece of the overall behavior being modeled. Typically, only activities are used for business process or workflow modeling. Furthermore, in most cases, each activity is associated with a use case. The activity diagram in Figure 5-2 shows six separate but related activities for a typical appointment system used in a doctor’s office: Get Patient Information, Create New Patient, Make Payment Arrangements, Create Appointment, Cancel Appointment, and Change Appointment. Object Nodes Activities and actions typically modify or transform objects. Object nodes model these objects in an activity diagram. Object nodes are portrayed in an activity dia- gram as rectangles (See Figure 5-1). The name of the class of the object is written inside the Business Process Modeling with Activity Diagrams 161 Get Patient Information Appt Request Info Appt Appt Request Info Appt Create New Patient Make Payment Arrangements [New Patient] [Old Patient] Cancel Appointment Change AppointmentCreate Appointment FIGURE 5-2 Activity Diagram for Appointment System rectangle. Essentially, object nodes represent the flow of information from one activity to another activity. The simple appointment system portrayed in Figure 5-2 shows object nodes flowing from the Create Appointment and Change Appointment activities. Control Flows and Object Flows There are two different types of flows in activity dia- grams: control and object (See Figure 5-1). Control flows model the paths of execution through a business process. A control flow is portrayed as a solid line with an arrowhead on it showing the direction of flow. Control flows can be attached only to actions or activ- ities. Figure 5-2 portrays a set of control flows through a doctor’s office’s appointment sys- tem. Object flows model the flow of objects through a business process. Because activities and actions modify or transform objects, object flows are necessary to show the actual objects that flow into and out of the actions or activities.7 An object flow is depicted as a dashed line with an arrowhead on it showing the direction of flow. An individual object flow must be attached to an action or activity on one end and an object node on the other end. Figure 5-2 portrays a set of control and object flows through the appointment system of a doctor’s office. Control Nodes There are seven different types of control nodes in an activity diagram: initial, final-activity, final-flow, decision, merge, fork, and join (see Figure 5-1). An initial node portrays the beginning of a set of actions or activities.8 An initial node is shown as a small, filled-in circle. A final-activity node is used to stop the process being modeled. Any time a final-activity node is reached, all actions and activities are ended immediately, regardless of whether they are completed. A final-activity node is represented as a circle surrounding a small, filled-in circle, making it resemble a bull’s eye. A new control node added to the activity diagram in UML 2.0 is the final-flow node. A final-flow node is simi- lar to a final-activity node, except that it stops a specific path of execution through the busi- ness process but allows the other concurrent or parallel paths to continue. A final-flow node is shown as a small circle with an X in it. The decision and merge nodes support modeling the decision structure of a business process. The decision node is used to represent the actual test condition that determines which of the paths exiting the decision node is to be traversed. In this case, each exiting path must be labeled with a guard condition. A guard condition represents the value of the test for that particular path to be executed. For example, in Figure 5-2, the decision node immediately below the Get Patient Information activity has two mutually exclusive paths that could be executed: one for old, or previous, patients, the other for new patients. The merge node is used to bring back together multiple mutually exclusive paths that have been split based on an earlier decision (e.g., the old- and new-patient paths in Figure 5-2 are brought back together). However, sometimes, for clarity purposes, it may be better not to use a merge node. For example, in Figure 5-3, which of the two activity diagrams, both rep- resenting an overview level of an order process, is easier to understand, the one on the left or the one on the right? The one on the left contains a merge node for the More Items on Order question, but the one on the right does not. In a sense, the decision node is playing double duty in the diagram on the right. It also serves as a merge node. Technically speak- ing, we should not omit the merge node, however, sometimes being technically correct according to the UML’s diagramming rules may actually cause the diagram to become con- fusing. From a business process modeling perspective, a good deal of common sense can go a long way. 162 Chapter 5 Functional Modeling 7 These are identical to data flows in data flow diagrams. 8 For those familiar with IBM flowcharts, this is similar to the start node. The fork and join nodes allow parallel and concurrent processes to be modeled (see Figure 5-1). The fork node is used to split the behavior of the business process into multiple parallel or concurrent flows. Unlike the decision node, the paths are not mutually exclusive (i.e., both paths are executed concurrently). For example, in Figure 5-4, the fork node is used to show that two concurrent, parallel processes are to be executed. In this case, each process is executed by two separate processors (parents). The purpose of the join node is similar to that of the merge node. The join node simply brings back together the separate parallel or concurrent flows in the business process into a single flow. Swimlanes As already described, activity diagrams can model a business process indepen- dent of any object implementation. However, there are times when it helps to break up an activity diagram in such a way that it can be used to assign responsibility to objects or indi- viduals who would actually perform the activity. This is especially useful when modeling a business workflow and is accomplished through the use of swimlanes. In Figure 5-4, the Business Process Modeling with Activity Diagrams 163 [Item Available] [Item Not Available] [More Items on Order] [No More Items on Order] Place Order Process Order Back-order ItemProcess Item Process Item [Item Available] [Item Not Available] [More Items on Order] [No More Items on Order] Place Order Process Order Back-order Item FIGURE 5-3 Two Very Similar Activity Diagrams swimlanes are used to break up among two parents the making of a school lunch compris- ing a peanut butter and jelly sandwich, a drink, and dessert. In this case, we use vertical swimlanes. We could also draw the activity diagram using more of a left-to-right orientation instead of a top-down orientation. In that case, the swimlanes would be drawn horizontally. In an actual business workflow, there would be activities that should be associated with roles of individuals involved in the business workflow (e.g., employees or customers) and the activities to be accomplished by the information system being created. This association 164 Chapter 5 Functional Modeling First Parent Second Parent Get Jelly Get Bread Get Drink Get Dessert Get Peanut Butter Create Sandwich Create Lunch Get Lunch Box Put Lunch in Box FIGURE 5-4 Activity Diagram for Making a School Box Lunch of activities with external roles, internal roles, and the system is very useful when creating the use-case descriptions and diagrams described later in this chapter. Guidelines for Creating Activity Diagrams Scott Ambler suggests the following guidelines when creating activity diagrams:9 1. Because an activity diagram can be used to model any kind of process, you should set the context or scope of the activity being modeled. Once you have determined the scope, you should give the diagram an appropriate title. 2. You must identify the activities, control flows, and object flows that occur between the activities. 3. You should identify any decisions that are part of the process being modeled. 4. You should attempt to identify any prospects for parallelism in the process. 5. You should draw the activity diagram. When drawing an activity diagram, the diagram should be limited to a single initial node that starts the process being modeled. This node should be placed at the top or top left of the diagram, depending on the complexity of the diagram. Furthermore, for most business processes, there should only be a single final-activity node. This node should be placed at the bottom or bottom right of the diagram (see Figures 5-2, 5-3, and 5-4). Because most high-level business processes are sequential, not parallel, the use of a final-flow node should be limited. When modeling high-level business processes or workflows, only the more important decisions should be included in the activity diagrams. In those cases, the guard conditions associated with the outflows of the decision nodes should be mutually exclusive. Further- more, the outflows and guard conditions should form a complete set (i.e., all potential values of the decision are associated with one of the flows). As in decision modeling, forks and joins should be included only to represent the more important parallel activities in the process. For example, an alternative version of Figure 5-4 may not include the forks and joins associated with the Get Jelly, Get Bread, Get Peanut Butter, Get Drink, and Get Dessert activities. This would greatly simplify the diagram.10 Business Process Modeling with Activity Diagrams 165 9 The guidelines presented here are based on work done by Scott Ambler. For more details, see Scott W. Ambler, The Object Primer: The Application Developer’s Guide to Object Orientation and the UML, 2nd ed. (Cambridge, UK: Cambridge University Press/SIGS Books, 2001); and Scott W. Ambler, The Elements of UML Style (Cambridge, UK: Cambridge University Press, 2003). 10 In fact, the only reason we depicted the diagram in Figure 5-3 with the multiple fork and join nodes was to demonstrate that it could be done. Look at the activity diagram for the appointment system in Figure 5-2. Think of one more activity that a user might ask for when gathering requirements for this system (e.g., maintaining patient insurance information). Questions 1. How would you depict this on the existing diagram? 2. After adding the activity to the diagram, what is your recommendation? 3. Would you keep the new activity within the scope of this system? Why or why not? 5-1 Activity DiagramsYOUR TURN When laying out the activity diagram, line crossings should be minimized to enhance the readability of the diagram. The activities on the diagram should also be laid out in a left-to-right and/or top-to-bottom order, based on the order in which the activities are exe- cuted. For example, in Figure 5-4, the Create Sandwich activity takes place before the Cre- ate Lunch activity. Swimlanes should be used only to simplify the understanding of an activity diagram. Furthermore, the swimlanes should enhance the readability of a diagram. For example, when using a horizontal orientation for swimlanes, the top swimlane should represent the most important object or individual involved with the process. The order of the remaining swimlanes should be based on minimizing the number of flows crossing the different swimlanes. Also, when there are object flows among the activities associated with the dif- ferent individuals (swimlanes) executing the activities of the process, it is useful to show the actual object flowing from one individual to another individual by including an object node between the two individuals (i.e., between the two swimlanes). This, of course, impacts how the swimlanes should be placed on the diagram. Finally, any activity that does not have any outflows or any inflows should be chal- lenged. Activities with no outflows are referred to as black-hole activities. If the activity is truly an end point in the diagram, the activity should have a control flow from it to a final- activity or final-flow node. An activity that does not have any inflow is known as a miracle activity. In this case, the activity is either missing an inflow from the initial node of the dia- gram or from another activity. USE-CASE DESCRIPTIONS Use cases are simple descriptions of a system’s functions from the bird’s-eye view of the users.11 Use-case diagrams are functional diagrams in that they portray the basic functions of the system—that is, what the users can do and how the system should respond to the user’s actions.12 Creating use-case diagrams is a two-step process: First, the users work with the pro- ject team to write text-based use-case descriptions; second, the project team translates the use- case descriptions into formal use-case diagrams. Both the use-case descriptions and the use-case diagrams are based on the identified requirements and the activity diagram description of the business process. Use-case descriptions contain all the information needed to produce use-case diagrams. Although it is possible to skip the use-case description step and move directly to cre- ating use-case diagrams and the other diagrams that follow, users often have difficulty describ- ing their business processes using only use-case diagrams. Through the creation of use-case descriptions, users can describe the required details of each individual use case. As to which should come first—use-case descriptions or a use-case diagram—technically speaking, it really does not matter. Both should be done to fully describe the requirements that an information system must meet. In this text, we present the creation of a use-case description first.13 166 Chapter 5 Functional Modeling 11 For a more detailed description of use-case modeling, see Alistair Cockburn, Writing Effective Use Cases (Read- ing, MA: Addison-Wesley, 2001). 12 Nonfunctional requirements, such as reliability requirements and performance requirements, are often documented outside of the use case through more traditional requirements documents. See Gerald Kotonya and Ian Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998); Benjamin L. Kovitz, Practical Software Requirements: A Manual of Content & Style (Greenwich, CT: Manning, 1999); Dean Leffingwell and Don Widrig, Managing Software Requirements: A Unified Approach (Reading, MA: Addison-Wesley, 2000); and Richard H. Thayer, M. Dorfman, and Sidney C. Bailin (eds.), Software Requirements Engineering, 2nd ed. (Los Alamitos, CA: IEEE Computer Society, 1997). 13 Practically speaking, the analyst and users will iterate between the descriptions and diagram. Do not worry about which comes first. Whichever seems to work with the user community of the current project is the way that it should be done. Use cases are the primary drivers for all the UML diagramming techniques. A use case communicates at a high level what the system needs to do, and all the UML diagramming techniques build on this by presenting the use-case functionality in a different way for a dif- ferent purpose. Use cases are the building blocks by which the system is designed and built. Use cases capture the typical interaction of the system with the system’s users (end users and other systems). These interactions represent the external, or functional, view of the system from the perspective of the user. Each use case describes one and only one func- tion in which users interact with the system,14 although a use case may contain several paths that a user can take while interacting with the system (e.g., when searching for a book in a Web bookstore, the user might search by subject, by author, or by title). Each possible execution path through the use case is referred to as a scenario. Another way to look at a scenario is as if a scenario is an instantiation of a specific use case. Scenarios are used exten- sively in behavioral modeling (see Chapter 7). Finally, by identifying all scenarios and try- ing to execute them through role playing CRC cards (see Chapter 6), you will be testing the clarity and completeness of your evolving understanding of the system being developed.15 When creating use cases, the project team must work closely with the users to gather the requirements needed for the use cases. This is often done through interviews, JAD ses- sions, and observation. Gathering the requirements needed for a use case is a relatively sim- ple process, but it takes considerable practice. A good place to look for potential use cases is the activity diagram representation of the business process. In many cases, the activities identified in the activity diagram will become the use cases in the business process being modeled. The key thing to remember is that each use case is associated with one and only one role that users have in the system. For example, a receptionist in a doctor’s office may play multiple roles—he or she can make appointments, answer the telephone, file medical records, welcome patients, and so on. Furthermore, it is possible that multiple users will play the same role. As such, use cases should be associated with the roles played by the users and not with the users themselves. Types of Use Cases There are many different types of use cases. We suggest two separate dimensions on which to classify a use case based on the purpose of the use case and the amount of information that the use case contains: (1) overview versus detail; and (2) essential versus real. An overview use case is used to enable the analyst and user to agree on a high-level overview of the requirements. Typically, they are created very early in the process of under- standing the system requirements, and they document only basic information about the use case, such as its name, ID number, primary actor, type, and a brief description. Use-Case Descriptions 167 14 This is one key difference between traditional structured analysis and design approaches and object-oriented approaches. If you have experience using traditional structured approaches (or have taken a course on them), then this is an important change for you. If you have no experience with structured approaches, then you can skip this footnote. The traditional structured approach is to start with one overall view of the system and to model processes via functional decomposition—the gradual decomposition of the overall view of the system into the smaller and smaller parts that make up the whole system. On the surface, this is similar to business process modeling using activity diagrams. However, functional decomposition is not used with object-oriented approaches. Instead, each of the use cases documents one individual piece of the system; there is no overall use case that documents the entire system in the same way that a level 0 data flow diagram attempts to document the entire system. By remov- ing this overall view, object-oriented approaches make it easier to decouple the system’s objects so they can be designed, developed, and reused independently of the other parts of the system. Although this lack of an overall view may prove unsettling initially, it is very liberating over the long term. 15 For presentation purposes, we defer discussion of role-playing to Chapter 6, walkthroughs to Chapter 8, and testing to Chapter 13. Once the user and the analyst agree upon a high-level overview of the requirements, the overview use cases can be converted to detail use cases. A detail use case typically doc- uments, as far as possible, all the information needed for the use case. An essential use case is one that describes only the minimum essential issues necessary to understand the required functionality. A real use case goes further and describes a specific set of steps. For example, an essential use case in a dentist office might say that the receptionist should attempt to match the patient’s desired appointment times with the available times, whereas a real use case might say that the receptionist should look up the available dates on the calendar using MS Exchange to determine if the requested appointment times were avail- able. The primary difference is that essential use cases are implementation independent, whereas real use cases are detailed descriptions of how to use the system once it is imple- mented. As such, real use cases tend to be used only in detailed design, implementation, and testing. Elements of a Use-Case Description A use-case description contains all the information needed to build the diagrams that fol- low, but it expresses the information in a less formal way that is usually simpler for users to understand. Figure 5-5 shows a sample use-case description.16 A use-case description has three basic parts: overview information, relationships, and the flow of events. Overview Information The overview information identifies the use case and provides basic background information about the use case. The use-case name should be a verb–noun phrase (e.g., Make Appointment). The use-case ID number provides a unique way to find every use case and also enables the team to trace design decisions back to a specific requirement. As already stated, the use-case type is either overview or detail and essential or real. The primary actor is usually the trigger of the use case—the person or thing that starts the execution of the use case. The primary purpose of the use case is to meet the goal of the primary actor. The brief description is typically a single sentence that describes the essence of the use case. The importance level can be used to prioritize the use cases. As described in Chapter 1, object-oriented development tends to follow a RAD-phased development approach, in which some parts of the system are developed first and other parts are developed only in later versions. The importance level enables the users to explicitly prioritize which business functions are most important and need to be part of the first version of the system and which are less important and can wait until later versions if necessary. The importance level can use a fuzzy scale, such as high, medium, and low (e.g., in Figure 5-5 we have assigned an importance level of high to the Make Appointment use case). It can also be done more formally using a weighted average of a set of criteria. For example, Larman17 suggests rating each use case over the following criteria using a scale from zero to five: ■ The use case represents an important business process. ■ The use case supports revenue generation or cost reduction. ■ Technology needed to support the use case is new or risky and therefore will require considerable research. 168 Chapter 5 Functional Modeling 16 Currently, there is no standard set of elements for a use case. The elements described in this section are based on recommendations contained in Alistair Cockburn, Writing Effective Use Cases (Reading, MA: Addison-Wesley, 2001); Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed. (Upper Saddle River, NJ: Prentice Hall, 2002); Brian Henderson-Sellers and Bhuvan Unhelkar, OPEN modeling with UML (Reading, MA: Addison-Wesley, 2000); Graham, Migrating to Object Tech- nology; and Alan Dennis and Barbara Haley Wixom, Systems Analysis and Design, 2nd ed. (New York: Wiley, 2003). 17 Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Use-Case Descriptions 169 Use-Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of Events: Subflows: Alternate/Exceptional Flows: Type: External Make appointment 2 High Patient Patient - wants to make, change, or cancel an appointment Doctor - wants to ensure patientís nee ds are met in a timely manner Use Case Type: Detail, essential Patient calls and asks for a new appointment or asks to cancel or change an existing appointment. Patient Make Payment Arrangements Create NewPatient 1. The Patient contacts the office regarding an appointment. 2. The Patient provides the Receptionist withhis orher name and address. 3. The Receptionist validates that the Patient exists in the Patient database. 4. The Receptionist executes the Make Payment Arrangements use case. 5. The Receptionist asks Patient if he or she would like to make a new appointment, cancel an existing appointment, or change an existing appointment. S-1: New Appointment 1. The Receptionist asks the Patient forpossible appointment times. 2. The Receptionist matches the Patient’s desired appointment times with available dates and times and schedules the new appointment. S-2: Cancel Appointment 1. The Receptionist asks the Patient for the old appointment time. 2. The Receptionist finds the current appointment in the appointment file and cancels it. S-3: Change Appointment 1. The Receptionist performs the S-2: cancel appointment subflow. 2. The Receptionist performs the S-1: new appointment subflow. S-1, 2a1: The Receptionist proposes some alternative appointment times based on what is available in the appointment schedule. S-1, 2a2: The Patient chooses one of the proposed times ordecides not to make an appointment. 3a: The Receptionist executes the Create NewPatient use case. 6. The Receptionist provides the results of the transaction to the Patient. This use case describes howwe make an appointment as well as changing or canceling an appointment. Relationships: Association: Include: Extend: Generalization: If the patient wants to make a new appointment, the S-1: new appointment subflowis performed. If the patient wants to cancel an existing appointment, the S-2: cancel appointment subflowis performed. If the patient wants to change an existing appointment, the S-3: change appointment subflowis performed. FIGURE 5-5 Sample Use-Case Description ■ Functionality described in the use case is complex, risky, and/or time critical. Depending on a use case’s complexity, it may be useful to consider splitting its implementation over several different versions. ■ The use case could increase understanding of the evolving design relative to the effort expended. TEMPLATE can be found at www.wiley.com /college/dennis A use case may have multiple stakeholders that have an interest in the use case. As such, each use case lists each of the stakeholders with each one’s interest in the use case (e.g., Patient and Doctor). The stakeholders’ list always includes the primary actor (e.g., Patient). Each use case typically has a trigger —the event that causes the use case to begin (e.g., Patient calls and asks for a new appointment or asks to cancel or change an existing appointment). A trigger can be an external trigger, such as a customer placing an order or the fire alarm ringing, or it can be a temporal trigger, such as a book being overdue at the library or the need to pay the rent. Relationships Use-case relationships explain how the use case is related to other use cases and users. There are four basic types of relationships: association, extend, include, and gener- alization. An association relationship documents the communication that takes place between the use case and the actors that use the use case. An actor is the UML representation for the role that a user plays in the use case. For example, in Figure 5-5, the Make Appointment use case is associated with the actor Patient. In this case, a patient makes an appointment. All actors involved in the use case are documented with the association relationship. An extend relationship represents the extension of the functionality of the use case to incorporate optional behavior. In Figure 5-5, the Make Appointment use case condition- ally uses the Create New Patient use case. This use case is executed only if the patient does not exist in the patient database. As such, it is not part of the normal flow of events and should be modeled with an extend relationship and an alternate/exceptional flow. An include relationship represents the mandatory inclusion of another use case. The include relationship enables functional decomposition—the breaking up of a complex use case into several simpler ones. For example, in Figure 5-5, the Make Payment Arrangements use case was considered to be complex and complete enough to be factored out as a sepa- rate use case that could be executed by the Make Appointment use case. The include rela- tionship also enables parts of use cases to be reused by creating them as separate use cases. The generalization relationship allows use cases to support inheritance. For example, the use case in Figure 5-5 could be changed such that a new patient could be associated with a specialized use case called Make New Patient Appointment and an old patient could be associated with a Make Old Patient Appointment. The common, or generalized, behav- ior that both the Make New Patient Appointment and Make Old Patient Appointment use cases contain would be placed in the generalized Make Appointment use case—for exam- ple, the include relationship to the Make Payment Arrangements use case. In other words, the Make New Patient Appointment and Make Old Patient Appointment use cases would inherit the Make Payment Arrangements use case from the Make Appointment use case. The specialized behavior would be placed in the appropriate specialized use case. For example, the extend relationship to the Create New Patient use case would be placed with the specialized Make New Patient Appointment use case as an included use case. Flow of Events Finally, the individual steps within the business process are described. There are three different categories of steps, or flows of events, that can be documented: normal flow of events, subflows, and alternate, or exceptional, flows: 1. The normal flow of events includes only those steps that normally are executed in a use case. The steps are listed in the order in which they are performed. In Figure 5-5, the patient and the receptionist have a conversation regarding the patient’s name, address, and action to be performed. 2. In some cases, the normal flow of events should be decomposed into a set of sub- flows to keep the normal flow of events as simple as possible. In Figure 5-5, we have identified three subflows: New Appointment, Cancel Appointment, and 170 Chapter 5 Functional Modeling Change Appointment. Each of the steps of the subflows is listed. These subflows are based on the control flow logic in the activity diagram representation of the business process (see Figure 5-2). Alternatively, we could replace a subflow with a separate use case that could be incorporated via the include relationships (see the earlier discussion). However, this should be done only if the newly created use case makes sense by itself. For example, in Figure 5-5, does it make sense to factor out a Create New Appointment, Cancel Appointment, and/or Change Appoint- ment use case? If it does, then the specific subflow(s) should be replaced with a call to the related use case, and the use case should be added to the include rela- tionship list. 3. Alternate or exceptional flows are ones that do happen but are not considered to be the norm. These must be documented. For example, in Figure 5-5, we have identi- fied four alternate or exceptional flows. The first one simply addresses the need to create a new patient before the new patient can make an appointment. Normally, the patient would already exist in the patient database. Like the subflows, the pri- mary purpose of separating out alternate or exceptional flows is to keep the nor- mal flow of events as simple as possible. Again, as with the subflows, replace the alternate or exceptional flows with separate use cases that could be integrated via the extend relationship (see the earlier discussion). When should events be factored out from the nomal flow of events into subflows or subflows and/or alternate or exceptional flows be factored out into separate use cases? Or, when should things simply be left alone? The primary criteria should be based on the level of complexity that the use case entails. The more difficult it is to understand the use case, the more likely events should be factored out into subflows, or subflows and/or alternate or exceptional flows should be factored out into separate use cases that are called by the cur- rent use case. This, of course, will create more use cases. As such, the use case diagram (see the following discussion) will become more cluttered. Practically speaking, we must decide which makes more sense. This will vary greatly, depending on the problem and the client. Remember, we are trying to represent, in as complete and concise manner as possible, our understanding of the business processes that we are investigating so that the client can val- idate the requirements that we are modeling. Therefore, there really is no single right answer. It really depends on the analyst, the client, and the problem. Optional Characteristics There are other characteristics of use cases that can be docu- mented. These include the level of complexity of the use case, the estimated amount of time it takes to execute the use case, the system with which the use case is associated, spe- cific data flows between the primary actor and the use case, any specific attribute, con- straint, or operation associated with the use case, any preconditions that must be satisfied for the use case to execute, or any guarantees that can be made based on the execution of the use case. As we noted at the beginning of this section, there is no standard set of char- acteristics of a use case that must be captured. In this book, we suggest that the informa- tion contained in Figure 5-5 is the minimal amount to be captured. Guidelines for Creating Use-Case Descriptions The essence of a use case is the flow of events. Writing the flow of events in a manner that is useful for later stages of development generally comes with experience. Figure 5-6 pro- vides a set of guidelines that have proven to be useful.18 Use-Case Descriptions 171 18 These guidelines are based on Cockburn, Writing Effective Use Cases, and Graham, Migrating to Object Technology. First, write each individual step in the form subject–verb–direct object and, optionally, preposition–indirect object. This form has become known as SVDPI sentences. This form of sentence has proven to be useful in identifying classes and operations (see Chapter 6). For example, in Figure 5-5, the first step in the normal flow of events, the Patient contacts the office regarding an appointment, suggests the possibility of three classes of objects: Patient, Office, and Appointment. This approach simplifies the process of identifying the classes in the structural model (described in Chapter 6). SVDPI sentences cannot be used for all steps, but they should be used whenever possible. Second, make clear who or what is the initiator of the action and who is the receiver of the action in each step. Normally, the initiator should be the subject of the sentence and the receiver should be the direct object of the sentence. For example, in Figure 5-5, the sec- ond step, Patient provides the Receptionist with his or her name and address, clearly por- trays the Patient as the initiator and the Receptionist as the receiver. Third, write the step from the perspective of an independent observer. To accomplish this, each step may have to be written first from the perspective of both the initiator and the receiver. Based on the two points of view, the bird’s eye view version can then be written. For example, in Figure 5-5, the Patient provides the Receptionist with his or her name and address, neither the patient’s nor the receptionist’s perspective is represented. Fourth, write each step at the same level of abstraction. Each step should make about the same amount of progress toward completing the use case as each of the other steps. On high-level use cases, the amount of progress could be very substantial, whereas in a low-level use case, each step could represent only incremental progress. For example, in Figure 5-5, each step represents about the same amount of effort to complete. Fifth, ensure that the use case contains a sensible set of actions. Each use case should represent a transaction. Therefore, each use case should comprise four parts: 1. The primary actor initiates the execution of the use case by sending a request (and possibly data) to the system. 2. The system ensures that the request (and data) is valid. 3. The system processes the request (and data) and possibly changes its own inter- nal state. 4. The system sends the primary actor the result of the processing. For example, in Figure 5-5, (1) the patient requests an appointment (steps 1 and 2), (2) the receptionist determines if the patient exists in the database (step 3), (3) the recep- tionist sets up the appointment transaction (steps 4 and 5), and (4) the receptionist gives the time and date of the appointment to the patient (step 6). The sixth guideline is the KISS principle. If the use case becomes too complex and/or too long, the use case should be decomposed into a set of use cases. Furthermore, if the normal flow of events of the use case becomes too complex, subflows should be used. For 172 Chapter 5 Functional Modeling 1. Write each set in the form of subject-verb-direct object (and sometimes preposition-indirect object). 2. Make sure it is clear who the initiator of the step is. 3. Write the steps from the perspective of the independent observer. 4. Write each step at about the same level of abstraction. 5. Ensure the use case has a sensible set of steps. 6. Apply the KISS principle liberally. 7. Write repeating instructions after the set of steps to be repeated. FIGURE 5-6 Guidelines for Writing Effective Use-Case Descriptions example, in Figure 5-5, the fifth step in the normal flow of events was sufficiently complex to decompose it into three separate subflows. However, as stated previously, care must be taken to avoid the possibility of decomposing too much. Most decomposition should be done with classes (see Chapter 6). The seventh guideline deals with repeating steps. Normally, in a programming language such as Visual Basic or C, we put loop definition and controls at the beginning of the loop. However, because the steps are written in simple English, it is normally better to simply write Repeat steps A through E until some condition is met after step E. It makes the use case more readable to people unfamiliar with programming. USE-CASE DIAGRAMS In the previous section, we learned what a use case is and discussed a set of guidelines for writing effective use-case descriptions. In this section, we learn how the use case is the building block for the use-case diagram, which summarizes, in one picture, all the use cases for the part of the system being modeled. An analyst can use the use-case dia- gram to better understand the functionality of the system at a very high level. Typically, the use-case diagram is drawn early on in the SDLC when gathering and defining requirements for the system because it provides a simple, straightforward way of com- municating to the users exactly what the system will do. In this manner, the use-case diagram can encourage the users to provide additional requirements that the written use case may not uncover. A use-case diagram illustrates in a very simple way the main functions of the system and the different kinds of users that will interact with it. Figure 5-7 describes the basic syn- tax rules for a use-case diagram. Figure 5-8 presents a use-case diagram for a doctor’s office appointment system. We can see from the diagram that patients, doctors, and management personnel will use the appointment system to make appointments, record availability, and produce schedule information, respectively. Actors The labeled stick figures on the diagram represent actors (see Figure 5-7). An actor is not a specific user, but instead is a role that a user can play while interacting with the system. An actor can also represent another system in which the current system interacts. In this case, the actor optionally can be represented by a rectangle containing <> and the name of the system. Basically, actors represent the principal elements in the environment in which the system operates. Actors can provide input to the system, receive output from the Use-Case Diagrams 173 Look at the activity diagram for the appointment sys- tem in Figure 5-2 and the use case that was created in Figure 5-5. Create your own use case based on an activity in the activity diagram or the activity that you created in Your Turn 5-1. Use Figure 5-6 to guide your efforts. 5-2 Use CasesYOUR TURN 174 Chapter 5 Functional Modeling An actor: ■ Is a person or system that derives benefit from and is external to the subject. ■ Is depicted as either a stick figure (default) or if a nonhuman actor is involved, as a rectangle with <> in it (alternative). ■ Is labeled with its role. ■ Can be associated with other actors using a specialization/superclass association, denoted by an arrow with a hollow arrowhead. ■ Is placed outside the subject boundary. A use case: ■ Represents a major piece of system functionality. ■ Can extend another use case. ■ Can include another use case. ■ Is placed inside the system boundary. ■ Is labeled with a descriptive verb–noun phrase. A subject boundary: ■ Includes the name of the subject inside or on top. ■ Represents the scope of the subject, e.g., a system or an individual business process. An include relationship: ■ Represents the inclusion of the functionality of one use case within another. ■ Has an arrow drawn from the base use case to the used use case. An extend relationship: ■ Represents the extension of the use case to include optional behavior. ■ Has an arrow drawn from the extension use case to the base use case. A generalization relationship: ■ Represents a specialized use case to a more generalized one. ■ Has an arrow drawn from the specialized use case to the base use case. An association relationship: ■ Links an actor with the use case(s) with which it interacts. <> Actor/Role Subject Actor/Role Use Case <> <> ** FIGURE 5-7 Syntax for Use-Case Diagram system, or both. The diagram in Figure 5-8 shows that three actors will interact with the appointment system (a patient, a doctor, and management). Sometimes an actor plays a specialized role of a more general type of actor. For exam- ple, there may be times when a new patient interacts with the system in a way that is some- what different than a general patient. In this case, a specialized actor (i.e., new patient) can be placed on the model, shown using a line with a hollow triangle at the end of the more gen- eral actor (i.e., patient). The specialized actor will inherit the behavior of the more general actor and extend it in some way (see Figure 5-9). Can you think of some ways in which a new patient may behave differently than an existing patient? Association Use cases are connected to actors through association relationships; these relationships show with which use cases the actors interact (see Figure 5-7). A line drawn from an actor to a use case depicts an association. The association typically represents two-way communication between the use case and the actor. If the communication is only one way, then a solid arrow- head can be used to designate the direction of the flow of information. For example, in Fig- ure 5-8 the Patient actor communicates with the Make Appointment use case. Because there are no arrowheads on the association, the communication is two-way. Finally, it is possible to Use-Case Diagrams 175 Appointment System Patient Produce Schedule Information Make Appointment Management Doctor Record Availability ** ** ** FIGURE 5-8 Use-Case Diagram for the Appointment System Appointment System Patient New Patient Produce Schedule Information Make Appointment Management Doctor Record Availability ** ** **FIGURE 5-9 Use-Case System with Specialized Actor represent the multiplicity of the association. Figure 5-8 shows an asterisk (*) at either end of the association between the Patient and the Make Appointment use case. This simply desig- nates that an individual patient (instance of the Patient actor) executes the Make Appoint- ment use case as many times as he or she wishes and that it is possible for the appointment part of the Make Appointment use case to be executed by many different patients. In most cases, this type of many-to-many relationship is appropriate. However, it is possible to restrict the number of patients that can be associated with the Make Appointment use case. We dis- cuss the multiplicity issue in detail in the next chapter in regards to class diagrams. Use Case A use case, depicted by an oval in the UML, is a major process that the system will perform that benefits an actor or actors in some way (see Figure 5-7), and it is labeled using a descrip- tive verb–noun phrase. We can tell from Figure 5-8 that the system has three primary use cases: Make Appointment, Produce Schedule Information, and Record Availability. There are times when a use case includes, extends, or generalizes the functionality of another use case in the diagram. These are shown using include, extend, and generalization relationships. To increase the ease of understanding a use-case diagram, higher-level use cases are normally drawn above the lower-level ones. It may be easier to understand these relationships with the help of examples. Let’s assume that every time a patient makes an appointment, the patient is asked to verify payment arrangements. However, it is occa- sionally necessary to actually make new payment arrangements. Therefore, we may want to have a use case called Make Payment Arrangements that extends the Make Appointment use case to include this additional functionality. In Figure 5-10, an arrow labeled with extend was drawn between the Make Payment Arrangements use case and the Make Appointment use case to denote this special use-case relationship. Furthermore, the Make Payment Arrangements use case was drawn lower than the Make Appointment use case. Similarly, there are times when a single use case contains common functions that are used by other use cases. For example, suppose there is a use case called Manage Schedule that performs some routine tasks needed to maintain the doctor’s office appointment schedule, and the two use cases Record Availability and Produce Schedule Information both perform the routine tasks. Figure 5-10 shows how we can design the system so that Manage Schedule is a shared use case that is used by others. An arrow labeled with include is used to denote the include relationship and the included use case is drawn below the use cases that contain it. Finally, there are times when it makes sense to use a generalization relationship to sim- plify the individual use cases. For example in Figure 5-10, the Make Appointment use case has been specialized to include a use case for an Old Patient and a New Patient. The Make Old Patient Appt use case inherits the functionality of the Make Appointment use case (including the Make Payment Arrangements use-case extension) and extends its own functionality with the Update Patient Information use case. The Make New Patient Appt use case also inherits all the functionality of the generic Make Appointment use case and calls the Create New Patient use case, which includes the functionality necessary to insert the new patient into the patient database. The generalization relationship is represented as an unlabeled hollow arrow with the more general use case being higher than the lower-use cases. Also notice that we have added a second specialized actor, Old Patient, and that the Patient actor is now simply a gen- eralization of the Old and New Patient actors. Subject Boundary The use cases are enclosed within a subject boundary, which is a box that defines the scope of the system and clearly delineates what parts of the diagram are external or internal to it (see Figure 5-7). One of the more difficult decisions to make is where to draw the subject 176 Chapter 5 Functional Modeling boundary. A subject boundary can be used to separate a software system from its environ- ment, a subsystem from other subsystems within the software system, or an individual process in a software system. They also can be used to separate an information system, including both software and internal actors, from its environment. As such, care should be taken to decide carefully what the scope of the information system is to be. The name of the subject can appear either inside or on top of the box. The subject boundary is drawn based on the scope of the system. In the appointment system, the Man- agement and Doctor actors may not be drawn. Remember that actors are outside of the scope of the system. In Figure 5-8, we listed a receptionist as being part of the use case. However, in this case, we assumed that the receptionist is an internal actor who is part of the Make Appointment use case. As such, the receptionist is not drawn on the diagram. 19 Use-Case Diagrams 177 Appointment System Patient New Patient Old Patient Produce Schedule Information Update Patient Information Make Payment Arrangements Make Old Patient Appt. Make New Patient Appt. Create New Patient Make Appointment Management Doctor Record Availability Manage schedule <> <> < > <> <> ** * * ** ** FIGURE 5-10 Extend and Include Relationships 19 In other non-UML approaches to object-oriented systems development, it is possible to represent external actors along with internal actors. In this example, the receptionist would be considered an internal actor (see Graham, Migrating to Object Technology, and Graham, Henderson-Sellers, and Younessi, The OPEN Process Specification). CREATING USE-CASE DESCRIPTIONS AND USE-CASE DIAGRAMS Use cases describe the functionality of a system and are a model of the dialog between the actors and the system. As such, they tend to be used to model both the contexts of the sys- tem and the detailed requirements for the system. Even though the primary purpose of use cases is to document the functional requirements of the system, they also are used as a basis for testing the evolving system. In this section, we describe an approach that supports requirements gathering and documentation with use cases. It is important to remember that use cases are used for both the as-is and to-be behavioral models. As-is use cases focus on the current system, whereas to-be use cases focus on the desired new system. The two most common ways to gather information for the use cases are through interviews and JAD sessions (observation is also sometimes used for as-is models). As discussed in Chapter 4, these techniques have advantages and disadvantages. Regardless of whether interviews or JAD sessions are used, recent research shows that some ways to gather the information for use cases are better than others. The most effec- tive process involves using thirteen steps to create use-case descriptions20 and four addi- tional steps to create use-case diagrams (see Figure 5-11). These thirteen steps are performed in order, but of course the analyst often cycles among them in an iterative fashion as he or she moves from use case to use case. 178 Chapter 5 Functional Modeling 20 The approach in this section is based on the work of Cockburn, Writing Effective Use Cases; Graham, Migrating to Object Technology; George Marakas and Joyce Elam, “Semantic Structuring in Analyst Acquisition and Represen- tation of Facts in Requirements Analysis,” Information Systems Research 9, no. 1 (1998): 37–63; and Alan Dennis, Glenda Hayes, and Robert Daniels, “Business Process Modeling with Group Support Systems,” Journal of Manage- ment Information Systems 15, no. 4 (1999): 115–142. Identify the Major Use Cases 1. Review the activity diagram. 2. Find the subject's boundaries. 3. Identify the primary actors and their goals. 4. Identify and write the overviews of the major use cases for the above. 5. Carefully review the current use cases. Revise as needed. Expand the Major Use Cases 6. Choose one of the use cases to expand. 7. Start filling in the details of the chosen use case. 8. Write the normal flow of events of the use case. 9. If the normal flow of events is too complex or long, decompose into subflows. 10. List the possible alternate or exceptional flows. 11. For each alternate or exceptional flow, list how the actor and/or system should react. Confirm the Major Use Cases 12. Carefully review the current set of use cases. Revise as needed. 13. Start at the top again. Create the Use-Case Diagram 1. Draw the subject boundary. 2. Place the use cases on the diagram. 3. Place the actors on the diagram. 4. Draw the associations. FIGURE 5-11 Steps for Writing Effective Use-Case Descriptions and Use-Case Diagrams Identifying the Major Use Cases The first step is to review the activity diagram. This helps the analyst to get a complete overview of the underlying business process being modeled. The second step is to identify the subject’s boundaries. This helps the analyst to iden- tify the scope of the system. However, as we work through the SDLC, the boundary of the system will change. The third step is to identify the primary actors and their goals. The primary actors involved with the system will come from a list of stakeholders and users. However, recall that an actor is a role that a stakeholder or user plays, not a specific user (e.g., doctor, not Dr. Jones). The goals represent the functionality that the system must provide the actor for the system to be a success. Identifying what the tasks are that each actor must perform can facilitate this. For example, does the actor need to create, read, update, or delete (CRUD)21 any information currently in the system, are there any external changes of which an actor must inform the system, or is there any information that the system should give the actor? Steps 2 and 3 are intertwined. As actors are identified and their goals are uncovered, the boundary of the system will change. The fourth step is to identify and write the major use cases, with basic information about each, rather than jumping into one use case and describing it completely (i.e., only an overview use case). Recall from the previous description of the elements of a use case that overview use cases contain only the use case name, ID number, type, primary actor, importance level, and brief description. Creating only overview use cases at this time pre- vents the users and analysts from forgetting key use cases and helps the users explain the overall set of business processes for which they are responsible. It also helps them under- stand how to describe the use cases and reduces the chance of overlap between use cases. It is important at this point to understand and define acronyms and jargon so that the pro- ject team and others from outside the user group can clearly understand the use cases. Again, the activity diagram is a very useful beginning point for this step. The fifth step is to carefully review the current set of use cases. It may be necessary to split some of them into multiple use cases or merge some of them into a single use case. Also, based on the current set, a new use case may be identified. You should remember that identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this point, so you need to remember that the goal at this step is to identify the major use cases and that you are creating only overview use cases. For example, in the doctors’ office exam- ple in Figure 5-10, we defined one use case as Make Appointment. This use case included the cases for both new patients and existing patients, as well as for when a patient changes or cancels an appointment. We could have defined each of these activities (makes an appointment, changes an appointment, or cancels an appointment) as separate use cases, but this would have created a huge set of small use cases. The trick is to select the right size so that you end up with three to nine use cases in each system. If the project team discovers many more than eight use cases, this suggests that the use cases are too small or that the system boundary is too big. If more than nine use cases exist, the use cases should be grouped together into packages (i.e., logical groups of use cases) to make the diagrams easier to read and keep the models at a reasonable level of complex- ity. It is simple at that point to sort the use cases and group together these small use cases into larger use cases that include several small ones or to change the system boundaries.22 Creating Use-Case Descriptions and Use-Case Diagrams 179 21 We describe the use of CRUD matrices in Chapter 7. 22 For those familiar with structured analysis and design, packages serve a similar purpose as the leveling and bal- ancing processes used in data flow diagramming. Packages are described in Chapter 8. Expanding the Major Use Cases The sixth step is to choose one of the major use cases to expand. Using the importance level of the use case can help do this. For example, in Figure 5-5, the Make Appointment use case has an importance level of high. As such, it should be one of the earlier use cases to be expanded. The criteria suggested by Larman23 can also be used to set the prioritization of the use cases, as noted earlier. The seventh step is to start filling in the details on the use-case template. For example, list all of the identified stakeholders and their interests in the use case, the level of impor- tance of the use case, a brief description of the use case, the trigger information for the use case, and the relationships in which the use case participates. The eighth step is to fill in the steps of the normal flow of events required to describe each use case. The steps focus on what the business process does to complete the use case, as opposed to what actions the users or other external entities do. In general, the steps should be listed in the order in which they are performed, from first to last. Remember to write the steps in an SVDPI form whenever possible. In writing the use case, remember the seven guidelines described earlier. The goal at this point is to describe how the chosen use case operates. One of the best ways to begin to understand how an actor works through a use case is to visualize performing the steps in the use case—that is, role-play. The tech- niques of visualizing how to interact with the system and of thinking about how other sys- tems work (informal benchmarking) are important techniques that help analysts and users understand how systems work and how to write a use case. Both techniques (visualization and informal benchmarking) are common in practice. It is important to remember that at this point in the development of a use case, we are interested only in the typical successful execution of the use case. If we try to think of all of the possible combinations of activities that could go on, we will never get anything written down. At this point, we are looking only for the three to seven major steps. As such, focus only on performing the typical process that the use case represents. The ninth step is to ensure that the steps listed in the normal flow of events are not too complex or too long. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps such as take fork out of drawer and put fork on table are much smaller than prepare cake using mix. If we end up with more than seven steps or steps that vary greatly in size, we should go back and review each step care- fully and possibly rewrite the steps. One good approach to produce the steps for a use case is to have the users visualize themselves actually performing the use case and to have them write down the steps as if they were writing a recipe for a cookbook. In most cases the users will be able to quickly define what they do in the as-is model. Defining the steps for to-be use cases may take a bit more coaching. In our experience, the descriptions of the steps change greatly as users work through a use case. Our advice is to use a blackboard or whiteboard (or paper with pencil) that can be easily erased to develop the list of steps, and then write the list on the use-case form. It should be written on the use-case form only after the set of steps is fairly well defined. The tenth step focuses on identifying the alternate or exceptional flows. Alternate or exceptional flows are those flows of success that represent optional or exceptional behav- ior. They tend to occur infrequently or as a result of a normal flow failing. They should be labeled so that there is no doubt as to which normal flow of events it is related. For exam- ple in Figure 5-5, alternate/exceptional flow 3a executes when step 3 fails (i.e., the Patient does not exist in the Patient database). 180 Chapter 5 Functional Modeling 23 Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. The eleventh step is simply to write the description of any alternate or exceptional flows. In other words, if an alternate or exceptional flow is to be executed, describe the response that the actor or system should produce. Like the normal flows and subflows, alternate or exceptional flows should be written in the SVDPI form whenever possible. Confirming the Major Use Cases24 The twelfth step is to carefully review the current set of use cases and to confirm that the use case is correct as written, which means reviewing the use case with the users to make sure each step is correct. The review should look for opportunities to simplify a use case by decomposing it into a set of smaller use cases, merging it with others, looking for common aspects in both the semantics and syntax of the use cases, and identifying new use cases. This is also the time to look into adding the include, extend, or generalization relationships between use cases. The most powerful way to confirm a use case is to ask the user to role- play, or execute the process using the written steps in the use case. The analyst will hand the user pieces of paper labeled as the major inputs to the use case and will have the user fol- low the written steps like a recipe to make sure that those steps really can produce the out- puts defined for the use case using its inputs. The thirteenth and final step is to iterate over the entire set of steps again. Users will often change their minds about what is a use case and what it includes. It is very easy to get trapped in the details at this point, so remember that the goal is to just address the major use cases. Therefore, the analyst should continue to iterate over these steps until he or she and the users believe that a sufficient number of use cases has been documented to begin iden- tifying candidate classes for the structural model (see Chapter 6). As candidate classes are identified, it is likely that additional use cases will be uncovered. Remember, object-oriented systems development is both iterative and incremental. As such, do not worry about identi- fying each and every possible use case at this point in the development of the system. Creating a Use-Case Diagram Basically, drawing the use-case diagram is very straightforward once use cases have been detailed. The actual use-case diagram encourages the use of information hiding. The only parts drawn on the use-case diagram are the system boundary, the use-cases themselves, the actors, and the various associations between these components. The major strength of the use-case diagram is that it provides the user with an overview of the detailed use cases. However, remember that anytime a use case changes, it could impact the use case diagram. There are four major steps in drawing a use-case diagram. First, the use-case diagram starts with the subject boundary. This forms the border of the subject, separating use cases (i.e., the subject’s functionality) from actors (i.e., the roles of the external users). Second, the use cases are drawn on the diagram. These are taken directly from the detailed use-case descriptions. Special use-case associations (include, extend, or generaliza- tion) are also added to the model at this point. Be careful in laying out the diagram. There is no formal order to the use cases, so they can be placed in whatever fashion needed to make the diagram easy to read and to minimize the number of lines that cross. It often is necessary to redraw the diagram several times with use cases in different places to make the diagram easy to read. Also, for understandability purposes, there should be no more than three to nine use cases on the model so the diagram is as simple as possible. These includes those use cases that have been factored out and now are associated with another use case through the include, extend, or generalization relationships. Creating Use-Case Descriptions and Use-Case Diagrams 181 24 This process is related to role-playing, which is discussed in Chapter 6, walkthroughs discussed in Chapter 8, and testing discussed in Chapter 13. Third, the actors are placed on the diagram. The actors are taken directly from the pri- mary actor element on the detailed use-case description. Like use-case placement, to min- imize the number of lines that will cross on the diagram, the actors should be placed near the use cases with which they are associated. The fourth and last step is to draw lines connecting the actors to the use cases with which they interact. No order is implied by the diagram, and the items added along the way do not have to be placed in a particular order; therefore, it may help to rearrange the sym- bols a bit to minimize the number of lines that cross, making the diagram less confusing. REFINING PROJECT SIZE AND EFFORT ESTIMATION USING USE-CASE POINTS25 In Chapter 3, we used function points and the COCOMO method to estimate the size and effort of a systems development project, respectively. However, neither of these approaches were developed or validated with object-oriented systems in mind. As such, even though they are very popular approaches to estimation, their application to object-oriented systems is questionable. Because we now know about use cases, we introduce a size and effort estimation technique that was developed around their use. This technique, known as use-case points, was originally developed by Gustav Karner of Objectory AB.26 Use-case points are based on the same ideas from which function points were developed. However, they have been refined to take into consideration the unique features of use cases and object orientation. To estimate size and effort using use-case points, at least the set of essential use cases and the use-case diagram must have been created. Otherwise, the information required will not be available. Once the use cases and use case diagram have been created, the actors and use cases must be classified as simple, average, or complex. Simple actors are separate systems with which the current system must communicate through a well-defined application program interface (API). Average actors are separate systems that interact with the current system using standard communication protocols, such as TCP/IP, FTP, or HTTP, or an external database that can be accessed using stan- dard SQL. Complex actors are typically end users communicating with the system using some type of GUI. Once all the actors have been classified, the appropriate numbers should be entered into the unadjusted actor weighting table contained in the use-case point–estimation worksheet (See Figure 5-12). For example, reviewing the Make Appointment use case (see Figure 5-5) and the use-case diagram for the Appointment 182 Chapter 5 Functional Modeling Look at the use-case diagram in Figure 5-10. Consider if a use case were added to maintain patient insurance infor- mation. Make assumptions about the details of this use case and add it to the existing use-case diagram in Figure 5-10. 5-3 Use–Case DiagramYOUR TURN 25 The material in this section is based on descriptions of use-case points contained in Raul R. Reed, Jr., Develop- ing Applications with Java and UML (Reading, MA: Addison-Wesley, 2002); Geri Schneider and Jason P. Winters, Applying Use Cases: A Practical Guide (Reading, MA: Addison-Wesley, 1998); and Kirsten Ribu, “Estimating Object-Oriented Software Projects with Use Cases” (master’s thesis, University of Oslo, 2001). 26 Objectory AB was acquired by Rational in 1995. Rational has now been acquired by IBM. Refining Project Size and Effort Estimation Using Use-Case Points 183 Unadjusted Actor Weighting Table: Actor Type Description Weighting Factor Number Result Simple External System with well-defined API 1 Average External System using a protocol-based 2 interface, e.g., HTTP, TCT/IP, or a database Complex Human 3 Unadjusted Actor Weight Total (UAW) Unadjusted Use Case Weighting Table: Use-Case Type Description Weighting Factor Number Result Simple 1–3 transactions 5 Average 4–7 transactions 10 Complex >7 transactions 15 Unadjusted Use-Case Weight Total (UUCW) Unadjusted Use Case Points (UUCP) ϭ UAW ϩ UUCW Technical Complexity Factors: Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes T1 Distributed system 2.0 T2 Response time or throughput 1.0 performance objectives T3 End-user online efficiency 1.0 T4 Complex internal processing 1.0 T5 Reusability of code 1.0 T6 Easy to install 0.5 T7 Ease of use 0.5 T8 Portability 2.0 T9 Ease of change 1.0 T10 Concurrency 1.0 T11 Special security objectives included 1.0 T12 Direct access for third parties 1.0 T13 Special user training required 1.0 Technical Factor Value (TFactor) Technical Complexity Factor (TCF) ϭ 0.6 ϩ (0.01 * TFactor) Environmental Factors: Factor Number Description Weight Assigned Value (0 – 5) Weighted Value Notes E1 Familiarity with system 1.5 development process being used E2 Application experience 0.5 E3 Object-oriented experience 1.0 E4 Lead analyst capability 0.5 E5 Motivation 1.0 E6 Requirements stability 2.0 E7 Part time staff –1.0 E8 Difficulty of programming language –1.0 Environmental Factor Value (EFactor) Environmental Factor (EF) ϭ 1.4 ϩ (Ϫ0.03 * EFactor) Adjusted Use Case Points (UCP) ϭ UUCP * TCF * ECF Effort in Person Hours ϭ UCP * PHM FIGURE 5-12 Use-Case Point–Estimation Worksheet TEMPLATE can be found at www.wiley.com /college/dennis system (see Figure 5-10) we see that we have four human actors interacting with the sys- tem, giving an unadjusted actor weight total (UAW) of 12. This is computed by summing the individual results that were computed by multiplying the weighting fact by the num- ber of actors of each type. In this case there were zero simple actors, zero average actors, and four complex actors. Depending on the number of unique transactions that the use case must address, a use case is classified as a simple use case (1–3), an average use case (4–7), or a complex use case (>7). In the original formulation of use-case point estimation, Karner suggested that included and extended use cases should be ignored. However, today the recommendation is to use all use cases, regardless of their type in the estimation calculation. For example, the Make Appointment use case described in Figure 5-5 must deal with activities including making a new appointment, canceling an existing appointment, changing an existing appointment, creating a new patient, and making payment arrangements. In this case, because the Make Appointment use case has to deal with five separate transactions, it is classified as an average use case (see the unadjusted use-case weighting table in Figure 5-12). Based on the Appointment System use-case diagram (see Figure 5-10), we have three sim- ple use cases (Produce Schedule, Make Old Patient Appointment, and Record Availability), four average use cases (Make Appointment, Make New Patient Appointment, Manage Schedule, and Make Payment Arrangements), and one complex use case (Update Patient Information). By multiplying by the appropriate weights and summing the results, we get an unadjusted use-case weight total (UUCW) value of 70. The value of the unadjusted use-case points (UUCP) is simply the sum of the unad- justed actor weight total (12) and the unadjusted use-case weight total (70). As such, UUCP is equal to 82. In the spirit of function point analysis, use-case point–based estimation also has a set of factors that are used to adjust the use-case point value. In this case, there are two sets of factors: technical complexity factors (TCF) and environmental factors (EF). There are thirteen separate technical factors and eight separate environmental factors. The pur- pose of these factors is to allow the project as a whole to be evaluated for complexity and experience levels of the staff, respectively. Obviously, these types of factors can impact the effort required by a team to develop a system. Each of these factors is assigned a value between 0 and 5, 0 representing that the factor is irrelevant to the system under consid- eration and 5 representing that the factor is essential for the system to be successful. The assigned values are then multiplied by their respective weights. These weighted values are then summed up to create a technical factor value (TFactor) and an environmental factor value (EFactor). The technical factors include the following: ■ Whether the system is going to be a distributed system ■ The importance of response time ■ The efficiency level of the end user using the system ■ The complexity of the internal processing of the system ■ The importance of code reuse ■ How easy the installation process has to be ■ The importance of the ease of using the system ■ How important it is for the system to be able to be ported to another platform ■ Whether system maintenance is important ■ Whether the system is going to have to handle parallel and concurrent processing ■ The level of special security required 184 Chapter 5 Functional Modeling ■ The level of system access by third parties ■ Whether special end user training is to be required (see Figure 5-12) The environmental factors include the following: ■ The level of experience the development staff has with the development process being used ■ The application being developed ■ The level of object-oriented experience ■ The level of capability of the lead analyst ■ The level of motivation of the development team to deliver the system ■ The stability of the requirements ■ Whether part-time staff have to be included as part of the development team ■ The difficulty of the programming language being used to implement the system (see Figure 5-12) Continuing the appointment example, the values for the technical factors were T1 (0), T2 (5), T3 (3), T4 (1), T5 (1), T6 (2), T7 (4), T8 (0), T9 (2), T10 (0), T11 (0), T12 (0), and T13 (0). Summing the weighted values in Figure 5-12 gives a TFactor value of 15. Plugging this value into the technical complexity factor (TCF) equation of the use-case point work- sheet gives a value of .75 for the TCF of the appointment system. The values for the environmental factors were E1 (4), E2 (4), E3 (4), E4 (5), E5 (5), E6 (5), E7 (0), and E8 (4), giving an EFactor of 25.5. Like the TFactor, Efactor is simply the sum of the weighted values. Using the environmental factor (EF) equation of the use- case point worksheet produces a value of .635 for the EF of the appointment system. Plugging the TCF and EF values, along with the UUCP value computed earlier, into the adjusted use-case points equation of the worksheet yields a value of 33.3375 adjusted use- case points (UCP). Now that we know the estimated size of the system by means of the value of the adjusted use-case points, we are ready to estimate the effort required to build the system. In Karner’s original work, he suggested simply multiplying the number of use-case points by 20 to estimate the number of person-hours required to build the system. However, based on additional experiences using use-case points, a decision rule to determine the value of the person-hours multiplier (PHM) has been created that suggests using either 20 or 28, based on the values assigned to the individual environmental factors. The decision rule is: If the sum of (number of Efactors E1 through E6 assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) р 2 PHM ϭ 20 Else If the sum of (number of Efactors E1 through E6 assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) ϭ 3 or 4 PHM ϭ 28 Else Rethink project; it has too high of a risk for failure Based on these rules, because none of Efactors E1 through E6 have a value less than 3 and only Efactors E8 has a value greater than 3, the sum of the number EFactors is 1. Thus, the appointment system should use a PHM of 20. This gives an estimated number of per- son-hours of 666.75 hours (20 * 33.3375). The filled-out worksheet is given in Figure 5-13. Refining Project Size and Effort Estimation Using Use-Case Points 185 FIGURE 5-13 Use-Case Point Estimation for the Appointment System 33.3375 * 20 ؍ UCP * PHM 666.75 ؍ Effort in person-hours 0.635 * 0.75 * 70 ؍ UUCP * TCF * ECF 33.3375 ؍ (Adjusted use case points (UCP ؉ (؊0.03 * 25.5) 1.4 ؍ ؉ (؊0.03 * EFactor) 0.635 1.4 ؍ (Environmental factor (EF Environmental Factor Value (EFactor) 25.5 E8 Difficulty of programming language –1 4 –4.0 E7 Part-time staff –1 0 0 E6 Requirements stability 2 5 10 E5 Motivation 1 5 5 E4 Lead analyst capability 0.5 5 2.5 E3 Object-oriented experience 1 4 4 E2 Application experience 0.5 4 2 development process being used E1 Familiarity with system 1.5 4 6 Factor Number Description Weight Assigned Value (0 – 5) Weighted Value Notes Environmental Factors: Technical complexity factor (TCF) ϭ 0.6 ϩ (0.01 * TFactor) 0.75 ϭ 0.6 ؉ (0.01 * 15) Technical Factor Value (TFactor) 15 T13 Special user training required 1 0 0 T12 Direct access for third parties 1 0 0 T11 Special security objectives included 1 0 0 T10 Concurrency 1 0 0 T9 Ease of change 1 2 2 T8 Portability 2 0 0 T7 Ease of use 0.5 4 2 T6 Easy to install 0.5 2 1 T5 Reusability of code 1 1 1 T4 Complex internal processing 1 1 1 T3 End-user online efficiency 1 3 3 performance objectives T2 Response time or throughput 1 5 5 T1 Distributed system 2 0 0 Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes Technical Complexity Factors: ؉ 70 12 ؍ UAW ؉ UUCW 82 ؍ (Unadjusted use-case points (UUCP Unadjusted Use Case Weight Total (UUCW) 70 Complex >7 transactions 15 1 15 Average 4–7 transactions 10 4 40 Simple 1–3 transactions 5 3 15 Use Case Type Description Weighting Factor Number Result Unadjusted Use-Case Weighting Table: Unadjusted Actor Weight Total (UAW) 12 Complex Human 3 4 12 interface, e.g., HTTP, TCT/IP, or a database Average External system using a protocol-based 2 0 0 Simple External system with well-defined API 1 0 0 Actor Type Description Weighting Factor Number Result Unadjusted Actor Weighting Table: Chapter 5 Functional Modeling 186 The primary advantages of using use-case points over traditional estimation tech- niques are that they are based in object-oriented systems development and use cases rather than traditional approaches to systems development. However, the risk of using use-case points is that their use does not have as much history in comparison to the traditional approaches described in Chapter 3. As such, the suggested classifications used for simple, average, and complex actors and use cases, the weighting factors for simple, average, and complex actors and use cases, and the weightings associated with the computation of the technical complexity and environmental factors may need to be modified in the future. However, at this point the suggested values seem to be the best available. Refining Project Size and Effort Estimation Using Use-Case Points 187 Consider the use case you created in Your Turn 5-2. Using the worksheet in Figure 5-12, estimate the project size and effort for your use case. 5-4 Estimating Using Use-Case PointsYOUR TURN Create a set of use cases for the following high-level processes in a housing system run by the campus hous- ing service. The campus housing service helps students find apartments. Apartment owners fill in information forms about the rental units they have available (e.g., location, number of bedrooms, monthly rent), which are then entered into a database. Students can search through this database via the Web to find apartments that meet their needs (e.g., a two-bedroom apartment for $400 or less per month within a half mile of campus). They then contact the apartment owners directly to see the apart- ment and possibly rent it. Apartment owners call the ser- vice to delete their listing when they have rented their apartment(s). 5-5 Campus HousingYOUR TURN In Your Turn 5-5, you identified use cases for a campus housing service that helps students find apartments. Based on those use cases, create a use-case diagram. 5-6 Drawing a Use-Case DiagramYOUR TURN Consider the use cases you created in Your Turn 5-5. Using the worksheet in Figure 5-12, estimate the project size and effort for your use cases. 5-7 Estimating Using Use-Case PointsYOUR TURN APPLYING THE CONCEPTS AT CD SELECTIONS The basic functional and nonfunctional requirements for the CD Selections Internet Sales System were developed previously. Carefully review these requirements (see Figures 2-13, 2-14, 2-15, 3-22, and 4-15). Business Process Modeling with Activity Diagrams Based on the functional requirements identified for the Internet Sales System, Alec and his team decided that there were at least four high-level activities that needed to be addressed: Place CD Orders, Maintain CD Information, Maintain CD Marketing Infor- mation, and Fill Mail Orders. As a first step toward developing a functional model of the functional requirements, Alec decided to model the overall flow of execution of the busi- ness processes as an activity diagram. Upon close review of the Place CD Orders require- ments, the team identified a decision and two additional activities: Place InStore Hold and Place Special Order. These activities were based on the requirements laid out in point 3.5 of Figure 4-15. Furthermore, the team noticed that there seemed to be three separate concurrent paths of execution implied in the requirements. The first path dealt with orders, the second addressed the maintenance of marketing information, and the third focused on maintaining the information about the CDs. Based on these new insights, Alec and his team drew the activity diagram for the Internet Sales system shown in Figure 5-14. 188 Chapter 5 Functional Modeling [Mail Order][In-Store Hold] [Special Order] Maintain CD Marketing InformationPlace Order Place Special Order Maintain CD Information Place In-Store Hold Fill Mail Order FIGURE 5-14 Activity Diagram for the CD Selections To-Be Internet Sales System Identify the Major Use Cases The first four steps in writing use cases deal with reviewing the activity diagram, finding the subject boundaries, listing the primary actors and their goals, and identifying and writ- ing overviews of the major use cases based on these results. These use cases will form the basis of the use cases that are contained on the use-case diagram. Take a minute and go back and review the requirements identified in Figure 4-15 and the activity diagram we just completed (see Figure 5-14) to identify the three to nine major use cases before you con- tinue reading. To begin with, it seems that the subject boundary should be drawn in such a manner that anything that is not part of CD Selections’ Internet Sales System, such as the vendors and customers, should be identified as primary actors. Therefore, these are considered out- side of the scope of the system. The other potential actors identified could be the distribu- tion system, electronic marketing (EM) manager, and the current CD Selections stores. Upon closer review of Figure 4-15, it seems that the distribution system and the cur- rent CD Selections stores should be outside the scope of the Internet Sales System. As such, they also should be identified as primary actors. It also seems that the EM manager should be considered as part of the Internet Sales System and, therefore, should not be identified as a primary actor. Remember, primary actors are only those that can be viewed as being outside of the scope of the system. The decision on whether the EM manager, the current CD Selections stores, or the distribution system is inside or outside of the system is some- what arbitrary. From a customer’s perspective, the distribution system, and the current CD Selections stores could be seen as being inside of the overall system, and it could be argued that the EM manager is a primary user of the Internet Sales System. At this point in the process, it is important to make a decision and to move on. Dur- ing the process of writing use cases, there are ample opportunities to revisit this decision to determine whether the set of use cases identified are necessary and sufficient to describe the requirements of the Internet Sales System for CD Selections. As you can see, based on the preceding, finding the systems boundaries and listing the primary actors are heavily intertwined. Based on the functional requirements and the activity diagram, Alec and his team identified four overview major use cases: Maintain CD Information, Maintain CD Mar- keting Information, Place Order, and Fill Order. You might have considered adding new CDs to the database, deleting old ones, and changing information about CDs as three sep- arate use cases—which, in fact, they are. In addition to these three, we also need to have use cases for finding CD information and printing reports about CDs. However, our goal at this point is to develop a small set of essential use cases for the Internet Sales System. The same pattern should be evident for the marketing materials. We have the same processes for recording new marketing material for a CD, creating it, reading it, updating it, deleting it, and printing it. These activities are usually required any time that you have information to be stored in a database. The project team at CD Selections identified these same four major use cases. At this point in the process, the project team began writing the overview use cases for these four. Remember that an overview use case only has five pieces of information: use case name, ID number, primary actor, type, and a brief description. At this point in time, we have already identified the primary actors and have associated them with the four use cases. Further- more, because we are just beginning the development process, all four use cases will be overview and essential types. Because the ID numbers are simply used for identification purposes (i.e., they act as a key in a database), their values can be assigned in a sequential manner. This leaves us with only two pieces of information for each use case to write. The use-case name should be an action verb–noun phrase combination (e.g., Make Appointment). Applying the Concepts at CD Selections 189 In the CD Selections Internet Sales situation, Maintain CD Information, Maintain CD Marketing Information, Place Order, and Fill Order seem to capture the essence of each of the use cases. Finally, a brief description is written to describe the purpose of the use case or the goal of the primary actor using the use case. This description can range from a sen- tence to a short essay. The idea is to capture the primary issues in the use case and make them explicit. (See Figure 5-15). 190 Chapter 5 Functional Modeling Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of events: Subflows: Alternate/exceptional flows: Maintain CD information 1 Distribution system Use Case Type: Overview, essential This adds, deletes, and modifies the basic information about the CDs we have available for sale (e.g., album name, artist(s), price, quantity on hand, etc.). Relationships: Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of events: Subflows: Alternate/exceptional flows: Use Case Type: Relationships: Use Case Name: Primary Actor: Stakeholders and interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of events: Subflows: Alternate/exceptional flows: Use Case Type: Relationships: Maintain marketing information 2 Vendor Overview, essential Overview, essential This adds, delete, and modifies the additional marketing material available for some CDs (e.g., reviews). This use case describes how customers can search the Web site and place orders. Place order 3 Customer Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of Events: Use Case Type: Relationships: Association: Include: Extend: Generalization: Fill order 4 Distribution system Type: Overview, essential This describes how orders move from the Internet Sales System into the distribution system and how status information will be updated from the distribution system. Subflows: FIGURE 5-15 Overview of Major Use Cases for CD Selections The fifth step is to carefully review the current set of use cases. Take a moment to review the use cases and make sure you understand them. Based on the descriptions of all four use cases, there seems to be an obvious missing use case: Maintain Order. Because the project team did not include language in the brief description of the Place Order use case, it seems that the project team believes that maintaining an order is sufficiently different from plac- ing an order that it should have its own use case to describe it. Furthermore, it does not seem reasonable that a customer would see placing an order and maintaining an order as the same use case. This type of interactive and incremental process goes on until the project team feels that they have identified the major use cases for the Internet Sales System. Expanding the Major Use Cases The sixth step is to choose one of the major use cases to expand. To help the project team to make this choice, they identified the trigger and the stakeholders and their interests for each of the major use cases. The first use case, Maintain CD Information, was triggered by the Distribution System distributing new information for use in the CD database. Besides the Distribution System, another stakeholder was identified: EM Manager. The second use case, Maintain CD Market- ing Information, has a similar structure. The receipt of marketing materials from vendors trig- gers it. Again, it seemed to the project team that the EM Manager was an interested stakeholder. The third use case, Place Order, is more interesting. The trigger is the action of a Customer. Again, the EM Manager is an interested stakeholder. This use case has many more inputs. The fourth use case, Fill Order, is based on the decision logic identified in the activity diagram. However, upon further reflection, the team decided to replace this use case with three separate use cases, one for each approach to filling an order: Place Special Order, Place In-Store Hold, and Fill Mail Order. The first two are controlled by actions of the Customer. However, the Fill Mail Order use case has a temporal trigger: every hour the Internet Sales System downloads orders into the Distribution System. The final use case, Maintain Order, is triggered by the action of a Customer. However, on close review, it seems that it also has much in common with the other maintenance-related use cases: Maintain CD Information and Maintain CD Mar- keting Information. And like all of the other use cases, the EM Manager has an interest. Based on their review of the major use cases, the project team decided that the Place Order use case was the most interesting. The next step, step 7, is to start filling in the details of the chosen use case. At this point in time, the project team had the information to fill in the stakeholders and interests, the trigger, and the association relationship. (Note: Remem- ber that the association relationship is simply the communication link between the primary actor and the use case.) In this use case, the association relationship is with the Customer. The project team then needed to gather and organize the information needed to define the Place Order use case in more detail. Specifically, they needed to begin writing the nor- mal flow of events; that is, they should perform the eighth step for writing effective use cases (see Figure 5-11). This was done based on the results of the earlier analyses described in Chapter 4 as well as through a series of JAD meetings with the project sponsor and the key marketing department managers and staff who would ultimately operate the system. The goal at this point is to describe how the chosen use-case operates: Place Order. Alec and the team decided to visualize placing a CD order over the Web and to think about how other electronic commerce Web sites work—that is, to role-play. As they role-played the Place Order use case, they realized that after the customer connected to the Web site, he or she probably began searching—perhaps for a specific CD, perhaps for a category of music—but in any event, they entered some information for their search. The Web site then should present a list of CDs matching their request along with some basic information about the CDs (e.g., artist, title, and price). If one of the CDs is of interest to them, they Applying the Concepts at CD Selections 191 might seek more information about it, such as the list of songs, liner notes, reviews, etc. Once they found a CD they liked, they would add it to their order and perhaps continue looking for more CDs. Once they were done—perhaps immediately—they would check out by presenting their order with information on the CDs they want and giving additional information such as mailing address, credit card, etc. When the team wrote the use case’s normal flow of events, they paid close attention to the seven guidelines described earlier. Alec realized that the first step was to present the customer with the home page or a form to fill in to search for an album. Even though this was technically correct, this type of step was very small compared to the other steps that followed.27 It was analogous to making the first step, hand the user a piece of paper. At this point, the team was looking only for the three to seven major steps. Based on the role-playing and the application of the earlier principles (see Figure 5-6), the team suc- cessfully identified a set of steps (see Figure 5-16). 192 Chapter 5 Functional Modeling Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: importance level: Trigger: Type: Normal Flow of Events: Subflows: Alternate/exceptional Flows: Place Order 3 High Customer External Customer Maintain order Use case type: Detail, Essential This use case describes how customers can search the Web site and place orders. Customer visits Web site and places order Customer - wants to search Web site to purchase CD EM manager - wants to maximize customer satisfaction Relationships: Association: Include: Extend: Generalization: 1. The Customer submits a search request to the system. 2. The System provides the Customer a list of recommended CDs. 3. The Customer chooses one of the CDs to find out additional information. 4. The System provides the Customer with basic information and reviews on the CD. 5. The Customer adds the CD to his or her shopping cart. 6. The Customer decides how to “fill” the order. 7. The Customer iterates over 3 through 5 until done shopping. 8. The Customer executes the Maintain Order use case. 9. The Customer logs in to check out. 10. The System validates the Customer’s credit card information. 11. The System sends an order confirmation to the Customer. 12. The Customer leaves the Web site. FIGURE 5-16 Places Order Use Case after Step 8 27 Because it is so small, it violates the fourth principle (see Figure 5-6). The first major step performed by the system is to respond to the customer’s search inquiry, which might include a search for a specific album name or albums by a specific artist. Or, it might be the customer wanting to see all the classical or alternative CDs in stock. Or, it might be a request to see the list of special deals or CDs on sale. In any event, the system finds all the CDs matching the request and shows a list of CDs in response. The user will view this response and perhaps will decide to seek more information about one or more CDs. He or she will click on it, and the system will provide additional informa- tion. Perhaps the user will also want to see any extra marketing material that is available as well. The user will then select one or more CDs for purchase, decide how to take deliv- ery of each CD, and perhaps continue with a new search. These steps correspond to events 1–7 in Figure 5-16. The user may later make changes to the CDs selected, either by dropping some or chang- ing the number ordered. This seems to be similar to an already identified separate use case: Maintain Order. As such, we can simply reuse that use case to handle those types of details. At some point the user checks out by verifying the CDs he or she has selected for purchase and providing information about himself or herself (e.g., name, mailing address, credit card). The system calculates the total payment and verifies the credit-card information with the credit-card clearance center. At this point in the transaction, the system sends an order con- firmation to the customer, and the customer typically leaves the Web site. Figure 5-16 shows the use case at this point. Note that the normal flow of events has been added to the form, but nothing else has changed. The ninth step for writing uses cases (see Figure 5-11) is to try and simplify the cur- rent normal flow of events. Currently, the team has twelve events, which is a little high. Therefore, the team decided to see if there were any steps that they could merge, delete, rearrange, and or leave out. Based on this review, they decided to create a separate use case that could handle the checkout process (events 9, 10, and 11): Checkout. They also realized that events 5 and 6 could be viewed as a part of the Maintain Order use case previously identified. As such they deleted events 5 and 6 and moved event 8 into their place. At this point in time, the Place Order use case had eight events. Given the purpose of this use case, it seemed to be a reasonable number of events. The next two steps in writing a use case deals with alternate or exceptional flows. (Note: Remember the normal flow of events captures only the typical set of events that end in a successful transaction.) With the Place Order use case, the development team defined success as a new order being placed. However, the team identified two sets of events that were exceptions to the normal flow. First, event 3 assumed that the list of recommended CDs was acceptable to the customer. However, as one of the team members pointed out, that is an unrealistic assumption. As such, two exceptional flows have been identified and written (3a-1 and 3a-2 in Figure 5-17) to handle this specific situation. Second, a customer may want to abort the entire order instead of going through the checkout process. In this case, exceptional flow 7a was created for this case.28 Confirming the Major Use Cases Once all the use cases had been defined, the final step in the JAD session was to confirm that they were accurate. The project team had the users role-play the use cases again. A few minor problems were discovered and were easily fixed. However, one major problem was Applying the Concepts at CD Selections 193 28 Another approach would be to force the customer through the Maintain Order or Checkout use cases. How- ever, the marketing representatives on the project team were concerned with customer frustration. As such, the project team included it in the Place Order use case. discovered: how is a new customer created? This was easily fixed by creating a new use case: Create New Customer. The new use case was added as an extension to the Checkout use case. Figure 5-18 shows the revised use cases. At this point in time, the use-case devel- opment process can actually start all over again, or we can move on to drawing the use- case diagram. 194 Chapter 5 Functional Modeling Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Normal Flow of Events: Subflows: Alternate/exceptional Flows: Place Order 3 High Customer Customer Checkout, Maintain Order Use Case Type: Detail, Essential This use case describes how customers can search the Web site and place orders. Customer visits Web site and places order Customer–wants to search Web site to purchase CD. EM manager–wants to maximize customer satisfaction. Relationships: Association: Include: Extend: Generalization: 1. Customer submits a search request to the system. 2. The System provides the Customer a list of recommended CDs. 3. The Customer chooses one of the CDs to find out additional information. 4. The System provides the Customer with basic information and reviews on the CD. 5. The Customer calls the Maintain Order use case. 6. The Customer iterates over 3 through 5 until done shopping. 7. The Customer executes the Checkout use case. 8. The Customer leaves the Web site. 3a-1. The Customer submits a new search request to the system. 3a-2. The Customer iterates over steps 2 through 3 until satisfied with search results or gives up. 7a. The Customer aborts the order. Type: External FIGURE 5-17 Places Order Use Case after Step 11 Complete the detailed use-case descriptions for the remaining overview use cases in Figure 5-18. Remember that it is possible to uncover additional functionality when you iterate through the use cases. As such, be sure to review all of them once you have finished. Further- more, you may also need to modify the activity diagram contained in Figure 5-14 once you have completed the detailed use case descriptions. 5-8 CD Selections Internet Sales SystemYOUR TURN Applying the Concepts at CD Selections 195 Association: Include: Materials arrive from vendors, distributors, wholesalers, record companies, and articles from trade magazines Relationships: Association: Include: Extend: Generalization : Vendor Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Type: External Use Case Type: Relationships: Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Maintain Marketing Information 2 Vendor Use Case Type: Detail, Essential This adds, deletes, and modifies the marketing material available for some CDs (e.g., reviews). Vendor–wants to ensure marketing information is as current as possible. EM Manager–wants marketing information to be correct to maximize sales. High Maintain CD Information 1 Distribution System Distribution System Downloads from the Distribution System Detail, Essential This adds, deletes, and modifies the basic information about the CDs we have available for sale (e.g., album name, artist(s), price, quantity on hand, etc.). Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Use Case Type: Relationships: Association: Include: Extend: Generalization : This use case describes how customers can search the Web site and place orders. Place Order 3 High Customer Customer Checkout, Maintain Order Detail, Essential Customer visits Web site and places order. Customer–wants to search Web site to purchase CD. EM Manager–wants to maximize Customer satisfaction. Type: External Type: External FIGURE 5-18 Revised Major Use Cases for CD Selections 196 Chapter 5 Functional Modeling Association: Include: Extend: Generalization : Customer signals the system they want to finalize their order. Relationships: Association: Include: Extend: Generalization : Credit Card Center Maintain Order Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Type: External Type: External Use Case Type: Relationships: Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Checkout 6 Customer Use Case Type: Detail, Essential This use case describes how the customer completes an order including credit card authorization. Customer–wants to finalize the order. Credit Card Center–wants to provide effective and efficient service to CD Selections. EM Manager–wants to maximize order closings. High Maintain Order 5 High Customer Customer visits Web site and requests to modify a current order. Detail, Essential This use case describes how a Customer can cancel or modify an open or existing order. Customer–wants to modify order. EM Manager–wants to ensure high customer satisfaction. Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Use Case Type: Relationships: Association: Include: Extend: Generalization : This use case describes how a customer is added to the Customer database. Create New Customer 7 High Customer Customer Detail, Essential An unknown Customer attempts to checkout. Customer–wants to be able to purchase CDs from CD Selections. EM Manager–wants to increase CD Selections Customer base. Type: External FIGURE 5-18 Revised Major Use Cases for CD Selections (Continued) Applying the Concepts at CD Selections 197 Association: Include: Extend: Generalization : Customer selects CD on order for an in store hold to be picked up at bricks and mortar store. Relationships: Association: Include: Extend: Generalization : Bricks and mortar store Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Type: External Bricks and mortar store Type: External Use Case Type: Relationships: Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Place InStore Hold 9 Customer Use Case Type: Detail, Essential This use case describes how a Customer places an in store hold using the Internet Sales system. Customer–wants to be able to place an in store hold a CD for In Store pick up. EM manager–wants to increase sales associated with the Internet Sales system. Bricks and Mortar Store Manager–wants to increase sales associated with the store. High Place Special Order 8 High Customer Customer selects CD on order for a special order at bricks and mortar store. Detail, Essential This use case describes how a Customer places a special order using the Internet Sales system. Customer–wants to be able to place a special order of CDs for in store pick up. EM manager–wants to increase sales associated with the Internet Sales system. Bricks and Mortar Store Manager–wants to increase sales associated with the store. Use Case Name: Primary Actor: Stakeholders and Interests: Brief Description: ID: Importance Level: Trigger: Use Case Type: Relationships: Association: Include: Extend: Generalization : This describes how mail orders move from the Internet Sales system into the distribution system and how status information will be updated from the distribution system. Fill Mail Order 10 High Customer Distribution System Maintain Order Detail, Essential Every hour the Distribution System will initiate a trading of information with the Internet Sales system. Mail Order Distribution System–wants to complete order processing in a timely manner. Customer–wants to receive order in a timely manner. EM Manager–wants to maximize order throughput. Type: Temporal FIGURE 5-18 Revised Major Use Cases for CD Selections (Continued) 198 Chapter 5 Functional Modeling Creating the Use-Case Diagram Because use-case diagrams provide only a pictorial overview of the detailed use cases, the team found that creating the use-case diagram from the detailed use-case descriptions was very easy. (Note: Remember that a use-case diagram shows only the subject boundary, the use cases themselves, the actors, and the various associations between these components.) The team fol- lowed the four major steps for drawing a use-case diagram given in Figure 5-11. First, they placed a box on the use-case diagram to represent the Internet Sales System and placed the system’s name at the top of the box. Second, they added the use cases to the diagram. Third, they placed the actors near the use cases with which they were associated. Fourth, they drew in the association connecting the actors with their respective use cases. Figure 5-19 portrays the use case diagram that the team created. Refining Project Size and Effort Estimation using Use-Case Points Now that the functional modeling aspect of the system development effort has been com- pleted, Alec and his team decided that they needed to refine the estimation of the size and effort to build the system. Based on the completed use cases (see Figure 5-18) and the use- case diagram (see Figure 5-19) and using the use-case point template (see Figure 5-13), Alec could now use the use cases as the basis for the estimation instead of using the func- tion point estimate that he had done earlier (see Figure 3-21). First, Alec had to classify each actor and use case as being simple, average, or complex. In the case of the actors, Bricks and Mortar store and Distribution System had a well- defined API. As such they were classified as simple actors. The Credit-Card center was con- sidered to be average, whereas the vendor and customer actors were classified as being complex. This gave an unadjusted actor weight total value of 10. (See Figure 5-20.) Second, Alec classified each use case based on the number of unique transactions that each had to handle. In this case, there were three simple use cases (Place InStore Hold, Place Special Order, and Fill Mail Order), one average use case (Create New Customer), and five complex use cases (Place Order, Checkout, Maintain Order, Maintain CD Infor- mation, and Maintain CD Marketing Information). Based on these, the unadjusted use- case weight total was computed to be 100 (see Figure 5-20). Third, Alec computed a value of 110 for the unadjusted use-case points. Fourth, he rated each of the technical complexity factors, rated each of the environmental factors, and com- puted the values for TCF and EF (see Figure 5-20). Fifth, using the unadjusted use-case points and the TCF and EF values, Alec calculated a value of 134.992 for adjusted use-case points. Sixth, based on the decision rule to determine whether to use 20 or 28 as the value of the per- son-hours multiplier, Alec realized that he should use 28. Consequently, Alec estimated the remaining effort for the project to be 3,779.776 person-hours. Converting the person-hours to person-months (3,779.776/160) and using the estimated schedule equation that he had The use-case diagram for the Internet Sales Systems does not include any generalization relationships. See if you can come up with one example for a use case and another example for an actor that may be helpful for CD Selections to add to the use-case diagram shown in Figure 5-19. Describe how the development effort may benefit from including your examples. 5-9 Identifying Generalization Associations in Use Cases and Specialized ActorsYOUR TURN used in the earlier estimate, 3.0 * person-months1/3 (see Figure 3-21), Alec estimated that the schedule would still be under the 10 months (8.6 months) that he had originally estimated. However, if he had not padded the estimate, he realized that he would have had to make sig- nificant changes to the current schedule. This could potentially have put the project into jeop- ardy of not being completed on time. Even though he currently considers himself fairly smart for padding the estimate, he realizes that his pad of 2.5 months has now been reduced to 1.4 months and he has not even delivered the analysis models yet. As such, Alec realizes that to pre- vent any schedule slippage, he must carefully manage the team. Applying the Concepts at CD Selections 199 Internet Sales System Vendor Customer Maintain CD Marketing Information <> Bricks and Mortar Store <> Credit-Card Center <> Distribution System PlaceOrder Checkout Maintain Order Fill Mail Order Create New Customer Place InStore Hold Place Special Order Maintain CD Information <> <> <> <> <> <> <> * * * * * * * ** ** * * * * FIGURE 5-19 Use-Case Diagram for the CD Selections To-Be Internet Sales System 200 Chapter 5 Functional Modeling Unadjusted Actor Weighting Table: Actor Type Description Weighting Factor Number Result Simple External System with well-defined API 1 2 2 Average External System using a protocol-based 2 1 2 interface, e.g., HTTP, TCT/IP, or a database Complex Human 3 2 6 Unadjusted Actor Weight Total (UAW) 10 Unadjusted Use Case Weighting Table: Use Case Type Description Weighting Factor Number Result Simple 1–3 transactions 5 3 15 Average 4–7 transactions 10 1 10 Complex >7 transactions 15 5 75 Unadjusted Use Case Weight Total (UUCW) 100 Unadjusted use case points (UUCP) ϭ UAW ϩ UUCW 110 ϭ 10 ϩ 100 Technical Complexity Factors: Factor Number Description Weight Assigned Value (0–5) Weighted Value Notes T1 Distributed system 2.0 5 10.0 T2 Response time or throughput 1.0 5 5.0 performance objectives T3 End-user online efficiency 1.0 5 5.0 T4 Complex internal processing 1.0 4 4.0 T5 Reusability of code 1.0 3 3.0 T6 Easy to install 0.5 3 1.5 T7 Ease of use 0.5 5 2.5 T8 Portability 2.0 4 8.0 T9 Ease of change 1.0 3 3.0 T10 Concurrency 1.0 3 3.0 T11 Special security objectives included 1.0 5 5.0 T12 Direct access for third parties 1.0 5 5.0 T13 Special User training required 1.0 3 3.0 Technical Factor Value (TFactor) 58.0 Technical complexity factor (TCF) ϭ 0.6 ϩ (0.01 ϫ TFactor) 1.18 ϭ 0.6 ϩ (0.01 ϫ 58) Environmental Factors: Factor Number Description Weight Assigned Value (0 – 5) Weighted Value Notes E1 Familiarity with system 1.5 1 1.5 development process being used E2 Application experience 0.5 2 1.0 E3 Object-oriented experience 1.0 0 0.0 E4 Lead analyst capability 0.5 3 1.5 E5 Motivation 1.0 4 4.0 E6 Requirements stability 2.0 4 8.0 E7 Part time staff –1.0 0 0.0 E8 Difficulty of programming language –1.0 4 –4.0 Environmental Factor Value (EFactor) 12.0 Environmental factor (EF) ϭ 1.4 ϩ (–0.03 * EFactor) 1.04 ϭ 1.4 ϩ (–.03 ϫ 12) Adjusted use case points (UCP) ϭ UUCP * TCF * ECF 134.992 ϭ 110 ϫ 1.18 ϫ 1.04 Person hours multiplier (PHM) PHM ϭ 28 Person hours ϭ UPC ϫ PHM 3,779.776 ϭ 134.992 ϫ 28 FIGURE 5-20 Use-Case Points Estimation for the Internet Sales Systems SUMMARY Business Process Modeling with Activity Diagrams Even from an object-oriented systems development point of view, business process model- ing has been shown to be valuable. The one major hazard of business process modeling is that it focuses the systems development process in a functional decomposition direction. However, if used carefully, it can enhance the development of object-oriented systems. UML 2.0 supports process modeling using an activity diagram. Activity diagrams comprise activities or actions, objects, control flows, object flows, and a set of seven different control nodes (initial, final-activity, final-flow, decision, merge, fork, and join). Furthermore, swimlanes can be used to enhance the readability of the diagrams. An activity diagram is very useful for helping the analyst to identify the relevant use cases for the information sys- tem being developed. Use-Case Descriptions Use cases are the primary method of documenting requirements for object-oriented sys- tems. They represent a functional view of the system being developed. There are overview and detail use cases. Overview use cases comprise the use-case name, ID number, primary actor, type, and a brief description. Detailed use cases extend the overview use case with the identification and description of the stakeholders and their interest, the trigger and its type, the relationships in which the use case participates (association, extend, generalization, and include), the normal flow of events, the subflows, and any alternate or exception flows to the normal flow of events. There are seven guidelines (see Figure 5-6) and thirteen steps (see Figure 5-11) for writing effective use cases. The thirteen steps can be summed up into three aggregate groups of steps: identify the major use cases (steps 1–5), expand the major use cases (steps 6–11), and confirm the major use cases (steps 12–13). Use-Case Diagrams Use-case diagrams are simply a graphical overview of the set of use cases contained in the system. They illustrate the main functionality of a system and the actors that interact with the system. The diagram includes actors, which are people or things that derive value from the system, and use cases that represent the functionality of the system. The actors and use cases are separated by a system boundary and connected by lines representing associa- tions. At times, actors are specialized versions of more general actors. Similarly, use cases can extend or use other use cases. Creating use-case diagrams is a four-step process (see Figure 5-8) whereby the analyst draws the system boundary, adds the use cases to the dia- gram, identifies the actors, and finally adds appropriate associations to connect use cases and actors together. This process is simple because the written description of the use cases is created first. Refining Project Size and Effort Estimation with Use-Case Points Use-case points are a relatively new size- and effort-estimation technique that is based on ideas similar to function point analysis. Use-case points are founded on the two primary constructs associated with use-case analysis: actors and use cases. Like function points, use- case points have a set of factors used to modify their raw value: technical complexity fac- tors and environmental factors. Technical complexity factors address the complexity of the project under consideration, whereas the environmental factors deal with the level of expe- rience of the development staff. Based on the number of use-case points, the estimated effort required can be computed. Summary 201 202 Chapter 5 Functional Modeling KEY TERMS Action Activity Activity diagram Actor Adjusted use-case points (UCP) Alternate flows Application program interface (API) Association relationship Average actors Average use case Black-hole activities Brief description Complex actors Complex use case Control flow Control node Decision node Detail use case Effort Environmental factor (EF) Environmental factor value (EFactor) Essential use case Estimation Exceptional flows Extend relationship External trigger Final-activity node Final-flow node Flow of events Fork node Functional decomposition Generalization relationship Guard condition Importance level Include relationship Inheritance Initial node Iterate Join node Logical model Merge node Miracle activity Normal flow of events Object flow Object node Overview use cases Packages Person-hours multiplier (PHM) Physical model Primary actor Process models Real use case Relationships Role Scenario Simple actors Simple use case Specialized actor Stakeholders Subflows Subject boundary SVDPI Swim lanes Technical complexity factor (TCF) Technical factor value (TFactor) Temporal trigger Trigger Unadjusted actor weight total (UAW) Unadjusted use-case points (UUCP) Unadjusted use-case weight total (UUCW) Use case Use-case description Use-case diagram Use-case ID number Use-case name Use-case points Use-case type QUESTIONS 1. Why is business process modeling important? 2. What is the purpose of an activity diagram? 3. What is the difference between an activity and an action? 4. What is the purpose of a fork node? 5. What are the different types of control nodes? 6. What is the difference between a control flow and an object flow? 7. What is an object node? 8. How is use case diagramming related to functional modeling? 9. Explain the following terms. Use layperson’s language, as though you were describing them to a user: (a) actor; (b) use case; (c) system boundary; (d) relationship. 10. Every association must be connected to at least one _______ and one _________. Why? 11. What is CRUD? Why is this useful? 12. How does a detail use case differ from an overview use case? 13. How does an essential use case differ from a real use case? 14. What are the major elements of an overview use case? 15. What are the major elements of a detail use case? 16. How do you create use cases? 17. Why do we strive to have about three to nine major use cases in a business process? 18. How do you create use-case diagrams? 19. What are some heuristics for creating a use case diagram? 20. Why is iteration important in creating use cases? 21. What is the viewpoint of a use case, and why is it important? Exercises 203 22. What are some guidelines for designing a set of use cases? Give two examples of the extend associations on a use-case diagram. Give two examples for the include associations. 23. Which of the following could be an actor found on a use-case diagram? Why? Ms. Mary Smith Supplier Customer Internet customer Mr. John Seals Data entry clerk Database administrator 24. What is a use-case point? For what is it used? 25. What process do we use to estimate systems develop- ment based on use cases? EXERCISES A. Investigate the Web site for Rational Software (www.306 .ibm.com/software/rational/) and its repository of information about UML. Write a paragraph news brief on the current state of UML (e.g., the current version and when it will be released; future improvements; etc.). B. Investigate the Object Management Group. Write a brief memo describing what it is, its purpose, and its influence on UML and the object approach to systems development. (Hint: A good resource is www.omg.org.) C. Create an activity diagram and a set of detail use-case descriptions for the process of buying glasses from the viewpoint of the patient, but do not bother to identify the flow of events within each use case. The first step is to see an eye doctor who will give you a prescription. Once you have a prescription, you go to a optical dis- pensary, where you select your frames and place the order for your glasses. Once the glasses have been made, you return to the store for a fitting and pay for the glasses. D. Draw a use-case diagram for the process of buying glasses in exercise C. E. Create an activity diagram and a set of detail use-case descriptions for the following dentist’s office system, but do not bother to identify the flow of events within each use case. Whenever new patients are seen for the first time, they complete a patient information form that asks their name, address, phone number, and brief medical history, which are stored in the patient infor- mation file. When a patient calls to schedule a new appointment or change an existing appointment, the receptionist checks the appointment file for an avail- able time. Once a good time is found for the patient, the appointment is scheduled. If the patient is a new patient, an incomplete entry is made in the patient file; the full information will be collected when they arrive for their appointment. Because appointments are often made far in advance, the receptionist usually mails a reminder postcard to each patient two weeks before their appointment. F. Draw a use-case diagram for the dentist’s office system in exercise E. G. Complete the detail use-case descriptions for the den- tist’s office system in exercise E by identifying the nor- mal flow of events, subflows, and alternate/exceptional flows within the use cases. H. Create an activity diagram and a set of detail use case descriptions for an online university registration sys- tem. The system should enable the staff of each acad- emic department to examine the courses offered by their department, add and remove courses, and change the information about them (e.g., the maxi- mum number of students permitted). It should permit students to examine currently available courses, add and drop courses to and from their schedules, and examine the courses for which they are enrolled. Department staff should be able to print a variety of reports about the courses and the students enrolled in them. The system should ensure that no student takes too many courses and that students who have any unpaid fees are not permitted to register (assume that a fees data store is maintained by the university’s financial office, which the registration system accesses but does not change). I. Draw a use-case diagram for the online university reg- istration system in exercise H. J. Create an activity diagram and a set of detail use-case descriptions for the following system. A Real Estate Inc. (AREI) sells houses. People who want to sell their houses sign a contract with AREI, and provide infor- mation on their house. This information is kept in a database by AREI, and a subset of this information is sent to the citywide multiple listing service used by all real estate agents. AREI works with two types of potential buyers. Some buyers have an interest in one 204 Chapter 5 Functional Modeling specific house. In this case, AREI prints information from its database, which the real estate agent uses to help show the house to the buyer (a process beyond the scope of the system to be modeled). Other buyers seek AREI’s advice in finding a house that meets their needs. In this case, the buyer completes a buyer infor- mation form that is entered into a buyer data base, and AREI real estate agents use its information to search AREI’s data base and the multiple listing service for houses that meet their needs. The results of these searches are printed and used to help the real estate agent show houses to the buyer. K. Draw a use-case diagram for the real estate system in exercise J. L. Create an activity diagram and a set of detail use-case descriptions for the following system. A Video Store (AVS) runs a series of fairly standard video stores. Before a video can be put on the shelf, it must be cat- aloged and entered into the video database. Every cus- tomer must have a valid AVS customer card in order to rent a video. Customers rent videos for three days at a time. Every time a customer rents a video, the system must ensure that he or she does not have any overdue videos. If so, the overdue videos must be returned and an overdue fee paid before customer can rent more videos. Likewise, if the customer has returned overdue videos but has not paid the overdue fee, the fee must be paid before new videos can be rented. Every morn- ing, the store manager prints a report that lists overdue videos. If a video is two or more days overdue, the manager calls the customer to remind him or her to return the video. If a video is returned in damaged condition, the manager removes it from the video database and may sometimes charge the customer. M. Draw a use-case diagram for the video system in exercise L. N. Create an activity diagram and a set of detail use-case descriptions for a health club membership system. When members join the health club, they pay a fee for a certain length of time. Most memberships are for one year, but memberships as short as two months are available. Throughout the year, the health club offers a variety of discounts on their regular membership prices (e.g., two memberships for the price of one for Valentine’s day). It is common for members to pay dif- ferent amounts for the same length of membership. The club wants to mail out reminder letters to mem- bers asking them to renew their memberships one month before their memberships expire. Some mem- bers have become angry when asked to renew at a much higher rate than their original membership con- tract, so the club wants to track the prices paid so that the manager can override the regular prices with spe- cial prices when members are asked to renew. The sys- tem must track these new prices so that renewals can be processed accurately. One of the problems in the health club industry is the high turnover rate of mem- bers. Although some members remain active for many years, about half of the members do not renew their memberships. This is a major problem, because the health club spends a lot in advertising to attract each new member. The manager wants the system to track each time a member comes into the club. The system will then identify the heavy users and generate a report so the manager can ask them to renew their member- ships early, perhaps offering them a reduced rate for early renewal. Likewise, the system should identify members who have not visited the club in more than a month, so the manager can call them and attempt to reinterest them in the club. O. Draw a use-case diagram for the system in exercise N. P. Create an activity diagram and a set of detail use-case descriptions for the following system. Picnics R Us (PRU) is a small catering firm with five employees. During a typical summer weekend, PRU caters fifteen picnics with twenty to fifty people each. The business has grown rapidly over the past year and the owner wants to install a new computer system for managing the ordering and buying process. PUR has a set of ten standard menus. When potential customers call, the receptionist describes the menus to them. If the cus- tomer decides to book a picnic, the receptionist records the customer information (e.g., name, address, phone number, etc.) and the information about the picnic (e.g., place, date, time, which one of the standard menus, total price) on a contract. The customer is then faxed a copy of the contract and must sign and return it along with a deposit (often a credit card or by check) before the picnic is officially booked. The remaining money is collected when the picnic is delivered. Some- times, the customer wants something special (e.g., birthday cake). In this case, the receptionist takes the information and gives it to the owner, who determines the cost; the receptionist then calls the customer back with the price information. Sometimes the customer accepts the price, other times, the customer requests some changes that have to go back to the owner for a new cost estimate. Each week, the owner looks through the picnics scheduled for that weekend and orders the supplies (e.g., plates) and food (e.g., bread, chicken) Minicases 205 needed to make them. The owner would like to use the system for marketing as well. It should be able to track how customers learned about PUR and identify repeat customers, so that PUR can mail special offers to them. The owner also wants to track the picnics for which PUR sent a contract, but the customer never signed the contract and actually booked a picnic. Q. Draw a use-case diagram for the system in exercise P. R. Create an activity diagram and a set of detail use-case descriptions for the following system. Of-the-Month Club (OTMC) is an innovative young firm that sells memberships to people who have an interest in certain products. People pay membership fees for one year and each month receive a product by mail. For exam- ple, OTMC has a coffee-of-the-month club that sends members one pound of special coffee each month. OTMC currently has six memberships (coffee, wine, beer, cigars, flowers, and computer games), each of which costs a different amount. Customers usually belong to just one, but some belong to two or more. When people join OTMC, the telephone operator records the name, mailing address, phone number, e-mail address, credit-card information, start date, and membership service(s) (e.g., coffee). Some customers request a double or triple membership (e.g., two pounds of coffee, three cases of beer). The computer game membership operates a bit differently from the others. In this case, the member must also select the type of game (action, arcade, fantasy/science fiction, educational, etc.) and age level. OTMC is planning to greatly expand the number of memberships it offers (e.g., video games, movies, toys, cheese, fruit, and veg- etables), so the system needs to accommodate this future expansion. OTMC is also planning to offer three- month and six-month memberships. S. Draw a use-case diagram for the system in exercise R. T. Create an activity diagram and a set of detail use case descriptions for a university library borrowing system (do not worry about catalogue searching, etc.). The system will record the books owned by the library and will record who has borrowed which books. Before someone can borrow a book, he or she must show a valid ID card, which is checked against the student database maintained by the registrar’s office (for stu- dent borrowers), the faculty/staff database main- tained by the personnel office (for faculty/staff borrowers), or against the library’s own guest data- base (for individuals issued a guest card by the library) to ensure that it is still valid. The system must also check to ensure that the borrower does not have any overdue books or unpaid fines before he or she can borrow another book. Every Monday, the library prints and mails postcards to those people with over- due books. If a book is overdue by more than two weeks, a fine will be imposed and a librarian will tele- phone the borrower to remind him or her to return the book(s). Sometimes books are lost or are returned in damaged condition. The manager must then remove them from the database and will sometimes impose a fine on the borrower. U. Draw a use-case diagram for the system in exercise T. V. Consider the application that is used at your school to register for classes. Complete a use-case point work- sheet to estimate the effort to build such an applica- tion. You will need to make some assumptions about the application’s interfaces and the various factors that affect its complexity. W. For exercises G, H, J, L, N, P, R, and T, complete a use- case point worksheet to estimate the effort to build such an application. MINICASES 1. Williams Specialty Company is a small printing and engraving organization. When Pat Williams, the owner, brought computers into the business office five years ago, the business was very small and very simple. Pat was able to utilize an inexpensive PC- based accounting system to handle the basic infor- mation-processing needs of the firm. As time has gone on, however, the business has grown and the work being performed has become significantly more complex. The simple accounting software still in use is no longer adequate to keep track of many of the company’s sophisticated deals and arrangements with its customers. Pat has a staff of four people in the business office who are familiar with the intricacies of the company’s record-keeping requirements. Pat recently met with her staff to discuss her plan to hire an IS consulting firm to evaluate their information system needs and recom- mend a strategy for upgrading their computer system. The staff is excited about the prospect of a new system, because the current system causes them much aggrava- tion. No one on the staff has ever done anything like 206 Chapter 5 Functional Modeling this before, however, and they are a little wary of the consultants who will be conducting the project. Assume that you are a systems analyst on the con- sulting team assigned to the Williams Specialty Co. engagement. At your first meeting with the Williams staff, you want to be sure that they understand the work that your team will be performing and how they will participate in that work. a. Explain, in clear, nontechnical terms, the goals of the analysis of the project. b. Explain, in clear, nontechnical terms, how use cases and a use-case diagram will be used by the project team. Explain what these models are, what they represent in the system, and how they will be used by the team. 2. Professional and Scientific Staff Management (PSSM) is a unique type of temporary staffing agency. Many organizations today hire highly skilled, technical employees on a short-term, temporary basis to assist with special projects or to provide a needed technical skill. PSSM negotiates contracts with its client compa- nies in which it agrees to provide temporary staff in specific job categories for a specified cost. For exam- ple, PSSM has a contract with an oil and gas explo- ration company in which it agrees to supply geologists with at least a master’s degree for $5,000 per week. PSSM has contracts with a wide range of companies and can place almost any type of professional or sci- entific staff members, from computer programmers to geologists to astrophysicists. When a PSSM client company determines that it will need a temporary professional or scientific employee, it issues a staffing request against the contract it had pre- viously negotiated with PSSM. When a staffing request is received by PSSM’s contract manager, the contract number referenced on the staffing request is entered into the contract database. Using information from the database, the contract manager reviews the terms and conditions of the contract and determines whether the staffing request is valid. The staffing request is valid if the contract has not expired, the type of professional or scientific employee requested is listed on the original contract, and the requested fee falls within the negoti- ated fee range. If the staffing request is not valid, the contract manager sends the staffing request back to the client with a letter stating why the staffing request can- not be filled, and a copy of the letter is filed. If the staffing request is valid, the contract manager enters the staffing request into the staffing request database as an outstanding staffing request. The staffing request is then sent to the PSSM placement department. In the placement department, the type of staff member, experience, and qualifications requested on the staffing request are checked against the database of available professional and scientific staff. If a qualified individual is found, he or she is marked “reserved” in the staff database. If a qualified individual cannot be found in the database, or is not immediately available, the placement department creates a memo that explains the inability to meet the staffing request and attaches it to the staffing request. All staffing requests are then sent to the arrangements department. In the arrangements department the prospective temporary employee is contacted and asked to agree to the placement. After the placement details have been worked out and agreed to, the staff member is marked “placed” in the staff database. A copy of the staffing request and a bill for the placement fee is sent to the client. Finally, the staffing request, the “unable-to-fill” memo (if any), and a copy of the placement fee bill is sent to the contract manager. If the staffing request was filled, the contract manager closes the open staffing request in the staffing request database. If the staffing request could not be filled, the client is notified. The staffing request, placement fee bill, and unable-to-fill memo are then filed in the contract office. a. Create an activity diagram for the business process described here. b. Develop a use case for each major activity identi- fied in the activity diagram. c. Create a use-case diagram for the system described here. 207 A structural, or conceptual, model describes the structure of the data that supports the business processes in an organization. During analysis, the structural model presents the log- ical organization of data without indicating how the data are stored, created, or manipulated so that analysts can focus on the business, without being distracted by technical details. Later during design, the structural model is updated to reflect exactly how the data will be stored in databases and files. This chapter describes class-responsibility-collaboration (CRC) cards, class diagrams, and object diagrams, which are used to create the structural model. OBJECTIVES ■ Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. ■ Understand the processes used to create CRC cards, class diagrams, and object diagrams. ■ Be able to create CRC cards, class diagrams, and object diagrams. ■ Understand the relationship between the structural and use case models. CHAPTER OUTLINE CHAPTER 6 Structural Modeling Introduction Structural Models Classes, Attributes, and Operations Relationships CRC Cards Responsibilities and Collaborations Elements of a CRC Card Class Diagrams Elements of a Class Diagram Simplifying Class Diagrams Object Diagrams Creating CRC Cards and Class Diagrams Object Identification Building CRC Cards and Class Diagrams Applying the Concepts at CD Selections Step 1: Create CRC Cards Step 2: Examine Common Object Lists Step 3: Role-Play the CRC Cards Step 4: Create the Class Diagram Step 5: Review the Class Diagram Step 6: Incorporate Patterns Step 7: Review the Model Summary INTRODUCTION During analysis, analysts create functional models to represent how the business system will behave. At the same time, analysts need to understand the information that is used and created by the business system (e.g., customer information, order information). In this chapter, we discuss how the data underlying the behavior modeled in the use cases are organized and presented. A structural model is a formal way of representing the objects that are used and cre- ated by a business system. It illustrates people, places, or things about which informa- tion is captured and how they are related to each other. The structural model is drawn using an iterative process in which the model becomes more detailed and less concep- tual over time. In analysis, analysts draw a conceptual model, which shows the logical organization of the objects without indicating how the objects are stored, created, or manipulated. Because this model is free from any implementation or technical details, the analysts can focus more easily on matching the model to the real business require- ments of the system. In design, analysts evolve the conceptual structural model into a design model that reflects how the objects will be organized in databases and files. At this point, the model is checked for redundancy and the analysts investigate ways to make the objects easy to retrieve. The specifics of the design model are discussed in detail in the design chapters. In this chapter, we focus on creating a conceptual structural model of the objects using CRC cards and class diagrams. Using these techniques, it is possible to show all the objects of a business system. We first describe structural models and their elements. Then, we describe CRC cards, class diagrams, and object diagrams. Finally, we describe how to create structural models using CRC cards and class diagrams and how the structural model relates to the use-case descriptions and the use-case diagram that we learned about in Chapter 5. STRUCTURAL MODELS Every time a systems analyst encounters a new problem to solve, the analyst must learn the underlying problem domain. The goal of the analyst is to discover the key data contained in the problem domain and to build a structural model of the objects. Object-oriented modeling allows the analyst to reduce the semantic gap between the underlying problem domain and the evolving structural model. However, the real world and the world of soft- ware are very different. The real world tends to be messy, whereas the world of software must be neat and logical. As such, an exact mapping between the structural model and the problem domain may not be possible. In fact, it may not even be desirable. One of the primary purposes of the structural model is to create a vocabulary that can be used by the analyst and the users. Structural models represent the things, ideas, or concepts—that is, the objects—contained in the domain of the problem. They also allow the representation of the relationships between the things, ideas, or concepts. By creating a structural model of the problem domain, the analyst creates the vocabulary necessary for the analyst and users to communicate effectively. One important thing to remember is that at this stage of development, the structural model does not represent software components or classes in an object-oriented program- ming language, even though the structural model does contain analysis classes, attributes, operations, and relationships among the analysis classes. The refinement of these initial classes into programming-level objects comes later. Nonetheless, the structural model at this point should represent the responsibilities of each class and the collaborations between the classes. Typically, structural models are depicted using CRC cards, class diagrams, and, in some cases, object diagrams. However, before describing CRC cards, class diagrams, and object diagrams, we describe the basic elements of structural models: classes, attributes, operations, and relationships.1 208 Chapter 6 Structural Modeling 1 For a more complete description of the fundamental characteristics of object-oriented systems, see the appendix. Classes, Attributes, and Operations A class is a general template that we use to create specific instances, or objects, in the prob- lem domain. All objects of a given class are identical in structure and behavior but contain different data in their attributes. There are two different general kinds of classes of interest during analysis: concrete and abstract. Normally, when an analyst describes the application domain classes, they are referring to concrete classes; that is, concrete classes are used to cre- ate objects. Abstract classes do not actually exist in the real world; they are simply useful abstractions. For example, from an employee class and a customer class, we may identify a generalization of the two classes and name the abstract class person. We may not actually instantiate the person class in the system itself, instead creating and using only employees and customers.2 We describe generalization in more detail with the following relationships. A second classification of classes is the type of real-world thing that a class represents. There are domain classes, user interface classes, data structure classes, file structure classes, operating environment classes, document classes, and various types of multimedia classes. At this point in the development of our evolving system, we are interested only in domain classes. Later in design and implementation, the other types of classes become more relevant. An attribute of an analysis class represents a piece of information that is relevant to the description of the class within the application domain of the problem being investigated. An attribute contains information the analyst or user feels the system should store. For example, a possible relevant attribute of an employee class is employee name, whereas one that may not be as relevant is hair color. Both describe something about an employee, but hair color is probably not all that useful for most business applications. Only those attributes that are important to the task should be included in the class. Finally, only attributes that are primi- tive or atomic types (i.e., integers, strings, doubles, date, time, boolean, etc.) should be added. Most complex or compound attributes are really placeholders for relationships between classes. Therefore, they should be modeled as relationships, not attributes (see the following). The behavior of an analysis class is defined in an operation, or service. In later phases, the operations are converted to methods. However, because methods are more related to implementation, at this point in the development we use the term operation to describe the actions to which the instances of the class are capable of responding. Like attributes, only problem domain–specific operations that are relevant to the problem being investigated should be considered. For example, it is normally required that classes provide means of creating instances, deleting instances, accessing individual attribute values, setting individ- ual attribute values, accessing individual relationship values, and removing individual rela- tionship values. However, at this point in the development of the evolving system, the analyst should avoid cluttering up the definition of the class with these basic types of oper- ations and focus only on relevant problem domain–specific operations. Relationships There are many different types of relationships that can be defined, but all can be classified into three basic categories of data abstraction mechanisms: generalization relationships, aggregation relationships and association relationships. These data abstraction mechanisms allow the analyst to focus on the important dimensions while ignoring nonessential dimen- sions. Like attributes, the analyst must be careful to include only relevant relationships. Structural Models 209 2 Because abstract classes are essentially not necessary and are not instantiated, there have been arguments made that it would be better not to include any of them in the description of the evolving system at this stage of development (see J. Evermann and Y.Wand,“Towards Ontologically Based Semantics for UML Constructs,”in H. S. Junii, S. Jajodia, and A. Solvberg (eds.) ER 2001, Lecture Notes in Computer Science 2224 (Berlin: Springer-Verlag, 2001): 354–367. How- ever, because abstract classes have been included traditionally at this stage of development, we also include them. Generalization Relationships The generalization abstraction enables the analyst to cre- ate classes that inherit attributes and operations of other classes. The analyst creates a super- class that contains the basic attributes and operations that will be used in several subclasses. The subclasses inherit the attributes and operations of their superclass and can also contain attributes and operations that are unique just to them. For example, a customer class and an employee class can be generalized into a person class by extracting the attributes and oper- ations they have in common and placing them into the new superclass, person. In this way, the analyst can reduce the redundancy in the class definitions so that the common elements are defined once and then reused in the subclasses. Generalization is represented with the a-kind-of relationship, so that we say that an employee is a-kind-of person. The analyst also can use the flip side of generalization, specialization, to uncover addi- tional classes by allowing new subclasses to be created from an existing class. For example, an employee class can be specialized into a secretary class and an engineer class. Further- more, generalization relationships between classes can be combined to form generalization hierarchies. Based on the previous examples, a secretary class and an engineer class can be subclasses of an employee class, which in turn could be a subclass of a person class. This would be read as a secretary and an engineer are a-kind-of employee and a customer and an employee are a-kind-of person. The generalization data abstraction is a very powerful mechanism that encourages the analyst to focus on the properties that make each class unique by allowing the similarities to be factored into superclasses. However, to ensure that the semantics of the subclasses are maintained, the analyst should apply the principle of substitutability. By this we mean that the subclass should be capable of substituting for the superclass anywhere that uses the superclass (e.g., anywhere we use the employee superclass, we could also logically use its secretary subclass). By focusing on the a-kind-of interpretation of the generalization rela- tionship, the principle of substitutability is applied. Aggregation Relationships There have been many different types of aggregation or composition relationships proposed in data modeling, knowledge representation, and lin- guistics. For example, a-part-of (logically or physically), a-member-of (as in set member- ship), contained-in, related-to, and associated-with. However, generally speaking, all aggregation relationships relate parts to wholes or parts to assemblies. For our purposes, we use the a-part-of or has-parts semantic relationship to represent the aggregation abstrac- tion. For example, a door is a-part-of a car, an employee is a-part-of a department, or a department is a-part-of an organization. Like the generalization relationship, aggregation relationships can be combined into aggregation hierarchies. For example, a piston is a- part-of an engine, and an engine is a-part-of a car. Aggregation relationships are bidirectional in nature. The flip side of aggregation is decomposition. The analyst can use decomposition to uncover parts of a class that should be modeled separately. For example, if a door and engine are a-part-of a car, then a car has- parts door and engine. The analyst can bounce around between the various parts to uncover new parts. For example, the analyst can ask, What other parts are there to a car? or To which other assemblies can a door belong? Association Relationships There are other types of relationships that do not fit neatly into a generalization (a-kind-of) or aggregation (a-part-of) framework. Technically speak- ing, these relationships are usually a weaker form of the aggregation relationship. For example, a patient schedules an appointment. It could be argued that a patient is a-part-of an appointment. However, there is a clear semantic difference between this type of rela- tionship and one that models the relationship between doors and cars or even workers and unions. As such, they are simply considered to be associations between instances of classes. 210 Chapter 6 Structural Modeling CRC CARDS CRC cards are used to document the responsibilities and collaborations of a class. We use an extended form of the CRC card to capture all relevant information associated with a class.3 We describe the elements of our CRC cards later, after we explain responsibilities and collaborations. Responsibilities and Collaborations Responsibilities of a class can be broken into two separate types: knowing and doing. Knowing responsibilities are those things that an instance of a class must be capable of knowing. An instance of a class typically knows the values of its attributes and its rela- tionships. Doing responsibilities are those things that an instance of a class must be capa- ble of doing. In this case, an instance of a class can execute its operations or it can request a second instance, which it knows about, to execute one of its operations on behalf of the first instance. The structural model describes the objects necessary to support the business processes modeled by the use cases. Most use cases involve a set of several classes, not just one class. These classes form a collaboration. Collaborations allow the analyst to think in terms of clients, servers, and contracts.4 A client object is an instance of a class that sends a request to an instance of another class for an operation to be executed. A server object is the instance that receives the request from the client object. A contract formalizes the interac- tions between the client and server objects. For example, a patient makes an appointment with a doctor. This sets up an obligation for both the patient and doctor to appear at the appointed time. Otherwise, consequences, such as billing the patient for the appointment regardless of whether he or she appears, can be dealt out. Also, the contract should spell out what the benefits of the contract will be, such as a treatment being prescribed for whatever ails the patient and a payment to the doctor for the services provided. Chapter 9 provides a more detailed explanation of contracts and examples of their use. An analyst can use the idea of class responsibilities and client–server–contract collab- orations to help identify the classes, along with the attributes, operations, and relation- ships, involved with a use case. One of the easiest ways in which to use CRC cards in developing a structural model is through anthropomorphism—pretending that the classes have human characteristics. This is done by having analyst and/or the user role-play and pretend that they are an instance of the class being considered. They then can either ask questions of themselves or be asked questions by other members of the development team. For example: Who or what are you? What do you know? What can you do? The answers to the questions are then used to add detail to the evolving CRC cards. CRC Cards 211 3 Our CRC cards are based on the work of D. Bellin and S. S. Simone, The CRC Card Book (Reading, MA: Addison-Wesley, 1997); I. Graham, Migrating to Object Technology (Wokingham, England: Addison-Wesley, 1995); and B. Henderson-Sellers and B. Unhelkar, OPEN modeling with UML (Harlow, England: Addison-Wesley, 2000). 4 For more information, see K. Beck and W. Cunningham, “A Laboratory for Teaching Object-Oriented Think- ing,” Proceedings of OOPSLA, SIGPLAN Notices, 24, no. 10 (1989): 1–6; B. Henderson-Sellers and B. Unhelkar, OPEN Modeling with UML (Harlow, England: Addison-Wesley, 2000); C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliffs, NJ: Prentice Hall, 1998); B. Meyer, Object- Oriented Software Construction (Englewood Cliffs, NJ: Prentice Hall, 1994); and R. Wirfs-Brock, B. Wilkerson, and L. Wiener, Designing Object-Oriented Software (Englewood Cliffs, NJ, Prentice Hall, 1990). Elements of a CRC Card The set of CRC cards contains all the information necessary to build a logical structural model of the problem under investigation. Figure 6-1 shows a sample CRC card. Each CRC card captures and describes the essential elements of a class. The front of the card allows the recording of the class’s name, ID, type, description, list of associated use cases, respon- sibilities, and collaborators. The name of a class should be a noun (but not a proper noun, such as the name of a specific person or thing). Just like the use cases, in later stages of development, it is important to be able to trace back design decisions to specific require- ments. In conjunction with the list of associated use cases, the ID number for each class can be used to accomplish this. The description is simply a brief statement that can be used as a textual definition for the class. The responsibilities of the class tend to be the operations that the class must contain (i.e., the doing responsibilities). The back of a CRC card contains the attributes and relationships of the class. The attributes of the class represent the knowing responsibilities that each instance of the class 212 Chapter 6 Structural Modeling Front: Class Name: Patient ID: 3 Calculate last visit Make appointment Change status Provide medical history Responsibilities Associated Use Cases: 2Description: An individual that needs to receive or has received medical attention Type: Concrete, Domain Appointment Medical history Collaborators Back: Attributes: Insurance carrier (text) Amount (double) Relationships: Generalization (a-kind-of): Person Aggregation (has-parts): Medical History Other Associations: Appointment FIGURE 6-1 Sample CRC Card will have to meet. Typically, the data type of each attribute is listed with the name of the attribute (e.g., the amount attribute is double and the insurance carrier is text). There are three types of relationships typically captured at this point in time, generalization, aggre- gation, and other associations. In Figure 6-1, we see that a Patient is a-kind-of Person and that a Patient is associated with Appointments. Again, CRC cards are used to document the essential properties of a class. However, once the cards are filled out, the analyst can use the cards and anthropomorphism in role- playing to uncover missing properties by executing the different scenarios associated with the use cases (see Chapter 5). This can be used as a basis to test the clarity and complete- ness of the evolving representation of the system.5 CLASS DIAGRAMS A class diagram is a static model that shows the classes and the relationships among classes that remain constant in the system over time. The class diagram depicts classes, which include both behaviors and states, with the relationships between the classes. The follow- ing sections first present the elements of the class diagram, followed by the way in which a class diagram is drawn. Elements of a Class Diagram Figure 6-2 shows a class diagram that was created to reflect the classes and relationships needed for the set of use cases that describe the appointment system in Chapter 5. Class The main building block of a class diagram is the class, which stores and manages information in the system (see Figure 6-3). During analysis, classes refer to the people, places, events, and things about which the system will capture information. Later, during design and implementation, classes can refer to implementation-specific artifacts such as windows, forms, and other objects used to build the system. Each class is drawn using three part rectangles, with the class’s name at top, attributes in the middle, and operations at the bottom. We can see that Person, Medical Staff, Doctor, Patient, Medical History, Appoint- ment, Bill, Diagnosis, Health Problem, and Symptom are classes in Figure 6-2. The attrib- utes of a class and their values define the state of each object created from the class, and the behavior is represented by the operations. Attributes are properties of the class about which we want to capture information (see Figure 6-3). Notice that the Person class in Figure 6-2 contains the attributes lastname, firstname, address, phone, and birthdate. At times, you may want to store derived attributes, which are attributes that can be calculated or derived; these special attributes are denoted by placing a slash (/) before the attribute’s name. Notice how the person class contains a derived attribute called /age, which can be derived by subtracting the patient’s birth date from the current date. It is also possible to show the visibility of the attribute on the dia- gram. Visibility relates to the level of information hiding to be enforced for the attribute. The visibility of an attribute can either be public (ϩ), protected (#), or private (Ϫ). A public attribute is one that is not hidden from any other object. As such, other objects can modify its value. A protected attribute is one that is hidden from all other classes except its imme- diate subclasses. A private attribute is one that is hidden from all other classes. The default visibility for an attribute is normally private. Class Diagrams 213 5 For presentation purposes, we defer discussing walkthroughs and inspections to Chapter 8 and testing to Chapter 13. Operations are actions or functions that a class can perform (see Figure 6-3). The func- tions that are available to all classes (e.g., create a new instance, return a value for a particu- lar attribute, set a value for a particular attribute, delete an instance) are not explicitly shown within the class rectangle. Instead, only those operations unique to the class are included, such as the cancel without notice operation in the Appointment class and the generate cancellation fee operation in the Bill class in Figure 6-2. Notice that both the operations are followed by parentheses, which contain the parameter(s) needed by the operation. If an 214 Chapter 6 Structural Modeling Person -lastname -firstname -address -phone -birthdate -/age Patient -amount -insurance carrier +make appointment() +calculate last visit() +change status() +provides medical history() provides 0..1 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 1..* 1..* 1..* * 0..1 * 1 1 1 1 Appointment -time -date -reason +cancel without notice() +primary insurance carrier Bill -date -amount -purpose +generate cancellation fee() Medical History -heart disease -high blood pressure -diabetes -allergies Nurse Doctor Employee Health Team Administrative Staff Symptom -name Illness -description Treatment -medication -instructions -symptom severity suffer has scheduled leads to schedules FIGURE 6-2 Sample Class Diagram operation has no parameters, the parentheses are still shown but are empty. As with attrib- utes, the visibility of an operation can be designated as public, protected, or private. The default visibility for an operation is normally public. There are three kinds of operations that a class can contain: constructor, query, and update. A constructor operation creates a new instance of a class. For example, the patient class may have a method called insert (), which creates a new patient instance as patients are entered into the system. As we just mentioned, if an operation implements one of the basic functions (e.g., create a new instance), it is not explicitly shown on the class diagram, so typically we do not see constructor methods explicitly on the class diagram. Class Diagrams 215 A class: • Has a name typed in bold and centered in its top compartment. • Has a list of attributes in its middle compartment. • Represents a kind of person, place, or thing about which the system will need to capture and store information. • Has a list of operations in its bottom compartment. attribute name /derived attribute name operation name () • Does not explicitly show operations that are available to all classes. An attribute: • Represents properties that describe the state of an object. • Can be derived from other attributes, shown by placing a slash before the attribute’s name. An operation: • Represents the actions or functions that a class can perform. • Can be classified as a constructor, query, or update operation. • Includes parentheses that may contain parameters or information needed to perform the operation. An association: • Represents a relationship between multiple classes or a class and itself. A generalization: • Is labeled using a verb phrase or a role name, whichever better represents the relationship. An aggregation: • Represents a logical a-part-of relationship between multiple classes or a class and itself. • Is a special form of an association. A composition: • Represents a physical a-part-of relationship between multiple classes or a class and itself • Is a special form of an association. • Can exist between one or more classes. • Represents a-kind-of relationship between multiple classes. • Contains multiplicity symbols, which represent the minimum and maximum times a class instance can be associated with the related class instance. Class 1 -attribute1 +operation1() AssociatedWith 0..* 1 0..* 1IsPartOf 1..* 1IsPartOf FIGURE 6-3 Class Diagram Syntax A query operation makes information about the state of an object available to other objects, but it does not alter the object in any way. For instance, the calculate last visit () operation that determines when a patient last visited the doctor’s office will result in the object being accessed by the system, but it will not make any change to its information. If a query method merely asks for information from attributes in the class (e.g., a patient’s name, address, phone), then it is not shown on the diagram because we assume that all objects have operations that produce the values of their attributes. An update operation changes the value of some or all the object’s attributes, which may result in a change in the object’s state. Consider changing the status of a patient from new to current with a method called change status () or associating a patient with a particular appointment with schedule appointment (appointment). Relationships A primary purpose of a class diagram is to show the relationships, or asso- ciations, that classes have with one another. These are depicted on the diagram by drawing lines between classes (see Figure 6-3). When multiple classes share a relationship (or a class shares a relationship with itself), a line is drawn and labeled with either the name of the relationship or the roles that the classes play in the relationship. For example, in Figure 6-2 the two classes patient and appointment are associated with one another whenever a patient schedules an appointment. Thus, a line labeled schedules connects patient and appointment, representing exactly how the two classes are related to each other. Also, notice that there is a small solid triangle beside the name of the relationship. The triangle allows a direction to be associated with the name of the relationship. In Figure 6-2, the schedules relationship includes a triangle, indicating that the relationship is to be read as patient schedules appointment. Inclusion of the triangle simply increases the readability of the dia- gram. In Figure 6-4, three additional examples of associations are portrayed: an Invoice is AssociatedWith a Purchase Order (and vice versa), a Pilot Flies an Aircraft, and a Spare Tire IsLocatedIn a Trunk. Sometimes a class is related to itself, as in the case of a patient being the primary insur- ance carrier for other patients (e.g., spouse, children). In Figure 6-2, notice that a line was drawn between the patient class and itself and called primary insurance carrier to depict the role that the class plays in the relationship. Notice that a plus (ϩ) sign is placed before the label to communicate that it is a role as opposed to the name of the relationship. When labeling an association, we use either a relationship name or a role name (not both), whichever communicates a more thorough understanding of the model. 216 Chapter 6 Structural Modeling Purchase Order Aircraft TrunkSpare Tire Pilot Invoice 0..* 1 0..* 0..* Flies 0..1 0..1 IsLocatedIn Associated With FIGURE 6-4 Sample Association Relationships also have multiplicity, which documents how an instance of an object can be associated with other instances. Numbers are placed on the association path to denote the minimum and maximum instances that can be related through the association in the format minimum number .. maximum number (see Figure 6-5). The numbers spec- ify the relationship from the class at the far end of the relationship line to the end with the number. For example, in Figure 6-2, there is a 0..* on the appointment end of the patient schedules appointment relationship. This means that a patient can be associated with zero through many different appointments. At the patient end of this same relationship there is a 1, meaning that an appointment must be associated with one and only one (1) patient. In Figure 6-4, we see that an instance of the Invoice class must be AssociatedWith one instance of the Purchase Order class and that an instance of the Purchase Order class may be AssociatedWith zero or more instances of the Invoice class, an instance of the Pilot class Flies zero or more instances of the Aircraft class and that an instance of the Aircraft class may be flown by zero or more instances of the Pilot class; finally, we see that an instance the Spare Tire class IsLocatedIn zero or one instance of the Trunk class, whereas an instance of the Trunk class can contain zero or one instance of the Spare Tire class. There are times when a relationship itself has associated properties, especially when its classes share a many-to-many relationship. In these cases, a class called an association class is formed, which has its own attributes and operations. It is shown as a rectangle attached by a dashed line to the association path, and the rectangle’s name matches the label of the association. Think about the case of capturing information about illnesses and symptoms. An illness (e.g., the flu) can be associated with many symptoms (e.g., sore throat, fever), Class Diagrams 217 1 0..* 1..* 0..1 2..4 1..3,5 Exactly one A department has one and only one boss. Zero or more One or more Zero or one Specified range Multiple, disjoint ranges An employee has zero to many children. A boss is responsible for one or more employees. An employee can be married to zero or one spouse. An employee can take from two to four vacations each year. An employee is a member of one to three or five committees. Department Boss1 Employee Child0..* Boss Employee1..* Employee Spouse0..1 Employee Vacation2..4 Employee Committee1..3,5 FIGURE 6-5 Multiplicity and a symptom (e.g., sore throat) can be associated with many illnesses (e.g., the flu, strep throat, the common cold). Figure 6-2 shows how an association class can capture infor- mation about remedies that change depending on the various combinations. For example, a sore throat caused by strep throat will require antibiotics; whereas, treatment for a sore throat from the flu or a cold could be throat lozenges or hot tea. Another way to decide when to use an association class is when attributes that belong to the intersection of the two classes involved in the association must be captured. We can visually think about an asso- ciation class as a Venn diagram. For example, in Figure 6-6, the Grade idea is really an inter- section of the Student and Course classes, because a grade exists only at the intersection of these two ideas. Another example shown in Figure 6-6 is that a job may be viewed as the intersection between a Person and a Company. Most often, classes are related through a normal association; however, there are two special cases of an association that you will see appear quite often: generalization and aggregation. Generalization and Aggregation Associations A generalization association shows that one class (subclass) inherits from another class (superclass), meaning that the properties and operations of the superclass are also valid for objects of the subclass. The generalization 218 Chapter 6 Structural Modeling CourseStudent 0..* 0..* Grade CompanyPerson 0..* 0..* Job Person CompanyJob Student CourseGrade FIGURE 6-6 Sample Association Classes path is shown with a solid line from the subclass to the superclass and a hollow arrow pointing at the superclass (see Figure 6-3). For example, Figure 6-2 communicates that doctors, nurses, and administrative personnel are all kinds of employees and those employees and patients are kinds of persons. Remember that the generalization relationship occurs when you need to use words like is a kind of to describe the relationship. Some additional examples of generalization are given in Figure 6-7. For example, Cardinal is a kind of Bird, which is a kind of Animal; a General Practitioner is a kind of Physician, which is a kind of Person; and a Truck is a kind of Land (Vehicle), which is a kind of Vehicle. An aggregation association is used when classes actually comprise other classes. For example, think about a doctor’s office that has decided to create health-care teams that include doctors, nurses, and administrative personnel. As patients enter the office, they are Class Diagrams 219 TroutCardinal FishBird Animal CarTruck Land HelicopterPlane Air SubmarineShip Sea PatientPhysician SpecialistGeneral Practitioner Person Vehicle FIGURE 6-7 Sample Generalizations assigned to a health-care team, which cares for their needs during their visits. Figure 6-2 shows how this relationship is denoted on a class diagram. A diamond is placed nearest the class representing the aggregation (health-care team), and lines are drawn from the arrow to connect the classes that serve as its parts (doctors, nurses, and administrative personnel). Typically, you can identify these kinds of associations when you need to use words like is a part of or is made up of to describe the relationship. However, from a UML perspective, there are two types of aggregation associations: aggregation and composition (see Figure 6-3). Aggregation is used to portray logical a part of relationships and is depicted on a UML class diagram by a hollow or white diamond. For example in Figure 6-8, three logical aggrega- tions are shown. Logical implies that it is possible for a part be associated with multiple wholes or that is relatively simple for the part to be removed from the whole. For example, an instance of the Employee class IsPartOf an instance of at least one instance of the Department class, an instance of the Wheel class IsPartOf an instance of the Vehicle class, and an instance of the Desk class IsPartOf an instance of the Office class. Obviously, it is relatively easy to remove a wheel from a vehicle or move a desk from an office. Composi- tion is used to portray a physical part of relationships and is shown by a black diamond. Physical implies that the part can be associated with only a single whole. For example in Figure 6-9, three physical compositions are illustrated: an instance of a door can be a part of only a single instance of a car, an instance of a room can be a part of an instance only of 220 Chapter 6 Structural Modeling Department Vehicle OfficeDesk Wheel Employee 1..* 1..* 1..* 1 Is Part Of Is Part Of Is Part Of0..* 1 Car Building MouseButton Room Door 1..* 1 1..* 1 Is Part Of Is Part Of Is Part Of1..* 1 FIGURE 6-8 Sample Aggregation Associations FIGURE 6-9 Sample Composition Associations a single building; and an instance of a button can be a part of only a single mouse. How- ever, in many cases, the distinction that you can achieve by including aggregation (white diamonds) and composition (black diamonds) in a class diagram may not be worth the price of adding additional graphical notation for the client to learn. As such, many UML experts view the inclusion of aggregation and composition notation to the UML class diagram as simply “syntactic sugar” and, as such, not necessary because the same information can always be portrayed by simply using the association syntax. Simplifying Class Diagrams When a class diagram is fully populated with all the classes and relationships for a real- world system, the class diagram can become very difficult to interpret (i.e., be very com- plex). When this occurs, it is sometimes necessary to simplify the diagram. One way to simplify the class diagram is to show only concrete classes.6 However, depending on the number of associations that are connected to abstract classes—and thus inherited down to the concrete classes—this particular suggestion could make the diagram more difficult to comprehend. A second way to simplify the class diagram is through the use of a view mechanism. Views were developed originally with relational database management systems and are simply a subset of the information contained in the database. In this case, the view would be a useful subset of the class diagram, such as a use case view that shows only the classes and relationships relevant to a particular use case. A second view could be to show only a particular type of relationship: aggregation, association, or generalization. A third type of view is to restrict the information shown with each class, for example, show only the name of the class, the name and attributes, or the name and operations. These view mechanisms can be combined to further simplify the diagram. A third approach to simplifying a class diagram is through the use of packages (i.e., logical groups of classes). To make the diagrams easier to read and keep the models at a rea- sonable level of complexity, the classes can be grouped together into packages. Packages are general constructs that can be applied to any of the elements in UML models. In Chapter 5, we introduced them to simplify use-case diagrams. In the case of class diagrams, it is simple to sort the classes into groups based on the relationships that they share.7 Object Diagrams Although class diagrams are necessary to document the structure of the classes, there are times when a second type of static structure diagram, called an object diagram, can be useful. An object diagram is essentially an instantiation of all or part of a class dia- gram. Instantiation means to create an instance of the class with a set of appropriate attribute values. Object diagrams can be very useful when trying to uncover details of a class. Generally speaking, it is easier to think in terms of concrete objects (instances) rather than abstrac- tions of objects (classes). For example in Figure 6-10, a portion of the class diagram in Figure 6-2 has been copied and instantiated. The top part of the figure simply is a copy of a small view of the overall class diagram. The lower portion is the object diagram that instantiates that subset of classes. By reviewing the actual instances involved, John Doe, Appt1, and Dr. Smith, we may discover additional relevant attributes, relationships, and/or Class Diagrams 221 6 See Footnote 2. 7 For those familiar with structured analysis and design, packages serve a similar purpose as the leveling and bal- ancing processes used in data flow diagramming. Packages and package diagrams are described in more detail in Chapter 8. operations or possibly misplaced attributes, relationships, and/or operations. For example, an appointment has a reason attribute. Upon closer examination, the reason attribute may have been better modeled as an association with the Symptom class. Currently, the Symp- tom class is associated with the Patient class. After reviewing the object diagram, this seems to be in error. As such, we should modify the class diagram to reflect this new understanding of the problem. CREATING CRC CARDS AND CLASS DIAGRAMS Creating a structural model is an iterative process whereby the analyst makes a rough cut of the model and then refines it over time. Structural models can become quite complex— in fact, there are systems that have class diagrams containing hundreds of classes. In this section, we go through one iteration of creating a structural model, but we would expect that the model would change dramatically as we communicate with users and fine-tune our understanding of the system. However, before we do this, we first present a set of 222 Chapter 6 Structural Modeling Patient -amount -insurance carrier +make appointment() +calculate last visit() +change status() +provide medical history() 0..* 0..* 0..*0..* 1..* 1..* 1 1 Appointment -time -date -reason +cancel without notice() +primary insurance carrier Doctor Symptom -name suffer schedules has scheduled John Doe: Patient lastname = “Doe” firstname = “John” address = “1000 Main Street” phone = “555-555-5555” birthdate = 01/01/72 / age = 32 amount = $0.00 insurance carrier = “JD Health Insurance” Appt1: Appointment Dr. Smith: Doctor time = 3:00 date = 7/7/2004 reason = “pain in neck” Symptom1: Symptom name = “muscle pain” lastname = “Smith” firstname = “Jane” address = “Doctor’s Clinic” phone = “999-555-5555” birthdate : 12/12/64 / age = 39 FIGURE 6-10 Sample Object Diagram approaches to identify and refine a set of candidate objects and provide a set of steps based on these approaches that can be used to create the initial rough cut structural model. Object Identification Many different approaches have been suggested to aid the analyst in identifying a set of candidate objects for the structural model. The three most common approaches are textual analysis, common object lists, and patterns. Most analysts use a combination of all three techniques to make sure that no important objects and object attributes, operations, and relationships have been overlooked. Textual Analysis Textual analysis is an analysis of the text in the use-case descriptions. The analyst starts by reviewing the use-case descriptions and the use-case diagrams. The text in the descriptions is examined to identify potential objects, attributes, operations, and relationships. The nouns in the use case suggest possible classes, whereas the verbs suggest possible operations. Figure 6-11 presents a summary of guidelines we have found useful. The textual analysis of use-case descriptions has been criticized as being too simple, but because its primary purpose is to create an initial rough-cut structural model, its simplicity is a major advantage. Common Object List As its name implies, a common object list is simply a list of objects common to the business domain of the system. In addition to looking at the specific use cases, the analyst also thinks about the business, separately from the use cases. Several categories of objects have been found to help the analyst in the creation of the list, such as physical or tangible things, incidents, roles, and interactions.8 Analysts should first look for physical, or tangible, things in the business domain. These could include books, desks, chairs, and office equipment. Normally, these types of objects are the easiest to identify. Incidents are events that occur in the business domain, such as meetings, flights, performances, or accidents. Reviewing the use cases can readily identify the roles that the people play in the problem, such as doctor, nurse, patient, or receptionist. Typically, an interaction is a transaction that takes Creating CRC Cards and Class Diagrams 223 • A common or improper noun implies a class of objects. • A proper noun or direct reference implies an instance of a class. • A collective noun implies a class of objects made up of groups of instances of another class. • An adjective implies an attribute of an object. • A doing verb implies an operation. • A being verb implies a classification relationship between an object and its class. • A having verb implies an aggregation or association relationship. • A transitive verb implies an operation. • An intransitive verb implies an exception. • A predicate or descriptive verb phrase implies an operation. • An adverb implies an attribute of a relationship or an operation. Source: These guidelines are based on Russell J. Abbott, “Program Design by Informal English Descriptions,” Com- munications of the ACM 26, no. 11 (1983): 882–894; Peter P-S Chen, “English Sentence Structure and Entity-Relationship Diagrams,” Information Sciences: An International Journal 29, no. 2–3 (1983): 127–149; and Graham, Migrating to Object Technology. FIGURE 6-11 Textual Analysis Guidelines 8 For example, see C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliffs, NJ: Prentice Hall, 1998); and S. Shlaer and S. J. Mellor, Object-Oriented Systems Analysis: Modeling the World in Data (Englewood Cliffs, NJ: Yourdon Press, 1988). place in the business domain, such as a sales transaction. Other types of objects that can be identified include places, containers, organizations, business records, catalogs, and policies. In rare cases, processes themselves may need information stored about them. In these cases processes may need an object, in addition to a use case, to represent them. Patterns The idea of using patterns is a relatively new area in object-oriented systems development.9 There have been many definitions of exactly what a pattern is. From our perspective, a pattern is simply a useful group of collaborating classes that provide a solution to a commonly occurring problem. Because patterns provide a solution to commonly occurring problems, they are reusable. An architect, Christopher Alexander, has inspired much of the work associated with using patterns in object-oriented systems development. According to Alexander and his colleagues,10 it is possible to make very sophisticated buildings by stringing together com- monly found patterns, rather than creating entirely new concepts and designs. In a very similar manner, it is possible to put together commonly found object-oriented patterns to form elegant object-oriented information systems. For example, many business transac- tions involve the same type of objects and interactions. Virtually all transactions would require a transaction class, a transaction line item class, an item class, a location class, and a participant class. By simply reusing these existing patterns of classes, we can more quickly and more completely define the system than if we start with a blank piece of paper. Many different types of patterns have been proposed, ranging from high-level business- oriented patterns to more low-level design patterns. For example, Figure 6-12 depicts a very useful pattern: the Sales Order Contract pattern11. Figure 6-13 lists some common business domains for which patterns have been developed and their source. If we are developing a business information system in one of these business domains, then the patterns developed for that domain may be a very useful starting point in identifying needed classes and their attributes, operations, and relationships. 224 Chapter 6 Structural Modeling 9 There have been many books devoted to this topic; for example, see Peter Coad, David North, and Mark Mayfield, Object Models: Strategies, Patterns, & Applications, 2nd ed. (Englewood Cliffs, NJ: Prentice Hall, 1997); Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML: Business Patterns at Work (New York: Wiley, 2000); Martin Fowler, Analysis Patterns: Reusable Object Models (Reading, MA: Addison-Wesley, 1997); Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software (Reading, MA: Addison-Wesley, 1995); David C. Hay, Data Model Patterns: Conventions of Thought (New York: Dorset House, 1996). 10 Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel, A Pattern Language (New York: Oxford University Press, 1977). 11 This pattern is based on the sales order contract pattern described in David C. Hay, Data Model Patterns: Conventions of Thought (New York: Dorset House, 1996). OrganizationPerson Product Type Line Item Sales Order Party ** *1 ** contains includes places FIGURE 6-12 Sales Order Contract Pattern Building CRC Cards and Class Diagrams It is important to remember that CRC cards and class diagrams can be used to describe both the as-is and to-be structural models of the evolving system, but they are most often used for the to-be model. There are many different ways to identify a set of candidate objects and to create CRC cards and class diagrams. Today most object identification begins with the use cases identified for the problem (See Chapter 5). In this section, we describe a seven-step process used to create the structural model of the problem (see Figure 6-14). Creating CRC Cards and Class Diagrams 225 Accounting 3, 4 Actor-Role 2 Assembly-Part 1 Container-Content 1 Contract 2, 4 Document 2, 4 Employment 2, 4 Financial Derivative Contracts 3 Geographic Location 2, 4 Group-Member 1 Interaction 1 Material Requirements Planning 4 Organization and Party 2, 3 Plan 1, 3 Process Manufacturing 4 Trading 3 Transactions 1, 4 1. Peter Coad, David North, and Mark Mayfield, Object Models: Strate- gies, Patterns, and Applications, 2nd ed. (Englewood Cliffs, NJ: Prentice Hall, 1997). 2. Hans-Erik Eriksson and Magnus Penker, Business Modeling with UML: Business Patterns at Work, (New York: Wiley, 2000). 3. Martin Fowler, Analysis Patterns: Reusable Object Models (Reading, MA: Addison-Wesley, 1997). 4. David C. Hay, Data Model Patterns: Conventions of Thought (New York, NY, Dorset House, 1996). Business Domains Sources of Patterns FIGURE 6-13 Useful Patterns 1. Create CRC cards by performing textual analysis on the use cases. 2. Brainstorm additional candidate classes, attributes, operations, and relationships by using the common object list approach. 3. Role-play each use case using the CRC cards. 4. Create the class diagram based on CRC cards. 5. Review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships. 6. Incorporate useful patterns. 7. Review the structural model. FIGURE 6-14 Steps for Object Identification and Structural Modeling Step 1: Create CRC Cards We could begin creating the structural model with a class dia- gram instead of CRC cards. However, due to the ease of role-playing with CRC cards, we prefer to create the CRC cards first and then transfer the information from the CRC cards into a class diagram later. As a result, the first step of our recommended process is to cre- ate CRC cards. This is done by performing textual analysis on the use case descriptions. If you recall, the normal flow of events, subflows, and alternate/exceptional flows written as part of the use case were written in a special form called Subject–Verb–Direct object–Preposition– Indirect object (SVDPI). By writing use-case events in this form, it is easier to use the guidelines for use case analysis in Figure 6-11 to identify the objects. Reviewing the primary actors, stakeholders and interests, and brief descriptions of each use case allows additional candidate objects to be identified. Furthermore, it is useful to go back and review the original requirements to look for information that was not included in the text of the use cases. Record all the uncovered information for each candidate object on a CRC Card. Step 2: Examine Common Object Lists The second step is to brainstorm additional candidate objects, attributes, operations, and relationships using the common object list approach. What are the tangible things associated with the problem? What are the roles played by the people in the problem domain? What incidents and interactions take place in the problem domain? As you can readily see, by beginning with the use cases, many of these questions already have partial answers. For example, the primary actors and stakeholders are the roles that are played by the people in the problem domain. However, it is possible to uncover additional roles not thought of previously. This obviously would cause the use cases and the use-case model to be modified and possibly expanded. As in the previous step, be sure to record all the uncovered information onto the CRC cards. This includes any modifications uncovered for any previously identified candidate objects and any informa- tion regarding any new candidate objects identified. Step 3: Role-Play the CRC Cards The third step is to role-play each use-case scenario using the CRC cards.12 Each CRC card should be assigned to an individual, who will per- form the operations for the class on the CRC card. As the performers play out their roles, the system will tend to break down. When this occurs, additional objects, attributes, oper- ations, or relationships will be identified. Again, like the previous steps, any time any new information is discovered, new CRC cards are created or modifications to existing CRC cards are made. Step 4: Create the Class Diagram The fourth step is to create the class diagram based on the CRC cards. This is equivalent to creating the use-case diagram from the use case descriptions. Information contained on the CRC cards is simply transferred to the class diagrams. The responsibilities are transferred as operations, the attributes are drawn as attributes, and the relationships are drawn as generalization, aggregation, or association relationships. However, the class diagram also requires that the visibility of the attributes and operations be known. As a general rule of thumb, attributes are private and operations are public. Therefore, unless the analyst has a good reason to change the default visibility of these properties, then the defaults should be accepted. Finally, the analyst should examine the model for additional opportunities to use aggregation or generalization relationships. 226 Chapter 6 Structural Modeling 12 For more information on role playing scenarios using CRC cards, see D. Bellin and S. Suchman Simone, The CRC Card Book (Reading, MA: Addison-Wesley, 1997); G. Kotonya and I. Sommerville, Requirements Engineering (Chichester, England: Wiley, 1998), and D. Leffingwell and D. Widrig, Managing Software Requirements: A Unified Approach (Reading, MA: Addison-Wesley, 2000). These types of relationships can simplify the individual class descriptions. As in the previous steps any and all changes must be recorded on the CRC cards. Step 5: Review the Class Diagram The fifth step is to review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships. Up until this step, the focus of the process has been on adding information to the evolving model. At this point in time, the focus begins to switch from simply adding information to also challenging the reasons for including the information contained in the model. Step 6: Incorporate Patterns The sixth step is to incorporate useful patterns into the evolving structural model. A useful pattern is one that would allow the analyst to more fully describe the underlying domain of the problem being investigated. Looking at the collection of patterns available (Figure 6-13) and comparing the classes contained in the patterns with those in the evolving class diagram does this. After identifying the useful patterns, the analyst incorporates the identified patterns into the class diagram and modifies the affected CRC cards. This includes adding and removing classes, attributes, operations, and/or relationships. Step 7: Review the Model The seventh and final step is to validate the structural model, including both the CRC cards and the class diagram. This is best accomplished during a formal review meeting using a walkthrough approach, in which an analyst pre- sents the model to a team of developers and users. The analyst walks through the model, explaining each part of the model and all the reasoning that went into the decision to include each of the classes in the structural model. This explanation includes justifica- tions for the attributes, operations, and relationships associated with the classes. Finally, each class should be linked back to at least one use case; otherwise, the purpose of including the class in the structural model will not be understood. It is often best if the review team also includes people outside the development team that produced the model because these individuals can bring a fresh perspective to the model and uncover missing objects.13 Creating CRC Cards and Class Diagrams 227 13 We describe walkthroughs, verification, and validation in Chapter 8 and testing in Chapter 13. Using Figure 6-1 as a template, complete the CRC cards for the remaining identified classes in Figure 6-2. 6-1 Appointment SystemYOUR TURN In Your Turn 5-2, you created a set of the use cases from the campus housing service that helps students find apart- ments. Using the same use cases, create a structural model (CRC cards and class diagram). See if you can identify at least one potential derived attribute, aggregation relation- ship, generalization relationship, and association relation- ship for the model. 6-2 Campus HousingYOUR TURN APPLYING THE CONCEPTS AT CD SELECTIONS The previous chapter described the CD Selections Internet Sales System (see Figures 5-14 through 5-20). In this section, we demonstrate the process of structural modeling using one of the use cases identified: Place Order (see Figure 5-17). Even though we are using just one of the use cases for our structural model, you should remember that to create a complete structural model, all use cases should be used. Step 1: Create CRC Cards The first step Alec and the team took was to create the set of CRC cards by performing tex- tual analysis on the use cases. To begin with, Alec chose the Place Order use case (see Figure 5-17). He and his team then used the textual analysis rules (see Figure 6-11) to identify the candidate classes, attributes, operations, and relationships. Using these rules on the Normal Flow of Events, they identified Customer, Search Request, CD, List, and Review as candidate classes. They uncovered three different types of search requests: Title Search, Artist Search, and Category Search. By applying the textual analysis rules to the Brief Description, an addi- tional candidate class was discovered: Order. By reviewing the verbs contained in this use case, they saw that a Customer places an Order and that a Customer makes a Search Request. To be as thorough as possible, Alec and his team also reviewed the original require- ments used to create the use case. The original requirements are contained in Figure 4-15. After reviewing this information, they identified a set of attributes for the Customer (name, address, e-mail, and credit card) and Order (CDs to purchase and quantity) classes and uncovered additional candidate classes: CD Categories and Credit-Card Clearance Center. Furthermore, they realized that the Category Search class used the CD Categories class. Finally, they also identified three subclasses of CD Categories: Rock, Jazz, and Classical. Alec’s goal, at this point in time, was to be as complete as possible. As such, he realized that they might have identified many candidate classes, attributes, operations, and relationships that might not be included in the final structural model. Step 2: Examine Common Object Lists The second step for Alec and his team was to brainstorm additional candidate classes, attrib- utes, operations, and relationships. He asked the team members to take a minute and think 228 Chapter 6 Structural Modeling A large direct health and insurance medical provider needed an Enterprise Information Management (EIM) system to enable enterprisewide information management and support the effective use of data for critical cross- functional decision making. In addition, the client needed to resolve issues related to data redundancy, inconsistency and unnecessary expenditure. The client faced information challenges such as these: The company data resided in mul- tiple sources and was developed for department-specific use, with limited enterprise access. In addition, departments created varied data definitions and data were being man- aged by multiple departments within the company. Source: http://www.deloitte.com/dtt/case_study/0,1005,sid% 253D26562%02526cid%253D132760,00.html Questions 1. Should the company assess their current informa- tion management? 2. How would a structural model aid the firm in under- standing their current information management? What solution would you propose? 6-A Health and Insurance Medical Provider—Implementing an EIM SystemCONCEPTS IN ACTION Applying the Concepts at CD Selections 229 Front: Class Name: Customer ID: 1 Responsibilities Associated Use Cases: 3Description: An individual that may or has purchased merchan- dise from the CD Selections Internet sales system Type: Concrete, Domain Collaborators Back: Attributes: Last name First name Street address City State Zip code Country E-mail Credit card Relationships: Generalization (a-kind-of): Aggregation (has-parts): Other Associations: Order; Search Request Middle initial FIGURE 6-15 Customer Class CRC Card about what information they would like to keep about CDs. The information that they thought of was a set of attributes—for example, title, artist, quantity on hand, price, and category. He then asked them to take another minute and think about the information that they should store about orders and an order’s responsibilities. The responsibilities they identi- fied were a set of operations, including calculate tax, calculate extension price, calculate shipping, and calculate total. Currently, the attributes (CDs to purchase and quantity) of Order implied that a customer should be allowed to order multiple copies of the same CD and allow different CDs to be ordered on the same order. However, the current structural model did not allow this. As such, they created a new class that was associated with both the Order class and the CD class: Order Line Item. This new class only had one attribute, quantity, but it had two relationships: one with Order and the other with CD. When they reviewed the Customer class, they decided that the name and address attrib- utes needed to be expanded; name should become last name, first name, and middle initial, and address should become street address, city, state, country, and zip code. The updated Cus- tomer class and Order class CRC cards are shown in Figures 6-15 and 6-16, respectively. Step 3: Role-Play the CRC Cards The third step was to role-play the classes recorded on the CRC cards. The purpose of this step was to validate the current state of the evolving structural model. Alec handed out the CRC cards to different members of his team. Using the CRC cards, they began executing the different use cases (see Figure 5-18), one at a time, to see if the current structural model could support each use case or whether the use case caused the system to crash. Anytime 230 Chapter 6 Structural Modeling Front: Class Name: Order ID: 2 Calculate shipping Calculate tax Calculate total Responsibilities Associated Use Cases: 3Description: An order that has been placedby a customer which includes the individualitems purchasedby the customer Type: Concrete, Domain Collaborators Back: Attributes: Shipping Tax Total Relationships: Generalization (a-kind-of): Aggregation (has-parts): Other Associations: Order Item; Customer FIGURE 6-16 Order Class CRC Card Complete the CRC cards for the remaining identified classes. 6-3 CD Selections Internet Sales SystemYOUR TURN the system crashed, there was something missing: a class, an attribute, a relationship, or an operation. They would then add the missing information to the structural model and try executing the use case again. First, Alec and the team decided that the customer had requested the system to per- form a search for all the CDs associated with a specific artist. Based on the current CRC cards, the team felt that the system would produce an accurate list of CDs. They then tried to ask the system for a set of reviews of the CDs. At this point in the exercise, the system crashed. The CRC cards did not have the Review class associated with the CD class. There- fore, there was no way to retrieve the requested information. This observation raised another question: was there other marketing information that should be made available to the customer—for example, artist information and sample clips? Next, the team realized that vendor information should be a separate class that was associated with a CD rather than an additional attribute of a CD. This was because vendors had additional information and operations themselves. If the team had modeled the vendor information as an attribute of CD, then the additional information and operations would have been lost. They continued role-playing each of the use cases until they were comfort- able with the structural model’s ability to support each and every one. Step 4: Create the Class Diagram The fourth step was to create the class diagram from the CRC cards. Figure 6-17 shows the current state of the evolving structural model as depicted in a class diagram based on the Places Order use case. Step 5: Review the Class Diagram The fifth step was to review the structural model for missing and/or unnecessary classes, attributes, operations, and relationships. At this point, the team challenged all components of the model (class, attribute, relationship, or operation) that did not seem to be adding any- thing useful to the model. If a component could not be justified sufficiently, then they removed it from the structural model. By carefully reviewing the current state of the struc- tural model, they were able to challenge more than a third of the classes contained in the class diagram (see Figure 6-17). It seemed that the CD categories and their subclasses were not really necessary. There were no attributes or operations for these classes. As such, the idea of CD categories was modeled as an attribute of a CD. The category attribute for the CD class was previously uncovered during the brainstorming step. Also, upon further review of the Search Request class and its subclasses, it was decided that the subclasses were really nothing more than a set of operations of the Search Request class. This was an example of process decomposition creeping into the modeling process. From an object-oriented perspective, we must always be careful to not allow this to occur. However, during the previous steps in the modeling process, Alec wanted to include as much information as possible in the model. He felt that it was more beneficial to remove this type of information after it had crept into the model than to take a chance on not capturing the information required to solve the problem. Step 6: Incorporate Patterns The sixth step was to incorporate any useful pattern into the structural model. One pattern that could be useful is the Contract pattern listed in Figure 6-13. By reviewing this pattern (see Figure 6-12), Alec and his team uncovered two subclasses of the Customer class: Individual and Organizational. Furthermore, Peter Coad has identified twelve transaction patterns that also could be useful for Alec and his team to investigate further.14 Applying the Concepts at CD Selections 231 14 See Peter Coad, David North, and Mark Mayfield, Object Models: Strategies, Patterns, and Applications, 2nd ed. (Englewood Cliffs, NJ: Prentice Hall, 1997). Step 7: Review the Model The seventh and final step is to carefully review the structural model. Figure 6-18 shows the Places Order use-case view of the structural model as portrayed in a class diagram developed by Alec and his team. This version of the class diagram incorporates all the modifications described previously. 232 Chapter 6 Structural Modeling In Your Turn 5-8, you completed the detailed use cases for the CD Selections Internet Sales System. Using these detailed use cases, complete the structural model (CRC cards and class diagram) for the remaining use cases in Figure 5-18. 6-4 CD Selections Internet Sales SystemYOUR TURN Credit-Card Clearance Center Customer Search Req CD List Order Order Item CD Vendor Review Artist Info Sample Clip Mkt Info * * * * checks distributes classifies *1 places makes uses consists of results in * * * * * 1 * 0..* 1..* 0..* 0..* 1 1 0..1 includes 1* contains 0..*1 1 1promotes 1 * Title Search Artist Search Category Search CD Categories Rock Jazz Classical FIGURE 6-17 Preliminary CD Selections Internet Sales System Class Diagrams (Places Order Use-Case View) SUMMARY Structural Models Structural models describe the underlying data structure of an object-oriented system. Whereas use-case models provide an external functional view of the evolving system (i.e., what the system does), structural models provide an internal static view of the evolving sys- tem (i.e., how the objects are organized in the system). At this point in the development of the system, the structural model represents only a logical model of the underlying problem domain. One of the primary purposes of the structural model is to create a vocabulary that allows the users and developers to communicate effectively about the problem under inves- tigation. Structural models comprise classes, attributes, operations, and relationships. There are three basic types of relationships that normally are depicted on structural models: aggre- gation, generalization, and association. Structural models typically are represented by CRC cards, class diagrams, and, in some cases, object diagrams. CRC Cards CRC cards model the classes, their responsibilities, and their collaborations. There are two different types of responsibilities: knowing and doing. Knowing responsibilities are associ- ated mostly with attributes of instances of the class, whereas doing responsibilities are asso- ciated mostly with operations of instances of the class. Collaborations support the concepts of clients, servers, and contracts between objects. CRC cards capture all the essential elements of the instances of a class. The front of the card allows the recording of the class’s name, ID, type, description, list of associated use cases, responsibilities, and collaborators, whereas the back of the card contains the attributes and relationships. Class Diagrams A class diagram is a graphical description of the information contained on the CRC cards. It shows the classes and the relationships between the classes. The class diagram portrays Summary 233 Credit-Card Clearance Center Customer Search Req CD List Order Order Item CD Vendor Review Artist Info Sample Clip Mkt Info * * checks distributes ** * places makes results in consists of * * * * * * 1 0..1 includes ** * * contains ** 1 1 1 promotes * * Individual Organizational FIGURE 6-18 CD Selections Internet Sales System Class Diagram (Places Order Use-Case View) additional information, not included on the CRC cards: the visibility of the attributes and operations and the multiplicity of the relationships. Also, there are times that a relationship itself contains information. In this case, an associated class is created. There are special arcs for each of the relationships (aggregation, generalization, and association) contained in the diagram. In real-world systems that can have over 100 classes, the class diagram can become overly complicated. To allow for the simplification of the diagram, a view mechanism can be used. A view restricts the amount of information portrayed on the diagram. Some use- ful views are: hiding all information about the class except for its name and relationships; showing only the classes that are associated with a particular use case; and limiting the rela- tionships included to only one specific type (aggregation, generalization, and association). When attempting to uncover additional information about the details of a class, it is use- ful to portray specific instances of a class instead of the classes themselves. An object diagram is used to depict a set of objects that represent an instantiation of all or part of a class diagram. Creating CRC Cards and Class Diagrams Creating a structural model is an iterative process. The process described is a seven-step process. The steps include textual analysis of use cases, brainstorming additional objects using common object lists, role-playing each use case using the CRC cards, creating class diagrams, and incorporating useful patterns. 234 Chapter 6 Structural Modeling KEY TERMS A-kind-of A-part-of Abstract class Aggregation association Assemblies Association Association class Attribute Class Class diagram Client Collaboration Common object list Conceptual model Concrete class Constructor operation Contract Class-Responsibility- Collaboration (CRC) CRC cards Decomposition Derived attribute Doing responsibility Generalization association Has-parts Incidents Instance Interactions Knowing responsibility Method Multiplicity Object Object diagram Operation Package Parts Pattern Private Protected Public Query operation Responsibility Roles Server Static model Static structure diagram Structural model Subclass Substitutability Superclass SVDPI Tangible things Textual analysis UML Update operation View Visibility Wholes 1. Describe to a businessperson the multiplicity of a rela- tionship between two classes. 2. Why are assumptions important to a structural model? 3. What is an association class? 4. Contrast the following sets of terms: object; class; instance QUESTIONS Exercises 235 property; method; attribute superclass; subclass concrete class; abstract class 5. Give three examples of derived attributes that may exist on a class diagram. How would they be denoted on the class diagram? 6. What are the different types of visibility? How would they be denoted on a class diagram? 7. Draw the relationships that are described by the fol- lowing business rules. Include the multiplicities for each relationship. A patient must be assigned to only one doctor and a doctor can have one or many patients. An employee has one phone extension, and a unique phone extension is assigned to an employee. A movie theater shows at least one movie, and a movie can be shown at up to four other movie theaters around town. A movie either has one star, two costars, or more than ten people starring together. A star must be in at least one movie. 8. How do you designate the reading direction of a rela- tionship on a class diagram? 9. For what is an association class used in a class dia- gram? Give an example of an association class that may be found in a class diagram that captures students and the courses that they have taken. 10. Give two examples of aggregation, generalization, and association relationships. How is each type of associa- tion depicted on a class diagram? 11. Identify the following operations as constructor, query, or update. Which operations would not need to be shown in the class rectangle? Calculate employee raise (raise percent) Calculate sick days () Increment number of employee vacation days () Locate employee name () Place request for vacation (vacation day) Find employee address () Insert employee () Change employee address () Insert spouse () EXERCISES A. Draw class diagrams for the following classes: Movie (title, producer, length, director, genre) Ticket (price, adult or child, showtime, movie) Patron (name, adult or child, age) B. Create an object diagram based on the class diagram you drew for exercise A. C. Draw a class diagram for the following classes. Con- sider that the entities represent a system for a patient billing system. Include only the attributes that would be appropriate for this context. Patient (age, name, hobbies, blood type, occupation, insurance carrier, address, phone) Insurance carrier (name, number of patients on plan, address, contact name, phone) Doctor (specialty, provider identification number, golf handicap, age, phone, name) D. Create an object diagram based on the class diagram you drew for exercise C. E. Draw the following relationships: 1. A patient must be assigned to only one doctor and a doctor can have many patients. 2. An employee has one phone extension, and a unique phone extension is assigned to an employee. 3. A movie theater shows many different movies, and the same movie can be shown at different movie theaters around town. F. Draw a class diagram for each of the following situations: 1. Whenever new patients are seen for the first time, they complete a patient information form that asks their name, address, phone number and insurance carrier, which are stored in the patient information file. Patients can be signed up with only one carrier, but they must be signed up to be seen by the doctor. Each time a patient visits the doctor, an insurance claim is sent to the carrier for payment. The claim must contain information about the visit, such as the date, purpose, and cost. It would be possible for a patient to submit two claims on the same day. 2. The state of Georgia is interested in designing a system that will track its researchers. Information of interest includes: researcher name, title, posi- tion; university name, location, enrollment; and research interests. Researchers are associated with one institution, and each researcher has several research interests. 236 Chapter 6 Structural Modeling 3. A department store has a bridal registry. This reg- istry keeps information about the customer (usually the bride), the products that the store carries, and the products each customer registers for. Customers typically register for a large number of products and many customers register for the same products. 4. Jim Smith’s dealership sells Fords, Hondas, and Toyotas. The dealership keeps information about each car manufacturer with whom they deal so that they can get in touch with them easily. The dealership also keeps information about the models of cars that they carry from each manufacturer. They keep infor- mation such as list price, the price the dealership paid to obtain the model, and the model name and series (e.g., Honda Civic LX). They also keep information about all sales that they have made (for instance, they will record the buyer’s name, the car they bought, and the amount they paid for the car). In order to contact the buyers in the future, contact information is also kept (e.g., address, phone number). G. Create object diagrams based on the class diagrams you drew for exercise F. H. Examine the class diagrams that you created for exer- cise F. How would the models change (if at all) based on these new assumptions? 1. Two patients have the same first and last names. 2. Researchers can be associated with more than one institution. 3. The store would like to keep track of purchase items. 4. Many buyers have purchased multiple cars from Jim over time because he is such a good dealer. I. Visit a Web site that allows customers to order a prod- uct over the Web (e.g., Amazon.com). Create a struc- tural model (CRC cards and class diagram) that the site must need to support its business process. Include classes to show what they need information about. Be sure to include the attributes and operations to repre- sent the type of information they use and create. Finally, draw relationships, making assumptions about how the classes are related. J. Create a structural model (CRC cards and class diagram) for Exercise C in Chapter 5. K. Create a structural model for exercise E in Chapter 5. L. Create a structural model for exercise H in Chapter 5. M. Create a structural model for exercise J in Chapter 5. N. Create a structural model for exercise L in Chapter 5. O. Create a structural model for exercise N in Chapter 5. P. Create a structural model for exercise P in Chapter 5. Q. Create a structural model for exercise R in Chapter 5. R. Create a structural model for exercise T in Chapter 5. MINICASES 1. West Star Marinas is a chain of twelve marinas that offer lakeside service to boaters, service and repair of boats, motors, and marine equipment, and sales of boats, motors, and other marine accessories. The sys- tems development project team at West Star Marinas has been hard at work on a project that eventually will link all the marina’s facilities into one unified, networked system. The project team has developed a use-case diagram of the current system. This model has been carefully checked. Last week, the team invited a number of system users to role-play the various use cases, and the use cases were refined to the users’ satisfaction. Right now, the project manager feels confident that the as-is system has been adequately represented in the use-case diagram. The director of operations for West Star is the spon- sor of this project. He sat in on the role-playing of the use cases and was very pleased by the thorough job the team had done in developing the model. He made it clear to you, the project manager, that he was anxious to see your team begin work on the use cases for the to-be system. He was a little skeptical that it was nec- essary for your team to spend any time modeling the current system in the first place but grudgingly admit- ted that the team really seemed to understand the business after going through that work. The methodology you are following, however, spec- ifies that the team should now turn its attention to developing the structural models for the as-is system. When you stated this to the project sponsor, he seemed confused and a little irritated. “You are going to spend even more time looking at the current sys- tem? I thought you were done with that! Why is this necessary? I want to see some progress on the way things will work in the future!” What is your response to the director of operations? Why do we perform structural modeling? Is there any benefit to developing a structural model of the current system at all? How do the use cases and use-case diagram help us develop the structural model? 2. Holiday Travel Vehicles sells new recreational vehicles and travel trailers. When new vehicles arrive at Holiday Minicases 237 Travel Vehicles,a new vehicle record is created. Included in the new vehicle record are a vehicle serial number, name, model, year, manufacturer, and base cost. When a customer arrives at Holiday Travel Vehicles, he or she works with a salesperson to negotiate a vehicle purchase. When a purchase has been agreed upon, a sales invoice is completed by the salesperson. The invoice summarizes the purchase, including full customer infor- mation, information on the trade-in vehicle (if any), the trade-in allowance, and information on the purchased vehicle. If the customer requests dealer-installed options, they are listed on the invoice as well. The invoice also summarizes the final negotiated price, plus any applica- ble taxes and license fees. The transaction concludes with a customer signature on the sales invoice. a. Identify the classes described in the preceding sce- nario (you should find six). Create CRC cards for each class. Customers are assigned a customer ID when they make their first purchase from Holiday Travel Vehicles. Name, address, and phone number are recorded for the customer. The trade-in vehicle is described by a serial number, make, model, and year. Dealer-installed options are described by an option code, description, and price. b. Develop a list of attributes for each class. Place the attributes onto the CRC cards. Each invoice lists just one customer. A person does not become a customer until he or she purchases a vehicle. Over time, a customer may purchase a number of vehicles from Holiday Travel Vehicles. Every invoice must be filled out by only one sales- person. A new salesperson may not have sold any vehi- cles, but experienced salespeople have probably sold many vehicles. Each invoice only lists one new vehicle. If a new vehicle in inventory has not been sold, there will be no invoice for it. Once the vehicle sells, there will be just one invoice for it. A customer may decide to have no options added to the vehicle or may choose to add many options. An option may be listed on no invoices, or it may be listed on many invoices. A customer may trade in no more than one vehicle on a purchase of a new vehicle. The trade-in vehicle may be sold to another customer, who later trades it in on another Holiday Travel vehicle. c. Based on the preceding business rules in force at Holiday Travel Vehicles and CRC cards, draw a class diagram and document the relationships with the appropriate multiplicities. Remember to update the CRC cards. 238 Behavioral models describe the internal dynamic aspects of an information system that supports the business processes in an organization. During analysis, behavioral models describe what the internal logic of the processes is without specifying how the processes are to be implemented. Later, in the design and implementation phases, the detailed design of the operations contained in the object is fully specified. In this chapter, we describe three UML 2.0 diagrams that are used in behavioral modeling: sequence diagrams, communication diagrams, and behavioral state machines. OBJECTIVES ■ Understand the rules and style guidelines for sequence and communication diagrams and behavioral state machines. ■ Understand the processes used to create sequence and communication diagrams and behavioral state machines. ■ Be able to create sequence and communication diagrams and behavioral state machines. ■ Understand the relationship between the behavioral models and the structural and functional models. CHAPTER OUTLINE CHAPTER 7 Behavioral Modeling Introduction Behavioral Models Interaction Diagrams Objects, Operations, and Messages Sequence Diagrams Communication Diagrams Behavioral State Machines States, Events, Transitions, Actions, and Activities Elements of a Behavioral State Machine Building Behavioral State Machines CRUD Analysis Applying the Concepts at CD Selections Sequence Diagrams Communication Diagrams Behavioral State Machines CRUD Analysis Summary INTRODUCTION The previous two chapters discussed functional models and structural models. Systems analysts utilize functional models to describe the external behavioral view of an information system, whereas they use structural models to depict the static view of an information system. In this chapter, we discuss how analysts use behavioral models to represent the internal behav- ior or dynamic view of an information system. There are two types of behavioral models. First, there are behavioral models used to represent the underlying details of a business process portrayed by a use-case model. In Interaction Diagrams 239 UML, interaction diagrams (sequence and communication) are used for this type of behav- ioral model. Second, there is a behavioral model that is used to represent the changes that occur in the underlying data. UML uses behavioral state machines for this. During analysis, analysts use behavioral models to capture a basic understanding of the dynamic aspects of the underlying business process. Traditionally, behavioral models have been used primarily during design, where analysts refine the behavioral models to include implementation details (see Chapter 8). For now, our focus is on what the dynamic view of the evolving system is and not on how the dynamic aspect of the system will be implemented. In this chapter, we concentrate on creating behavioral models of the underlying busi- ness process. Using the interaction diagrams (sequence and communication diagrams) and behavioral state machines, it is possible to give a complete view of the dynamic aspects of the evolving business information system. We first describe behavioral models and their components. We then describe each of the diagrams, how they are created, and how they are related to the functional and structural models described in Chapters 5 and 6. BEHAVIORAL MODELS When an analyst is attempting to understand the underlying application domain of a prob- lem, he or she must consider both structural and behavioral aspects of the problem. Unlike other approaches to the development of information systems, object-oriented approaches attempt to view the underlying application domain in a holistic manner. By viewing the problem domain as a set of use cases that are supported by a set of collaborating objects, object-oriented approaches allow an analyst to minimize the semantic gap between the real-world set of objects and the evolving object-oriented model of the problem domain. However, as we pointed out in the previous chapter, the real world tends to be messy, which makes perfectly modeling the application domain practically impossible in software. This is because software must be neat and logical to work. One of the primary purposes of behavioral models is to show how the underlying objects in a problem domain will work together to form a collaboration to support each of the use cases. Whereas structural models represent the objects and the relationships between them, behavioral models depict the internal view of the business process that a use case describes. The process can be shown by the interaction that takes place between the objects that collaborate to support a use case through the use of interaction (sequence and communication) diagrams. It is also possible to show the effect that the set of use cases that make up the system has on the objects in the system through the use of behavioral state machines. Creating behavioral models is an iterative process that iterates not only over the indi- vidual behavioral models [e.g., interaction (sequence and communication) diagrams and behavioral state machines] but also over the functional (see Chapter 5) and structural models (see Chapter 6). As the behavioral models are created, it is not unusual to make changes to the functional and structural models. In the next three sections, we describe interaction diagrams and behavioral state machines and when to use each. INTERACTION DIAGRAMS One of the primary differences between class diagrams and interaction diagrams, besides the obvious difference that one describes structure and the other behavior, is that the mod- eling focus on a class diagram is at the class level, whereas the interaction diagrams focus on the object level. In this section we review objects, operations, and messages and we cover the two different diagrams (sequence and communication) that can be used to model the interactions that take place between the objects in an information system. Objects, Operations, and Messages An object is an instantiation of a class, that is, an actual person, place, event, or thing about which we want to capture information. If we were building an appointment system for a doctor’s office, classes might include doctor, patient, and appointment. The specific patients, such as Jim Maloney, Mary Wilson, and Theresa Marks, are considered objects— that is, instances of the patient class. Each object has attributes that describe information about the object, such as a patient’s name, birth date, address, and phone number. Each object also has behaviors. At this point in the development of the evolving system, the behaviors are described by operations. An operation is nothing more than an action that an object can perform. For example, an appointment object can probably schedule a new appointment, delete an appointment, and locate the next available appointment. Later on during the development of the evolving sys- tem, the behaviors will be implemented as methods. Each object also can send and receive messages. Messages are information sent to objects to tell an object to execute one of its behaviors. Essentially, a message is a function or procedure call from one object to another object. For example, if a patient is new to the doctor’s office, the system will send an insert message to the application. The patient object will receive the instruction (the message) and do what it needs to do to go about inserting the new patient into the system (the behavior). Sequence Diagrams Sequence diagrams are one of two types of interaction diagrams. They illustrate the objects that participate in a use case and the messages that pass between them over time for one use case. A sequence diagram is a dynamic model that shows the explicit sequence of messages that are passed between objects in a defined interaction. Because sequence diagrams emphasize the time-based ordering of the activity that takes place among a set of objects, they are very helpful for understanding real-time specifications and complex use cases. The sequence diagram can be a generic sequence diagram that shows all possible sce- narios1 for a use case, but usually each analyst develops a set of instance sequence diagrams, each of which depicts a single scenario within the use case. If you are interested in under- standing the flow of control of a scenario by time, you should use a sequence diagram to depict this information. The diagrams are used throughout both the analysis and design phases. However, the design diagrams are very implementation specific, often including database objects or specific user interface components as the classes. Elements of a Sequence Diagram Figure 7-1 shows an instance sequence diagram that depicts the objects and messages for the Make Appointment use case, which describes the process by which a patient creates a new appointment or cancels or reschedules an appoint- ment for the doctor’s office appointment system. In this specific instance, the Make Appointment process is portrayed. 240 Chapter 7 Behavioral Modeling 1 Remember that a scenario is a single executable path through a use case. Actors and objects that participate in the sequence are placed across the top of the dia- gram using actor symbols from the use-case diagram and object symbols from the object diagram (see Figure 7-2). Notice that the actors and objects in Figure 7-1 are aPatient, aReceptionist, Patients, UnpaidBills, Appointments, and anAppt.2 They are not placed in any particular order, although it is nice to organize them in some logical way, such as the order in which they participate in the sequence. For each of the objects, the name of the class of which they are an instance is given after the object’s name (e.g., Patients: PatientsList means that Patients is an instance of the PatientsList class that contains indi- vidual patient objects). A dotted line runs vertically below each actor and object to denote the lifeline of the actors/objects over time (see Figure 7-1).3 Sometimes an object creates a temporary object; in this case an X is placed at the end of the lifeline at the point the object is destroyed (not shown). For example, think about a shopping cart object for a Web com- merce application. The shopping cart is used for temporarily capturing line items for an order, but once the order is confirmed, the shopping cart is no longer needed. In this case, an X would be located at the point at which the shopping cart object is destroyed. When objects continue to exist in the system after they are used in the sequence diagram, then the lifeline continues to the bottom of the diagram (this is the case with all of the objects in Figure 7-1). Interaction Diagrams 241 sd Make Appt Use Case RequestAppt(name, address) NewCancelChangeAppt?() ApptTimes?() aPatient LookUpPatient() aReceptionist Patients:PatientsList [aPatient Exists] LookupBills() MatchAppts() UnpaidBills:BillsList Appointments:ApptsList CreateAppt() anAppt:Appointment 2 In some versions of the sequence diagram, object symbols are used as surrogates for the actors. However, for purposes of clarity, we recommend using actor symbols for actors instead. 3 Technically speaking, in UML 2.0 the lifeline actually refers to both the object (actor) and the dashed line drawn vertically underneath the object (actor). However, we prefer to use the older terminology because it is more descriptive of what is actually being represented. FIGURE 7-1 Example Sequence Diagram 242 Chapter 7 Behavioral Modeling An actor: ■ Is a person or system that derives benefit from and is external to the system. ■ Participates in a sequence by sending and/or receiving messages. ■ Is placed across the top of the diagram. ■ Is depicted either as a stick figure (default) or, if a nonhuman actor is involved, as a rectangle with <> in it (alternative). An object: ■ Participates in a sequence by sending and/or receiving messages. ■ Is placed across the top of the diagram. A lifeline: ■ Denotes the life of an object during a sequence. ■ Contains an X at the point at which the class no longer interacts. An execution occurrence: ■ Is a long narrow rectangle placed atop a lifeline. ■ Denotes when an object is sending or receiving messages. A message: ■ Conveys information from one object to another one. ■ A operation call is labeled with the message being sent and a solid arrow, whereas a return is labeled with the value being returned and shown as a dashed arrow. A guard condition: ■ Represents a test that must be met for the message to be sent. anObject : aClass <> Actor/Role anActor aMessage() [aGuardCondition]: aMessage() Return Value For object destruction: ■ An X is placed at the end of an object’s lifeline to show that it is going out of existence. A frame: ■ Indicates the context of the sequence diagram. X Context Term and Definition Symbol FIGURE 7-2 Sequence Diagram Syntax A thin rectangular box, called the execution occurrence, is overlaid onto the lifeline to show when the classes are sending and receiving messages (see Figure 7-2). A message is a communication between objects that conveys information with the expectation that activ- ity will ensue. There are many different types of messages that can be portrayed on a sequence diagram. However, in the case of using sequence diagrams to model use cases, two types of messages are typically used: operation call and return. Operation call messages passed between classes are shown using solid lines connecting two objects with an arrow on the line showing which way the message is being passed. Argument values for the mes- sage are placed in parentheses next to the message’s name. The order of messages goes from the top to the bottom of the page, so messages located higher on the diagram represent messages that occur earlier on in the sequence, versus the lower messages that occur later. A return message is depicted as a dashed line with an arrow on the end of the line portraying the direction of the return. The information being returned is used to label the arrow. How- ever, because adding return messages tends to clutter the diagram, unless the return messages add a lot of information to the diagram, they can be omitted. For example, in Figure 7-1, no return messages are depicted.4 In Figure 7-1, ‘LookUpPatient()’ is a message sent from the actor aReceptionist to the object Patients, which is a container for the current patients to determine whether the aPatient actor is a current patient. At times a message is sent only if a condition is met. In those cases, the condition is placed between a set of brackets, [ ] {e.g., [aPatient Exists] LookupBills()}. The condition is placed in front of the message name. However, when using a sequence diagram to model a specific scenario, conditions are typically not shown on any single sequence diagram. Instead, conditions are implied only through the existence of different sequence diagrams. There are times that a message is repeated. This is designated with an asterisk (*) in front of the message name (e.g., * Request CD). An object can send a message to itself. This is known as self-delegation. Sometimes, an object will create another object. This is shown by the message being sent directly to an object instead of its lifeline. In Figure 7-1, the actor aReceptionist creates an object anAppt. Figure 7-3 portrays two additional examples of instance-specific sequence diagrams. The first one is related to the Make Lunch use case that was described in the activity dia- gram portrayed in Figure 5-4. The second one is related to the Place Order use case associ- ated with the activity diagram in Figure 5-3. In both examples, the diagrams simply represent a single scenario. Notice, in the Make Lunch sequence diagram there is a message being sent from an actor to itself [CreateSandwich()]. Depending on the complexity of the scenario being modeled, this particular message could have been eliminated. Obviously, both the process of making a lunch and placing an order can be quite a bit more complex. However, from a learning point of view, you should be able to see how the sequence dia- grams and the activity diagrams relate to one another. Building a Sequence Diagram In this section we describe a six-step process used to create a sequence diagram5 (see Figure 7-4). The first step in the process is to determine the context of the sequence diagram. The context of the diagram can be a system, a use case, or a scenario of a use case. The context of the diagram is depicted as a labeled frame around the diagram (see Figures 7-1, 7-2, and 7-3). Most commonly, it is one use- case scenario. Figure 7-1 portrays the instance-specific sequence diagram for the sce- nario from the Make Appointment use case given in Figure 5-5 for making a new appointment for an existing patient. For each possible scenario for the Make Appoint- ment use case, a separate instance-specific sequence diagram would be created. On the surface, this seems to be a lot of potentially redundant and useless work. However, at this Interaction Diagrams 243 4 However, some CASE tools require the return messages to be displayed. Obviously, when using these tools, you will have to include the return messages on the diagram. 5 The approach described in this section are adapted from Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide (Reading, MA: Addison-Wesley, 1999). point in the representation of a system, we are still trying to completely understand the problem. As such, this process of creating instance-specific sequence diagrams for each scenario instead of creating a single generic sequence diagram for the entire use case will enable the developers to attain a more complete understanding of the problem being addressed. Furthermore, each instance-specific sequence diagram is fairly simple to interpret, whereas a generic sequence diagram can be very complex. As such, the test- ing of a specific use case is accomplished in a much easier manner by validating and ver- ifying the completeness of the set of instance-specific sequence diagrams instead of trying to work through a single complex generic sequence diagram.6 244 Chapter 7 Behavioral Modeling sd Make Lunch Use Case sd Submit Order Use Case MakeLunch() Lunch aChild:Child firstParent:Parent secondParent:Parent aCustomer:Customer CreateLunch() Sandwich Lunch GetSandwich() CreateSandwich() SubmitOrderRequest() OrderRejected aCustomer:Customer aSalesPerson:SalesPerson SubmitCreditRequest() CreditDeniedFIGURE 7-3 Additional Sample Instance-Specific Sequence Diagrams 6 Additional discussion of testing is included in Chapter 13. We also discuss walkthroughs and inspections in Chapter 8. The second step is to identify the objects that participate in the sequence being modeled—that is, the objects that interact with each other during the use-case scenario. The objects are identified during the development of the structural model (see Chapter 6). These are the classes on which the objects of the sequence diagram for this scenario will be based. One very useful approach to identifying all of the scenarios associated with a use case is to role-play the CRC cards (see Chapter 6). This can help you identify potentially missing operations that are necessary to support the business process, which the use case is representing, in a complete manner. Also, during role playing, it is likely that new classes, and hence new objects, will be uncovered.7 Don’t worry too much about identifying all the objects perfectly; remember that the behavioral modeling process is iterative. Usually, the sequence diagrams are revised multiple times during the behavioral modeling processes. The third step is to set the lifeline for each object. To do this, you need to draw a vertical dotted line below each class to represent the class’s existence during the sequence. An X should be placed below the object at the point on the lifeline where the object goes out of existence. The fourth step is to add the messages to the diagram. This is done by drawing arrows to represent the messages being passed from object to object, with the arrow pointing in the message’s transmission direction. The arrows should be placed in order from the first message (at the top) to the last (at the bottom) to show time sequence. Any parameters passed along with the messages should be placed in parentheses next to the message’s name. If a message is expected to be returned as a response to a message, then the return message is not explicitly shown on the diagram. The fifth step is to place the execution occurrence on each object’s lifeline by drawing a narrow rectangle box over top of the lifelines to represent when the classes are sending and receiving messages. The sixth and final step is to validate the sequence diagram. The purpose of this step is to guarantee that the sequence diagram completely represents the underlying process. This is done by guaranteeing that the diagram depicts all the steps in the process.8 Interaction Diagrams 245 FIGURE 7-4 Steps for Building Sequence Diagrams 1. Set the context. 2. Identify which objects will participate. 3. Set the lifeline for each object. 4. Lay out the messages from the top to the bottom of the diagram based on the order in which they are sent. 5. Add the execution occurrence to each object‘s lifeline. 6. Validate the sequence diagram. 7 This obviously will cause you to go back and modify the structural model (see Chapter 6). 8 We describe validation in more detail in Chapter 8. In Your Turn 5-2, you were asked to create a set of use cases and a use-case diagram for the campus housing service that helps students find apartments. In Your Turn 6-2, you were asked to create a structural model (CRC cards and class diagram) for those use-cases. Select one of the use cases from the use-case diagram and create a set of instance- specific sequence diagrams that represents the interaction among classes in the different scenarios of the use case. 7-1 Drawing a Sequence DiagramYOUR TURN Communication Diagrams Communication diagrams, like sequence diagrams, essentially provide a view of the dynamic aspects of an object-oriented system. As such, they can show how the members of a set of objects collaborate to implement a use case or a use-case scenario. Further- more, they can be used to model all the interactions among a set of collaborating objects, i.e., a collaboration (see CRC cards in Chapter 6). In this case, a communication diagram can portray how dependent the different objects are on one another.9 A communication diagram is essentially an object diagram that shows message-passing relationships instead of aggregation or generalization associations. Communication diagrams are very useful to show process patterns (i.e., patterns of activity that occur over a set of collabo- rating classes). Communication diagrams are equivalent to sequence diagrams, but they emphasize the flow of messages through a set of objects, whereas the sequence diagrams focus on the time ordering of the messages being passed. Therefore, to understand the flow of control over a set of collaborating objects or to understand which objects collaborate to support business processes, a communication diagram can be used. For time ordering the messages, a sequence diagram should be used. In some cases, both can be used to more fully under- stand the dynamic activity of the system. Elements of a Communication Diagram Figure 7-5 shows a communication diagram for the Make Appointment use case. Like the sequence diagram in Figure 7-1, the Create Appointment process is portrayed. 246 Chapter 7 Behavioral Modeling 9 We return to this idea of dependency in Chapters 8 and 9. sd Make Appt Use Case aPatient 1: RequestAppt(name, address) 4: NewCancelChangeAppt?() 5: ApptTimes?() aReceptionist 2: LookUpPatie nt() 3: [aPatient Exists] LookupBills() 6: MatchAppts() 7: CreateAppt() Appointments:ApptsList anAppt:Appointment UnpaidBills:BillsList Patients:PatientsList FIGURE 7-5 Sample Communication Diagram Actors and objects that collaborate to execute the use case are placed on the commu- nication diagram in a manner to emphasize the message passing that takes place between them. Notice that the actors and objects in Figure 7-5 are the same ones in Figure 7-1: aPatient, aReceptionist, Patients, UnpaidBills, Appointments, and anAppt.10 Again, as with the sequence diagram, for each of the objects, the name of the class of which they are an instance is given after the object’s name (e.g., Patients: PatientsList). (The communication diagram syntax is given in Figure 7-6.) Unlike the sequence diagram, the communication diagram does not have a means to explicitly show an object being deleted or created. It is assumed that when a delete, destroy, or remove message is sent to an object, it will go out of existence, and a create or new message will cause a new object to come into existence. Interaction Diagrams 247 10 In some versions of the communication diagram, object symbols are used as surrogates for the actors. How- ever, again we recommend using actor symbols for actors instead. An actor: ■ Is a person or system that derives benefit from and is external to the system. ■ Participates in a collaboration by sending and/or receiving messages. An object: ■ Participates in a collaboration by sending and/or receiving messages. ■ Is placed across the top of the diagram. An association: ■ Shows an association between actors and/or objects. ■ Is used to send messages. A message: ■ Conveys information from one object to another one. ■ Has direction shown using an arrowhead. ■ Has sequence shown by a sequence number. A frame: ■ Indicates the context of the communication diagram. A guard condition: ■ Represents a test that must be met for the message to be sent. <> Actor/Role anActor Context SeqNumber: aMessage SeqNumber: [aGuardCondition]: aMessage Term and Definition Symbol ■ Is depicted either as a stick figure (default) or, if a nonhuman actor is involved, as a rectangle with <> in it (alternative). anObject:aClass FIGURE 7-6 Communication Diagram Syntax Another difference between the two interaction diagrams is that the communication dia- gram never shows returns from message sends, whereas the sequence diagram can option- ally show them. An association is shown between actors and objects with an undirected line. For example, there is an association shown between the aPatient and aReceptionist actors. Messages are shown as labels on the associations. Included with the labels are lines with arrows showing the direction of the message being sent. For example, in Figure 7-5, the aPatient actor sends the RequestAppt() message to the aReceptionist actor, and the aReceptionist actor, sends the NewCancelChangeAppt?() and the ApptTimes?() mes- sages to the aPatient actor. The sequence of the message sends is designated with a sequence number. In Figure 7-5, the RequestAppt() message is the first message sent, whereas the NewCancelChangeAppt?() and the ApptTimes?() messages are the fourth and fifth message sent, respectively. Like the sequence diagram, the communication diagram can represent conditional messages. For example, in Figure 7-5, the LookupBills() message is sent only if the [aPatient exists] condition is met. If a message is repeatedly sent, an asterisk is placed after the sequence number. Finally, an association that loops onto an object shows self-delegation. The message is shown as the label of the association. When a communication diagram is fully populated with all the objects, it can become very complex and difficult to understand. When this occurs, it is necessary to simplify the diagram. One approach to simplifying a communication diagram, like use-case diagrams (see Chapter 5) and class diagrams (see Chapter 6), is through the use of packages (i.e., log- ical groups of classes). In the case of communication diagrams, its objects are grouped together based on the messages sent to and received from the other objects.11 Figure 7-7 provides two additional examples of communication diagrams. These dia- grams are equivalent to the sequence diagrams contained in Figure 7-3. However, when comparing the communication diagrams to the sequence diagrams in these figures, you see that there is quite a bit of information lost. For example, the CreateSandwich() message is nowhere to be found. However, the primary purpose of the communication diagram is to show how the different actors and classes interact, and this is exactly the information that is included. 248 Chapter 7 Behavioral Modeling 11 For those familiar with structured analysis and design, packages serve a similar purpose as the leveling and balancing processes used in data flow diagramming. Packages and package diagrams are described in Chapter 8. sd Make Lunch Use Case CreateLunch() GetSandwich()MakeLunch() aChild:Child firstParent:Parent secondParent:Parent sd Submit Order Use Case aCustomer:CustomerSubmitOrderRequest() SubmitCreditRequest() aCustomer:Customer aSalesPerson:SalesPerson FIGURE 7-7 Additional Sample Communication Diagrams Building a Communication Diagram12 Remember that a communication diagram is basically an object diagram that shows message-passing relationships instead of aggregation or generalization associations. In this section, we describe a five-step process used to build a com- munication diagram (see Figure 7-8). The first step in the process is to determine the context of the communication diagram. Like a sequence diagram, the context of the diagram can be a system, a use case, or a scenario of a use case. The context of the diagram is depicted as a labeled frame around the diagram (see Figures 7-5, 7-6, and 7-7). The second step is to identify the objects (actors) and the associations that link the objects (actors) that participate in the collaboration together. Remember, the objects that par- ticipate in the collaboration are instances of the classes identified during the development of the structural model (see Chapter 6). Like the sequence-diagramming process, it is likely that additional objects, and hence classes, will be discovered. Again, this is normal because the underlying development process is iterative and incremental. As such, in addition to the com- munication diagram being modified, the sequence diagrams and structural model will prob- ably also have to be modified. Furthermore, additional functional requirements may also be uncovered, hence requiring the functional models to be modified as well (see Chapter 5). The third step is to lay out the objects (actors) and their associations on the commu- nication diagram by placing them together based on the associations that they have with the other objects in the collaboration. By focusing on the associations between the objects (actors) and minimizing the number of associations that cross over one another, we can increase the understandability of the diagram. The fourth step is to add the messages to the associations between the objects. We do this by adding the name of the message(s) to the association link between the objects and an arrow showing the direction of the message being sent. Furthermore, each message has a sequence number associated with it to portray the time-based ordering of the message.13 The fifth and final step is to validate the communication diagram. The purpose of this step is to guarantee that the communication diagram faithfully portrays the underlying process(es). This is done by ensuring that all steps in the process are depicted on the diagram.14 Interaction Diagrams 249 12 The approach described in this section is adapted from Booch, Rumbaugh, and Jacobson, The Unified Modeling Language User Guide. 13 However, remember the sequence diagram portrays the time-based ordering of the messages in a top-down manner. As such, if your focus is on the time-based ordering of the messages, we recommend that you also use the sequence diagram. 14 We describe validation in Chapter 8. 1. Set the context. 2. Identify which objects (actors) and the associations between the objects participate in the collaboration. 3. Lay out the communication diagram. 4. Add messages. 5. Validate the communication diagram. FIGURE 7-8 Steps for Building Communication Diagrams In Your Turn 7-1 you were asked to create a set of instance specific sequence diagrams for a use case of the campus housing service. Draw a communication diagram for the same situation. 7-2 Drawing a Communication DiagramYOUR TURN BEHAVIORAL STATE MACHINES Some of the classes in the class diagrams represent a set of objects that are quite dynamic in that they pass through a variety of states over the course of their existence. For exam- ple, a patient can change over time from being ‘new’ to ‘current,’to ‘former,’and so on, based on his or her status with the doctor’s office. A behavioral state machine is a dynamic model that shows the different states through which a single object passes during its life in response to events, along with its responses and actions. Typically, behavioral state machines are not used for all objects, but just to further define complex objects to help simplify the design of algorithms for their methods. The behavioral state machine shows the different states of the object and what events cause the object to change from one state to another. In comparison to the interaction diagrams, behavioral state machines should be used to help understand the dynamic aspects of a single class and how its instances evolve over time15 and not with seeing how a particular use case or use-case scenario is executed over a set of classes. In this section, we describe states, events, transitions, actions, and activities and the use of the behavioral state machine to model the state changes through which complex objects pass. As in the creation of the interaction diagrams, when we create a behavioral state machine for an object, it is possible that we will uncover additional events that need to be included in your functional model (see Chapter 5), additional operations that need to be included in the structural model (see Chapter 6), so possibly our interaction diagrams may have to be modified again. Once more, because object-oriented development is iterative and incremental, this continuous modification of the evolving models (functional, struc- tural, and behavioral) of the system is to be expected. States, Events, Transitions, Actions, and Activities The state of an object is defined by the value of its attributes and its relationships with other objects at a particular point in time. For example, a patient might have a state of new, cur- rent, or former. The attributes or properties of an object affect the state that it is in; how- ever, not all attributes or attribute changes will make a difference. For example, think about a patient’s address. Those attributes make very little difference as to changes in a patient’s state. However, if states were based on a patient’s geographic location (e.g., in-town patients were treated differently than out-of-town patients), changes to the patient’s address would influence state changes. An event is something that takes place at a certain point in time and changes a value or values that describe an object, which, in turn, changes the object’s state. It can be a des- ignated condition becoming true, the receipt of the call for a method by an object, or the passage of a designated period of time. The state of the object determines exactly what the response will be. A transition is a relationship that represents the movement of an object from one state to another state. Some transitions have a guard condition. A guard condition is a Boolean expression that includes attribute values, which allows a transition to occur only if the con- dition is true. An object typically moves from one state to another based on the outcome of an action triggered by an event. An action is an atomic, nondecomposable process that cannot be interrupted. From a practical perspective, actions take zero time, and they are associated with a transition. In contrast, an activity is a nonatomic, decomposable process that can be interrupted. Activities take a long period of time to complete, they can be started and stopped by an action, and they are associated with states. 250 Chapter 7 Behavioral Modeling 15 Some authors refer to this as modeling an object’s life cycle. Elements of a Behavioral State Machine Figure 7-9 presents an example of a behavioral state machine representing the patient class in the context of a hospital environment. From this diagram we can tell that a patient enters a hospital and is admitted after checking in. If a doctor finds the patient to be healthy, he or she is released and is no longer considered a patient after two weeks elapses. If a patient is found to be unhealthy, he or she remains under observation until the diag- nosis changes. A state is a set of values that describes an object at a specific point in time, and it rep- resents a point in an object’s life in which it satisfies some condition, performs some action, or waits for something to happen (see Figure 7-10). In Figure 7-9 states include entering, admitted, released, and under observation. A state is depicted by a state symbol, which is a rectangle with rounded corners with a descriptive label that communicates a particular state. There are two exceptions. An initial state is shown using a small, filled-in circle, and an object’s final state is shown as a circle surrounding a small, filled-in circle. These excep- tions depict when an object begins and ceases to exist, respectively. Arrows are used to connect the state symbols, representing the transitions between states. Each arrow is labeled with the appropriate event name and any parameters or con- ditions that may apply. For example, the two transitions from admitted to released and under observation contain guard conditions. As in the other behavioral diagrams, in many cases it is useful to explicitly show the context of the behavioral state machine using a frame. Figure 7-11 depicts two additional behavioral state machines. The first one is for the lunch object that was associated with the Make Lunch use-case scenario of Figures 7-3 and 7-7. In this case, there is obviously additional information that has been cap- tured about the lunch object. For example, the scenario of Figures 7-3 and 7-7 did not include information regarding the lunch being taken out of the box or being eaten. This implies additional use cases and/or use-case scenarios that would have to be included in a system that dealt with lunch processing. The second behavioral state machine deals with the life cycle of an order. The order object is associated with the submit order use- case scenario described in Figures 7-3 and 7-7. As in the lunch example, there is quite a bit of additional information contained in this behavioral state machine. As such, for an order-processing system, quite a few additional sequence and communication diagrams Behavioral State Machines 251 Patient Enters Hospital Checks In [Diagnosis = Healthy] [> 2 weeks] Entering Admitted Released Under Observation [Diagnosis = Unhealthy] [Diagnosis = Healthy] FIGURE 7-9 Sample Behavioral State Machine Diagram would be necessary to completely represent all the processing associated with an order object. Obviously, because behavioral state machines can uncover additional processing requirements, they can be very useful in filling out the complete description of an evolv- ing system. Sometimes, states and subclasses can be confused. For example, in Figure 7-12, are the classes Freshman, Sophomore, Junior, and Senior subclasses of the class Undergraduate or are they simply states that an instance of the Undergraduate class goes through during its lifetime? In this case, the latter is the better answer. When trying to identify all potential classes when the structural model is created (see Chapter 6), you may actually identify states of the relevant superclass instead of subclasses. This is another example of how tightly inter- twined the functional, structural, and behavioral models can be. From a modeling perspec- tive, even though we had to remove the Freshman, Sophomore, Junior, and Senior subclasses from the structural model, it was better to capture that information as part of the structural model and remove it when we were creating the behavioral models than to omit it and take the chance of missing a crucial piece of information about the problem domain. Remember, 252 Chapter 7 Behavioral Modeling A state: ■ Is shown as a rectangle with rounded corners. ■ Has a name that represents the state of an object. An initial state: ■ Is shown as a small, filled-in circle. ■ Represents the point at which an object begins to exist. A final state: ■ Is shown as a circle surrounding a small, filled-in circle (bull's-eye). ■ Represents the completion of activity. An event: ■ Is a noteworthy occurrence that triggers a change in state. ■ Can be a designated condition becoming true, the receipt of an explicit signal from one object to another, or the passage of a designated period of time. ■ Is used to label a transition. A transition: ■ Indicates that an object in the first state will enter the second state. ■ Is triggered by the occurrence of the event labeling the transition. ■ Is shown as a solid arrow from one state to another, labeled by the event name. A frame: ■ Indicates the context of the behavioral state machine. Context anEvent aState Term and Definition Symbol FIGURE 7-10 Behavioral State Machine Diagram Syntax Order Denied Order is created Customer submits order Customer edits order information Authorization = Denied Order sent for credit authorization Customer withdraws order request Order sent to customer Customer accepts shipment Received Authorization = Approved Order is closed Lunch [Created] [PlacedInBox] [TakenOutOfBox] [Eaten] Created Packed Being Eaten In Process Ordered Processing Placed Shipped FIGURE 7-11 Additional Sample: Behavioral State Machine Diagrams 253 object-oriented development is iterative and incremental. As such, as we progress to a “cor- rect” model of the problem domain, we will make many mistakes. Building a Behavioral State Machine Behavioral state machines are drawn to depict a single class from a class diagram. Typically, the classes are very dynamic and complex, requiring a good understanding of their states over time and events triggering changes. You should examine your class diagram to identify which classes will need to undergo a complex series of state changes and draw a diagram for 254 Chapter 7 Behavioral Modeling Graduate Student DoctoralMasters Freshman VS. & [Accepted] SophomoreFreshman Undergraduate Undergraduate SeniorJunior DoctoralMasters Graduate Student Sophomore [>30 Hours Earned] Junior [>60 Hours Earned] Senior [>90 Hours Earned] [Graduate] FIGURE 7-12 States versus Subclasses each of them. In this section, we describe a five-step process used to build a behavioral state machine (see Figure 7-13).16 Like the other behavioral models, the first step in the process is to determine the context of the behavioral state machine, which is shown in the label of the frame of the diagram. The context of a behavioral state machine is usually a class. How- ever, it also could be a set of classes, a subsystem, or an entire system. The second step is to identify the various states that an object will have over its life- time. This includes establishing the boundaries of the existence of an object by identifying the initial and final states of an object. We also must identify the stable states of an object. The information necessary to perform this is gleaned from reading the use-case descrip- tions, talking with users, and relying on the requirements-gathering techniques that you learned about in Chapter 4. An easy way to identify the states of an object is to write the steps of what happens to an object over time, from start to finish, similar to how the nor- mal flow of events section of a use-case description would be created. The third step is to determine the sequence of the states that an object will pass through during its lifetime. Using this sequence, the states are placed onto the behavioral state machine in a left-to-right order. The fourth step is to identify the events, actions, and guard conditions associated with the transitions between the states of the object. The events are the triggers that cause an object to move from one state to the next state. In other words, an event causes an action to execute that changes the value(s) of an object’s attribute(s) in a significant manner. The actions are typically operations contained within the object. Also, guard conditions can model a set of test conditions that must be met for the transition to occur. At this point in the process, the transitions are drawn between the relevant states and labeled with the event, action, or guard condition. The fifth step is to validate the behavioral state machine by making sure that each state is reachable and that it is possible to leave all states except for final states. Obviously, if an iden- tified state is not reachable, either a transition is missing or the state was identified in error. Furthermore, only final states can be a dead end from the perspective of an object-life cycle.17 Behavioral State Machines 255 16 The approach described in this section is adapted from Booch, Rumbaugh, and Jacobson, The Unified Model- ing Language User Guide. 17 We describe validation in Chapter 8. 1. Set the context. 2. Identify the initial, final, and stable states of the object. 3. Determine the order in which the object will pass through the stable states. 4. Identify the events, actions, and guard conditions associated with the transitions. 5. Validate the behavioral state machine. FIGURE 7-13 Steps for Building a Behavioral State Machine You have been working with the system for the campus housing service that helps students find apartments. One of the dynamic classes in this system is probably the apartment class. Draw a behavioral state machine to show the various states that an apartment class transitions throughout its lifetime. Can you think of other classes that would make good candidates for a behavioral state machine? 7-3 Drawing a Behavioral State MachineYOUR TURN CRUD ANALYSIS One useful technique for identifying potential collaborations is CRUD analysis.18 CRUD analysis uses a CRUD matrix, in which each interaction among objects is labeled with a let- ter for the type of interaction: C for create, R for read or reference, U for update, and D for delete. In an object-oriented approach, a class/actor-by-class/actor matrix is used.19 Each cell in the matrix represents the interaction between instances of the classes. For example, in Figure 7-1, an instance of the Receptionist actor creates an instance of the Appointment class. As such, assuming a Row:Column ordering, a C is placed in the cell aReceptionist: Appointment. Also, in Figure 7-1, an instance of the Receptionist actor references an instance of the Appointments. In this case, an R is placed in the aReceptionist:Appoint- ments cell. Figure 7-14 shows the CRUD matrix based on the Make Appointment use case. Unlike the interaction diagrams and behavioral state machines, a CRUD matrix is most useful as a systemswide representation. Once a CRUD matrix is completed for the entire sys- tem, the matrix can be scanned quickly to ensure that each and every class can be instanti- ated. Furthermore, each type of interaction can be validated for each class. For example, if a class represents only temporary objects, then the column in the matrix should have a D in it somewhere. Otherwise, the instances of the class will never be deleted. Because a data warehouse contains historical data, objects that are to be stored in one should not have any U or D entries in their associated columns. As such, CRUD analysis can be used as a way to partially validate the interactions among the objects in an object-oriented system. Finally, the more interactions among a set of classes, the more likely they should be clustered together in a collaboration. However, the number and type of interactions are only an esti- mate at this point in the development of the system. As such, care should be taken when using this technique to cluster classes together to identify collaborations. CRUD analysis also can be used to identify complex objects. The more (C)reate, (U)pdate, or (D)elete entries in the column associated with a class, the more likely the instances of the class will have a complex life cycle. As such, these objects are candidates for state modeling with a behavioral state machine. 256 Chapter 7 Behavioral Modeling Receptionist RU CRUD R RU CRUD PatientList R Patient UnpaidBills Appointments R Appointment Receptionist PatientList Patient UnpaidBills Appointments Appointment FIGURE 7-14 CRUD Matrix for the Make Appointment Use Case 18 CRUD analysis has typically been associated with structured analysis and design [see Alan Dennis, Barbara Haley Wixom and Roberta M. Roth, Systems Analysis Design, 3nd ed. (New York: Wiley, 2006)] and information engineering [see James Martin, Information Engineering, Book II Planning and Analysis (Englewood Cliffs, NJ: Prentice Hall, 1990)]. In our case, we have simply adapted it to object-oriented systems development. Specific details on collaborations are described in Chapter 8. 19 Another useful but more detailed form of the CRUD matrix is a Class/Actor:Operation-by-Class/Actor:Operation matrix. For validation and verification purposes, this more detailed matrix is more useful. However, for our purposes at this point in our discussion, the Class/Actor-by-Class/Actor matrix is sufficient. APPLYING THE CONCEPTS AT CD SELECTIONS Because Alec and the team has now completed the functional and structural models for the Internet Sales System, he has decided that it was time to move on and begin to create the behavioral models. Alec understood that in some ways the behavioral models will allow them to complete their understanding of the problem that they are solving. As such, Alec and his team created sequence diagrams, communication diagrams, behavioral state machines, and a CRUD matrix. As in Chapter 6, the team created behavioral models for all the use cases and classes in the evolving system description. However, in the sections that follow, we see only the models associated with the Place Order use case and the Order class. The sections are organized in the same manner as the chapter: sequence diagrams, com- munication diagrams, behavioral state machine, and CRUD matrix. Sequence Diagrams To begin with Alec decided to follow the steps for building a sequence diagram listed in Figure 7-4. As such, Alec first needed to determine the context of the sequence diagram. He decided to use a scenario20 from the Place Order use case that was created in Chap- ter 5 and illustrated in Figure 5-17. (Refer to the original use case for the details.) Figure 7-15 lists the normal flow of events, which contains the scenario that this sequence dia- gram describes. The second step was to identify the objects that participated in the scenario being modeled. The classes associated with the Place Order use case are shown in Figure 6-18. For example, the classes used for the Place Order use case include Customer, CD, Marketing Information, Credit Card Clearance Center, Order, Order Item, Vendor, Search Request, CD List, Review, Artist Information, Sample Clip, Individual, and Organizational. Applying the Concepts at CD Selections 257 You have been working with the system for the campus housing service that helps students find apartments. Based on the work completed so far, perform a CRUD analysis to identify which classes collaborate the most and to perform some validation of the evolving representation of the system. 7-4 CRUD AnalysisYOUR TURN 20 Remember, as stated previously, a scenario is a single executable path through a use case. Normal Flow of Events: 1. Customer submits a search request to the system. 2. The System provides the Customer a list of recommended CDs. 3. The Customer chooses one of the CDs to find out additional information. 4. The System provides the Customer with basic information and reviews on the CD. 5. The Customer calls the Maintain Order use case. 6. The Customer iterates over 3 through 5 until done shopping. 7. The Customer executes the Checkout use case. 8. The Customer leaves the Web site. FIGURE 7-15 Normal Flow of Events of the Places Order Use Case During the role playing of the CRC cards, Anne, one of the analysts assigned to the CD Selections Internet System development team, asked whether a Shopping Cart class should be included. She stated that every Internet sales site she had been to had a shopping cart that was used to build an order. However, the instance of the Shopping Cart class existed only until either an order was placed or the shopping cart was emptied. Based on this obvi- ous oversight, both the Place Order use case and the class diagram will have to be modi- fied. Brian, another analyst, pointed out that the CDs themselves were going to have to be associated with some type of searchable storage. Otherwise, it would be impossible to find the CD in which the customer was interested. However, Alec decided that the CD List class would suffice for both the searchable storage and a temporary instance that would be cre- ated as a result of a search request. Alec pointed out to the team that this process was fairly typical in object-oriented development. The more the development team learned about the requirements, the more the models (functional, structural, and behavioral) would evolve. Alec reminded them that the important thing to remember was that an object-oriented development process was incremental and it iterated over all of the models. As such, as they understood the problem better, the team would most likely have to make changes to the functional and structural models already completed. Based on the team’s current understanding of the Place Order use case, they decided that instances of the Search Request, CD List, CD, Marketing Material, Customer, Review, Artist Information, Sample Clip, and Shopping Cart classes would be required to describe this scenario. Furthermore, they realized that the Customer actor interacted with the sce- nario. To complete this step, the team laid out the objects on the sequence diagram by drawing them, from left to right, across the diagram. The third step was to set the lifeline for each object. To do this, they drew a vertical dot- ted line below each of the objects (aSR, aCDL, CDs, aCD, MI, aR, AI, SC, aSC and anOrder) and the actor (aCustomer). They placed an X at the bottom of the lifelines for aCDL and aSC because they go away at the end of this process. The fourth step was to add the messages to the diagram. By examining the steps in Fig- ure 7-15, the team was able to determine the way in which the messages should be added to the diagram. Figure 7-16 shows the diagram they created. Notice how they did not include messages back to Customer in response to create SR and add CD. In these cases, the team assumed that aCustomer would receive response messages about the requested CD and inserted CD, respectively. The fifth step was to add the execution occurrence to each object’s and actor’s lifeline. This was done by drawing a narrow rectangle box over top of the lifelines to represent when the objects (actors) are sending and receiving messages [e.g., in Figure 7-16 aCustomer is active during the entire process, whereas aSR is active only at the beginning of the process (the top of the diagram)]. Finally, the CD Selections team validated the diagram by ensuring that the diagram accu- rately and completely represented the scenario of the Place Order use case being modeled. Figure 7-16 portrays their completed sequence diagram. 258 Chapter 7 Behavioral Modeling In Your Turn 5-8, you completed the detailed use cases for the CD Selections Internet Sales System. In Your Turn 6-4, you completed the structural model. Based on the com- pleted functional and structural models, create the sequence diagrams for the remaining scenarios of all of the use cases in Figure 5-18. 7-5 CD Selections Internet Sales SystemYOUR TURN sd Place Order Use Case CreateSR() aCustomer Find CDs() Create CDL() Get Mkt Info() Get Review() Get Sample Clip() aSR:SearchReq aCDL:CDList CDs:CDList aCD:CD MI:Mkt Info aR:Review anOrder:Order AI:Artist Info SC:Sample Clip aSC:ShoppingCart Get Basic Info() add CD(() Create Order() Get Artist Info() X X FIGURE 7-16 Sequence Diagram for the Places Order Use Case 259 Communication Diagrams Brian, one of the analysts, pointed out to the team that sequence diagrams and communi- cation diagrams essentially modeled the same things. As such, he felt that it was not worth the time for the team to do both. And because they had already completed the sequence diagrams, he really did not want to do the communication diagrams also. However, even though the diagrams are very similar in what they portray, Alec decided that it would be worth the team’s time to build both. He felt that it could be possible that the different for- mats of the diagrams might uncover additional requirements. As such, the team also cre- ated communication diagrams. Alec chose to create the communication diagrams by following the steps in Figure 7-8 that describe how to build a communication diagram. Like creating sequence diagrams, the first step in the process was to determine the context of the communication diagram. Alec chose to start with the same scenario of the Place Order use case that he and the team had used previously when they created the sequence diagrams (see Figure 7-16). By executing the second step, the CD Selections team again identified the objects and the associations that link the objects together. Because they are using the same scenario as they did in the previously described sequence diagram, instances of the Search Request, CD List, CD, Marketing Material, Customer, Review, Artist Information, Sample Clip, and Shop- ping Cart classes should be the ones included. Also, because the Customer actor interacts with the scenario, it should also be included. Furthermore, the team identified the associa- tions between the objects (e.g., the instances of CD are associated with instances of Mkt Info, which, in turn, are associated with instances of Review, Artist Info, and Sample Clip). During the third step, the team placed the objects on the diagram based on the asso- ciations that they have with the other objects in the collaboration. This was done to increase in readability and, hence, the understandability of the diagram (see Figure 7-17). During the fourth step, the CD Selections team added the messages to the associations between the objects. For example, in Figure 7-17, the Create SR() message is the first mes- sage sent, and the FindCDs() message is the second message sent. The aCustomer actor sends the Create SR() message to the aSR object, and the aSR object sends the FindCDs() message to the CDs object. Finally, the CD Selections team executed the fifth and final step: validating the dia- gram. They accomplished this by ensuring that the scenario of the Place Order use case was accurately and completely represented by the diagram. See Figure 7-17 for the completed communication diagram for this particular scenario of the Place Order use case. Further- more, they compared the previously created sequence diagram (see Figure 7-16) with the communication diagram (see Figure 7-17) to ensure that that both diagrams were equiva- lent. The only difference between the two diagrams was the ease in portraying the time ordering of the messages in the sequence diagram to represent how the objects interacted with each other in the communication diagram. 260 Chapter 7 Behavioral Modeling In Your Turn 5-8, you completed the detailed use cases for the CD Selections Internet Sales System. In Your Turn 6-4, you completed the structural model. Based on the com- pleted functional and structural models, create the com- munication diagrams for the remaining scenarios of all the use cases in Figure 5-18. Be sure to compare these dia- grams to the sequence diagrams created in Your Turn 7-5. 7-6 CD Selections Internet Sales SystemYOUR TURN Behavioral State Machines As in the previous example diagrams, we focus our attention only on the Place Order use case. Alec decided to follow the steps building a behavioral state machine (see Figure 7-13). As with the earlier diagrams, the first step was to determine the context for the behavioral state machine to be drawn. Upon reviewing the objects involved in the scenario described by the sequence diagram (see Figure 7-16) and the communication diagram (see Figure 7-17), Alec decided that the team should focus on the Order class. The second step was to identify the various states that an order will go through during its lifetime. To enable the discovery of the initial, final, and stable states of an order, Alec and the development team interviewed a customer representative who dealt with process- ing customer orders on a regular basis. Based on this interview, the team uncovered the life of an order (see Figure 7-18) from start to finish, from an order’s perspective. Applying the Concepts at CD Selections 261 sd Place Order Use Case 10. Create Order() 7: Get Artist Info() 8: Get Sample Clip() 3: Create CDL() 2: Find CDs() 5: Get Mkt Info() 6: Get Review() 9: add CD() 4: Get Basic Info() 1: Create SR() aSR:Search Request aSC:Shopping Cart aCD:CD anOrder:Order MI:Mkt Info SC:Sample Clip aCDL:CDList CDs:CDList aR:Review AI:Artist Info aCustomer FIGURE 7-17 Communication Diagram for the Places Order Use Case 1. The customer creates an order on the Web. 2. The customer submits the order once he or she is finished. 3. The credit authorization needs to be approved for the order to be accepted. 4. If denied, the order is returned to the customer for changes or deletion. 5. If accepted, the order is placed. 6. The order is shipped to the customer. 7. The customer receives the order. 8. The order is closed. FIGURE 7-18 The Life of an Order The third step was to determine the sequence of the states that an order object will pass through during its lifetime. Based on the order’s lifecycle portrayed in Figure 7-18, the team identified and laid out the states of the order on the behavioral state machine. Next, the team identified the events, actions, and guard conditions associated with the transitions between the states of the order. For example, the event Order is created moves the order from the Initial state to the In process state (see Figure 7-19). During the Processing state, a credit authorization is requested. The guard condition Authorization ϭ Approved pre- vents the order from moving from the Processing state to the Placed state unless the credit authorization has been approved. Also, the guard condition Authorization ϭ Denied prevents the order from moving from the Processing state to the Denied state unless the credit autho- rization has been denied. As such, between the two guard conditions, the order is stuck in the processing state until the credit authorization has been either approved or denied. The team finally validated the Order’s behavioral state machine by ensuring that each state was reachable and that it was possible to leave all states except for the final states. Fur- thermore, the team made sure that all states and transitions for the order had been mod- eled. At this point in time, one of the analysts on the team, Brian, suggested that possibly there were multiple types of orders being described in the behavioral state machine. Specifically, he thought that there were denied and accepted orders. Based on this discov- ery, he suggested that two new classes, for each subtype of order, be created. However, upon further review by the entire team, it was decided that adding these classes to the class diagram and modifying all the other diagrams to reflect this change would not add any- thing to the understanding of the problem. Therefore, it was decided not to add the classes. However, in many cases, modeling the states that an object will go through during its lifetime may, in fact, uncover additional useful subclasses. Figure 7-19 illustrates the behavioral state machine that the CD Selections team created for an order object.21 CRUD Matrix As an attempt to tie the functional, structural, and behavioral models together, Alec decided to create a CRUD matrix. To accomplish this, Alec assigned Anne the task of creating the matrix. As in the previous examples, we have limited this example to the Place Order use case. To begin with, Anne created a class-by-class matrix. She then placed a (C)reate, (R)ead, (U)pdate, or a (D)elete in each cell of the matrix that represented an interaction between instances of the classes. For example, in Figures 7-16 and 7-17, an instance of SearchReq created an instance of CDList. Also, in Figures 7-16 and 7-17, an instance of CD references an instance of MktInfo. In this case, an R was placed in the CD:MktInfo cell. Figure 7-20 shows the CRUD matrix that Anne created based on the Place Order use case. 262 Chapter 7 Behavioral Modeling In Your Turn 7-5 and 7-6, you completed the sequence and communication diagrams for all the use-case scenar- ios for the CD Selections Internet Sales System. Based on these scenario-based diagrams and the structural model you created in Your Turn 6-4, create a set of behavioral state machines for each concrete class contained in the class diagram. 7-7 CD Selections Internet Sales SystemYOUR TURN 21 If the development team had been carefully reading our textbook, they would have seen that they could have reused the Order behavioral state machine in Figure 7-11. Order In Process Ordered Denied Order is created Customer submits order Customer edits order information Authorization = Denied Processing Order sent for credit authorization Customer withdraws order request Placed Order sent to customer Customer accepts shipment Shipped Received Authorization = Approved Order is closed FIGURE 7-19 Behavioral State Machine for the Order Class 263 SUMMARY Behavioral Models Behavioral models describe the internal logic of the business processes described by the use cases associated with an information system. They provide a detailed view of how the objects contained in the information system collaborate to support the use cases that rep- resent the underlying business processes. Behavioral models, like functional and structural models, are created using an iterative and incremental process. Based on this process, it is likely that changes will have to be made to both the functional and structural models. Interaction Diagrams Interaction diagrams are used to describe how objects collaborate to support use cases. There are two different types of interaction diagrams: sequence and communication. Both diagrams provide a dynamic model that portrays the interaction among the objects asso- ciated with a use case. The primary difference between the two diagrams is that sequence diagrams focus on the time-ordering or sequence of the messages being sent between the objects, whereas communication diagrams spotlight the collaborating nature of the objects supporting use cases. A communication diagram is essentially an object diagram (see Chapter 6) that portrays message-sending relationships instead of structural relationships. 264 Chapter 7 Behavioral Modeling Customer RU UC SearchReq CR CDList CD R Mkt Info UUU Review Artist Info Sample Clip Shopping Cart Order Artist Sample Shopping Customer SearchReq CDList CD Mkt Info Review Info Clip Cart Order FIGURE 7-20 CRUD Matrix for the Places Order Use Case In Your Turn 7-5, 7-6, and 7-7, you completed the sequence diagrams, the communication diagrams, and the behavioral state machines based on the detailed use cases (Your Turn 5-8) and the structural model (Your Turn 6-4) for the CD Selections Internet Sales System. Based on these results, complete the CRUD matrix begun by Anne (see Figure 7-20). 7-8 CD Selections Internet Sales SystemYOUR TURN Behavioral State Machine The behavioral state machine shows the different states through which a single class passes during its life in response to events, along with responses and actions. A state is a set of val- ues that describes an object at a specific point in time, and it represents a point in an object’s life in which it satisfies some condition, performs some action, or waits for some- thing to happen. An event is something that takes place at a certain point in time and changes a value(s) that describes an object, which, in turn, changes the object’s state. As objects move from state to state, they undergo transitions. When drawing a behavioral state machine, like the other behavioral diagrams, the first thing is to set the context of the diagram: system, subsystem, set of classes, or an individ- ual class. Then, rectangles with rounded corners are placed on the model to represent the various states on which the context will take. Next, arrows are drawn between the rectan- gles to denote the transitions, and event labels are written above the arrows to describe the event that causes the transition to occur. Typically, behavioral state machines are used to portray the dynamic aspect of a complex class. CRUD Analysis CRUD analysis is a very useful approach to identifying potential collaborations among classes and to verifying and validating a system. It allows the analyst to see what type of interactions (create, read/reference, update, or delete) that the different types of objects have in the system in a very concise format (CRUD Matrix). CRUD analysis also supports the identification of the more complex objects that could benefit from state modeling using a behavioral state machine. Questions 265 KEY TERMS Action Activity Actor Association Attributes Behavior Behavior models Behavioral state machines Class Class diagram Collaboration Communication diagram Condition CRC cards CRUD analysis CRUD matrix Dynamic model Event Execution occurrence Final state Frame Generic sequence diagram Guard condition Initial state Instance Instance sequence diagram Lifeline Message Method Object Operation Operation call message Packages Return message Scenario Self-delegation Sequence diagram State State symbol Temporary object Transition Trigger Use case QUESTIONS 1. How is behavioral modeling related to structural modeling? 2. How does a use case relate to a sequence diagram? A communication diagram? 3. Contrast the following sets of terms: state; behavior class; object action; activity 266 Chapter 7 Behavioral Modeling use case; scenario method; message 4. Why is iteration important when creating a behavioral model? 5. What are the main building blocks for the sequence diagram? How are they represented on the model? 6. How do you show that a temporary object is to go out of existence on a sequence diagram? 7. Do lifelines always continue down the entire page of a sequence diagram? Explain. 8. Describe the steps used to create a sequence diagram. 9. Describe the main building blocks for the communi- cation diagram and how they are represented on the model. 10. How do you show the sequence of messages on a com- munication diagram? 11. How do you show the direction of a message on a communication diagram? 12. Describe the steps used to create a communication diagram. 13. Are states always depicted using rounded rectangles on a behavioral state machine? Explain. 14. What kinds of events can lead to state transitions on a behavioral state machine? 15. What are the steps in building a behavioral state machine? 16. How are guard conditions shown on a behavioral state machine? 17. Describe the type of class that is best represented by a behavioral state machine. Give two examples of classes that would be good candidates for a behavioral state machine. 18. What is CRUD analysis and what is it used for? 19. Identify the models that contain each of the following components: actor association class extends association final state guard condition initial state links message multiplicity object state transition update operation EXERCISES A. Create a sequence diagram for each of the following scenario descriptions for a video store system. A Video Store (AVS) runs a series of fairly standard video stores. 1. Every customer must have a valid AVS customer card in order to rent a video. Customers rent videos for three days at a time. Every time a customer rents a video, the system must ensure that the cus- tomer does not have any overdue videos. If so, the overdue videos must be returned and an overdue fee paid before customer can rent more videos. 2. If the customer has returned overdue videos but has not paid the overdue fee, the fee must be paid before new videos can be rented. If the customer is a premier customer, the first two overdue fees can be waived, and the customer can rent a video. 3. Every morning, the store manager prints a report that lists overdue videos; if a video is two or more days overdue, the manager calls to remind the cus- tomer to return the video. B. Create a communication diagram for the video system in Exercise A. C. Perform a CRUD analysis for the current state of the video system in Exercise A. D. Create a sequence diagram for each of the following scenario descriptions for a health club membership system. 1. When members join the health club, they pay a fee for a certain length of time. The club wants to mail out reminder letters to members asking them to renew their memberships one month before their memberships expire. About half of the members do not renew their memberships. These members are sent follow-up surveys to complete asking why they decided not to renew so that the club can learn how to increase retention. If the member did not renew because of cost, a special discount is offered to that customer. Typically, 25 percent of accounts are reactivated because of this offer. 2. Every time a member enters the club, an attendant takes his or her card and scans it to make sure the person is an active member. If the member is not active, the system presents the amount of money it Exercises 267 costs to renew the membership. The customer is given the chance to pay the fee and use the club, and the system makes note of the reactivation of the account so that special attention can be given to this customer when the next round of renewal notices are dispensed. E. Create a communication diagram for each of the health club membership scenarios described in Exercise D. F. Perform a CRUD analysis for the current state of the health club membership system in Exercise D. G. Think about sending a first-class letter to an interna- tional pen pal. Describe the process that the letter goes through to get from your initial creation of the letter to being read by your friend, from the letter’s perspec- tive. Draw a behavioral state machine that depicts the states that the letter moves through. H. Consider the video store that is described in Question A. Draw a behavioral state machine that describes the various states that a video goes through from the time it is placed on the shelf through the rental and return process. I. Draw a behavioral state machine that describes the various states that a travel authorization can have through its approval process. A travel authorization form is used in most companies to approve travel expenses for employees. Typically, an employee fills out a blank form and sends it to his or her boss for a sig- nature. If the amount is fairly small (< $300), then the boss signs the form and routes it to accounts payable to be input into the accounting system. The system cuts a check that is sent to the employee for the right amount, and after the check is cashed, the form is filed away with the canceled check. If the check is not cashed within 90 days, the travel form expires. When the amount of the travel voucher is a large amount (> $300), then the boss signs the form and sends it to the CFO, along with a paragraph explaining the purpose of the travel; the CFO signs the form and passes it along to accounts payable. Of course, both the boss and the CFO can reject the travel authorization form if they do not feel that the expenses are reasonable. In this case, the employee can change the form to include more explanation or decide to pay the expenses. J. Picnics R Us (PRU) is a small catering firm with five employees. During a typical summer weekend, PRU caters fifteen picnics with twenty to fifty people each. The business has grown rapidly over the past year, and the owner wants to install a new computer system for managing the ordering and buying processes. PRU has a set of ten standard menus. When potential cus- tomers call, the receptionist describes the menus to them. If the customer decides to book a picnic, the receptionist records the customer information (e.g., name, address, phone number, etc.) and the informa- tion about the picnic (e.g., place, date, time, which one of the standard menus, total price) on a contract. The customer is then faxed a copy of the contract and must sign and return it along with a deposit (a credit- card number or check) before the picnic is officially booked. The remaining money is collected when the picnic is delivered. Sometimes, the customer wants something special (e.g., birthday cake). In this case, the receptionist takes the information and gives it to the owner, who determines the cost; the receptionist then calls the customer back with the price informa- tion. Sometimes the customer accepts the price; other times, the customer requests some changes that have to go back to the owner for a new cost estimate. Each week, the owner looks through the picnics scheduled for that weekend and orders the supplies (e.g., plates) and food (e.g., bread, chicken) needed to make them. The owner would like to use the system for marketing as well. It should be able to track how customers learned about PRU and identify repeat customers, so that PRU can mail special offers to them. The owner also wants to track the picnics on which PRU sent a contract but the customer did not sign the contract and actually book a picnic. 1. Create an activity diagram for the PRU system. 2. Identify the use cases for the PRU system. 3. Create the use-case diagram for the PRU system. 4. Create a class diagram for the PRU System. 5. Choose one use case and create sequence diagrams. 6. Create a communication diagram for the use case chosen in Question 5. 7. Create a behavioral state machine to depict one of the classes on the class diagram in Question 2. 8. Perform a CRUD analysis for the current state of the system’s representation. K. Of-the-Month Club (OTMC) is an innovative young firm that sells memberships to people who have an interest in certain products. People pay membership fees for one year and each month receive a product by mail. For example, OTMC has a coffee-of-the-month club, which sends members one pound of special cof- fee each month. OTMC currently has six member- ships (coffee, wine, beer, cigars, flowers, and computer games), each of which costs a different amount. Cus- tomers usually belong to just one, but some belong to two or more. When people join OTMC, the telephone 268 Chapter 7 Behavioral Modeling operator records the name, mailing address, phone number, e-mail address, credit-card information, start date, and membership service(s) (e.g., coffee). Some customers request a double or triple membership (e.g., two pounds of coffee, three cases of beer). The computer game membership operates a bit differently from the others. In this case, the member must also select the type of game (action, arcade, fantasy/ science-fiction, educational, etc.) and age level. OTMC is planning to greatly expand the number of member- ships it offers (e.g., video games, movies, toys, cheese, fruit, vegetables), so the system needs to accommodate this future expansion. OTMC is also planning to offer three-month and six-month memberships. 1. Create an activity diagram for the OTMC system. 2. Identify the use cases for the OTMC system. 3. Create a use-case diagram for the OTMC system. 4. Create a class diagram for the OTMC System. 5. Choose one use case and create sequence diagrams. 6. Create a communication diagram for the use case chosen in Question 5. 7. Create a behavioral state machine to depict one of the classes on the class diagram in Question 2. 8. Perform a CRUD analysis for the current state of the system’s representation. L. Think about your school or local library and the processes involved in checking out books, signing up new borrowers, and sending out overdue notices from the library’s perspective. Describe three use cases that represent these three functions. 1. Create a use-case diagram for the library system. 2. Create a class diagram for the library system. 3. Choose one use case and create sequence diagrams. 4. Create a communication diagram for the use case chosen in Question 3. 5. Create a behavioral state machine to depict one of the classes on the class diagram in Question 2. M. Think about the system that handles student admis- sions at your university. The primary function of the system should be able to track a student from the request for information through the admissions process until the student is either admitted or rejected from attending the school. Write a use-case descrip- tion that can describe an Admit Student use case. 1. Create a use-case diagram for the one use case. Assume that students of alumni are handled differ- ently than other students. Also, a generic Update Student Information use case is available for your system to use. 2. Create a class diagram for the use case that you selected for Question 2. An admissions form includes the contents of the form, SAT information, and ref- erences. Additional information is captured about students of alumni, such as their parent’s graduation year, contact information, and college major. 3. Choose one use case and create sequence diagrams. Assume that a temporary student object is used by the system to hold information about people before they send in an admission form. After the form is sent in, these people are considered students. 4. Create a communication diagram for the use case chosen in Question 3. 5. Create a behavioral state machine to depict a person as he or she moves through the admissions process. 6. Perform a CRUD analysis for the current state of the system’s representation. 1. Refer to the use-case descriptions and use-case dia- gram you prepared for Professional and Scientific Staff Management (PSSM) for Minicase 2 in Chapter 5. PSSM was so satisfied with your work that they wanted the behavioral models created so that they could understand the interaction that would take place between the users and the system in greater detail. a. Create both sequence and a communication dia- grams for each use case. b. Based on the sequence and communication dia- grams, create CRC cards for each class identified and a class diagram. c. Perform a CRUD analysis for the current state of the system’s representation. 2. Refer to the structural model that you created for Hol- iday Travel Vehicles for Minicase 2 in Chapter 6. a. Choose one of the more complex classes and create a behavioral state machine for it. b. Based on the structural model you created, role- play the CRC cards to develop a set of use cases that describe a typical sales process. c. Create both sequence and communication dia- grams for the use case. d. Perform a CRUD analysis for the current state of the system’s representation. MINICASES Contracts Hardware/Software Specifications Deployment Diagrams User Interface Design Data Access & Manipula- tion Class Design Object Persistence Design Method Specifications Class Specifications Package Diagrams Alternative Matrix Factored/Partitioned Structural Model Factored/Partitioned Functional Model Factored/Partitioned Behavioral Model PART THREE Design Modeling Whereas analysis modeling concentrated on the functional requirements of the evolving system, de- sign modeling incorporates the nonfunctional re- quirements. That is, design modeling focuses on how the system will operate. First, the project team veri- fies and validates the analysis models (functional, structural, and behavioral). Next, a set of factored and partitioned analysis models are created. The class and method designs are illustrated using the class specifications (using CRC cards and class diagrams), contracts, and method specifications. Next, the data management layer is addressed by designing the ac- tual database or file structure to be used for object persistence, and a set of classes that will map the class specifications into the object persistence format chosen. Concurrently, the team produces the user in- terface layer design using use scenarios, windows navigation diagrams, real use cases, interface stand- ards, and user interface templates. The physical archi- tecture layer design is created using deployment diagrams and hardware software specification. This collection of deliverables represents the system speci- fication that is handed to the programming team for implementation. CHAPTER 8 Moving on to Design CHAPTER 9 Class and Method Design CHAPTER 10 Data Management Layer Design CHAPTER 11 Human Computer Interaction Layer Design CHAPTER 12 Physical Architecture Layer Design This page intentionally left blank Object-oriented system development uses the requirements that were gathered during analysis to create a blueprint for the future system. A successful object-oriented design builds upon what was learned in earlier phases and leads to a smooth implementation by creating a clear, accurate plan of what needs to be done. This chapter describes the initial transition from analysis to design and presents three ways to approach the design for the new system. OBJECTIVES ■ Understand the verification and validation of the analysis models. ■ Understand the transition from analysis to design. ■ Understand the use of factoring, partitions, and layers. ■ Be able to create package diagrams. ■ Be familiar with the custom, packaged, and outsource design alternatives. ■ Be able to create an alternative matrix. CHAPTER OUTLINE CHAPTER 8 Moving on to Design 271 Introduction Verifying and Validating the Analysis Models Verification and Validation through Walkthroughs Functional Model Verification and Validation Structural Model Verification and Validation Behavioral Model Verification and Validation Balancing the Analysis Models Evolving the Analysis Models into Design Models Factoring Partitions and Collaborations Layers Packages and Package Diagrams Identifying Packages and Creating Package Diagrams Verifying and Validating Package Diagrams Design Strategies Custom Development Packaged Software Outsourcing Selecting a Design Strategy Developing the Actual Design Alternative Matrix Applying the Concepts at CD Selections Packages and Package Diagrams Verifying and Validating the Analysis Models Developing the Actual Design Summary INTRODUCTION The purpose of analysis is to figure out what the business needs are. The purpose of design is to decide how to build the system. The major activity that takes place during design is evolving the set of analysis representations into design representations. Throughout design, the project team carefully considers the new system in respect to the current environment and systems that exist within the organization as a whole. Major considerations of the how of a system are environmental factors such as inte- grating with existing systems, converting data from legacy systems, and leveraging skills that exist in-house. Although the planning and analysis are undertaken to develop a possible system, the goal of design is to create a blueprint for a system that makes sense to implement. An important initial part of design is to examine several design strategies and decide which will be used to build the system. Systems can be built from scratch, purchased and customized, or outsourced to others, and the project team needs to investigate the viabil- ity of each alternative. This decision influences the tasks that are to be accomplished dur- ing design. At the same time, detailed design of the individual classes and methods that are used to map out the nuts and bolts of the system and how they are to be stored must still be completed. Techniques such as CRC cards, class diagrams, contract specification, method specification, and database design provide the final design details in prepara- tion for the implementation phase, and they ensure that programmers have sufficient information to build the right system efficiently. These topics are covered in Chapters 9 and 10. Design also includes activities such as designing the user interface, system inputs, and system outputs, which involve the ways that the user interacts with the system. Chapter 11 describes these three activities in detail, along with techniques such as storyboarding and prototyping, which help the project team design a system that meets the needs of its users and is satisfying to use. Finally, physical architecture decisions are made regarding the hardware and software that will be purchased to support the new system and the way that the processing of the system will be organized. For example, the system can be organized so that its processing is centralized at one location, distributed, or both centralized and distributed, and each solu- tion offers unique benefits and challenges to the project team. Because global issues and security will influence the implementation plans that are made, they need to be considered along with the system’s technical architecture. Physical architecture, security, and global issues are described in Chapter 12. The many steps of design are highly interrelated and, as with the steps in analysis, the analysts often go back and forth among them. For example, prototyping in the interface design step often uncovers additional information that is needed in the system. Alterna- tively, a system that is being designed for an organization that has centralized systems may require substantial hardware and software investments if the project team decides to change to a system in which all the processing is distributed. In this chapter, we overview the processes that are used to evolve the analysis models into design models. But, before we move on into design, we really need to be sure that the current analysis models are consistent. As such, we next discuss an approach to verify and validate the analysis models. Afterward, we describe different higher-level constructs that can be used to evolve the analysis models into design models. Then, we introduce the use of packages and package diagrams as a means of representing the higher-level constructs used to evolve the models. Finally, we examine the three fundamental approaches to devel- oping new systems: make, buy, or outsource. 272 Chapter 8 Moving on to Design VERIFYING AND VALIDATING THE ANALYSIS MODELS1 Before we evolve our analysis representations into design representations, we need to verify and validate the current set of analysis models to ensure that they faithfully represent the problem domain under consideration. This includes testing the fidelity of each model; for example, we must be sure that the activity diagram(s), use-case descriptions, and use-case dia- grams all describe the same functional requirements, and between the models, for instance, transitions on a behavioral state machine are associated with operations contained in a class diagram. Before we describe the specific tests to consider, we describe walkthroughs, a man- ual approach that supports verifying and validating the evolving models.2 Afterward, we describe a set of rules that can be used for verification and validation of the analysis models. Verification and Validation through Walkthroughs A walkthrough is essentially a peer review of a product. In the case of the analysis models, a walkthrough is a review of the different models and diagrams created during analysis. This Verifying and Validating the Analysis Models 273 In Chapters 2 and 3, we discussed several classic mis- takes and how to avoid them. Here, we summarize four classic mistakes in the design phase and discuss how to avoid them. 1. Reducing design time: If time is short, there is a temptation to reduce the time spent in “unproduc- tive” activities such as design so that the team can jump into “productive” programming. This results in missing important details that have to be investi- gated later at a much higher time and cost (usually at least ten times higher). Solution: If time pressure is intense, use timeboxing to eliminate functionality or move it into future versions. 2. Feature creep: Even if you are successful at avoiding scope creep, about 25 percent of system require- ments will still change. And, changes—big and small—can significantly increase time and cost. Solution: Ensure that all changes are vital and that the users are aware of the impact on cost and time. Try to move proposed changes into future versions. 3. Silver bullet syndrome: Analysts sometimes believe the marketing claims for some design tools that claim to solve all problems and magically reduce time and costs. No one tool or technique can eliminate overall time or costs by more than 25 percent (although some can reduce individual steps by this much). Solution: If a design tool has claims that appear too good to be true, just say no. 4. Switching tools midproject: Sometimes analysts switch to what appears to be a better tool during design in the hopes of saving time or costs. Usually, any benefits are outweighed by the need to learn the new tool. This also applies even to minor upgrades to current tools. Solution: Don’t switch or upgrade unless there is a compelling need for specific features in the new tool, and then explicitly increase the schedule to include learning time. Adapted from Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1966). Avoiding Classic Design MistakesPRACTICAL TIP 1 The material in this section has been adapted from E. Yourdon, Modern Structured Analysis (Englewood Cliffs, NJ: Prentice Hall, 1989). Verifying and validating are a type of testing. We also describe testing in Chapter 13. 2 Even though many modern CASE tools can automate much of the verifying and validating of the analysis mod- els, we feel that it is paramount that systems analysts understand the principles of verification and validation. Fur- thermore, some tools such as VISIO that supports UML diagramming are only diagramming tools. Regardless, the analyst is expected to perform all diagramming correctly. review typically is completed by a team of individuals that comes from the analysis team, the design team, and the client. The purpose of an analysis walkthrough is to thoroughly test the fidelity of the analysis models to the functional requirements and to ensure that the models are consistent. That is, an analysis walkthrough uncovers errors or faults in the evolving spec- ification. However, a walkthrough does not correct errors—it simply identifies them. Error correction is to be accomplished by the analysis team after the walkthrough is completed. Walkthroughs are very interactive. As the presenter “walks” through the representa- tion, members of the walkthrough team should ask questions regarding the representation. For example, if the presenter is walking through a class diagram, another member of the team could ask why certain attributes, operations, or associations were not included. The actual process of simply presenting the representation to a new set of eyes can uncover obvious misunderstandings and omissions. In many cases, the representation creator can get lost in the proverbial trees and not see the forest.3 In fact, many times the act of walking through the representation causes a presenter to see the error himself or herself. For psy- chological reasons, hearing the representation helps the analyst to see the representation more completely.4 As such, the representation creators should regularly do a walkthrough of the analysis models themselves by reading the representations out loud to themselves, regardless of how they think it may make them look. There are specified roles that different members of the walkthrough team can play. The first is the presenter role. This should be played by the individual who is primarily responsi- ble for the specific representation being reviewed. This individual presents the representation to the walkthrough team. The second role is recorder, or scribe. The recorder should be a member of the analysis team. This individual carefully takes the minutes of the meeting by recording all significant events that occur during the walkthrough. In particular, all errors that are uncovered must be documented so that the analysis team can address them. Another important role is to have someone who raises issues regarding maintenance of the represen- tation. Yourdon refers to this individual as a maintenance oracle.5 Due to the emphasis on reusability in object-oriented development, this role becomes particularly crucial. Finally, someone must be responsible for calling, setting up, and running the walkthrough meetings. For a walkthrough to be successful, the members of the walkthrough team must be fully prepared. As such, all materials to be reviewed must be distributed with sufficient time for the team members to review them before the actual meeting. Furthermore, all team members should be expected to mark up the representations so that during the walk- through meeting, all relevant issues can be discussed. Otherwise, the walkthrough will be both inefficient and ineffective. During the actual meeting, as the presenter is walking through the representation, the team members should point out any potential errors or misunderstandings. In many cases, the errors and misunderstandings are caused by invalid assumptions that would not be uncovered without the walkthrough. One potential danger of walkthroughs is when management decides the results of uncovering errors in the representation are a reflection of an analyst’s capability. This must be avoided at all costs. Otherwise, the underlying purpose of the walkthrough—to improve the fidelity of the representation—will be thwarted. Depending on the organization, it may be necessary to omit management from the walkthrough process. If not, the walkthrough process may break down into a slugfest to make some team members to look good by destroying the presenter. To say the least, this is obviously counterproductive. 274 Chapter 8 Moving on to Design 3 In fact, all joking aside, in many cases the developer is down at the knothole level and can’t even see the tree, let alone the forest. 4 This has to do with using different senses. Because our haptic senses are the most sensitive, “touching” the rep- resentation would be best. However, it is not clear how one can touch a use case or a class. 5 See Appendix D of Yourdon, Modern Structured Analysis. Functional Model Verification and Validation In this book, we have suggested three different representations for the functional model: activity diagrams, use-case descriptions, and use-case diagrams (see Chapter 5). In this sec- tion, we describe a set of rules to ensure that these three representations are consistent among themselves. First, when comparing an activity diagram to a use-case description, there should be at least one event recorded in the normal flow of events, subflows, or alternate/exceptional flows of the use-case description for each activity or action that is included on an activity diagram, and each event should be associated with an activity or action. For example, in Figure 5-2, there is an activity labeled Get Patient Information that seems to be associated with the first two events contained in the normal flow of events of the use-case description shown in Figure 5-5. Second, all objects portrayed as an object node in an activity diagram must be mentioned in an event in the normal flow of events, subflows, or alternate/exceptional flows of the use- case description. For example, the activity diagram in Figure 5-2 portrays an Appt object, and the use-case description refers to a new appointment and changing an existing appointment. Third, sequential order of the events in a use-case description should occur in the same sequential order of the activities contained in an activity diagram. For example in Figures 5-2 and 5-5, the events associated with the Get Patient Information activity (events 1 and 2) should occur before the events associated with the Make Payment Arrangements activity (event 4). Fourth, when comparing a use-case description to a use-case diagram, there must be one and only one use-case description for each use case, and vice versa. For example, Figure 5-5 portrays the use-case description of the Make Appointment use case. However, the use-case diagrams shown in Figures 5-8, 5-9, and 5-10 are not totally consistent with the use-case description given in Figure 5-5. As such, either the use-case description needs to be modified by breaking it down into multiple use-case descriptions or the use-case diagram needs to be modified. Upon reviewing the two representations, it was decided to create a new use-case diagram (see Figure 8-1) that was consistent with the use-case Verifying and Validating the Analysis Models 275 Appointment System Make Payment Arrangements Create New Patient Produce Schedule Information Patient Make Appointment ** Management Doctor Record Availability Manage Schedule ** ** < < i nclu de> > <> < > <> FIGURE 8-1 Modified Use-Case Diagram for the Appointment System description given in Figure 5-5. However, there are still inconsistencies between the two representations: the use-case diagram has use cases portrayed on it, but there were no use- case descriptions associated with them. For presentation purposes, we have omitted those additional descriptions. As such, we can safely assume that they would go through the same testing procedure that the Make Appointment use case does. Fifth, all actors listed in a use case description must be portrayed on the use-case dia- gram. Furthermore, each one must have an association link that connects it to the use case and must be listed with the association relationships in the use-case description. For example, the Patient actor is listed in the use-case description of the Make Appointment use case (see Figure 5-5), it is listed with the association relationships in the Make Appointment use-case description, and it is connected to the use case in the use-case dia- gram (see Figure 8-1). Sixth, in some organizations, we should also include the stakeholders listed in the use- case description as actors in the use-case diagram. For example, there could have been an association between the Doctor actor and the Make Appointment use case (see Figures 5-5 and 8-1). However, in this case it was decided not to include this association because the Doctor never participates in the Make Appointment use case.6 Seventh, all other relationships listed in a use-case description (include, extend, and generalization) must be portrayed on a use-case diagram. For example, in Figure 5-5, there is an include relationship listed with the Make Payment Arrangements use case and in Figure 8-1, we see that it appears on the diagram between the two use cases. Finally, there are many diagram-specific requirements that must be enforced. For example, in an activity diagram a decision node can be connected to activity or action nodes only with a control flow, and for every decision node there should be a matching merge node (see Chapter 5). Every type of node and flow has different restrictions. However, the complete restrictions for all the UML diagrams are beyond the scope of this text.7 The concept map in Figure 8-2 portrays the associations among the func- tional models. Structural Model Verification and Validation In Chapter 6, we suggested three representations that could be used for structural model- ing: CRC cards, class diagrams, and object diagrams. Because an object diagram is simply an instantiation of some part of a class diagram, we limit our discussion to CRC cards and class diagrams. As in the previous section regarding functional models, this section pro- vides a set of rules that will test the consistency within the structural models. For example purposes, we use the appointment problem described in Chapters 5, 6, and 7. An example CRC card for the patient class is shown in Figure 6-1, and the associated class diagram is portrayed in Figure 6-2. First, every CRC card should be associated with a class on the class diagram, and vice versa. For example, the Patient CRC card is associated with the Patient class on the class diagram (see Figures 6-1 and 6-2). However, in Chapter 6 we portrayed a CRC card only for the Patient class. Obviously, there needs to be a CRC card associated with each and every class on the class diagram for the structural model to be consistent. 276 Chapter 8 Moving on to Design 6 Another possibility could have been to include a Receptionist actor. However, we had previously decided that the Receptionist was in fact part of the Appointment System and not simply a user of the system. If UML supported the idea of internal actors, or actor-to-actor associations, this implicit association could easily be made explicit by having the Patient actor communicate with the Receptionist actor directly, regardless of whether the Receptionist actor was part of the system or not. See Footnote 19 in Chapter 5. 7 A good reference for these types of restrictions is S.W. Ambler, The Elements of UML 2.0 Style (Cambridge, UK: Cambridge University Press, 2005). Second, the responsibilities listed on the front of the CRC card must be included as operations in a class on a class diagram, and vice versa. For example, the make appointment responsibility on the patient CRC card also appears as the make appointment() operation in the Patient class on the class diagram. Third, collaborators on the front of the CRC card imply some type of relationship on the back of the CRC card and some type of association that is connected to the associated class on the class diagram. For example, the appointment collaborator on the front of the CRC card also appears as an other association on the back of the CRC card and as an asso- ciation on the class diagram that connects the Patient class with the Appointment class. Fourth, attributes listed on the back of the CRC card must be included as attributes in a class on a class diagram, and vice versa. For example, the amount attribute on the Patient CRC card is included in the attribute list of the Patient class on the class diagram. Fifth, the object type of the attributes listed on the back of the CRC card and with the attributes in the attribute list of the class on a class diagram implies an association from the class to the class of the object type. For example, technically speaking, the amount attribute implies an association with the double-object type. Simple types such as int and double are never shown on a class diagram. Furthermore, depending on the problem domain, object types such as Per- son, Address, or Date may not be explicitly shown either. However, if we know that messages are being sent to instances of those object types, we probably should include these implied associ- ations as relationships. Sixth, the relationships included on the back of the CRC card must be portrayed using the appropriate notation on the class diagram. For example in Figure 6-1, instances of the Patient class is a-kind-of Person, it has instances of the Medical History class as part of it, and it has an association with instances of the Appointment class. As such, the association from the Patient Verifying and Validating the Analysis Models 277 Including Contains Contains Contains HasKinds AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith Have AssociatedWith Activity Diagram Activities/Actions Functional Models Use-Case Diagram Object Nodes Flows Use Cases Scenarios Relationships Stakeholders Actors Events Use Case Descriptions Object Flows Control Flows FIGURE 8-2 Interrelationships among Functional Models class to the Person class should represent that the Person class is a generalization of its sub- classes, including the Patient class; the association from the Patient class to the Medical His- tory class is in the form of aggregation (a white diamond); and the association between instances of the Patient class and instances of the Appointment class is a simple association. Seventh, an association class, such as the Treatment class in Figure 6-2, should be cre- ated only if there is indeed some unique characteristic (attribute, operation, or relation- ship) about the intersection of the connecting classes. If no unique characteristic exists, then the association class should be removed and only an association between the two con- necting classes should be displayed. Eighth, there are times that subclasses contained in a class diagram are really nothing more than different states through which an instance of the superclass will go during the instance’s lifetime. For example, as we discussed in Chapter 7, the subclasses of Freshman, Sophomore, Junior, and Senior really were states that an instance of the Undergraduate class would traverse (see Figure 7-12). In this case, removing subclasses from the class dia- gram can improve the fidelity of the diagram. Finally, as in the functional models, there are specific representation rules that must be enforced. For example, a class cannot be a subclass of itself. As such, the Patient CRC card cannot list Patient with the generalization relationships on the back of the CRC card, nor can a generalization relationship be drawn from the Patient class to itself. Again, all the detailed restrictions for each representation is beyond the scope of this book.8 Figure 8-3 portrays the associations among the structural models. Behavioral Model Verification and Validation In Chapter 7, we described three different diagrams that could be used to represent the behavioral model: the sequence diagram, the communication diagram, and the behavioral state machine. The sequence and communication diagrams modeled the interaction among instances of classes that worked together to support the business processes included in a system, whereas the behavioral state machine described the state changes through which an object traverses during its lifetime. We again use the appointment system described in Chapters 5, 6, and 7 and focus on Figures 7-1, 7-5, 7-9, and 7-14 to describe a set of rules that can be used to ensure that the behavioral model is internally consistent. First, every actor and object included on a sequence diagram must be included as an actor and an object on a communication diagram, and vice versa. For example, in Figures 7-1 and 7-5, the aReceptionist actor and the Patients object appear on both diagrams. Second, if there is a message on the sequence diagram, there must be an association on the communications diagram, and vice versa. For example, Figure 7-1 portrays a message being sent from the aReceptionist actor to the Patients object. As such, a matching associ- ation appears in the corresponding communication diagram (see Figure 7-5). Third, every message that is included on a sequence diagram must appear as a message on an association in the corresponding communication diagram, and vice versa. For exam- ple, the LookUpPatient() message sent by the aReceptionist actor to the Patients object on the sequence diagram (see Figure 7-1) appears as a message on the association between the aReceptionist actor and the Patients object on the communication diagram (see Figure 7-5). Fourth, if a guard condition appears on a message in the sequence diagram, there must be an equivalent guard condition on the corresponding communication diagram, and vice versa. For example, the message sent from the aReceptionist actor to the UnpaidBills object has a guard condition of [aPatient Exists] (see Figure 7-1). Figure 7-5 shows the matching guard condition included on the communication diagram. 278 Chapter 8 Moving on to Design 8 See Footnote 7. Fifth, the sequence number included as part of a message label in a communica- tions diagram implies the sequential order in which the message will be sent. As such, it must correspond to the top-down ordering of the messages being sent on the sequence diagram. For example, the LookUpPatient message sent from the aReceptionist actor to the Patients object on the sequence diagram (see Figure 7-1) is the second from the top of the diagram. As such, the LookUpPatient message sent from the aReceptionist actor to the Patients object on the communications diagram (see Figure 7-5) is labeled with the number 2.9 Verifying and Validating the Analysis Models 279 9 There are more complicated numbering schemes that could be used. However, for our purposes, a simple sequential number is sufficient. Structural Models Including Contains Contains Contains Class Diagram Responsibilities Collaborators Association Aggregation Composition Attributes Classes Type CRC Cards Objects Object Diagram Contains Represents Associations/ Relationships Have HasKinds Generalization Association Class HasKindsHasKinds InstanceOf AssociatedWith AssociatedWith AssociatedWith AssociatedWith Operations FIGURE 8-3 Interrelationships among Structural Models Sixth, all transitions contained in a behavior state machine must be associated with a message being sent on a sequence and communication diagram, and it must be classified as a (C)reate, (U)pdate, or (D)elete message in a CRUD matrix. For example, in Figure 7-9 the Checks In transition must be associated with a message in the corresponding sequence and communication diagrams. Furthermore, it should be associated with an (U)pdate entry in the CRUD matrix associated with the hospital patient system. Seventh, all entries in a CRUD matrix imply a message being sent from an actor or object to another actor or object. If the entry is a (C)reate, (U)pdate, or (D)elete, then there must be an associated transition in a behavioral state machine that represents the instances of the receiving class. For example in Figure 7-14 the R and U entries in the Receptionist row and Appointments column imply that instances of the Receptionist actor will read and update instances of the Appointments class. As such, there should be read and update mes- sages on the sequence and communication diagrams corresponding with the appointments processes. Reviewing Figures 7-1 and 7-5, we see that there is a message, MatchAppts(), from the aReceptionist actor to the Appointments object. However, based on this review, it is unclear as to whether the MatchAppts() message represents a read, update, or both. As such, additional analysis is required.10 Furthermore, because there is an (U)pdate message involved, there must be a transition on a behavioral state machine that portrays the life cycle of an Appointments object. Finally, there are many representation specific rules that have been proposed. However, as in the other models, these rules are beyond the scope of this section on verification and validation.11 Figure 8-4 portrays the associations among the behavioral models. Balancing the Analysis Models In the previous sections, we have focused on verifying and validating the individual models: function, structural, and behavioral. However, as we have stated repeatedly, object-oriented systems development is incremental and iterative. Figure 8-5 portrays the fact that the object-oriented analysis models are highly interrelated. Next, we center our attention on ensuring that the different models are consistent. For example, do the functional and structural models agree? What about the functional and behavioral mod- els? And finally, are the structural and behavioral models trustworthy? In this section, we describe a set of rules that are useful to verify and validate the intersections of the analy- sis models. Depending on the specific constructs of each actual model, different interre- lationships are relevant. The process of ensuring the consistency among them is known as balancing the models. Balancing Functional and Structural Models To balance the functional and structural models, we must ensure that the two sets of models are consistent with each other. That is, the activity diagrams, use-case descriptions, and use-case diagrams must agree with the CRC cards and class diagrams that represent the evolving model of the problem domain. Figure 8-6 shows the interrelationships between the functional and structural models. By reviewing this figure, we uncover four sets of associations between the models. This gives us a place to begin balancing the functional and structural models.12 280 Chapter 8 Moving on to Design 10 We have delayed the description of designing operations/methods until Chapter 9. As such, the detailed infor- mation required to understand a specific message has not been created yet. However, in many cases, enough infor- mation will already have been created to validate many of the transitions in behavioral state machines and CRUD matrices. 11 See Footnote 7. 12 Role-playing the CRC cards (see Chapter 6) also can be very useful in verifying and validating the interrela- tionships among the functional and structural models. Verifying and Validating the Analysis Models 281 Including HasKinds Contains HasKinds Describe Contains Contains Contains AssociatedWith AssociatedWith Behavioral State Machine Interaction Diagram Behavioral Models Sequence DiagramCommunication Diagram Objects Actors Delete Update States Create Messages Cell Entries Transitions CRUD Matrix Associations Read FIGURE 8-4 Interrelationships among Behavioral Models Functional Models Structural Models Behavioral Models FIGURE 8-5 Object-Oriented Analysis Models First, each and every class on a class diagram and each and every CRC card must be associated with at least one use case, and vice versa. For example, the CRC card, portrayed in Figure 6-1, and its related class contained in the class diagram (see Figure 6-2) is associ- ated with the Make Appointment use case described in Figure 5-5. Including Contains AssociatedWith AssociatedWith AssociatedWith AssociatedWith InstanceOf Represents Have HasKindsHasKinds HasKinds Contains Including Contains HasKinds Contains Contains Have Contains Contains Structural Models CRC Cards Object DiagramClass Diagram Collaborators Responsibilities Type Objects Classes Aggregation Association Generalization Associations/ Relationships CompositionAssociation Class Functional Models Use-Case Diagram Activity Diagram Activities/Actions Use-Case Descriptions Flows Events Actors Object Nodes Stakeholders Relationships Object Flows Control Flows Use Cases Scenarios Attributes Operations FIGURE 8-6 Interrelationships among Functional and Structural Models 282 Second, every activity or action contained in an activity diagram (see Figure 5-2) and every event contained in a use-case description (see Figure 5-5) should be related to one or more responsibilities on a CRC card and one or more operations in a class on a class diagram and vice versa. For example, the Get Patient Information activity on the example activity dia- gram (see Figure 5-2) and the first two events on the use-case description (see Figure 5-5) are associated with the make appointment responsibility on the CRC card (see Figure 6-1) and the makeAppointment() operation in the Patient class on the class diagram (see Figure 6-2). Third, every object node on an activity diagram must be associated with an instance of a class on a class diagram, (i.e., an object) and a CRC card, such as the Appt object node (see Figure 5-2) and the Appointment class (see Figure 6-2) or an attribute contained in a class and on a CRC card. However, in Figure 5-2, there is an additional object node, Appt Request Info, that does not seem to be related to any class in the class diagram portrayed in Figure 6-2. Thus, either the activity or class diagram is in error or the object node must represent an attribute. In this case, it does not seem to represent an attribute. As such, we could add a class to the class diagram that creates temporary objects associated with the object node on the activity diagram. However, it is unclear what operations, if any, would be associated with these temporary objects. Therefore, a better solution would be to delete the Appt Request Info object nodes from the activity diagram. In reality, this object node represented only a set of bundled attribute values, that is, data that would be used in the appointment system process (see Figure 8-7). Verifying and Validating the Analysis Models 283 Get Patient Information Appt. Appt. Create New Patient Make Payment Arrangements [New Patient] [Old Patient] Cancel Appointment Change AppointmentCreate Appointment FIGURE 8-7 Updated Appointment System Activity Diagram Fourth, every attribute and association/aggregation relationships contained on a CRC card (and connected to a class on a class diagram) should be related to the subject or object of an event in a use-case description. For example, in Figure 5-5, the second event states: The Patient provides the Receptionist with their name and address. By reviewing the CRC card in Figure 6-1 and the class diagram in Figure 6-2, we see that the Patient class is a sub- class of the Person class and, hence, inherits all the attributes, associations, and operations defined with the Person class, where name and address attributes are defined. Balancing Functional and Behavioral Models As in balancing the functional and struc- tural models, we must ensure the consistency of the two sets of models. In this case, the activity diagrams, use-case descriptions, and use-case diagrams must agree with the sequence diagrams, communication diagrams, behavioral state machines, and CRUD matrix. Figure 8-8 portrays the interrelationships between the functional and behavioral models. Based on these interrelationships, we see that there are four areas with which we must be concerned.13 First, the sequence and communication diagrams must be associated with a use case on the use-case diagram and a use-case description. For example, the sequence diagram in Figure 7-1 and the communication diagram in Figure 7-5 are related to scenarios of the Make Appointment use case that appears in the use-case description in Figure 5-5 and the use-case diagram in Figure 8-1. Second, actors on sequence diagrams, communication diagrams, and/or CRUD matrices must be associated with actors on the use-case diagram or referenced in the use-case description, and vice versa. For example, the aPatient actor in the sequence diagram in Figure 7-1, the com- munication diagram in Figure 7-5, and the CRUD matrix in Figure 7-14 appears in the use-case diagram in Figure 8-1 and the use-case description of Figure 5-5. However, the aReceptionist does not appear in the use-case diagram but is referenced in the events associated with the Make Appointment use-case description. In this case, the aReceptionist actor is obviously an internal actor, which cannot be portrayed on UML’s use-case diagram. Third, messages on sequence and communication diagrams, transitions on behavioral state machines, and entries in a CRUD matrix must be related to activities and actions on an activity diagram and events listed in a use-case description, and vice versa. For example, the CreateAppt() message on the sequence and communication diagrams (see Figures 7-1 and 7-5) is related to the CreateAppointment activity (see Figure 8-7) and the S-1: New Appointment subflow on the use-case description (see Figure 5-5). Furthermore, the C entry into the Receptionist Appointment cell of the CRUD matrix is also associated with these messages, activity, and subflow. Fourth, all complex objects represented by an object node in an activity diagram must have a behavioral state machine that represents the object’s lifecycle, and vice versa. As stated in Chapter 7, complex objects tend to be very dynamic and pass through a variety of states during their lifetimes. However, the Appointment object node (see Figure 8-7) seems to represent a fairly simple object. It seems only to be created, changed, and canceled. As such, in this case no behavioral state machine would be necessary. Balancing Structural and Behavioral Models To discover the interrelationships among the structural and behavioral models, we use the concept map in Figure 8-9. In this case, there are five areas in which we must ensure the consistency among the models.14 284 Chapter 8 Moving on to Design 13 Performing CRUD analysis (see Chapter 7) could also be useful in reviewing the intersections among the functional and behavioral models. 14 Both role-playing (see Chapter 6) and CRUD analysis (see Chapter 7) also can be very useful in this undertaking. Including AssociatedWith AssociatedWith AssociatedWith AssociatedWith Contains Describe Including Contains Contains Contains HasKinds HasKinds Contains Contains Have HasKinds Contains Behavioral Models CRUD Matrix Communication Diagram Associations Messages Sequence Diagram Cell Entries Transitions States Activity Diagram Use-Case Diagram Use-Case Descriptions Object Nodes Activities/Actions Stakeholders Relationships UpdateCreate Objects Use Cases Control FlowsObject Flows Flows Events Actors Functional Models Behaviorial State Machine Interaction Diagram Read Delete Scenarios Actors FIGURE 8-8 Interrelationships among Functional and Behavioral Models 285 Including Including Contains Contains AssociatedWith AssociatedWith AssociatedWith AssociatedWith Structural Models CRC Cards Object DiagramClass Diagram Contains Contains Contains InstanceOf Responsibilities Objects Represents Classes Associations/ Relationships Attributes Type Have HasKinds HasKinds HasKinds HasKinds Association Aggregation Generalization CompositionAssociation Class Operations Contains Behavioral Models Interaction Diagram Behaviorial State Machine CRUD Matrix Communication Diagram Associations Actors Messages Sequence Diagram Cell Entries Transitions Contains Contains Describe States Delete UpdateReadCreate HasKinds Objects Collaborators FIGURE 8-9 Interrelationships among Structural and Behavioral Models 286 First, objects that appear in a CRUD matrix must be associated with classes that are represented by CRC cards and appear on the class diagram, and vice versa. For example, the Patient class in the CRUD matrix in Figure 7-14 is associated with the CRC card in Figure 6-1 and the Patient class in the class diagram in Figure 6-2. Second, because behavioral state machines represent the life cycle of complex objects, they must be associated with instances (objects) of classes on a class diagram and with a CRC card that represent the class of the instance. For example, the behavior state machine that describes an instance of an Order class in Figure 7-11 implies that an Order class exists on a related class diagram and that a CRC card exists for the related class. Third, communication and sequence diagrams contain objects that must be an instanti- ation of a class that is represented by a CRC card and is located on a class diagram. For exam- ple, Figure 7-1 and Figure 7-5 have an anAppt object that is an instantiation of an Appointment class. As such, the Appointment class must exist in the class diagram (see Figure 6-2) and a CRC card should exist that describes it. However, there are several objects on the communication and sequence diagrams associated with classes that do not exist on the class diagram. These include a PatientsList class, a BillsList class, and ApptsList class. At this point in time, the analyst must decide to either modify the class diagram by adding these classes or rethink the communication and sequence diagrams. In this specific case, because we are mov- ing on into design, it is better to add the classes to the class diagram (see Figure 8-10). Fourth, messages contained on the sequence and communication diagrams, transi- tions on behavioral state machines, and cell entries on a CRUD matrix must be associated with responsibilities and associations on CRC cards and operations in classes and associa- tions connected to the classes on class diagrams. For example, the CreateAppt() message on the sequence and communication diagrams (see Figures 7-1 and 7-5) relate to the makeAp- pointment operation of the Patient class and the schedules association between the Patient and Appointment classes on the class diagram (see Figure 6-2). Fifth, the states in a behavioral state machine must be associated with different values of an attribute or set of attributes that describe an object. For example, in Figure 7-12 an instance of the Undergraduate class has different states based on the value of an attribute: HoursEarned. Summary Figure 8-11 portrays a concept map that is a complete picture of the interre- lationships among the diagrams covered in Chapters 5, 6, and 7. It is obvious from the complexity of this figure that balancing all the functional, structural, and behavioral mod- els is a very time-consuming, tedious, and difficult task. However, without paying this level of attention to the evolving models that represent the system, the models will not provide a sound foundation on which to design and build the system. EVOLVING THE ANALYSIS MODELS INTO DESIGN MODELS Now that we have successfully verified and validated our analysis models, we need to begin evolving them into appropriate design models. The purpose of the analysis models was to represent the underlying business problem domain as a set of collaborating objects. In other words, the analysis activities defined the functional requirements. To achieve this, the analysis activities ignored nonfunctional requirements such as performance and the system environment issues (e.g., distributed or centralized processing, user interface issues, and database issues). In contrast, the primary purpose of the design models is to increase the likelihood of successfully delivering a system that implements the functional requirements in a manner that is affordable and easily maintainable. Therefore, in system design, we address both the functional and nonfunctional requirements. Evolving the Analysis Models into Design Models 287 288 Chapter 8 Moving on to Design Person -lastname -firstname -address -phone -birthdate -/ age Patient -amount -insurance carrier +make appointment() +calculate last visit() +change status() +provides medical history() provides 0..1 0..1 0..1 0..1 0..* 0..* 0..* 0..* 0..* 0..* 0..* 0..* 1..* 1..* 1..* * 0..1 1 1 1 1 11 1 Appointment -time -date -reason +cancel without notice() +primary insurance carrier Bill -date -amount -purpose +generate cancellation fee() Medical History -heart disease -high blood pressure -diabetes -alergies Nurse Doctor Employee PatientsList BillsList Health Team Administrative Staff Symptom -name Illness -description Treatment medication instructions symptom severity containedIn containedIn containedIn suffer has scheduled leads to schedules ApptsList FIGURE 8-10 Updated Appointment System Class Diagram From an object-oriented perspective, system design models simply refine the system analysis models by adding system environment (or solution domain) details to them and refin- ing the problem domain information already contained in the analysis models. When evolving the analysis model into the design model, you should first carefully review the use cases and the current set of classes (their operations and attributes, and the relationships between them). Including Contains Contains Contains Represents Instanceof Contains HasKinds HasKinds HasKinds Have HasKinds Including AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith Associated With AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith AssociatedWith Includes HasKinds Including Contains Contains Contains Contains Contains Contains Contains HasKinds Structural Models CRC Cards Object DiagramClass Diagram Collaborators Attributes Operations Type Classes Associations/ Relationships Aggregation Generalization CompositionAssociation Class Behavioral Models Object-Oriented Analysis Models Interaction Diagram Behaviorial State Machine CRUD Matrix Communication Diagram Messages Sequence Diagram Cell Entries Activity Diagram Use-Case Diagram Use-Case Descriptions Object Flows Control Flows Object Nodes Activities/ Actions Flows Stakeholders Relationships Events Delete Read Update Create Scenarios Functional Models Actors Objects AssociatedWith Transitions States Association Have Use Cases Responsibilities FIGURE 8-11 Interrelationships among Object-Oriented Analysis Models 289 Are all the classes necessary? Are there any missing classes? Are the classes fully defined? Are their any missing attributes or methods? Do the classes have any unnecessary attributes and methods? Is the current representation of the evolving system optimal? Obviously, if we have already verified and validated the analysis models, quite a bit of this has already taken place.Yet, object-oriented systems development is both incremental and iterative. Therefore, we must review the analysis models again. However this time, we begin looking at the models of the problem domain through a design lens. As such, we will make modifications to the problem domain models that will enhance the efficiency and effectiveness of the evolving system. In the following sections, we introduce factoring, partitions and collaborations, and lay- ers as a way to evolve problem domain-oriented analysis models into optimal solution domain-oriented design models. From an enhanced Unified Process perspective (see Figure 1-11), we are moving from the analysis workflow to the design workflow. Furthermore, we are moving further into the Elaboration phase and partially into the Construction phase. Factoring Factoring is the process of separating out a module into a stand-alone module in and of itself. The new module can be a new class or a new method. For example, when reviewing a set of classes, it may be discovered that they have a similar set of attributes and methods. As such, it may make sense to factor out the similarities into a separate class. Depending on whether the new class should be in a superclass relationship to the existing classes or not, the new class can be related to the existing classes through generalization (a-kind-of ) or possibly through aggre- gation (has-parts) relationship. For example, using the appointment system example in the previous chapters (see Figure 6-2), if the Employee class had not been identified, we could pos- sibly identify it at this stage by factoring out the similar methods and attributes from the Nurse, Administrative Staff, and Doctor classes. In this case, we would relate the new class (Employee) to the existing classes using the generalization (a-kind-of) relationship. Obviously, by exten- sion we also could have created the Person class if it had not been previously identified. Abstraction and refinement are two processes closely related to factoring. Abstraction deals with the creation of a higher-level idea from a set of ideas. Identifying the Employee class is an example of abstracting from a set of lower classes to a higher one. In some cases, the abstrac- tion process will identify abstract classes, whereas in other situations, it will identify additional concrete classes.15 The refinement process is the opposite of the abstraction process. In the appointment system example in the previous chapters (see Figure 6-2), we could identify addi- tional subclasses of the Administrative Staff class, such as Receptionist, Secretary, and Book- keeper. Of course we would add the new classes only if there were sufficient differences between them. Otherwise, the more general class, Administrative Staff, would suffice. Partitions and Collaborations Based on all the factoring, refining, and abstracting that can take place to the evolving system, the sheer size of the system representation can overload both the user and the developer. At this point in the evolution of the system, it may make sense to split the representation into a set of partitions. A partition is the object-oriented equivalent of a subsystem,16 where a sub- system is a decomposition of a larger system into its component systems (e.g., an accounting 290 Chapter 8 Moving on to Design 15 See Chapter 6 for the differences between abstract and concrete classes. 16 Some authors refer to partitions as subsystems [e.g., see R. Wirfs-Brock, B. Wilkerson, and L. Weiner, Designing Object-Oriented Software (Englewood Cliffs, NJ: Prentice Hall, 1990)], whereas others refer to them as layers [e.g., see I. Graham, Migrating to Object Technology (Reading, MA: Addison-Wesley, 1994)]. However, we have chosen to use the term partition [C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliffs, NJ: Prentice Hall, 1998)] to minimize confusion between subsystems in a traditional system development approach and layers associated with Rational’s Unified Approach. information system could be functionally decomposed into an accounts payable system, an account receivable system, a payroll system, etc.). From an object-oriented perspective, parti- tions are based on the pattern of activity (messages sent) among the objects in an object- oriented system. We describe an easy approach to model partitions and collaborations later in this chapter: packages and package diagrams. A good place to look for potential partitions is the collaborations modeled in UML’s com- munication diagrams (see Chapter 7). If you recall, one useful way to identify collaborations is to create a communication diagram for each use case. However, because an individual class may support multiple use cases, an individual class can participate in multiple use-case-based collaborations. In those cases where classes are supporting multiple use cases, the collabora- tions should be merged together. Furthermore, the class diagram should be reviewed to see how the different classes are related to one another. For example, if attributes of a class have complex object types, such as Person, Address, Department, etc., and these object types were not modeled as associations in the class diagram, we need to recognize these implied associ- ations. As such, creating a diagram that combines the class diagram with the communication diagrams can be very useful to show to what degree the classes are coupled.17 The greater the coupling between classes, the more likely the classes should be grouped together in a collab- oration or partition. Finally, by looking at a CRUD matrix, we can use CRUD analysis (see Chapter 7) to identify potential classes on which to merge collaborations. Depending on the complexity of the merged collaboration, it may be useful in decom- posing the collaboration into multiple partitions. In this case, in addition to having collabo- rations between objects, it is possible to have collaborations among partitions. The general rule of thumb is the more messages sent between objects, the more likely the objects belong in the same partition. The fewer messages sent, the less likely the two objects belong together. Another useful approach to identifying potential partitions is to model each collabo- ration between objects in terms of clients, servers, and contracts. A client is an instance of a class that sends a message to an instance of another class for a method to be executed; a server is the instance of a class that receives the message; and a contract is the specification that formalizes the interactions between the client and server objects (see Chapters 6 and 9). This approach allows the developer to build up potential partitions by looking at the contracts that have been specified between objects. In this case, the more contracts there are between objects, the more likely that the objects belong in the same partition. The fewer contracts, the less chance there is that the two classes do belong in the same partition. Remember, the primary purpose of identifying collaborations and partitions is to determine which classes should be grouped together in design. Evolving the Analysis Models into Design Models 291 17 We describe the concept of coupling in Chapter 9. You have been working with the system for the campus housing service over the previous three chapters. In Chap- ter 5, you were asked to create a set of use cases (Your Turn 5-5) and to create a use-case diagram (Your Turn 5-6). In Chapter 6, you created a structural model (CRC cards and class diagram) for the same situation (Your Turn 6-2). In Chapter 7, you created a sequence diagram (Your Turn 7-1) and a communication diagram (Your Turn 7-2) for one of the use cases you had identified in Chapter 5. Finally, you also created a behavioral state machine for the apartment class in Chapter 7 (Your Turn 7-3). Based on the current set of functional, structural, and behavioral models portrayed in these diagrams, apply the abstraction and refinement processes to identify addi- tional abstract and concrete classes that would be useful to include in the evolving system. 8-1 Campus HousingYOUR TURN Layers Until this point in the development of our system, we have focused only on the problem domain; we have totally ignored the system environment (data management, user inter- face, and physical architecture). To successfully evolve the analysis model of the system into a design model of the system, we must add the system environment information. One use- ful way to do this, without overloading the developer, is to use layers. A layer represents an element of the software architecture of the evolving system. We have focused only on one layer in the evolving software architecture: the problem domain layer. There should be a layer for each of the different elements of the system environment (e.g., data management, user interface, physical architecture). Like partitions and collaborations, layers also can be portrayed using packages and package diagrams (see the following text). The idea of separating the different elements of the architecture into separate layers can be traced back to the MVC architecture of Smalltalk.18 When Smalltalk was first cre- ated,19 the authors decided to separate the application logic from the logic of the user inter- face. In this manner, it was possible to easily develop different user interfaces that worked with the same application. To accomplish this, they created the Model-View-Controller (MVC) architecture, where Models implemented the application logic (problem domain) and Views and Controllers implemented the logic for the user interface. Views handled the output and Controllers handled the input. Because graphical user interfaces were first developed in the Smalltalk language, the MVC architecture served as the foundation for virtually all graphical user interfaces that have been developed today (including the Mac interfaces, the Windows family, and the various Unix-based GUI environments). Based on Smalltalk’s innovative MVC architecture, many different software layers have been proposed.20 Based on these proposals, we suggest the following layers on which to base software architecture: foundation, problem domain, data management, human–computer interaction, and physical architecture (see Figure 8-12). Each layer limits the types of classes that can exist on it (e.g., only user interface classes may exist on the human–computer inter- action layer). The following provides a short description of each layer. 292 Chapter 8 Moving on to Design 18 See S. Lewis, The Art and Science of Smalltalk: An Introduction to Object-Oriented Programming Using Visual- Works (Englewood Cliffs, NJ: Prentice Hall, 1995). 19 Smalltalk was first invented in the early 1970s by a software-development research team at Xerox PARC. It intro- duced many new ideas into the area of programming languages (e.g., object orientation, windows-based user interfaces, reusable class library, and the idea of a development environment). In many ways, Smalltalk is the father (or mother) of all object-based and object-oriented languages, such as Visual Basic, C++, and Java. 20 For example, Problem Domain, Human Interaction, Task Management, and Data Management (P. Coad and E. Yourdon, Object-Oriented Design [Englewood Cliffs, NJ: Yourdon Press, 1991)]; Domain, Application, and Interface (I. Graham, Migrating to Object Technology [Reading, MA: Addison-Wesley, 1994)]; Domain, Service, and Presentation [C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design (Englewood Cliffs, NJ: Prentice Hall, 1998)]; Business,View, and Access [A. Bahrami, Object-Oriented Systems Development using the Uni- fied Modeling Language (New York: McGraw-Hill, 1999)]; Application-Specific, Application-General, Middleware, System-Software [I. Jacobson, G. Booch, and J. Rumbaugh, The Unified Software Development Process (Reading, MA: Addison-Wesley, 1999)]; and Foundation, Architecture, Business, and Application [M. Page-Jones, Fundamentals of Object-Oriented Design in UML (Reading, MA: Addison-Wesley, 2000)]. Layers Examples Relevant Chapters Foundation Date, Enumeration 8, 9 Problem Domain Employee, Customer 5, 6, 7, 8, 9 Data Access DataInputStream, 9, 10 and Management FileInputStream Human–Computer Interaction Button, Panel 9, 11 Physical Architecture ServerSocket, URLConnection 9, 12 FIGURE 8-12 Layers and Sample Classes Foundation The foundation layer is, in many ways, a very uninteresting layer. It contains classes that are necessary for any object-oriented application to exist. They include classes that represent fundamental data types (e.g., integers, real numbers, characters, strings), classes that represent fundamental data structures, sometimes referred to as container classes (e.g., lists, trees, graphs, sets, stacks, queues), and classes that represent useful abstractions, some- times referred to as utility classes (e.g., date, time, money). Today, the classes found on this layer are typically included with the object-oriented development environments. Problem Domain The problem-domain layer is what we have focused our attention on up until now. At this stage of the development of our system, we will need to further detail the classes so that it will be possible to implement them in an effective and efficient man- ner. Many issues need to be addressed when designing classes, no matter on which layer they appear. For example, there are issues related to factoring, cohesion and coupling, con- nascence, encapsulation, proper use of inheritance and polymorphism, constraints, con- tract specification, and detailed method design. These issues are discussed in Chapter 9. Data Management The data management layer addresses the issues involving the persis- tence of the objects contained in the system. The types of classes that appear in this layer deal with how objects can be stored and retrieved. The classes contained in this layer allow the problem domain classes to be independent of the storage utilized and, hence, increase the portability of the evolving system. Some of the issues related to this layer include choice of the storage format (such as relational, object/relational, and object databases) and stor- age optimization (such as clustering and indexing). A complete description of all the issues related to the data management layer is beyond the scope of this book.21 However, we do present the fundamentals in Chapter 10. Human–Computer Interaction The human–computer interaction layer contains classes associated with the View and Controller idea from Smalltalk. The primary purpose of this layer is to keep the specific user interface implementation separate from the problem domain classes. This increases the portability of the evolving system. Typical classes found on this layer include classes that can be used to represent buttons, windows, text fields, scroll bars, check boxes, drop-down lists, and many other classes that represent user inter- face elements. When it comes to designing the user interface for an application, there are many issues that must be addressed. For example, how important is consistency across different user interfaces, what about differing levels of user experience, how is the user expected to be able to navigate through the system, what about help systems and online manuals, what types of input elements should be included (e.g., text box, radio buttons, check boxes, sliders, drop-down list boxes, etc.), and what types of output elements should be included (e.g., text, tables, graphs, etc.)? Like the data management layer, a complete description of all the issues related to human–computer interaction is beyond the scope of this book.22 However from the user’s perspective, the user interface is the system. As such, we present the basic issues in user interface design in Chapter 11. Evolving the Analysis Models into Design Models 293 21 There are many good database design books that are relevant to this layer; see, for example, F. R. McFadden, J. A. Hoffer, Mary B. Prescott, Modern Database Management, 4th ed. (Reading, MA: Addison-Wesley, 1998); M. Blaha and W. Premerlani, Object-Oriented Modeling and Design for Database Applications (Englewood Cliffs, NJ: Prentice Hall, 1998); and R. J. Muller, Database Design for Smarties: Using UML for Data Modeling (San Francisco: Morgan Kaufmann, 1999). 22 One of the best books on user interface design is B. Schheiderman, Designing the User Interface: Strategies for Effective Human Computer Interaction, 3rd ed. (Reading, MA: Addison-Wesley, 1998). Physical Architecture The physical architecture layer addresses how the software will execute on specific computers and networks. As such, this layer includes classes that deal with communication between the software and the computer’s operating system and the network. For example, classes that address how to interact with the various ports on a spe- cific computer are included in this layer. This layer also includes classes that interact with so-called middleware applications, such as the OMG’s CORBA and Microsoft’s DCOM and .NET architectures that handle distributed objects. Unlike the foundation layer, there are many design issues that must be addressed before choosing the appropriate set of classes for this layer. These design issues include the choice of a computing or network architecture (such as the various client-server architec- tures), the actual design of a network, hardware and server software specification, global/international issues (such as multilingual requirements), and security issues. Like the data management and human–computer interaction layers, a complete description of all the issues related to the physical architecture is beyond the scope of this book. However, we do present the basic issues in Chapter 12. PACKAGES AND PACKAGE DIAGRAMS In UML, collaborations, partitions, and layers can be represented by a higher-level con- struct: a package.23 A package is a general construct that can be applied to any of the ele- ments in UML models. In Chapter 5, we introduced the idea of packages as a way to group use cases together to make the use-case diagrams easier to read and to keep the models at a reasonable level of complexity. In Chapters 6 and 7, we did the same thing for class and communication diagrams, respectively. In this section we describe a package diagram: a dia- gram composed only of packages. A package diagram is effectively a class diagram that only shows packages. The symbol for a package is similar to a tabbed folder (see Figure 8-13). Depending on where a package is used, packages can participate in different types of relationships. For example, in a class diagram, packages represent groupings of classes. Therefore, aggregation and association relationships are possible. In a package diagram, it is useful to depict a new relationship, the dependency relationship. A dependency relationship is portrayed by a dashed arrow (see Figure 8-13). A dependency 294 Chapter 8 Moving on to Design A package: ■ Is a logical grouping of UML elements ■ Is used to simplify UML diagrams by grouping related elements into a single higher-level element A dependency relationship: ■ Represents a dependency between packages, i.e., if a package is changed, the dependent package also could have to be modified. ■ Has an arrow drawn from the dependent package toward the package on which it is dependent. Package FIGURE 8-13 Syntax for Package Diagram 23 This discussion is based on material in Chapter 7 of M. Fowler with K. Scott, UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed. (Reading, MA: Addison-Wesley, 2004). relationship represents the fact that a modification dependency exists between two packages. That is, it is possible that a change in one package potentially could cause a change to be required in another package. Figure 8-14 portrays the dependencies among the different lay- ers (foundation, problem domain, data management, human–computer interaction, and physical architecture). For example, if a change occurs in the problem domain layer, it most likely will cause changes to occur in the human–computer interaction, physical architecture, and data management layers. Notice that these layers “point to” the problem domain layer; as such, they are dependent on it. However, the reverse is not true.24 At the class level, there could be many causes for dependencies among classes. For example, if the protocol for a method is changed, then this causes the interface for all objects of this class to change. Therefore, all classes that have objects that send messages to the instances of the modified class may have to be modified. Capturing dependency rela- tionships among the classes and packages helps the organization in maintaining object- oriented information systems. As already stated, collaborations, partitions, and layers are modeled as packages in UML. Furthermore, collaborations are normally factored into a set of partitions, which are typically placed on a layer. In addition, partitions can be composed of other partitions. Also, it is possible to have classes in partitions, which are contained in another partition, which is placed on a layer. All these groupings are represented using packages in UML. Remember that a package is simply a generic, grouping construct used to simplify UML models through the use of composition.25 A simple package diagram, based on the appointment system example from the previ- ous chapters, is shown in Figure 8-15. This diagram portrays only a very small portion of the entire system. In this case, we see that the Patient UI, Patient-DAM, and Patient Table Packages and Package Diagrams 295 FIGURE 8-14 Package Diagram of Dependency Relation- ships among Layers Human–Computer Interaction Problem Domain Physical Architecture Data Management Foundation 24 A useful side effect of the dependencies among the layers is that the project manager can divide the project team up into separate subteams: one for each design layer. This is possible because each of the design layers is depen- dent on the problem domain layer, which has been the focus of analysis. In design, the team can gain some pro- ductivity-based efficiency by working on the different layer designs in parallel. 25 For those familiar with traditional approaches, such as structured analysis and design, packages serve a similar purpose as the leveling and balancing processes used in data flow diagramming. classes depend on the Patient class. Furthermore, the Patient-DAM class depends on the Patient Table class. The same can be seen with the classes dealing with the actual appoint- ments. By isolating the Problem Domain classes (such as the Patient and Appt classes) from the actual object persistence classes (such as the Patient Table and Appt Table classes) through the use of the intermediate Data Management classes (Patient-DAM and Appt- DAM classes), we isolate the Problem Domain classes from the actual storage medium.26 This greatly simplifies the maintenance and increases the reusability of the Problem Domain classes. Of course, in a complete description of a real system, there would be many more dependencies. 296 Chapter 8 Moving on to Design HCI Layer Appt Sys UI Patient UI Appt UI PD Layer Appt Sys Patient Appt DM Layer Patient-DAM Appt-DAM Patient Table Appt TableFIGURE 8-15 Partial Package Diagram of the Appointment System 26 These issues are described in more detail in Chapter 10. Identifying Packages and Creating Package Diagrams In this section, we describe a simple five-step process to create package diagrams (see Fig- ure 8-16). The first step is to set the context for the package diagram. Remember, packages can be used to model partitions and/or layers. Revisiting the appointment system again, let’s set the context as the problem domain layer. The second step is to cluster the classes together into partitions based on the relation- ships that the classes share. The relationships include generalization, aggregation, the vari- ous associations, and the message sending that takes place between the objects in the system. To identify the packages in the appointment system, we should look at the differ- ent analysis models [e.g., the class diagram (see Figure 6-2), the communication diagrams (see Figure 7-5)], and the CRUD matrix (see Figure 7-14). Classes in a generalization hier- archy should be kept together in a single partition. The third step is to place the clustered classes together in a partition and model the partitions as packages. Figure 8-17 portrays five packages: PD Layer, Person Pkg, Patient Pkg, Appt Pkg, and Treatment Pkg. The fourth step is to identify the dependency relationships among the packages. In this case, we review the relationships that cross the boundaries of the packages to uncover potential dependencies. In the appointment system, we see association relationships that connect the Person Pkg with the Appt Pkg (via the association between the Doctor class and the Appointment class), and the Patient Pkg, which is contained within the Person Pkg, with the Appt Pkg (via the association between the Patient and Appointment classes) and the Treatment Pkg (via the association between the Patient and Symptom classes). The fifth step is to place the dependency relationships on the evolved package diagram. In the case of the Appointment system, there are dependency relationships between the Person Pkg and the Appt Pkg and the Person Pkg and the Treatment Pkg. To increase the understandability of the dependency relationships among the different packages, a pure package diagram that shows only the dependency relationships among the packages can be created (see Figure 8-18). Verifying and Validating Package Diagrams Like all the previous models, package diagrams need to be verified and validated. In this case, the package diagrams were derived primarily from the class diagram, the communi- cations diagrams, and the CRUD matrix. Only two areas need to be reviewed. Packages and Package Diagrams 297 1. Set the context. 2. Cluster classes together based on shared relationships. 3. Model clustered classes as a package. 4. Identify dependency relationships among packages. 5. Place dependency relationships between packages. FIGURE 8-16 Steps for Identifying Packages and Building Package Diagram Based on the factoring of the evolving system in Your Turn 8-1, identify a set of partitions for the Problem Domain layer and model them in a package diagram. 8-2 Campus HousingYOUR TURN PD Layer Person Pkg Appt Package Treatment Pkg Patient PkgPerson -lastname -firstname -address -phone -birthdate -/ age Administrative Staff Employee Nurse Health Team Doctor Symptom Illness 0..* 0..* 0..* 1..* 0..* 0..* 1..* 1..* 1 1 1 0..1 0..* 1 0..1 Patient -amount -insurance carrier +make appointment() +calculate last visit() +change status() +provides medical history() Medical History -heart disease -high blood pressure -diabetes -alergies Appointment -time -date -reason -name -description +cancel without notice() Bill -date -amount -purpose +generate cancellation fee() 0..*0..* ** +primary insurance carrier Treatment medication instructions symptom severity provides has scheduled schedules leads to suffer FIGURE 8-17 Package Diagram of the PD Layer for the Appointment System 298 First, the identified packages must make sense from a problem domain point of view. For example, in the context of an appointment system, the packages in Figure 8-18 (Per- son, Patient, Appt, and Treatment) seem to be reasonable. Second, all dependency relationships must be based on message-sending relationships on the communications diagram, associations on the class diagram, and cell entries in the CRUD matrix. In the case of the appointment system, the identified dependency relation- ships are reasonable (see Figures 6-2, 7-5, 7-14, and 8-18). DESIGN STRATEGIES Until now, we have assumed that the system will be built and implemented by the pro- ject team; however, there are actually three ways to approach the creation of a new system: developing a custom application in-house, buying a packaged system and cus- tomizing it, and relying on an external vendor, developer, or service provider to build the system. Each of these choices has its strengths and weaknesses, and each is more appropriate in different scenarios. The following sections describe each design choice in turn, and then we present criteria that you can use to select one of the three approaches for your project. Custom Development Many project teams assume that custom development, or building a new system from scratch, is the best way to create a system. For one thing, teams have complete control over the way the system looks and functions. Furthermore, custom development also allows developers to be flexible and creative in the way they solve business problems. Additionally, a custom application would be easier to change to include components that take advantage of current technologies that can support such strategic efforts. Building a system in-house also builds technical skills and functional knowledge within the company. As developers work with business users, their understanding of the Design Strategies 299 PD Layer Person Pkg Appt Pkg Treatment Pkg Patient Pkg FIGURE 8-18 Overview Package Diagram of the PD Layer for the Appointment System business grows and they become better able to align IS with strategies and needs. These same developers climb the technology learning curve so that future projects applying sim- ilar technology require much less effort. Custom application development, however, also includes a dedicated effort that involves long hours and hard work. Many companies have a development staff that already is overcommitted to filling huge backlogs of systems requests, and they just do not have time for another project. Also, a variety of skills—technical, interpersonal, functional, pro- ject management, and modeling—all have to be in place for the project to move ahead smoothly. IS professionals, especially highly skilled individuals, are quite difficult to hire and retain. The risks associated with building a system from the ground up can be quite high, and there is no guarantee that the project will succeed. Developers could be pulled away to work on other projects, technical obstacles could cause unexpected delays, and the business users could become impatient with a growing timeline. Packaged Software Many business needs are not unique, and because it makes little sense to reinvent the wheel, many organizations buy packaged software that has already been written rather than devel- oping their own custom solution. In fact, there are thousands of commercially available software programs that have already been written to serve a multitude of purposes. Think about your own need for a word processor—did you ever consider writing your own word processing software? That would be very silly considering the number of good software packages available that are relatively inexpensive. Similarly, most companies have needs that can be met quite well by packaged software, such as payroll or accounts receivable. It can be much more efficient to buy programs that 300 Chapter 8 Moving on to Design I worked with a large financial institution in the southeast that suffered serious financial losses several years ago. A new CEO was brought in to change the strategy of the organization to being more “customer focused.” The new direction was quite innovative, and it was determined that custom systems, including a data warehouse, would have to be built to support the new strategic efforts. The prob- lem was that the company did not have the in-house skills for these kinds of custom projects. The company now has one of the most successful data-warehouse implementations because of its willing- ness to use outside skills and its focus on project manage- ment. To supplement skills within the company, eight sets of external consultants, including hardware vendors, sys- tem integrators, and business strategists, were hired to take part and transfer critical skills to internal employees. An in- house project manager coordinated the data-warehouse implementation full-time, and her primary goals were to set clearly expectations, define responsibilities, and com- municate the interdependencies that existed among the team members. This company shows that successful custom devel- opment can be achieved, even when the company may not start off with the right skills in-house. But, this kind of project is not easy to pull off—it takes a talented project manager to keep the project moving along and to transi- tion the skills to the right people over time. —Barbara Wixom Questions 1. What are the risks in building a custom system without the right technical expertise? 2. Why did the company select a project manager from within the organization? 3. Would it have been better to hire an external pro- fessional project manager to coordinate the project? 8-A Building a Custom System—with Some HelpCONCEPTS IN ACTION have already been created, tested, and proven, and a packaged system can be bought and installed in a relatively short period of time, when compared with a custom system. Plus, packaged systems incorporate the expertise and experience of the vendor who created the software. Packaged software can range from reusable components (such as ActiveX and Javabeans) to small, single-function tools (such as the shopping cart program) to huge, all-encompassing systems such as enterprise resource planning (ERP) applications that are installed to automate an entire business. Implementing ERP systems is a process in which large organizations spend millions of dollars installing packages by companies such as SAP,PeopleSoft, Oracle, and Baan and then change their businesses accordingly. Installing ERP software is much more difficult than installing small application packages because benefits can be harder to realize and problems are much more serious. One problem is that companies buying packaged systems must accept the func- tionality that is provided by the system, and rarely is there a perfect fit. If the packaged system is large in scope, its implementation could mean a substantial change in the way the company does business. Letting technology drive the business can be a dangerous way to go. Most packaged applications allow for customization, or the manipulation of system parameters to change the way certain features work. For example, the package might have a way to accept information about your company or the company logo that would then appear on input screens. Or, an accounting software package could offer a choice of vari- ous ways to handle cash flow or inventory control so that it can support the accounting practices in different organizations. If the amount of customization is not enough and the software package has a few features that don’t quite work the way the company needs it to work, the project team can create workarounds. A workaround is a custom-built add-on program that interfaces with the packaged application to handle special needs. It can be a nice way to create needed functionality that does not exist in the software package. But, workarounds should be a last resort for several reasons. First, workarounds are not supported by the vendor who supplied the packaged software, so upgrades to the main system may make the workaround ineffective. Also, if problems arise, vendors have a tendency to blame the workaround as the culprit and refuse to provide support. Although choosing a packaged software system is simpler than custom development, it too can benefit from following a formal methodology, just as if a custom application were being built. Systems integration refers to the process of building new systems by combining packaged software, existing legacy systems, and new software written to integrate these together. Many consulting firms specialize in systems integration, so it is not uncom- mon for companies to select the packaged software option and then outsource the inte- gration of a variety of packages to a consulting firm. (Outsourcing is discussed in the next section). The key challenge in systems integration is finding ways to integrate the data produced by the different packages and legacy systems. Integration often hinges on taking data pro- duced by one package or system and reformatting it for use in another package or system. The project team starts by examining the data produced by and needed by the different packages or systems and identifying the transformations that must occur to move the data from one to the other. In many cases, this involves “fooling” the different packages or sys- tems into thinking that the data were produced by an existing program module that the package or system expects to produce the data rather than the new package/system that is being integrated. Design Strategies 301 A third approach is through the use of an object wrapper.27 An object wrapper is essen- tially an object that “wraps around” a legacy system, enabling an object-oriented system to send messages to the legacy system. Effectively, object wrappers create an application pro- gram interface (API) to the legacy system. The creation of an object wrapper allows the protection of the corporation’s investment in the legacy system. Outsourcing The design choice that requires the least amount of in-house resources is outsourcing—hiring an external vendor, developer, or service provider to create the system. Outsourcing has become quite popular in recent years. Some estimate that as many as 50 percent of companies with IT budgets of more than $5 million are currently outsourcing or evaluating the approach. According to Wikipedia,“outsourcing involves transferring or sharing management con- trol and/or decision-making of a business function to an outside supplier, which involves a degree of two-way information exchange, coordination and trust between the outsourcer and its client.” From an IT perspective, IT outsourcing can include things such as (1) hiring con- sultants to solve a specific problem, (2) hiring contract programmers to implement a solu- tion, (3) hiring a firm to manage the IT function and assets of a company, or (4) actually outsourcing the entire IT function to a separate firm. Today, through the use of Application Service Providers (ASPs) and Web Services technology, it is possible to use a pay-as-you-go approach for a software package.28 Essentially, IT outsourcing involves hiring a third party to perform some IT function that traditionally would be performed in-house. There can be great benefit to having someone else develop a company’s system. They may be more experienced in the technology or have more resources, such as experienced programmers. Many companies embark upon outsourcing deals to reduce costs, whereas others see it as an opportunity to add value to the business. 302 Chapter 8 Moving on to Design Pharmaceutical companies are generally heavily regu- lated companies. It may take years for a new drug to make it to the marketplace because of time for the development phase, highly monitored testing, and final approval by the Food and Drug Administration (FDA). Once in the market- place, other companies can try to produce generic drugs that seem to be compatible with the name-brand drug. Occasionally an approved drug, some years into its life span, gets scrutiny for higher-than-expected side effects. For example, a drug that is effective in lowering cholesterol may also cause the side effect of an increased chance for cataract growth that was not discovered during the initial testing and approval cycle. Data are collected on all aspects of clinical trials and from the marketplace, but some relationships are just harder to find. Questions 1. Is there a particular system approach to being able to collect and analyze data from a mountain of data? 2. If you were building a strategic planning system for tracking a drug from proposal through development and testing and into the marketplace, how would you approach it? 3. What requirements might be necessary to build such a system? 8-B Collecting Data for the Long TermCONCEPTS IN ACTION 27 Ian Graham, Object-Oriented Methods: Principles & Practice, 3rd ed. (Reading, MA: Addison-Wesley, 2001). 28 For an economic explanation of how this could work, see H. Baetjer, Software as Capital: An Economic Perspective on Software Engineering (Los Alamitos, CA: IEEE Computer Society Press, 1997). For whatever reason, outsourcing can be a good alternative for a new system. However, it does not come without costs. If you decide to leave the creation of a new system in the hands of someone else, you could compromise confidential information or lose control over future development. In-house professionals are not benefiting from the skills that could be learned from the project; instead the expertise is transferred to the outside organization. Ultimately, important skills can walk right out the door at the end of the contract. Furthermore, when off- shore outsourcing is being considered, we must also be cognizant of language issues, time-zone differences, and cultural differences (for example, acceptable business practices as understood in one country that may be unacceptable in another). All these concerns, if not dealt with prop- erly, can prevail over any advantage that outsourcing or offshore outsourcing could realize. However, most risks can be addressed if a company decides to outsource, but two are particularly important. First, the company must thoroughly assess the requirements for the project—a company should never outsource what is not understood. If rigorous planning and analysis has occurred, then the company should be well aware of its needs. Second, the company should carefully choose a vendor, developer, or service with a proven track record with the type of system and technology that its system needs. Three primary types of contracts can be drawn to control the outsourcing deal. A time-and-arrangements contract is very flexible because a company agrees to pay for what- ever time and expenses are needed to get the job done. Of course, this agreement could result in a large bill that exceeds initial estimates. This works best when the company and the outsourcer are unclear about what it is going to take to finish the job. A company will pay no more than expected with a fixed-price contract because if the outsourcer exceeds the agreed-upon price, it will have to absorb the costs. Outsourcers are much more careful about defining requirements clearly up front, and there is little flexibil- ity for change. The type of contract gaining in popularity is the value-added contract, whereby the outsourcer reaps some percentage of the completed system’s benefits. The company has very little risk in this case, but it must expect to share the wealth once the system is in place. Creating fair contracts is an art because flexibility must be carefully balanced with clearly defined terms. Often needs change over time. As such, the contract should not be so specific and rigid that alterations can’t be made. Think about how quickly technology like the World Wide Web changes. It is difficult to foresee how a project may evolve over a long period of time. Short-term contracts help leave room for reassessment if needs change or if relationships are not working out the way both parties expected. In all cases, the rela- tionship with the outsourcer should be viewed as a partnership where both parties benefit and communicate openly. Managing the outsourcing relationship is a full-time job. Thus, someone needs to be assigned full-time to manage the outsourcer, and the level of that person should be appro- priate for the size of the job (a multimillion dollar outsourcing engagement should be han- dled by a high-level executive). Throughout the relationship, progress should be tracked and measured against predetermined goals. If a company does embark upon an outsourc- ing design strategy, it should be sure to get adequate information. Many books have been written that provide much more detailed information on the topic.29 Figure 8-19 summa- rizes some guidelines for outsourcing. Design Strategies 303 29 For more information on outsourcing, we recommend M. Lacity and R. Hirschheim, Information Systems Out- sourcing: Myths, Metaphors, and Realities (New York, NY: Wiley, 1993); L. Willcocks and G. Fitzgerald, A Business Guide to Outsourcing Information Technology (London: Business Intelligence, 1994); E. Carmel, Offshoring Infor- mation Technology: Sourcing and Outsourcing to a Global Workforce (Cambridge, UK: Cambridge University Press, 2005); J. K Halvey and B. M. Melby, Information Technology Outsourcing Transactions: Process, Strategies, and Con- tracts, 2nd Ed. (Hoboken, NJ: Wiley, 2005); and T. L. Friedman, The World is Flat: A Brief History of the Twenty- First Century, Updated and Expanded Edition (New York: Farrar, Straus, and Giroux, 2006). 304 Chapter 8 Moving on to Design Outsourcing Guidelines • Keep the lines of communication open between you and your outsourcer. • Define and stabilize requirements before signing a contact. • View the outsourcing relationship as a partnership. • Select the vendor, developer or service provider carefully. • Assign a person to managing the relationship. • Don’t outsource what you don’t understand. • Emphasize flexible requirements, long-term relationships and short-term contracts. FIGURE 8-19 Outsourcing Guidelines Value-added contracts can be quite rare—and very dra- matic. They exist when a vendor is paid a percentage of revenue generated by the new system, which reduces the up-front fee, sometimes to zero. The City of Chicago and EDS (a large consulting and systems integration firm) agreed to reengineer the process by which the city col- lects the fines on 3.6 million parking tickets per year and thus signed a landmark deal of this type three years ago. At the time, because of clogged courts and administrative problems, the city collected on only about 25 percent of all tickets issued. It had a $60 million backlog of uncol- lected tickets. Dallas-based EDS invested an estimated $25 mil- lion in consulting and new systems in exchange for the right to up to 26 percent of the uncollected fines, a base processing fee for new tickets, and software rights. To date, EDS has taken in well over $50 million on the deal, analysts say. The deal has come under some fire from various quarters as an example of an organization giving away too much in a risk-reward-sharing deal. City officials, however, counter that the city has pulled in about $45 million in previously uncollected fines and has improved its collection rate to 65 percent with little up-front investment. Source: Jeff Moad. “Outsourcing? Go out on the limb together.” pp. 58–61, Vol. 41, No. 2. Datamation, February 1, 1995. Question Do you think the City of Chicago got a good deal from this arrangement? Why or why not? 8-C EDS Value-Added ContractCONCEPTS IN ACTION Selecting a Design Strategy Each of the design strategies just discussed has its strengths and weaknesses, and no one strategy is inherently better than the others. Thus, it is important to understand the strengths and weaknesses of each strategy and when to use each. Figure 8-20 summarizes the characteristics of each strategy. Business Need If the business need for the system is common and technical solutions already exist in the marketplace that can meet the business need of the system, it makes lit- tle sense to build a custom application. Packaged systems are good alternatives for common business needs. A custom alternative must to be explored when the business need is unique or has special requirements. Usually, if the business need is not critical to the company, then outsourcing is the best choice—someone outside of the organization can be respon- sible for the application development. In-house Experience If in-house experience exists for all the functional and technical needs of the system, it will be easier to build a custom application than if these skills do not exist. A packaged system may be a better alternative for companies that do not have the technical skills to build the desired system. For example, a project team that does not have Web commerce technology skills may want to acquire a Web commerce package that can be installed without many changes. Outsourcing is a good way to bring in outside experi- ence that is missing in-house so that skilled people are in charge of building a system. Project Skills The skills that are applied during projects are either technical (e.g., Java, SQL) or functional (e.g., electronic commerce), and different design alternatives are more viable, depending on how important the skills are to the company’s strategy. For example, if certain functional and technical expertise that relate to Internet sales applications and Web commerce application development are important to an organization because it expects the Internet to play an important role in its sales over time, then it makes sense for the company to develop Web commerce applications in-house, using company employees, so that the skills can be developed and improved. On the other hand, some skills, such as network security, may be either beyond the technical expertise of employees or not of interest to the company’s strategists—it is just an operational issue that needs to be addressed. In this case, packaged systems or outsourcing should be considered so internal employees can focus on other business-critical applications and skills. Project Management Custom applications require excellent project management and a proven methodology. There are so many things, such as funding obstacles, staffing holdups, and overly demanding business users, that can push a project offtrack. Therefore, the pro- ject team should choose to develop a custom application only if it is certain that the under- lying coordination and control mechanisms will be in place. Packaged and outsourcing alternatives also need to be managed; however, they are more shielded from internal obsta- cles because the external parties have their own objectives and priorities (e.g., it may be eas- ier for an outside contractor to say no to a user than it is for a person within the company). The latter alternatives typically have their own methodologies, which can benefit compa- nies that do not have an appropriate methodology to use. Time Frame When time is a factor, the project team should probably start looking for a system that is already built and tested. In this way, the company will have a good idea of how long the package will take to put in place and what the final result will contain. The time frame for custom applications is hard to pin down, especially when you consider how Design Strategies 305 Use Custom Use a Packaged Use Outsourcing Development When… System When… When… Business Need The business need is unique. The business need is common. The business need is not core to the business. In-house Experience In-house functional and In-house functional In-house functional or technical technical experience exists. experience exists. experience does not exist. Project Skills There is a desire to The skills are not strategic. The decision to outsource is a build in-house skills. strategic decision. Project Management The project has a highly The project has a project The project has a highly skilled skilled project manager manager who can coordinate project manager at the level and a proven methodology. vendor’s efforts. of the organization that matches the scope of the outsourcing deal. Time frame The time frame is flexible. The time frame is short. The time frame is short or flexible. FIGURE 8-20 Selecting a Design Strategy many projects end up missing important deadlines. If a company must choose the custom development alternative and the time frame is very short, it should consider using tech- niques such as timeboxing to manage this problem. The time to produce a system using outsourcing really depends on the system and the outsourcer’s resources. If a service provider has services in place that can be used to support the company’s needs, then a busi- ness need could be implemented quickly. Otherwise, an outsourcing solution could take as long as a custom development initiative. DEVELOPING THE ACTUAL DESIGN Once the project team has a good understanding of how well each design strategy fits with the project’s needs, it must begin to understand exactly how to implement these strategies. For example, what tools and technology would be used if a custom alternative were selected? What vendors make packaged systems that address the project needs? What ser- vice providers would be able to build this system if the application were outsourced? This information can be obtained from people working in the IS department and from recom- mendations by business users. Or, the project team can contact other companies with sim- ilar needs and investigate the types of systems that they have put in place. Vendors and consultants usually are willing to provide information about various tools and solutions in the form of brochures, product demonstrations, and information seminars. However, a company should be sure to validate the information it receives from vendors and consul- tants. After all, they are trying to make a sale. Therefore, they may stretch the capabilities of their tool by focusing on only the positive aspects of the tool while omitting the tool’s drawbacks. It is likely that the project team will identify several ways that a system could be con- structed after weighing the specific design options. For example, the project team may have found three vendors that make packaged systems that potentially could meet the project’s needs. Or, the team may be debating over whether to develop a system using Java as a devel- opment tool and the database management system from Oracle or to outsource the devel- opment effort to a consulting firm such as Accenture or American Management Systems. Each alternative will have pros and cons associated with it that need to be considered, and only one solution can be selected in the end. Alternative Matrix An alternative matrix can be used to organize the pros and cons of the design alternatives so that the best solution will be chosen in the end. This matrix is created using the same steps as the feasibility analysis, which was presented in Chapter 2. The only difference is that the alternative matrix combines several feasibility analyses into one matrix so that the alternatives can easily be compared. An alternative matrix is a grid that contains the technical, 306 Chapter 8 Moving on to Design Suppose that your university is interested in creating a new course registration system that can support Web- based registration. What should the university consider when determining whether to invest in a custom, pack- aged, or outsourced system solution? 8-3 Choose a Design StrategyYOUR TURN budget, and organizational feasibilities for each system candidate, pros and cons associated with adopting each solution, and other information that is helpful when making compar- isons. Sometimes weights are provided for different parts of the matrix to show when some criteria are more important to the final decision. To create the alternative matrix, draw a grid with the alternatives across the top and different criteria (e.g., feasibilities, pros, cons, and other miscellaneous criteria) along the side. Next, fill in the grid with detailed descriptions about each alternative. This becomes a useful document for discussion because it clearly presents the alternatives being reviewed and comparable characteristics for each one. Suppose that a company is thinking about implementing a packaged financial system such as Oracle E-Business Financials or Microsoft’s Dynamics GP, but there is not enough expertise in-house to be able to create a thorough alternative matrix. This situation is quite common—often the alternatives for a project are unfamiliar to the project team, so outside expertise is needed to provide information about the alternatives’ criteria. One helpful tool is the request for proposals (RFP). An RFP is a document that solicits proposals to provide the alternative solutions from a vendor, developer, or service provider. Basically, an RFP explains the system that a company is trying to build and the criteria that it will use to select a system. Vendors then respond by describing what it would mean for them to be a part of the solution. They communicate the time, the cost, and exactly how their product or services will address the needs of the project. There is no formal way to write an RFP, but it should include basic information such as the description of the desired system, any special technical needs or circumstances, eval- uation criteria, instructions for how to respond, and the desired schedule. An RFP can be a very large document (i.e., hundreds of pages) because companies try to include as much detail as possible about their needs so that the respondent can be just as detailed in the solution that would be provided. Thus, RFPs typically are used for large projects rather than small ones because they take a lot of time to create; even more time and effort are needed for vendors, developers, and service providers to develop high-quality responses— only a project with a fairly large price tag would be worth the time and cost to develop a response for an RFP. A less-effort-intensive tool is a request for information (RFI) that includes the same for- mat as the RFP. The RFI is shorter and contains less-detailed information about a com- pany’s needs, and it requires general information from respondents that communicates the basic services that they can provide. The final step, of course, is to decide which solution to design and implement. The decision should be made by a combination of business users and technical profession- als after the issues involved with the different alternatives are well understood. Once the decision is finalized, design can continue as needed, based on the selected alternative. Developing the Actual Design 307 Suppose you have been assigned the task of selecting a CASE tool for your class to use for a semester project. Using the Web or other reference resources, select three CASE tools (e.g., ArgoUML, IBM’s Rational Rose, or Visual Paradigm). Create an alternative matrix that can be used to compare the three software products so that a selection decision can be made. 8-4 Alternative MatrixYOUR TURN APPLYING THE CONCEPTS AT CD SELECTIONS In the previous installments of the CD Selections Case, the CD Selections Internet Sales System has been described: ■ In Chapter 4, the functional and nonfunctional requirements for the system were given (see Figure 4-15). ■ In Chapter 5, the functional model was given (see Figures 5-14 through 5-19). ■ In Chapter 6, the structural model was given (see Figures 6-15 through 6-18). ■ In Chapter 7 the behavioral models were developed for the Places Order use case and the Order class (Figures 7-15 through 7-19). In this section of the case, we see how Alec and his team prepared to move from an analy- sis, or problem-domain, orientation to a design, or solution-domain, orientation. Follow- ing, we will see that to get ready for this transition, Alec and his team first create a package diagram to partition the problem-domain layer. Next, they go through a verification and validation of all of the analysis models; finally, they choose a design strategy to develop the actual design. As in the previous installments of the case, we deal only with the Places Order use case. However, object-oriented systems development is holistic. Therefore, to be com- plete, Alec and company had to finish all the previous Your Turns associated with the case. Packages and Package Diagrams At this point in the development of the Internet Sales System for CD Selections, Alec wanted to explicitly partition the evolving system. To do this, Alec decided to use packages to represent both the layers and partitions in each layer. Once he made this decision, he chose to follow the steps for identifying packages and building package diagrams in Figure 8-9. Because, at this point in the development, the team has been focusing only on analy- sis models, Alec decided that the team should concentrate on identifying only potential partitions on the Problem Domain Layer. The second step, cluster classes together, was accomplished by reviewing the relation- ships among the different classes (see Figures 6-18, 7-17, and 7-20). Through this review process, the team saw that there were generalization, aggregation, various associations, and message-sending relationships. They also saw the entries in the CRUD matrix. Because they understood that classes in a generalization hierarchy should be kept together, they clustered the Customer, Individual, and Organization classes together to form a partition. Brian pointed out that it is also preferred to keep classes together that participate in aggregation relationships. Based on aggregation relationships, they clustered the Mkt Info, Review, Artist Info, and Sample Clip classes together in a partition. Based on the association rela- tionship and the message-sending pattern of activity between the CD and Mkt Info classes, Anne suggested that they should be in the same partition. Furthermore, because the Ven- dor class was related only to the CD class, Alec suggested that they be placed in the same partition. Finally, the development team decided to place the Order and Order Item classes together and the Search Req and CD List classes together in their own partitions. The third step was to model each of these partitions as packages. Figure 8-21 shows the classes being contained in their respective packages. Observe that the Credit-Card Clear- ance Center is not currently contained in any package. Next, Alec quickly identified four associations among the different packages: the Cus- tomer Package and the Order Package, the Customer Package and the Search Package, the Order Package and the CD Package, and the Search Package and the CD Package. He also identified an association between the Credit-Card Clearance Center class and the Customer Package. Based on these associations, five dependency relationships were identified. 308 Chapter 8 Moving on to Design PD Layer Order Package CD Package Search Package Customer Package includes Results in makes consists of contains distributes checks places promotes Organizational Customer Individual Credit Card Clearance Center Order Item Review Artist Info Sample Clip CD Vendor Mkt Info Order CD ListSearch Req 1 0..1 * * * * * 1 1 1 * * * * * * * * * * * * * * FIGURE 8-21 Package Diagram of the PD of CD Selections Internet Sales System 309 The fifth and final step was to place the dependency relationships on the package diagram. Again, to increase the understandability of the dependency relationships among the different packages, Alec decided to create a pure package diagram that depicted only the highest-level packages (and in this case the Credit-Card Clearance Center class) and the dependency relationships (see Figure 8-22). Verifying and Validating the Analysis Models Upon completing the partitioning of the Problem Domain Layer, the team felt pretty good about what they had accomplished. However, based on his understanding of what was coming up next, Alec wanted to be sure that the analysis models—functional, structural, 310 Chapter 8 Moving on to Design PD Layer Customer Package Order Package Search Package CD Package Credit-Card Clearance Center FIGURE 8-22 Overview Package Diagram of the PD Layer of CD Selections Internet Sales System In previous Your Turns, you completed the functional, struc- tural, and behavioral models for the CD Selections Internet Sales System. Based on these results, create more complete package diagrams based on those created by Alec. 8-5 CD Selections Internet Sales SystemYOUR TURN behavioral—and the partitions made sense, so he decided that all the work to date needed to go through a verification and validation step. To say the least, the team was not all that excited about this. In fact, Brian pointed out that the team had been verifying and vali- dating everything as they went along. As such, he argued that this would simply be a waste of time. But, Alec prevailed. He explained that in past projects, when they had not assured the quality of the Problem Domain Layer, teams had run into significant problems. These problems included the system not solving the right problem, significant cost overruns, and the system not being delivered on time. Because this team was relatively inexperi- enced with the technology that they were about to use, Alec told the team that there was not enough slack in the workplan to run into problems related to the analysis models. He suggested that the team perform a walkthrough with the model and that they ensure all the relationships among the diagrams were fully tested (see Figures 8-2, 8-3, 8-4, 8-6, 8-8, 8-9, and 8-10). The good news was that the team had actually been very careful in developing the analysis models and they did not uncover any errors within the diagrams. Brian brought up his earlier point in an “I told you so” manner. However, Alec let him blow off a little steam and simply reminded the team that it was better to have done the verification and validation step now and not have to be sorry later. He pointed out that the other layers are mostly dependent on the Problem Domain Layer (see Figure 8-14) and any mistake not caught now could be very costly to catch later. Developing the Actual Design Once the team had verified and validated the analysis models, Alec had to decide on a design strategy. As he saw it, he had three different approaches that he could take with the new system: He could develop the entire system using development resources from CD Selections, he could buy a commercial Internet sales packaged software program (or a set of different packages and integrate them), or he could hire a consulting firm or service provider to create the system. Immediately, Alec ruled out the third option. Building Inter- net applications, especially sales systems, was important to the CD Selections’ business strategy. By outsourcing the Internet Sales System, CD Selections would not develop Inter- net application development skills and business skills within the organization. Instead, Alec decided that a custom development project using the company’s stan- dard Web development tools would be the best choice for CD Selections. In this way, the company would be developing critical technical and business skills in-house, and the pro- ject team would be able to have a high level of flexibility and control over the final prod- uct. Also, Alec wanted the new Internet Sales System to directly interface with the existing distribution system, and there was a chance that a packaged solution would not be able to integrate as well into the CD Selections environment. There was one part of the project that potentially could be handled using packaged software: the shopping cart portion of the application. Alec realized that a multitude of Applying the Concepts at CD Selections 311 At this point in time, you should go back through all of the analysis models created and verifiy and validate them using a walkthrough process. 8-6 CD Selections Internet Sales SystemYOUR TURN programs had been written and were available (at low prices) to handle a customer’s order transaction over the Web. These programs allow customers to select items for an order form, input credit-card and billing information, and finalize the order transaction. Alec believed that the project team should at least consider some of these packaged alternatives so that less time had to be spent writing a program that handled basic Web tasks; then more time could be devoted to innovative marketing ideas and custom interfaces with the distri- bution system. To help better understand some of the shopping cart programs that were available in the market and how their adoption could benefit the project, Alec created an alternative matrix that compared three different shopping cart programs with each other (see Figure 8-23). Although all three alternatives had positive points, Alec saw Alternative B (Web- Shop) as the best alternative for handling the shopping cart functionality for the new Inter- net sales system. WebShop was written in JAVA, the tool that CD Selections selected as its standard Web development language; the expense was reasonable, with no hidden or recur- ring costs; and there was a person in-house who had some positive experience with the pro- gram. Alec made a note to look into acquiring WebShop as the shopping cart program for the Internet sales system. SUMMARY Design contains many steps that guide the project team through planning out exactly how a system needs to be constructed. The requirements that were identified and the models that were created during analysis serve as the primary inputs for the design activities. In object-oriented design, the primary activity is to evolve the analysis models into design models by optimizing the problem-domain information already contained in the analysis models and adding system environment details to them. 312 Chapter 8 Moving on to Design Alternative 1: Alternative 2: Alternative 3: Shop-With-Me WebShop Shop-N-Go Technical • Developed using C: very • Developed using C and JAVA: • Developed using JAVA: would like Feasibility little C experience in-house would like to develop in-house to develop in-house JAVA skills JAVA skills • Orders sent to company • Flexible export features for • Orders saved to a number of using email files passing order information to file formats other systems Economic • $150 initial charge • $700 up front charge, • $200/year Feasibility no yearly fees Organizational • Program used by other • Program used by other retail • Brand new application: few Feasibility retail music companies music companies companies have experience with Shop-N-Go to date Other Benefits • Very simple to use • Tom in IS support has had limited, but positive experience with this program • Easy to customize Other Limitations • The interface is not easily customized FIGURE 8-23 Alternative Matrix for Shopping Cart Program Verifying and Validating the Analysis Models Before actually adding system environment details to the analysis models, the various rep- resentations need to be verified and validated. One very useful approach to test the fidelity of the representations is to perform a walkthrough in which developers walk through the representations by presenting the different models to members of the analysis team, mem- bers of the design team, and representatives of the client. The walkthrough must validate each model to be sure that the different representations within the model all agree with each other; for example, for the functional model, activity diagrams, use-case descriptions, and use-case diagrams must be consistent with each other. Furthermore, the different models (functional, structural, and behavioral) must be consistent. Finally, care must be taken dur- ing the walkthroughs to ensure that the presenter is not simply degraded and destroyed. Evolving the Analysis Models into Design Models When evolving the analysis models into design models, the analysis models: activity dia- grams, use-case descriptions, use-case diagrams, CRC cards, class and object diagrams, sequence diagrams, communication diagrams, and behavioral state machines should first be carefully reviewed. During this review, factoring, refinement, and abstraction processes can be used to polish the current models. During this polishing, it is possible that the analysis models may become overly complex. If this occurs, then the models should be partitioned based on the interactivity (message sending) and relationships (generalization, aggregation, and association) shared among the classes. The more a class has in common with another class (i.e., the more relationships shared), the more likely they belong in the same partition. The second thing to do to evolve the analysis mode is to add the system environment (physical architecture, user interface, and data access and management) information to the problem domain information already contained in the model. To accomplish this and to control the complexity of the models, layers are used. A layer represents an element of the software architecture of the system. We recommend five different layers to be used: foun- dation, physical architecture, human–computer interaction, data access and management, and problem domain. Each layer supports only certain types of classes (e.g., database manipulation classes would be allowed only on the data access and management layer). Packages and Package Diagrams A package is a general UML construct used to represent collaborations, partitions, and layers. Its primary purpose is to support the logical grouping of other UML constructs together (e.g., use cases and classes by the developer and user to simplify and increase the understandability of a UML diagram). There are instances in which a diagram that contains only packages is useful. A package diagram contains packages and dependency relationships. A dependency relationship represents the possibility of a modification dependency existing between two packages (i.e., changes in one package could cause changes in the dependent package). Identifying packages and creating a package diagram is accomplished using a five-step process. The five steps can be summed up as setting the context, clustering similar classes, placing the clustered classes into a package, identifying dependency relationships among the packages, and placing the dependency relationship on the package diagram. Design Strategies During the design phase, the project team also needs to consider three approaches to cre- ating the new system, including developing a custom application in-house, buying a pack- aged system and customizing it, and relying on an external vendor, developer, or system provider to build and/or support the system. Summary 313 Custom development allows developers to be flexible and creative in the way they solve business problems, and it builds technical and functional knowledge within the organiza- tion. But, many companies have a development staff that is already overcommitted to fill- ing huge backlogs of systems requests, and they just don’t have time to devote to a project where a system is built from scratch. It can be much more efficient to buy programs that have been created, tested, and proven, and a packaged system can be bought and installed in a relatively short period of time as compared with a custom solution. Workarounds can be used to meet the needs that are not addressed by the packaged application. The third design strategy is to outsource the project and pay an external vendor, devel- oper, or service provider to create the system. It can be a good alternative to approaching the new system; however, it does not come without costs. However, if a company decides to leave the creation of a new system in the hands of someone else, the organization could compromise confidential information or lose control over future development. Each of the design strategies discussed here has its strengths and weaknesses, and no one strategy is inherently better than the others. Thus, it is important to consider such issues as the uniqueness of business need for the system, the amount of in-house experi- ence that is available to build the system, and the importance of the project skills to the company. Also, the existence of good project management and the amount of time avail- able to develop the application play a role in the selection process. Developing the Actual Design Ultimately, the decision must be made regarding the specific type of system that needs to be designed. An alternative matrix can help make this decision by presenting feasibility information for several candidate solutions in a way in which they can be compared easily. Both the Request for Proposal and Request for Information are two ways to gather accu- rate information regarding the alternatives. 314 Chapter 8 Moving on to Design KEY TERMS A-kind-of Abstract classes Abstraction Aggregation Alternative matrix Balancing the models Class Client Collaboration Concrete classes Contract Controller CORBA Custom development Customization Data management layer Dependency relationship Design phase Enterprise resource systems (ERP) Errors Factoring Faults Fixed-price contract Foundation layer Generalization Has-parts Human–computer interaction layer Layer Maintenance oracle Message Method Model Model-View-Controller (MVC) Module Object wrapper Outsourcing Package Package diagram Packaged software Partition Physical architecture layer Presenter Problem domain layer Recorder Refinement Request for information (RFI) Request for proposals (RFP) Scribe Server Smalltalk Systems integration Test Time-and-arrangements contract Validation Value-added contract Verification View Walkthrough Workaround Exercises 315 QUESTIONS 1. What is the primary difference between an analysis model and a design model? 2. What is a walkthrough? How does it relate to verifica- tion and validation? 3. What are the different roles played during a walk- through? What are their purposes? 4. What are the relationships within the functional mod- els, structural models, and the behavioral models that need to be tested? 5. What is meant by balancing the models? 6. What are the interrelationships between the func- tional, structural, and the behavioral models that need to be tested? 7. What does factoring mean? How is it related to abstraction and refinement? 8. What is a partition? How does a partition relate to a collaboration? 9. What is a layer? Name the different layers. 10. What is a package? How are packages related to parti- tions and layers? 11. What is a dependency relationship? How do you iden- tify them? 12. What are the five steps for identifying packages and creating package diagrams? 13. What needs to be verified and validated in package diagrams? 14. What situations are most appropriate for a custom development design strategy? 15. What are some problems with using a packaged soft- ware approach to building a new system? How can these problems be addressed? 16. Why do companies invest in ERP systems? 17. What are the pros and cons of using a workaround? 18. When is outsourcing considered a good design strat- egy? When is it not appropriate? 19. What are the differences between the time-and- arrangements, fixed-price, and value-added contracts for outsourcing? 20. How are the alternative matrix and feasibility analysis related? 21. What is an RFP? How is this different from an RFI? EXERCISES A. Perform a verification and validation walkthrough of the functional and structural models of the dentist office problem-domain layer described in exercises E, F, and G in Chapter 5 and exercise K in Chapter 6. B. Based on the functional models you created for exer- cises E, F, and G in Chapter 5 and the structural model you created in exercise K in Chapter 6, draw a package diagram for the problem-domain layer for the dentist office system. Be sure to verify and vali- date the diagram. C. Perform a verification and validation walkthrough of the functional and structural models of the real estate system problem-domain layer described in exercises J and K in Chapter 5 and Exercise M in Chapter 6. D. Based on the functional models you created for exer- cises J and K in Chapter 5 and the structural model you created in exercise M in Chapter 6, draw a package dia- gram for the problem-domain layer for the real estate system. Be sure to verify and validate the diagram. E. Perform a verification and validation walkthrough of the functional, structural, and behavioral models of the video store system problem-domain layer described in exercises L and M in Chapter 5, exercise N in Chapter 6, and exercises A, B, and C in Chapter 7. F. Based on the functional models you created for exer- cises L and M in Chapter 5, the structural model you created in exercise N in Chapter 6, and the behavioral models you created in exercises A, B, and C in Chapter 7, draw a package diagram for the problem-domain layer for the video store system. Be sure to verify and validate the diagram. G. Perform a verification and validation walkthrough of the functional, structural, and behavioral models of the health club membership system problem-domain layer described in exercises N and O in Chapter 5, exercise O in Chapter 6, and exercises D, E, and F in Chapter 7. H. Based on the functional models you created for exer- cises N and O in Chapter 5, the structural model you created in exercise O in Chapter 6, and the behav- ioral models you created in exercises D, E, and F in Chapter 7, draw a package diagram for the problem domain layer for the health club membership system. Be sure to verify and validate the diagram. 316 Chapter 8 Moving on to Design I. Perform a verification and validation walkthrough of the functional, structural, and behavioral models of the catering system problem-domain layer described in exercises P and Q in Chapter 5, exercise P in Chap- ter 6, and exercise J in Chapter 7. J. Based on the functional models you created for exer- cises P and Q in Chapter 5, the structural model you created in exercise P in Chapter 6, and the behavioral models you created in exercise J in Chapter 7, draw a package diagram for the problem-domain layer for the catering system. Be sure to verify and validate the diagram. K. Perform a verification and validation walkthrough of the functional, structural, and behavioral models of the Of-the-Month Club system problem-domain layer described in exercises R and S in Chapter 5, exercise Q in Chapter 6, and exercise K in Chapter 7. L. Based on the functional models you created for exer- cises R and S in Chapter 5, the structural model you created in Exercise Q in Chapter 6, and the behavioral models you created in exercise K in Chapter 7, draw a package diagram for the problem-domain layer for the system for the Of-the-Month Club. Be sure to verify and validate the diagram. M. Perform a verification and validation walkthrough of the functional, structural, and behavioral models of the university library system problem-domain layer described in exercises T and U in Chapter 5, exercise R in Chapter 6, and exercise L in Chapter 7. N. Based on the functional models you created for exer- cises T and U in Chapter 5, the structural model you created in Exercise R in Chapter 6, and the behavioral models you created in exercises L in Chapter 7, draw a package diagram for the problem domain layer for the university library system. Be sure to verify and validate the diagram. O. Which design strategy would you recommend for the construction of the system in each exercise? Why? a. exercises A & B b. exercises C & D c. exercises E & F d. exercises G & H e. exercises I & J f. exercises K & L g. exercises M & N P. Suppose you are leading a project that will implement a new course-enrollment system for your university. You are thinking about either using a packaged course- enrollment application or outsourcing the job to an external consultant. Create an outline for an RFP to which interested vendors and consultants could respond. Q. Suppose you and your friends are starting a small business painting houses in the summertime. You need to buy a software package that handles the finan- cial transactions of the business. Create an alternative matrix that compares three packaged systems (e.g., Quicken, MS Money, Quickbooks). Which alternative appears to be the best choice? MINICASES 1. Susan, president of MOTO, Inc., a human resources management firm, is reflecting on the client manage- ment software system her organization purchased four years ago. At that time, the firm had just gone through a major growth spurt, and the mixture of automated and manual procedures that had been used to manage client accounts became unwieldy. Susan and Nancy, her IS department head, researched and selected the pack- age that is currently used. Susan had heard about the software at a professional conference she attended, and at least initially, it worked fairly well for the firm. Some of their procedures had to change to fit the package, but they expected that and were prepared for it. Since that time, MOTO, Inc. has continued to grow, not only through an expansion of the client base, but also through the acquisition of several smaller employ- ment-related businesses. MOTO, Inc. is a much different business than it was four years ago. Along with expand- ing to offer more diversified human resource manage- ment services, the firm’s support staff has also expanded. Susan and Nancy are particularly proud of the IS depart- ment they have built up over the years. Using strong ties with a local university, an attractive compensation pack- age, and a good working environment, the IS depart- ment is well-staffed with competent, innovative people, plus a steady stream of college interns that keeps the department fresh and lively. One of the IS teams pio- neered the use of the Internet to offer MOTO’s services to a whole new market segment, an experiment that has proven very successful. It seems clear that a major change is needed in the client management software, and Susan has already begun to plan financially to undertake such a project. This software is a central part of MOTO’s operations, Minicases 317 and Susan wants to be sure that a quality system is obtained this time. She knows that the vendor of their current system has made some revisions and additions to its product line. There are also a number of other software vendors who offer products that may be suit- able. Some of these vendors did not exist when the purchase was made four years ago. Susan is also con- sidering Nancy’s suggestion that the IS department develop a custom software application. a. Outline the issues that Susan should consider that would support the development of a custom soft- ware application in-house. b. Outline the issues that Susan should consider which would support the purchase of a software package. c. Within the context of a systems development pro- ject, when should the decision of “make-versus-buy” be made? How should Susan proceed? Explain your answer. 2. Refer to minicase 1 in Chapter 6. After completing all the analysis models (both the as-is and to-be models) for West Star Marinas, the director of operations finally understood why it was important to under- stand the as-is system before delving into the develop- ment of the to-be system. However, you now tell him that the to-be models are only the problem-domain portion of the design. To say the least, he is now very confused. After explaining to him the advantages of using a layered approach to developing the system, he says, “I don’t care about reusability or maintenance. I only want the system to be implemented as soon as possible. You IS types are always trying to pull a fast one on the users. Just get the system completed.” What is your response to the Director of Opera- tions? Do you jump into implementation as he seems to want? What do you do next? 3. Refer to the analysis models that you created for profes- sional and scientific staff management (PSSM) for mini- case 2 in Chapter 5 and for minicase 1 in Chapter 7. a. Add packages to your use-case diagram to simplify it. b. Use the communication diagram to identify logical partitions in your class diagram. Add packages to the diagram to represent the partitions. 4. Refer to the analysis models that you created for Holiday Travel Vehicles for minicase 2 in Chapter 6 and for mini- case 2 in Chapter 7. a. Add packages to your use-case diagram to simplify it. b. Use the communication diagram to identify logical partitions in your class diagram. Add packages to the diagram to represent the partitions. 318 The most important step of the design phase is designing the individual classes and methods. Object-oriented systems can be quite complex, so analysts need to create instruc- tions and guidelines for programmers that clearly describe what the system must do. This chapter presents a set of criteria, activities, and techniques used to design classes and meth- ods. Together they are used to ensure the object-oriented design communicates how the system needs to be coded. OBJECTIVES ■ Become familiar with coupling, cohesion, and connascence. ■ Be able to specify, restructure, and optimize object designs. ■ Be able to identify the reuse of predefined classes, libraries, frameworks, and components. ■ Be able to specify constraints and contracts. ■ Be able to create a method specification. CHAPTER OUTLINE CHAPTER 9 Class and Method Design Introduction Review of the Basic Characteristics of Object Orientation Classes, Objects, Methods, and Messages Encapsulation and Information Hiding Polymorphism and Dynamic Binding Inheritance Design Criteria Coupling Cohesion Connascence Object Design Activities Adding Specifications Identifying Opportunities for Reuse Restructuring the Design Optimizing the Design Mapping Problem-Domain Classes to Implementation Languages Constraints and Contracts Elements of a Contract Types of Constraints Method Specification General Information Events Message Passing Algorithm Specification Applying the Concepts at CD Selections Summary INTRODUCTION WARNING: This material may be hazardous to your mental stability. Not really, but now that we have your attention, you must realize that this material is fairly technical in nature and that it is extremely important in today’s “flat” world. Today, much of the actual implementa- tion will be done in a different geographic location than where the analysis and design are Introduction 319 performed. As such, we must ensure that the design is specified in a “correct” manner. We must make certain that there is no, or at least minimal, ambiguity in the design specification. In today’s flat world, the common language spoken among developers is very likely to be UML and some object-oriented language, such as Java, and not English. English has always been and always will be ambiguous. Furthermore, to what version of English do we refer? As both Oscar Wilde and George Bernard Shaw independently pointed out, the United States and England are divided by a common language. A simple, but relevant, example is the number of zeros in one billion. In American English, there are nine, but in British English there are twelve. Obviously, this could lead to problems when one is building financial information systems. Practically speaking, Class and Method design is where all the work actually gets done during design. No matter which layer you are focusing on, the classes, which will be used to create the system objects, must be designed. Some people believe that with reusable class libraries and off-the-shelf components, this type of low-level, or detailed, design is a waste of time and that we should jump immediately into the “real” work: coding the system. However, if the past shows us anything, it shows that low-level, or detailed, design is critical despite the use of libraries and components. Detailed design is still very important for three reasons. First, with today’s modern CASE tools, quite a bit of the actual code can be generated by the tool from the detailed design. Second, even preexisting classes and components needs to be under- stood, organized, and pieced together. Third, it is still common for the project team to have to write some code and produce original classes that support the application logic of the system. Jumping right into coding will guarantee results that can be disastrous. For example, even though the use of layers can simplify the individual classes, they can increase the com- plexity of the interactions between them. As such, if the classes are not designed carefully, the resulting system can be very inefficient. Or worse, the instances of the classes (i.e., the objects) will not be capable of communicating with each other, which, of course, will result in the system not working properly. Furthermore, in an object-oriented system, changes can take place at different levels of abstraction. These levels include variable, method, class/object, package,1 library, and/or application/system levels (see Figure 9-1). The changes that take place at one level can impact other levels (e.g., changes to a class can affect the package level, which can affect both the system level and the library level, which in turn can cause changes back down at the class level). Finally, changes can occur at different levels at the same time. The good news is that the detailed design of the individual classes and methods is fairly straightforward, and the interactions among the objects on the problem-domain layer have been designed, in some detail, during analysis (see Chapters 5–7). The other layers (data man- agement, human–computer interaction, and system architecture), are highly dependent on the problem-domain layer (see Figure 8-7). Therefore, if the problem-domain classes are designed correctly, the design of the classes on the other layers will fall into place, relatively speaking. That being said, it has been our experience that many project teams are much too quick at jumping into writing code for the classes without first designing them. Some of this has been caused by the fact that object-oriented systems analysis and design has evolved from object-oriented programming. Until recently there has been a general lack of accepted guidelines on how to design and develop effective object-oriented systems. How- ever, with the acceptance of UML as a standard object notation, standardized approaches based on work of many object methodologists have begun to emerge.2 1 A package is a group of collaborating objects. Other names for a package include cluster, partition, pattern, sub- ject, and subsystem. 2 For example, OPEN [I. Graham, B. Henderson-Seller, and H. Yanoussi, The Open Process Specification (Reading, MA: Addison-Wesley, 1997)], RUP [P. Kruchten, The Rational Unified Process: An Introduction, 2nd ed. (Reading, MA: Addison-Wesley, 2000)], and the Enhanced Unified Process (see Chapter 1). In this chapter, we begin by reviewing the basic characteristics of object orientation. Next, we present a set of useful design criteria and activities that are applicable across any layer for class and method design. Finally, we present a set of techniques that are useful for design methods: contracts and method specifications. Review of the Basic Characteristics of Object Orientation3 Object-oriented systems can be traced back to the Simula and the Smalltalk programming languages. However, until the increase in processor power and the decrease in processor cost that occurred in the 1980s, object-oriented approaches were not practical. Many of the specific details concerning the basic characteristics of object-orientation are language dependent; that is, each object-oriented programming language tends to implement some of the object-oriented basics in different ways. As such, we need to know which program- ming language is going to be used to implement the different aspects of the solution. Oth- erwise, the system may behave in a manner different than the analyst, designer, and client expect. Today, the Cϩϩ, Java, and Visual Basic.Net programming languages tend to be the more predominant ones used. In this section, we review the basic characteristics of object orientation and point out where the language specific issues emerge. Classes, Objects, Methods, and Messages The basic building block of the system is the object. Objects are instances of classes that we use as templates to define objects. A class defines both the data and processes that each object contains. Each object has attributes that describe data about the object. Objects have state, which is defined by the value of its attributes and its relationships with other objects at a particular point in time. And, each object has methods, which specify what processes the object can perform. From our perspective, methods are used to implement the opera- tions that specified the behavior of the objects (see Chapter 6). In order to get an object to perform a method (e.g., to delete itself), a message is sent to the object. A message is essen- tially a function or procedure call from one object to another object. 320 Chapter 9 Class and Method Design Application/System Package Library Class/Object Variable Method FIGURE 9-1 Levels of Abstraction in Object-Oriented Systems Source: Adapted from David P. Tegarden, Steven D. Sheetz, and David E. Monarchi, “A Software Complexity Model of Object-Oriented Systems,” Decision Support Systems 13 (March 1995): 241–262. 3 For an introduction to the basic characteristics, see Appendix 1. Encapsulation and Information Hiding Encapsulation is the mechanism that combines the processes and data into a single object. Information hiding suggests only the information required to use an object be available out- side the object; that is, information hiding is related to the visibility of the methods and attributes (see Chapter 6). Exactly how the object stores data or performs methods is not relevant, as long as the object functions correctly. All that is required to use an object are the set of methods and the messages needed to be sent to trigger them. The only commu- nication between objects should be through an object’s methods. The fact that we can use an object by sending a message that calls methods is the key to reusability because it shields the internal workings of the object from changes in the outside system, and it keeps the sys- tem from being affected when changes are made to an object. Polymorphism and Dynamic Binding Polymorphism means having the ability to take several forms. By supporting polymor- phism, object-oriented systems can send the same message to a set of objects, which can be interpreted differently by different classes of objects. And, based on encapsulation and information hiding, an object does not have to be concerned with how something is done when using other objects. It simply sends a message to an object and that object determines how to interpret the message. This is accomplished through the use of dynamic binding. Dynamic binding refers to the ability of object-oriented systems to defer the data typ- ing of objects to run time. For example, imagine that you have an array of type employee that contains instances of hourly employees and salaried employees (see Figure 9-2). Both these types of employees implement a compute pay method. An object can send the mes- sage to each instance contained in the array to compute the pay for that individual instance. Depending on whether the instance is an hourly employee or a salaried employee, a differ- ent method will be executed. The specific method is chosen at run time. With this ability, individual classes are easier to understand. However, the specific level of support for poly- morphism and dynamic binding is language specific. Most object-oriented programming languages support dynamic binding of methods, and some support dynamic binding of attributes. As such, it is important to know what object-oriented programming language is going to be used. But polymorphism can be a double-edged sword. Through the use of dynamic bind- ing, there is no way to know before run time which specific object will be asked to execute its method. In effect, there is a decision made by the system that is not coded anywhere.4 Introduction 321 Array Employee ** contains +computePay() Hourly Employee +computePay() Salaried Employee +computePay() FIGURE 9-2 Polymorphism Example 4 From a practical perspective, there is an implied case statement. The system chooses the method based on the type of object being asked to execute it and the parameters passed as arguments to the method. Furthermore, because all these decisions are made at run time, it is possible to send a mes- sage to an object that it does not understand (i.e., the object does not have a correspond- ing method). This can cause a run-time error that, if not programmed to handle correctly, can cause the system to abort.5 Finally, if the methods are not semantically consistent, the developer cannot assume that all methods with the same name will perform the same generic operation. For example, imagine that you have an array of type person that contains instances of employees and customers (see Figure 9-3). These both implement a compute pay method. An object can send the message to each instance contained in the array to exe- cute the compute pay method for that individual instance. In the case of an instance of employee, the compute pay method computes the amount that the employee is owed by the firm, whereas the compute pay method associated with an instance of a customer computes the amount owed the firm by the customer. Depending on whether the instance is an employee or a customer, a different meaning is associated with the method. As such, the semantics of each method must be determined individually. This substantially increases the difficulty of understanding individual objects. The key to controlling the difficulty of understanding object-oriented systems when using poly- morphism is to ensure that all methods with the same name implement that same generic operation (i.e., they are semantically consistent). Inheritance Inheritance allows developers to define classes incrementally by reusing classes defined pre- viously as the basis for new classes. Although we could define each class separately, it might be simpler to define one general superclass that contains the data and methods needed by the subclasses and then have these classes inherit the properties of the superclass. Sub- classes inherit the appropriate attributes and methods from the superclasses above them. Inheritance makes it simpler to define classes. 322 Chapter 9 Class and Method Design Array Person ** contains +computePay() Employee +computePay() Customer +computePay() Hourly Employee +computePay() Salaried Employee +computePay() FIGURE 9-3 Polymorphism Misuse Example 5 In Java, these errors are referred to as exceptions that the system “throws” and must “catch.” In other words, the programmer must correctly program the throw and catch or the Java virtual machine will abort. Again, each pro- gramming language can handle these situations in a unique manner. There have been many different types of inheritance mechanisms associated with object-oriented systems.6 The most common inheri- tance mechanisms include different forms of single and multiple inher- itance. Single inheritance allows a subclass to have only a single parent class. Currently, all object-oriented methodologies, databases, and pro- gramming languages permit extending the definition of the superclass through single inheritance. Some object-oriented methodologies, databases, and program- ming languages allow a subclass to redefine some or all the attributes and/or methods of its superclass. With redefinition capabilities, it is pos- sible to introduce an inheritance conflict [i.e., an attribute (or method) of a subclass with the same name as an attribute (or method) of a super- class]. For example in Figure 9-4, Doctor is a subclass of Employee. Both have methods named ComputePay(). This causes an inheritance con- flict. Furthermore, when the definition of a superclass is modified, all its subclasses are affected. This may introduce additional inheritance con- flicts in one (or more) of the superclass’s subclasses. For example in Fig- ure 9-4, Employee could be modified to include an additional method, UpdateSchedule(). This would add another inheritance conflict between Employee and Doctor. Therefore, developers must be aware of the effects of the modification not only in the superclass, but also in each subclass that inherits the modification. Finally, through redefinition capabilities, it is possible for a programmer to arbitrarily cancel the inheritance of methods by placing stubs7 in the subclass that will override the definition of the inherited method. If the cancellation of methods is necessary for the cor- rect definition of the subclass, then it is likely that the subclass has been misclassified (i.e., it is inheriting from the wrong superclass). As you can see, from a design perspective, inheritance conflicts and redefinition can cause all kinds of problems with interpreting the final design and implementation.8 How- ever, most inheritance conflicts are due to poor classification of the subclass in the inheri- tance hierarchy (the generalization a-kind-of semantics are violated), or the actual inheritance mechanism violates the encapsulation principle (i.e., subclasses are capable of directly addressing the attributes or methods of a superclass). To address these issues, Jim Rumbaugh, and his colleagues, suggested the following guidelines:9 ■ Do not redefine query operations. ■ Methods that redefine inherited ones should restrict only the semantics of the inherited ones. ■ The underlying semantics of the inherited method should never be changed. ■ The signature (argument list) of the inherited method should never be changed. However, many existing object-oriented programming languages violate these guidelines. When it comes to implementing the design, different object-oriented programming Introduction 323 6 See, for example, M. Lenzerini, D. Nardi, and M. Simi, Inheritance Hierarchies in Knowledge Representation and Programming Languages (New York: Wiley, 1991). 7 In this case, a stub is simply the minimal definition of a method to prevent syntax errors occurring. 8 For more information, see Ronald J. Brachman, “I Lied about the Trees Or, Defaults and Definitions in Knowl- edge Representation,” AI Magazine 5, no. 3 (Fall 1985): 80–93. 9 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design (Engle- wood Cliffs, NJ: Prentice Hall, 1991). Person +computePay() Employee +computePay() Salaried Employee +computePay() Doctor +computePay() +updateSchedule() FIGURE 9-4 Redefinition and Inheritance Conflict Example languages address inheritance conflicts differently. Therefore, it is important at this point in the development of the system to know what the chosen programming language sup- ports. And, we must be sure that the design can be implemented as intended. Otherwise, the design needs to be modified before it is turned over to remotely located programmers. When considering the interaction of inheritance with polymorphism and dynamic bind- ing, object-oriented systems provide the developer with a very powerful, but dangerous, set of tools. Depending on the object-oriented programming language used, this interaction can allow the same object to be associated with different classes at different times. For example, an instance of Doctor can be treated as an instance of Employee or any of its direct and indirect superclasses, such as SalariedEmployee and Person, respectively (see Figure 9-4). Therefore, depending on whether static or dynamic binding is supported, the same object may execute different implementations of the same method at different times. Or, if the method is defined only with the SalariedEmployee class and it is currently treated as an instance of the Employee class, the instance may cause a run-time error to occur.10 As stated previously, it is important to know what object-oriented programming language is going to be used so that these kinds of issues can be solved with the design, instead of the implementation, of the class. With multiple inheritance, a subclass may inherit from more than one superclass. In this situation, the types of inheritance conflicts are multiplied. In addition to the possibil- ity of having an inheritance conflict between the subclass and one (or more) of its super- classes, it is now possible to have conflicts between two (or more) superclasses. In this latter case, there are three different types of additional inheritance conflicts that can occur: ■ Two inherited attributes (or methods) have the same name (spelling) and semantics. ■ Two inherited attributes (or methods) have different names but identical semantics (i.e., they are synonyms). ■ Two inherited attributes (or methods) have the same name but different seman- tics (i.e., they are heteronyms, homographs, or homonyms). This also violates the proper use of polymorphism. For example, in Figure 9-5, Robot-Employee is a subclass of both Employee and Robot. In this case, Employee and Robot conflict with the attribute name. Which one should Robot-Employee inherit? Because they are the same, semantically speaking, does 324 Chapter 9 Class and Method Design Employee -name -classification -runningTime Robot -name -type -runningTime Robot-EmployeeFIGURE 9-5 Additional Inheritance Conflicts with Multiple Inheritance 10 This happens with novices quite regularly when using Cϩϩ. it really matter? It is also possible that Employee and Robot could have a semantic con- flict on the classification and type attributes if they have the same semantics. Practically speaking, the only way to prevent this situation is for the developer to catch it during the design of the subclass. Finally, what if the runningTime attributes have different seman- tics? In the case Employee objects, the runningTime attribute stores the employee’s time running a mile, whereas the runningTime attribute for Robot objects stores the average time between checkups. Should Robot-Employee inherit both of them? It really depends on whether the robot employees can run the mile or not. With the potential for these additional types of conflicts, there is a risk of decreasing the understandability in an object-oriented system instead of increasing it through the use of multiple inheritance. As such, great care should be taken when using multiple inheritance. DESIGN CRITERIA When considering the design of an object-oriented system, a set of criteria exists that can be used to determine whether the design is a good one or a bad one. According to Coad and Yourdon,11 “A good design is one that balances trade-offs to minimize the total cost of the system over its entire lifetime.” These criteria include coupling, cohesion, and connascence. Coupling Coupling refers to how interdependent or interrelated the modules (classes, objects, and methods) are in a system. The higher the interdependency, the more likely changes in part of a design can cause changes to be required in other parts of the design. For object- oriented systems, Coad and Yourdon12 identified two types of coupling to consider: interaction and inheritance. Interaction coupling deals with the coupling among methods and objects through mes- sage passing. Lieberherr and Holland put forth the law of Demeter as a guideline to Design Criteria 325 Meilir Page-Jones, through his consulting company, identi- fied a set of abuses of inheritance. In some cases, these abuses led to lengthy and bloody disputes, gruesome imple- mentations, and in one case, it led to the destruction of the development team. In all cases, the error was in not enforc- ing a generalization (a-kind-of) semantics. In one case, the inheritance hierarchy was inverted: BoardMember was a superclass of Manager, which was a superclass of Employee. However, in this case, an Employee is NOT a-kind-of Man- ager, which is NOT a-kind-of BoardMember. In fact, the opposite was true. However, if you think of an Organization Chart, a BoardMember is super to a Manager, which is super to an Employee. In another example, the client’s firm attempted to use inheritance to model a membership idea (e.g., Student is a member of a club). However, the club should have had an attribute that contained the student members. In the other examples, inheritance was used to implement an association relationship and an aggregation relationship. Source: Meilir Page-Jones, Fundamentals of Object-Oriented Design in UML (Reading, MA: Addison-Wesley, 2000). Question As an analyst, how can you attempt to avoid these types of inheritance abuses? 9-A Inheritance AbusesCONCEPTS IN ACTION 11 Peter Coad and Edward Yourdon, Object-Oriented Design (Englewood Cliffs, NJ: Yourdon Press, 1991), p. 128. 12 Ibid. 326 Chapter 9 Class and Method Design minimize this type of coupling.13 Essentially, the law minimizes the number of objects that can receive messages from a given object. The law states that an object should send mes- sages only to one of the following: ■ Itself (For example, in Figure 9-6a, Object1 can send Message1 to itself. In other words, a method associated with Object1 can use other methods associated with Object1.14) ■ An object that is contained in an attribute of the object or one of its superclasses (For example in Figure 9-6b, PO1 should be able to send messages using both its Customer and Date attributes.) ■ An object that is passed as a parameter to the method (For example in Figure 9-6c, the aPatient instance sends the message RequestAppt(name, address) to the aReceptionist instance, which is allowed to send messages to the instances contained in the name and address parameters.) ■ An object that is created by the method (For example in Figure 9-6c, the method RequestAppt associated with the aReceptionist instance creates an instance of the Appointment class. As such, the RequestAppt method is allowed to send messages to anAppt.) ■ An object that is stored in a global variable15 In each case, interaction coupling is increased. For example, the coupling increases between the objects if the calling method passes attributes to the called method or if the calling method depends on the value being returned by the called method. There are six types of interaction coupling, each falling on different parts of a good- to-bad continuum. They range from no direct coupling to content coupling. Figure 9-7 presents the different types of interaction coupling. In general, interaction coupling should be minimized. The one possible exception is that non-problem-domain classes must be coupled to their corresponding problem-domain classes. For example, a report object (on the human–computer interaction layer) that displays the contents of an employee object (on the problem-domain layer) will be dependent on the employee object. In this case, for optimization purposes, the report class may be even content or pathologically coupled to the employee class. However, problem-domain classes should never be coupled to non- problem-domain classes. Inheritance coupling, as its name implies, deals with how tightly coupled the classes are in an inheritance hierarchy. Most authors tend to say simply that this type of coupling is desirable. However, depending on the issues raised previously with inheritance—inheri- tance conflicts, redefinition capabilities, and dynamic binding—a high level of inheritance coupling may not be a good thing. For example, in Figure 9-8, should Method2() defined in Subclass be allowed to call Method1() defined in Superclass? Or, should Method2() defined in Subclass refer to Atribute1 defined in Superclass? Or, even more confusing, assuming that Superclass is an abstract class, can a Method1() call Method2() or use Attribute2 defined in Subclass? Obviously, the first two examples have some intuitive sense. Using the properties of a superclass is the primary purpose of inheriting from it in the first place. On the other hand, the third example is somewhat counterintuitive. However, due to 13 Karl J. Lieberherr and Ian M. Holland, “Assuring Good Style for Object-Oriented Programs,” IEEE Software,6, no. 5 (September, 1989): 38–48; and Karl J. Lieberherr, Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns (Boston, MA: PWS Publishing, 1996). 14 Obviously, this is stating what is expected. 15 From a design perspective, global variables should be avoided. Most pure object-oriented programming lan- guages do not explicitly support global variables. As such, we do not address them any further. the way that different object-oriented programming languages support dynamic binding, polymorphism and inheritance, all these examples could be possible. As Snyder has pointed out, most problems with inheritance involve the ability within the object-oriented programming languages to violate the encapsulation and Design Criteria 327 Purchase Order -PO Number[1..1] : unsigned long -Sub Total[0..1] : Currency -Tax[0..1] : Currency -Shipping[0..1] : Currency -Total[0..1] : Currency -Customer[1..1] : Customer -State[1..1] : State PO1: Purchase Order Date : Date PO Number : unsigned long Sub Total : Currency Tax : Currency Shipping : Currency Total : Currency Customer : Customer State : State Message 1 Invoice Object 1 Accts Pay Forms -Date : date RequestAppt(name, address) NewCancelChangeAppt?() ApptTimes?() aPatient LookUpPatient() aReceptionist Patients:PatientsList [aPatient Exists]: LookupBills() MatchAppts() UnpaidBills:BillsList Appointments:ApptsList CreateAppt() anAppt:Appointment (a) (b) (c) FIGURE 9-6 Interaction Coupling Examples information-hiding principles.16 Therefore, again, knowledge of which object-oriented programming language is to be used is crucial. From a design perspective, the developer will need to optimize the trade-offs of violating the encapsulation and information-hiding principles and increasing the desirable coupling between subclasses and its superclasses. The best way to solve this conundrum is to ensure that inheritance is used only to support generalization/specialization (a-kind-of) semantics and the principle of substitutability (see Chap- ter 6). All other uses should be avoided. Cohesion Cohesion refers to how single-minded a module (class, object, or method) is within a sys- tem. A class or object should represent only one thing, and a method should solve only a single task. Three general types of cohesion, method, class, and generalization/special- ization, have been identified by Coad and Yourdon17 for object-oriented systems. Method cohesion addresses the cohesion within an individual method (i.e., how single- minded a method is). Methods should do one and only one thing. A method that actually performs multiple functions is more difficult to understand—and, therefore, to implement and maintain—than one that performs only a single function. There are seven types of method cohesion that have been identified (see Figure 9-9). They range from functional 328 Chapter 9 Class and Method Design Good No Direct Coupling The methods do not relate to one another; that is, they do not call one another. Data The calling method passes a variable to the called method. If the variable is composite (i.e., an object), the entire object is used by the called method to perform its function. Stamp The calling method passes a composite variable (i.e., an object) to the called method, but the called method only uses a portion of the object to perform its function. Control The calling method passes a control variable whose value will control the execution of the called method. Common or Global The methods refer to a “global data area” that is outside the individual objects. Bad Content or Pathological A method of one object refers to the inside (hidden parts) of another object. This violates the principles of encapsulation and information hiding. However, C++ allows this to take place through the use of “friends.” Source: These types were adapted from Meilir Page-Jones, The Practical Guide to Structured Systems Design, 2nd ed. (Englewood Cliffs, NJ: Yardon Press, 1988); and Glenford Myers, Composite/Structured Design (New York: Van Nostrand Reinhold, 1978). Level Type Description FIGURE 9-7 Types of Interaction Coupling Superclass +method1() -attribute1 Subclass +method2() -attribute2FIGURE 9-8 Inheritance Coupling Example 16 Alan Snyder, “Encapsulation and Inheritance in Object-Oriented Programming Languages,” in N. Meyrowitz, ed., OOPSLA ’86 Conference Proceedings, ACM SigPlan Notices, 21, no. 11 (November 1986); and Alan Snyder, “Inheritance and the Development of Encapsulated Software Components,” in B. Shriver and P. Wegner, eds., Research Directions in Object-Oriented Programming (Cambridge, MA: MIT Press, 1987). 17 Coad and Yourdon, Object-Oriented Design. cohesion (good) down to coincidental cohesion (bad). In general, method cohesion should be maximized. Class cohesion is the level of cohesion among the attributes and methods of a class (i.e., how single-minded a class is). A class should represent only one thing, such as an employee, a department, or an order. All attributes and methods contained in a class should be required for the class to represent the thing. For example, an employee class should have attributes that deal with a social security number, last name, first name, middle initial, addresses, and benefits, but it should not have attributes such as door, engine, or hood. Fur- thermore, there should be no attributes or methods that are never used. In other words, a class should have only the attributes and methods necessary to fully define instances for the problem at hand. In this case, we have ideal class cohesion. Glenford Meyers suggested that a cohesive class18 should have these attributes: ■ It should contain multiple methods that are visible outside the class (i.e., a single- method class rarely makes sense). ■ Each visible method performs only a single function (i.e., it has functional cohesion). Design Criteria 329 FIGURE 9-9 Types of Method Cohesion 18 We have adapted his informational-strength module criteria from structured design to object-oriented design. [see Glenford J. Myers, Composite/Structured Design (New York, NY: Van Nostrand Reinhold, 1978)]. Good Functional A method performs a single problem-related task (e.g., calculate current GPA). Sequential The method combines two functions in which the output from the first one is used as the input to the second one (e.g., format and validate current GPA). Communicational The method combines two functions that use the same attributes to execute (e.g., calculate current and cumulative GPA). Procedural The method supports multiple weakly related functions. For example, the method could calculate student GPA, print student record, calculate cumulative GPA, and print cumulative GPA. Temporal or Classical The method supports multiple related functions in time (e.g., initialize all attributes). Logical The method supports multiple related functions, but the choice of the specific function is chosen based on a control variable that is passed into the method. For example, the called method could open a checking account, open a sav- ings account, or calculate a loan, depending on the message that is send by its calling method. Bad Coincidental The purpose of the method cannot be defined or it performs multiple functions that are unrelated to one another. For example, the method could update customer records, calcu- late loan payments, print exception reports, and analyze competitor pricing structure. Source: These types were adapted from Page-Jones, The Practical Guide to Structured Systems, and Myers, Composite/Structured Design. Level Type Description ■ All methods reference only attributes or other methods defined within the class or one of its superclasses (i.e., if a method is going to send a message to another object, the remote object must be the value of one of the local object’s attributes).19 ■ It should not have any control-flow couplings between its visible methods. Page-Jones20 has identified three less-than-desirable types of class cohesion: mixed- instance, mixed-domain, and mixed-role (see Figure 9-10). An individual class can have a mixture of any of the three types. Generalization/specialization cohesion addresses the sensibility of the inheritance hier- archy. How are the classes in the inheritance hierarchy related? Are the classes related through a generalization/specialization (a-kind-of) semantics? Or, are they related via some association, aggregation, or membership type of relationship that was created for simple reuse purposes? Recall all the issues raised previously on the use of inheritance. For example, in Figure 9-11, the subclasses ClassRooms and Staff inherit from the superclass Department. Obviously, instances of the ClassRooms and Staff classes are not a-kind-of Department. However, in the early days of object-oriented programming, this use of inher- itance was quite common. When a programmer saw that there were some common prop- erties that a set of classes shared, the programmer would create an artificial abstraction that defined the commonalities. This was potentially useful in a reuse sense, but it turned out to cause many maintenance nightmares. In this case, instances of the ClassRooms and Staff classes are associated with or a-part-of an instance of Department. Today we know that highly cohesive inheritance hierarchies should support only the semantics of generalization and specialization (a-kind-of) and the principle of substitutability. 330 Chapter 9 Class and Method Design 19 This restricts message passing to only the first, second, and fourth conditions supported by the law of Demeter. For example, in Figure 9-6c, aReceptionist must have attributes associated with it that contains objects for Patients, Unpaid Bills, and Appointments. Furthermore, once anAppt is created, a Receptionist must have an attribute with a