MIS 396W Cuyamaca College Technical Writing Self Reflection Paper

https://developers.google.com/tech-writing/one (Links to an external site.)

As you read the material, consider how you may utilize this knowledge to improve your own writing quality for business, technical, and personal pursuits.

Then, please answer the following questions in a text submission, and submit your assignment. Canvas is unreliable, I suggest writing your answers in a word document, and then pasting it into the submission field.

1) In your own words, what is the objective of technical writing, and why is it important in the context of the Software Development Lifecycle (SDLC)? How might it benefit my business or our clients’ users? Anticipated responses would be about 2-3 moderate sized paragraphs.

2) How might documentation you write for your own development team (system documentation) differ from the documentation you produce for end users (how to use/operate the system)? Anticipated responses would be about 2-3 moderate sized paragraphs, and address the differences in audiences for documentation.

3) In relation to the material and topics in this assignment, reflect on your own writing experience and capabilities, and consider “what is an area of my own writing, in a technical writing / documentation sense, that can be improved, and what topic from the material can help me accomplish this? Anticipated responses would objectively assess the student’s own writing capabilities, identify an area that can be improved, and suggest how they can improve. A length of 1-4 paragraphs would be appropriate.

DENNIS
WIXOM
ROTH
S YS T EM S A N A LY S IS
& D ES I G N
6 TH E D I T I O N
Visible Analyst Student Edition
Educating tomorrow’s developers today
Visible Analyst is a “hands-on” tool for teaching students all aspects of analysis and design
including dynamic rules, consistency checking, managing change, and understanding the integration
issues across an IT project. Visible Analyst prepares students to enter the IT world as business or
data architects, analysts, designers, and modelers.
Visit us at www.visible.com to learn more.
YOU CAN Start Today
with the Visible Analyst!
Only takes 2
minutes to install!
Save… 33% discount!
Please visit
http://store.visible.com/Wiley.aspx
to purchase and register with your
information (see below) and obtain a
valid license for your student edition of
the software. To purchase the discounted
software you will need to enter the
following code:
978112014
Email support is provided to all registered
students at support@visible.com. Your
registration includes
■
■
■
■
the latest release of the Visible Analyst
Student Edition (software)
the Visible Analyst eTutorial
a preloaded Sample Instructional
Project
access to Webcast “How to” and “Get
Started” Instructional Videos.
Disclaimer: The publisher of the textbook does not sponsor, review, or make decisions about Visible Analyst software,
and will not be responsible for, or involved in, any changes to the software.
SYSTEMS ANALYSIS AND DESIGN
Sixth Edition
Alan Dennis
Indiana University
Barbara Haley Wixom
Massachusetts Institute of Technology
Roberta M. Roth
University of Northern Iowa
VP & EXECUTIVE PUBLISHER
EXECUTIVE EDITOR
CONTENT EDITOR
ASSOCIATE EDITOR
MARKETING MANAGER
OPERATIONS MANAGER
ASSOCIATE PRODUCTION MANAGER
DESIGNER
Don Fowley
Beth Lang Golub
Mary O’Sullivan
Ellen Keohane
Christopher Ruel
Yana Mermel
Joyce Poh
Wendy Lai
This book was set by Aptara.
Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for
more than 200 years, helping people around the world meet their needs and fulﬁll their aspirations. Our
company is built on a foundation of principles that include responsibility to the communities we serve and
where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global eﬀort to address
the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are
addressing are carbon impact, paper speciﬁcations and procurement, ethical conduct within our business
and among our vendors, and community and charitable support. For more information, please visit our
website: www.wiley.com/go/citizenship.
Copyright © 2015, 2012, 2009 John Wiley & Sons, Inc. All rights reserved. No part of this publication may be
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 authorization
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 070305774, (201)748-6011, fax (201)748-6008, website http://www.wiley.com/go/permissions.
Evaluation copies are provided to qualiﬁed academics and professionals for review purposes only, for use in
their courses during the next academic year. These copies are licensed and may not be sold or transferred
to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return
instructions and a free of charge return mailing label are available at www.wiley.com/go/returnlabel. If you
have chosen to adopt this textbook for use in your course, please accept this book as your complimentary
desk copy. Outside of the United States, please contact your local sales representative.
Library of Congress Cataloging-in-Publication Data
Dennis, Alan.
Systems analysis and design / Alan Dennis, Barbara Haley Wixom, Roberta M. Roth.—Sixth edition.
pages cm
Includes bibliographical references and index.
ISBN 978-1-118-89784-3 (paperback)
1. System design. 2. System analysis. 3. Computer architecture. I. Wixom, Barbara Haley,
1969– II. Roth, Roberta M. (Roberta Marie), 1955– III. Wixom, Barbara Haley. IV. Roth,
Roberta M. V. Title.
QA76.9.S88D464 2014
004.2ʹ2—dc23
2014034532
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
To Kelly
To Chris, Haley, and Hannah
To Rich and the boys, always.
PREFACE
PURPOSE OF THIS BOOK
Slearnystems
Analysis and Design (SAD) is an exciting, active ﬁeld in which analysts continually
new techniques and approaches to develop systems more eﬀectively and eﬃciently. However, there is a core set of skills that all analysts need to know no matter what approach or
methodology is used. All information systems projects move through the four phases of planning, analysis, design, and implementation; all projects require analysts to gather requirements, model the business needs, and create blueprints for how the system should be built; and
all projects require an understanding of organizational behavior concepts like change management and team building.
This book captures the dynamic aspects of the ﬁeld by keeping students focused on doing
SAD while presenting the core set of skills that we feel every systems analyst needs to know
today and in the future. 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 students
to practice. In this way, students can leave the course with experience that will form a rich
foundation for further work as a systems analyst.
OUTSTANDING FEATURES
A Focus on Doing SAD
The goal of this book is to enable students to do SAD—not just read about it, but understand
the issues so that 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 provides
opportunities for students to practice before they do it in a real-world project. After reading
each chapter, the student will be able to perform that step in the system development life cycle
(SDLC) process.
Rich Examples of Success and Failure
The book includes a running case about a ﬁctitious company called Tune Source. Each chapter
shows how the concepts are applied in situations at Tune Source. Unlike running cases in other
books, this text focuses examples on planning, managing, and executing the activities described
vi Preface
in the chapter, rather than on detailed dialogue between ﬁctitious 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 that describe how real companies succeeded—
and failed—in performing the activities in the chapter. Many of these examples are drawn
from our own experiences as systems analysts.
Incorporation of Object-Oriented Concepts and Techniques
The ﬁeld is moving toward object-oriented concepts and techniques, both through UML 2.0,
the new standard for object-oriented analysis and design, as well as by gradually incorporating
object-oriented concepts into traditional techniques. We have taken two approaches to incorporating object-oriented analysis and design into the book. First, we have integrated several
object-oriented concepts into our discussion of traditional techniques, although this may not
be noticed by the students because few concepts are explicitly labeled as object-oriented concepts. For example, we include the development of use cases as the ﬁrst step in process modeling (i.e., data ﬂow diagramming) in Chapter 4, and the use (and reuse) of standard interface
templates and use scenarios for interface design in Chapter 9.
Second, and more obvious to students, we include a ﬁnal chapter on the major elements
of UML 2.0 that can be used as an introduction to object-oriented analysis and design. This
chapter can be used at the end of a course—while students are busy working on projects—or
can be introduced after or instead of Chapters 5 and 6.
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 IBM, the U.S. Department of Defense, and the Australian Army. We have also
worked with diverse industry advisory boards of IS professionals and consultants in developing the book and have incorporated their stories, feedback, and advice throughout. Many
students who use this book will eventually apply the skills on the job in a business environment, and we believe that they will have a competitive edge by 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 encounters
them in a typical project. Although the presentation necessarily is linear (because students
have to learn concepts in the way in which they build on each other), we emphasize the iterative, complex nature of SAD as the book unfolds. The presentation of the material should align
well with courses that encourage students to work on projects, because it presents topics as
students need to apply them.
Graphic Organization
The underlying metaphor for the book is doing SAD through a project. We have tried to
emphasize this graphically throughout the book so that students can better understand how
the major elements in the SDLC are related to each other. First, at the start of every major
phase of the system development life cycle, we present a graphic illustration showing the major
deliverables that will be developed and added to the electronic “project binder” during that
phase. Second, at the start of each chapter, we present a checklist of key tasks or activities that
will be performed to produce the deliverables associated with this chapter. These graphic
Preface vii
elements—the deliverables tied to each phase and the task checklist tied to each chapter—can
help students better understand how the tasks, deliverables, and phases are related to and ﬂow
from one to another.
Finally, we have highlighted important practical aspects throughout the book by marking boxes and illustrations with a “push pin.” These topics are particularly important in the
practical day-to-day life of systems analysts and are the kind of topics that junior analysts
should pull out of the book and post on the bulletin board in their oﬃce to help them avoid
costly mistakes.
WHAT’S NEW IN THE SIXTH EDITION
The sixth edition contains several signiﬁcant enhancements, including new and updated content, new Concepts in Action features, and updated exercises. The most signiﬁcant content
changes are:
■
■
■
■
■
Expanded discussion of Agile methodologies, particularly Scrum, in chapter 2.
Considerable reorganization of chapter 4 (Use Case Analysis) so as to clarify
concepts and add more illustrations.
New content on mobile application architectures in chapter 8.
Extensive revision of chapter 9, User Interface Design, in order to streamline the
presentation for added clarity. New content has been added to reﬂect some important current user interface concepts, including usability, user experience (UX),
issues of designing for touch screen interfaces, and several additional user interface
design tools, including site maps, wireframe diagrams, and wireﬂow diagrams.
New content in the chapter 11, Database Design, on the newer NoSQL databases
and the BigData concept.
Throughout the book, the chapter objectives have been revised to reﬂect active learning objectives. Chapter references to outside sources have been updated to current resources wherever
possible. New Concepts in Action features appear throughout the book to provide updated,
real-world illustrations of the textbook content.
For this edition, a series of tutorial lessons have been created that will teach students how
to use and apply the Visible Analyst™ computer-assisted software engineering (CASE) software
to a simple systems development project scenario. (Please see the Supplements section of this
Preface for more information on purchasing Visible Analyst software at a reduced price for use
in your course.)
We know that most professors and students ﬁnd the Systems Analysis and Design class
to have a lot of demanding content, particularly in those classes that include a signiﬁcant
project. Many professors would like their students to be able to experience ﬁrst-hand how
useful a CASE tool is to a systems analyst, but ﬁnd it diﬃcult to include instruction on a CASE
tool in an already full course. The goal of these lessons is to enable students to learn the basics
of the Visible Analyst CASE software with little involvement on the part of the professor. The
lesson material is found on the student web site for this textbook (at www.wiley.com/college/
dennis), with references to these lessons found in new Your-Turn boxes throughout the book.
Professors have the ﬂexibility to assign these tutorial lessons if they want to include the Visible
Analyst software in their courses, but are also free to exclude this material if they prefer. The
tutorial lessons have been written to provide students with a suﬃcient foundation to apply
Visible Analyst to a more signiﬁcant systems development project, should that be a part of
their course.
viii Preface
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 speciﬁc tasks that analysts need to accomplish over the course
of a project, and the deliverables that will be produced from the tasks. As students complete the
book, tasks will be “checked oﬀ ” and deliverables will be completed and stored in project folders.
Part 1 covers the ﬁrst phase of the SDLC, the Planning Phase. Chapter 1 introduces the
SDLC, the roles and skills needed for a project team, project initiation, the systems request, and
feasibility analysis. Chapter 2 discusses project selection, the selection of an SDLC methodology for the project, and project management, with emphasis on the work plan, staﬃng plan,
project charter, risk assessment, and tools used to help manage and control the project.
Part 2 presents techniques needed during the analysis phase. In Chapter 3, students are
introduced to requirements determination and are taught a variety of analysis techniques to
help with business process automation, business process improvement, and business process
reengineering. Chapter 4 focuses on use cases, Chapter 5 covers process models, and Chapter 6
explains data models and normalization.
The Design Phase is covered in Part 3 of the textbook. In Chapter 7, students create an alternative matrix that compares custom, packaged, and outsourcing alternatives. Chapter 8 focuses
on designing the system architecture, which includes the architecture design, hardware/software
speciﬁcation, and security plan. Chapter 9 focuses on the user interface and presents interface
design; in this chapter, students learn how to create use scenarios, the interface structure diagram,
interface standards, and interface prototypes. Finally, data storage design and program design are
discussed in Chapters 10 and 11, which contain information regarding the data storage design,
the program structure chart, and program speciﬁcations.
The Implementation Phase is presented in Chapters 12 and 13. Chapter 12 focuses on
system construction, and students learn how to build and test the system. It includes information about the test plan and user documentation. Conversion is covered in Chapter 13, where
students learn about the conversion plan, the change management plan, the support plan, and
the project assessment.
Chapter 14 (online) provides a background of object orientation and explains several key
object concepts supported by the standard set of object-modeling techniques used by systems
analysts and developers. Then, we explain how to draw four of the most eﬀective models in
UML: the use case diagram, the sequence diagram, the class diagram, and the behavioral state
machine diagram.
SUPPLEMENTS
www.wiley.com/college/dennis
Online Instructors Manual
The instructors manual provides resources to support the instructor both in and out of the
classroom:
■
■
■
■
Short experiential exercises can be used to help students experience and understand
key topics in each chapter.
Short stories have been provided by people working in both corporate and
consulting environments for instructors to insert into lectures to make concepts
more colorful and real.
Additional mini-cases for every chapter allow students to perform some of the key
concepts that were learned in the chapter.
Answers to end-of-chapter questions and exercises are provided.
Preface ix
Online Instructor’s Resources
■
■
PowerPoint slides, prepared by author Roberta Roth, are provided that instructors
can tailor to their classroom needs and that students can use to guide their reading
and studying activities.
Test Bank includes a variety of questions ranging from multiple choice to essaystyle questions. A computerized version of the Test Bank is also available.
Student Web Site
■
Web Quizzes help students prepare for class tests. See www.wiley.com/college/dennis.
Wiley E-Text: Powered by VitalSource
This Wiley e-text oﬀers students continuing access to materials for their course. Your students
can access content on a mobile device, online from any Internet-connected computer, or by a
computer via download. With dynamic features built into this e-text, students can search
across content, highlight, and take notes that they can share with teachers and classmates.
Readers will also have access to interactive images and embedded podcasts.
Visible Analyst
Wiley has partnered with Visible Analyst to give students a discounted price for Visible Analyst software, an intuitive modeling tool for all aspects of traditional or object-oriented systems
analysis and design. All new copies of the text will have a Key Code (printed on a page near
the front of this text) that will provide a discount on Visible Analyst software. To obtain the
software, students should visit http://store.visible.com/Wiley.aspx and enter their Key Code.
Students who buy a new print text or digital e-book will receive one-third oﬀ the price of a
downloadable edition of the software with a 6-month license. With the software, they will also
receive tutorials, how-to videos, and a sample project. Students who buy used copies of this
text may buy Visible Analyst at full price using the URL provided.
Project Management Software
You can download a 60-day trial of Microsoft Project Professional 2013 from the following
Web site: http://technet.microsoft.com/en-us/evalcenter/hh973401. Note that Microsoft has
changed its policy and no longer oﬀers the 120-day trial previously available.
Another option now available to education institutions adopting this Wiley title is a free
introductory 3-year membership for DreamSpark Premium. DreamSpark Premium is designed
to provide the easiest and most inexpensive way for academic departments to make the latest
Microsoft software available in labs, classrooms, and on student and instructor PCs. Microsoft
Project software is available through this Wiley and Microsoft publishing partnership, free of
charge with the adoption of any qualiﬁed Wiley title. Each copy of Microsoft Project is the full
version of the software, with no time limitation, and can be used indeﬁnitely for educational
purposes. Contact your Wiley sales representative for details. For more information about the
DreamSpark Premium program, contact drmspkna@Microsoft.com.
ACKNOWLEDGMENTS
We extend our thanks to the many people who contributed to the preparation of this sixth
and past editions. We are indebted to the staﬀ at John Wiley & Sons for their support,
including Beth Lang Golub, Executive Editor; Christopher Ruel, Marketing Manager; Joyce
Poh, Associate Production Manager; and Wendy Lai, Senior Designer.
x Preface
We would like to thank the following reviewers of the sixth edition for their helpful and
insightful comments:
Name
Las Adams
Jon W. Beard
Claudia Howery
Glynn Johnson
Kay Lee
Long Li
Suzanne Nordhaus
School
Bethune-Cookman University
George Mason University
Delta College
University of Houston
University of Kansas
Grambling State University
Lee College
We would like to thank the many practitioners from private practice, public organizations, and
consulting ﬁrms for helping us add a real-world component to this project. A special remembrance goes to Matt Anderson from Accenture, who was a role model for all who knew him—
who demonstrated excellence in systems analysis and design and in life in general.
Thanks also to our families and friends for their patience and support along the way,
especially to Christopher, Haley, and Hannah Wixom; Alec Dennis; and Richard Jones.
Alan Dennis
Barb Wixom
ardennis@indiana.edu
bwixom@mindspring.com
Robby Roth
Roberta.Roth@uni.edu
CONTENTS
Preface
PART ONE
CHAPTER 1
v
PLANNING PHASE
The Systems Analyst
and Information
Systems Development
Introduction
The Systems Analyst
Systems Analyst Skills
Systems Analyst Roles
The Systems Development Life Cycle
Planning
Analysis
Design
Implementation
Project Identiﬁcation and Initiation
System Request
Applying the Concepts at Tune Source
Feasibility Analysis
Technical Feasibility
Economic Feasibility
Organizational Feasibility
Applying the Concepts at Tune Source
Chapter Review
Appendix 1A—Detailed Economic
Feasibility Analysis for Tune Source
CHAPTER 2
Project Selection
and Management
Introduction
Project Selection
Applying the Concepts at Tune Source
Creating the Project Plan
Project Methodology Options
Selecting the Appropriate Development
Methodology
Estimating the Project Time Frame
Developing the Work Plan
Staﬃng the Project
Staﬃng Plan
Coordinating Project Activities
1
2
3
4
4
5
6
9
9
10
10
11
13
15
18
18
19
25
28
30
33
35
36
37
38
39
40
47
49
50
55
55
58
Managing and Controlling the Project
Reﬁning Estimates
Managing Scope
Timeboxing
Managing Risk
Applying the Concepts at Tune Source
Staﬃng the Project
Coordinating Project Activities
Chapter Review
Appendix 2A—The Function Point Approach
Appendix 2B—Project Management Tools:
The Gantt Chart and PERT Chart
Gantt Chart
PERT Chart
61
61
63
63
64
65
66
69
70
73
PART TWO
CHAPTER 3
81
ANALYSIS PHASE
Requirements
Determination
Introduction
The Analysis Phase
Requirements Determination
What Is a Requirement?
The Process of Determining
Requirements
The Requirements Deﬁnition Statement
Requirements Elicitation Techniques
Requirements Elicitation in Practice
Interviews
Joint Application Development (JAD)
Questionnaires
Document Analysis
Observation
Selecting the Appropriate Techniques
Requirements Analysis Strategies
Problem Analysis
Root Cause Analysis
Duration Analysis
Activity-Based Costing
Informal Benchmarking
Outcome Analysis
78
78
78
82
82
83
85
85
87
89
90
91
91
98
102
104
105
107
108
108
108
110
110
110
111
xii Contents
Technology Analysis
Activity Elimination
Comparing Analysis Strategies
Applying the Concepts at Tune Source
Eliciting and Analyzing Requirements
Requirements Deﬁnition
System Proposal
Chapter Review
111
112
113
113
113
114
114
116
CHAPTER 4
120
Use Case Analysis
Introduction
What is a Use Case?
The Use Case Concept in a Nutshell
Use Case Formats and Elements
Casual Use Case Format
Use Cases in Sequence
Fully Dressed Use Case Format
Applying Use Cases
Use Case Practical Tips
Use Cases and Functional Requirements
Use Cases and Testing
Creating Use Cases
Applying the Concepts at Tune Source
Identifying the Major Use Cases
Elaborating on the Use Cases
Chapter Review
120
122
122
123
123
126
126
128
129
129
129
130
144
144
145
149
CHAPTER 5
153
Process Modeling
Introduction
Data Flow Diagrams
Reading Data Flow Diagrams
Elements of Data Flow Diagrams
Using Data Flow Diagrams to Deﬁne
Business Processes
Process Descriptions
Creating Data Flow Diagrams
Creating the Context Diagram
Creating Data Flow Diagram Fragments
Creating the Level 0 Data Flow Diagram
Creating Level 1 Data Flow Diagrams
(and Below)
Validating the Data Flow Diagrams
Applying the Concepts at Tune Source
Creating the Context Diagram
153
154
154
156
158
162
162
164
165
166
166
173
177
177
Creating Data Flow Diagram Fragments
Creating the Level 0 Data Flow Diagram
Creating Level 1 Data Flow Diagrams
(and Below)
Validating the Data Flow Diagrams
Chapter Review
178
183
184
CHAPTER 6
187
Data Modeling
178
178
Introduction
The Entity Relationship Diagram
Reading an Entity Relationship Diagram
Elements of an Entity Relationship
Diagram
The Data Dictionary and Metadata
Creating an Entity Relationship Diagram
Building Entity Relationship Diagrams
Advanced Syntax
Applying the Concepts at Tune Source
Validating an Entity Relationship Diagram
Design Guidelines
Normalization
Balancing Entity Relationship Diagrams
with Data Flow Diagrams
Chapter Review
Appendix 6A: Normalizing the Data Model
189
193
196
196
199
200
203
203
206
PART THREE
CHAPTER 7
217
218
DESIGN PHASE
Moving into Design
Introduction
Transition from Requirements to Design
System Acquisition Strategies
Custom Development
Packaged Software
Outsourcing
Inﬂuences on the Acquisition Strategy
Business Need
In-House Experience
Project Skills
Project Management
Time Frame
Selecting an Acquisition Strategy
Alternative Matrix
Applying the Concepts at Tune Source
Chapter Review
187
188
188
206
208
211
218
219
221
223
224
225
228
228
229
229
230
230
230
231
233
234
Contents xiii
CHAPTER 8
Architecture Design
237
Introduction
Elements of an Architecture Design
Architectural Components
Client–Server Architectures
Client–Server Tiers
Server-Based Architecture
Mobile Application Architecture
Advances in Architecture Conﬁgurations
Comparing Architecture Options
Creating an Architecture Design
Operational Requirements
Performance Requirements
Security Requirements
Cultural and Political Requirements
Designing the Architecture
Hardware and Software Speciﬁcation
Applying the Concepts at Tune Source
Creating an Architecture Design
Hardware and Software Speciﬁcation
Chapter Review
237
238
238
239
240
242
243
244
245
246
246
247
249
254
256
258
260
260
261
262
CHAPTER 9
265
User Interface Design
Introduction
The Usability Concept
Principles for User Interface Design
Layout
Content Awareness
Aesthetics
Usage Level
Consistency
Minimize User Eﬀort
Special Issues of Touch Screen
Interface Design
User Interface Design Process
Understand the Users
Organize the Interface
Deﬁne Standards
Interface Design Prototyping
Interface Evaluation/Testing
Navigation Design
Basic Principles
Menu Tips
Message Tips
266
266
267
267
269
270
270
272
273
273
274
275
277
279
280
283
286
286
287
289
Input Design
Basic Principles
Input Tips
Input Validation
Output Design
Basic Principles
Types of Outputs
Media
Applying the Concepts at Tune Source
Understand the Users
Organize the Interface
Deﬁne Standards
Interface Template Design
Develop Prototypes
Interface Evaluation/Testing
Chapter Review
292
292
294
296
296
296
298
300
301
301
301
303
303
305
305
306
CHAPTER 10 Program Design
311
Introduction
Moving from Logical to Physical
Process Models
The Physical Data Flow Diagram
Applying the Concepts at Tune Source
Designing Programs
Structure Chart
Syntax
Building the Structure Chart
Applying the Concepts at Tune Source
Design Guidelines
Program Speciﬁcation
Syntax
Applying the Concepts at Tune Source
Chapter Review
312
312
312
315
316
319
320
322
324
328
335
335
339
341
CHAPTER 11 Data Storage Design
346
Introduction
Data Storage Formats
Files
Databases
Selecting a Storage Format
Applying the Concepts at Tune Source
Moving from Logical to Physical Data Models
The Physical Entity Relationship Diagram
Revisiting the CRUD Matrix
347
347
348
350
354
356
357
357
359
xiv Contents
Applying the Concepts at Tune Source
Optimizing Data Storage
Optimizing Storage Eﬃciency
Optimizing Access Speed
Estimating Storage Size
Applying the Concepts at Tune Source
Chapter Review
360
362
363
364
369
371
373
PART FOUR IMPLEMENTATION PHASE 377
CHAPTER 12 Moving into Implementation 378
Introduction
378
Managing the Programming Process
379
Assigning Programming Tasks
379
Coordinating Activities
380
Managing the Schedule
381
Testing
381
Test Planning
382
Unit Tests
384
Integration Tests
386
System Tests
386
Acceptance Tests
386
Developing Documentation
388
Types of Documentation
389
Designing Documentation Structure
389
Writing Documentation Topics
391
Identifying Navigation Terms
392
Applying the Concepts at Tune Source
394
Managing Programming
394
Testing
394
Developing User Documentation
396
Chapter Review
397
CHAPTER 13 Transition to the New System
Introduction
Making the Transition to the New System
The Migration Plan
Selecting the Conversion Strategy
Preparing a Business Contingency Plan
Preparing the Technology
Preparing People for the New System
Understanding Resistance to Change
Revising Management Policies
Assessing Costs and Beneﬁts
Motivating Adoption
Enabling Adoption: Training
Postimplementation Activities
System Support
System Maintenance
Project Assessment
Applying the Concepts at Tune Source
Implementation Process
Preparing the People
Postimplementation Activities
Chapter Review
The Movement to Objects
(Online Only)
You can access this chapter at
www.wiley.com/college/dennis
400
400
401
402
402
406
408
408
409
410
411
412
415
418
418
419
421
423
423
423
424
424
CHAPTER 14
INDEX
427
I-1
PART ONE
MY PROJECT
PLANNING PHASE
Planning
st
System Request
Chapter 1
Project Initiation
Feasibility Analysis
llyysiss
Project Workplan
lan
Chapter 2
Project Management
Staffing Plan
Project Standards
rdss
Risk Assessment
ntt
n
Analysis
The Planning Phase involves two
primary issues: understanding why an
information system should be developed
and creating a plan for how the project
team should develop it.
Design
Implementation
The deliverables from both steps are
combined into the project plan. The
project sponsor and approval committee
then decide if the project should
continue on.
CHAPTER 1
THE SYSTEMS ANALYST
AND INFORMATION
SYSTEMS DEVELOPMENT
PLANNING
TASK
CHECKLIST
Identify project.
Develop systems request.
Analyze technical feasibility.
Analyze economic feasibility.
Analyze organizational feasibility.
Perform project selection review.
Estimate project time.
Identify project tasks.
Create work breakdown structure.
Create PERT Charts.
Create Gantt Charts.
Manage scope.
Staﬀ project.
Create project charter.
Set up CASE repository.
Develop standards.
Begin documentation.
Assess and manage risk.
T
his chapter introduces the role of the systems analyst in information systems development projects. First, the fundamental four-stage systems development life cycle (planning,
analysis, design, and implementation) is established as the basic framework for the information system (IS) development process. Next, ways in which organizations identify and initiate
potential projects are discussed. The ﬁrst steps in the process are to identify a project that will
deliver value to the business and to create a system request that provides the basic information about the proposed system. Next, the analysts perform a feasibility analysis to determine
the technical, economic, and organizational feasibility of the system.
OBJECTIVES
■
■
■
■
■
■
■
Explain the role played in information systems development by the systems analyst.
Describe the fundamental systems development life cycle and its four phases.
Explain how organizations identify IS development projects.
Explain the importance of linking the information system to business needs.
Be able to create a system request.
Describe technical, economic, and organizational feasibility assessment.
Be able to perform a feasibility analysis.
Introduction 3
INTRODUCTION
The systems development life cycle (SDLC) is the process of determining how an information
system (IS) can support business needs, designing the system, building it, and delivering it to
users.
If you have taken a programming class or have programmed on your own, you have
probably experienced some success in developing small software applications. Creating
high-quality information systems that meet expectations and provide meaningful value to
organizations is a much more complex endeavor, however.
Numerous studies over the years report that projects involving information technology
experience failure rates from 30 to 70%.1 The deﬁnition of failure in these studies is often quite
diﬀerent, so the meaning of these statistics is hard to pin down. It is clear, though, that bringing
an information system development project to a successful conclusion is diﬃcult and many
things need to be done right if we hope to achieve a positive outcome.
Although we would like to promote this book as a “silver bullet” that will keep you from
experiencing failed IS projects, we must admit that such a silver bullet guaranteeing IS development success does not exist.2 Instead, this book will provide you with many fundamental
concepts and practical techniques that you can use to improve the likelihood of success.
The systems analyst plays a key role in the SDLC, analyzing the business situation, identifying opportunities for improvements, and designing an information system to implement the
improvements. Many systems analysts view their profession as one of the most interesting,
exciting, and challenging jobs around. As a systems analyst, you will work as a team with a
variety of people, including business and technical experts. You will feel the satisfaction of
seeing systems that you designed and developed make a signiﬁcant positive business impact,
while knowing that your unique skills helped make that happen.
It is important to remember that the primary objective of the systems analyst is not to
create a wonderful system. The primary goal is to create value for the organization, which for
most companies means increasing proﬁts. (Government agencies and not-for-proﬁt organizations measure value diﬀerently.) Many failed projects were abandoned because the analysts
tried to build a wonderful system without clearly understanding how the system would support the organization’s goals, improve business processes, and integrate with 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 that it can
earn greater proﬁts or serve its constituents more eﬀectively.
This book introduces you to the fundamental skills needed by a systems analyst. This is a
pragmatic book that discusses best practices in systems development; it does not present a
general survey of systems development that exposes you to everything about the topic. By
deﬁnition, systems analysts do things and challenge the current way that an organization
works. To get the most out of this book, you will need to actively apply the ideas and concepts
in the examples and in the “Your Turn” exercises that are presented throughout to your own
systems development project. This book will guide you through all the steps for delivering a
successful information system. In the text, we illustrate how one organization, called Tune
Source, applies the steps in one project, developing a Web-based digital music sales system.
(Other illustrations of successful IS projects are provided on the course web site.) By the time
1
Michael Krigsman, “CIO Analysis: Why 37 Percent of Project Fail”, zdnet.com, accessed February 2014.
The idea of using the silver bullet metaphor was ﬁrst described in a paper by Frederick Brooks. See Frederick P. Brooks, Jr.,
“No Silver Bullet—Essence and Accident in Software Engineering,” Information Processing 1986, the Proceedings of the IFIP
Tenth World Computing Conference, H.-J. Kugler (ed.), 1986: 1069–76.
2
4 C ha pt e r 1 The Systems Analyst and Information Systems Development
CONCEPTS
1-A Managerial Causes of IT Failures
IN ACTION
A significant proportion of IT projects fail to fulfill their
original objectives, resulting in wasted resources and a
damaged reputation for the responsible IT department.
In many cases, the causes of the failure are organizational issues, not technical issues.
Qantas, the Australian national airline, has endured
two high-profile IT failures in recent years. In 1995,
Project eQ, a 10-year technology services contract with
IBM, was cancelled after four years, at a cost of $200
million. Poor planning contributed to the failure to
upgrade a complex and unwieldy IT infrastructure saddled with 700-odd applications written in older programming languages.
In 2008, Qantas canceled Jetsmart, a $40 million
parts-management system implementation, due in part to
a dispute with the unionized users (aircraft mechanics) of
the system. The union advised its members not to assist
with the implementation, claiming the software unnecessarily increased the members’ workload.
An analysis of these IT failures reveals several contributing factors. First, Qantas faced the challenges of a complicated technical infrastructure and outdated legacy
applications. More significantly, however, was the failure of
company leadership to understand basic IT issues. In public
statements, the company CFO seemed not to care about the
user perspectives on new software, preferring instead to put
in what management thought was appropriate. This attitude, in part, led to union problems and claims of poorly
designed, hard-to-use software and inadequate training.
Aging applications and an unwieldy technical infrastructure are challenges faced by many organizations
today. But the senior-management attitude that seemingly disregards the views of software users casts serious
questions about Qantas’ prospects for IT project success
in the future.
Adapted from: Michael Krigsman, “Quantas Airways: A
Perfect Storm for IT Failures?”, 2/29/08, zdnet.com, accessed
March 2014.
you ﬁnish the book, you will not be an expert analyst, but you will be ready to start building
systems for real.
In this chapter, we ﬁrst describe the role of the systems analyst in information systems
development projects. We discuss the wide range of skills needed to be successful in this role,
and we explain various specialties that systems analysts may develop. We then introduce the
basic SDLC that information systems projects follow. This life cycle is common to all projects
and serves as a framework for understanding how information systems projects are accomplished. We discuss how projects are identiﬁed and initiated within an organization and how
they are initially described in a system request. Finally, we describe the feasibility analysis that
is performed, which drives the decision whether to proceed with the project.
THE SYSTEMS ANALYST
The systems analyst plays a key role in information systems development projects. The systems analyst works closely with all project team members so that the team develops the right
system in an eﬀective way. Systems analysts must understand how to apply technology to
solve business problems. In addition, systems analysts may serve as change agents who identify the organizational improvements needed, design systems to implement those changes,
and train and motivate others to use the systems.
Systems Analyst Skills
New information systems introduce change to the organization and its people. Leading a
successful organizational change eﬀort is one of the most diﬃcult jobs that someone can do.
Understanding what to change, knowing how to change it, and convincing others of the need
for change require a wide range of skills. These skills can be broken down into six major
categories: technical, business, analytical, interpersonal, management, and ethical.
The Systems Analyst 5
Spotlight on Ethics-1
James is a systems analyst on a new account management system for Hometown National Bank. At a recent
meeting with the project sponsor, James learned about
some new ideas for the system that were not a part of
the original project scope. Specifically, the bank’s marketing director has asked that some of the data that will
be collected by the new system from customers who
open new checking and savings accounts also be used
as the basis of a marketing campaign for various loan
products the bank offers.
James is uncomfortable with the request. He is not
sure the bank has the right to use a person’s data for
purposes other than the original intent. Who “owns” this
data, the bank that collected it as a part of a customer
opening an account, or the customer who the data
describes? Should James insist that the customers give
authorization to use “their” data in this way? Or should
he say nothing and ignore the issue? Is it necessary (or
appropriate) for a systems analyst to be an ethical watchdog in a systems development project? Why or why not?
Analysts must have the technical skills to understand the organization’s existing technical
environment, the new system’s technology foundation, and the way in which both can be ﬁt
into an integrated technical solution. Business skills are required to understand how IT can be
applied to business situations and to ensure that 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.
Often, analysts need to communicate eﬀectively, one-on-one with users and business
managers (who often have little experience with technology) and with programmers (who
often have more technical expertise than the analyst does). They must be able to give presentations to large and small groups and to 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
must manage the pressure and risks associated with unclear situations.
Finally, analysts must deal fairly, honestly, and ethically with other project team members,
managers, and system users. Analysts often deal with conﬁdential information or information
that, if shared with others, could cause harm (e.g., dissent among employees); it is important
for analysts to maintain conﬁdence and trust with all people.
Systems Analyst Roles
As organizations and technology have become more complex, most large organizations now
build project teams that incorporate several analysts with diﬀerent, but complementary roles.
In smaller organizations, one person may play several of these roles. Here we brieﬂy describe
these roles and how they contribute to a systems development project.
YO U R
1-1 Being an Analyst
TU R N
Suppose you set a goal to become an analyst after you
graduate. What type of analyst would you most prefer
to be? Why does this particular analyst role appeal to
you? What type of courses should you take before you
graduate? What type of summer job or internship
should you seek?
Question
Develop a short plan that describes how you will prepare for your career as an analyst.
6 C ha pt e r 1 The Systems Analyst and Information Systems Development
The systems analyst role focuses on the IS issues surrounding the system. This person
develops ideas and suggestions for ways that IT can support and improve business processes,
helps design new business processes supported by IT, designs the new information system, and
ensures that all IS standards are maintained. The systems analyst will have signiﬁcant training
and experience in analysis and design and in programming.
The business analyst role focuses on the business issues surrounding the system. This
person helps to identify the business value that the system will create, develops ideas for
improving the business processes, and helps design new business processes and policies.
The business analyst will have business training and experience, plus knowledge of analysis
and design.
The requirements analyst role focuses on eliciting the requirements from the stakeholders
associated with the new system. As more organizations recognize the critical role that complete and accurate requirements play in the ultimate success of the system, this specialty has
gradually evolved. Requirements analysts understand the business well, are excellent communicators, and are highly skilled in an array of requirements elicitation techniques (discussed in
Chapter 3).
The infrastructure analyst role focuses on technical issues surrounding the ways the system will interact with the organization’s technical infrastructure (hardware, software, networks, and databases). This person ensures that the new information system conforms to
organizational standards and helps to identify infrastructure changes that will be needed to
support the system. The infrastructure analyst will have signiﬁcant training and experience in
networking, database administration, and various hardware and software products. Over time,
an experienced infrastructure analyst may assume the role of software architect, who takes a
holistic view of the organization’s entire IT environment and guides application design decisions within that context.
The change management analyst role focuses on the people and management issues
surrounding the system installation. This person ensures that adequate documentation and
support are available to users, provides user training on the new system, and develops strategies to overcome resistance to change. The change management analyst will have signiﬁcant training and experience in organizational behavior and speciﬁc expertise in change
management.
The project manager role ensures that the project is completed on time and within budget
and that the system delivers the expected value to the organization. The project manager is
often a seasoned systems analyst who, through training and experience, has acquired specialized project management knowledge and skills. More will be said about the project manager
in the next chapter.
The roles and the names used to describe them may vary from organization to organization. In addition, there is no single typical career path through these professional roles. Some
people may enter the ﬁeld as a more technically oriented programmer/analyst. Others may
enter as a business-oriented functional specialist with an interest in applying IT to solve business problems. As shown in Figure 1-1, those who are interested in the broad ﬁeld of information systems development may follow a variety of paths during their career.
THE SYSTEMS DEVELOPMENT LIFE CYCLE
In many ways, building an information system is similar to building a house. First, the owner
describes the vision for the house to the developer. Second, this idea is transformed into
sketches and drawings that are shown to the owner and reﬁned (often, through several drawings, each improving on the other) until the owner agrees that the pictures depict what he or
she wants. Third, a set of detailed blueprints is developed that presents much more speciﬁc
information about the house (e.g., the layout of rooms, placement of plumbing ﬁxtures and
The Systems Development Life Cycle 7
Requirements
analyst
Entry-level
business function
specialist
Change
management
analyst
Business
analyst
Project
manager
Systems
analyst
Entry-level
programmer/
analyst
Infrastructure
analyst
Software
architect
More common path
FIGURE 1-1
Career Paths for
System Developers
Less common path
electrical outlets, and so on). Finally, the house is built following the blueprints—and often
with some changes and decisions made by the owner as the house is erected.
Building an information system using the SDLC follows a similar set of four fundamental
phases: planning, analysis, design, and implementation (Figure 1-2). Each phase is itself composed of a series of steps, which rely on techniques that produce deliverables (speciﬁc documents and ﬁles that explain various elements of the system). Figure 1-3 provides more detail
on the steps, techniques, and deliverables that are included in each phase of the SDLC and
outlines how these topics are covered in this textbook.
Figures 1-2 and 1-3 suggest that the SDLC phases proceed in a logical path from start to
ﬁnish. In some projects, this is true. In many projects, however, the project team moves
through the steps consecutively, incrementally, iteratively, or in other patterns. Diﬀerent projects may emphasize diﬀerent parts of the SDLC or approach the SDLC phases in diﬀerent
ways, but all projects have elements of these four phases.
For now, there are two important points to understand about the SDLC. First, you
should get a general sense of the phases and steps that IS projects move through and some
of the techniques that produce certain deliverables. In this section, we provide an overview
Planning
Analysis
Idea
FIGURE 1-2 The Systems Development Life Cycle
Design
Implementation
System
success
8 C ha pt e r 1 The Systems Analyst and Information Systems Development
Phase
Chapter
Planning
Focus: Why build
this system?
How to structure
the project?
Primary outputs:
—System request with
feasibility study
—Project plan
1
1
Identify opportunity
Analyze feasibility
2
Develop workplan
2
Staff project
2
Control and direct project
3
Develop analysis strategy
3
Determine business
requirements
4
5
6
Create use cases
Model processes
Model data
7
Design physical system
Design strategy
8
Design architecture
9
Design interface
10
Design programs
11
Design databases and files
Architecture design
Hardware and software selection
Use scenario
Interface structure
Interface standards
Interface prototype
Interface evaluation
Data flow diagramming
Program structure chart
Program specification
Data format selection
Entity relationship modeling
Denormalization
Performance tuning
Size estimation
Analysis
Focus: Who, what,
where, and when for
this system?
Primary output
—System proposal
Design
Focus: How will this
system work?
Primary output:
—System specification
Implementation
12
Focus: Delivery and
support of completed
system
Primary output:
13
—Installed system
Step
Technique
Project identification
Technical feasibility
Economic feasibility
Organizational feasibility
Time estimation
Task identification
Work breakdown structure
PERT chart
Gantt chart
Scope management
Project staffing
Project charter
CASE repository
Standards
Documentation
Timeboxing
Risk management
Business process automation
Business process improvement
Business process reengineering
Interview
JAD session
Questionnaire
Document analysis
Observation
Use case analysis
Data flow diagramming
Entity relationship modeling
Normalization
Construct system
Programming
Software testing
Performance testing
Install system
Conversion strategy selection
13
Maintain system
13
Post-implementation
Training
Support selection
System maintenance
Project assessment
Post-implementation
audit
FIGURE 1-3 Systems Development Life Cycle Phases
Deliverable
System request
Feasibility study
Project plan
—Workplan
—Staffing plan
—Standards list
—Risk assessment
System proposal
—Requirements definition
—Use cases
—Process models
—Data model
Alternative matrix
System specification
—Architecture report
—Hardware and software specification
—Interface design
—Physical process model
—Program design
—Database and file specification
—Physical data model
Test plan
Programs
Documentation
Migration plan
—Conversion plan
—Business contingency plan
—Training plan
Support plan
Problem report
Change request
Post-implementation
audit report
The Systems Development Life Cycle 9
of the phases, steps, and some of the techniques that are used to accomplish the steps.
Second, it is important to understand that the SDLC is a process of gradual reﬁnement. The
deliverables produced in the analysis phase provide a general idea what the new system
will do. These deliverables are used as input to the design phase, which then reﬁnes them
to produce a set of deliverables that describes in much more detailed terms exactly how
the system should be built. These deliverables in turn are used in the implementation
phase to guide the creation of the actual system. Each phase reﬁnes 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ﬁed—
how will it contribute to the organization’s future success? Most ideas for new systems
come from outside the IS area and are recorded on a system request. A system request
presents a brief summary of a business need and explains how a system that addresses
the need will create business value. The IS department works together with the person
or department generating the request (called the project sponsor) to conduct a feasibility
analysis. The feasibility analysis examines key aspects of the proposed project:
The 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 systems
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 management,
the project manager creates a workplan, staﬀs the project, and puts techniques in place to
help control and direct the project through the entire SDLC. The deliverable for project
management is a project plan that 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 (Figure 1-3). During this phase, the project team investigates any current system(s), identiﬁes improvement opportunities, and develops a concept
for the new system. This phase has three steps:
1. An analysis strategy is developed to guide the project team’s eﬀorts. Such a strategy usually
includes studying the current system (called the as-is system) and its problems, and envisioning ways to design a new system (called the to-be system).
2. The next step is requirements gathering (e.g., through techniques such as interviews,
group workshops, or questionnaires). The analysis of this information—in conjunction
with input from the project sponsor and many other people—leads to the development of a concept for a new system. The system concept is explained through a set of
requirement statements and a set of business analysis models that describe how the
business will operate if the new system is developed. The analysis models represent
user/system interactions and the data and processes needed to support the underlying
business process.
10 C ha pt er 1 The Systems Analyst and Information Systems Development
3. The analyses, system concept, requirements, and models are combined into a document
called the system proposal, which is presented to the project sponsor and other key decision makers (e.g., members of the approval committee) who will decide whether the
project should continue to move forward.
The system proposal is the initial deliverable describing the requirements the new system
should satisfy. Some experts suggest this phase would be better named analysis and initial
design, rather than analysis, since it really provides the ﬁrst step in the new system design.
Since most organizations continue to use the name analysis for this phase, we will use it in this
book as well. It is important to remember, however, 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 that will be in place; the user interface, forms, and reports that will be
used; and the speciﬁc programs, databases, and ﬁles that will be needed. Although most of
the strategic decisions about the system are 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 must be determined. This clariﬁes whether the system will be
developed by the company’s own programmers, whether its development will be
outsourced to another ﬁrm (usually a consulting ﬁrm), or whether the company will
buy and install a prewritten software package.
2. This leads to the development of the basic architecture design for the system that
describes the hardware, software, and network infrastructure that will be used. In most
cases, the system will add to or change the infrastructure that already exists in the
organization. The interface design speciﬁes how the users will move through the system
(e.g., by navigation methods such as menus and on-screen buttons) and the forms and
reports that the system will use.
3. The database and ﬁle speciﬁcations are developed. These deﬁne exactly what data will be
stored and where they will be stored.
4. The analyst team develops the program design, which deﬁnes 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 used by the programming team for implementation. At the end of the design phase, the feasibility analysis and
project plan are reexamined and revised, and another decision is made by the project
sponsor and approval committee about whether to terminate the project or continue
(Figure 1-3).
Implementation
The ﬁnal phase in the SDLC is the implementation phase, during which the system is actually
built (or purchased and installed if the design calls for a prewritten software package). 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 ﬁrst step. The system is built and tested to ensure that it performs as designed. Since the cost of ﬁxing bugs can be immense, testing is one of the
most critical steps in implementation. Most organizations should spend more time and
attention on testing than on writing the programs in the ﬁrst place.
Project Identification and Initiation 11
2. The system is installed. Installation is the process by which the old system is turned oﬀ
and the new one is turned on. There are several approaches that may be used to convert
from the old to the new system. One of the most important aspects of conversion is
training, during which users are taught to use the new system and help manage the
resulting organizational changes.
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.
PROJECT IDENTIFICATION AND INITIATION
Where do project ideas come from? A project is identiﬁed when someone in the organization identiﬁes a business need to build a system. 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, unacceptable
product defect rates, or increased competition. New business initiatives and strategies may
be created and a system to support them is required, or a merger or acquisition may require
systems to be integrated.
Business needs also can surface when the organization identiﬁes unique and competitive
ways of using IT. Many organizations keep an eye on emerging technology, which is technology
that is in the early stages of widespread business use. For example, if companies stay abreast of
technological advances such as cloud computing, mobile apps, or Big Data, they can develop
business strategies that leverage the capabilities of these technologies and introduce them into
the marketplace as a ﬁrst mover. Ideally, companies can take advantage of this ﬁrst mover position by making money and continuing to innovate while competitors trail behind.
Today, many new information system projects grow out of business process management
(BPM) initiatives. BPM is a methodology used by organizations to continuously improve endto-end business processes. BPM can be applied to internal organizational processes and to
processes spanning multiple business partners. By studying and improving their underlying
business processes, organizations can achieve several important beneﬁts, including:
■
■
■
enhanced process agility, giving the organization the ability to adapt more rapidly
and eﬀectively to a changing business environment;
improved process alignment with industry “best practices”; and
increased process eﬃciencies as costs are identiﬁed and eliminated from process
workﬂows.
BPM generally follows a continuous cycle of systematically creating, assessing, and altering business processes. Business analysts, with their in-depth business knowledge, play a
particularly important role in BPM by:
1.
2.
3.
4.
deﬁning and mapping the steps in a business process,
creating ways to improve on steps in the process that add value,
ﬁnding ways to eliminate or consolidate steps in the process that do not add value,
creating or adjusting electronic workﬂows to match the improved process maps.
The last step is particularly relevant to our discussion since the need for information systems projects is frequently identiﬁed here. In fact, the automation of business processes
(termed business process automation), is the foundation of many information technology systems. In these situations, technology components are used to complement or substitute for
manual information management processes with the intent of gaining cost eﬃciencies.
12 C ha pt er 1 The Systems Analyst and Information Systems Development
BPM practitioners recognize, however, that it is not always advisable to just “pave the cow
paths” by simply adding automation to speed up existing processes (step 4 above). In many
situations, business process improvement (BPI) results from studying the business processes,
creating new, redesigned processes to improve the process workﬂows, and/or utilizing new
technologies enabling new process structures (steps 2, 3, and 4 above). For example, could a
retail store’s checkout process be redesigned along the lines of the EZPass toll collection system on highways? Could customers check out and pay with their mobile devices while clerks
simply review the contents of the customer’s shopping bag?
Projects with a goal of BPI make moderate changes to the organization’s operations, and
can improve eﬃciency (i.e., doing things right) and improve eﬀectiveness (i.e., doing the right
things). These types of projects involve more risk than business process automation projects
since more signiﬁcant changes are made to the organization’s operations.
BPM may also reveal the need for the complete revamping of the organization’s business
processes, termed business process reengineering (BPR). BPR means changing the fundamental
way in which the organization operates—“obliterating” the current way of doing business and
making major changes to take advantage of new ideas and new technology. As you might
expect, BPR projects involve substantial risk due to the signiﬁcant organizational and operational changes that result. Top management support and careful management are critical in
these fairly rare types of projects.
Both IT people (i.e., the information systems experts) and business people (i.e., the subject matter experts) should work closely together to ﬁnd ways for technology to support business needs. In this way, organizations can leverage the exciting technologies available while
ensuring that projects are based upon real business objectives such as increasing sales, improving customer service, and decreasing operating expenses. Ultimately, information systems
need to aﬀect the organization’s bottom line (in a positive way!).
When a strong business need for an information system is recognized, often as a result of
BPM, a person (or group) who has an interest in the system’s success typically steps forward.
We call this person (or group) the project sponsor. Often, the project sponsor develops the
initial vision of the new system. The project sponsor works throughout the SDLC to make sure
that the project is moving in the right direction from the perspective of the business and
serves as the primary point of contact for the project team. Usually, the sponsor of the project
is from a business function such as marketing, accounting, or ﬁnance; however, members of
the IT area also can sponsor or cosponsor a project.
CONCEPTS
1-B BPI on the Farm
IN ACTION
In the farming industry, grain is commonly loaded
into large grain-hauling trucks by the driver parking
under the grain bin, jumping out of the truck cab,
signaling the grain bin operator to start filling, monitoring the fill level, signaling the bin operator to stop
filling, jumping back into the truck cab, driving 3 feet
forward, and repeating the cycle numerous times until
the truck bed is full. This laborious process can be
simplified by digitizing the process. Cameras and
secure Wi-Fi can be installed on the grain bin. When
a truck arrives, the driver can open an app on his
smartphone from the truck cab. Through the app, the
driver can initiate, monitor, and control the filling
process without a grain bin operator and without leaving the truck. This real-world example illustrates BPI,
the redesign of a business process with the right application of information technology, providing significant efficiency gains.
Adapted from: Nicole Laskowski, “Crowdsourcing is the new
cloud computing—Get with it, CIOs,” searchcio.techtarget.
com, accessed February 2014.
Project Identification and Initiation 13
YO U R
1-2 Implementing a Satellite Data Network
TU R N
A major retail store spent $24 million dollars on a large
private satellite communication system that provides
state-of-the-art voice, data, and video transmission
between stores and regional headquarters. When an item
gets 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 the
store’s major competitors has an older system in which
transactions are uploaded at the end of a business day.
The first company feels that its method of instant communication and feedback allows it to react more quickly
to changes in the market, giving the company a competitive advantage. For example, if an early winter snowstorm
causes stores across the upper Midwest to start selling
high-end (and high-profit) snow throwers quite quickly,
the company’s nearest warehouse can prepare next-day
shipments to maintain a good inventory balance, while
the competitor may not move quite as quickly and thus
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 attempt to close the
“information gap” in this example?
The size or scope of the project often determines the kind of sponsor who is involved.
A small, departmental system might be sponsored by a single manager; however, a large,
organizational initiative might be sponsored by the entire senior management team and
even the CEO. If a project is primarily 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 functions may be
necessary.
The business need drives the high-level business requirements for the system. Business
requirements describe the reasons for developing the system and outline the capabilities it will
provide the organization. These requirements need to be explained at a high level so that the
approval committee and, ultimately, the project team understand what the business expects
from the ﬁnal product. Business requirements summarize the features the information system
must include, such as the ability to collect customer orders online or the ability for suppliers
to receive inventory status information as sales occur.
The project sponsor has the insights needed to determine the business value that will
be gained from the system, in both tangible and intangible ways. Tangible value can be
quantified and measured easily (e.g., 2% 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, a better competitive
position).
Once the project sponsor identiﬁes a project that meets an important business need and he
or she can identify the business requirements and business value of the system, it is time to
formally initiate the project. In most organizations, project initiation begins by preparing a
system request.
System Request
A system request is a document that describes the business reasons for building a system and
the value that the system is expected to provide. The project sponsor usually completes this
14 C ha pt er 1 The Systems Analyst and Information Systems Development
form as part of a formal system project selection process within the organization. Most system
requests include ﬁve elements: project sponsor, business need, business requirements, business
value, and special issues (Figure 1-4). The sponsor describes the person who will serve as the
primary contact for the project, and the business need presents the reasons prompting the
project. The business requirements of the project refer to the business capabilities that the system must have, and the business value describes the beneﬁts that the organization should
expect from the system. Special issues are included on the document as a catchall category for
other information that should be considered in assessing the project. For example, the project
may need to be completed by a speciﬁc deadline. Any special circumstances that could aﬀect
the outcome of the project must be clearly identiﬁed.
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 resources. The committee
reviews the system request and makes an initial determination, based on the information
provided, of whether to investigate the proposed project or not. If approved, the next step is to
conduct a feasibility analysis.
Element
FIGURE 1-4
Elements of the
System Request Form
Description
Examples
Project Sponsor
The person who initiates the
project and who serves as the
primary point of contact for the
project on the business side
Several members of the finance
department
Vice president of marketing
CIO
CEO
Business Need
The business-related reason for
initiating the system
Reach a new market segment
Offer a capability to keep up
with competitors
Improve access to information
Decrease product defects
Streamline supply acquisition
processes
Business Requirements
The new or enhanced business
capabilities that the system
will provide
Provide onIine access to information
Capture customer demographic
information
Include product search capabilities
Produce performance reports
Enhance online user support
Business Value
The benefits that the system will
create for the organization
3% increase in sales
1% increase in market share
Reduction in headcount by 5 FTEs
$200,000 cost savings from
decreased supply costs
$150,000 savings from removal
of outdated technology
Special Issues or
Constraints
Issues that pertain to the approval
committee’s decision
Government-mandated deadline
for May 30
System needed in time for the
Christmas holiday season
Top-level security clearance needed
by project team to work with data
FTE, full-time equivalent.
Project Identification and Initiation 15
CONCEPTS
1-C Interview with Don Hallacy, President, Technology
Services, Sprint Corporation
IN ACTION
At Sprint, network projects originate from two vantage
points—IT and the business units. IT projects usually
address infrastructure and support needs. The businessunit projects typically begin after a business need is
identified locally, and a business group informally collaborates with IT regarding 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 investigate 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 contains
the economic value added and the net present value of
the project.
Of course, not all projects undergo this rigorous
process. The larger projects require more time to be
allocated to the analysis team. It is important to remain
flexible and not let the process consume the organization. At the beginning of each budgetary year, specific
capital expenditures are allocated for operational
improvements and maintenance. Moreover, this money
is set aside to fund quick projects that deliver immediate
value without going through the traditional approval
process. Don Hallacy
Applying the Concepts at Tune Source
Throughout the book, we will apply the concepts in each chapter to a ﬁctitious company called
Tune Source. For example, in this section, we will illustrate the creation of a system request.
Tune Source is a company headquartered in southern California. Tune Source is the brainchild
of three entrepreneurs with ties to the music industry: John Margolis, Megan Taylor, and Phil
Cooper. Originally, John and Phil partnered to open a number of brick and mortar stores in
southern California specializing in hard-to-ﬁnd and classic jazz, rock, country, and folk recordings. Megan soon was invited to join the partnership because of her contacts and knowledge
of classical music. Tune Source quickly became known as the place to go to ﬁnd rare audio
recordings. Annual sales last year were $40 million with annual growth at about 3–5% per year.
YO U R
1-3 Too Much Paper, Part 1
TU R N
The South Dakota Department of Labor, Workers’ Compensation division was sinking under a load of paper
files. This state agency ascertains that employees are
treated fairly when they are injured on the job. If a person
(or company) called to see the status of an injury claim,
the clerk would have to take a message, get the paper file,
review the status, and call the person back. Files were
stored in huge filing cabinets and were entered by year
and case number (i.e., the 415th person injured in 2008
would be in a file numbered 08-415). Few callers knew
the file number and would give their name and address
and the date of injury. The clerk would look in a spiral
notebook for the last name around the date that was
given—and then find the file number to retrieve the
folder. Some folders were small—possibly documenting a
minor injury requiring only a brief treatment period.
Other folders could be very large, with numerous medical reports from several doctors verifying the extent of a
serious injury and treatment (such as an arm amputation).
A digital solution was suggested—reports could be submitted online via a secure web site. Medical reports
could be submitted electronically, either as a pdf file or
as a faxed digital file. This solution would also mean that
the clerk taking the phone call could query the database
by the person’s name and access the information in a
matter of seconds.
Question
Begin a systems request for this project. Focus on stating
the business need and the business requirements for this
project. What is the value of this system?
16 C ha pt er 1 The Systems Analyst and Information Systems Development
Background John, Megan, and Phil, like many others in the music industry, watched with
alarm the rise of music-sharing web site like Napster, as music consumers shared digital audio
ﬁles without paying for them, denying artists and record labels royalties associated with sales.
Once the legal battle over copyright infringement was resolved and Napster was shut down, the
partners set about establishing agreements with a variety of industry partners in order to oﬀer a
legitimate digital music download resource for customers in their market niche. Phil has asked
Carly Edwards, a rising star in the Tune Source marketing department, to spearhead the digital
music download project.
Tune Source currently has a web site that enables customers to search for and purchase
CDs. This site was initially developed by an Internet consulting ﬁrm and is hosted by a prominent local internet service provider (ISP) in Los Angeles. The IT department at Tune Source has
become experienced with Internet technology as it has worked with the ISP to maintain the site.
System Request At Tune Source, new 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. Carly’s ﬁrst step was to prepare a system request for the
committee.
Figure 1-5 shows the system request she prepared. The project sponsor is Carly, and the
business needs are to increase sales and provide a music download capability demanded by a
System Request—Digital Music Download Project
Project Sponsor: Carly Edwards, Assistant Vice President, Marketing
Business Need: This project has been initiated to create the capability of selling digital music downloads
to customers through kiosks in our stores and over the Internet using our web site. Currently,
• Customers have many alternatives for downloading music and we need to provide this capability to
retain our competitive position.
• Our music archive of rare and hard-to-find music is underutilized.
Business Requirements: Using this system over the Web or in-store kiosks, customers will be able to
search for and purchase digital music downloads. The specific functionality that the system should have
includes the following:
•
•
•
•
•
Search for music in our digital music archive.
Listen to music samples.
Purchase individual downloads at a fixed fee per download.
Establish a customer subscription account permitting unlimited downloads for a monthly fee.
Purchase music download gift cards.
Business Value: We expect that Tune Source will increase sales by enabling existing customers to purchase
specific digital music tracks and by reaching new customers who are interested in our unique archive of
rare and hard-to-find music. We expect to gain a new revenue stream from customer subscriptions to our
download services. We expect some increase in cross-selling, as customers who have downloaded a track
or two of a CD decide to purchase the entire CD in a store or through our web site. We also expect a new
revenue stream from the sale of music download gift cards.
Conservative estimates of tangible value to the company include the following:
FIGURE 1-5
System Request for
Tune Source
A template for this
figure is available on
the student web site
•
•
•
•
$757,500
$950,000
$205,000
$153,000
in
in
in
in
sales from individual music downloads
sales from customer subscriptions
additional in-store or web site CD sales
sales from music download gift cards
Special Issues or Constraints:
• The marketing department views this as a strategic system. To prevent significant customer attrition,
this project should be completed as soon as possible.
Project Identification and Initiation 17
very competitive marketplace. Notice that the need does not focus on the technology associated with the project. The emphasis is on the business aspects: increasing sales and maintaining a competitive position in the company’s market.
In the system request, the project sponsor focuses on describing his or her vision of the
business requirements at a very high level. Carly has expressed a clear vision of how this system will aﬀect Tune Source: sales of individual music downloads, revenue from customer
subscriptions, sales from cross-selling of CDs, and sales of music download gift cards. Carly
acknowledges customer demand for this capability and also recognizes the need to respond to
this demand in order to retain the business of its loyal customer base.
The estimates of tangible value were diﬃcult to develop, since this venture is completely
new to Tune Source. To prepare for this, Carly had several of her staﬀ members conduct both
an in-store customer survey and an online customer survey to assess the customers’ interest in
individual music downloads, subscription programs, and gift cards. The surveys also attempted
to gauge the customers’ price sensitivity for these oﬀerings.
From the survey results, Carly and her staﬀ developed a range of sales projections for
the various revenue streams: a high-level estimate, a medium-level estimate, and low-level
estimate. They also developed probability assessments for each of these outcomes, settling
on a 25% likelihood for the high-level estimate, a 60% likelihood for the medium-level
estimate, and a 15% likelihood for the low-level estimate. Based on the sales projections and
the probability estimates, a weighted average estimated sales ﬁgure was computed for each
revenue stream.
For example, for individual downloads,
Expected sales 5 (900,000 * .25) 1 (750,000 * .60) 1 (550,000 * .15)
5 225,000 1 450,000 1 82,500
5 757,500
These projections are summarized in Figure 1-6.
After analyzing the survey results, Carly and her staﬀ were conﬁdent that the sales projections and probability estimates were as accurate as they could make them this early in the
project. The completed system request is shown in Figure 1-5.
Steering Committee Approval Carly Edwards presented the system request for the digital music
download project to the Tune Source project steering committee at its next meeting. Response to
the request was uniformly positive. The strong support for the project by John, Megan, and Phil, the
company’s top executives, helped to spur the committee’s rapid approval of the project. Following
approval of the system request, Jason Wells, a senior systems analyst in the IT department, was
assigned to work with Carly to develop a preliminary feasibility analysis for the project.
Sales Projections
Individual Downloads
Subscriptions
$900,000
$1,100,000
$250,000
$180,000
Medium-level estimate
(prob. = 60%)
750,000
950,000
200,000
150,000
Low-level estimate
(prob. = 15%)
550,000
700,000
150,000
120,000
$757,500
$950,000
$205,000
$153,000
High-level estimate
(prob. = 25%)
FIGURE 1-6
Sales Projections for
Tune Source Digital
Music Download
Project
Weighted average
expected sales
Cross-Selling of CDs
Gift Cards
18 C ha pt er 1 The Systems Analyst and Information Systems Development
FEASIBILITY ANALYSIS
Once the need for the system and its business requirements have been deﬁned, the approval
committee authorizes the systems analyst to prepare a more detailed business case to better
understand the proposed information system project. Feasibility analysis guides the organization in determining whether to proceed with the project. Feasibility analysis also identiﬁes
the important risks associated with the project that must be managed if the project is
approved. As with the system request, each organization has its own process and format for
the feasibility analysis, but most include techniques to assess three areas: technical feasibility,
economic feasibility, and organizational feasibility (Figure 1-7). The results of evaluating
these three feasibility factors are combined into a feasibility study deliverable that is submitted to the approval committee.
You might wonder at the omission of the element of time as a risk factor for the project.
While the time available for a project can certainly be a concern, we consider time to be a
project management issue. We will discuss project management strategies that can be used
when time is tight in Chapter 2.
Although we will discuss feasibility analysis now within the context of project initiation,
most project teams revise the 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 beneﬁts, the project team may decide to cancel the project or make substantial
revisions.
Technical Feasibility
The ﬁrst issue in the feasibility analysis is to assess the technical feasibility of the project, 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 the question: “Can we build it?”3
Technical Feasibility: Can We Build It?
•
•
•
•
Familiarity with application: 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 will be.
Economic Feasibility: Should We Build It?
•
•
•
•
FIGURE 1-7
Feasibility Analysis
Assessment Factors
A template for this
figure is available on
the student web site
Development costs
Annual operating costs
Annual benefits (cost savings and/or increased revenues)
Intangible benefits and costs
Organizational Feasibility: If We Build It, Will They Come?
•
•
•
•
•
3 We
Is the project strategically aligned with the business?
Project champion(s)
Senior management
Users
Other stakeholders
use the words “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?”
Feasibility Analysis 19
Many risks can endanger the successful completion of the project. First and foremost is
the users’ and analysts’ familiarity with the application. When analysts are unfamiliar with the
business application area, they have a greater chance of misunderstanding the users or missing
opportunities for improvement. The risks increase dramatically when the users themselves
have limited knowledge of the application. If the project involves a new business innovation,
neither the users nor the analysts may have any direct knowledge or experience of the proposed new application. 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 and delays will occur because of the need to learn how to use the technology. Risk increases dramatically when the technology itself is new (e.g., a Big Data project
using Hadoop). When the technology is not new but the organization lacks experience with it,
technical risk is reduced somewhat, since outside expertise should be available from vendors
and consultants.
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 number
of distinct features in the system. Larger projects present more risk, because they are more
complicated to manage and because there is a greater chance that some important system
requirements will be overlooked or misunderstood. Large systems are typically highly integrated with other systems, increasing project complexity.
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 have numerous systems already in place. New technology and
applications need to be able to integrate 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 infrastructure. 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 customer service systems.
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 does a project need to grow before it is considered “big”?). One approach is to compare the project with
prior projects undertaken by the organization. Another option is to consult with experienced
IT professionals in the organization or with external IT consultants; often, they will be able to
judge whether a project is feasible from a technical perspective.
Economic Feasibility
The second element of a feasibility analysis is to perform an economic feasibility analysis (also
called a cost–beneﬁt analysis). This attempts to answer the question “Should we build the
system?” Economic feasibility is determined by identifying costs and beneﬁts associated with
the system, assigning values to them, calculating future cash ﬂows, and measuring the ﬁnancial worthiness of the project. As a result of this analysis, the ﬁnancial opportunities and risks
of the project can be understood. Keep in mind that organizations have limited capital
resources and multiple projects will be competing for funding. The more expensive the project, the more rigorous and detailed the analysis should be. Before illustrating this process
with a detailed example, we ﬁrst introduce the framework we will apply to evaluate project
investments and the common assessment measures that are used.
Cash Flow Analysis and Measures IT projects commonly involve an initial investment that
produces a stream of beneﬁts over time, along with some ongoing support costs. Therefore, the
20 C ha pt er 1 The Systems Analyst and Information Systems Development
value of the project must be measured over time. Cash ﬂows, both inﬂows and outﬂows, are
estimated over some future period. Then, these cash ﬂows are evaluated using several techniques
to judge whether the projected beneﬁts justify incurring the costs.
A very basic cash ﬂow projection is shown in Figure 1-8 to demonstrate these evaluation techniques. In this simple example, a system is developed in Year 0 (the current year)
costing $100,000. Once the system is operational, beneﬁts and on-going costs are projected
over 3 years. In row 3 of this ﬁgure, net beneﬁts are computed by subtracting each year’s total
costs from its total beneﬁts. Finally, in row 4, we have computed a cumulative total of the net
cash ﬂows.
Two of the common methods for evaluating a project’s worth can now be determined.
Each of these calculations will be explained here:
Return on Investment The return on investment (ROI) is a calculation that measures the
average rate of return earned on the money invested in the project. ROI is a simple calculation
that divides the project’s net beneﬁts (total beneﬁts – total costs) by the total costs. The ROI
formula is:
ROI 5
Total Benefits 2 Total Costs
Total Costs
ROI 5
152,000 2 138,000
14,000
5
5 10.14%
138,000
138,000
A high ROI suggests that the project’s beneﬁts far outweigh the project’s cost, although
exactly what constitutes a “high” ROI is unclear. ROI is commonly used in practice; however,
it is hard to interpret and should not be used as the only measure of a project’s worth.
Break-Even Point Another common approach to measuring a project’s worth is the break-even
point. The break-even point (also called the payback method) is deﬁned as the number of years it
takes a ﬁrm to recover its original investment in the project from net cash ﬂows. As shown in
row 4 of Figure 1-8, the project’s cumulative cash ﬂow ﬁgure becomes positive during Year 3, so
the initial investment is “paid back” over two years plus some fraction of the third year.
(In the year in which Cumulative Cash Flow turns positive):
Number of years
That year’s Net Cash Flow 2 That year’s Cumulative Cash Flow
BEP = of negative cash 1
That year’s Net Cash Flow
flow
Year 0
Total Benefits
FIGURE 1-8
Simple Cash Flow
Projection
Year 1
Year 2
Year 3
Total
45,000
50,000
57,000
152,000
Total Costs
100,000
10,000
12,000
16,000
138,000
3
Net Benefits
(Total Benefits – Total Costs)
(100,000)
35,000
38,000
41,000
14,000
4
Cumulative Net Cash Flow
(100,000)
(65,000)
(27,000)
14,000
Feasibility Analysis 21
Using the values in Figure 1-8, the BEP calculation is:
BEP 5 2 1
41,000 2 14,000
28,000
521
5 2.68 years
41,000
41,000
The break-even point is intuitively easy to understand and does give an indication of a
project’s liquidity, or the speed at which the project generates cash returns. Also, projects that
produce higher returns early in the project’s life are thought to be less risky, since we can
anticipate near-term events with more accuracy than long-term events. The break-even point
ignores cash ﬂows that occur after the break-even point has been reached; therefore, it is
biased against longer-term projects.
Discounted Cash Flow Technique The simple cash ﬂow projection shown in Figure 1-8, and
the return on investment and break-even point calculations all share the weakness of not recognizing the time value of money. In these analyses, the timing of cash ﬂows is ignored. A dollar in
Year 3 of the project is considered to be exactly equivalent to a dollar received in Year 1.
Discounted cash ﬂows are used to compare the present value of all cash inﬂows and
outﬂows for the project in today’s dollar terms. The key to understanding present values is to
recognize that if you had a dollar today, you could invest it and receive some rate of return on
your investment. Therefore, a dollar received in the future is worth less than a dollar received
today, since you forgo that potential return. If you have a friend who owes you $100 today, but
instead gives you that $100 in 3 years—you’ve been had! Assuming you could have invested
those dollars at a 10% rate of return, you will be receiving the equivalent of $75 in today’s terms.
The basic formula to convert a future cash ﬂow to its present value is:
PV 5
Cash flow amount
, where n is the year in which the cash flow occurs.
(1 1 Rate of return) n
The rate of return used in the present value calculation is sometimes called the required
rate of return, or the cost of obtaining the capital needed to fund the project. Many organizations will have determined the appropriate rate of return to use when analyzing IT investments. The systems analyst should consult with the organization’s ﬁnance department.
Using our previous illustration, $100 received in 3 years with a required rate of return of
10% has a PV of $75.13.
PV 5
100
100
5
5 75.13
3
(1 1 0.1)
1.331
In Figure 1-9, the present value of the projected beneﬁts and costs shown in Figure 1-8
have been calculated using a 10% required rate of return.
Year 0
FIGURE 1-9
Discounted Cash
Flow Projection
Year 1
Year 2
Year 3
Total Benefits
45,000
50,000
57,000
PV of Total Benefits
40,909
41,322
42,825
Total Costs
100,000
10,000
12,000
16,000
PV of Total Costs
100,000
9,091
9,917
12,021
Total
125,056
131,029
22 C ha pt er 1 The Systems Analyst and Information Systems Development
Net Present Value (NPV) The NPV is simply the diﬀerence between the total present value of
the beneﬁts and the total present value of the costs.
NPV 5 © PV of Total Benefits 2 © PV of Total Costs
5 $125,056 2 $131,029 5 ($5,973)
As long as the NPV is greater than zero, the project is considered economically acceptable.
Unfortunately for this project, the NPV is less than zero, indicating that for a required rate of
return of 10%, this project should not be accepted. The required rate of return would have to
be something less than 6.65% before this project returns a positive NPV. This example illustrates the fact that sometimes the “naïve” techniques of ROI and BEP ﬁnd that the project
appears acceptable, but the more rigorous and ﬁnancially correct NPV technique ﬁnds the
project is actually unacceptable.
Figure 1-10 reviews the steps involved in performing an economic feasibility analysis.
Each step will be illustrated by an example in the upcoming sections.
Identify Costs and Beneﬁts The systems analyst’s ﬁrst task when developing an economic
feasibility analysis is to identify the kinds of costs and beneﬁts the system will have and list them
along the left-hand column of a spreadsheet. Figure 1-11 lists examples of costs and beneﬁts that
may be included. The costs and beneﬁts can be broken down into four categories: (1) development
costs, (2) operational costs, (3) tangible ben…

Turn in your highest-quality paper
Get a qualified writer to help you with

“ MIS 396W Cuyamaca College Technical Writing Self Reflection Paper ”

Get high-quality paper

Guarantee! All work is written by expert writers!

Still stressed from student homework?

Get quality assistance from academic writers!

Order now