Scott Tilley - Systems Analysis and Design-Cengage (2020)

·-
#"" '- CENGAGE

': .. CENGAGE
Aus1ral1a • Brazol • Mexico · Singapore · United Kmgdom • Un11ed S1a1es
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Thi\ i~ an clcctmnic vc,...ion of Lhc print 1cx1book. Due to electronic rights rc,1ricuons,
some third p:u1y conlcnt may be >uppressed. Edilorial review has deemed Lhat any suppressed
content doc> not materially affect the overall learning experience. The publil.her rc>crve~ the right
10 remove contem from thi• title at any time if sub11Cquent rights restriction• require it. For
valuable information on pricing. previou• editions. change• Lo current edilinn<. and al1ema1c
formats. please visit www.ccnu~<: com/bj~hen:d to search by ISBNll. author. 1ille. or keyword for
muccrial\ in your areas of interest.
lmponant oticc: Media contcnl referenced \nthin the produce descripuon or the product
text may not be available in the eBook \er..ion.
('.,.,...Jlt..,..,........., "' ..-. ""' . . .................. . ......"""'."'"""<"'.,.. Dartn .......... "'" •.-.........,,
......., ....,....,....,.,.......,,
... ~--. . ~~~
C.....""_..,...._..,...,. ....,....._.,.,...._• .._,. ......,~.n....-..-..ilk...,.~C~ ......_ __......_..,,,.. ..__........_..., _..... 4 ......,__........._• .,._.1111:

,:_ CENGAGE
Systems Analysls and Design, Twelfth Edition
Scott Tilley
SVP. Higher Educatton Prodlm Management:
Enn Joyner
VP. Product MaNgement Mike Schenk
Product Otre<tor.1.Auren Murphy
Product Team Manager Krosun McNary
Product Manager JaylT'Me Falconi
Product As5'Stant. Anna Goulart
Oire<1or, LHrnong Design Rebecu von Glllern
SenK>r Manager, learning Otsigr• Leigh Hefferon
Learning Designer· Emily Po~
Vice Preslden~ Marketing - Science, Technology,
& Math Jason Sakos
Senior Marketing D1re<1or: Michele McTlghe
Execu1lve Marketing Monoger: Cossle Cloutier
Product Speclallst: Mackenzie Paine
Director, Content Creation: Juliet Steiner
Senior Manager, Content Creation: Pauy S1ephan
Cement Manager: Michele Stulgo
Technical Editor: John Freitas
Director, Digital Producllon Services:
Krista Kellman
Digital Delivery Lead· Justin Maniaci
Designer: Uzz Anderson
Proctucuon ~rvlce/Compos.llon. Lum1na
O..tamaiocs. Ltd.
Cover unage iStock.com/Nongkran_ch
O 2020. 2017 Cengage learning. Inc
Unless otherwise noted, aH content ls Cl Cengage.
WCN: 02·300
ALL RIGHTS RESEl!VEO. No part of this work CO\lt!red by lhe copyright
herein may be reproduced or d1s111buted on any form or by any means.
except as permitted by U.S. copyright law. without the pnor written
pennissi<>n of the copyright owner
For product informatlOfl and technology asslsta~. contact us a1
Cengage Customer & Sales Support, 1-IOC>-3S4-9706or
support.cengage.com.
L
For permlss!On to use mateflal from this text or product.
submit all requests onlone at www.cengage.com/permlsslons.
Library of Congress Control Number PCN to come
ISBN: 978-0-357· 11781-1
Cengage
20 Channel Center Sueet
Boston, MA02210
USA
Cengage is a leading provider of customized learning soludons with
employees residing in nearly 40 dlfferem coumrles and sales In more
than 125 countries around the world. Fond your local repre~n tatlve at
www.cengage.com.
Cengage pro<lucts are represented in Canada by Nelson Educallon, l td.
To learn more about Cengage platforms and services. reglste< or access
your on lone leamlng solution. or purchase materials for your course, Visit
www.cengage.com.
Notice 10 the Reader
Publisher does not warrant or guarantee any or the produos descnbed herein or perform any Independent analySis in connecttOn Wlth
any of the product Information conta•ned herein. Publisher does not assume. and expressly disclaims. •"'I obliga11on 10 obtain and
Include riformatlon olher than that prOVlded to 11 by the manufacturer. The reader os expressly warned to consider and adopt all saftty
pre<auhons th.it might be •ndiC.lled by the actMties destnbed herein and IO a\IOid all po<enUal hazards By lolowrig the lll>tructions
conta1Md herein. the reader wi hngly assumes all rlsl<s In collllKtlorl With such instructooros. The pubftsher makes no repr~ntations or
warranties of a"J lund, 1nclud1ng but not lim ted 10, the warran11es of fimess fot parucular purpose or mercharGblltlY, nor are arty such
representations Implied with respect to the matenal set forth here•n. and the pubhsher takes no responsibility with re11>Kt to such
ma1erlat. The publisher shall noc be liable for any special consequenual, or exemplary damages resulting. In whole or p;in. from 1he
readers' use of, or rehanot upon. this material
Printed in 1he United S1a1es of America
Print Number: 01 Print Year: 20 19
r...,,,.._ a-oc,,.,..~ .u ._~.a "'' ·~ 11ir .. ...., ~ -~·-· .. ....,"'".,.. nw~•..-.. ,..."''"_..,....., , ..... ""..., tir ~,._._~ .,..., -<.....,._~~
r.....l __ .._......,..,_..,.,............_.,.....,..._...,.....,_..,.,,_., ._..~~a-.e.._..,...,.,,._. __ .....,.__.t__.•.._a..,.. .......... ,......_... ..........

iii
DEDlCATION
To all of my students - past, present, and future
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ... lllil__.~.t
•......w~~-._....,..,....., ........ _. _ _..........,....,. ... .-;11-...~~c-,,....i.__..~w._.._ ........ __ ..,.._.,......,..._..,....._...., ..

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
v
BRIEF CONTENTS
PHASE I: SYSTEMS PLANNING 001
Chapter I Introduction co Systems Analysis and Design 002
Chapter 2 Analyzing the Business Case 044
Chapter 3 Managing Systems Projecrs 074
PHASE 2: SYSTEMS ANALYSIS 103
Chapter 4 Requirements Engineering 104
Chapter s Data and Process Modeling 144
Chapter 6 Object Modeling .1 80
Chapter 7 Development Strategies 200
PHASE 3: SYSTEMS DESIGN 227
Chapter 8 User Interface Design 228
Chapter 9 Data Design 268
Chapter 10 System Architecture 316
p
~
•
10
Chapter 11 Managing Systems Implementation 352
PHASE: · S STEMS SUPPORT AND SECURITY 399
Chapter 12 Managing Systems Support and Security 400
Glossary 453
Index 471

vi
TABLE OF CONTENTS
PHASE I : SYSTEMS PLANNING
Introduction to Systems Analysis
and Design
Learning Objectives
I. I Information Technology
I. I.I The Changing Nature of Information Technology
1.1.2 Synems Analysis and Design
1.1.3 What Does a Systems Analyst Doi
1.2 Information System s
1.2.1 Hardware
1.2.2 Software
1.2.3 Data
1.2.4 Processes
1.2.S People
Case In Point I. I. Data B~. che
1.3 Internet Business Strategies
1.3.1 The lnttrnet Model
I .J 2 82C (BuS1ncsMo·Consumer)
I .J.3 828 (Business·tO· Buslness)
1.4 Modeling Business Ope rations
1.5 Busines$ Informa tion Systems
1.5 I Enterpriu Computing
l.S.2 T rmuccion Processang
I .SJ Business Support
l.S.4 Knowled&e Mana&e"*"
I .S.5 User Producov1ty
I .S 6 D1giul Assistants
1.5 .7 Systems lnteinuon
C..• ~ 1n P.
t I 2: Au 1n• '"'° ~ h I •
1.6 Organiu.tional Information Models
1.6 I Functions and Organlzadonal l.eve:s
1.6.2 Top Man~ers
1.6.3 Middle Maniiers •nd Know1ed&• Worker>
1.6.4 Supervisor> and Team Leaders
1.6.5 Operadonal Employees
2
3
3
4
"
4
5
5
6
7
7
8
8
8
8
9
9
11
II
II
12
13
14
15
15
5
16
16
16
17
17
17
1.7 Systems Deve lopment 17
1.7.1 StructuredAnalysls 18
1.7.2 Object-Oriented Analysis 2 1
1.7.3 Agile Methods 22
1.7.4 Prototyping 24
1.7.5 Tools 24
1.8 The Information Technology Department 26
1.8.1 Appllcatlon Development 27
C;ue in Point 1.3: Global Hotel~ and Momma's Motels 27
1.8.2 Systems Support and Security 27
1.8.3 User Support 28
1.8.4 D•toboseAdmlnt>trotJon 28
1.8.5 Network Adminlstrodon 28
1.8.6 Web Support 28
1.8.7 Qu>l1ty Assuranco (QA) 28
I. 9 The Systems Analyst
1.9.1 Role
1.9.1 Knowledge. SIUlb. and Ecb::auon
l.9J Certification
1.9.4 c..reer Opportunities
1.9.5 Trends"' lnformabon Technology
A Question of Ethics
1.10 Summary
Key Terms
Exercises
Analyzing the Business Case
Learning Objectives
2. I Strategic Planning
2.1 .1 Strategic Planning Overview
Case in Point 2.1; Pets for Rent
2.1.2 SWOT Analysis
2.1 J The Role of the IT Dep1rtmenc
2.1 Strategic PlanningTools
2.l The Business Case
2.4 Systems Requests
2.5 Factors Affecting Syste m s Projects
2.5. 1 lntern>I Factors
2.5.1 Extern>! Factors
2.6 Processing Systems Requests
2.6.1 Sys<ems P.equen forms
2.6.2 Systems Request Tools
2.63 Systems Review Committee
Case 1n P"'nt 2 1: At '"' y A1r1 " , P.art On~
2. 7 Assessing Request Feasibility
2.7.1 Feuibtlity Studies
2.7.2 Operauon>l FeaS1bthty
2.7.3 Ecooom<e Feasib1l1ty
2.7.4 Teclvlical F<!asibillty
2.7.5 Schedule Feasfblllty
2.8 Setting Priorities
2.8.1 Dynamic Priorities
2.8.2 F•«ors That Affect Priority
2.8.3 Discretionary and Nondlscretoonary Projects
Case in Point 2.3: Attaway Airline , Part Two
2. 9 The Preliminary Investigation
2. 9.1 Planning the Preliminary lnvesclgadon
2.9.2 Performing tho Preliminary lnvesdgatlon
2. 9.3 Sumtmn•mg the Preliminary lnvestlg-.tion
A Question of Ethics
2. 10 Summary
Ke:yTerms
Exercises
28
28
29
31
32
33
35
35
37
42
44
45
45
45
45
46
47
47
49
so
50
52
54
54
54
54
SS
56
56
57
57
58
58
S9
59
59
60
60
60
61
61
68
69
69
70
72
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Table o f Contents
vii
Managing Systems Projects
Learning Objectives
3. 1 Overview of Project Management
3.1 I Whn Sh>peS a Project•
3.1 2 What Isa Project Tnansfe'
3.1.3 What Does a Protect ~nager Do'
3.2 Creating a W ork Breakdown Structure
3.2.1 Gontt Clwu
3.2.2 PERT/CPM Charts
3.2.3 ldent1fyi11g Tasks In a Wori< B<cakdown Structure
Ca•~ in Point l. I . S onri Sottw;i.n
3.2.4 Foctors Affecting Dul'O\don
3.2.S Displ;ay111g the Wori< Breakdown Structure
3.3 Task Patterns
3.3.1 Using Task Boxes to Create a Model
3.3.2 Task Pattem Types
3.3.3 Working with Complex Task Pattems
Case In Point 3.2: Parallel Services
3.4 The Crltica.I Path
3.4.1 Calculacing the Cntlcol Path
3.5 Project Monitoring and Control
3.S. I Monitori11g and Contra I Techniques
3.S.2 Malntolnin& • Schedule
3.S.3 Tasks and the Critical Poth
J.t Reporting
3.6 I Project Status M .. anis
3.6.2 Project Statui Rtporu
3.63 0..long woth Problems
3.7 Project Management Software
3.8 Risk Management
3.9 Managing for Success
C. P, 1t l J 1me Software
3 9 I Buslnen luues
3.9.2 Budget Issues
3.9.3 Schedule Issues
A Question of Ethics
3. 10 Summary
Key Terms
Exer cises
PHASE 2 : SYSTEMS ANALYSIS
Chapter 4
Requirements Engineering
Learning Objectives
4. 1 Syste m Req uirements
4.1.1 Types of Requoremenu
4.1.2 Requlremenu Challenges
4.1.3 Additional Conslderatlons
4.2 Team-Based Techniques
4.2.I )olntAj>pl1ca11on 0..elopment
Case in Point 4.1: North Hills College
74
75
7S
7S
76
76
76
n
78
80
80
81
82
82
83
8"
SS
85
85
87
87
87
87
1)7
88
88
88
89
93
94
95
95
95
96
96
96
98
100
104
105
105
106
107
108
109
111
4.2.2 Rapid Apphcadon Development
4.2.3 Agile Methods
4.3 Gathering Requirements
4.4 Gathering Requirements Through Interviews
4.4.1 The lnterv>ew Process
4.5 Gathering Requirements Using Other
Techniques
4.5.1 Document Review
4.S.2 Observation
4.5.3 QueJtionnaires ond Su~
4.S.4 Interviews Venus Quescionnaires
4.S.S S...ns«>rmin&
4.5.6 Sampling
4.S 7 Research
Case in Point 4.2: CyberStuff
4.6 Gathering Re quirements In Aglle Projects
4.7 Representing Requirements
1.7.1 Natural Language
Case in Point 4.3: Digital Pen Transcription
... 7.2 Diagrams
1.7.3 Models
4.8 Validating and Verifying Requirements
4.9 Tool.s
A Question of Ethics
4. 10 Summary
Key Te rms
Exercises
Chapter S
Data and Process Modeling
Leaming Objectives
5.1 Logical Versus PhysicaJ Models
5.2 Data Flow Diagrams
S.3 Data Flow Diagram Symbols
5 3 I Proun Symbol>
5.3.2 Data Flow Symbols
5.3.3 Data Store Symbols
5.3.4 Enticy Symbols
5.3S Usin& DFD Symbols
5.4 Drawing Data Flow Diagrams
5.5 Drawing a Context Diagram
5.6 Drawing a Diagram 0 DFD
S.7 Drawing Lower-Level DFDs
Case In Point 5.1 : Big Ten University
5.8 Data Dictionary
5.8.1 Documenting the Data Eltmenu
5.8.2 Documentinc the Data Rows
5.8.3 Documenting the Data Stores
5.8.4 Documenting the Processes
5.8.5 Documentm& the En"tles
5.8 6 Documenung the Records
5.8.7 Data Dlcuonary Reporu
5.9 Process Description Tools in Modular Design
5.9.1 Procen Descnpcions 1n Obiect·Oriented [)eo.lelopmen1
S.9.2 Modubr Design
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
111
113
114
116
116
12 1
122
122
123
124
115
125
126
127
127
128
128
129
129
13 I
Ill
134
137
137
139
142
144
145
145
146
147
147
149
ISi
152
152
154
155
158
163
164
161
165
166
167
167
167
168
169
169
169

viii
Table of Conte nts
5.9.J Slt\ICtured En&hsh
5.9.4 Dec1si0n T~es
Case in Point 5 .2 : Rock Solid Outfitters (Part I)
5.9 .S DeclSlO!'I Trees
use in Point 5.3 : Rock Solid Outfitters (Part 2)
A Question of Ethics
5. 1 0 Summary
Key Terms
Exercises
Chapter 6
Object Modeling
Learning Objectives
6.1 Object-Oriented Analysis
Case In Point 6. 1: Travel Biz
6.2 Objects
6.3 Attributes
6.4 Methods
6.5 Messages
6.6 Classes
6.1 Relationships Among Objects a.nd Classes
6.8 The Unified Modellng language (UML)
6.8. I Use Cue Mod~1n1
6.8.2 Use Cue Ofagnms
Case in Point 6.l : Hilltop Moton
6.8..3 Cius 01ograms
use in Point 6 .3: Train the Trainers, Inc.
6.8.4 Sequence O.airams
6.8.S State Transition Oiograms
6.8.6 Activity Diagrams
6.8.7 Susineu Process Modeling
6.9 Tools
A Question of Ethics
6.1 0 Summary
Key Terms
Exercises
Chapter 7
Development Strategies
Learning Objectives
7. 1 Traditional Versus Web-Based Systems
Development
7.1.I Traditional Oevelopmenc In a U'ldltlonal systems
development environment
7 .1.2 Web-Based Oevalopmenc: In a web-based systems
development environment
7 .2 Evolving Trends
7.3 In-House Software Development Options
73.1 Make or Buy Decision
7 .3 l Developing Softw1re In-House
7 33 Purclwin1 • ~ Pac.kage
170
170
174
175
175
176
176
177
179
180
181
181
181
183
183
183
184
186
187
187
189
189
l'JO
191
192
192
193
194
195
195
195
197
199
200
201
201
201
202
203
203
204
205
7.3.4 Custom1%1ng •Software Pad<ogc 206
7 .3.S Cre.tlng User Appli<att0ns 207
Case in Point 7 . 1: Doug's Sporting Goods 108
7 .4 Outsourcing 208
7.4. I The Growth ol Ouuourc"'I 108
7.4.2 Outsouran& Fees 209
7A3 Ouuourong Issues and Concerns 1 10
7 .5 Offshoring 210
Case in Point 7.2: Turnkey Services 211
1.6 Software as a Service 211
7.7 Selecting a Devefopment Strategy 211
7.7. I The Systems Analysts Role 212
7.7.2 Analyzing Cost and Bcnefiu 212
7.7.3 Cost-Benef1tAnalysls Checkllot 213
Case in Point 7.3: Ster1ingAssoclates 214
7.8 The Software Acquisition Process 214
Step I: Evaluate che Information Synem Requirements 214
Step 2: Identify Potential Vendors or Outsouroing Options 2 I 6
Step 3: Evaluate the Alternatives 217
Step 4: Perform Cost-Benefit Analysis 219
Step S: Prepare a Recommendation 219
7.9 Completion ofSyscemsAnalysisTasks 219
7.9.1 System Requirements Document 219
7.9.2 Presentation to Management 220
7.9.3 Transition to Systems Des1&n 221
A Question of Ethics 222
7. 10 Summary 222
KeyTefms 224
Exercises 226
PHASE 3 : SYSTEMS DESIGN
Chapter 8
User Interface Design
Leaming Objectives 228
8.1 User Interfaces 229
8.2 Human-Computer Interaction 230
Case in Point 8. 1: Casual Observer Software 232
8.3 Seven Habits of Suceessful Interface Designers 232
8.3.1 Undeni:and the Busman 232
8.3.2 Maxlml1e Graphical Effectiveness 232
8.3.3 Think like a User 233
8.3.4 Use Models and Prototype> 233
8.3.5 Focus on Usability 233
8.3.6 Invite Feedback 233
8.3.7 Document Everythln& 234
8.4 Guidelines for User Interface Design 234
8.4.1 Create an Interface That Is Easy to Learn and Use 234
8.4.2 Enhance User Producuvlty 235
8.4.3 Provide Flexibility 236
8.4.4 Provide U1en wich Help and Feedback 236
8.4.5 Create an Atll'lctove Layout and Oesl&n 137
8.4.6 Enhance che Interface 238
8.4.7 Focus on Oaa Entry Screens 240
8.4.8 Use Validation Rules 143
8.4.9 Manoge Data Effectro'Oly 245
8.4.10 Reduce lnputVolume 145
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
Table o f Contents
ix
Case in Point 8.l : Boolean Toys
8.5 Source Document and Form Design
8.6 Printed Output
8.6.1 Report ~'II'
8.6.2 Report ~lgn Pnndples
8.6.3 Tn- of R"'°ru
Ca.e in Point 8.3: Luy Eddie
8.7 Technology Issues
8.7.1 Output Technology
8.7.2 Input TechnolocY
8.8 Security and Control Issues
8.8. I 0uq>Vt Secumy and Control
8.8 2 Input Securtl}' and Control
8.9 EmergingTrends
8.9.1 Modulor Deslsn
8.9.2 Re•pon•lve Web Design
8.9.3 Prototyp1n1
A Question or Ethics
8.10 Summary
Key Terms
Exercises
Chapter 9
Data Design
Learning Objectives
9. 1 Data Design Concepts
9.1.1 O.ta Scructures
9.1.2 Mano and o.,,.ca: Ao.a cnsiin Ex.omple
9.1.3 Database Manaaement Systems
9.1 DBMS Components
9.2. I lnU!rfaces lor Usen, Database Administrators. and
Related Systems
9.2.2 Schema
9.2.3 Physical Data Repository
9.3 Web-Based Design
9.4 Data Design Terms
9.'4.1 Definitions
9.'4.2 Key Field•
9.'4.3 Refttential Integrity
9.5 Entity-Relationship Diagrams
9.5.1 Drawing an ERO
9.5.2 Typos of Refadon•hlps
9.5.3 Cardinality
Case In Point 9. 1: Top Text Publishing
9.6 Data Normalii.ation
9.6. I Saindard Notation Format
9.6.2 First Normal Form
9.6.3 Second Normal Form
9.6.'4 Third Normal Form
Case In Point 9.2: CyberToys
9.6.S Two Re>l-World Examples
9.7 Codes
9.7. 1 Ottrv.-ofCodes
9.7.l Types of Codes
9.1.3 Designing Cod.s
2'46
146
2'47
2'48
248
250
251
251
252
25'4
255
255
156
257
257
158
258
260
260
262
266
268
269
269
269
271
272
273
2n
273
274
275
175
276
279
280
180
180
183
284
284
285
286
287
290
291
291
297
297
298
299
Case 1n Point 9.3= Madera Tools
9.8 Data Storage and Access
9 8.1 Tools and Techniques
9.8.2 Logial Venu• Phytical Storage
9 8.3 O.ta Cod•ng
9.9 Data Control
A Question or Ethics
9.10 Summary
KeyTe,.ms
Exercises
Chapter 10
System Architecture
Learning Objectives
I 0. 1 A,.chitecture Checklist
I 0.1.1 Corporat0 Organludon and Culture
I 0.1.2 Enterprise Resource Planning (ERP)
I 0. 1.3 lnltQI Cost and TCO
I 0. 1.'4 Sal•b•lity
I 0. 1.S Web Integration
I 0.1.6 Legacy Systems
10. 1.7 Processing Options
I 0.1.8 Security Issues
10.1 9 Corporote Portals
Case in Point 10.1 ABC Sy.terns
I O.l The Evolution of System Architecture
I 0.2.1 Mainframe Arch1tec:wre
I O.l.l Impact of the Ptrsonal Computer
I 0.2.3 Network Evoluuon
I 0.3 Client/Server An:hitecture
10.3 I The Client's Role
I 0.3.2 OoentJSeM1er Tiers
I 0.3.3 M1ddleware
10.3.'4 Cost-Benefit luues
10.3.S Ptrformanco Issues
I 0.4 The Impact of the Internet
10.4 .I lntemet·BuedArchiteca.o,.
I 0.'4 2 Cloud Computing
10.4.3 Web 2.0
I 0.5 E-Commerce Architecture
I 0.5.1 In-House Solutions
I 0.5.2 Packaged Solu11ons
I 0.5.3 Service Providers
Case in Point I O.l . Small Potatoes
I 0.6 Processing Methods
I 0.6.1 Online Processing
I 0.6.2 Batch Processing
I 0.6.3 Example
10.7 Network Models
I 0.7. 1 The OSI Model
10.7.2 NetworkTopology
10.7.3 Network Devices
I 0.8 W ireless Networks
I 0.8.1 Stand•rds
I 0.8 2 Topolog1u
1083 Trends
300
301
301
302
303
305
306
306
308
313
316
317
317
317
318
319
319
319
320
320
320
321
321
321
322
322
323
324
325
326
326
327
327
328
328
329
329
330
33 1
33 1
332
332
332
333
333
334
331
335
337
338
338
339
339

x
Table of Contents
Case In Point I 0 .3: Spider IT Services
10.9 Systems Design Completion
10.9.1 System DHlgn Speclflcauon
I 0.9.2 Us..-ApprCMI
10 9.3 PreS4'lc11lons
A Question of Ethics
I 0.1 0 Summary
Key Terms
Exercises
340
341
341
3'12
342
3 43
343
346
350
'--
I
I l.93 Dati Conve.-..on
11.9.4 Training
11.9.S Post-lmplementadon Tasks
~
tdwtrica
A Q uestion of Ethics
I I. I 0 Summary
Key Terms
Exercises
382
383
387
391
391
394
398
PHASE 4 : SYSTEMS
IMPLEMENTATION
PHASE S : SYSTEMS SUPPORT
AND SECURITY
Managing Systems Implementation
Managing Systems Support
and Security
Learning Objectives
11 .1 Quality A ssurance
I I. I. I Softw.lre Englneerlnc
I 1.1.2 Systems Engineering
I 1.13 International Organization for St»ndardlution
I 1.2 Application Development
11.2.1 Review the System Design
I 1.2.2 Application De..lopment Tuks
I l.2J Syncms Development Tools
I I .3 Structured Development
11.J. I Strvcture Chuts
I I 3.2 CohesK>n .nd Coupl 111
11.3.3 Drawing a StrvCture Chart
11 .4 Object-Oriented Developme nt
11.4.1 Charactenstlcs of Object-Onented De-ttlopment
11.4.2 lmplementadon of Obtect-Onented Designs
114.3 Object-Oriented Cohesion and Couplin&
I 1.5 Agile Development
11 5.1 en.-Programml11g
11 S 2 UJ1r Scones
11.5.3 Iterations and Releases
11 .6 Coding
I I. 7 Testing
11.7.1 Unlt Teulng
11.7.2 Integration Tesung
11.7.3 System Tesdng
C:... I M...,.,lnc.
11.8 Docum entation
11.8. 1 Program Documcntodon
11.8.2 System Documentation
11.8.3 Operations Documentition
11.8.4 User Documentitlon
I 1.8.5 Online Documentation
I I • 9 Installation
11.9.1 Operational andTest Environments
11.9.2 System Changeover
352
353
353
3S3
355
356
356
356
357
359
360
361
362
364
365
366
366
367
368
369
369
369
370
370
372
372
3 l
373
374
374
375
375
376
3 78
378
379
Lear ning O bjectives
12. 1 User Support
12.1.1 UserTralnlng
12.1.2 Help Desks
12.1.3 Outsourcing Issues
12.2 Maintenance Tasks
12.2.1 Types of Maintenance
12.2.2 Correctl\'e Maintenance
12.2.3 Adaptm: Mimt~ncc
12.2.4 P..-fectrVe Maintenance
12.2.S ~ntive Maintenance
Case n Po 12 0 0
12.3 Maintenance Management
12.l. I The Mimtenance Te"'"
12.3.2 Maintenance Requests
12.33 Establishing Pnorrt1u
12.l.4 Configuration Management
12.l.S M•intemnce Releases
12.l.6 VersK>n Control
12.3.7 Basehnes
1n:lng, Inc,
12.4 System Performance Manage ment
12.4. I fault Management
12.4.2 Performance and Workload Measurement
12.4.3 Cap•clty Planning
12.5 System Security
12.S. I System Security Concepts
12.S.2 Risk Management
12.S.3 Attacker Promos and Attacks
12.6 Security Levels
12.6.1 Physical Security
Case in Point 12.2: Outer B;mks County
12.6.2 Network Security
12.6.3 Application Security
12.6.4 Ric Security
12.6.S User Security
12.6.6 Procedur.ll Security
400
401
401
401
403
403
404
404
406
406
407
7
408
408
409
410
411
412
412
414
4 14
414
416
417
419
419
420
421
423
423
426
426
429
431
432
434
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
Table o f Contents
xi
c. l'uw 17 C on L 1 Consulting, Inc.
12.7 Backup and Recovery
12.7.1 Global Terrorism
12.7.l Backup f>ojKoes
12.7.3 Business ContJnUtty Issues
12.8 System Retirement
12. 9 Future Challenges and Opportunities
12. 9.1 T..-.nds and Predoc:tJOns
12. 9 l Strateiic Ptann•f\g for IT Pro(euionals
12. 9.3 IT Credentials and Cerofoc:aaon
4)4 12.9.4 CnocalThonkln&Skills
435
12.9.S Cybcretllla
435 A Question of Ethics
435 11.10 Summary
436
Key Terms
437
Exercises
438
438 Glossary
+40
+41
Index
442
442
443
443
446
452
453
471

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

xiii
PREFACE
The Shelly C:ishman Series~ offers the finesr rexes in compurer education. \Ve are
proud char our previous editions of Systems Anafysis and Design have been so well
received by insrructors and srudenrs. Systems Analysis and Design, 12th edition
continues with the innovation, qualiry, and reliabiliry you have come to expect.
T he Shelly Cashman Series dcvelopmenr ream carefully reviewed our pedagogy and
analyzed its effectiveness in reaching roday's srudenr. Conremporary srudents read les~
but need to retain more. As rhey develop and perform skills, students must know how co
apply the skills ro different ~errings. Today's students need co be continually engaged and
challenged to rerain whar they're learning. With chis book, we continue our commitment
to focusing on the user and how the)' learn besr.
Facing a challenging global markerplace, companies need strong IT resources ro 5ur·
vive and compete effecrivcly. Many of today's students will become the systems analysts,
managers, and lT professionals of tomorrow. This text will help prepare them for rho e
roles.
Overview
Systems A nalysis and Design, 12th edition offers a practical, streamlined, and
updated approach to information systems development. Systems analysis and design is a
disciplined process for creating high-qualiry enterprise information systems. An information
system is an amalgam of people, data, and technology to provide support for business
furn 'tiom .. •. As technology evolves, so docs systems analysis. The book cmphasi.i:es
the role of the systems analyst in a dynamic, business-related environment. A !.ystcms
analyst ii. a valued team member who helps plan, develop, and maintain information
systems. Analysrs must be exccllenr communicators with strong analytical and crincal
thinking skills. They must also be business savvy, technically competent, and be cquall)'
comfortable working with managers and programmers. Throughout the book, realworld
examples emphasize critical thinking and lT skills.
I\1any two· and four-year colleges and schools use this book in information systems
and computer science curriculums. The 12th edition includes expanded coverage of
emerging technologies, such as agile methods, cloud computing, and mobile applications.
Thi!> new marcrial complements the updated treatment of traditional approaches
to systems analysis and design.
Using chi~ book, ~tudents learn how to translate business requirements into informa·
tion systems char support a company's strategic objectives. Case srudies and assignments
teach analytical reasoning, critical thinking, and p roblem-solving skills. Numerous projects,
assignments, and end-of-chapter exercises are provided, along with detailed instructor
support material.
Objectives of This Text
Systems Analysis and Design, 12th edition is inrended for a three credit-hour introductory
systems analysis and design course. This rexr is designed ro:
• explain systems analysis and design using an appealing full-color format, numerous
scrcenshors and illusrrarions, and an easy-to-read srylc that invites students ro learn.
• introduce project managemenr concepts early in the systems development process.
• challenge students with a Question of Ethics mini-case in each chaprer that a ks
them to respond to real-life ethical issues in an IT environment.
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ... lllil__.~ .t
•......w~~-._....,..,....., ........ _. _ _..........,....,. ... .-;11-...~~c-,,....i.__..~w._.._ ........ __ ..,.._.,......,..._..,....._...., ..

xiv
Preface
• provide multi-method coverage, including a comparison of structured, objectorientcd,
and agile systems development merhods.
• explain how IT supporcs business requirements in todays intensely competitive environment,
and
• d~ribc major IT devclopmcntS and trends.
New and Updated Feature s in This Edition
Systems Analysis and Design, 12th editio11 offers these exciting new and updated
features:
• Reexamined strucrure and subject coverage to ensure studentS can identify and focus
on the main content readily. Confirmed chat related content has been aligned under
comprehensive section headings to maintain a clear flow of topic and reduce distraction.
• A renewed emphasis on aligning learning objectives with chapter content and assessments.
The learning objectives have been updated and carefully reworded so that
instructors know what m focus 011, and studencs know what is expected of them.
T he questions, discussion t<>pics, and projects have all been updated to better assess
student mastery of the material.
• Updated or replaced many Case in Point mini-cases ro ensure learners arc exposed to
relevant and current examples of real-world business applicanons of key concepts.
• Updated examples of CASE tools reflecting web-based and/or open source offerings.
These cools are often free and are representative of modern systems analysis
solutions.
• Updated screenshots to Microsoft Office 2019 products and Visible Analyst 2016.
Organization of This Text
Systems Analysis and Design, 12th edition contains 12 chapters that reach valuable
cross-functional skills. The chapters are organized into five phases: planning, analysis,
design, implemenrarion, and support and security. A four-part S)•stems Analyst's Toolkit,
now available as an online appendix, reflects the most recenc changes in today's syscems
analysis tools and also includes invaluable resources. Cross-functional toolkits provide
scudents with che basic skills soughc after by organizations hiring systems analysts.
Phase I: Systems Planning
• Chapter 1 - Introduction to Systems Analysis and Design: Chapter l provides an
introduction ro systems analysis and design by describing the role of information
teclmology i.n today's dynamic business environment.
• Chapter 2 - Analyzing the Business Case: Chaprer 2 explains how syscems projects
gee srartcd and how co evaluate a projecc propost1l co determine ics feasibility.
• Chapter 3 - Managing Systems Projects: Chapter 3 describes how to use project
management tools and techniques, and how to plan, schedule, monicor, and report
on n· projects.
c..,....lla'c......,........, A1..,....ai-.en ... ~-..,.~·----·~••klk<9i11,..,_0w.~,,... .. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~ •.
a:.a.ww~ ... ...,,..,.., ..,.......,,,... ........ _.._...,~ .. ., ... cn11.,.__..........,,..-:&-c~..,.--:c--•.,,. .. -~....._.....,.. .... ..,,, ......... ,... ........... ..,._.._

Preface
xv
Phase 2: Systems Analysis
• Chapter 4 - Requirements Engineering: Chapter 4 describes the requirements engineering
process: gathering facts about a systems project, preparing documentation,
and creating models char will be used to design and develop the S)Stem.
• Chapter 5 - Data and Process Modeling: Chapter 5 discusses data and process
modeling techniques that analysis use to show how the system transforms data into
w.eful information.
• Chapter 6 - Object ModcUng: Chapter 6 discusses object modeling techniques rhar
analysts use ro crc:irc a logic:il model.
• Chapter 7 - Development Strategies: Chapter 7 considers various development strategies
for the new system and plans for the transition to the systems design phase.
Phase 3: Systems Design
• Chapter 8- User Interface Design: Chapter 8 explains how to design an effective
user interface :ind how m handle data security and control issues.
• Chapter 9 - Oaca Design: Chapter 9 focuses on the data design skills that arc necessary
for a systems analyst to construct the physical model of the information system.
• Chapter l 0 - System Architecture: Chapter I 0 describes system architecture, which
translates the logical design of an information system into a physical blueprint.
Ph
I
• Chapter 11 - Managing Systems Implementation: Chapter 11 describes application
development, documentation, testing, training, data con,·ersion, and system changeover.
Phoue 5 S !> St.. p - and Securit"
• Chapter 12 - Managing Systems Support and Security: Chapter 12 describes systems
support and sccunry casks char continue throughour the useful file of rhe system,
includmg maintenance, sccuriry, backup and disaster recovery, performance mcasurcmcnr,
and system renremenr.
Online Appendix: The Systems Analyst's Toolkit
• Toolkit Part A - Conuuwiication Tools: Part A of the toolkit discui.ses coinmunication
tools that can help the analyst write clearly, speak effectively, and deliver powerful
presentations.
• Toolkit Part B - CASE Tools: Part B describes CASE tools that be can used co
design, cnn~truct, and document an information system.
• Toolkit Part C- Financial Analysis Tools: Part C demonstrates financial analysis
tools that can used ro measure project feasibility, develop accurate cost-benefit estimates,
and make sound decisions.
• Toolkit Part D - Internet Resource Tools: Part D describes Internet resource cools
chat can be used co locate information, obtain reference material, and monitor IT
trends and developments.
c..., .....31:8C....,:...._ Al ~ ,,_~,..., •WGfd.~•~•.....••,__0.:•*'"-.......-61111,_,,..-_,-.c..........,.._ec... lllil __.~.t
•......w~~- ._...., ..,. ...., ........ _. _ _..........,....,. ... .-;11-...~~c-,,....i.__..~w._.._ ........ _ _ ..,.._.,......,..._..,....._...., ..

xvi
Features
FEATURES
CHAPTER LEARNINGTOOLSAND HOWTHEYWILL HELPYOU
Case In Point: Each chapter includes th.rec brief cases thar provide a comextual business
example for students focused on the key issues covered in the chapter.
A Q uesrion of Ethics: A realistic ethical issue is presented at the end of each chapter.
These examples force you to examine your reactions and how you would respond to
common workplace situations.
Chapter Exercises: The chapter exercises are direct!)• related to the learning objectives.
Your answers to the 10 questions will show that you understand the key points. Five
discussion topics and five projects offer opportunities to dig deeper and learn even more.
MINDTAP FOR SYSTEMS ANALYSIS AND DESIGN
MindTap for Systems Analysis and Design, 12th edition is a personalized, fully onl ine,
digital learning platform of content, assignments, and services that engages students and
encourages them to think critically whlle allowing instn1ctors to easily set their course
through simple customization options.
MindTap is designed to help students master the skills they need in today's workforce.
Research shows employers need c ritical thinkers, troubleshooters, and creative
problem-solvers to stay relevant in our fast paced, technology-driven world. MindTap
helps sn1denrs achieve this with assignments and activities that provide hands-on prac·
rice and real-life relevance. They are guided through assignments rhar help them master
basic knowledge and undersranding before moving on to more challenging problems.
i\1indTap is designed around learning objectives and provides the analytics and
reporting to easily see where the class stands in terms of progress, engagement, and
completion rates. Students can access eBook content in the ~l indTap Reader, which
offers highlighting, note-taking, search and audio, and mobile access. learn more at
www.cengage.com/mindrap.
Co11ceptClips: ConceptClip videos focus learners on a key concept in each chapter and
arc designed ro deepen their understanding of the topic.
Running Case: Based on feedback from readers and instructors, we've created a new
running case to replace the SCR Case from previous editions. The case challenges learners
to apply key systems analysis and design concepts and skills to a realistic scenario
they would encounter in the workplace. The case brings the key concepts and skills of
the chapter rogether in an authentic assignment. The look and feel of rhe case tool has
also been updared ro be an authenric, immersive experience for students.
INSTRUCTOR RESOURCES
We are dedicated to providing you all the tools you need ro make your class a success.
information on all supplementary inaterials can be found on the password-protected
website at logi11.ce11gage.com. If you need help accessing this page, please contact your
(engage representative.
The Instructor Resources include the fo llowing:
• Online Appendix: The Systems Analyst's Toolkit: A 4-parr online appendix reflects
rhc mosr recent changes in today's systems analysis tool .
c..,....lla'c......,........, A1..,....ai-.en ... ~-..,.~·----·~••klk<9i11,..,_0w.~,,... .. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~ •.
a:.a.ww~ ... ...,,..,.., ..,.......,,,... ........ _.._...,~ .. ., ... cn11.,.__..........,,..-:&-c~..,.--:c--•.,,. .. -~....._.....,.. .... ..,,, ......... ,... ........... ..,._.._

About The Author
x v ii
• Instructor's Manual: Contains lecture notes summarizing the chapter sections, figures
and boxed elemenrs found in ever>' chapter, teacher tips, classroom activities, and
quick quives in ,\ilicrosoft Word files.
• PowerPoint Presentations: A multimedia lecture presentation system provides slides
for each chapter, based on chapter objectives.
• Figure Files: Illustrations for every figure in the text in electronic form.
• Solutions to Exercises: Includes solutions for end-of-chapter exercises.
• Test Bank and Test Engine: Test banks include questions for every chapter, featuring
objective-based and critical thinking question types, page number references, and figure
references when appropriate. Cengage Leanling Testing powered by Cognero is a
flexible, online S)•Stem that allows you to:
• author, edit, and manage test bank content from multiple Cengage Leaming solutions.
• create multiple test versions in an insranr.
• deliver rests £rom your LMS, your classroom, or wherever you want.
ABOUT THE AUTHOR
Willi the 12th edition, Scott Tilley becomes the sole author of Systems Analysis and
Design in the Shelly Cashman Series. Dr. Tilley is an emeritus profcs~or at the Florida
Institute of Technology, president and founder of the Center for Technology & Society,
president and co-founder of Big Data Florida, president of the Space Coast chapter of
the international Council of Systems Engineering (IN COSE), and a Space Coast \X'riters'
Guild f ellow. In addirion to this book, he is the author or editor of numerous other publications,
including Software Testing in the Cloud: Migration 6r Execution (5pnnger,
2012), Testing iOS Apps with Hadoop Unit: Rapid Distributed GUI Testing ( ~1organ
& Claypool, 2014), The Vicious SUJans (And Other Tall Tales) (Precious Publishing,
2017), Dreams (Antholog) Alliance, 2018), and Technical justice (CTS Press, 2019). He
wrote the weekly "Technology Today" column for Florida Today (Gannett) from 2010
to 2018. l le holds a Ph.D. in computer science from the University of Victoria.
ACKNOWLEDGMENTS
A book like Systems Analysis and Design would not be possible without rhc help and
support of a great many people, both past and present. Harry Rosenblarr's contributions
to previous editions of rhe book provided the foll!lldarion for the current edition. His
foresight made updating the material much easieir than it might otherwise have been.
Textbooks these days arc much more than just printed books; they arc educational
platforms that have many moving parts. This means purring together an updated edirion
of a book like this, particularly on an aggressive schedule, is a challenge. I'm pleased to
say that the entire production ream rose to the occasion. Thanks to Jaymie Falconi,
Michele Srulga, Emily Pope, and Maria Garguilo at Cengage for all of their help. Thanks
to John Freitas for providing new screenshors of programs and applications. An>' errors
or omissions in this edition of the text are purely my responsibility.
Finally, sincere thanks to the insrn1ctors and students who offered feedback and comments.
We have tried to address your concerns and incorporate your suggestions. As this
field is constantly evolving, we srrongl)' encourage your participation in helping us provide
the freshest, most relevant information possible. We will cenainly continue to listen carefully.
If }'OU have an)' que tions or comments, please contact us through your local representative.
c..., .... .31:8C....,:...._ Al~,,_~,..., •WGfd.~•~• ..... ••,__0.:•*'"-....... -61111,_,,..-_,-.c..........,.._ec ... lllil__.~.t
•......w~~-._....,..,....., ........ _. _ _..........,....,. ... .-;11-...~~c-,,....i.__..~w._.._ ........ __ ..,.._.,......,..._..,....._...., ..

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

PHASE
Systems planning is the first of five phases in the systems development life cycle. It's always a
good idea to know whether a project fits the company's overall strategy.A systems project that
does not align with corporate strategies should not be approved. The role of an information
system is to support business goals.
Chapter I focuses on an introduction to systems analysis and design by describing the role
of information technology in today's dynamic business environment.This includes information
systems, lntemet business strategies, modeling business operations, business information
systems, organizational information models, systems development, the information technology
department. and the role of the systems analyst.
Chapter 2 focuses on analyzing the business case, explains how systems projects get started, and
describes how to evaluate a project proposal to determine its feasibility.This includes strategic
planning and strategic planning tools, the business case, systems requests, factors affecting
systems projects, processing systems requests, assessing request feasibility, setting priorities, and
the preliminary investigation.
Chapter 3 focuses on managing systems projecu.This includes an overview of project
management, creating a work breakdown structure, task patterns, the critical path, project
monitoring and cont.rel, reporting, project management so~ware, risk management, and
managing for success.
r..,,...J1DOr-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I
Introduction to Systems Analysis and Design
Introduction to
Systems Analysis
and Design
Chapter I is the first of three chapters in the systems
planning phase. This chapter explains the role of
information technology In today's dynamic business
environment. This chapter describes the development
of information systems. systems analysis and design concepts.
and various systems development methods. This
chapter also summarizes the role of the information
technology department and its people in the enterprise.
The chapter includes three "Case in Point" discussion
questions to help contextualize the concepts
described in the text. The "Question of Ethics" invites
examination of the ACM's code of ethics and those of a
developing systems analyst.
LEARNl"IG OB ECT VES
When yo11 fi11ish this d1apter, you should be able to:
1. Describe rhe impact of informarion rechnology
on soc1ery
2. Describe che five main components of an
informarion sysrem
3. Explain lnrerner business srratcgies and
relationships, including B2C and B2B
4. Explain how rouse business profiles and models
S. Undersrand rhe seven rypcs of information
systems used in business
6. Describe the types of inform:i rion Lhe four
classes of users need
7. Distinguish among struccured analysis, objeceorienccd
analysis, and agile systems development
methods
8. Lise rhe tools chat enable rhc syseems analyse
to develop, manage, and mainrain large-scale
information systems
9. Explain the seven main functions of rhe
information technology department
10. Describe the roles and responsibiliries of a
systems analrst within the enterprise
CONTENTS
I. I Information Technolog)
I .2 Information Systems
Case in Point J. J: Data Breaches
1.3 Internet Business Strategies
1.4 Modeling Business Operations
1.5 Business lnformarion Systems
Case in Point 1.2: Autonomous Vehicles
1.6 Organiz.arional Information Models
1.7 Systems Development
1.8 The Information Technology Department
Case in Point 1.3: Global Horels m1d Momma 's
Morels
1.9 The Systems Analyse
A Question of Ethics
I. I 0 Summary
Key Terms
Exercises
r..,,...JmDr-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
I. I Information Technology
3
I. I INFORMATION TECHNOLOGY
Information technology (IT) refers to the combination
of hardware, software, and services that people use to
manage, communicate, and share information. Companies
use information as a way to increase productivity,
deliver quality products and services, maintain customer
loyalty, and make sound decisions. In a global economy
with intense competition, information technology can
mean the difference berween success and failure.
l\1ore than ever, business success depends on information
technology. IT is driving a new digital economy,
where advances in hardware, software, and connectivity
can provide enormous benefits to businesses and individuals.
Although economic trends affect IT spending
levels, most companies give IT budgers a high priority, in
good rimes or bad. The reason is simple: during periods
of growth, companies cannot afford co lag behind the
IT curve. Conver&ely, when the economy slows down,
firms often use IT co reduce operating costs a nd improve
efficiency.
Fh c More Sillies Ban
Driver Toting
Digital Cure fo r
Health Care Costs
Social Media
Explodes!
Another Home Run
for Apple'!
1Math: 1Pod +
i Phone
---·
+ 1 Pat! =
SS$
FIGURE 1- 1 These headlines Illustrate the enormous
impact of information technology on our lives.
lnforn1Jtion technology a lso has profound influence on modern li fe. Although
fictitious, the headlines in Figure l-1 offer dramatic examples of how information
technology issues such as data privacy, mobile devices, and social media affects our
society. We live in a world where we can be traced, analyzed, and survei lled without
our knowledge. This raises many important questions, such as how to secure personal
dara while still providing useful functionality and business value.
The following sections provide a sense of IT history, an overview of systems
analysis and design, and a description of the syst ems analyst's role.
1. 1. 1 The Changing Nature of Information Technology
ll1e history of IT is a fascinating srudy of human progress and achievemenr. \Ve are
dazzled by the latest and greatest technology, just as our parents and grandparents
were astonished by the arrival of television, space flight, and personal compuring.
It is imporrant for IT professionals, who live a nd work in this exciting world, to
realize r h~1t each technology advance is part of a long-term process that often brings
dramatic change hut never really ends. The story of IBM is a good example.
As its name suggesrs, International Business l\1achines was a major supplier of office
equipment a nd rypewriters long before the modern computer era. Herman Hollerith,
who invented a card that identified characters by the location of punched holes,
founded IBM's predecessor company in 1896. A deck of hundreds or even thousands of
these cards could store data that was easily sorted , queried, and printed by machines.
This system sc)llnds archaic now, but punch card technology was a huge advance that
revolutionized the business world and was in use into the 1960s and beyond.
Today, IBM is a globe-spanning company with several hundred thousand employees.
It has succeeded in part by constantly adapting to its changing business environment.
For example, while it was once known primarily as a hardware company, today IBM
makes a significant part of its revenue from software and services. It also inveMs in
its people and tries to hire the best talent available. The result is that IBM has more
parents and more Noble Prize winners than any other IT company in history.

Chapter I
Introduction to Systems Analysis and Design
4 1.2 Information Systems
1. 1.2 Systems Analysis and Design
S)stcms anal ys i ~ and design is a step-by-step process for developing high-quality
information syscems. An information system combines technology, people, and darn
to pro\•ide support for business funcrions such as order processing, invencory control,
human resources, accounting, and man)' more. Some information systems handle
routine day-to-day rasks, while ochers can help managers make bener decisions, spot
marketplace trends, and reveal patterns that might be hidden in srored darn.
Talented people, including a mix of managers, users, nerwork administrators, web
designers, programmers, and systems analysts, typically develop information systems.
Capable IT professionals like these are always in demand, even in a slow economy.
For example, norice how many positions related to information technology and information
systems arc available in the Melbourne, Florida area, as shown on Monster.
com's job search website in Figure 1-2.
MONSTER
[ Q. Information lecltnology & ~ FMelboume. FL ____ _.
. ., ... Information technology & Information systems Jobs In Melbourne, Florida (1081 Jobs Found)
Find Jobs • Caree< Resource• • Post a Resume C<lmpany Profiles
FIGURE I ·2 Monscer.com is an example of an online job search website that IT professionals can use.
Sourc.r. n I en
1.1 .3 What Does a Systems Analyst Do?
A ~yMems analy~t is a valued member of the IT department ream who helps plan,
develop, and maintam information systems. Analysts must be excellent communicators
wirh strong analytical and critical thinking skills. Because S)'Stems analysts transform
business requirements into IT projects, they must be busmess-savvy as well as
technically competent and be equally comfortable with managers and progranlmcrs,
who sometimes have different points of view.
:Vlost companies assign systems analysts to the IT department, but analysts can
also report to a specific user area such as marketing, sales, or accounting. As a member
of a functional team, an analyst is better able to understand the needs of that
group and how IT supports rhe department's mission. Smaller companies often use
consultants to perform sysrems analysis work on an as-needed basis.
On any given day, an analyst mighr be asked to docwuent business processes, rest
hardware and software packages, design input screens, train users, and plan e-commerce
websites. A systems analyst n1ay occasionally manage IT projects, including tasks,
resources, schedules, and costs. To keep managers and users informed, the analyst conducts
meetings, delivers presentations, and writes memos, reports, and documentation.
Section 1.9 lists typica l skills and education requirements, certifications, career
opportunities, and the possible impacr. of future IT trends for systems analysts.
1.2 INFORMATION SYSTEMS
A system is a set of related components that produces specific results. For example,
specialized systems route lnternet traffic, manufacture microchips, and control
complex entities like the Hubble telescope, which took the amazing image shown in
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

1.2 Information Systems
Phase I
Systems Planning
s
Figure 1-3. A mission-critical ~stem is one that is vital to a
company's operations. An order processing srsrem, for example,
is mission-critical because the company cannot do business
without it.
Every system requires input data. For example, a computer
receives data when a key is pressed or when a menu command
is selected. In an information system, data consisrs of basic
facrs that are the system's raw material. lnfonnation is data
that has been transformed into output that is valuable to users.
An mformarion system has five key componenrs, as shown
in Figure 1-4: hardware, software, dara, processes, and people.
1.2.1 Hardware
Hardware consists of everything in the physical layer of the
information &ystem. For example, hardware can include
servers, workstarions, networks, telecommunications
equipment, fiber-optic cables, mobile devices, scanners, digital
capture devices, and other technology-based infrastructure.
A l::irge concentration of networked computers working
FIGURE 1-l Consider the amazing technology
that enabled the Hubble telescope to capture this
Image.
Sourcet Co..rt y of it,.. I "'-j,j
together is called a data center. As new technologies emerge,
manufacturers race to market the innovations and reap the rewards.
Hardware purchasers today face a wide array of technology choices and
decisions. In 1965, Gordon Moore, a cofounder of Intel, predicted that the
number of rransisrors on an inregrared circuir chip would double abour
every 24 months. His concept, called Moore's law, has remained valid for
over 50 )'Cars. Fortunately, as hardware became more powerful, it abo
became much less expensive. Large businesses with thousands or millions
of sales rranc;actions require company-wide information systems and powerful
servers, which are often now in the cloud, such as those shown in
Figure 1-5.
1.2.2 Software
I
l
[
I
I
1111111 ••
8ol••
.,...
.. 111111
.....
Soh\\arc refers to the programs rhar control the hardware and produce the
desired information or resulrs. Somvare consists of S)'Stem sofrware and
application software.
System software manages the hardware components, which can include
a single computer or a global network with many thousands of c(jents. Either the
hardware manufacturer supplies the system software or a company purchases it
from a vendor. Examples of sysrem software include the operating system, security
software rhat protects the computer from intrusion, device drivers that communicate
with hardware such as printers, and utility programs that handle specific tasks such
as dara backup and disk management. System software also controls the flow of darn,
provides darn security, and manages network operations. In today's inrerconnected
busines!> world, network sofrware is virally importanr.
Application software consists of programs that support day-to-day busines~
functions and provide users with the information they need. Example!> of company-wide
applications, called l.'llterpri\e application~ . include order proces!>ing !>y!>tems, payroll
systems, and company conununications networks. On a smaller scale, individual users
can boost productivity with tools such as spreadsheets, presentation software, and
databa~e management systems.
......... ""_.. ...
.-.. ............... _
/
~ . I
• s
'
'
•
<
y
s
T
E
~ T
M
FIGURE 1-4 An Information
system needs these components.
.. __ __.... ................... ~~·~---- ·· · ---~~-.,.- "~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..
/
I.ii

Chapter I
Introduction to Systems Analysis and Design
6 1.2 Information Systems
FIG URE 1-S Cloud compudng provides the enormous storage and speed that modern IT systems need.
( ry ~ I/I "°'- <Orr"
Applic:nion software includes horizontal and vertical systems. A hori1ontal sy~ tem
is a sysrem, such as an inventory or payroll application, that can be adapted for use in
many differenr rypes of companies. A verrical system is designed to meer rhe unique
requiremencs of a specific business or industry, such as an online rerailer, a medical
practice, or an auto dealership.
~l ost companies use a mix of software that is acquired at various rimes. When
planning an information system, a compan)' must consider how a new system
will interface with older systems, which are called legacy systems. For example, a
new human resources sysrem might n eed to exchange data with a legacy payroll
application.
1.2.3 Data
Data is the raw material that an in.formation system transforms into useful information.
For exa mple, an information system using a relational database can store data
in various locations, called rabies. By linking the tables, the system can display the
specific information that the user needs-no more and no less. Figure 1-6 shows a
payroll system that stores data in foLJr separate tables. Notice that the linked rabies
work together to supply 19 different data items. A user c:.in display any or all darn
items and filter the data ro fit defined limits. In this example, the user requested a list
of employees who live in a certain city and worked more rhan 40 hours in the last
pay period. Jane Doe's n:.ime was the first ro display.
The growth of big data has given rise to new ways of scoring, sea rching,
:ind managing data. Tradirional relational models are srill used, but so-called
NoSQI dat aba~cs are gaining in popularity due to their ability ro scale to extremely
large and unstrucrured datasets.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.2 Information Systems
7
P>yl'tnod
Hoors Wotlrtd
fMPl,OVff
9 Employet No
Otpt
Ply Rott
f1rs.tNlMt
Ml
ltrt N1mt
Strt:tt
CllY
CUAAENTOfDUCTIONS
fmplQYet No
I Otduruon Codt
Amount
O!OUCTION OPTIONS
t Oedu<:llon Code
Otsalpllon
frtqvtn()'
FIGURE I ·6 In a typial payroll system using a relational model, daa is st0ttd on separate ables that are hnked to
fonn an overall daabase.
1.2.4 Processes
Processes de cribe the tasks and business functions that users, managers, and IT sraff
members perform LO achieve specific results. Processes are the building blocks of an
ioforn1ation system because they represent actual day·to-day business operations. To
build a successful information system, analysts muse understand business processes
and document them carefully.
1.2.5 People
People who have an interest in an information system are called stakeholders. Stakeholders
include che management group responsible for the system, the users (sometimes
called end users) inside and outside the company who will interact with rhe
system, and IT sea ff members, such as systems analysts, programmers, and network
administrators, who develop and support the syscem.
Each stakeholder group has a viral interest in the information system, bur
most experienced IT professionals agree that chc success or failure of a system
usually depends on whether it meets the needs of irs users. For that reason, it is
essential to understand user requiremenrs and expectations rhroughout the development
process.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
8 1.3 Internet Business Strategies
A data breach occurs when a hacker gains illegal access to a system and steals personal data.
such as credit card numbers or home addresses. With more of our information stored in
the cloud. data breaches are becoming increasingly common. Research recent news articles
about large-scale data breaches. summarize why they occurred, and suggest how they might be
prevented in the fuwre.
I J INTERNET BUSINESS STRATEGIES
To design successful systems, systems analysts must understand a company's business
operations. Each situation is different. For example, a retail ~tore, a medical practice,
and a hotel chain all have unique informarion systems requirements. As the business
world changes, systems analysts can expect to work in new kinds of companies that
will require innovative IT solutions.
Business mday is being shaped by rhree major trends: rapidly increasing globalization,
technology integration for seamless information access across ::i wide v::iriety of devices
i.uch ::is laptop~ and smartphones, and the rapid growth of cloud-based computing and
software services. These trends are being driven by the immen~c power of the Internet.
1.3. 1 The Internet Model
Internet-based commerce is called e-commerce (electronic commerce). Internet-based
systems involve various hardware and software designs, but a typical model is a series of
web pages rhat provides a user interface, which communicates with database management
sofnvare and a web-based data server. On mobile devices, the user mceracrs wich
the system with an app, bur che same back-end services are accessed. As Internet-based
commerce continues ro grow, career opportunities will expand sigmficanrly for IT profes!.1onals
such as web designers, database developers, and systems analyses.
1.3.2 B2C (Business-to-Consumer)
Using che Internee, consumers can go online to purchase an enormous variety of product)
and services. This new shopping environment allow~ custome~ to do research,
compare prices and features, check availability, arrange delivery, and choose payment
methods in a single convenient session. Many companies, such as airlines, offer incentives
for on line cr::insactions because web-based processing cost~ are lower than traditional
methods. By making Aight information available online to lase-minute travelers,
some airlines also offer special discounts on seats that might otherwise go unfilled.
B2C (business-to-consumer) is changing traditional business models and creating
new ones. For example, a common business model is a retail store that sells a product
to a customer. To carry out that same transaction 0 11 the Internet, che company must
develop an online score and deal with a totally different set of marketing, advertising,
and proficabilicy issues.
Some companies have found ne'v ways to use established business models. For
example, Airbnb and VRBO have transformed chc traditional hospitality service
industry into a popular and successful way for individuals to rent chcir properties.
Ocher retailers seek to enhance che oulinc shopping experience by offering gift advisors,
buying guides, how-co clinics, and similar fcarures. In the e-commerce battles,
the real winners are on line consumers, who have more information, better choices,
and chc convenience of shopping ac borne.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase I
Systems Planning
1.4 Modeling Business Operations
9
1.3.3 B2B (Business-to-Business)
Alrhough rhe bu~mess-ro-consumer (B2C) sector is more familiar to rerail cu~romer;,
the volume of B2B (bu ~ines s- ro-busine~s ) transactions is many rimes greater. Industry
observers predict that 828 sales will increase sharply as more firms seek to improve
efficiency and reduce costs.
Initially, electronic commerce berween two companies used a darn sharing arrangement
called electronic data interchange (EDI). EDI enabled computer-to-computer
dara transfer, usually over private telecommunications lines. Firms used EDI to
plan production, adjust inventory levels, or stock up on raw materials usmg dara
from another company's information system. As B2B volume soared, compan)'·tocompany
transactions migrated to the Internet, wbich offered srandard protocols,
universal ::wailability, and low communication costs. The main advantage of the web
is that it offers seamless communication between different hardware and software
environments, anywhere and anytime.
Because ir allows companies ro reach the global marketplace, B2B is especially
i1nporrant to smaller suppliers and cusromers who need instant information about
prices and avai lability. In an approach that resembles an open marketplace, some 82B
sites invite buyers, sellers, distributors, and manufacturers to offer products, submit
specifications, and transact business.
r..~osr large firms and government agencies use supply chain managemenc (SCM )
software. A supply chain refers to all the companies who provide materials, services, and
functions needed m provide a product to a custon1er. For example, a Sherwin-Williams
customer who buys a gallon of paint is at the end of a chain that includes the raw mate·
rial sources, packaging suppliers, manufacturers, transporters, warehouses, and rerail
srores. Because SCM is complex and dynamic, specialized software helps businesses
manage invenrory levels, costs, alternate suppliers, and much more.
1.4 MooFUNG Bus1~ess OPERATIONS
Sysrems analysts U!.C modeling to represent company operations and informatton needs.
Modeling produces a graphical rcpresenration of a concept or process that systems
developers can analyze, cest, and modify. A S)'Stems analyst can describe and sunpltfy an
information syscem by using a set of business, data, object, network, and process models.
A business profile is an overview of a company's mission, functions, organizanon,
products, services, customers, suppliers, competicors, constraints, and future direction.
Although much of this informarion is readily available, a systems analyst usually
needs co do additional research and fact-finding co fill our missing or incomplete
infonnation. A business profile is the starting point for the modeling process, and
a systems analyst can describe and simplify an infonnation syscem by using a set of
business models and business process models.
A business model describes the information that a system must provide. Analysts
also create models to represent data, objects, oenvorks, and other system components.
Although the models might appear to overlap, they actually work together to describe
the same environment from different poincs of view.
Business process modeling involves a business profile and a set of models that
document business operation~. Model-based systems engineering (MBSE) is one of
the leading methods used by systems analysts co develop informacion systems.
A bu~ines\ process is a specific set of rransactions, events, and result<i that can be
described and documented. A business process model (BPM) graphically displays one
or more business processes, such as handling an airline reservation, filling a producr
order, or updating a customer account. The sales order example in Figure 1-7 shows a
simple model that includes an evenc, rbree processes, and a result.
......... ""_.. ... .-.. ............... _
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter I
Introduction to Systems Analysis and Design
10
1.4 Modeling Business Operations
Ched< Customer
Status
P1ocess
Veriy Customer
Cred~
Verily Customer
Credit
Process
Enter Customer
Order Data
Enter Customer j
Order Data
FIGURE I· 7 A simple business model might c:onsist
of an event, three processes, and a result.
FIGURE I · 8 This sample uses business process
modeling nocation (BPMN) to represent the same
events, processes, and workllow shown In Figure 1-7.
$ourcet Or.iwo -n
_____ ... _
·-- g Q.
0000
0 0 00
0000
oooa
V0(9@
001 (
I
OciCJO
00011
11==
A rough skecch might be sufficient to document a simple business process. For
complex models, analyses can choose computer-based tools thac use bu ~i ne ss process
modeling notation (BPMN). BPMN includes standard shapes and symbols to
represenr evenrs, processes, workflows, and more . .Vlulcipurpose application such as
Microsoft Visio or online diagramming tools such as draw.io can be used to create
BPNIN models. Notice that tbe draw.io model in Figure 1-8 use:. BPMN symbols to
represent the same sales order process shown in Figure 1-7.
--
.,_
.. ~- · - ·
=====================··
__
......_....
-·-
·- -
0
•
•
... .
.._.. __ _
.. -
·-
-·
o.i:.c:..o
0000
QoO•
fcoOo
0 -A><>
. . ;: .
FIGURE I ·9 Lucidchart allows you to drag and drop various symbols and connect them to model a business process.
Sowc.« Lu.. ,iJ s. ... .,..,_
....
..
C=i
~
•
·--·-·
Cl
0
'
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.5 Business Information Systems
I I
Systems developers often use multipurpose charring tools such as Lucidchart to
display business-related models. Lucidchart is a popular tool that systems analysts
can use to create business process diagrams, flowcharts, organization charts, network
diagrams, floor plans, project timelines, and workflow diagrams, among others.
Figure 1-9 shows how to drag and drop various symbols from the left pane into the
drawing on the right and connect them to show a business process.
1.5 8USINS::SS INFORMATION SYSTEMS
In rhe past, IT managers identified an information system based on its primary
users. For example, administrative staff used office systems, operational people
used operational systems, middle managers used decision support systems, and rop
managers used executive i11for111atio11 systems.
Today, those traditional labels no longer apply. For example, all employees,
including top managers, use office productivity systems to do their jobs. Similarly,
operational users often require decision support systems to do their jobs. As business
changes, information use also changes, and now it makes more sense to identify a
system by its functions and features, rather than by its users. A new set of system
definitions includes enterprise computing systems, transaction processing systems,
business support systems, knowledge management systems, user productivity systems,
digital assisranrs, and systems inregrarion.
1.5. 1 Enterprise Computing
Enterprise computing refers to information systems that supporc company-wide
operations and dara management requiremenrs. Walman's inventory control system,
Boeing's production control system, and Hilcon H otels' reservation system arc examples
of enterprise computing systems. The main objective of enterprise compuring is
ro integrarc a company's primary functions (such as production, sales, ervices, inventory
control, and accounting) ro improve efficiency, reduce coses, and help managers
make key decisions. Enterprise computing also improves data ecuriry and rcliahiliry
by imposing a company-wide framework for data access and storage.
In many large companies, applications called enterprise re~ource planning
(ERP) i.ystcm!> provide cosr-effecrive support for users and manageri. throughout
the company. For example, a car rental company can use ERP to foreca~t cu~tomer
demand for rental cars at hundreds of locations. Because of its growth and potentia~
many hardware and sofrware vendors target the enterprise computing marker
and offer a wide array of produces and services. For example, Figure 1-10 highlights
SAP's leading ERP solutions. SAP is a Germany company that is a market leader in
enterprise application software.
By providing a company-wide computing environment, many firms have been able
to achieve dramatic cost reductions. Other companies have been disappointed in the
time, money, and commitment necessary to implement ERP successfully. A potential
disadvanrage is rhat ERP systems genera Uy impose an overall strucn1re rhar might
or might not march the way a company operates. ERP is described in more detail in
Chapter 7, which discusses development strategics.
1.5.2 Transaction Processing
Transaction processing (TP) systems process data generated by day-ro-dar business
operations. Examples of TP systems include customer order processing, accounts
receivable, and warranry claim processing.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
12 1.5 Business Information Systems
Check
Credit
Status
What is ERP?
ERP stands for Enterprise Resource Planning
What is the simplest ERP definition? Think about all the core processes needed to run a company:
finance, HR, manufacturing, supply chain, services, procurement, and others. At its most basic level,
ERP integrates these processes into a single system. But new ERP systems are anything but basic.
They provide intelligence, visibility, analytics, and efficiency across every aspect of a business. Using
the latest technologies, ERP systems facilitate the flow of real-time information across departments
and ecosystems, so businesses can make data-driven decisions and manage performance - live.
Check
Stock
Status
~\
FIGURE 1-1 0 SAP is a leading vendor of ERP solutions that can boost productivity.
s...r. ..
TP sysrems perform a series of casks whenever a specific transaction occurs. In
the example shown in Figure 1-11, a TP syscem verifies the cuscomer's darn, checks
the customer's credic starus, checks the stock starus, poses to accounts receivable,
adjusts the inventory level, and updates the sales file. TP S)'Stems typically involve
large amounts of data and are mission-critical syscems because the enterprise cannot
function without them.
Post to
Accounts
Aece1vabla
Verify 1 6
nsactlon
Data
Customer
• ,.,. Sates
Adjust
Inventory
Levels
Update
Sales Fie
FIGURE I · I I A single sales transaction consius of six separate
tasks. which the TP system processes as a group.
T P syscems are efficient because they process a
set of transacrion-relatt:d command~ as a group
rather than individually. To protect darn incegrity,
however, TP systems ensure that if any single
elemenc of a cran s~1 c tio11 fai ls, the system does not
process the rest of the transaction.
E .5.3 Business Support
Business support system~ provide job-related
information support to users at all levels of a
company. These systems can analyze transactional
data, generate information needed to manage and
control business proces~es, and provide information
that leads to better decision making.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.5 Business Information Systems
13
The earliest business computer systems replaced manual tasks, such as payroll
processing. Companies soon realized that computers also could produce valuable
information. The new systems were called management information 'Y~ tem s
( ~U S) because managers were the primary users. Today, emplO)'ees at all levels
need informanon to perform their jobs, and they rely on informanon system~ for
that support.
A business support system can work hand in hand with a TP sy tern. For example,
when a cornpan)• sells merchandise to a cusromer, a TP system records the sale,
updates the customer's balance, and makes a deduction from inventOf)'. A related business
support system highlights slowor
fast-moving items, customers
with past-due balances, and inventory
levels that need adjustment.
To compete effectively, firms
must collect production, sales,
and shipping data and update the
compan>r-wide business support
system immediately. Automated
data acquisition is possible using
technology such as radio frequency
identification (RFJD), which uses
high-frequency radio waves to track
physical objects, such as the shirt
shown in Figure 1- 12. Major retailers
such as Walmart, which requires
its suppliers co add RFlD rags to
all item , have fueled RFlD's dramatic
growth by tracking produces
throughout the retail process.
An imporrant feature of a
b~mess supporr system is decision
support capability. Decision supporr
FIGURE 1- 1 l With an RFID tag. items can be tracked and monitored throughout
the retail process.
~
helps users make dec1 ions by creating a computer model and applying a sec of
variables. For example, a truck Oeet dispatcher might run a series of what-if scenarios
to determine the impact of increased shipments or bad weather. Alcernacively, a retailer
might use what-if analysis to decermine the price it must charge co increase profits by a
specific amount while volume and costs remain unchanged.
1.5.4 Knowledge Management
Knowledge management systems use a large data base called a knowledge base that
alJows users to find information by entering keywords or questions in normal English
phrases. A knowledge management system uses inference rules, which are logical rules
char identify data patterns and relationships.
The WolframAlpha website, shown in Figure 1-13, describes itself as a "computational
knowledge engine." Ir has a sophisticated natural language front end that
understands user queries in several domains. As shown in the figure, these domains
include mathematics, science and technology, society and culnire, and everyday life.
WolframAlpha relics upon a large knowledge base spanning multiple websites and its
own proprietarr algorithms ro provide users witb detailed answers to rheir questions
on many different topics. The results are displayed using a mix of multimedia, including
mathematical equations if appropriate.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
14 1.5 Business Information Systems
• WolframAlpha --
• I
_..,_
Matte• a:1 •• Sdnn & '!echnclagy• Sodo!y & Culluze • ~Ult
1 ...
.!:!
• .,.,...,._ .a """" • -·-
t.:
--
>: 1 1 -
-·- s -
1
--
. .
m
v
FM 4' Nl.0'• 1 •tfl.
tto.fh<ll41 ~
Ho!.lw1014IV1W\
rt' ........ ._ .. ~ .,_,
\v; ..,...,~, IMPo"lllWWIW
J ...
·-
•
t ............... [). C::...,,nt.oqo; Sclfl'ICll
~ ._.,,rtNl>Q
•
..,,,,,!C.""1CM ~
.. \ ~1'9"1i.tll• .. •'Hll'll ~
-·
•
Poll*'lfAOtrt""J'
..... •
T.clfly
:.:..i ·-
11111 ,._,,~ "':!JI( f•1o''*POtUt1Clrl
... " .. ... ...... •
...... ...
tWllll1d
FIGURE 1- 13 WolframAlpha describes itself as a "computational knowledge engine."
Soun:•: IM. ,.,,., "' plu l.
I .S.S User Productivity
Companies provide employees at alJ levels with technology that improves
productiviry. Examples of user productivity systems ioclude email, voice mail, video
and web conferencing, word processing, automated calendars, database managemenc,
spreadsheets, desktop publishing, presentation graphics, company inrranets, and integrated
mobile computing systems. User productivity systems also include groupware,
which enables users to share dara, colJaborate on projects, and work in teams. One
popular groupware product is Slack, shown in Figure 1- l 4. Slack provides common
app integration and unified communication channels for distributed teams.
Slade Is where work happens
,.
--------- _----...---
·-··-·" -·--
-
-­
.....
- ----
.. -·----·-··-·-
............ -
FIGURE 1-14 Slack Is a popular groupware application that provides common app
Integration and unified communkation channels for distributed teams.
Sou~ ..
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

Phase I
Systems Planning
1.5 Business lnforma cion 5yscems
IS
\'V'hen companies first installed word processing systems, managers expected ro
reduce the number of employees as office efficiency increased. Thar did nor happen,
primaril) because rhe basic nature of clerical work changed. With computers
performing the reperirive work, office personnel were able co handle tasks char
required more judgment, decision making, and access to information.
Computer-based office work expanded rapidly as companies assigned more
responsibility co employees at lower organizational levels. Relatively inexpensl\·e
hardware, powerful networks, corporate downsizing, and a move coward employee
empowerment also conrribured ro this rrend. Today, administranve assistants and
company presidents alike are nerworked, use computer workstations, and share corporate
data co perform their jobs.
1.5.6 Digital Assistants
Rapid advanceb in natural language processing have made a
new rype of business information system possible: the personal
digital ab5i!.tant. T hese i.ysrems are combinations of knowledge
management systems and user productivity systems, enhanced
with artificial intelligence and machine learning capabilities.
They are typica lly cloud based and can be embed ded in
hardware devices of various sizes and types.
Digital absisrants are exemplified by products such as
Amazon.com's Alexa, Apple's Siri, and Google Assistant. Users
speak to these applications just as they would speak to a real
person. The device replies in a human-sounding voice. These
services increase their capabilirics over rime. They can integrate
with other software applications and actual hardware,
such as controlling lights ar home or the rempera·rure ar the
office. An image of the Amazon Echo Dor, which is a sman
speaker powered by Alexa, is shown in Figure 1-15.
FIGURE 1-15 Amazoncom·s Echo Dot.a digital
assistant embedded 1n a smart speaker powered
by Alexa.
Sow«<
1.5.7 Systems Integration
Most large companies require systems that combine transaction proce sing, business support,
knowledge managcmenc, and user productivity features. For example, !tuppose an
international customer makes a warranty claim. A customer service representative enters
the claim into a TP system, which updates rwo other systems: a knowledge management
S)'!ttem that tracks produce problems and warranry activity and a quality control system
with decision support capabiliries. A qualiry control engineer uses what-if analysis to
determine if the firm should make product design changes to reduce warranty claims.
lo this example, a TP system is inregrated with a knowledge management sy!ttem and a
business support system with decision support features.
Imagine you work for a large automotive company. Your manager asks you to look into integrating
a digital as.sistant into a new vehicle for the next production year. How would understanding
your company·s business profile help you complete chis task?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I
Introduction to Systems Analysis and Design
16 I .6 Organizational Information Models
1.6 ORGANIZATIONAL INFORMATION MODELS
Corporate organizational strucn1re has changed considerably in recent years. In an
effort to increase producriviry, many companies reduced the number of managemenr
levels and delegated responsibility ro operational personnel. Although modern organization
charts rend to be flatter, an organizational hierarchy still exists in most firms.
1.6. 1 Functions and Organizational Levels
A rypica I organizarional model identifies business functions and organizational levels,
as shown in Figure 1-16. Within the functional areas, operational personnel report to
supervisors and team leaders. The next level includes middle m:inagers and knowledge
workers, who, in turn, report to top managers. In a corporate srrucrure, the top
managers reporr to a board of directors elected by the company's shareholders.
Top
Managers
Middle Managers
and
Know edge
Workers
SupervlSOl'S and Team
LeadatS
Operabonal Efr4>toyees
Organizational Levels
Business Functions
FIGURE 1-1 6 A typical organizational model identifies business functions and organiutional levels.
A systems analyst must understand the compan)''s organitational model to recognize
who is responsible for specific processes and decisions and ro be aware of what
information is required by whom.
1.6.2 Top Managers
Top managers develop long-range plans, called srrategic plan~ , which define the company's
overall mission and goals. To plot a future course, top managers ask questions
such as " How much should the company invest in information technology?", " How
much will Internet sales grow in the next five years?", or "Should the company build
new factories or conrract out production functions?"
Strategic planning affects the company's future survival and growth, including
long-term IT plans. Top managers focus on the overall business enterprise and use IT
to set the company's course and direction. To develop a strategic plan, top managers
also need information from outside the company, such as economic forecasts, technology
trends, competitive threats, and governmental issues.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.7 Systems Development
17
1.6.3 Middle Managers and Knowledge Workers
Jusr below rhe rop management level, most companies have a layer of middle managers
and knowledge workers. Middle managers provide direction, necessary resources,
and performance feedback ro supervisors and ream leaders. Becau e they focus on a
omewhat shorter time frame, middle managers need more detailed informarion than
top managers but somewhat less than supervisors who oversee da)'-to-day operations.
For example, a middle manager might review a weekly sales summary for a threestare
area, whereas a local sales team leader would need a daily report on customer
sales at a single location.
In addition to middle managers, every company has people called knowledge
workers. Knowledge workers include systems analyses, programmers, accountants,
researchers, tramers, human resource specialists, and other professionals. Knowledge
workers also use business support systems, knowledge management systems, and user
productiviry systems. Knowledge workers provide support for the organization's basic
functions. Just as a mi litary unit requires logistical support, a successful company
needs knowledge workers to carry out its missio111.
1.6.4 Supervisors and Team Leaders
Supervisors, often called team leaders, oversee operational employees ;'Ind carry out
day-to-day functions. They coordinare operational tasks and people, make necessary
decisions, and ensure that the right rools, materials, and training are avai lable. Like
other managers, supervisors and team leaders need decision support information,
knowledge management systems, and user productivity systems to carry out their
responsibilities.
1.6.5 Operational Employees
Operational emplo)'ees include users who rely on transaction processing systems ro
enter and receive dara they need to perform their jobs. In many companies, operational
U)ers also need mformation ro handle tasks and make decisions that were
assigned previously to supervisors. lliis rrend, called empo\\'erment, gives employees
more responsibiliry and accounrabiliry. ~1any companies find char empowerment
improves employee morivarion and increases customer sarisfactio11.
I. 7 SYSTEMS DEVELOPMENT
Many options exist for developing information systems, bur the most popular
a l ternative~ are !itructurcd analysis, which is a traditional method that scill is widely
used, object-oriented (0-0) analysis, which is a more recent approach thac many
analysts prefer, and agile methods, which incl ude the laresc trends in software development.
Figure 1-17 provide~ an overview of the three methods, which are discussed
in the following !.Cccions.
Although most projects utilize one approach, it i!> not unusual for systems developers
to mix and match methods to gain a better perspective. [n addition tO rhese
three main development methods, some organiza1tions choose to develop their own
in-house approache!> or use techniques offered br software suppliers, cool vendors, or
consultants. Manr alternatives exist, and IT experts agree that no single development
method is bei.c in all cases. An approach that works well for one project might have
disadvantages or risks in another situation. The imponant thing is to understand the
various methods and the srrengths and weaknesses of each approach.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
18
I. 7 Systems Development
STRUCTURED
ANALYSIS
OBJECT-ORIENTED
ANALYSIS
AGILE
METHODS
Description
Represents !he system in terms
al daa and !he processes !hat
act upon that data.System
de< elcpment IS organized
into phases. with deMrables
and milestones to measure
pi ogi ess. The watemll model
typically consists al five
phases: requil el I M!l ltS. desipl.
ConstruCOOl'I. testing. and
mamtenanee & e\IOlution. Iteration
is possible among !he phases.
Views the system in terms
of objects that combine
data and processes. The
objects represent actual
people, things, transactions.
and events. Compared to
structural analysis, 0-0
phases tend to be more
interactive. Can use the
waterfall model or a model
that stresses greater
iteration.
Scresses intense team-based
effort. Breaks development
into cycles. or iterations,
that add functionality. Each
cycle 1s designed. built. and
tested in an ongoing process.
Attempts to reduce ma1or
risks by incremental steps In
short time intervals.
Mode ling
Tools
Data flow diagrams (DFDs) and
process descriptions, which are
described In Chapter S. Also,
business process modeling.
Various object-oriented
diagrams depict system
actors, methods, and
messages, which are
described in Chapter 6.
Also, business process
modeling.
Tools that enhance
communication, such as
collaborative software,
brainstorming. and
whiteborads. Business
process modeling works well
with agile methods.
Pros
Traditional method that has
been very popular over time.
Relies heavily on written
documentation. Frequent phase
iteration can provide flexibility
comparable to other methods.
Well-suited to traditional
project management tools and
techniques.
Integrates easily
with object-oriented
programming languages.
Code is modular and
reusable, which can reduce
cost and development
time. Easy to maintain
and expand because new
objects can be created using
inherited properties.
Very flexible and efficient in
dealing with change. Stresses
team lnteraroon and reflects
a set of community-based
values. Frequent deliverables
consandy v.ahdate the
project and reduce risk.
C o ns
Changes can be cosdy,
especially in later phases.
Requirements are defined
early, and can change during
development. Users might not
be able to describe their needs
until they can see examples of
features and functions.
Somewhat newer method
might be less familiar
to development team
members. Interaction of
objectS and classes can be
complex in larger systems.
Team members need a
high level of technical
and communications
skills. Lack of structure
and documentation can
Introduce risk factors.
Overall project might be
subject t0 scope change as
user requirements change.
FIGURE 1-17 Comparison of structured, object-oriented, and agile development methods.
Regardless of rhe devclopmenr strategy, people, tasks, rimerables, and cosrs must
be managed effectively. Complex projects can involve dozens of people, hundreds of
ra~ks, and many thousands of dollars. Project management is the process of planning,
scheduling, monitoring, controlling, a nd reporring upon the devclopmcnr of an informarion
system. Chapcer 3 describes projecc management rools and rcchniques in derail.
I. 7. I Structured AnaJysis
Srrucrured anal)•sis is a traditional systems developmenr rechniquc rhac is rime
rested and easy co undersrand. Srrucrured analysis uses a series of phases, called rhe
('...,...., Jlt.'lit(ftllllpl ..... "'It ............. \I_,- "'"""«iflN ~-.............. .... ,,. .... ._ ........ _ ... ,..y ... .., .... ...,.....,.4 .._ ........ -··~~
............ w. .................................. ......., ..... ....-i ....... ~. c:...a.-..---• "'•· ............... - ..... -4 ............... ~ ..... .

Phase I
Systems Planning
1.7 Systems Development
19
~ys tems development life cycle (SDLC), co plan, analyze, design, implement, and
support an information system. Although structured analysis evolved many years
ago, it remains a popular systems development method. Structured analysis is based
on an overall plnn, similar to a blueprint for constructing a building, so it is called n
predictive nppro:ich.
rrucrured :innl)•sis use a sec of process models co describe a system graphically.
Because it focu~e~ on processes that transform data into useful mformarion,
structured anal)'sis 1s called a process-centered technique. In addition ro modeling
the processes, srrucrured analysis also addresses data organization and structure,
rel:uional database design, and user interface issues.
A process model shows rhe data that flows in and our of system processes. Inside
each process, input data is transformed by business rules that generate the output.
Figure 1-18 shows a process model that was ere-aced with the Visible Analyst CASE
tool. The model, which represents a school registration system, is a called a data flow
diagram (DFD) because it uses various symbols and shapes to represent data flow,
processing, and storage. DFDs are discussed in more detail in Chapter 5.
41 V•,.blt 4n4'y11 · I Rf GIST RATION PROCESS MODEU>FD)
li F~t [d< Vo<w °"''°"' Rq>OMt"')' 0..gftm Tools W.ndow -" Help
CJC!J:.l W .J1' ~ '1.a ia l • 4 ~ o""'a "' .. ,"\ ..,, , T
1~ vj •4 14, I .J • ol I
[J x
- " .
SCHOOL REGISTRA TIO~ SYSTEl\1
Sl\JDENTS
COURS{OATA
.....--------1.t ~DC..''TS
REGI STRA TIOll Oo\T A
R£CIST£R 1---------M
OUTPUT
CL\.SS ROSTERS
C'Ol'RS£S
<
>
I~ ISOiOOL REGlS­
F IG URE 1- 18 This Visible Analyst sc:reen shows a process model for a sc:hool registration system.The REGISTER STUDENTS process
accepts Input data from two sources and transforms it into output data.
Source:: V" ! ,,. t"" ("'Pl~ 11(~1
Structured analysis uses the SDLC to plan and manage the systems development
process. The SDLC describes activities and functions that all systems developers perform,
regardless of which approach they use. In the waterfall model, the result of each
phase is called a deliverable, which flows into the next phase.
Some analysts see a disadvanrage in rhe built-in structure of rhe SDLC because
the waterfall model does not emphasize interacriviry among the phases. This criticism
can be valid if the SDLC phases are followed too rigidly. However, adjacent phases
can and do interact, as shown by the circular arrows in Figure 1-19, and interaction
among several phases is nor uncommon. Used in chis manner, the traditional model is
not as different from agile methods as ir might appear ro be.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter I
Introduction to Systems Analysis and Design
20
1.7 Systems Development
Systems
Security and
S upport
• System
teqUitements
document
• Systrim
design
spec1ftcat1on
• Functioning
system
• Fully
operahonaJ
system
FIGURE 1-1 9 Development phases and deliverables are
shown in the waterfall model. The circular symbols indie1te
Interaction among the phases.
The SDLC model usually includes five seeps,
which are described in the following sections: systems
planning, systems analysis, systems design, systems
implemencarion, and systems support and security.
SYSTEMS PLANNING: The sy~tem \
planning phase
usually begins with a formal request to the IT department,
called a systems request, which describes problems
or desired chaDges in an information system or
a business process. In many companies, IT systems
planning is an integral part of overall business plan­
Ding. When managers and users develop their business
plans, they usually include lT requirements thar generate
systems requests. A systems request can come
from a rop manager, a planning team, a department
bead, or the IT department itself. The request can be
very siignificant or relatively minor. A major request
might involve a new informarion system or the
upgrading of an existing system. In contrast, a minor
request might ask for a new feature or a change to the
user interface.
The purpose of this phase is m perform a
preliminary investigation co evaluate an IT-related
business opportunity o r problem. The preliminary
investigation is a critical step because the outcome will
affect the entire development process. A key part of
the preliminary investigation is a feasibility Mudy that
reviews anticipated COM~ and benefits and recommends
a course of action based on operational, technical,
economic, and time factors.
Suppose a systems analyst receives a request for
a system change or improvement. The first step is to
determine whether it makes sense co launch a preliminary
investigation at all. Before a conclusion can be
reached, more information about the business operations may be needed. After an
investigation, the systems analyst n1ight determine that the information system functions
properly, bur users need more training. ln some situations, a business process
review may be recommended rather than an IT solution. ln other cases, a fu ll-scale
systems review may be necessary. U tbe development process continues, the next step
is the systems analysis phase.
SYSTEMS ANALYSIS: The purpose of the systems analysis phase is to build a logical
model of the new system. T he first step is requirements engineering, where the analyst
invc~tigates business processes and dlocuments what the new system must do to satisfy
users. Requirements engineering continues the investigation that began during the
system~ planning phase. To understand rhe system, fact-finding using techniques such
as interviews, surveys, document rev iew, ob:.ervacion, and sampling is performed. The
fact-finding results are used to build business models, data and process models, and
object models.
The deliverable for the systems analysis phase is the ~>~te rn requirements
document. The system requiremencs document describes management and user
requirements, costs, and benefits and outlines alternative development strategies.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.7 Systems Development
21
SYSTEMS DESIGN: The purpose of the systems design phase is to create a physical
model thar will satisfy all documented requiremenrs for the system. At this srage, che user
interface is desii,'lled, and necessary outputs, inpucs, and processes are idenrified. In addirion,
internal and external controls are designed, including computer-based and manual
features, to guarantee that the system will be reliable, accurate, maintainable, and -;ecure.
During the systems design pbase, the applicarion archirecrure is also determined, which
programmers will use ro cransform the logicaJ design into program modules and code.
The deliverable for this phase is the system de5ign specification, which is presented
to management and users for review and approval. Management and user involvement
are critical to avoid any misunderstanding about what the new system will do,
how it will do 1r, and what it will cost.
SYSTEMS IMPLEMENTATION: During the systems implementation phase, the new
system is constructed. Whether the developers use structured analysis or 0-0 methods,
the procedure is the same-programs are written, tested, and documenced, and
the system is installed. rf the system was purchased as a package, systems analysts
configure the sofrwarc and perform any necessary modifications. The objective of the
systems implementation phase is to deliver a completely functioning and documented
information system. Ac the conclusion of this phase, the system is ready for use. Final
preparations include converting data to the new system's files, training users, and performing
the actual transirion to the new system.
The systems implementation phase also includes an assessment, called a systems
evaluation, to determine whether the system operates properly and if co~ts and benefits
are within expecrarions.
SYSTEMS SUPPORT AND SECURITY: During che systems ~ uppo rt and security
phase, the IT staff maintains, enhances, and proteccs the system. M aintenance
changes correct errors and adapt to changes in the environment, such as new rax
races. Enhancements provide new features and benefits. The objective during this
phase is to maximize return on the IT investment. Security controls safeguard the
system from both external and internal threats. A well-designed system must be
secure, reliable, maintarnable, and scalable. A scalable design can expand to meet
new business requirements and volumes. lnfom1ation systems development is always
a work in progress. Business processes change rapidly, and most information systems
need to be updated significantly or replaced after several years of operation. For
example, a web-based sysrem may need more servers added to cope with increased
workJoad.
I. 7 .2 Object-Oriented Analysis
Whereas structured analysis rreats processes and data as separate componenrs,
object-oriented analysis combines data and the processes that act on the data as
objects. Systems analysts use 0-0 to model rea l-world business processes and operations.
The result is a set of software objects that represent actual people, things, rransactions,
and events. Using an 0 -0 programming language, a programmer then writes
the code rhat creates the objects.
An object is a member of a class, which is a collection of similar objects. Objects
possess characteristics called properties, which the object inherits from its class or
possesses on its own. As shown in Figure 1-20, the class called PERSON includes
I STRUCTOR and STUDENT. Because the PERSON class bas a property called
Address, a STUDENT inherirs the Address propeny. A STUDE1'.'T also has a property
called Nla1or thar is nor shared by ocher members of the PERSON class.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
22
Introduction to Systems Analysis and Design
1.7 Systems Development
INSTRUCTOR
Name
Address
Dale ol Bir1h
Otlice Location
Olllce Phone
Email
PERSON
Name
Address
Date of S.rih
lnhefll&d
properties
Other -{
properties
STUDENT
Name
Address
Dale of Birlh
GPA
Adv<SOr
FIGURE I ·20 The PERSON class includes INSTRUCTOR and
STUDENT objects. which have Inherited properties and their own
properties.
FIGURE 1-21 In a cyplc:al o.o development model.
planning. analysis. and design tasks Interact continuously
to generate protocypes that can be tested.
In 0-0 design, built-in processes called
nzethods can change an object's properties. For
example, in an online catalog store, an ORDER
o bject might have a properry called STATUS that
changes when a CUSTOMER object clicks to
place, confirm, or cancel the order.
One objecr can send information to another
object by using a message. A message requests
specific behavior or information from another
object. For example, an ORDER object might send
a message to a CUSTOM ER ob1ect that requests
a shipping address. When it receives the message,
the CUSTOMER object supplies the information.
The ORDER object has the capability to send the
message, and the CUSTOMER object knows what
actions to perform when it receives the message.
0-0 analysis uses object models to represent data
and behavior and to show how objects affect other
objects. By describing the objects and methods
needed to suppon a business operation, a systems
developer can design reusable components that speed up
system implementation and reduce development cost.
Object-oriented methods usually fol low a series of
analysts and design phases that arc simil:ir to the SDLC,
although rhere is less agreement on rbe number of phases and
their names. In an 0-0 model, the phases tend ro be more
interactive. Figi1re 1-21 shows an 0-0 development model
where planning, analysis, and design tasks interact ro produce
procotypes that can be rested and implemented. The result
is an interactive model that can accurately depict real-world
business processes.
0-0 merhodolog)' is popular because it provides an easy
transition to 0-0 programming languages ~uch as C++,
Java, and Swift. Chapter 6 covers 0-0 analysis and design,
with a detailed de cription of 0-0 terms, concept!., tools,
and techniques.
I. 7 .3 Agi ~e Methods
Development tcchnjques change over time. For example, structured
analysis is a traditional approach, ~md agile methods are
the newest development. Structured analysis builds an overall
plan for the information system, just as a conn·actor might use
a blueprint for constructing a building. Agile methods, in conrmsr, attempt ro develop a
system incrcmcntall)' by building a series of prototypes and constantly ad justing them to
user rcquircmcnrs. As the agile process continues, developers revise, extend, and merge
earlier versions into the final product. An agile approach emphasizes continuous feedback,
:ind each incremental step is affected by what was learned in rhc prior steps.
Although relatively new to software development, the norion of iterative development
can be traced back to Japanese auto firms that were able ro boost productivity
by using a flexible manufacturing system, where team-based effort and short-term
milestones helped keep quality up and costs down. Agile methods have attracted a
wide following and an entire community of users, as shown in f igure 1-22.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

1.7 Systems Development
Phase I
Systems Planning
23
lQ Scrum.org
...., ____ Q
EVENTS
The Scrum.org community is Large and active! Here is a list of some
of the events that members of our community are participating in.
Scot.So~
-
1. 2018 9 Edncugn
ScolScft Is tno ~ teen conll!nlnce in~ ts on anruat fes!NDI
d Ideas end Wlo\latlOn that ShowCases the best cf!Jle ~
tlldviology S«10r and llrtl'gS you saugnt all8r si: e aha rs from tar lb.ing
IOC4~
International Conference on Data Science, £-learning
and ln(ormot/on Systems 2018
0 0t lob.< I Z018 9 Mi\dnd
READ MORE
Don t miss ScNm org CEO Dave West as he is a keynote speaker fO< lhlS
....,•nl
FIG URE I 022 Scrum.org is a popular website supporting the agile community.
s~.l ~ ,.,,.,, 1
Agile merhods typically use a ~ piral model, which represents a series of itcrarions,
or revisions, based on user feedback. As the process continues, the final product gradually
evolves. An agile approach requires intense interacrivity between developers
and individual users and does not begin with an overall objective. Instead, the agile
process determines the end result. Proponents of the spiral model believe that this
approach reduces risks and speeds up software development.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
24 1.7 Systems Development
Barry Boehm, a noted sofrware eagineering professor, initially suggested spiral
models in the 1990s. He seated that each ireration, or phase, of the model musr have
a specific goal char is accepted, rejecced, or changed by rhe u'er or clienr. Thu , each
irerarion produces feedback and enhancemenrs, which enable the ream ro reach the
overall project goal. Typically, each iteration in a spiral model includes planning,
risk analysis, engineering, and evaluation. The repeated irerarions produce a series of
procorype~. which evolve inco the fin ished system. orice that rhese phases re emble
SD L C rasks, which also can be icerative.
Numerous orher adaprive variarions and related methods exi~t, and most TT
developers expect this trend ro continue in che future. Two examples arc Scrum,
which is discussed in Chapter 4, and Extreme Programming (XP), which is discussed
in Chapter 11.
Alchough agile methods are becoming popular, analysts should recognize char
these approaches have advantages and disadvantages. By their nature, agile methods
can allow developers co be much more flexible and responsive bur can be riskier than
more tradition::il methods. For example, without a derailed set of system requirements,
certain features requested by some users might not be consistent with the company's
larger game plan.
Other potential disadvantages of agile methods can include weak documentation,
blurred lines of accountabiJity, and too little emphasis on the larger business picture.
Also, unless properly implemented, a long series of iterations might accually add ro
project cost and development time. The bottom line is that sysrems analysrs should
undcrsrand the pros and cons of any approach before selecting a devclopmenr merhod
for a specific projecr.
I . 7.4 Prototyping
Srrucrured analysii., object-oriented analysis, and agile merhods can all employ
protoq·ping as a supporting sysrem s development method. ProtOt)·ping resrs system
concepts and provides an opportunity to examine input, ourput, and user
in terfaces before final decisions are made. A protot}pe is an early working version
of ::in information sysrem. Jusr as an aircrafr manufacturer resrs a new design in
a wind tunnel, sysrems analysts construct and study informarion system protorypes.
A protorype can serve as an initial model thar is used as a benchmark ro
evaluarc rhe finished system, or the prototype irself can develop into the final
version of the system. Either way, prototyping speeds up the development process
significantly.
A possible disadvantage of prototyping is that imporrant decisions might be made
too early, before business or IT issues are undersrood thoroughly. A prototype based
on careful fact-finding and modeling rechniques, however, con be an extremely valuable
tool.
1.7.S Tools
All systems development methods must be supported by tools to en:.ible the systems
analyst to develop, manage, and maintain large-scale information systems. These tools
go by various names, including application lifecycle management (ALM), also called
product li fccycle management (PLM); integrated development environments (IDE);
::ind computer-aided systems enginee ring (CASE), also called computer-aided software
engineering. CASE tools provide an overall framework for systems development and
support a wide variety of design methodologies, including structured analysis and
objcct-orienred analysis.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

1.7 Systems Development
Phase I
Systems Planning
25
Tools make ir easier ro build an informarion system, thereby boosring IT
productiviry and improving rhe qualiry of the finished product. After developing a
model, many CA E rools can generare program code, which speeds che implemenrarion
process. Figure 1-23 shows the wehsire for Polarion, an ALtvl solution from iemens
that 1~ part of cheir larger ~uire of offerings. Figure 1-24 shows the website for
Microsoft Visual cudio, a leading IDE. Figure 1-25 shows che web ite for Cameo
Systems Modeler, a leading MBSE CASE cool.
Polarion® application lifecycle management solutions overview
Polarion
Po&lnon & a u,,1fted appl.c-•tion tiftc)<t. 11\11"1i19f"Wf\t so' ... hon YrNte )Vt'
an de-. bl.ltd lftl Ind "'IN99 ...,.,pla tcftwllt• S)"lle!M on I un.lltd
100 pert8'l - Dl..O 10M-lNl W"4S llNll leltnl « "'°""'"°'
of users
lnnowtr, pn>blem solw, and untodt syntfg~es woss d1str1bult'd teams
fl«Jcoble 1rd1lte<W,. end ll<ltM•ng en1bl., organlz•tlans 10 go H tlwy
grow.
Po anon ALM
- .. fHt«r - mo<e ,_, M1ilt
~nmg- - lr«Nblr.ty ond
~ty lr>•o your oppll(11.,., 1 let)dc
D
Polarion REQUIREMENTS
Ehoiwfy ~'-· ..,.,_••W-ond
,.,.._,_.,_II for complu SJ"I_,.
K1otS ........ pqea lifK)'des
D
Polarlon QA
"°"ides comclle•~ IOI...,_ qunty .....,_..
ondtnt>ng~
D
Variants Add-on
ll<ipidly INI el!.ttiwfy o..ign. ~Ind
~· complu f1mlfies CJf ptodUtl _...,,,.
1NI va-11 wilh lndintty lffcf"'ll -logy
1NI lr-tegrll"'"'
D
Polanon Pro
unify Chl"llO ....... met'I. llSli & is....
trodJoog 11'<! _
contribt.itof5 Kf'Cl55 tre entefp\M
,_.."9 KrOU 111 P'O)KI
D
Polarlon Reviewer
[Nble ln~nll •nd Ule<nel It.I~ IO
,....,...""and COftVT1iil"M on ""°'t. ,..,... M'ld
piOlllcle lndunry-complio<U tl«-
lill""""" ond ll'PfOli'll\.
D
FIGURE 1-ll Polarton ,. a unified application lifecycle management (ALM) solution from Siemens.
5-<s
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ··----~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
26 1.8 The Information Technology Department
--
Visual Studio IDE ·- -
·­- -·-
I' ..---
·---
-­
·-
·-· •
:==:...
·-·
·- ==::....
Download Vo~ual Studio for Mac .!. ··-
No Magic
t - ,,,,,_.'-, ----··
.......... =----........................... --..
Fully-featurtd 1ntt.'9rak-d o.:vdoprrn:t l t:riwonment
·­
(IOE)
··­
--
•
fo< Android. 10S. rnacOS, web, and doud
-
- . ··­
··­ - .
··- ·-
t' , 7111 I • .._
-·-
-·-
I"------··
.-.... ~ ........-~
I
r". -·oo=
-
~=~-­
- • -~ J
-·-
- -
••
- .
- ••
- -
FIGURE I ·24 Microsoft Visual Studio is a fully-feawred integrated development environment (IDE).
Sour<e: """ •o • tt Co• p• .. 1
Cameo Systems Modeler
c-~ .... MrDllllw .." .. ~" ..... cnw.--~ CClllabar•Nit Modllt B.wlofld ..,.,....(•......
~lllillltbiilll & I ......a..,-°""*'~,....Wld~"'feoolsto.... tne*.lftel~.al---bOI
tt'AWIR thtMGAM a d cx .... Srr'IMlmidelSD...,., lllt••••w••• ...................
. ........,_... ~ ...--..--.....-·..........
• c. '••CNdl......-<v
• Trn ........-n~b-.ntl
..... ---·---~
~~c..tlt ~"'~' 4 ' 1H Jl~M ....... XMI ~ 0t(IUbill1fkld to~ "ffllt.
FIGURE I ·25 Cameo Systems Modeler is a cross-platform collaborative Model-Based Systems Engineering
(MBSE) environment.
SOYrc:•: " ' ""ltt ·( n:
1.8 THE INFORMATION TECHNOLOGY DEPARTMENT
The IT department develops and maintains information systems. The IT group
provides technical support, which iodudes seven main functions: application
development, systems support and securiry, user support, database administration,
network administration, web suppon, and quality assurance. These functions overlap
considerably and often have different names in different companies.
The structure of the IT department varies among companies, as does its name
and placement within the organization. In a small firm, one person might handle
(....,..... J:gi ( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

Phase I
Systems Planning
1.8 The Information Technology Department
27
all computer support activities and services, whereas a large corporation might
require many people with peciali1ed skills co provide information systems support.
Figure 1-26 shows a typical IT organization in a company char has networked PCs,
enterprise-wide databa~ es, centralized processing, and web-based operations.
IT Department
I I_
Apphcauoo l Syslems Support
Development and Secunty
I
User
Support
Otrector
lnlonnation Technology
I
Database
AdminlstrallOn
~ '-
Network
Administration
_ I_
Web
Support
I
Ouahty
Assurance (QA)
FIGURE 1-26 Depending on its size, an IT department might have separate organization units for these
functions. or they might be combined Into a smaller number of ceams.
1.8. I Application Development
The IT application development group typically provides leadership and overall guidance,
but teams consisting of users, managers, and LT staff members develop the systems themselves.
A popular model for information systems development is a project-oriented ream
with IT professionals providing overall coordination, guidance, and technical support.
Suppose you work in the IT department of Global Hotels. a multinational hotel cham. Global
Hotels runs several specialized business support systems. induding a guest reservations system
that was developed in-house to meet the requirements of a large company with worldwide
operations. Guests can make one-stop online reservations by visiting Globals website, which has
links to all major vavel industry sites.
Global Hotels f ust acquired Mom ma's, a regional chain of 20 motels. Momma 's uses
a vertical reservations package suitable for small- to medium-sized businesses and a
generic accounting and finance package. Should Momma's use Global Hotels' information
systems or continue with its ownl In your answer, consider issues such as business
profiles, business processes, system interactivity, and e-commerce. What additional
information would be helpful to you in making a recommendation?
1.8.2 Systems Support and Security
Systems support and security provides vital protection and maintenance services for
system hardware and software, including enterprise computing systems, networks,
transaction processing systems, and corporate IT infrastructure. The systems support
and security group implements and monitors physical and electronic security hardware,
software, and procedures. This group also installs and supports operating systems, telecommunications
software, and cencralized database management systems. ln addition,
systems support and security technicians provide technical assistance to ocher groups
in the IT department. If a site has a large number of remote clients, the systems support
group often includes a deplorment ream that installs and configures the workstations.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I
Introduction to Systems Analysis and Design
28 I. 9 The Systems Analyst
1.8.3 Use r Support
User support provides u ers with technical informarion, training, and produccivicy
support. The user support function usually is called a help de\k. A help desk's staff
crams u~crs and managers on application sofnvare such as email, word processing,
spreadsheets, and graphics packages. User support specialists answer questions, croubleshooc
problems, and serve as a clearinghouse for user problems and solutions.
1.8.4 Database Administration
Dara base administration involves data design, management, sccurit)', backup, and
access. In small- and medium-sized companies, an IT support person performs chose
roles in addition to other duties. Regardless of company size, mission-critical database
applications require continuous attention and technical support.
1.8.5 Network Administration
Business operations depend on networks chat enable company-wide information systems.
Network administration includes hardware and so~wa re maintenance, support,
and security. In addition to controlling user access, network administrators insrall,
configure, m::inage, monitor, and maintain network appl ications. Nerwork administration
is discussed in more detail in Chapter 10.
1.8.6 Web Support
\'V'cb ~upporr is a vital technical support function. Web support spccialisrs design and
construct web pages, monitor traffic, manage hardware and sofnvare, and link webbased
::ipplic::irions to the company's information systems. Reliable, high-quality web
support is especia lly critical for companies engaged in e-commerce.
1.8. 7 Quality Assurance (QA}
Many large IT deparrments also use a quality assurance (QA) team thac reviews
and tests all applicarions and systems changes to verify specifications and software
quality standards. The QA team usually is a separate umr that reports directly ro IT
management.
I. 9 THE SYSTEMS ANALYST
A systems analyse investigates, analyzes, designs, develops, insralls, evaluates, and
maintains a company's information systems. To perform chose tasks, a sysrcms analyst
constantly interacts with users ai!ld managers within and outside rhe company.
The fo llowing sections describe a systems analyst's role, knowledge, skills, education,
certifications, and career opportunities.
1.9. 1 Role
A systems analyst helps develop IT systems rhar support business requirements. To
succeed, analysts often must ace as translators. For example, when chey descri be
business processes to programmers, they muse speak a language thar programmers
will undersrand clearly. Typically, the analyse builds a series of models, diagrams,
and decision rabies and uses other descriptive cools and technique . Similarly, when
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.9 The Systems Analyst
29
communicating with managers, the analyst often must cranslate complex technical
issues into words and images thar nontechnical people can grasp. To do this, the analyst
uses various presentation skills, models, and communication methods.
Analyse arc often che company's best line of defense against an IT disaster-a <tystcm
that is rcchnically sound bur fail s because it does not meet the needs of u<;e~ and managers.
\Xlhen thil> occur<;, poor communication i usually to blame. For an analyst, the most
valuable skill i<t the ability to listen. An effective analyse will involve users in every <ttcp of
the development process and listen carefully ro what they have to say. As the process continue
, the analyse will seek feedback and comments from the users. This mput can provide
a valuable early wammg system for projecrs chat might otherwise go off the crack.
1.9.2 Knowledge, Skills, and Education
A successful systems analyst needs technical knowledge, oral and written commu·
nication skills, an understanding of business operations, and critical thinking skills.
Educational requiremenrs vary widely depending on the company and the position.
In a rapidly changing fT marketplace, a syste1ns analyst must manage his or her own
career and have a plan for professional development.
TECHNICAL KNOWLEDGE: Sracc-of-the-a rt knowledge is extremely import·
ant in a rapidly changing business and technical environment. The Internet offers
numerous opportunities to update technical knowledge and skills. M any IT pro·
fcssionals go online ro learn about technical developments, exchange experiences,
and get answers co qucsrions. For example, the International Council on Systems
Engineering (I COSE), shown in Figure 1-27, is one of the leading organizations
offering ystems analysts a wealth of information, news, training, supporr communities,
and more. Analysrs also maintain cheir skills by actending training courses, borh
I
E
~ r -~- - ~ , -
. -- - . '
WHAT ts S¥SltMS CNGIN((llllNG1
L .. ,, • .ai.u1 1hit .._, .. nr..e .......
)
IMCOSl"S IMPACT
l•Mlf\& t~ rwtt.1.r• of 5"'i•m'
En1•1'\ff_rif'1g
GIOW IN SYSTCMS £NGINClllllHG
V..pe lh• •~Id en4 .tw..w-e ,_., C•t..-t
rltOM me CUTIING lDGE
lll'lpeictfwl ,'9d«.b end Mat .... the--.,,,
nHO YOUA COMMliNIT't
ltwol"4 toc.ify •tit INCOS["" yow
,-~...-ch.
FIGURE 1-27 INCOSE Is one of the leading organizations offering systems analysts a w~lth of lnfonnation.
news. training. communities, and more.
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter I
Introduction to Systems Analysis and Design
30 I. 9 The Systems Analyst
on-site and online. Nerworking with colleagues is another way to keep up with new
developments, and membership in professional associations also is important.
COMMUNICATION SKILLS: A systems analyst need~ srrong oral and written
communication ~kills and che ability to interact with people at all levels, from operational
staff to senior executives. Often, the analyst must work with people outside
the company, such as sofrware and hardware vendors, customers, and government
official s. Analysts often coordinate IT project teams, where they use commumcation
skills co guide and motivate team members.
BUSINESS SKILLS: A systems analyst works closely with managers, supervisors, and
operational employees. To be effective, be or she must understand business operations
and processes, communicate clearly, and translate business needs into requirements
that can be understood by programmers and systems developers. A successful analyst
is business-oriented, curious, comfortable with financial cools, and able ro sec the big
picture. Chapter 2 describes some basic concepts, including strategic planning, SWOT
analysis, and feasibility tests.
CRITICAL THINKING SKILLS: Most educators agree that critical thinking skills
include Lhe abi lity co compare, classify, evaluate, recognize patcerns, an3 lyt.e cause and
effect, and apply logic. Critical thinkers often use a what-if approach, and they have
rhe ability to evaluate rheir own thinking and reasoning.
Critical thinking skills are valuable in the IT industry, where employers seek
job candidates who can demonstrate these skills and bring them to the workplace.
Figure 1-28 shows the website for Critical Thinking Community, a nonprofit
organization rhat provides encouragement and resources for critical thinkers.
Defining Critical Thinking
Cnmi.i tJ•li"tl .... 141 •-.U.., qf IM W<ll«t IO ...,..q of UH~
Cn~cel u.ntono,. a ncn conoept 1na1 ha been cM•alopng throughout the pat 2500 )'Mf'I. The !Mm "cnbelf
thinking" ha• lb IOOls In the mid-late 20lll century. We olret here O'tet1apping o.flnillonl, lDgellle< wl1ich lorm
• IUbllantllle, lre"8Clladplinaly concel)Clon of Ctfticlal thinking
Crltlcal Thinking• Defined by llM -
Coundl tor Eacetlen .. In Cttu .. 1Thinking,1117
Aatalement by MlcllMi Sa1ven & Rlctlard Pa!A. ~ at 11>8 80> Annual ln.,,,.tlcnal Con-on
en~ce1ri.n1c1no anc1 e-.i fWorm. s-1oe1.
Critical I~ Is 11>8 ~ualy disdc>lned proceM ol ~ and alclllul1y concec>CUallZJl'IO. applylng,
·~~and/or ..,.batinginl'o11118fiongalhatad Imm. otgane,.led by,~
--18-. 1eftadlol1, IMIOllfng, ot ~ H •~IO belef and •clan. ln 1111 ....... ry fotm, l
le - on uni-01111 ;t• - lt>at Itel-id oubj9ct - dMelont doallly. 9CCUtaeY I" oclal<>ot
--..Y. ••••""'· ---good-, do!#>. blMdth. IRI r--.
FIGURE 1-28 The Critical Thinking Community Is a nonprofit organlzadon that provides encouragement and
resources for critical thinkers.
Soun:. 0 ..r ,~,..."'
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.9 The Systems Analyst
31
EDUCATION: Companies rypically require systems analysts to have a college degree
in information systems, compurer science. or business, and some IT experience usually
is required. For higher-level posirions, many companies require an advanced degree.
Sometimes, educarional requirements can be waived if a candidate has significant
experience, skills, or profcs~ional certifications.
1.9.3 Certification
~1any hardware and software companies offer certification for IT professionals.
Certification 'erifies that an individual demonstrated a certain level of knowledge and
skill on a standardized test. Certification is an excellent way for IT professionals to
learn new skills and gain recognition for their efforts. Although certification does not
guarantee competence or abtliry, many companies regard certification as an import·
ant credential for hiring or promotion. Certification is discussed in more detail in
Chapter 12.
In addition to traditional hardware and software certifications, some firms :.ire
exploring ways to assess critical thinking skills, as shown in Figure 1-29. These ski lls
include perception, organization, analysis, problem solving, and decision making.
Whether or not form:.i l certification is involved, these skills are extremely valuable ro
IT professionals and the employers who hire thetin.
THINK Watson
- - ,..,.. I 'nloU- I -· I ... I - I c.ua
The Gold Standard Critical Thinking Test
There ,. 1 ,.,....., wny IM W.tson·u.-r Ct1Ucal T1llnlOl!g Apprals&i ts w
mo.t w1c1r1y used tool for Wlecu,. creat manaeers aod de\'elopin& Min
!Hden: lt worb. ~In 1925. tod.y IM Watson-Glaser Is t"4! premier
tool for rvaluatlnt w a11ni1;.,. abtltty ~ l)<Ofess10N1ls.
• menti
---- ---- -
--- -·
--· _,
':···~ii!!'
-----·---
=---::. W .:-.:---a.:;::_:::
- ...----::---..---
·­
• •
~"'"'=='-- .- =-- -..._~==-- -..__________
------ ==----
. :::-::::::::..~ . --------
. ==-----====---·--=:.--
--
- - r
--:::-----~--
• _,......,. Ct1ttcll tfll"9 ... ltlfllty 1'1111 dldCD\ ll'IUi"I
• fllrecilcll JUOrttnt. ~ to1"""1. CNlllmtty, GPrMm io c;cpc •w» I "'°'9
• ~ '-ttary of UM tft Mlf'IJ'll. F' I '""* It, WICI ~r:iort
• c.r.i..t" '#ftl'I ot•'-d'i,. IOCtty Md Pl"'O'll'''Y t-.i
• °'4 .,.......,.,._flClfl It -ltfl~ CDtl • !?Br;~ t!!!ll p.tl\ utnWW;
. "*" 4 "IM'I ""'-..,,,. C1'mla mt -.tth """"'twpxt .. ciptfon&
FIGURE 1-29 Employers lllce co hire people who can think logically and effectively.
Sourc.,. lu
1111 _ ic, _ _., !!O>rt
ll>"ll\Jo'f Cn11<o!lv
-.>•uQln>""'°""'
·--·
1bp Scat .. on W G twlp "odlCt
.... itudr. lill " ...".. ret'WI\
• l*'fca WWW l (at!W ,,...,, U'IC9 ~
........
kDfftl 1111 h ...... ~ ..,. ~
efW.tliDr't-GIM« ............ ..
_
("..,_...,llll!Ot...... 1.--s .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .......,..""_......-................. ..____..................... ~~·~----··----~~-.,.-"~ ...........--......

Chapter I
Introduction to Systems Analysis and Design
32 I. 9 The Systems Analyst
1.9.4 Career Opportunities
The demand for sysrems analyses is expected co remain srrong. Companies will
need S)'SCems analysrs co apply new informacion rechnology, and che explo!>ion in
e-commerce will fuel IT job growth. The sysrems analyse position is a challenging and
rewarding one that can lead to a cop managemenr posirion. \Vith an understanding
of technical and business issues, a sysrerns analyse has an unlimited horizon. ~!any
companies have presidents and senior managers who srarted in IT departments as
systems analysts.
The responsibiliries of a systems analyst at a small firm are different from those
ar a large corporarion. Working ar a small or large company is a marcer of personal
choice.
JOB TITLES: Firsr, do nor rely on job rides alone. Some positions are called sys rems
analysts bur involve only programming or rechnical support. In ocher cases, sysrcms
analyst responsibilirics are found in positions rirled computer specialist, programmer,
programmer/analyse, sysrems designer, software engineer, and variou~ ochers. Be sure
rhc responsibilities of the job are stated clearly when considering a position.
COMPANY ORGANIZATION: Find our everything about the company and where
the IT department fits in the organizarion chart: Where are IT functions performed,
and by whom? A firm n1igbr have a central IT group bur decentralize the systems
development function. This situation sometimes occurs in large conglomerates, where
rhe parcnc company consolidates information char actually is developed and managed
at the subsidiary level.
COMPANY SIZE: A smaller firm migbr provide more variety. However, a larger company
wirh scare-of-the-arr sysrems provides opportuniti~ for speciah.mrion. Alrhough
there mighr be more responsibiliry in a smaller company, rhe promorional opporrunines
and financial rewards could be grearer in larger companies. Working as an independent
consulraor is also an option. l\1aoy consuJring firms have been successful in
offering rheir services ro smaller business enterprises that do nor have the experrise co
handle systems development on their own.
SALARY, LOCATION,AND FUTURE GROWTH: Finally, consider salary, location,
and the company's prospecrs for future growth and success. Initial impre sions from
employment interviews with the company and its people are important. lvlosr importantly,
review shore- and long-term goals very carefully before deciding which position
is most suirablc.
CORPORATE CULTURE: fn addition to having goals, methods, and information
systems requirements, every firm has an underlying corporaLc culLure. A corpora re
culture is the set of beliefs, rules, traditions, values, and attitudes char define a company
and influence its way of doing business. To be successful, a systems anal) 1 St must
understand rhc corporate culture and how it affects the way informarion is managed.
Companies sometimes include statements about corporate culrurc in rheir mission
sraremenrs, which are explained in Chapter 2.
A systems analyse must undersrand the firm's culture and find it comforrable. If
the company encourages personal growth and empowerment, work is much more
enjoyable. For example, consider the Salesforce corporare culture described in
Figure 1-30. A company like Salesforce is likely ro attract, rerain, and morivare the
besr and brighrest people. In fact, Salesforce ranked# I in Fortune's 21st annual list of
rhe country's grearesr places to work.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
1.9 The Systems Analyst
33
Our Salesforce culture.
M~..._Ol.At°*'"f/llMl. Wl..., .. Gllllft.....,,,Mll .... llf ... ~~W ... ~ew---.9'11t......,,,_MfN•
..... Ow .........w-.-ONflllM,,_.li a M,~Md ......... to~'ftlf"*--._
IS ZW-
Our Ohana blazes trails
¥111>W artM•1' .... ,....,_....-:1MWOft. 9
,..., ................ ...._._..
~ ·f~ LlMHMC*•
Our values connect and 1nsp1re us
_,..,,,,......_,.,.. ........ 0...---... ...- ,_.,. _..,, .. .,_DNA
Trust OJ<,t~r Sore@S.~ lnnOlr.ltlOll
" ..... ~.,,,~.,.,
~ ................... 0wr weiw....,, w p I ...
.....,.,. .._ °"' ONN Oii. :pl ,........ ra- ,,...,,.,.,., to_.. ..
............ .. ......
--·-
_
Equo ty
...
_ ......... ...,..
~·,,.,.·-~·
MON ..... w' t' I Cl llNll worid
FIGURE 1-30 A corporate culture like Salesforce is likely to attract. retain. and motivate the best and
brightest people.
,_..,
1.9.5 Trends in Information Technology
Systems analysts need to rrack trends in information technology because technological
changes affect business operations, career opponunities, and enterprise strategies.
Very few areas evolve as fast as information technology. Each year sees evolutionary
developments in current technology, such as faster processors, wider network bandwidth,
and increased storage capabilities. Once in a while, a truly transformative
cbange occurs, such as the injection of artificial intelligence applications across the
enterprise or a revolution in the basic tenets of computation with the nascent introduction
of quantum computing.
Some of the key trends that are disrupting information tech11ology include agile
methods, artificial cloud computing, data science, mobile devices, service orientation,
and social medio networks. These trends can affect education and training needs, give
rise to new certifications, and open lucrative career opportunities.
Agile methods have already been discussed in this chapter and are covered in
more derail later in the book. The agile movement is a significant trend in information
technology thot all systems analysts should follow. It scarred as a response to
the heavyweight process models ::ind was iniri:.tlly used for smaller teams, bur interest
in agile methods has grown to encompass almost all application areas and business
organizations.
Cloud computing is in many ways a rerum to the past: a model of shared computing
and data storage resources accessed from remote clients, rather like the mainframe
era. Howe,·er, cloud computing is different in that it offers virrualiled re~ources
that can grow to accommodate increased requirements as needed. It '~ abo different in
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I
Introduction to Systems Analysis and Design
34 I. 9 The Systems Analyst
that buying capaciry on demand from a thriving vendor marketplace can reduce the
capital co ts needed for in-house computing infrastructure. It also present<> additional
securiry needs to address.
If cloud computing represencs the computational aspect of processing, data ~ciencc
represents the data aspect. The world is producing more and more data at an
incredible rate. New cools and techniques are being developed to manage these large
datasets. Areas such as machine learning and predictive analyncs are expericncmg
tremendous growth as companies try to apply artificial intelligence techniques ro the
problem of big darn. As depicted in Figure L-3 I, many of the developments related
co big data arc driving trends in information technology-trends rhe S)'5tems analyst
must follow to stay current.
FIG URE 1-3 1 Big data is driving many new developments 1n information ttthnology.
I ('< ~
Mobile devices and the app ecosystem that goe!> with them are a revolurionary
development in information technology. The shift of computing capabilities ro "the
edge" of rhe network has put unprecedented power in the hands of end users. Smartphones
are rhe most common computing device on the planet, and ~ystems analysts
will need to know about the role of apps and the effect of the bring your own device
(BYOD) movement in the enterprise.
Traditionally, IT companies were identified as product-oriented or serviceoriented.
Product-oriented firms manufactured computers, routers, or microchips,
while service-oriented companies included consultants, vendors, software developers,
and service providers. Today, those distinctions are gone. Most successful
IT companies offer a mix of products, services, and support. Value-added services
such as consulting, software, and technical support often are more profitable than
hardware sales.
Social media rides on some of the trends mentioned earlier, such as cloud
computing, darn science, mobile devices, and service orientation. 1 lowever, social
media has had arguably the most profound influence on sociery. \'Vitness the popularity
of Facebook, with over 2 billion users worldwide. Companies tap into the power of
social media, coupled with location-aware apps, to create truly innovative solutions
that arc chnnging the face of information technology.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I Systems Planning
I. I 0 Summary
35
You are enjoying your job as a summer intern in the IT department of a local company.
At lunch yesterday, several people were discussing ethical issues. You learned that some of
them belong to IT organizations that have ethical codes to guide members and set professional
standards. For example. your supervisor belongs to the Association for Computing
Machinery (ACM), which has over 100,000 members from more than 100 countries and a
website at ocm.org. Your supervisor said that the ACM code of ethics is important to her
and would definitely influence her views. On the other hand, one of the senior programmers
believes that his own personal standards would be sufficient to guide him if ethical
questions were to arise.
Because you are excited about your career as an IT professional, you decide to
visitACM's website to examine the code of ethics and make up your own mind.After
you do so, would you tend to agree more with your supervisor or with the senior
programmer!
I . I 0 SUMMARY
Information technolog)' (IT) refers to the combina tion of hardware, software, and
services rhat people use to manage, communicate, and share informarion. Technology
is changing rapidly, and IT professionals must prepare for the future. IT suppor~
business operations, improves productivitr, and helps managers make decisions.
Systems analysis and de 1gn is the process of developing information systems that
rransform data into useful information, and systems analysts are IT team member
who help plan, develop, and maintain information systems.
The essenrial components of an informarion system are hardware, software, data,
processes, and people. Hardware consists of everything in the physical layer of the
informanon system. Sofrware consists of system software, which manages the hardware
components, and application software, which supports day-to-day business
operations. Data is rhe raw material chat an information system transforms into useful
information. Processes describe the tasks and functions char users, managers, and
IT staff members perform. People who interact with a system include users, from both
within and outside the company.
Most s u cces~fu l companies offer a mix of produces, technical and financial
services, consulting, and customer support. A rapidly growing business category
is the Internet-dependent fi rm, which relies solely on Internet-based operations.
E-commerce includes business-to-consumer (B2C) sales, and business-to-business
(B2B) transactions that use Internet-based digital marketplaces or private electronic
data interchange (EDI) systems.
A systems analyst starts with a business profile, which is an overview of company
fu nctions, and then he or she creates a series of business models that represent business
processes, which describe specific transactions, events, tasks, and results. Analysts
use business process modeling rools to document complex operarions. Systems
analysts u e modeling, prototyping, and computer-aided systems engineering (CASE)
tools. Modeling produces a graphical representation of a concept or process, whereas
prototyping involves the creation of an early working model of the information or its
components.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I
Introduction to Systems Analysis and Design
36 I. I 0 Summary
Based on their functions and features, business information systems are identified
as enterprise computing systems, transaction processing systems, business support
systems, knowledge management systems, user productivity systems, digital a5sistants,
or systems integration. In most companies, significant overlap and integration exists
among the various types of information systems.
A typical organization structure includes top managers, middle manager5 and
knowledge workers, supervisors and team leaders, and operanonal employees. Top
managers develop strategic plans, which define an overall mission and goals. Middle
managers provide direction, resources, and feedback to supervisors and team leaders.
Knowledge workers include various professionals who function as support staff.
Supervisors and ceam leaders oversee operational employees. Each organi1arional
level has a different set of responsibi Ii ties and information needs.
Three popular system development approaches are structured analysis, which is a
traditional method that still is widely used, object-oriented analysis (0-0), which is a
more recent approach chat many analysts prefer, and agile methods, which include the
latest trends in software development.
Structured analysis uses a series of phases, called the systems development lLfe
cycle (SDLC) that usually is shown as a waterfall model. Structured analysis uses an
overall plan, similar to a blueprint for constructing a building, so it is called a predictive
approach. This method uses a set of process models co describe a system graphically
and also addresses data organization and structure, relational database design,
and user inrerfacc issues.
Objecr-orienred analysis combines data and the processes that act on the data inro
things called objects chat represent people, things, transactions, and events. Objects
have characccrisrics, called properties, and built-in processes, ca lled methods, and can
send information to ocher objects by using messages. Using an 0-0 programming
language, a programmer then writes the code that creates the objects. Object-oriented
methods usual!)' follow a series of analysis and design phases similar co the SDLC,
but the phases arc more interactive.
Agile methods are the newest development approach and anempt co develop a
system incrementally by building a series of prototypes and con5ranrly adjusting them
to user requirements. Agile methods typically use a spiral model, which reprcsenn, a
!>ertes of iteration , or revisions, based on user feedback. The repeated 1terauons produce
a series of prototypes, which evolve into the finished system.
Regardless of the development strategy, people, tasks, timetables, and costs must
be managed effectively using project management tools and techniques, which are
described in derail in Chapter 3.
The IT department develops, mai11tains, and operates a company's information
systems. IT staff members provide technical support, including application development,
systems support, user support, database administration, network administration,
web support, and quality assurance. These functions overlap considerably and
often have different names in different companies.
In addition to technical knowledge, a systcn1s analyst must understand rhc business,
chink criticall y, and commUI\icace effectively. Valuable credentials such as certifications
arc available to systems analysts. A systems analyst's responsibilities depend
on a company's organization, size, and culture. Systems analysts need to consider salary,
location, and future growth potential when making a career decision.
Some of the key trends in information technology include agile methods, artificial
cloud computing, data science, mobile devices, service orientation, and social media
networks.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
Key Terms
37
Key Te rms
agile method\ Sy\ttms de' clopmcnr methods char arrempr 10 de,·elop a sys1em incrementally by build·
ing a senc> of prOIOt) pes and cons13Jltly ad1usliog them to user requiremems. Rela1ed to ad.iptin•
methods.
app A soff\, are appltc.mon th.it runs on a mobtle dence. such as a smartphone or tablet.
applocat10n hftC)dt mana11cmcnt (ALM) Acrivitie\ 1ha1 co,·cr rhe entire SDLC, indudmg requ1remen1>,
dc"11n, de,•dnpmcnr, tc,nn11, and dcplopncnr and management of ~nftware appli~non\.
apphcaunn ,oftwarc Sofn.arc program\, such as email, word proc~'o", .,prcad,hecr-. and graphic'
packages. u..ed hy emplo)'ce<. in rypica I office o;cenarios.
artificial intelligence The atrempr co recreate narural inreUigence through software in machines.
B2B (busincss·to bu1ineu) A commercial exchange (e.g., producrs or services) bcn,een businesses, typi·
cally enabled by tlw lmernet or electronic means.
B2C (bu•it11.'\\·to-co111umcr) A commercial exchange (e.g., produces or service,) between bu\inc\\eS and
con•umeri. conducted over the Internet.
hi11 d:ll,\ F.xircmcly laq.\c datnsct\ (c.11., pctahytcs) requiring no ntraditional ~ppruache, to deal wi th
them. Snmcrime\ chnracrcri1.cd hy three term<: volume, variety, and velocity.
bring your own de, ice (B\'Ol>) An equipmenr managemenr model where employees arc in charge of
their devices (e.g .. computers, 1ablets, smartphones) ac work, noc 1he lT deparrmcm. Tlus includes
device selecuon Jnd Sl'lup. progum installation and updating. and network connecti' ity (indudmg
security).
busineu model A graphical representauou of business functions that consist of busin~s processes, such
.1s s.iles, .1ccoun11ng, and purch.1S1ng.
hu'1nC\\ prncc" A dC'lc,.iprion of •pecific event<, ra<ks, and dc<ircd rc<ult<.
bu,inc" pr!ICC\\ model RPM ) A graphical reprco;enratiun of one or more bu<inc" procc,'>C<.
businC'ls proce<< modeling no1a11on (BPM:-:) A srandard sec of shapes and symhols used to repr~nt
e\ enrs. processes. and work flows m computer-based modeling cools.
business profile A definition of a company's overall functions, processes, organiunon, product>, servic~.
customer.. >upphtrs, compernon., constramt>, .md furure drrecuoo.
bu,ine<,\ rule\ How a » •tcm handle> data and produces U5Cful informauon. Busincs;, rule\, al;o ~allcd
hu>incs' logic, rcflcct the operational requirements of the busincs>. Fxamplc, 1ndudc adding the
proper amount of <ale< tax m invoices, calculating customer balances and finance charge<, and dc1cr·
mining whether a c:usmmcr is eligihlc for a ,·olume-ba\Cd discounr.
bu\ine-.\ \upport \Y\IClll\ Provide job-related informarion support co user< at all lt'vel\ of a company.
CASE 1ools Powerful software used in computer-aided S)'Stems engineering (CASE) ro help systems ana·
l)'St> develop Jnd mamrnin information S)''tetus.
certificauon A credenii.11 Jn individual earns by demonstrating a certam level of knowll'dge .ind skill on
a sta11dard1ted tcsr.
das~
A term u\cd 111 object-oriented modeling to indicate a collection of ~iniilar objc"'·
computcr-a1dcd \Oftwarc cngmccring (CASE) A technique that use< powerful program< ca lled CA ~r.
tool< co provide an overall framework for systems development. The tools ~upport a wide varicry of
design methodologie,, including srrucnired analysis and objecr-orienced analysis. Also referred to a'
compmcr-aidcd ;y;1e1m engineering.
computer-.udcd >>Stem; cn111neet1nR 1CM.£) See compmer-aided software engmeermg ( <..A~E).
wrporatc culture A >et of beliefs, rul~. 1radmons, \alues. and attitude~ that define J cornpau) and mflu·
em:e 1r< wa) of doing business.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter I
Introduction to Systems Analysis and Design
38 Key Terms
critical Lhinl.mg ~I.ill> The abilif} to compare, dassif), evaluJte, rccognne panem>. anal) Lt cause and
effect, and apply logic. Such skills are valued m the IT mdusrry.
dat.t The ra\\ m.11erial or basic facts used by informauon S) stem>.
d.ua center A !Jrgc ton~cntrarion of ncrworkcd computer' working together.
data no\\ d1a11ram (Df D) Graphical rcprC\cnlation of the \)>Lem, \hem mg II \tore\, prnu:"e', and tran>form'
Jara mm u-cful information.
data ~ocnce lnrerd1~1pltnary field rhar blends computer science, math and stausucs, and bu~iness merhods
10 anal)'Zc large darasers. Involves artificial imelligcnce. machinc learning .ind prcdicn"c analytics,
and v1sualitation techniques.
Jell\ crabl~ A polished, fu1al product, suitable for its intended use. £nd product> or del1verJbles often
cornc1de wnh the complenon of each SDLC phase.
e·commcf(C tclccironic conuncrcc) Transactions (e.g., buying anti ,cllinµ of l\(X>U\ and onfnrmaunn) that
c><:cur on the Internet. Includes both businc~-to-consuoncr and bu,ine.-· to· l)l1'inc,s.
clcc1ronic dnra inrcrchanJle (FDT) A process that involve' computer-co-computer transfer of darn
bcrwccn companies.
cmpo"ermcnt A business prnccice chac places more responsibility and ,1ccoumuhiht) rhrougbour all levels
of .Ill org.mizaliou.
enterprise applic.mons Comp.tn)·wide applications, such as order processwg systems. pJyroll systems,
Jnd compJn) communicanons networks.
c:nterpri\c rnmpurini: Information 'YMcms char >t1pport lompany-w1Je data ma11a11emcnt requirement\,
,uch a• airline rc<;crvanon' or credit card billing sy.tcms.
cntcrpri\e re\our'c planning (FRP A process that cstablishc, an cnccrpri-c-w1Je \trnrei:y for IT
rc,ourccs. FRP defines a <pecific archirccrure, including ''andard< for data, procc,,ini;. network, and
u-er imcrfol-C d<'\1gn.
fcasibilm study An mmal in\'esrig;uion to clearly identify the n.uure and scope of the business opporrnmr)
or problem. Also called preluninary 1.Dvestigauon.
groupn.ire J>r~ams thar run on a necwork chat enable users to share data, collaborate on pro1«ts, and
work m teams. Also called workgroup sohware.
hardnarc The phy<ical layer of rhc information system, to include computer\, network\, communication<
equopmenr, and orher rcchnolo&>y·hased infrastructure.
help dc\k A cenrrali1cd resource miffed by TT professionals that provide' U\Cr' with che \upporr rhey
need to do 1he1r job>. A help de>k h,.,., three main objel"tivc~: to ~how people: how to U\c ~y,ccm
re.uur~C> more dfc:ctivcly. to provide an~wcn. to 1,-chnical or opcrarion,11 quc., 1 io11~, and to make
user\ more productive by reaching rhcm how to mcer their own mformation need<.
horiiontal sy\Ccm A basic sysrcm, such as an inventory or payroll packap,e, that 1s commonly used by a
vnricry of companies.
inference rule' lnsrructions that direct a knowledge management sys1em ro idcmify data pat1crns and
rdanonsh1ps.
information Dnm rhar has been changed inro n useful form of outpur.
informauon S)\lcon A combination of infom1arion 1cdinology. people, and data co '>upport bminc~s
requirements. Ilic five key components a~e hardware. software, data, proccs.es, and people.
1nforma11on tcchnoloiiy (IT ) A combination of hardware, software, and telecommun1c.111on< S)>lem'i
that support business operations, improve producuvitl, and help manager\ make decisions.
intCjlr.ued dc\Clopmcnr environments (IDE) An application for hu1lding orhcr \Oft" .ire appli~tions.
T)·picall> includes a visual code editor, an integrated compiler, a debugger. a configuration manageme111
~)Mem, and a rest framework.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Phase I
Systems Planning
Key Terms
39
i1aa1ht: An ;idapme method I) pictll) use,, a spiral de,·elopmenr model, which builds on J series of
ncrauoru..
I.no\\ ledge b.i\c A popular ws1cm\ dn·elopmem 1echnique that uses a group of ~r.. man.igcr~. and IT
profc:,~1onal\ who work t<>gc1hcr to gather mformanon, <l~u~ bu~mess need>, and define the new
\y~rcm rcqu1rcment'\.
lcitaq. '}"tern An older 'l)'\tcm rhat is rypically less rechnologically advanced than currcnrly available 'Y'rcm\.
machine learning An application of compurer science and anifkial intelligence thar uses automattd
approaches 10 pattern recognition and predictive analytics based on large darJsets.
management informauon ~)>tern (MlS) A computer-based information system used in business plJnnmg,
control, decision making, and problem solvmg.
mi"ion-criuul \)'\lcm An information 'Y'tcm rhar i> vital to a company'~ upt:rauons.
mc>dt:l-ha,cd 'Y'lcm' c1111incc1 ing (MBSE) An approach to ,,.ystcm' engineering that relit' on doma111
models, rather than rrndinonal documcnr., to dc<ii;n la rg:e·,calc <rtcm' and convey information
hctwccn cngi nee rs.
modeling J\ process th,11 produces a graphical representacion of a concept or process tbtlt systems developers
can analy tc, test. a nd modify.
Moore's l.i" A prediction 1h,11 compuring power would double every 18 to 24 months due 10 wcreJsed
nuui.1rurw11011 of elecrron1c components.
NoSQl. dataha\c) Da1.1ba"' 'y>tcrn' that use a flat, nonrabular (nonrdarional) \lrULlur" 10 'tore :ind
procc" largc-..calc dara,cr\.
objc.:t In obJl-Ct-oricntcd analy<;i• or programming, an object rcprcscnr- a real pcrwn, place, event, or
rra0\act1on.
objcct-oritntcd 0-0J ;inal~s1s The act of understanding an information S)Stem b) rdenufymg things
c.tlled ob1m~. An ob1ec1 represents a real person, place, event. or transaction. Obiecr-onemed analysis
~ .i popul.u .1ppro.1ch 1h.1r ;ees .i S)>tem Crom the viewpoint of the obiect> tbetrueh cs .I) the> funcuon
and interact wuh the sysrem.
personal d1g11al assistant A progr.im rhat responds rouser requesrs through a natural interface, such as
regular speech, to provide assmancc to general-purpose queries. Often embedded m devices such JS
lmemet<Onnl'Cted )peaJ..ers and smarrphones.
prdiminal} imc\Ugaunn 1\n cnirial analy)is ro de:trly idenri fy the narure and scope of the hu,ine,~
opponumty or problem. /\l'o called fca>ibility >tUd).
PrQ\cuore or ta'k 1ha1 user>, managers, and IT sraff member) perform. Al;o, the logkal rules
of a 'Y'tcm that arc applied m rran5fonn dara mro meaningful infom1anon. ln data Aow diagram5, a
p mce'~ receives input darn and produces nurput thar has a different content, form, or hoch.
procl~\
produc1 lifccycle management (Pl .M) See application lifocycle management (ALM.).
product oriented Comp,m ie~ that manufacture computers, routecs, or microchips.
projccc management The proccs5 of planning, scheduling, moni roring, conrrolling, and reporting upon
the development of nn informarion sys1cm .
propcrtic' In oh1t.'Ct·oriemcd (0·0) analysis, characteristics rhat objects inherit from their da>S or po~ ­
>css on their own.
prototH>C An c.1rly, rJp1dl) constructed workmg version of the proposed uuorm.ition >y>tcm.
radio frequency idcnt1fic.111on (RI Ill) Technology rh.~ r uses high-frequency radio waves to tr.1ck physical
ob1c•·ts.
requirement\ en11mccring Used m the systems planning phase of the SDLC. It invoh·cs using various
focr-finding techniques, such as interviews, 5urvers, observation, and samplmg, ro d~nt>c the current
system and ident1f) the requ1rcmcni> for the new sysrem.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter I
Introduction to Systems Analysis and Design
40 Key Terms
SL-.alablc Ille abihry of a S)»tem to expand ro meer new business requirements and 'olumes.
;en ice-oriented A comp:my that primarilr offers information or o,erviu:·~ or .,.,11, i;0<xh produced b}
other\.
\ofc"arc A proi;ram run h)· computer. for a >pec1Fic functmn or ta.>k.
>p1r.tl modd A developmem modd wub a series of iterations. or rev1s1oos. ba.cd on user feedback.
s1akcholdu An)·one who 1s affected by cbe companr's performance, sud1 as customers. emplO)'ttS, suppliers.
srockholdcrs. and members of the comrnuruty.
\tratt111c plan' The loni;-rani;c plans thar define the corporate mis,ion and goal\. Typically defined by
top manni;cmcnt, with inpuc from all le,·els.
\trucmrcd anal)~;, A trndirional sysrems developmenr cechnique that U'>e'> phase; ro plan, analpc,
de,ii;n, 1mplemenr, and \ uppon on information sysrem. Proces•es and cla1a Jrc treated a' scpara1t
component•.
supply cb.un A rradmon,11 systems developmenr ceduuque th.ir uses phases to pl.111, analyze, design,
implenienr. and supporr ;rn information sysrem. Processes and data .ire treated as scp.iratc
componcn1s.
suppl> chain management (SCM! The coordination. integracion, and man,1gemenr of materials, infor·
ma11on. and finances as they move from suppliers to customers, both w1dun and between comparues.
In a rornlly 1megr.1ted supply chain, J. customer order could CJ use J production planrung
system to schedule a work order, which in rum could mgger a call for certam pJrtS from one or
more suppliers.
\)'tern \ o;et of related componcnrs thac produces specific re~uJt.,.
')\tern dc-.1gn 'fl"ofic:uion A document that preo;encs the complece design for the new information'>"'­
tem, along with derailed ccMs, ~mffing, and scheduling for completing chc next SDL.C pha\c, \)\tern<.
implemcm.atson. Also called the technical d~'h'" \pc<:1fo:at1un ur the dct:ulcd de,1i;n 'pcc1fica11on.
>)>tCm requirement> document A docwnent !hat conram> the reqwremelll> for the new S) >tern. describes
the .iltern.im ts th.ii were considered, and makes a specific r«ommend.mon to mana~ement. It 1s the
end product of the systems aoal)·s1s phase.
S}Stcm software Programs that control the comp uter, including chc opcranng sysrcm. de' ice drive~ that
commumca1e \~uh hardware, and lo"·level utilities.
\)>IClll\ anal)\I\ and dcsii;n The process of developing information sy\rems that eff1.-crively uo;e hardware,
wftware, data. proces~cs, and people to support the cumpany'; bussn""' obje ... uvc,.
');tcm\ anal)\i\ pha\c The >ewnd SDLC phase. The purpose of this ph.i;e I> to build a log"al model of
rhc new sr,rcm.
systems anal) st A person who plans, analyzes, and implemcnrs mformanon systems. They 111.1y work
im crnall y within a compan) 's IT department o r be hired b) a company as an independent consultant.
~>SICm\ design pha~c The third SDLC phase. Thie purpose of syotems design is to creme a bl ueprint for
the new S)'\tem that will sacisfy all documented requirements, whether the syMem is being developed
in-how.e or purchased os a package.
~)>lcm; Jc•cloprncnt life C)dc (SDI C) Activiti~ and fum:rions that ;ystcm> developers t)pically per·
form, rci;a rdlc's of how tho•c acnvirics a nd foncrions fit mro a partkular mcthodolofly. The SDI C
model include~ five phaws: ( I) sysccms planning, (2) systems analysis, Pl sy\tcms dcsifln, (4) sy,tcms
implementation, and (5) systems support and securiry.
')\!Cm' implcmcntauon phase The fourth phase of the SDLC. During this pha;c, the ne'~ &)Stem is con·
sm1ctcd-pr~rams arc wmtcn, tested, and documented, and the ;ystcm is ms1,1llcd.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase I
Systems Planning
Key Terms
4 1
S}Stcms pbnntng pha~c lhc first phase of the SDLC. During this phase, che S)>tems prOJl'Ct get> starred.
rhc proic.:t propo •.il is C\,ilu.ued to determine its fea.ibility. lhe project managemem pl.in 1s formu-
1.itcd, w11h the help of <...ASL rooh where appropnatc.
~}~tcm• requc\t A form~! rcquc\t to the IT department that describe~ problem' or dc\ircd .:hangc\ tn an
information \)'\tcm or bu\inc\s process. It might propose enhancements for an cxi~nng >)'Stem, the
correctmn of problem,, or the development of an entirely new S)"'item.
\}~ICm\ \uppon and ~Cl'Urit) pha,c During the sysrems support and !>CCUriry pha..e of the SDLC, the rr
\laff maintain\, cnhan.:o:\, and protect' the .,y;rcm.
techni,aJ support Tcchmcal supporr is neces>ar)' ro supporr che wide \Jtiet) of 11 S)Stellli .ind u>ers. lt
mdudes six mam funcuons: applicanon developmenr, systems support, user support, d.11JbJse .1dmtnis1ra11on,
nttwork admin1strarion, and web support. These functions ovcrl.ip cons1dr.rably and often
have diffcrrnr names 111 different companies.
transaction proccssiog !Tl') S)'Stcnt~ Operational systems used co process day-10-day recurnng business
cransacuons, such as cusromer billing.
u.,..,r produl!i' ity '}'lcnh Applkation' 1hm provide employet:s of :ill levch n wide array of tool, to
improve jnh performance. Fxamplc' indudc email, word prcx:c,;in11, graphic~, nnd comp.111y inrrnncc-.
met\ 'irakcholdcr- in,idc and out~idc the company who wil I mrc:ract with the 'YMcm.
vertical S}SlCUI A S)'Srem designed to meet the unique requirements of a spectf1c busmess or mdustry,
such as a wtb-based retailer or nuro-supplr srore.
warcrfall model The tradmonal model of soft\vare de,·elopmenr. A graph that depicts the result of each
5DLC phase £lowing do,~o mto the nei.r phase.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter I
Introduction to Systems Analysis and Design
42 Exercises
Exercises
Questions
1. Whac is information rechnology, and why is it imporranr co socicry?
2. What are the five main components of an information S)'Stem?
3. Explain how ndcsharing services such as Uber and Lyft are disrupting rradir1onal raxicab business
models.
4. Describe the busine~s profile of a home improvemenr srore like Home Depot or Lowe's and how it i~
used.
5. What are the seven types of information systems used in business?
6. What cypes of informacion do the four organizational levels common ro many businesses need?
7. Compare three sysrems dcvelopmenr merhods.
8. Name rhe tools rhar enable che sysccms analyst to develop, manage, and maintain large-sca le informa·
tion systems.
9. Sumrn:irizc the seven main functions of rhe IT department.
I 0. Whar arc the roles and responsibilities of a sysrems analysr in a modern business?
Discussion Topics
1. Some experts believe rhar rhc growrh in e-commerce will cause states and local governments ro lose
rax revenue, unless lmcrner transactions are subject ro sales rax. Whar is one argument rhar supports
this view and one rhar opposes ir?
2. When team memberl> .ire geographically dispersed, communication bccomcl> more challenging.
Explain how groupware can increase user producrivicy in chis contexc.
3. Under whac circumsrances should a systems analyse recommend an agile merhodology over Struccurcd
devclopmenr or ob1ecr-orienced analysis?
4. Should che IT dirccror reporc co che company presidenc or somewhere else? Does it marrer?
5. Rapid advancements in areas such as machine learning and predictive analycics in dara science are
affecting the daily operarions of many IT deparnnenrs. What should a syscems analyst do ro stay
currenr?
Project s
1. Contact three people ac your school who use informacion systems. Lise cheir positions, the mformacion
they need, the sysrems they use, and the business functions they perform.
2. Visir rhree websites ro learn more about agile system development. Prepare a lisr of the sires you visited
and a ~ummary of the results.
3. Model-based systems engineering (MBSE) is one of che leading methods used by systems analyses to
develop informarion systems. Cameo Systems Modeler is one of the leading cools supporting MBSE.
Research magazine articles and the web ro learn more about this tool's capabilities. Identify three of
its srrengrhs in terms of improving rhe qualiry of the finished product.
4. Explore the Critical Thinking Community website ac criticalthinki11g.org. Identify three importanr
topic~ currencly being di~cussed and describe your findings.
5. Compare the corporate culrure of three leading IT companies and show how rheir ~tarement of values
could atcracr (or repel) sysrems analysts from joining their organization.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

Chapter 2 Analyzing the Business Case
Analyzing the
Business Case
Chapter 2 explains how to analyze a business case.This
chapter also explains why it is Important to understand
business operations and requirements, how IT projects
support a company's overall strategic plan, how systems
projects get started, and how systems analysts conduct
a feasibility study and perform preliminary investigations,
which concludes with a report to management.
Fact-finding techniques that begin at this point and carry
over into later development phases are also described.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" asks the
systems analyst to consider the Implications of granting
preferential treatment to a system enhancement
request when the request originates with a friend of the
project's manager.
LEARNING OB ECTIVES
Wl1e11 you fi11isb this d1apter, you s/Jould be able
to:
I. Describe the strategic planning process.
2. Conduct a SWOT analysis.
3. Explam how cools can support strategic
planning.
4. Explain the concept of a business case.
5. Summarize the ~ix main rea~ons for systems
requests.
6. Describe the two factors affecting systems
projects.
7. Explain how systems requests are processed.
8. Explain how systems request feasibility is
assessed.
9. Explain how systems requests arc prioritized.
I 0. Conduct a preliminary invesrigarion.
CONTENTS
2. 1 Strategic Planning
Case in Point 2. 1: Pets for Rent
2.2 Strategic Planning Tools
2.3 The Business Case
2.4 Systems Requests
2.5 Factors Affecting Systems Projects
2.6 Processing Systems Reque~cs
Case in Point 2.2: Actaway Airlines, Part One
2.7 Assessing Request Feasibility
2.8 Setting Priorities
Case in Point 2.3: Arra way Airlines, Parr Two
2.9 The Preliminary Investigation
A Question of Ethics
2. 10 Summary
Key Term~
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase I
Systems Planning
2.1 Strategic Planning
45
2 I STRATEGIC PLANNING
Strategic planning is the process of identifying long-term organizational goals, strategies,
and resources. A strategic plan looks beyond day-to-day activities and focuses on
a horizon that is three, five, ten, or more years in the forure. The IT ream must deliver
IT resources ro support the firm's long-term strategic goals. Therefore, IT managers
and systems analysts must understand and participate in strategic planning acriviries.
IT managers ha\'e ro prepare for long-range needs, such as a new darn warehouse,
even as they handle immediate problems, such as a logic bug in the payroll system. In
mosr companies, the IT ream reviews each IT-related proposal, project, and systems
request ro determine if it presents a strong business case, or justification.
T he following sections provide an overview of strategic planning, a description of
SWOT analysis, and a look at the role of the IT d epartment.
2. 1. 1 Strategic Planning Overview
Strategic planning starts with a mission ~ tatemen t that reflects rhe firm's vision, purpose,
and v:ilues. Mission statements usually focus on long-term challenges and goals,
the importance of the firm's stakeholders, :rnd a commitment to the fi rm's role as a
corporate citizen. For example, Google's mission statement posted on their website is
stated succinctly as," ... to organize the world's information and make it universally
accessible and useful."
\Vi ch the mission statement as a backdrop, a f'irm develops short-term goals and
objectives. For example, the company might establish one-year, three-year, and fiveyear
goals for expanding market share. To achieve those goals, the company might
develop a list of shorter-term objecrives. lf it wants to increase online orders by
30% next year, a company might sec quarterly objectives with monthly milestones.
High-priority objectives arc called crirical success factors. A critical success factor is
one that must be achie\'ed to fulfill the company's mission.
Objccti\•cs also might include tactical plans, such as creating a new website and
training a special customer support group to answer email inquiries. Finally, the objectives
translate into day-to-day business operations, supported by IT and other corporate
resources. The outcome is a sec of business resulcs thar affect company stakeholders.
Pets for Rent is an innovative company that brings puppies to corporate meetings.
The company's CEO says that having puppies in a room with employees in an informal setting
helps break down communication barriers and fosters. a greater sense of teamwork and comradery.
Since this is a new company, the CEO has asked you if a mission statement is necessary.
After you review the chapter material, write a brief memo with your views. Be sure to include
good (and not-so-good) examples of actual mission statements that you find on the web.
2. 1.2 SWOT Analysis
The letters SWOT stand for strengths, weaknesses, opportunities, and threats. A SWOT analysis can focus
on a specific product or project, an operating division, the entire company, or the mission statement itself.
The overall aim is to avoid seeking goals that are unrealistic, unprofitable, or unachievable.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 2 Analyzing the Business Case
46
2.1 Strategic Planning
STRENGTHS
• Excellent web design staff
• low systems analyst
turnover
• Recently upgraded notwork
OPPORTUNmES
• Well-pos1Uoned for expansion
• Can be first with new
software
• High potenbal tor B2B
growth
An enterprise SWOT analysis usually begins with these questions:
• What are our strengths, and how can we use them to achieve our business goals?
• What are our weaknesses, and how can we reduce or eliminate chem?
• \'Qhac arc our opportunities, aod how do we plan ro rake advanragc of them?
• \'Qhat are our threats, and ho\V can we assess, manage, and respond m the possible
risks?
WEAKNESSES
• Still using 58\/eral legacy
systems
• Budget Increase was turned
down
• Documentation needs updaUng
THREATS
• Aggressive new web
competition
• Impact ol new FCC rules
• Other firms oller bener
benefits
FIGURE 2 - 1 A SWOT analysis might produce l"e$Ults similar to those
shown here.
A SWOT analysis examines a
firm's technical, human, and financial
resources. In Figure 2-1, the
butlered lists show samples of rypical
strengths, wca kncsscs, opportunities,
and threats for an organization considering
cxp:tnding their web-based
online operations.
As the SWOT process conrinues,
management reviews specific
resources, business operations, and
valm1blc assets. For example, suppose
rhat the company owns an imporranr
patent. A SWOT review for rhe parent
might resemble Figure 2-2.
There is no srandard approach to
strategic planning. Some managers
believe that a firm's mi sion sratement
!.hould contain an inspirational
message to its stakeholders. Others
feel that unless a firm starts with a
realistic SWOT assessment, ic might
develop a mission statement that is
unachievable. Most companies view
the strategic planning process as a dynamic iorcraction, where the company's mission
statement reflects a long-term horizon, but sets forch goals that arc achievable and
consistent with real-world conditions.
2. 1.3 The Ro le of the IT De partment
A systems analyst should be interested in strategic planning because it reflects a
higher level of involvement in supporring the direcrion of rhe project. For example,
while working on rhe same project, one analyst might say, "I am using a CASE cool,"
while another might say, "I am helping the company succeed in a major new business
venture." Systems analysts should focus on the larger, strategic role of the IT department
even as they carry out their day-to-day technical tasks.
Experienced analysts know that planning is essentia l for IT project success, and it
must srarr as early as possible. Careful planning can help assure chat:
• The proiect supports overall business strategy and operarional needs.
• The project scope is well defined and clearly stated.
• The project goals are realistic, achievable, and tied ro specific statements,
assumptions, constraints, factors, and other inpucs.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
2.3 The Business Case
47
During the planning process, management
and IT should be closely linked. In
the past, a typical IT department handled
Strengths
all aspects of systems development and
consulted uc;er~ only when, and if, the
• Our patent covers valuable
technology that we can use in
depamnent wanted user input. Today,
popular products
systems development 1c; much more
team-onenred. New approaches to systems
development, such as agile methods,
Patent
typically involve groups of users, managers,
Opportunities
and IT staff working together right from
• We can use the technology on
the start of the project.
more products, license 11 to
Although ream-oriented development
others, or seek more patents.
is the norm, some companies still sec the
role of the IT department as a gatekeeper,
responsible for screening and evaluating
systems requests. Should the IT department
perform the initial evaluation, or shouJd
a cross-functional team do it? The answer
probably depends on rhc company's size, the nature of the system request, and the
scale of the project. For example, in smaller companies or firms where only one person
has IT skills, that person acts as a coordinator and consults closely with users and
managers to evaluate systems requests. Larger firms are more likely to use an cvaluarion
team or a srsrems review committee.
SWOT Analysis of a Corporate Patent
Weaknesses
• Our patent has a hmrted Me
Whetl 11 expires. the technology
will no longer be prot8C1ed
Threats
• A compehtor might develop
similar technology thal does
not legally lnfnnge our patent.
FIGURE 2-2 This SWOT analysis example focuses on a specific asset: a
company patent.
2 2 STqATEGIC PLAl'INING TOOLS
Irrespective of the development strategy used, many organizations still rely on the IT
group to provide guidance when it comes to selecting tools to support strategic planning
activities. Some analyses srick to tradicional text-based methods, using tvlicrosofc
\'(lord rabies, to pro,•ide srrucrure and clarity. Ochers prefer a spreadsheet, such as
t..1icrosoft Excel, because it is easy to display prioriries and the relative importance of
planning assumptions.
A more sophisticated approach is co use a CASE tool to define and document the
overall environment. Such tools can integrate various statements, entities, data elemencs,
and graphical models into an overall structure. The result is more consistency,
better quality, and much less effort for the system analyst. Figure 2-3 shows a cloudbased
road mapping software product from Aha! chat provides inccgraced support for
product scracegy visioning and strategy develop1nent.
There arc other strategic planning "cools" that are not CASE tools, bur more techniques
that ore sometimes supported by software programs. For example, mind maps,
balanced scorecards, and gap analysis are all valuable techniques thac can be parr of strategic
planning in an organizarion. An imporrant role for the systems ana lyst is to know
when each of these rools and cechniques can best be used in particular project conwxcs.
2.3 THE BUSINESS CASE
During the systems planning phase, the IT ream reviews a request co determine if
it presents a strong businesc; case. The term business case refers co the reasons, or

c..
Chapter 2 Analyzing the Business Case
48 2.3 The Business Case
Ahal -- _, -
_,,
-
.....
-
0 Strategy first
- - -
.....,..............,,... ... .......... I"'
.... ....-.;,~ -=---
-
·-~-- ·-- .-- ••• • •
=
- -
,_. ._..,_,............ --
~
_.,. .......... .,_, .. ...,., .. .,.... ....
... -"«.,... ..... ..., ......
FIGURE 2-l Aha! provides Integrated support for product strategy visioning.
·~• .&.1\. 1 ,_
jusrificarion, for a proposal. To perform rhe review, the analysr muse consider rhe
company's overall mission, objectives, and IT needs.
A business case shouJd be comprehensive yet easy to understand. It should
describe rhe project clearly, provide the juscificarioa to proceed, and estimate the project's
financial impact. SpecificaUy, che business case should answer questions such as
the following:
• Why are we doing this project?
• What is the project about?
• How docs this solution address key business issues?
• I low much will it cost and how long will it rake?
• Will we suffer a productivity loss during the transition?
• What is the return OJl investment and payback period?
• What arc the risks of doing rhe project? What are the risks of nor doing the
projccr?
• How will we measure success?
• What alternatives exist?
Examples of business cases, borh good and bad, can be found on line. Just search
for "sample business case" and examine the structure and content of some of rhe samples
available. It is particularly instructive to compare and contrast business cases for
different areas, such as chose for go\•emmenr contracts versus private enterprises.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.4 Systems Requests
49
2.4 SYSTEMS REQUESTS
The starting point for most information
systems projects is called a systems request,
which is a formal way of asking for IT
support. A srsrems requesr might propose
enhancements for an existing system, the
correction of problems, the replacemenr
of an older sy rem, or rhe developmenr of
an enrirel)• new informarion sysrem char is
needed ro support a company's currenr and
future busine s need .
As Figure 2-4 shows, rhe six main reasons
for ~ystems request are stronger controls,
reduced cost, more information, bener performance,
improved service to customers, and
more support for new produces and services.
More
Suppo<1
Improved t/
Service _J
Stronger
Controls
Systems
Request
Better
Performance
J
Reduced
Cos1
I
More
lnlormatt~
STRONGER CONTROLS: A system must
have effective controls to ensure that data
is secure and accurate. This is becoming
increasingly important given the number
of darn breaches that seem to occur on a
daily ba!.i . ome common securiry controls
include passwords, various levels
of user acces~, and encryption, or coding
data to keep it safe from unauthorized
users. l lardware-based security conrrols
include biometric devices that can identify
a person by a retina scan or b>• mapping
a fingerprint pattern. The technology uses
infrared scanners that create images with
thousands of measurements of personal
physical characteristics, as shown in
Figure 2-5, which displays Apple's Face ID
security mechanism on the iPhonc.
In addition to being secure, data also
must be accurate. Controls ~hou ld minimize
data entry errors whenever possible.
For example, if a user enters an invalid
customer number, the order processing
system should reject the entry immediately
and prompt the user to enter a valid
FIGURE 2-4 Six main reasons for systems requests.
FIGURE 2-5 Apple Face ID uses advanced machine leamirig co recognize users.
number. Darn entry controls must be effective without being excessive. If a !.)'Stem
requires users to confirm every item with an "Are you sure? YIN" message, internal
users and customers might complain that the system is not user-friendly.
REDUCED COST: The current system could be expensive ro operate or maintain
as a result of rechnical problems, design weaknesses, or the changing demands of che
busine s. Ir might be possible to adapr the system co newer technology or upgrade
it. On the other hand, cost-benefit analysis might show that a new system would be
more cost effective and provide bener supporr for long-term objectives.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
so
2.5 Factors Affecting Systems Projects
MORE INFORMATION: The syscem mighc produce informacion char is insufficienc,
incomplere, or unable ro supporc the company's changing informarion
needs. For example, a syscem chat tracks customer orders mighr nor be capable of
analy1.1ng and predicring marketing rrends. In the face of intense compericion and
rapid product development cycles, managers need the best po~s1ble informacion
to make major decisions on planning, designing, and marketing new products and
services.
BETTER PERFORMANCE: The current system mjght not meec performance requiremencs.
For example, ic n1ighc respond slowly co data inquiries at certain times, or it
mighc be unable co support company growth. Performance limicarions also result
when a system that was designed for a specific hardware configuration becomes
obsolete when new hardware is introduced.
IMPROVED SERVICE: Systems requests often are aimed ac improving service ro customers
or users within the company. For instance, allowing mutual fund investors ro
check their account balances on a website, storing data on rental car customer preferences,
or creating an online college registration system arc all examples of providing
valuable services and increased cusromer satisfaction.
MORE SUPPORT FOR NEW PRODUCTS AND SERVICES: New products and
services often require new types or levels of IT supporc. For example, a sofrware
vendor might offer an automacic upgrade service for subscribers; or a package delivery
company might add a special service for RFID-tagged shipment!>. In situations like
rhe!>e, it is most likely that addjtional IT support will be required. At the other end of
the speetrum, product obsolescence can also be an important factor in IT planning. As
new products enter the marketplace, vendors often announce that they will no longer
provide support for older versions. A lack of vendor support would be an important
consideracion in deciding whether or not to upgrade.
2.5 f ACTORS AFFECTING SYSTEMS PROJECTS
internal and external factors affecc every business decision that a company makes,
and IT projects are no exception. Figure 2-6 shows internal and external factors that
shape corporate IT choices.
2.S. I Internal Factors
Internal focrors include the strategic plan, top managers, user requests, information
technology deparcment, existing systems and data, and company finances.
STRATEGIC PLAN: A company's srrategic plan sets the overall direction for the
firm and has an important impact on IT projects. Company goals and objectives rhat
need IT support will generate sysrems requests and influence IT priorities. A strategic
plan that stresses technology rends to create a favorable climate for IT projects that
extends throughout the organization.
TOP MANAGERS: Because significant resources arc required, top management usually
initiates large-scale projects. Those decisions often result from strategic business
goals that require new IT systems, more information for decision making processes,
or better supporr for mission-critical information systems.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.5 Factors Affecting Systems Projects
5 1
Government
External Factors
Lr-----
Teclinology
l.._ ____ ~J -...
Suppliers
The Economy l.
------
Competitors J L -----­
Custome~
FIGURE 2·6 Internal and CKternal factors that affect IT projecrs.
USER REQUESTS: As users rely more heavily on information systems to perform
their jobs, they arc likely to request even more IT services and support. For example,
sales rep might request improvemencs to the company's web ire, a more powerful
sales analysis report, a network ro link all sales locations, or an on line S)'Stem that
allows customers to obrain the status of their orders instantly. Or, users might nor
be satisfied with the current system because it is difficult to learn or lacks flexibtliry.
They might want 111formation S)'Stems support for business requirement!> that did nor
even exist when the S)'Stem was first developed.
INFORMATION TECHNOLOGY DEPARTMENT: Systems project requests come also
&om the IT department itself. TT staff members often make recommendations based
on their knowledge of business operations and cechno1ogy trends. IT proposals might
be strictly technical matters, such as replacement of certain nenvork components, or
suggestions might be more business oriented, such as proposing a new reporting or
data collection srstem.
EXISTING SYSTEMS AND DATA: Errors or problems in existing systems can trigger
requests for sysrcms projects. When dealing with older systems, analyses sometimes
spend coo much rime reacting ro day-to·day problems without looking at underlying
causes. This approach can curn an iniormarion system into a patchwork of corrections
and changes that cannot support the company's overall business needs. This
problem typically occurs with legacy systems, which are older systems rhat are less
technologically advanced. When migrating ro a new system, IT pl:inners must plan
the conversion of existing data, which is described in detai l in Chapter I I.
COMPANY FINANCES: A company's financial status can affect systems projects.
If rhe company is going through a difficult time, the project may be postponed until
there is more cash available to finance the effort. On the other hand, if the company
is enjoying financial success, the decision ro embark on a new project may be easier to
make.
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~---- ···---~~ - .,.-"~ ........... --......

Chapter 2 Analyzing the Business Case
52
2.5 Factors Affecting Systems Projects
•
FIGURE 2·7 QR Code.
2.S.2 External Factors
Exrernal facrors include technology, suppliers, cusromers, comperiror<;, the economy,
and government.
TECHNOLOGY: Changing technology is a major force affecting business and society
in general. For example, the rapid growth of telecommunications, coupled with
increased computing power and continuous miniaturization of electronic components,
has created entire new industries and technologies, including the proliferarion
of smarrphones and the app ecosysrem.
Technology also dramatically reshapes existing business opcrarions .
The success of scanner technology resulted in universal bar coding rhat
now affects virtually all products. Some industry experts predict that
bar code technology, which is over 40 years old, will be overshadowed
in the furure by electronic product code (EPC) technology that uses
RFID rags to identify and monitor the movement of each individual
product, from the factory floor to the rernil checkout counter.
Quick Response codes (QR Codes), as shown in Figure 2-7, are like
bar codes bur square in shape. They contain more information than
traditional bar codes, but less than RFID rags. T hey do ha vc the advantage
of being less expensive to use than RFID rags, and they can be
printed on almost anything-including online advertisements.
The Internet-of-Things (JOT) is a newer development that involves
almost all electronic devices con1municating with one another over a computer
network. The communication can use radio signa l ~, as with RFID
cags, digical messages, or other means. loT devices can act as sensors, sending
important information to centralized data storage and procetising nodes. Io T devices
also raise new security and privacy concerns that the systems analyst must coru.ider.
SUPPLIERS: With the growth of clcctroaic data interchange (EDI), relationships with
suppliers arc crirically importanr. For example, an automobile company might require
that suppliers code their parts in a certain manner to march rhc auto company's inventor)'
conrrol system. EDI also enables just-in-time UIT ) inventory ystems that rely on
computer-to-computer data exchange to minimize unneces ary inventory. The purpose
of a JIT system is to provide the right products at the right place at rhc right rime.
Blockchain technology is a promising mechanism for managing upply chains more
powerfully rhan before. Blockchain provides a distributed ledger ysrem that is efficient,
secure, transparent. Large companies such as 181\ll are already using blockchain
to improve operarions for their customers, such as the Food Trust product shown in
Figure 2-8 rhar \'<'almart uses for tracking food safety from grower to consumer.
IBM Blockchaln at work
FIGURE 2·8 IBM 81ockcha1n.
Sourt• »1(
,....~.....nc:rwe,..; ,.._..___,.
......
_
......._.___.
..
.........
----~----- __...._,.,._...,..,. ._.. .....__ ..__ .......
-..............
--­·--
._ ......
---
..... _,..._
---- ......
.....--------.
. .............. ".
.-....
-
-........__
(....,..... J:gi ( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

2.5 Factors Affecting Systems Projects
Phase I
Systems Planning
53
CUSTOMERS: Customers are virally important 1to any business. Information S)'Stcm
that interact with customers usually receive top prioriry. Many companies implement
customer relationship management (C RM) systems char integrate all customer-related
event<; and transactions, including marketing, sales, and customer service acnvines.
Vendor-oriented CRNI systems often interconnect with supply chain management
(SCM) systems, which were discu sed in Chapter 1. CR;\it components can provide
automated responses to sales inquiries, online order processing, and inventory tracking.
Some suppliers use robots for order fulfillment, such as the Kiva robots shown in
Figure 2-9 rhar Amazon.com uses in their warehouses.
FIGURE l -9 Amnon Roboucs' Krva robots.
Another RFID application is called electronic proof of delivery (EPOD). Using
EPOD, a supplier uses RFID tags on each crate, case, or shipping unit ro create a digital
shipping list. The customer receives the list and scans rbe incoming shipment. If a
discrepancy is detected, iris reported and adjusted automatically. Because they would
be expensive ro invesrigare manually, small shipping inconsistencies might nor otherwise
be traced. This is an example of technolog)r-related cost control.
COMPETITORS: Competition drives many information systems decisions. For
example, if one cellula r telephone provider offers a new cype of digiral service, orher
firm s musr match rhe plan in order to remai n competitive. New product research and
developmcnr, marketing, sales, and service all require IT support.
THE ECONOMY: Economic activity bas a powerful influence on corporate
information management. In a period of economic expansion, firms need to be rea<ly
with i.calable systems that can handle additional volume and growth. Predicting the
business cycle is not an exact science, and careful research and planning are important.
GOVERNMENT: Federal, stare, and local government regulations directly affect
the design of corporate information systems. For example, up-to-dare fRS reporting
requiremenrs must be designed into a payroll package.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
54 2.6 Processing Systems Requests
2.6 PROCESSING SYSTEMS REQUESTS
In most organizacions, che IT deparcment receives more systems requests than it can hancUe.
Many organizations assign responsibility for evaluating systems requests to a group of
key managers and users. tvlany companies call this group a systems rC\ iew com mince
or a computer resources committee. RegardJess of che name, che objective 1s to use the
combined judgn1ent and experience of severaJ analysts co evaluate project requests.
2.6. 1 Systems Request Forms
Many organizations use a special form for systems requests, similar to the online sample
hown in Figure 2-10. A properly designed form streamlines che request process and
ensures consistency. The form must be easy to understand and include clear instructions.
It should include enough space for all required information and )hould indicate
what supporting documents
are needed. Most companies
use onJine systems request
Submit Roqueet
forms rh:H users submit electronically
because the form can
Tech Support Request Sysleni 1/ •• r1,.:.. ·"~' :: .. ·, ~· ,,, "'·'"''· 1
o-awio .. ~
__ ., olllllO Cl• 7 • )
oa- .... o ...
FIGURE 2- 10 Example of an onhne systems request form.
be processed automatically.
When a systems request
form is received, a systems analyst
or IT manager examines it
co determine what IT resources
arc required for the preliminary
investigation. A designated
person or a committee then
decides whether m proceed
wirh a prelimmary inve tigation.
omerimes, a situation
requires an immediate response.
For example, if the problem
involves a mission-critical system,
an IT maintenance team
must restore normal operacions
immediately. \'Qhen the sysrem is functioning properly, die ream conduce a review and
prepares a systems request to docwnent the work that was perfom1ed.
2.6.2 Systems RequestTools
\Xfhen the number of requests su bmitted through automated fo rms becomes significant,
or if the requests can originate from internal sources as well as extern a I customers,
special-purpose systems request tools can be used to help manage the work flow. For
example, Figure 2-'l 1 ill ustrates the service request capabilities from l'nregrify that captures,
manages, and routes requests to systems analysts based on definable business
rules. In th is way, requests are tracked and analyzed for improved performance.
2.6.3 Systems Review Committee
Most large companies use a systems review comminee to evaluate systems requests.
Instead of relying on a single individual, a committee approach provides a variety of
experience and knowledge. \Vith a broader viewpoint, a committee can establish priorities
more effectively tban an individual, and one person's bias is less likely ro affect
the decisions.
(....,..... J:gl( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.6 Processing Systems Requests SS
A rypical committee consists of
the IT director and several managers
or representarives from other
departmencs. The IT dirccror usuall)'
serve:. as a technical consultant
co ensure that committee members
are aware of crucial issues, problems,
and opportunities.
Although a committee offers
many advantages, some disadvantagei.
exist. For example, action
on requescs must wait unril the
committee meets. Another potential
disadvantage of a committee is
that members might favor projects
req uested by their own departments,
and internal political differences
could delay important decisions.
M any sma ller companies rely
on one person to evaluate sysrem
requests instead of a committee. If
C . ··• •' "' .... c • • • • '·' p ::::. GM11o.rno
Service Request Management
-·----................... ~ ...........
.... &"!ilil• ~ ---·-----~----.... ·--
.. ........
---.....
._ ~ .......
--~..-.........................
...,.._,___..., _
_.. .... ,... .............. _... ......
- ........ ---..... ,..._ ...................... ~o..
.........
.........;ill........._.............,. ___
-- -- -
--
s..1.....-r .. -
FIGURE 2- 11 A service request management system from lntegrify.
only one person has the necessary IT skills and ex perience, that person must consult
closely with users and managers throughout the company to ensure that bu5iness and
operational needs arc considered carefully.
\Vherher one person or a commitrec is responsible, the goal is to evaluate the
requests and ser priorities. Suppose four requests must be reviewed:
1. The marketing group wanes to analyze current customer spending habits and
forecast future trends.
2. The technical supporr group wanes a cellular link, so sen•ice representatives can
download rechnical dara instantly.
3. The accounting department wanes ro redesjgn customer starements and allow
Internet access.
4. The producrion sraff wants an inventory control system that can exchange dara
wirh major suppliers.
\'<lhich projects should che firm pursue? What criteria should be applied? I low
should priorities be determined? To answer chose questions, the individual or the
commirtce muse assess rhc feasibiliry of each request.
__ , . . . - . . ~
. CASEJN ;.P.OINfl:,.2.2: ,A TIT AWAY AIRLINES, ~ RART:: O;,a·>
·.:4
' .
-- ---- -
You are the IT director at Attaway Airlines, a small regional air carrier.You chair the
company's systems review committee. and you currently are dealing with strong
disagreements about two key projeets. The marketing manager says it is vital to have a new
computerized reservation system that can provide better customer service and reduce operational
costs. The vice president of finance is equally adamant that a new accounting system
is needed immediately because it will be very expensive to adjust the current system to new
federal reporting requirements. The VP outranks the marketing manager. and the VP is your
boss.The next meeting, which promises to be a real showdown, is set for 9:00 a.m. tomorrow.
How will you prepare for the meeting! What questions and issues should be discussed!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 2 Analyzing the Business Case
56
2. 7 Assessing Request Feasibility
Schedule
• Can we do 11 in
time?
2. 7 ASSESSING REQUEST FEASIBILITY
As described in Chapter 1, a sysrerns request must pass several tests to see whether
it is worthwhile to proceed further. The first step is to identify and weed out systems
requests that arc not feasible. For example, a request would not be feasible if it
required hardware or software that the company already had rejected.
Even if the request is feasible, it might not be necessary. For example, a request
for multiple versions of a report could require considerable design and programming
effort. A bencr alternarive might be to download the server dara ro a personal compurerbased
sofnvare package and show users how to produce their own reports. In this
case, rraming users would be a bener investment than producing reports for them.
Somerimes assessing request feasibility is quite simple and can be done in a few
hours. If rhc request involves a new system or a major change, however, extensive
fact-finding and investigation in rhe form of feasibility studies are reqwred.
2. 7. I Feasibility Studies
As shown in Figure 2- 12, a feasibi lity study uses four main yardsticks ro measure a
proposal: operational feasibi lity, eco111omic feasibi lity, technical feasibility, and schedule
fcasibil icy.
How much effort should go into a feasibility study depends on nature of the
request. For example, if a deparunent wants an existing report sorted in a different
order, the analyst can decide quickly whether the request is feasible. On the other
hand, a proposal by the marketing department for a new market research system to
predict sales trends would require much more effort. Jn either case, the systems analyst
should ask these important questions:
• ls the proposal desirable in an operational sense? Is it a practical approach char will
soh·e a problem or rake advantage of an opporruniry to achieve company goals?
• Is the proposal technically feasible? Are the necessary technical resources and
people available for the project?
0pe1"8tlonal
• WiH If be easy to
team and vse?
Fualble?
Technlcel
• Do we have the
tech resources?
Economic
=:=a • Will b enefits
e'Kceed costs?
FIGURE l -1 l A feasibility study examines operational, technical, economic,
and schedule factors.
• Is rhe proposal economically desirable?
What are the projected saving~ and costs?
Are ocher intangible factors involved, such
as customer satisfocrion or company image?
ls the problem worrh solving, and will
the request result in a sound business
investment?
• Can the proposal be accomplished
within an acceptable rime frame?
To obtain more information about a
systems request, initial fact-finding might
be accomplished by studying organization
charts, performing interviews, reviewing
current documentation, observing operations,
and surveying users. Sometimes,
developing prototypes can provide additional
insight into the feasibility of the
request. If the systems request is approved,
more intensive face-finding will continue
during the systems analysis phase.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.7 Assessing Request Feasibility
57
2.7.2 O perational Feasibility
Operational feasibi lity means that a proposed system will be used effectively after ir
has been developed. If users have difficulry with a new sysrem, it will nor produce the
expected benefits. Orgamtarional culture can also affect operational feasibility. For
instance, a system that works well in a highly structured workplace might be very
unpopular in a more relaxed corporate culture. Operational feasibility is difficult ro
measure wirh precision but must be studied very carefully. The follo·wing questions
would help predict a system's operational feasibility:
• Does management support the project? Do users support the pro1ecr? ls rhe current
!>yi.cem well liked and effectively used? Do users see the need for change?
• \Xfill the new system result in a workforce reduction? lf so, what will happen to
the affected employees?
• Will the new system require training for users? lf so, is the company prepared
to provide the necessary resources for training current employees?
• Will users be involved in planning rhe new system right from the start?
• Will rhc new system place any new demands on users or require any operaring
changes? For example, will any information be less accessible or produced less
frequencly? Will performance decJjne in any way? lf so, will an overall gain co
the organizarion outweigh individual losses?
• Will customers experience adverse effects in any way, either temporarily or
permanently?
• Will any risk co rhe company's image or goodwill resulc?
• Does the development schedule conflict with other company priorities?
• Do legal or ethical issues need to be considered?
2.7.l Economic Feasibility
Economic feasibility means thar the projected benefits of the proposed !>ystem outweigh
the est11nated coses usually considered the total cost of ownenhip ( fCO),
which includes ongoing support and maintenance cosrs, as well as acquisition co~ts.
To determine TCO, the analyst must estimate coses in each of the folio\\ mg areas:
• People, including IT staff and users
• J lardwarc and equipment
• Software, including in-house development as well as purchases from vendors
• Formal :.tnd informal craining, including peer-to-peer support
• Licenses and fees
• Consulting expenses
• Facility costs
• The e~timatcd cost of not developing the system or postponing the project
Tangible co~ts , such as those listed above, usually can be measured in dollars. But
intangible co~ ts also must be considered. For exainple, low employee morale might not
have an immediate dollar impact, bur certainly will affect the company's performance.
In addition to costs, tangible and inrangible benefits to the company must be assessed.
The systems review commirtee will use those figures, along with the cost estimates, to
decide whether ro pursue rhe project beyond the preliminary investigation phase.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
58 2. 7 Assessing Request Feasibility
Tangible benefi ts are benefits that can be measured in dollars. Tangible benefits
result from a decrease in expenses, an increase in revenues, or both. Examples of tangible
benefits include the following:
• A new scheduling l>ysrem that reduces overtime
• An online package tracking system that improves service and decreases the
need for clerical staff
• A sophisticated inventory control system that curs excess inventory and eliminates
production delays
lniangible benefits are advantages tbat are difficult to measure in dollars but are
important to the company. Examples of intangible benefits include rhe following:
• A user-friendly system that improves employee job satisfaction
• A sales tracking system that supplies berter information for marketing decisions
• A new website that enhances the company's image
The development timetable must also be considered, because some benefits mighr
occur as soon as rhe system is operational, but others might not rake place until later.
2.7.4 Technical Feasibility
Technical feasibility refers to the technical resources needed to develop, purchase,
install, or operate the system. When assessing technical feasib ility, an analyst should
consider the following points:
• Does the company have the necessary hardware, software, and network
resources? If not, can those resources be acquired without difficult)•?
• Docs the company have the needed technical expertise? If not, can it be acquired?
• Does rhe proposed platform have sufficient capacit} for future needs? If not,
can it be expanded?
• Will a prototype be required?
• \Xfill the hardware and software environment be reliable? \Xfill tt integrate with
ocher company information systems, both now and in the future? Will ir mrerface
properly with external systems operated by customer~ and suppliers?
• Will the combination of hardware and software supply adequate performance?
Do clear expectations and performance specifications exist?
• Will rhe system be able to handle future transaction volume and company
growth?
Keep in mind that systems requests that are not currently technically feasible cao
be resubmitted as new hardware, software, or expertise becomes available. Development
costs might decrease, or the value of benefits might increase enough that a systems
request eventually becomes feasible. Conversely, an initially feasible project can
be rejected later.
2. 7 .S Schedule Feasibility
Schedule feasibility means rhar a project can be implemented in an acceptable rime
frame. \'V'hen assessing schedule feasibility, a systems analyst must consider the inter·
action between time and costs. For example, speeding up a project schedule might
make a project feasible, but much more expensive.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
2.8 Setting Priorities
59
Other issues that relate ro schedule feasibiliry include the following:
• Can the company or the IT ream control the factors chat affect schedule
feasibiliry?
• Has management established a firm cimetable for the project?
• \Xlhar condition~ must be satisfied during the development of the system?
• \Xlill an accelerated schedule pose any risks? If so, arc the risks acceptable?
• \Xl11l project management techniques be available to coordinate and control the
project?
• Will a project manager be appointed?
Chapter 3 describes various project management tools and techniques.
2.8 SFTTING PRIORITIES
After rejecting systems requests that are not feasible, the systems review committee
must establish priorities for the remaining items. lf tools are used as part of the review
process, the requests may already be in a partially or fully sorted order. The highest
priority goes to project requests that provide the greatest benefit, at the lowest cost, in
the shortest period of rime. Many faccors, however, influence project evaluation.
2.8.1 Dynamic Priorities
It's important to note that many projects are dynamic in nature. For example, projects
chat have adopted an agile merhodology are prone ro rapid changes rhroughout the system
development lifecycle. These changes can cause request priorities to change as well.
For example, acquisition costs mighc increase over time, making the project more
expensive than anticipated. This can affect the economic feasibility of a number of
requests. In addition, managers and users somecimes lose confidence in a project. For
all those reasons, feasibiliry anal)•sis and priority setting are ongoing rask that must
be performed throughout the S)'Stems development process.
2.8.2 FactorsThatAffect Priority
When assessing a project's priority, a systems analyst should consider the following:
• Will the proposed system reduce costs? Where? When? How? By how much?
• Will the system increase revenue for the company? Where? When? How? By
how much?
• Will the systems project result in more information or produce better results?
I low? Are the results measurable?
• Will rhe system serve customers better?
• \'(fill the system serve the organization berrer?
• Can the project be implemented in a reasonable time period? How long will
the results last?
• Are the necessary financial, human, and technical resources available?
Few projects will score high in all areas. Some proposals might not reduce costs
but will provide important new features. Other systems might reduce operating costs

Chapter 2 Analyzing the Business Case
60 2.9 The Preliminary Investigation
substantially but require che purchase or lease of additional hardware. Some systems
might be very desirable but require several years of development before producing
significant benefits.
\'<lhenever possible, the analyst should use tangible costs and benefits that can be
measured in dollars. However, the proposal might invoh·e intangible benefits, such as
enhancing the organization's image, raising employee morale, or improving customer
service. These examples are harder to measure but should aJ50 be considered.
2.8.3 Disc~tionary and Nondiscretionary Projects
Pro1eccs where management has a choice in implementing chem are called
di~c recion ary project!;. Projects where no choice exists are called nondiscretionary
projects. Creating a new report for a user is an example of a discretionary project;
adding a reporc required by a new federal law is an example of a nondiscretionary
project.
If a particular project is not discretionary, the systems analyst should ask if it is
really necessary for the systems review committee to evaluate it. Some people believe
th:it waiting for com111irtee approval delays critical nondiscrecionary projects unnecessaril
y. Others believe tbat submitting all requests to the systems review keeps the committee
aware of all projects that compete for IT resources. As a result, the committee
can review priorities and create realistic schedules.
Many nondiscrerionary projects are predictable. Examples include annual updates
ro payroll, cax percentages, or quarterly changes in reporting requirements for an
insurance processing system. By planning ahead for predictable projects, the IT
department manages its resources berrer and keeps the systems review committee fully
informed without needing prior approval in every case.
Back at Ar.u.way Airlines, the morning meeting ended with no agreement between the VP
of finance and the marketing manager. In fact, a new issue arose.The VP now says that the
new accounting system is entided to the highest priority because the federal government
soon will require the reporting of certain types of company-paid health insurance premiums.
Because the current system will not handle this report. the VP insists that the entire
accounting system is a nondiscretionary project. As you might expect. the marketing
manager Is upset. Can pare of a project be nondiscretionary? What issues need co be
discussed/ The committee meets again tomorrow. and the members will look to you. as the
IT director, for guidance.
2. 9 THE PRELIMINARY INVESTIGATION
A systems analyst conducts a preliminary investigation to study the systems request
and recommend specific action. After obtaining an authorization to proceed, the
analyst interacts wirh managers, users, and other stakeholders, as shown in the
model in Figure 2-13. The analyst garhers faces about the problem or opportunity,
project scope and constraints, project benefits, and estimated development
rime and coses. T he end produce of the preliminary investigation is a report to
management.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase I
Systems Planning
2.9 The Preliminary Investigation
61
2.9.1 Planning the Preliminary Investigation
Before starting a preliminary inve rigarion, iris importanr co let
people know about chc invcstigarion and explain the role of the
system analyst. 1\lleetings with key managers, users, and ocher
stakeholders such as the rT staff should be scheduled, to describe
the proiect, e'<plain roles and responsibilities, answer questions,
and invite comments. Interactive communication with users
starts at this point and continues throughout the development
process.
A systems project often produces significant changes in
company operarions. Employees may be curious, concerned, or
even opposed to those changes. It is not surprising ro encounter
some user resistance during a preliminary investigation.
Employee attitudes and reactions arc important and must be
considered.
When interacting with users, use the word problem carefully,
because ir has a negative meaning. When users are asked
about problems, some will stress current system limitations
Problem or
Opportunity
Projec1 Scope
and Cons1ra1nts
rather than desirable new features or enhancements. Instead
of focusing on difficulties, question users about additional capability they would
like to have. This approach highlights ways to improve the user's job, provides a
better understanding of operations, and builds better, more positive relationships
with users.
2.9.2 Performing the Preliminary Investigation
During a preluninary investigation, a systems analyst typically follows a series of
steps, as ~hown in Figure 2-14. The exact procedure depends on the nature of the
request, the size of the project, and the degree of urgency.
Benefits
Costs
Report to Management J
FIGURE 2- 13 Model ofa preliminary
Investigation. Note the Importance of fact-finding
In each of the four areas.
Step I: Understand t he Problem or O pportunity
lf the systems request mvolves a new informacion system
or a substantial change 111 an existing syscem, sysre1ns
analysts might need co develop a business profile chat
descnbes current business processes and funcrioos, as
explained in Chapter I. Even where the request involves
relatively minor changes or enhancements, how chose
modifications will affect business operations and ocher
information systems must be understood. Often a change
in one system has an unexpected ripple effect on another
system. When a systems request is analyzed, which
departments, users, and business processes are involved
must be determined.
Jn many cases, the systems request does not reveal
the underlying problem, bur only a symptom. For
example, a request to invest igate centralized processing
delays might reveal improper scheduling practices
rather than hardware problems. Similarly, a request
for analysis of customer complaints might disclose a
lack of sales representative training, rather than problems
with the product.
•
•
0
0
Undersland the problem or opponun11y
Dehne fhe pro1ect sc;ope and consframts _J
Perform lact-fond1ng
• Analyze organlzauon charts
• Review documentauon
• Observe operaflons
• Conducf a user survey
Study usablhty, cost, benefit. and schedule data
Evaluate feaslbllity
• Operational
• Technical
• Economic
• Schedule
FIGURE 2- 1 ~ Five main steps in a typical preliminary
invesug~uon .
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~---- ···---~~ - .,.-"~ ........... --......

Chapter 2 Analyzing the Business Case
62 2. 9 The Preliminary Investigation
A popular rechnique for investigaring causes and effecrs is called a fi 5hbone
diagram, a shown in Figure 2-15. A fishbone diagram is an analysis cool rhar
represenrs the possible causes of a problem as a graphical ourline. \Vhen using a
fish bone diagram, an analyse firsr scares rhe problem and draws a main bone wirh
sub-bones chat rcpresenr possible causes of rhe problem. In rhe example shown in
Figure 2-15, rhe problem is Low Morale, and rhe analyst has identified four areas
to investigate: £11vironme11t, People, Management, and Mac/1111es. In each area,
the analyst idenrifies possible causes and draws chem as horizontal sub-bones.
For example, Temp too hot or cold is a possible cause in rhe £11viro11me11t bone.
For each cause, the analyse muse dig deeper and ask rhe quesrion: Whar could be
causing this symprom co occur? For example, why is it too hoc? If the answer is a
Faulty thermostat, rhe analyst indicates this as a sub-bone co rhe Temp too hot or
cold cause. In ch is manner, the analyst adds addirional sub-bones to the diagram,
until he or she uncovers root causes of a problem, rather than just the symptoms.
fl! •• ~- - •• , •• _....... ·--·- :.
---~-- ....·-
•
•
--
-
...
FIGURE l - 1 S A fishbone diagram displays the causes of a problem.Typically, you must dig deeper to identify
anual causes rather than just symptoms
-
Step 2: Define the Project Scope and Constraints
Determining the project scope means defining the specific boundaries, or extent, of
the project. For example, a statemen't that, payroll is not being produced accurate/)'
is very general, compared with the statement, overtime pay is 1101 being calc11/ated
correctly (or production workers on the second shift at the Yorktown pla11t. Similarly,
the statement, the project scope is to modify the accounts receivable system, is not
as specific as the statement, the project scope is to allow customers to inquire 011/i11e
about acco1111t balances and recent transactions.
Some analysrs find it helpful ro define project scope by creating a list with sections
called Nfust Do, Should Do, Could Do, and W/011't Do. This list can be reviewed
later, during the systems analysis phase, when the systems requirements document is
developed.
Projects with very general scope definitions are at risk of expanding gradually,
without specific authorization, in a process called project creep. To avoid thi~
problem, project scope should be defined as clearly as possible. A graphical model
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.9 The Preliminary Investigation
63
that shows the systems, people, and business processes that will be affected is sometimes
useful. The scope of the project also establishes the boundaries of the preliminary
investigation itself. A systems analyst should limit the focus to the problem at
hand and avoid unnecessary expendirure of time and money.
Along with defining the scope of the project, any constraincs on the '>)'Stem must
be identified. A c on~train t is a requirement or condition that the system must .,arisfy
or an outcome that the system must achieve. A constraint can im·olve hardware,
software, rime, policy, law, or cosr. System constraints also define project cope. For
example, if the system must operate with cxisring hardware, that is a constraint that
affects porential solutions. Other examples of consrraincs are:
• The order entry sy!.rem must accept input from 15 remote site .
• The human resources information system must produce statistics on hiring
practices.
• The new website must be operational by March 1.
When examining constraints, their characteristics should be identified, as follows.
PRESENTVERSUS FUTURE: Is the constraint something that must be met as soon as
the system is developed or modified, or is the constraint necessary ar some fucure time?
INTERNAL VERSUS EXTERNAL: Ls the consrrainr due ro a requirement within the
organization, or docs some external force, such as government regulation, impose it?
MANDATORY VERSUS DESIRABLE: Is the coosuaint mandatory? ls it absolutely
essential to meet rhe constraint, or is ir merely desirable?
Figure 2-16 shows five examples of constraints. Notice rhar each constraint has
three characterisrics, which arc indjcarcd by ics position in the figure and by the srmbol
thac represents the consrrainr, as follows:
Sample Constraints Shown byTlming, Type, and Urgency
("'E;';'mple A: New IRS
I
I ~must be used 1n
!he payroll system as
as poSSlble
Example B: Sometime neX1
year our largest cus1omer wdl
require a seounty code for all
onhne transactlOlls
Present
Future
I • Mandatory constraint
•
£ • Desirable constraint
Internal
Example C: Managemen1
prefers that the project be
completed now rather
than next quarter
Example 0 : Starting next
week, the marketing system
must track all repeat visits
to the webslle.
Example E: To reduce raw material
costs. we should build supply chain
management capabthty Into lhe next
versoo of our purcnasmg system
FIGURE l - t 6 Examples of v.1nous types of constraints.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
64 2. 9 The Preliminary Investigation
• The consrraint in Example A is presenr, external, and mandatory.
• The constraint in Example B is future, external, and mandatory.
• The constraint in Example C is present, internal, and desirable.
• The constrJint in Example D is present, internal, and mandatory.
• The con rrainr in Example Eis future, interna~ and desirable.
Regardless of the type, all constraints should be identified as early as possible
to avoid future problems and surprises. A clear definition of project scope and constraints
avoids misunderstandings that arise when managers assume that the system
will have a certain feature or support for a project, but later find that the feature is
nor included.
Ste p 3: Pe rform Fact-Finding
The objective of face-finding is to gather data about project usability, costs, benefits,
;ind schedules. Fact-finding involves various techniques, which arc described
below. Depending on what information is needed to investigate the systems
request, fact-finding might consume several hours, days, or weeks. For example, a
change in a report format o r data entry screen might require a single telephone call
or email message to a user, whereas a new inventory system would involve a series
of interviews. During fact-finding, the analyst might analyze organization charts,
conduct interviews, review current documentation, observe operations, and carry
out a user survey.
ANALYZE ORGANIZATIO N CHARTS: An analyst will not alway~ know the organi­
.tational structure of departments involved in the study. Organization charts should be
obtained to understand the functions and identify people to interview.
If organization charts are not available, or are out-of-date, the necessary information
should be obtained from department personnel and construct the charts, as
shown in Figure 2-17.
Even when charts are available, their accuracy should be verified. Keep in mind
that an organization chart shows formal reporting relationships but nor the informal
alignment of a group, which also is important.
Customer Service Department
FIGURE 2- 17 Specialo:z.ed tools such as MlcrosoftVisoo an be used to draw
organizational charu. but general purpose presentation tools such as Microsoft
PowerPoint shown here can also be used.
primary merhod of obraining
information during the preliminary
investigation is the interview. The
interviewing process involves a
series of steps:
CONDUCT INTERVIEWS: The
1. Determine the people to
interview.
2. Establish objecri vcs for the
interview.
-
3. Develop interview questions.
4. Prepare for the interview.
~ 5. Conduct the interview.
6.
7.
Document the interview.
Evaluate rhe interview.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2.9 The Preliminary Investigation
65
These seven steps arc discussed in derail in Chapter 4, which describes fact-finding
techniques that occur during the systems analysis phase of the SDLC.
Rememher that the purpose of the interview, and of che preliminary mvestiganon
itself, is co uncover facts, nor ro convince others char che project is justified. The
analyst's primary role in an interview is co ask effective questions and listen carefully.
If several people will be asked about the same topic, a standard set of questions for all
the interviews should be prepared. Also be sure to include open-ended que ttons, such
as " \Xlhat else do you think I should know about the system?" or .. Is there any other
relevant information that we have not discussed?"'
\'(!hen conducting interviews during the preliminary investigation, interview managers
and supervisors who have a broad knowledge of the system and can provide an
overview of the business processes involved. Depending on the situation, talking to
operational personnel to learn how the system functions on a day-to-day basis may
also be helpful.
REVIEW DOCUMENTATION: Although interviews are an extremely important
method of obtaining information, investigating the current system documentation is
also useful. The documentation might nor be up ro dare, so check with users co confirm
that the information is accurate and complete.
OBSERVE OPERATIONS: Another fact-finding method is to observe the current
system in operation. Observe how workers carry out typical tasks. Trace or follow
the actual paths taken by input source documents or output reports. ln addition to
observing operations, consider sampling the inputs or outputs of the system. Using
sampling techniques described in Chapter 4, valuable information about the nature
and frequency of the problem can be obtained.
CONDUCT A USER SURVEY: Interviews can be rime consuming. Sometimes information
from a larger group can be obtained by conducting a user survey. In this
case, design a form that users complete and rerurn for cabularion. A survc}' is nor as
Aexible as a series of interviews, bur ir is
less expensive, generally rakes less time,
and can involve a broad cross-secrion of
Pareto Chart: Inventory System Errors
people.
ANALYZE THE DATA: Systems analysts
use many techniques to locate the source
of a problem. For example, the Pareto
chart is a widely used tool for visualizing
issues that need attention. Named for a
nineteenth century economist, a Pareto
chart is drawn as a vertical bar graph, as
shown in Figure 2-J 8. The bars, which
represent various causes of a problem, are
arranged in descending order, so the team
can focus on the most important causes.
ln the example shown, a systems analyst
mighr use a Pareto chart to learn more
about the causes of inventory system
problems, so that necessary improvements
can be made.
- -- - .....
-
FIGURE l -18 A Pareto chart displays the causes ofa problem. in priority
order. so an analyst can tackle the most lmpon:ant cases first. In this example.
the part number issue would be the obvious starting point.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
66 2. 9 The Preliminary Investigation
The XY chart, somerimes called a scatter diagnim, is anorher problem-solving root.
Often, an :malysr looks for a correlation becween two variables. For example, suppose
complainrs are received about network response time, and rhe cause needs robe
derermined. The analyst would rry to identify variables, such as rhe number of users,
to see whecher there is a correlation, or pan ern. Figure 2-19 shows rwo XY charts
wirh dara samples. The firsr chart sample would suggest thar rhere is no corrclacion
....
. __ .. .• .. .
... ...............
-
--..._
0-. .... _ ...........
~-
-
~
-
II
• p
• .A ' •
·- - - - ·-
•
..
Network Response Time vs. Number of Users
• .. •
I
-
.. .
. .
••
..
• • • •
---
• •
--- • •
- • ••
• p I
n ...... t n...,...1 .,..
. ......_ ... -
Network Response Time vs. Number of Users
..
.....
•-1
..
"
. . .
. .
- - ..
• • •
... r- -~· ..
• •
FIGURE 2- 19 An XY chart shows correlation between variables, which is very important in
problem solving. Conversely, a lack of correlation suggests that the vari:lbles are independent.
and that you should look elsewhere for the cause.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

2.9 The Preliminary Investigation
Phase I
Systems Planning
67
between the delays and the number of users, so the analyst would look elsewhere for
the source of the problem. However, if the data resembles the second XY sample, it
indicates a strong relationship between the number of users and the longer response
rimes. Thar informanon would be extremely valuable in the problem-solving process.
Step 4:Analyze Project Usability, Cost, Be nefit, and Schedule Data
During fact-finding, data is gathered about the project's predicted cosrs, anticipated
benefits, and chedule issues that could affect implementation. Before feasibility can
be evaluated, this data must be analyzed carefuUy. If interviews were conducted or
surveys used, the data should be tabulated to make it easier to understand. If current
operations were observed, the results should be reviewed and key facts that will be
useful in the feasibihry analysis highlighted. If cost and benefit data were gathered,
financial analysis and impact statements can be prepared using spreadsheets and
other decision-support tools.
Also, time and cost estimates should be developed for the requirements modeling
tasks for the next SDLC phase, systems analysis. Specifically, the following should be
considered:
• What information must be obtained, and how will it be gathered and analyzed?
• Who will conduct the interviews? How many people will be interviewed, and
how much time will be needed to meet with the people and i.umnrnrize their
responses?
• \'(fill a survey be conducted? Who will be involved? How much time will it cake
people to complete it? How much rime will it take to tabulate the results?
• How much will it cost to :rnalyze che information and prepare a report with
findings and recommendations?
Step S: Evaluate Feasibility
At chis point, the problem or opportunity has been analyzed, the proiect scope and
consrraincs have been defined, and fact-finding has been performed ro evaluate
project usab1liry, costs, benefits, and time constraints. The next step is to as ess the
project'!> feasibility, beginning with reviewing che answers to the questions listed in
Section 2.7. The following guidelines should also be considered:
OPERATIONAL FEASIBILITY: Fact-finding should have included a review of user
needs, requirements, and expectations. When this data is analyzed, look for areas that
might present problems for system users and how chey might be resolved. Because
operational feasibility means that a system will be used effectively, this is a vital area
of concern.
ECONOMIC FEASIBILITY: Using che fact-findi ng data, financial analysis tools can
be applied to :i~sess feas ihiliry. The cost-benefit dara will be an important factor fo r
management co consider. Also, a cost estimate for the project development ream wi ll
be built into the project management plan.
TECHNICAL FEASIBILITY: The fact-finding data should identify the hardware, software,
and network resources needed co develop, install, and operate the system. \~ith this
data, a checklist can be developed that will highlight technical costs and concerns, if any.
SCHEDULE FEASIBILITY: The fact-finding data should include stakeholder expectations
regarding acceptable timing and completion dares. As mentioned previously,
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 2 Analyzing the Business Case
68 2. 9 The Preliminary Investigation
often a trade-off exisrs berween a project's schedule and its cosrs. For example,
compressing a projecr schedule mighr be possible, but only if the budget is increased
accordingly co add extra personnel. The schedule data will be incorporated into the
pro1cct plan in che form of task durations and milestones.
At rhis stage of the preliminary investigation, there are several alrernarives. It
might be rhat no action is necessary or thar some other srrateg)', such as addirional
training, is needed. To solve a minor problem, a simple solurion might be chosen
wirhour performing further analysis. In other situations, it will be recommended that
rhe project proceed to the next phase, which is systems analysis.
2.9.3 Summarizing the Preliminary Investigation
The fina l cask in the preliminary investigation is to summarize the results and recommendations,
which can be conveying to management in a report and/or in a presentation.
The written report and the oral presentation are examples of the need for
systems analysts to develop strong conu11unicacions skills. The report includes an
evaluation of the systems request, ao estimate of costs and benefits, and a case for
action, which is a summary of che pi:oject request and a specific recommendation.
T he spcci fie format of a preliminary investigation report varies. A typical report
might consist of the fo llowing sections:
• /ntroductio11-tbe fi rst section is an overview of che reporc. The introduction
contains a brief description of the system, the name of the person or group
who performed the investigation, and the name of the person or group who
initiated the investigation.
• Systems Request Summary-the summary describes the basis of the systems
request.
• findings-the findings section contains the results of che preliminar)' investigation,
including a descriptjoa of the project's scope, constraints, and
feasibiliry.
• Recommendations-a summary of the project request and a specific recommendation.
Management will make the final dec1s1on, but the IT department's
input is an important factor.
• Pro1ect Roles-this section lists the people who will participate in the project
and describes each person's role.
• Time and Cost Estimates- this section describes the cost of acquiring and
installing the system, and che coral cost of ownership during the system's useful
life. Intangible costs also should be noted.
• Expected Benefits-this section includes anticipated tangible and intangible
benefits and a timetable that shows when they are to occur.
• Appendix- an appendix is included in the report if supporting information
must be attached. For example, the interviews conducted might be listed, the
documencacion reviewed, and other sources for the information obtained.
Detailed interview reporrs do not need to be included, but those documents
that support the report's findings should be retained for future reference.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
2. 10 Summary
69
As a new systems analyst at Premier Financial Services. you are getting quite an education.
You report to the IT manager, who also chairs the systems review committee. Several
months ago. the committee rejected a request from the finance director for an expensive
new accounts payable system because the benefits did not appear to outweigh the costs.
Yesterday. the IT manager's boss asked the IT manager to reconsider the finance director's
request. and to persuade the other members to approve it. The IT manager wanted
to discuss the merits of the request, but the discussion was cut off rather abruptly. It turns
out the IT manager's boss and the finance director are longtime friends.
The IT manager is now very uncomfortable meeting with her boss. She believes the
directive to reconsider the finance director's request would undermine the integrity of the
systems review process. She feels it would be unethical to grant preferred treatment just
because a friendship is involved. She is thinking of submitting a request to step down as
review committee chair, even though that might harm her career at the company.
Is this an ethical question, or just a matter of office politics? What would you do if you
were the IT manager!
2. I 0 SUMMARY
Systems plann ing is rhe firsr phase of rhe systems development life cycle. Effective
information systems help an organization support irs business processes, carry out its
mission, and serve its stakeholders. During strategic planning, a company examines
its purpose, vision, and values and develops a mission scacement, which leads to goals,
objecttve!>, day-to-day operauons, and business resulcs that affect compan)' stakeholders.
SWOT analysis exammes strengths, weaknesses, opponumries, and threats.
S\XIOT analysis can be u ed at the enterprise level and for mdividual pro1ect~.
During the }'Stems planning phase, an analyse reviews the busines~ case, which is
the basis, or reason, for a proposed system. A business case should de cribe the project
clearly, provide the jusrificarion to proceed, and estimate rhe project's financial
impact.
Sy~tem~ projects are initiaced co improve performance, provide more information,
reduce costs, strengthen controls, or provide bener service. Various internal and external
factors affect syscems projects, such as user requests, top management directives,
existing sy~tems, the IT department, software and hardware vendors, technology, cu~tomers,
competitors, the economy, and government.
During the preliminary investigation, the analyst evaluates the systems request and
determine~ whether the project is feasible from an operational, technical, economic,
and schedule standpoint. Analysts evaluate systems requests on the basis of their
expected costs and benefits, both tangible and intangible.
The steps in the preliminary in vestigation are to understand the problem or opportunity;
define the project scope and constraints; perform fact-finding; analyze project
usability, cost, benefit, and schedule dara; evaluate feasibility; and present results and
recommendations to management. During the preliminary investigation, analysts
often use investigative rools such as fishbone diagrams, Pareto charts, and XY charts.
The last cask in a preliminary invescigarion is to prepare a report to management. The
report must include an estimate of time, staffing requirements, cosrs, benefits, and
expected results for the next phase of the SDLC.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 2 Analyzing the Business Case
70 Key Terms
Key Te rms
biomclric de' kes A mech3ntSm used co uniquely identify a per~n by J rcuna scan or b> mJpping J
fa"al panern.
blod..-h.un A distributed ledger srstem. The technology underl}1ng B11corn.
bu'"''"'' ""'" Refer' to the rca>On>, or ju.cification, for a propo"11.
ca\c: for a•"l1on A part of the prd1m111ary 1n\'e>t1gat1on report to mdna11c:ment that \ummar11e> pro1c.t
rcque\r. and make> ,pcxific recommendation,.
computer resources commim~e A group oi key managers and users responsible for cvaluanng systems
requests. Inc rcrm "systems review commircee ~ is also used.
constraint A requirement or a condirion rhar rhe sysrem must satisf>' or an ourcomc chat 1he system muse
achieve.
critical \Uccc" focwrs Viral objectives that mu>t be achieved for rhe entcrpri>e m fulfill ir' mi,,,ion.
cu,ttuncr rdatiomhip nurna11ement (CRM) l\fany companie; implement 'Y'len1' to mtci;rotc all
cU\lomer·rdarcd event> and tran,action'> including mnrkcrin11, >ale,, and ""l<>mer wrvicc activitics.
discrc1i0Mry projects Where managemenr has a cboice in implementing a pro1ect, rhey arc c;1 1ied d1screrionJry.
l·or example, cre:iring a new reporr for a user is .111 example of .1 discreuonary pro1ccr.
economic fcas1b1lit)' Achieved if the projecred benefits of rhe proposed system ou1we1gh rhc csrirnarcd
cosrs involved in acquiring, installing, and operating ir.
clcccrnnic darn interchange !EDT) The exchange of busine's document\ hctwccn compute" ll'ing a scan·
Jard clcctronk format.
dcuronic produu ~ode (EPCJ Technology char U!>l"> RFID la);) co idcntit) and monicor chc movement of
each 1nd1ndual product, from rhc factory Aoor ro the retail chc~kolll counter.
dcctron1c proof of dcli''l'f} (U'OO) A supplier uses RHD t.igs 011 e.ich cr.ite. case, or shipping unu ro
crearc J d1giral shipping hsr ro verify receipt oi goods.
cncrypuon A process where data is coded (oonverted into unrc.idable char.1cters) so char only those wnh
the required authorization can access the da1a.
fi,hhonc diagram \n analy-;is rool rhar represenrs rhe pos'>ible cau<e<> of a problem a< a graphical nm·
line. ""'.:ailed an bhikawa <liah'l"am.
intang1hlc hencfih Po\1ll•c ouKomcs that a~ difficult to mea~ure 1n dollars. Howc\'cr, intangible hcne·
fib can he very important m che calculation of economic fca>1b1hry. An c'<amplc of an intan111blc hen·
cfir m1ghr he a new wch<ite rhar improve-; a company'' ima11e.
intangible co-.s lrems that are difficulr ro measure in dollar remlS, such a~ employee d1~sa11~focnon.
ln1emc1 of Thing~ (IOT) Devices connected to one anorhcr over a computer nerwork.
j1M m·rimc (]TT) The exchange or dclh·ery of informanon when and where It i< needed. For c-camplc,
just·m·rimc 11wcntory sysrcms rely on compmer-co-compurer darn exchange rn minimize unncccs"3ry
111ven1ory.
111i,)io11 ~1a1c111cnt
1\ documcnr or >ratcmenr rbar <lc;c1·ibes 1hr.: company for Ill• stakeholder; and bricny
' rare' the company's overall purpose, produces, services, and value,.
nond1scrctionary pro1ccts Where managemem has no choice in 1mplemcnt111g a pro1ccr, they ore called
nond1screrionar)'· For example, adding a report required by a new fedcrJI law.
operational fca~ib1lit)'
A •y,rcm char that will be used effecth•cly afrcr i1 has hccn developed.
Parero chart \vertical har graph named for a nineceench century economist. The bar<, which rcpre<cm
'arn>u., cau~e~ of a problem, are arranged in descending order, o;o rhe reJm can focu< on rhc mmr
11nport.1nt cau>e>.
prd1minal"} 10\C\llga11on An mmal :malysIS to clearly 1dennfy the namre and scope of the business
opportumry or problem. Al,o called a feasibilicy study.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase I
Systems Planning
Key Terms
71
pro1cct cr•-ep !"he procco~ b> which projects with ,.et) general scope definirions exp.ind gradual!)." 11h·
out ~pcc1ftc .1u1horua11on.
proi«t \.:ope A ~pc..1fic dctcrmmanon of a pro1en's boundaries or extent.
\c.ttter diagram A tool u\cd hy 'Y'lem anal)\"' co graphicall) show the corrd;mon between two variabl~.
Al'-<> c..1llcd an XY chart.
\cbcdulc fcas1biliry A proiect can be 1mplcmemed in an acceptable rune frame.
str.1t1:111c planomg Inc process o( 1dennfy1ng long-rerm orga nizanonal goals. s1rateg1es, and resource.
'iWOT analy\1' An c~ammarion of a company'• srreni,'ths (S), wcaknc•scs (W ), oppnrruni11c' (0), and
threat• (T).
\}'>tern\ rcquc•t A formal appeal m rhe IT departmem rhar describes problem\ or de\ired chanitc' in an
information •>''lean ur hu\lnes• proces;. Ti mighr propose t.>nham:emenl:!> for an exi;uni; 'Y>tem, the
corrcx:1iun of problem,, 01 the devdvpment vf an entirely new system.
systems renew commiuee A group of key nunagers and users responsible for cvalu.11mg systems
requests. The term computer resources committee is somerimes J!so used.
tangible benefit~ Pomivc outcomes that can be measured in dollars. The)' can resulr from ,1 decrc.1se 1n
expenses. an increase in revenues, or botb.
tangible cmi. f.xpen•cs that haven ~pecific dollar value. Examples include employee o;al.iric• and hard
ware pun .. ha>c,.
U!thnital fca.,ihilil) \Vhcn an ori:ani1:1ri11n ha~ the resources to develop or purcha_,e, 1mtall, and operate
rhc ~JMcm.
101.il co~1 of o" ocrsh1p (TCO) A number used in assessing costs. which tndudes oogomg suppon .ind
numrenJnct costs, .1s well a~ acqu1sinon cosrs.
XY chart A tool used b> S)Stcm analysts 10 graphie<1lly show rhe corrcla1ion between mo \ar1.1hlcs. Also
called J scancr diagram.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 2 Analyzing the Business Case
72 Exercises
Exercises
Questions
1. Why should a S)'Stems analyst be interested in strategic planmng?
2. Lisr the four factors invoked in a S\'V'OT analysis.
3. Describe how CASE rools can support strategic planning.
4. List five que~tions rhe business case should answer.
5. What arc the six main reasons for sysrems requests?
6. Explain the two main factors affecting systems requescs.
7. Describe the role of rhc sy~rems review committee in processing systems requests.
8. Define operational, economic, technical, and schedule feasibility.
9. List seven questions the sysrcms analyst should consider when assessing project priorities.
10. What are rhe five seeps of :i prel iminary investigation?
Discussion Topics
1. One of your coworkers says, "Mission statements are nice, but rhey really don'r change things down
here where rhc work gets done." How would you reply?
2. Discuss how a company's financial status can affect systems projects.
3. The vice prc~idenr of accounting ~ays to you, the IT direcror, "This request procedure takes too long.
My people know what they are doing, and their systems requests are necessary and important." She
~uggcsts char the IT deparrmenr bypass rhe initial seeps and immediately get ro work on her requesrs.
What would you say ro her?
4. When setting prioriries for system requests, the highest priority goes to projects that provide rhe great·
e~t benefit, at the lowest cost, in rhe shortest period of time. How would you reconcile projects thar
can produce good results in che shorr rerm versus projects rbac can produce excellent resulcs in rhe
long term?
5. The final cask 1n rhe preliminar)' invesngation is to summan1e chc r~ults and recommendations in a
report and/or 1n a presenrarion. Which form of communicarion, wrirren or oral, do you chink is rhe
most effci.-ri'e for come)·ing your findings co managemenc?
Projects
1. Use rhe lnrcrncr rn find rluec examples of corporare mission stacemcncs.
2. Prepare a SWOT anal)·sis of your school or your employer.
3. A mind map is a diagram used ro visua lly organize information. ldencify a tool rhat supports the crcacion
of mind maps and explain how they can be a valuable part of srraregic planning.
4. Visit che website for an IT magazine and find an article chac discusses business cases. Summarize rhe
article and what you learned from it.
5. Think of a problem you have experienced ar school or at work and draw a sample fishbone diagram
with at lease two levels.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

Chapter 3
Managing Systems Projects
Managing
Systems Projects
Chapte r 3 is the final chapter in the systems planning
phase of the SDLC. This chapter describes project
management and explains how to plan, schedule,
monitor, and report on IT projects.
The chapter includes three "Case in Point" discussion
q,uestions to help contextualize the concepts described
in the teXt. The "Question or Ethics" considers the
implications of raising awareness of a project going astray
even when the project manager Is reluctant to do so.
LEARNING OBJECTIVES
When you fi11ish this chapter, you shottld be able
to:
1. Wustrate pro1ect priorities in the form of a project
triangle
2. E..xplain project planning, scheduling, monitoring,
and reporting
3. Create a work breakdown srrucrure
4. Identify cask pattern~
5. Calculate a project's crirical parh
6. Describe project monitoring and concrol techniques
Lo keep a project on schedule
7. Explain how project starus is reported
8. Describe project management sofrware and how
it can be of assisrance
9. Create a risk m:magcmcnt plan
10. Describe why projects sometimes fail
CONTENTS
3.1 Overview of Project Nlanagemcnt
3.2 Creating a Work Breakdown Structure
Case in Point 3.J: Sun r 1~e Software
3.3 Task Patterns
Case in Point 3.2: Parallel Sernces
3.4 The Critical Path
3.5 Project Monitoring and Control
3.6 Reporting
3.7 Project ~1anagement Software
3.8 Risk Management
3.9 Managing for Succes~
Case in Point 3.3: Ju ~r-in-lime Software
A Question of Ethics
3.10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
3.1 Overview of Project Management
Phase I
Systems Planning
75
3.1 OvERv1cw OF PROJECT MANAGEMENT
Many professionals manage business and personal projects every day bur do nor
always give it much thought. The management process for developing an information
system or working on a construction project is much the same. The only difference is
the nature of the project. To manage a large-scale IT project, specific tools and techniques
arc needed. A project manager is also needed, someone who is responsible for
overseeing all relevant tasks. Project management for IT professionals includes planning,
scheduling, monitoring and controlling, and reporting on information S)'Stcm
development.
A project manager will break rhe project dow11 into individual tasks, determine the
order in which the tasks need to be performed, and figure out how long each task will
take. \Xlith this informarion, Gantt charts or PERT/CPM charts can be used to schedule
and manage the work. Microsoft Project is a popular project management roof
that can help create and then monitor the project plan, report progress, and u~e risk
management to make rhc whole process easier for everyone.
3. 1.1 W hat Shapes a Project?
A succe~sful project must be completed on time, be within budget, and deliver
a quality product that satisfies users and meets requirements. Project management
techniques can be used throughout the SDLC. Systems developers
can initiate a formal project as early as the preliminary investigation stage, or
later on, as analysis, design, and implementarion acrivities occur.
Systems development projects tend to be dynamic and challenging. There
is always a balance between constraints, which '-\'as discussed in Chapter 2,
and interactive clements such as project cost, scope, and time.
3. 1.2 W hat Is a ProjectTriangle?
Figure 3-1 shows a very simple example of a project triangle. for each
project, it must be decided what is most important, because the work
cannot be good and fast and cheap.
When it comes to project management, things are not quite
so simple. Decisions do nor need to be all-or-nothing but recognize
that any change in one leg of the triangle "rill affect the
other two legs. Figure 3-2 represents a common view of a
project triangle, where the three legs are cost, scope, and time.
The challenge is to find rhe optimal balance among these factors.
Most successful project managers rely on personal experience,
communication ability, and resourcefulness. For example,
if an exrremely time-critical project starts to slip, the project
man~1gcr might have to rrim some features, seek approval for
a budget increase, add new personnel, or a combination of all
three actions.
On its website, Microsoft offers an interesting suggestion for
project managers who h:ive a project at risk: Find the "stuck
side" of the triangle. Microsoft states that in most projects, at
least one side of the triangle is fixed and unlikely co change.
It might be a budget cast in stone, a scope that is inflexible,
or a schedule driven by factors beyond the firm's control.
PICK ANY TWO
FIGURE l· I You can't get
everything you want; you have to
make chokes.
Time
FIGURE l·l A typical project triangle includes
coSt. scope. and time.

Chapter 3
Managing Systems Projects
76 3.2 Creating a Work Breakdown Structure
\~hi chever side is fixed is probably crirical co rhe projecr's success. The leg where the
problem re ides must also be identified: cost, scope, or rime.
3. 1.3 What Does a Project Manager Do?
\~hether a pro1ect involves a new office building or an informauon system, good
leadership is essential. In a sysrems project, rhe project manager, or project leader,
usually 1s a senior sy rems analyst or an IT department manager 1f the project 1s large.
An analyst or a programmer/analyst might manage smaller projects. In addition
to the project manager, mo t large projects have a project coordinator. A project
coordinator handles administrative responsibilities for the ream and negotiates with
users who might have conflicting requirements or want changes that would require
additional time or expense.
Project managers typically perforn1 four activities or functions: planning, scheduling,
monitoring, and reporti11g:
• Project planning includes identifying all project rasks and esrimaring rhe completion
rime and cost of each.
• Project scheduling involves the creation of a specific timetable, usually in the
form of charrs that show tasks, task dependencies, and critical casks thar might
delay the project. Scheduling also involves selecting and staffing rhe project
rea m and assigning specific tasks co ream members. Project scheduling uses
Gantt charts and PERT/CPNl charts, which are explained in rhe following
sections.
• Project moniroring requires guiding, supervising, and coordmaring the project
team's workload. The project manager must monitor the progress, evaluate the
results, and rake corrective action when necessary to control the project and
stay on target.
• Project rcponing includes regular progress reports to management, users, and
the project team itself. Effective reporting requires srrong communication skills
and a sense of what others want and need to know about the pro1ect.
The following sections describe the project planning and scheduling steps: how ro
create a work breakdown structure, identify task patterns, and calculate the project's
critical parh.
3.2 CREATING A WORK BREAKDOWN STRUCTURE
A work breakdown structure (WBS) involves breaking a project down into a series
of smaller tasks. Before creating WBSs, the two primary chart types should be understood:
Gantt charts and PERT/CPM charts.
3.2.1 Gantt Charts
I lenry L. Gantt, a mechanical engineer and management consultant, developed Gantt
charts almost I 00 years ago. His goal was to design a chart that could show planned
and actual progress on a project. A Gann chart is a horizontal bar chart chat represents
a sec of tasks. For example, the Gantt chart in Figure 3-3 displays five casks
in a vertical array, with time shown on the horizontal axis. The position of the bar
shows the planned starting and ending time of each task, and the length of rhe bar
indicates it~ duration. On the horizontal axis, time can be shown as elapsed rime
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
3.2 Creating a Work Breakdown Structure
77
from a fixed starting point or as actual calendar dates. A Gantt chart also can simplify
a complex project by combining several acriviries into a wsk group that contains
subsidiary tasks. This allows a complex project to be viewed as a set of integrated
modules.
. .., - --·- ·- --
.. - ..... ·- - - .... -
. -
-----~'"'
c-•-- ... -­
... - --
--
~ i.ao-.... ::. m........... --..
--=-~ "'-;-'
·- -
.._ --- - --
.·­
-·
.' .....
-·
--· --· - --· --·
.
-.
- ,_..,. . .._....,....._ • •
FIGURE 3-3 In this Gantc chart. note the yellow bars that show the percentage of task completion.
A Gantt chart can show task starus by adding a contrasting color to the horizontal
bars. For example, a vertical red arrow marks the current date in Figure 3-3. With a
fixed reference point, it is easy to see that Task I is way behind schedule; Task 2 is
only about 80% done and is running behind schedule; Task 3 should have started,
bur no work has been done; Task 4 actually is running ahead of schedule; and Task )
will begin in several weeks.
Gantt charts can present an overview of the project's status, but they do not provide
enough detailed information, which is necessary when managing a complex project.
Some project managers ma> find char PERT/CPM charts, which are discussed in
che followmg section, are better cools for managing large projects.
3.2.2 PERT/CPM Charts
The Program Evaluation Re' iew Techniq ue (PERT) was developed by the U.S.
Navy ro manage very complex project , such as rhe construction of nuclear
submarines. Ar appro'<imately the same time, the C ritical Path Method (C PM)
was developed by private industry to meet simLlar project management needs. The
distinction between the two methods has disappeared over time, and today the
technique is called either PERT, CPM, or PERT/CPM. This text will u~e the term
PERT chart.
PERT is a bou om-up ccchnique because it analyzes a large, complex projecr as a
series of individual tasks, just as a pyramid is builr from the borcom up using individual
blocks. To create a PERT charr, first identify all the project cask~ and esrimatc
how much time each cask will rake to perform. Next, determine the logical order in
wh.icb the tasks must be performed. For example, some tasks cannot start Lmtil other
casks bave been completed. In other siruations, several tasks can be performed at the
same rime.
Once the tasks arc known, their durations, and the order in which they must be
performed, calculate the time that it will take to complete the project. The specific
casks that will be critical to the project's on-time completion can also be identified.
An example of a PERT chart, which ~1icrosoft calls a network diagran1, is shown in
che lower screen in Figure 3-4.

Chapter 3
Managing Systems Projects
78 3.2 Creating a Work Breakdown Structure
I
w ~--- - ---
.... ... -
- - L.:
.. ... ·-· - - ... - ~- ... ·---- . .
- .
... -
... - - --
-- = --
---
_ ,c......_ ----
• ....c............. i . ....__...___
I ..,,..._.............,..
-·-----~
- - a
~ .,. . (_...._........... = .
,.. ... -. ._. ,.._ ..._ ..._ ·- ...... .
1
• '-+ •
'""' S kNI out lntorvlow t<hedulo
Stut Tuo 9/3/19 10 5
fon11h Tue t/S/19 Dut I d• v
Ars
FIGURE 3-4 The top screen shows a Gantt chart with six tasks.The PERT
chart in the bottom screen dlsplnys an easy-to-follow task pattern for the same
project. When the user mouses over the summary box for Task 5, the derails
become visible.
- ......
Although a Gantt charr offers a
valuable snapshor view of the projecr,
PERT charts are more useful for
scheduling, moniroring, and controlling
the actual work. \'(.lith a PFRT chart,
a project manager can converr task
start and fini sh rimes to acrual dates
by laying our the entire pro1ect on a
calendar. Then, on any given day, the
manager can compare what should be
happening wirh what is raking place
and react accordingly. Also, a PERT
chart displays complex task patterns
and relationships. This in formarion is
valuable to a manager who is trying ro
address high priority issues. PERT and
Gaorr charts are not mutually exclusive
recltniques, and project managers often
use both methods.
FigLtre 3-4 shows both chart types.
T he top screen is a Gantt chart with six
tasks. The PERT chart below it shows
rhe same project, using a separate box
for each rask instead of a horizontal
bar. Alrhough rhey borh show rhc rask pancrns and flow, rhc PERT chart boxes
can provide more information, such as task duration, start dare, finish date, and the
names of resources assigned co cbe cask. The PERT chart in Figure 3-4 would be too
small ro view the acrual derails, which are shown in the expanded rexr box ac che bottom
of che figure. How co create PERT charts is explained in a later section.
3.2.l Identifying Tasks in a Work Breakdown Structure
A WB musr clearly identify each task and include an estimated duration. A task,
or an acrivity, is an y work char has a beginning and an end and requires che use of
company resources such as people, time, or money. Examples of casks include conducting
interviews, designing a report, selecting software, waiting for the delivery
of eq uipment, or training users. Tasks are basic units of work that the project
manager plans, schedules, and monitors-so they should be relatively small and
manageable.
In addition ro rasks, every project has events, or mile~tones. An event, or a milestone,
is a recognizable reference point that can be used to monitor progress. For
example, an event might be the start of user training, the conversion of system data,
or the completion of interviews. A m.ilestone such as "complete 50% of program testing"
would not be useful information unless it could be determined exactly when that
even c wi II occur.
Figure 3-5 shows casks and events chat might be involved in che creation, distribution,
and tabulation of a questionnaire. Note that the beginning ::tnd end of
e::1ch cask are marked by a recognizable eveor. It would be virtually impossible
to manage a projecr as one large cask. Instead, the project is broken down into
smaller tasks, creating a WBS. The first step in creating a \'(.!BS is to list all che
tasks.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
3.2 Creating a Work Breakdown Structure
79
Start work oo
ques110no8"•
All
Prepare
quesbonnaire
Awart return of
questioma&res
Tabulate
questionnaJre
responses
Prepare repon
00
quesbOMalre
resuhs
e
Evoot or Milestone
.. Task
FIGURE l -S Using a questionnaire requires a series of ta.sks and eventS to crack the progress.The 1ilustration
shows the relationship between the tasks and the eventS, or milestones, which mark the beginning and end of
each task.
LISTING THE TASKS: While this step sounds simple, it can be c hallenging because
the rasks might be embedded in a document, such as d1e one shown in the first
version of Figure 3-6. One crick is ro srarr by highlighting the
individual casks, as !>hown in the second version. Adding bullets
makes the tal>k~ stand our more clearly, as shown in the rbird
version. The next step is to number rhe casks and create a cable,
similar to the one shown in Figure 3-7, with columns for cask
number, description, duration, and predecessor casks, which
muse be compleced before anocher rask can scan.
ESTIMATING TASK DURATION: Task duration can be hours,
days, or wceks--dependmg on the project. Because che following
example uses days, the units of measurement arc called person-days.
A pcrson-da) represents the work char one person can complete in
one day. This approach, howe\re~ can present some problems. For
example, if it will cake one person 20 days to perform a particular
cask, it might not be true that two people couJd complete chc same
task in 10 days or that I 0 people could perform tbe task in two
days. Some tasks can be divided evenly so it is possible to use different
combinations of time and people--up to a point-bur not
all. in most sysrems analysis rasks, rime and people are not inter·
changeable. If one analyst needs two hours to interview a user, two
analysrs also will need two hours co do the same interview.
Project managers often use a weighted formula for estimating
the durarion of each cask. T he project manager fixst ma kes three
time esrimatcl> for each cask: an optimisric, or best-case e~ timatc
(B), a probablc-ca\c e~ timate (P), and a pessimisric, or wo rse-case
e~ timatc (W). T he manager rhen assigns a weight, which is an
importance value, to each estimate. The weight can vary, bur a
common approach i'i to use a ratio of B = 1, P = 4, and W = J.
Tbe expected task duration is calculated as follows:
First, reserve the meeting room Then order
the marketing materials and brief the
managers After the bne~ngs. send out
customer emails and upload program to the
app store When lhe emails are sent and lhe
program is available on the app store ready,
load the new software. When the mar!(ebng
materiats have emved and the software is ready,
do a dress rehearsal.
Firs1. rr; ve t mr o.... Then orcJer
t> ,.,. '"'9,.., and b · I the
manat "' After lhe bnefings, nd out
cus:onn r m s and ''' IOad progrNn to It>"
app store. When the emails are soot and the
program is available on the a.pp store ready,
ioad tt>e ne,. ul!wa,,. When the marketing
erials have amved and the software 1s ready.
a dr'"' rthearsal.
-----
• First, reserve tho mooting room.
• Then order rhe mar~ellflg materi&/$ and brief
the manage1S.
• Aller the briefings, sand out customer omalls
and upload program to the app store.
• When the emails are sent and the program is
available on the opp store ready, load !he
now solrware.
• When the mart<ehng materials have arrived
and the software Is ready, do a dre~s rohearsal.
(B+4P+W)
6
FIGURE l-6 The three versions show how to
transform a wk scatement into a list of specific
casks for a work breakdown strucwre.

Chapter 3
Managing Systems Projects
80 3.2 Creating a Work Breakdown Structure
•
2
3
4
Description
Reserve the meeting room
O rder the marketing materials
Brief the managers
Send out customer emails
Duration
(Days)
Predecessor
Tasks
5 Upload program to the app store ......._____.._____.....
6 Load the new software
7 Do a dress rehearsal
FIGURE 3-7 In this table, columns hM! been addl!d for wk number,descripuon.
duration. and predecessor casks, which mun be completed before another task can start.
For example, a projecr manager mighr estimare rhar a file-conversion task could be
completed in as few as 20 days or could take as many as 34 days, bur most likely will
require 24 days. Using the formula, the expected task durarion is 25 days, calculated
as follows:
(20 + (4 *24) +34) = 25
6
A lively discussion is under way at Sunrise Software, where you are a project manager.
The main question is whether the person-days concept has limitations. In other words.
if a task will require I 00 person-days. does it matter whether two people in SO days,
five people in 20 days, ten people in I 0 days, or some other combination that adds up
to I 00 performs the work?
Two programmers on the project seem to think it doesn't matter. O n the other hand,
one of the project's systems analysts says it is ridiculous to think that any combination
would work.To support his point, this extreme example was offered: Could 100 people
accomplish a task estimated at 100 person-days in one day?
Is the systems analyst correct? If so. what are the limits in the "people versus days"
equation? Taking the concept a step further. is there an optimum number of people to be
assigned to a task! If so, how would that number be determined? You need to offer some
guidance at the next project team meeting.What will you say!
3.2.4 Factors Affecting Duration
When developing duration estimates, project managers consider fou r factors:
I . Project size
2. 1 luman resources
3. Experience with similar projects
4. Constraints
PROJECT SIZE: As described in Chapter 1, infom1acion systems have various charactcriscics
char affect their complex:iry and cost. ln addition to considering chose factors, a project
manager must estimate rhc time required to complete each proje<.1: phase.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __....................... ~~·~---- ···---~~ - .,.-"~...........--......
Phase I
Systems Planning
3.2 Creating a Work Breakdown Structure
81
To develop accurate esrimaces, a project manager must identify all project tasks, from
initial fact-finding to system implementation. Regardless of the systems development
methodology used, the project manager must determine how much time will be needed
to perform each task. In de,·eloping an estimate, che project manager must allow rime
for meetings, project re\'iews, craining, and any ocher factors (e.g., scheduled vacations or
unscheduled medical leave) that could affect che productivity of the development team.
HUMAN RESOURCES: Companies muse invest heavily in cutting-edge technology to
remain competici\'e in a connected world. ln many areas, skilled IT profes ionals arc
in greac demand, and firms must work hard to attract and retain the talent they need.
A project manager must assemble and guide a development team that has the skill and
experience to handle the project. lf necessary, additional systems analysts or programmers
111ust be hired or crained, and this must be accomplished within a specific time frame.
After a project gets under way, rhe project manager muse deal with curnover, job vacancies,
and escalating salaries in rhe redu1ology sector-all of which can aHect whether che
project can be completed on time and within budget. The project manager also has to
accommodate official holidays, family emergencies, and other events that may affect the
schedule.
EXPERIENCE WITH SIMILAR PROJECTS: A project manager can develop rime and
cost estimates based on the resources used for si1nilar, previously developed information
systems. The experience merhod works besc for small- or medium-sized projeccs
where the two systems are similar in size, basic content, and operating environment.
In large systems with more variables, the estimates are less reliable.
CONSTRAINTS: Chapter 2 explained chat constraints are defined during the preliminary
investigation. A constraint is a condition, restriction, or requirement chat the system
must sarisfy. For example, a constraint might involve maximums for one or more
resources, such as time, dollars, or people. A project manager must define system requirements
that can be achieved realistically within the required constraints. In the absence of
constraints, the project manager simply calculates the resources needed. 1 lowever, if constraints
arc presenr, the project manager must adjust other resources or change the scope
of the project. TI1is approach is similar to the what-if analysis described in Chapter 12.
3.2.S Displaying the Work Breakdown Structure
After the task durations are entered, the \X'BS will look like Figure 3-8. Task
groups can be used to manage a complex project with many tasks, just as with a
2
3
" s
6
7
Description
Reserve the meeting room
Order the marketing materials
Brief the managers
Send out customer emails
Upload program to the app store
Load the new software
Do a dress rehearsal
Duration
(Days)
9
2
3
3
2
Predecessor
Tasks
FIGURE 3·8 Task duraoons have been added, and the WBS is complete except for
predecessor ask information. The predecessor tasks will determine task ~tterns and
sequence or performance.

Chapter 3
Managing Systems Projects
82 3.3 Task Patterns
Gantt chart, to simplify the list. Nore rhat the WBS shown in Figure 3-8 is still
incomplete: It does nor show fields such as Starr Date, End Dare, Task ame,
Duration, and Predecessors-fields thar can be ke)' for project managers. \Vith
~1icrosoft Project, the \VBS (i ncluding some of these missing fields) might resemble
Figure 3-9.
-
.... . ·--- ·-·- .
.. --·. ·- ·- - - . . .._____ ..
.... ---·- -......-... ..
"'\
.. e .. • - ...........
.,_
--
,_ _
·-
~ • · ~.I - • o • ....,_ :=,.::.. :J.....
... ..................... --:::~....
...,_ .... ....
-
.
ct:= "-:- #,_,.,'- I I t
_ ....._____
I
-
,,_
_
- - -
..
; - .....
·-
·-
................... ..... •
............... ·- ...
............... .... ...
-
::--- ::. B , ::
.....
...... .......,........, • •
FIGURE 3-9 This Microsoft Project screen displays the same WBS, including task number. task name, duration.
and predecessor tasks.
.
3.3 TASK PATTERNS
Tasks in a WBS must be arranged in a logical sequence called a ta\k pattern. In
any project, large or small, casks depend on each other and must be performed in a
sequence, not unlike the commands in a software program. Task patterns can involve
dependent rasks, multiple successor tasks, and mulciplc predecessor rasks. In larger
projecrs, these patterns can be very complex, and an analyst must study the logical
flow carefully. This section explains how to understand and create graphical models
of these patterns.
3.3. 1 Using Task Boxes to Create a Model
In a PERT/CPM chart, project tasks are shown as rectangular boxes, arranged in the
sequence m which they must be performed. Each rectangular box, called a w k box, has
five sections, as shown in Figure 3-J 0. Each section of the task box contains important
infon11ation about the task, including the Task Name, Task ID, Task Duration, Start Day/
Date, and Finish Day/Date.
TASK BOX FORMAT
Start Day/Date
Task Name
Task ID
Finish Day/Date Task DuratlOO
FIGURE 3-10 Each section of the task
box concains important Information
about the cask. including the Task Name.
Task ID. Task Duration. Start Day/Date.
and Fmish Day/Date.
TASK NAME: The task name should be brief and descriptive, bur it
docs not have to be uJlique in the project. For example, a cask named
Conducr Interviews might occur in several phases of the project.
TASK ID: The task ID can be a number or code that provides unique
id en ti ficati<>n.
TASK DURATION: The duration is the amount of time it will rake to
complete a task, which is not necessarily the same as rhe elapsed rime.
For example, a cask that takes eight botirs of effort to complete would
be done in one day by a person dedicated lOO o/o, but if the person
assigned this task is only working 50% on this project, the task would
take rwo days elapsed time to complete. All tasks must use the same
time units, which can be hours, days, weeks, or months, depending on
the project. An actual project scans on a specific date bur can also be
measured from a point in rime, such as Day J.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.3 Task Patterns
83
START DAY/DATE: The stan day/date is the time that a rask is scheduled to begin. For
example, suppose that a simple project has cwo tasks: Task 1 and Task 2. Also suppose
that Task 2 cannot begin until Task 1 is finished. An analogy might be that a program
cannot run until che compurer is turned on. If Task 1 begins on Day 1 and has duration of
three days, it will finish on Day 3. Because Task 2 cannot begin until Task I is completed,
the start rime for Ta~k 2 is Day 4, which is the day after Task 1 is finished.
FINISH DAY/DATE: The finish day/date is the time that a task is scheduled for completion.
To calculate the finish day or date, add tbe duration to the start day or date.
\Vhen doing this, be very careful not to add too many days. For example, if a task
starts on Day I 0 and has duration of five days, then the finish date would be on Day
14-not Day 15.
3.3.2 Task Pattern Types
A project is based on a pattern of casks. In a large project, the
overall parrern would be quire complex, bur it can be broken
down inco three basic rypes of parrerns: dependent casks,
multiple i.uccessor rasks, and multiple predecessor tasks.
DEPENDENT TASKS: When casks must be completed one
after another, like the relay race shown in Figure 3-11, they are
called dependent task~ because one depends on the other. For
example, Figure 3-12 shows that Task 2 depends on Task 1,
because Task 2 can nor start unril Task 1 is completed. In this
example, the finish time of Task 1, Day 5, controls
the start dare of Task 2, which is Day 6.
FIGURE l - 11 In a relay race. each runner is
dependent on the preceding runner and cannot start
until me earlier finishes.
Y- F n
E XA~I PLE OF A DEPENDE NT TASK
MULTIPLE SUCCESSOR TASKS: \Xlhen Se\•eral
tasks can start at the same time, each 1s cilled a
concurrent ta~!.. . Often, rwo or more concurrent
tasks depend on a single prior task, which is called
a predeces~or cask. In this situation, each concurrent
task is called a ~ucc~sor task. In the example
shown in Figure 3-13, ~ucces or Tasks 2 and 3 both
can begin as soon as Task I is finished. ore that
the finish time for Task l determines the start time
for both Tasks 2 and 3. In other words, the earliest
that Task l can finish is Day 30, so Day 31 is the
earliest that Tasks 2 and 3 can start.
Prepare Oull"'8
CtNlllOocumenl
.
Start Day 1 ID 1
. Start Day6 ID. 2
Finish. Day S Dur S An1sh Day 14 Dur 9
FIGURE l-12 This example of a dependent iask shows that the fontsh
cme ofTask I. Day s. controls me start date of Task 2. which tS Day 6.
EXAMPLE O F MULTIPLE SUCCESSOR TASKS
Arrange Interviews
MULTIPLE PREDECESSOR TASKS: Suppose
that a task requires two or more prior tasks to
be completed before it can start. Figure 3-14
shows that example because Task 3 cannot begin
until Tasks 1 and 2 arc both completed. Since
the rwo tasks might not finish at the same time,
the longest (larcsr) predecessor rask becomes the
controlling factor. Note char rhe srarr for Task 3
is Day 16, nor Day 6. \'V'hy is chis so? Because
Task 3 depends on two predecessor tasks, Tasks 1
and 2, Task 3 cannot begin until the later of those
_
.........""_......-................. ..__
Develop Plan ,J4
Slart Day 1 ID: 1
Finish: Day 30 Dur 30
S1ar1: Day 31 ID: 2
Finish· Day 60
Dur30
~
Design Survey
Start Day 31 ID 3
Finish Dey 40 Dur 10
FIGURE 3- 1 l This example of multiple successor wlc.s shows that me
finish ame for Task I detennines the Start ome lo<' both Tasks 2 and 3.
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~----···---~~ - .,.-"~ ........... --......

Chapter 3
Managing Systems Projects
84 3.3 Task Patterns
EXAMPLE OF MJLTIPLE PREDECESSOFl TASi<S
aic.ri Authonullon
Start Day 1 10 1
Fi111Sh; Day 15
°"' 15
Cnlale Job Oeecripl!On
Slllrt Day 1 10 2
Aoish Oay5
0urs
[\
~
Conduct 1i .........
Start Day 16 ID 3
Anlsh: Day 45 Our30
FIGURE 3· 14 This example of multiple predecessor tasks shows
that the start umc for a successor cask must be the latest (largest)
finish dme for any of lcs preceding tasks. In the example shown, Task I
ends on Day IS. while Task 2 ends on Day S, so Task I controls the
start time for Task 3.
tasks is complete. Therefore, the start time for a
successor rask must be the latest {largest} finish
time for any of its preceding rasks. In the example
shown, Task I ends on Da)' 15, while Task 2 ends
on Day 5, so Task 1 contro l ~ the srarr time for
Task 3.
Task pattern type~ are idenufied by looking carefully
at the wording of the task sratemcnt. Words
like then, when, or and are action words that
signal a sequence of events. Here are three simple
examples:
• Do Task 1, then do Task 2 describes dependent
tasks char must be completed one after rhe
ocher.
• When Task 2 is finished, start rwo tasks: Task
3 and Task 4 describe multiple successor tasks
that can both start as soon as Task 2 is finished.
• W/Jen Tasks 5 and 6 are done, starr Task 7 indicates that Task 7 is a multiple
predecessor task bec3use ir ca11't srarr until rwo or more previous tasks all are
completed.
3.3.3 Working with Complex Task Patterns
When several task patterns combine, rhe facts must be studied very carcfullr rounderstand
the logic and sequeDce. A project schedule will nor he accurate if the underlying
rask pattern is incorrect. For example, consider the following three foct statements
and the rask patterns they represent. Examples of the task patterns are shown in
Figures 3-15, 3-16, and 3-17.
1 I ·I 2
1 2
4
FIGURE 3-1 S Dependent tasks.
FIGURE 3 - 16 Dependent tasks and multlple successor tasks.
1 2
FIGURE 3 - 17 Dependent tasks, muldple successor wks. and multiple
predecessor tasks.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.4 The Critical Path
85
DEPENDENT TASKS: Perform Task 1. \Vhen Task 1 is complete, perform Task 2.
DEPENDENT TASKS AND MULTIPLE SUCCESSOR TASKS: Perform Task I. \Xlhen
Task I is complete, perform Task 2. \Xlhen Task 2 is finished, start rwo tasks: Task 3
and Task 4. \Vhen Task 3 1s complete, start two more tasks: Task 5 and Task 6.
DEPENDENT TASKS, MULTIPLE SUCCESSORTASKS,AND MULTIPLE
PRED ECESSO R TASKS: Perform Task 1. When Task 1 is complete, perform Task 2.
When Task 2 is finished, start cwo Tasks: Task 3 and Task 4. When Task 3 is complete,
srart rwo more rasks: Task 5 and Task 6. When Tasks 5 and 6 arc done, srarr
Task 7. Then, when Tasks 4 and 7 arc finished, perform Task 8.
The project management team at Parallel Services is having a debate about how to define casks
In the WBS.The project manager wants to break wks down into the smallest possible units. For
example, she objected to a broad task statement called "Develop a training schedule.'' Instead,
she suggested three subwks: (I) "Determine availability of training room," (2) "Determine availability
of attendees," and (3) "Select specific dates and training times.''
Another project team member disagrees. He feels that the broader task statement
is better because It allows more flexibility and will produce the same result. He says
that if you break tasks Into pieces that are too small, you risk overmanaglng the work
and spending more time on monitoring than actually performing the tasks.As a member
of the team, which approach do you agree with more? What are the pros and cons
of each?
3.4 T!-iE CRITICAL PATH
Task patterns determine rhe order in which rhe casks are performed. Once rhe rask
sequence has been defined, a project manager can schedule the rasks and calculate rhe
critical path. A critical path is a series of tasks chat, if delayed, would affect the completion
dare of the overall projecr. If any cask on rhe critical path faUs behind schedule,
the entire projecr will be delayed.
For example, suppose that Joan and Jim are invited to someone's home for dinner.
Joan arrives on time, bur Jim arrives 30 minures !are. Jim's arrival is part of the
critical path because the host does not wane to start without him, so the meal will be
served 30 minutes later than originally planned.
Project managers always muse be aware of che critical parh, so they can respond
qu ickly co keep the project on track. Microsoft Project and other project management
software can highlight the series of tasks that forn1 the critical path.
3.4. 1 Calculating the Critical Path
Figure 3- J 8 shows a rraining project with five tasks. Note that the analyst has
arranged the tasks and entered rask names, IDs, and durations. The task patterns
should be reviewed firsr. In this example, Task 1 js followed by Task 2, which is a
dependent task. Task 2 has nvo successor tasks: Task 3 and Task 4. Tasks 3 and 4 are
predecessor tasks for Task 5.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 3
Managing Systems Projects
86 3.4 The Critical Path
Plan Training
Obtain Authorization
Hire Analysl
ID: 3
)"
Dur : 5
~
Announce Training
ID· 1 ~ ID: 2 tD· 5
Dur: 10 Dur: 30 Arrange Logistics Dur: 30
\. ID: 4 V'
Dur: 25
FIGURE 3-18 Example of a PERT/CPM chart with five tasks.Task 2 is a dependent task that has multiple successor tasks.Task S has
multiple predecessor tasks. In this figure, the analyst has arranged the casks and entered task names, IDs. and durations.
The next step is ro derermine srart and finish dates, which will determine the crirical
path for rhe project. The following explanation outlines a step-by-srep process.
The result is shown in Figure 3-19.
• Task I starts on Day 1 and has duration of 10 days, so the finish date is Day 10.
• Task 2, which is dependent 011Task1, can start 011 Day 11-the day afcer Ta~k
I ends. Wirh duration of 30 days, Task 2 will end on Day 40.
• Tasks 3 and 4 are multiple successor tasks that can start after Task 2 is done.
Task 2 ends on Day 40, so Tasks 3 and 4 both can stare on Day 41. Task 3 has
duration of five days and wiU end 011 Day 45. Task 4 has duration of 25 days
and will nor end until Day 65.
• Task 5 depends on Tasks 3 and 4, which are multiple predecessors. Because
Task 5 depends on both tasks, it cannot srart until the later of the two tasks is
complete. In this example, Task 3 ends earlier, but Task 4 will not be completed
until Day 65, so Task 5 cannot srarr until Day 66.
Plan Training
Obtain Authorization
Hire Analyst
)" Start: Day 41 ID: 3 ~
Finish: Day 45
Dur: 5
Announce Training
Start: Day 1 ID. 1
_.
Start. Day 11 ID:2 Start Day 66 ID: 5
Finish: Day 1 O Dur: 10 Finish: Day 40 Our: 30 Arrange Logistics Finish: Day 95 Dur: 30
\. Start: Day 41 ID: 4 V'
CRITICAL PATH:1·2·4·5 Finish: Day 65 Dur: 25
FIGURE 3-19 Now the analyst has entered the start and finish times, using the rules explained in this section. Note that the overall
project has duration of 95 days.
Recall char the critical path is a series of tasks chat, if delayed, would affccr rhc final
complcrion dace of rhe overall project. In this exan1plc, Tasks 1 and 2 arc the first casks
on rhc crirical path. Now look ar Task 5, which cannot start until borh Tasks 3 and 4
arc done. In chis case, Task 4 is the controlling factor because Task 4 finishes on Day 65,
which is 20 days larer than Task 3, which is completed on Day 45. Therefore, rhe start
dare for Task 5 is determined by the finish date for Task 4.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
3.6 Reporting
87
In contrast, Task 3 has slack rime and could be delayed up to 20 days wirhour
affecting Task 5. Slack rime is the amount of rime rhar the rask could be late without
pushing back the completion dare of the entire project. Tasks 1, 2, 4, and 5 repre ent
the critical path, which i highlighted with red arrows in Figure 3-19.
3.5 PROJECT MONITORING A~D CONTROL
Regardless of whether the project was planned and scheduled wirh projccr management
software or in some other manner, the project manager mUSt keep track of rhe casks and
progress of ream members, compare acrual progress with the project plan, verify the completion
of project milestones, and set standards and ensure thar they are followed.
3.S. I Monitoring and Control Techniques
To help en!.ure rhar qualiry standards are met, many project managers institute
structured walk-th roughs. A structured walk-through is a review of a project team
member's work hy orher members of rhe ream. Generally, systems analysts review the
work of other sybtems analysts, and programn1ers review the work of other programmers,
as a form of peer review. Structured walk-throughs take place throughout the
SDLC and are called de!.ign reviews, code reviews, or testing review!., depending on
the phase in which they occur.
3.S.2 Maintaining a Schedule
Mainraimng a project schedule can be challenging, and most projccrs run into at least
some problems or delays. By monitoring and controlling the work, the project manager
tries to anticipate problems, avoid them or minimize their impact, identify potential
solutions, and select the best way to solve the problem.
The better the original plan, the easier it will be to control the project. If clear,
verifiable milcsrones exist, ir will be simple ro determine if and when rhosc rargcts
arc achieved. If enough milestones and frcquenr checkpoints exist, problems will be
dcrccted rapidly. A project chat is planned and scheduled wirb PERT/CPM or in a
\'(18$ with Gantt charr can be tracked and controlled using these same techniques. As
work continues, the project manager revises che plan ro record acrual times for completed
casks and revises rimes for tasks that are nor ycr finished.
3.S.3 Tasks and the Critical Path
Project managers spend mosr of rheir time cracking rhc tasks along rhe critical path
because delays in rhose rasks have rhe greatest porenrial to delay or jeopardize the project.
Orhcr tasks cannot be ignored, however. For example, suppose that a rask nor on the critical
path rakes roo long and dcpleres the allotted slack time. Ar that point, the rask acruall)•
becomes part of rhe crirical path, and any further delay will push back the overall project.
3.6 REPORTING
Members of the project team regularly report their progress ro che project manager,
who in rurn reports ro management and users. The project manager collcccs, verifies,
organizes, and evaluates the information he or she receh·es from the ream. Then the
manager decides which information needs to be passed along, prepares a summary

Chapter 3
Managing Systems Projects
88 3.6 Reporting
that can be undersrood easily, adds comments and explanations if needed, and submits
it to management and users.
3.6.1 Project Status Meetings
Project manager , like the one shown in Figure 3-20, schedule regular meermgs to
update the ream and discuss project status, issues, problems, and opportunitie .
Although meeting can be time consuming, most pro1ect managers believe they are
worth the effort. The sessions give team members an opportunity to share information,
discuss common problems, and explain new techniques. The meetings also
give the project manager an opportunity to seek input and conduct brainstorming
sessions.
FIGURE 3·20 Project managers schedule regular meetings to update the project team and discuss
project staws. Issues. problems. and opportunities.
t ~....
llf~
3.6.2 Project Status Reports
A project manager must report regularly co hjs or her immediate supervisor, upper
management, and users. Although a progress report might be given verha lly co an
immediate supervisor, reports to management and users ui.ually are written. Ganrr
chartS often are included in progress reports to show project status graphica ll y.
3.6.3 Dealing with Problems
Deciding how to handle porenrial problems can be difficult. At what point should
management be informed about the possibility of cost overruns, schedule delays, or
technical problems? At one extreme is the overly cautious project manager who alerts
management to every potential snag and slight delay. The danger here is that the manager
loses credibility over a period of time, and management might ignore potentially
serious situations. At the other extreme is the project manager who tries to handle all
situations single-handedly and does not alert management until a problem is serious.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.7 Project Management Software
89
By the rime management learns of the problem, linle time might remain in which to
react or devise a solution.
A project manager's best course of action lies somewhere berwcen the rwo extremes
but is probably closer co the first. If the con.sequences are unclear, the analy t hould err
on the ide of caution and warn management about the possibility of a problem.
\Xlhen the s1ruarion 1 reported, explain what is being done to handle and monitor
the problem. If the siruarion is beyond the analyst's control, suggest possible acnons that
management can rake to resolve the siruarion. Most managers recognii.e that problems do
occur on mo t project ; 1t is berrer to alen management sooner rather than later.
J. 7 PROIECT MANAGEMENT SOFTWARE
Project managers use sofrware applications to help plan, schedule, monitor, and
report on a project. Most programs offer features such as PERT/CPM, Gann charts,
resource scheduling, project calendars, and cost tracking. As shown in Figure 3-2 1,
M icrosoft Project is a full -featured program that holds the dominant share of the
market. Ir is available as a software product for W indows and as an add-on on line
service -as parr of i\llicrosoft's Office 365.
- -·- - --
,___
°"' ......,
....
Project
Project management
....... .__
M~l'nlfe<thelperou,etnanod ......, __ .....i---.--1n......,..i.--..o........,_help,.....
,_,....,,., ..... twnl s\ey pr I d~ C'liv..
FIGURE 3-2 1 Microsoft Proje~
'°"ref': ,.. '
C I
In addition to 1\i1icrosofr Project, there are a number of other project management
tools available. For example, GanttProiect is a free open-source Java-based project
management tool that is available on multiple platforms (Windows, Mac OS X, and
Linux). It can produce Gantt and PERT/CPM charts, calculate the critical path auto·
marically, and read/write M icrosofr Project files .
Canlter is a free cloud-based project management tool. It runs in a browser window,
so there's no sofrware to install to use it. Apptivo and smartsheel are other
example~ of web -ba~ed project management tools offering simi lar capabilities but on
a paid subscription model.
Monday is a project management tool that is 11:ailored toward Mac u ers. As
shown in Figure 3-22, it is a highly visual cloud-based tool that supports agile development.
Trello, shown in Figure 3-23, is aoorher project management tool that is tailored
toward agile development.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 3
Managing Systems Projects
90
3.7 Project Management Software
A new way to manage your projects
..
,;
Pion Orgon11e Trock In one VISUO~ colloboroltve space
Sprint
0
Spmt2(TMWffli)
I
11> ... p""' ...., ~ ...
""""'°Pon:..
I
"-••Part. IOM brnp
Spr1m 1 (IA11 _,
I
,,,... .......
I ---Ito-.
Allignfl St11u1 Epic E111m1110n 0
"
"'9
HOllWl>lge
ii ' '!M Fdrurt
1 c1o,.
OJllayo
Ollllyt
,....,.
s..1 ... Epoc Ettlf'l'lll~ 0
lkJ9
02doft
Hew I g 01-,.
u.,.
-
FIGURE 3-22 Monday is a project management tool that is tailored toward Mac users.
Sour«< ...,
............ _
• a
,_ Don'•--~ ...
n -Ut
............ ~CNdft!A ~
,,.,,...n.n orH'*9 1 filil "°"1 • Ofll. ,_., o..g. a
• tt• fD
Ill
~r '*•••
- " '
-
-FIGURE 3.23 Trello is a project management tool that is tailored toward agile development.
__ ___
,
•
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.7 Project M anagement Software
9 1
The websites for all of rhese cools have more information about their capabilmes,
including demos, trial versions (where applicable), and rraining material.
Lrrespective of which projecr management tool used, a seep-by-seep process is
followed co develop a WBS, work wirh cask patterns, and aoal)'ze cbe critical path.
Tbe main difference is thar the sofrware does most of cbe work automatically, which
enables much more effective managemenr.
The followmg secnons explain how ~licrosofr Project could be used to handle
the sample cask summary for a preliminary investigation shown in Figure 3-24. This
example illusrrares that project management is dynamic and challenging. One significant
advamagc of intcgraced project 1nanagement software is that it allows the proiecc
manager to adjust schedules, estimates, and resource assignments rapidly in response
to real-world evenrs.
PIMH etucty the following t.ak aunnMry:
• First. we need to spend one day studying potential problems or opportunities.
• Then. we will define the project scope and constraints. That will take two days.
• Next, we will a11&lyze the organization ollarts That will take one day.
• After we analyze the charts. tour fact.finding tasl<s can start at once
' Observe operabons (two days)
> Conduct a user survey (three days)
> Conduct 11\terv- (two days)
> Review dOcumentatlOO (One day)
• When alt lour fact-finding tasks are fil'llShed, we win spend one day evaluating leasibilly
• Then we wlll spend one day presenllng the resuns and recommendallons to management.
FIGURE 3-24 A sample ask summary for a preliminary investig;itiOfl.
WORK BREAKDOWN STRUCTURE: Creating a WBS usmg Microsoft Project is
much the same as creating it manually. The tasks, durations, and task pacterns mu~t
still be identified. This informauon might have to be developed, or a task summary
like the one in Figure 3-24 might be used. The goal is co document all casks, dependencies,
dac~, and total projecr durarion. The first step is to create a Gann chart
showing the necessary information. As the information for each task is entered into
Microsoft Project, the duration and the predecessor tasks, if any, should also be
noted.
GANTT CHART: As casks arc entered, the progcam automatically performs the
c::ilculations, detect~ the task patterns, and creates a Gann chart. The charr consists
of horizontal bars, connected with arrows that indicate task dependencies. If a typical
workweek is selected, casks wi ll not be scheduled on Saturdays and Sundays.
However, for a mission-critica l project, a 24/7 calendar might be created. Whatever
is specified, the program will handle che tasks accordingly. Microsoft Project offers
numerous choice~ of display senings, formats, and calculation methods.
NETWORK DIAGRAM: After the Gann chart is completed, rhe darn can he viewed
in the form of a tvlicrosoft Project network diagram, which is simil::ir to a PERT
chart. When rhe Network Diagram option is selected, the project tasks, dependencies,
and stare and finish dares for each task are shown. A network diagram displays the
same information as the Gantt chart, including cask dependencies, but use task boxes
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 3
Managing Systems Projects
92 3.7 Project Management Software
to include much more derail. Using Microsoft Projecr, each cask can be assigned to
one or more people, budgets can be assigned targets, progress reports produced, and
schedules and deadlines readjusted as necessary.
CALENDAR VIEW: Calendar view is a good way to manage day-to-da)' activity. This
view !.hows the tasks, simila r to a PERT charr, as an overlay on the actual calendar.
Because the criucal path is highlighted in red, it is easy for a project manager to determine
priorities at any poim in rime.
Suppose the project manager wants to view the preliminary investigation in
Figure 3-24 as a Gantt chart, a PERT chan, and a day-to-day calendar. All three views are
shown in Figure 3-25. Each view sbo\vs the tasks, tbe riming, the dependencies, and the
critical parh. Note rhat of the four tasks scheduled for September 25, onl) 1 the user surve)'
is on rhe critical path, therefore that should be rbe project manager's primary concen1.
Gantt Chart View
I
i
..... ,o.e-,,,.,............... ~-......................... ,
....
·~~.......... u ....
•9\"
...........,.._..... ....,...... ,..,..
...
• .,.-.-_....,...
-·-
~.-......... ...
---- ·­ ...
_ • .,.............................. t_.
................... ·-
... fl'lllWllll....... . ....
--- -····
PERT Chart View
............ ...
-
C11lendarVlew
~· .
...
-
'
..
..
..
--... ......... u
--· _ • •
-·--
-
-•ft• h_..,, ••
--...
........ ·~- ~
... _
..... ~
-........
-
"". .. • • ...
,_
.... ~
...
......... -...... ·
.... fl'Wl1 ., •
.... I...,.
'+ ,._,., WV.•
l1 ~ _______ 2t. ,----~-----'-'
FIGU RE 3-2S Note how each view displays tile project and highlights tile crttial patll If you were the
project manager on September 25, your primary concern should be conduct1ng tile user survey.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.8 Risk Management
93
J.8 RisK MANAGEMENT
Every IT project involves risks that systems analysts and project managers must
address. A risk is an event char could affect the project negati\·ely. Risk management
is the process of identifying, analrzing, anriciparing, and monitoring risks to minimize
their impact on the projecr.
Although project management experts differ \vith regard to the number of seeps or
phases, a basic list of risk management casks would include rhe following:
• Develop a risk ma11ageme11t plan. A risk management plan includes a review
of the project's scope, stakeholders, budget, schedule, and any other internal
or external factors that might affect the project. The plan should define project
roles and responsibilities, risk management methods and procedures, categories
of risks, and contingency plans.
• fdenti(y tl1e risks. Ri\k identification lists each risk and as~esses the likelihood
that it could affect the project. The derails ·would depend on the specific proj­
Cl't, but most lists would include a mean~ of identification, and a brief description
of the risk, what might cause it to occur, who would be responsible for
responding, and the potential impact of the risk.
• Analyze the risks. This typically is a rwo-step process: Qualitative risk analysis
and quantitative risk analysis. Qualitative risk analysis evaluates each risk by
estimating the probability that it will occur and the degree of impact. Project
managers can u~e a formula to weigh risk and impact values, or they can display
the result~ in a two-axis grid. For example, a Microsoft Excel XY chart
can be used ro display rhc marrix, as shown in Figure 3-26. In rhe chart, norc
the various combinarions of risk and impact racings for the five sample values.
This tool can help a project manager focus on the most critical areas, where
risk probability and porenrial impact are high.
High impact
Low probability
Risk Matrix
High impact •
High probability
10..->o~---~-------~~~~~~~
9
8
7
t;
"' 8
~ 5
-"
.!! 4
a:
3
2
1
Medium impact
Medium probabt~ty
Low Impact
High probability
•
0 *-~~~~~~~~~~~~~..;..-~~~~--!
.--~'"-----. 2
Low Impact
Low probabiltty
3 4 5 6
Risk Probability
7 8 9 10
4 4 t • ~· .:. ~ ------ •
FIGURE 3-2 6 You can use a Microsoft Excel XY chart cype to display a nsk rmtr1x
that shows risk probability and potential impact.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
•

Chapter 3
Managing Systems Projects
94 3. 9 Managing for Success
The purpose of quantitative risk analysis is to understand rhe actual impact in
terms of dollars, rime, project scope, or quality. Quantitative risk analysis can involve
a modeling process called what-if analysis, which allows a project manager ro var)'
one or more elemenr(s) in a model to measure the effect on other elements. This topic
is di5cu5scd in more detail in Chapter 12.
• Create a risk response plan. A risk response plan is a proactive effort ro
anticipate a risk and describe an acrion plan to deal with 1t. An effective risk
response plan can reduce the overall impact by triggering rimely and appropriate
acnon.
• Monitor risks. This activity is ongoing throughout the risk management process.
Ir is important to conduct a continuous tracking process that can identify
new risks, note changes in existing risks, and update any other areas of rhe risk
management pla11.
Forrunarely, there is a wide variety of risk management ~ofrware available to help
a project manager with these casks. Most packages allow a project manager to assign
specific dares as constraints, a lign task dependencies, note external factors rhat might
affect a task, track progress, and displa)' casks that are behind schedule. Armed with
rhis information, the IT ream can quantify the project's risks, just as rhcy use financia l
analysis tools to quantify costs and benefits.
3.9 MANAGING FOR SUCCESS
Project management is a challenging task. Project managers musr he alert, rcchnically
competent, and highly resourceful. They also must be good communicators with
strong human resource skills. Project managers can be proud when they handle a succes-;ful
project that helps rhe company achieve irs business objecrive5.
Unfortunately, projects can and do get derailed for a wide variety of reasons.
\'<'hen problems occur, the project manager's abiliry to handle the siruarion becomes
the crincal factor. When a project manager first recognizes that a project 1s 111 trouble,
what options arc available? Alternatives can include trimming the project requirements,
adding to the project resources, delaying the project deadline, and improving
management controls and procedures. Sometimes, when a project experiences delays
or cosc overruns, the system still can be delivered on time and within budget if several
less critical requirements are trimmed. The system can be delivered to satisfy the
mosr necessary requ irements, and additional features can be added later as a part of a
maintenance or enhancement project.
If a project is in trouble because of a lack of resources or organizational support,
management 1night be willing to give rhe project more commitment and higher priority.
For example, management might agree to add more people to a project that is
behind schedule. Adding staff, however, will reduce the project's completion time only
if the addiciona I people can be integrated effectively into the development team. If
tea m members lack experience with certain aspects of the req uired technology, temporary
help might be obtained from IT consultants or part-time staff. Adding sraff
can mean training and orienting the new people, however. In some situations, adding
more people to a project actually might increase the time necessary ro complete the
project because of a principle called Brooks' law. Frederick Brooks, Jr., then an IBM
engineer, observed that adding manpower to a late software project only makes it
lacer. Brooks reached this conclusion when he saw that new workers on a project first
had to be educated and instructed by existing emp l oyee~ whose own productiviry was
reduced according!)'.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase I
Systems Planning
3.9 Managing for Success
95
To be successful, an informarion sysrem muse satisfy business requiremenrs,
sray wichin budger, be complered on rime, and-mosr imporranr of all-be managed
effectively. As stated earlier and derailed next, when a project develops
problems, the reasons typically involve business, budget, or schedule issues, as
explained in the followmg sections. In addition ro planning and managmg the
project, a project manager must be able to recognize these problems and deal with
them effectively.
You are a systems analyst at Just-In-Time Software. a company that specializes in short delivery
cycles for itS products.The current project is running ~hind schedule, and the project manager
wantS to bring a few extra programmers onboard co help with the work.
You are familiar with Brook's Law. How can you best explain co the project manager
that adding more people co che project at this late stage may make things worse1 You
don't want co be seen as a negative team player. but you're convinced that If you don't
speak up. the project's schedule will slip even more.
3. 9. I Business Issues
TI1e major objective of every system is to provide a solution co a business problem or
opportunity. If the system docs nor do this, then it is a failure-regardless of positive
reaction from users, acceptable budget performance, or timely delivery. When the
information system does nor meet business requirements, causes can include unidentified
or unclear requirements, inadequarely defined scope, imprecise targers, shortcuts
or sloppy work during systems analysis, poor design choices, insufficienr resting or
inadequate tcstmg procedures, and lack of change control procedures. Systems also
fail because of changes in the organization's culrure, funding, or objectives. A system
chat falls short of business needs also produces problems for users and reduces
employee morale and productivity.
As explained in Chapter 2, projecrs without clear scope definitions are risky
because they rend to expand gradually, wfrhout specific authorization, in a process
called project creep. However, even when a project is clearly described, ir must be
managed consrnnrly.
3.9.2 Budget Issues
Cost overruns rypically resu lt from one or more o f the following:
• Unrcalisric estimates that are roo optimisric or based on incomplete
information
• Failure w devel<>p an accurate forecast chat considers all costs over the life of
the project
• Poor monitoring of progress and slow response to early warning signs of
problems
• Schedule delays due ro focrors chat were nor foreseen
• Human resource issues, including mrnover, inadequate training, and
motivation
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 3
Managing Systems Projects
96 3.10 Summary
3.9.3 Schedule Issues
Problems with timetables and project milestones can indicate a failure co recognize
task dependencies, confusion between effort and progress, poor monitoring and
control methods, personality conAicrs among ream members, or cu mover of
project personnel. The failure of an IT project also can be caused by poor pro1ect
management techniques.
If the project manager fails co plan, staff, organi1_e, supervise, communicate, monvate,
evaluate, direct, and control properly, then the project is certain co foil. Even
when factors outside his or her control contribute to the fai lure, the project manager
is responsible for recognizing the early warning signs and handling chem effectively.
"Better blow the whistle," says your friend and project teammate at work. "The project
is out of control, and you know it!" "Maybe so," you respond, "But that's not my call- I'm
not the project manager." What you don't say is that the project manager feels like her
career is on the line. and she is reluctant to bring bad news to management at this time.
She honestly believes that the project can catch up and says that a bad report on a major
project could result in bad publicity for the firm and frighten potential customers.
To be fair. the next management progress report is scheduled in three weeks. It is
possible that the team could catch up. but you doubt it. You wonder if there is an ethical
question here: Even though the report isn't due yet. should a significant problem be
reported to management as soon as possible I You are concerned about the issue, and you
decide to discuss it with Stephanie. What will you say to her1
3 IQ SUMMARY
Project management is the process of planning, scheduling, monitoring, and reporting
on rhe development of an information system. Planning includes identifying all
project tasks and esrimaring the completion rime and coM of each. Project scheduling
involves rhe crearion of a specific timetable, u!.ualJy in che form of charts thar show
casks, cask dependencies, and critical tasks char might delay rhe project. Projecr monitoring
requires guiding, supervising, and coordinating the project ream\ workload.
The project manager muse monitor the progress, eva luate the results, and cake corrective
action when necessary to control the project and stay on carget. Project reporting
includes regular progress reports ro management, users, and the project ream itself.
Effective reporting requi res st rong communication skills and a sense of what others
want and need ro know about the project. A successful project must be completed on
time, be within budget, and deliver a quality product that satisfies users and meets
requiremen cs.
A project triangle shows three legs: project cost, scope, and time. A project manager
musr find rhe besr balance among these clemeDrs because a change in any leg of
rhc triangle will affccr rhe orher two legs. Project management techniques can be used
rhroughour rhe SDLC.
Planning, scheduling, monitoring, and reporting-all rake place within a larger
project development framework, \vh.ich includes three key steps: creating a WBS,
identifying task parrerns, and calcula ting the critical path. A WBS must clearly
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase I
Systems Planning
3.10 Summary
97
idenrify each task and include an estimated duration. A rask, or activity, is any work
that has a beginning and an end and requires the use of company resources such as
people, rime, or mone)•. Time and cost esrimares for rasks usually are made m personda)'s.
A person-day represents the work rhac one person can accomphsh in one day.
Esnmaring the rime for project activities is more difficult with larger systems. Project
managers musr consider rhe project size and scope, IT resources, prior experience
with similar pro1eccs or systems, and applicable constraints. In addition to tasks, every
project has cvenrs, or mile!>tones. An event, or a milestone, is a recognizable reference
point rhat can be used ro monitor progress.
Task patterns establish the sequence of work in a project. Task patterns involve
dependent casks, mulriple successor tasks, and multiple predecessor tasks. In larger
projects, rhese patterns can be very complex.
A critical path is a series of casks that, if delayed, would affect the completion dare
of rhe overall project. If any task on the critical path falls behind schedule, the entire
project will be delayed. Tasks on the critical path cannot have slack time. To identify
the critical path, calculate the start and finish date for each cask, which will determine
the critical path for the project.
In project scheduling, rhc project manager de\•elops a specific rime for each rask,
based on available resources and whether or not -cbe task is dependent on ocher predecessor
tasks. The manager can use graphical rools such as Gantt charts and PERT
charts ro assist in rhe scheduling process.
A Gann chart is a horizontal bar chart that represents the project schedule with
rime on the horizontal axis and tasks arranged vertically. ft shows individual tasks
and rask groups, which include several casks. In a Gantt chart, the Ieng-ch of the bar
indicarcs rhc durarion of the rasks. A Gann chart can display progress bur docs nor
show rask dependency derails or re ource assignment unless the charr was created
with a project management program that suppon:s dependency linking and rhe entry
of other information.
A PERT/C P~I charr shows the project as a nerwork diagram with tasks connected
by arrows. Using a prescribed calculation method, the project manager uses a PERT
chart to determine the overall duration of the project and provide specific information
for each task, including the rask IDs, their durarions, start and finish rimes, and
the order in which they must be performed. \Xlirh this information, the manager can
determine the critical path, which is the sequence of tasks that has no slack time and
must be performed on schedule in order to meet the overall project deadline.
Mose project managers use software applications such as Microsoft Project co
plan, schedule, and monitor projects. Project managers are responsible for risk management,
which is rhe process of identifying, analyzing, anticipating, and monitoring
risks 10 minimize their impact on the project.
In ihe end, project management involves the same skills as any other management.
The project manager must be perceptive, analytical, well organized, and a good communicator.
If the project manager senses that the project is off-track, he or she muse
take immediate steps to diagnose and solve the proble1n. lf the project manager fai ls
to plan, staff, organize, supervise, communicate, motivate, evaluate, direct, and control
properly, then the project is certain to fail. Even when factors outside his or her
control contribute to the failure, the project manager is responsible for recognizing
the early warning signs and handling them effectively.

Chapter 3
Managing Systems Projects
98 Key Terms
Key Te rms
actJ\11)- Any work rhar ha~ a beginning and an end and require> the use ol compan) rc<.oorce' including
people, tmte, :rnd/or mone). Example$ indu<le conducung a >erto of 1nten 1cw,, de-1gnmg a report,
\clet.:ung ,ofrware, waifing for the delivery of equipment, and 1ra1nmg u..er~. <iu 11/su l.t\L..
best-ca~ c<itimatc The mosr opcirnisric outcome.
bonom-up technique A method for analyung a large, complex protect as a serii-s of mdl\·idual tasks,
called project tasks.
Brool..s' la" hedenck Brooks, an IB~l engineer, observed that adding more rnanpO\\Cr 10 a !are soft·
\I ar~ proiect 01il) mak~ 11 later.
code re1 iew See structured walk-through.
concurrent 1a;I.. A rask that can be completed ar the same tune as (in p.1rnllel wnh) another task.
~riucal path A 'cric• of events and activities with no ;lack time. If any act1v11y along tht• critical path
foils hchind schedule, the entire project 'chedule i\ similarly delayed. 1\s the name implic,, a critical
parh include., all activities rhar are vir:il t() rhe project M:hedule.
Critical !~uh Method (Cl'M) Sbows a project as a nerwork diagram. The ,tctivitics Jre shown as vectors,
.ind the events are displayed graphically as nodes. Although Cl'M developed sepJrarely from the Progr.1rn
fa .1luarion Re1iew Technique (PERT), che two methods are essentially idenucal. See a'5o l'l:R l /CPM.
dependent t.1sk A task is said robe depeodem when ir has robe completed ma seri.11 sequence.
design re\lew See srrucrured walk-through.
durauon lne amounr of time 1r will rake ro complere a rask.
cwnc 1\ reference point thar marh a major occurrence. U~ to monitor pro11rc\\ and mana11c a projen.
Sec .ilso m1fc,tone.
fin,.,h day/d:ue The dov or d:irc when a cask i:. scheduled to be finbhed.
C~nn ,h;an A hormmtal bar chart chat illusrrate> a ,.:hcduf.,. Dc1•dopcd man) year' a110 b) Henry L
Gann as a proJouion 'ontrol c.,,hniquc. Still arc in common LI><: todJ).
nufc,tnnc \ reference point that mark. a major occurrence. U«:d to monitor pmgre" and manage a
projccr. See also event.
ncmnrk d1agr:im A PF.RT chan al~o is referred to as a network diagram.
open source Sofrware thac is supported b) a large group of users and developer•. The source code is
mJde free!) available.
pcrson-dav I he amoum of work that one person can comple1e in one d.1y.
l'l:.R f /Cl'M lbe l'rogr.im Ev•lua11011 Review Tecbmque (Pl:.RT) "a> developed by 1he U.S. Navy 10
man.tgc very complex projects, such as rhe construction of nuclear submarines. At appro,imarcly rhe
same 11me, the Cnrical Pach Method (CPM) was de, eloped by pnvare indusrr) to rnccr ~1m1lar project
management needs. The tmporranr disrincrions berween the two methods hal'e disappeared over rime,
and rot.lay 1he rechmque is cillled either PERl~ CPM, or l'ERT/Cl'M.
prc<lccc"or ta\k A <mglc prior task upon wl1 ich two or more concurrent 1.1sk\ depend.
probablc·<:a\c c\limarc The most likely outcome is called a probable-ca~c c\timatc.
Prol\ram [·.valuation Re\ i~ Technique (PERT} See l'ERT/CPM.
project coordin;11or The person who handles administrative responsihilitie< for the development team
and negoriate' wirh u~ers who might have conAicring requirement~ or wane changes that would
rc4uirc .11Jditional time or c..:pcnse.
pro1c't lc:ldcr The perwn chJrgcd with leading a project from a rechnical per~pc,rivc.
pro1c.:1 m.inJgcment The process of planning, schedtilm!(, mon11onng, controlltng, .1ntl reportutg upon
che dcl'elopmen1 of an information system.
pro1c.:r manager The pcrwn charged ,,;th maaagiag a projccc from an admm1stranve pcr<ipective.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase I
Systems Planning
Key Terms
99
pro1cct monitonng Gu1dmg, supervising. and coordin:iriog chc project 1eam's worlJoad.
project planninl( ldcnufymg prOJC\:t IJ>b and estimating completion ume Jnd cosb.
projcc1 rcporunit Pro,1dmg regular progress reports 10 managemen1. users, .md the pro1ecr 1eam nsclf.
pro1cx1 "'hrdulin11 The vca11on of a ">pc<:ific umcrable ro faciliratc complcuon ot J pro1a:1. Al'o m'ol'c'
<electing and ;,1;iffing rhc pro1ccr ream and a'\~1gnmg specific tasks to team mcmh<:.-.
pro1cct 1nan11k The thr« ma1or component~ of a project: co<t, scope, and nmc. A projc~'t manager rric\
to find the optimal balance among the\C facrors.
qualuati'c mk anal}"' Fvaluaring ri\k by escimaring che probability rhar ir will occur and the dcgrc-e of
impact.
quantitauvc ri~k anal) m cvaluaung mk m rerms of rhe acmal impact m terms of dollars, tune, pro1ccr
scope, or qualiry.
ri~k
An C\'ent th.tr could affccr the pro1ccr negatively.
ri~k identification Lming each risk and assessing the likelihood thar it could affect a pro1ccr.
ri'\k manai;cmcnt The procc'' of idcnrifying, evaluating. cracking, and controlling ri'h to minimize rhcir
impact.
ri,I.. management plan lnducJc, n rcvi<.·w of the prujt:t.'t's scope, sr:akeholtle,.,., hud11tt, •chet.lulc, and any
other internal or c'rcrnal factor' chat might affect the project. The plan <hould define projc~1 role\ and
rC"pomihi liric<, ri'k m,inagcmcnr mcrhod< and procedures, categoric< of ri<h, and contini;cncy plan<.
risl.. response plan A proaciive cffon to .inricipare a risk and describe an action plan rode.ii with ii. An
effecche rt>!. respon.)t p!Jn can reduce che o~erall llllpacr by criggenng a timely and appropri.ue acuon.
~I.tel. urnc !be amount of ume b) which an e\'enr can be !are without delaymg the pro1ecr. lbc difference
bet~ttn btest compleuon ume (LC!) and earliest completion titne (l:.Cf).
start day/dare lhc dJ) or date when a rask 1s scheduled to begin.
\tructurcd "alk-through \ rc,·1ew of a project ream member's work h}' other member\ of the ream.
Generali)', 'l'rcm' analy•r• review the work of orher S)"St:ems analym, and programmer\ renew rhc
worl.. of other programmer-, a' a form of peer re,·iew. Should take place throughout chi: SOI.( and
ar1: called rcqu1n:mcnt r.-vicw•, dc\lgn review<, code rC\;ews, or tc:>tmg n:v1cw•, dcp1:nd1ng on the
pha\C in "h11:h thcr occur.
\UCCC\\nr ta'k F.ach nf the cnncurrcnr ra•k' of a prcdeccswr cask.
ca'k An} worl.. that ha<i a beginning and an end and requires the use of company resources 111clud111g
people, time, ,111d/or money. Examples include conducting a series of inter\'iews. designing .1 report,
~elect111g buff\\ are, waiting for the deJi,ery of equipment, and training users. See .:1/su a1..1 .. it>ta>k
bu" A i:o111ponc111 of a PF.RT/CPM charr that contains imporranr scheduling and duration information
abour J tJ>k. Fnch ra>k in a pruic1..-i is represented by its own task box in the PF.RT/CPM 1..hart.
ta>k group A ta'k thnt rcprc~cnr~ ~C\'eral activ11ics.
task ID A number or code thn1 uniquely identifies a task.
task name A brief dcscrip11ve name for a task, which does not have to be unique in the pro1ecr. Fc>r
example, a task 11.1med Conduct l111erv1ews might appear in several phases of the proiecr.
tasl.. paucrn A log"al •~quence of ra~ks ma WBS. Can involve sequential tJsk>, muluple >U"e;;or tasks,
and muluple predecessor tasks.
tcmng rc•icw See '\tructured \\all..-through.
\\eight An important mulupher th,1r managers facror inro esnmares so the) c.in he an3lyzed.
\\Ork brcal..do" n uructurc (WBS) A pro1ect broken down imo a series of smaller task\. Su also Gantt
chan; PERT/CPM chan.
wo~t -ca'c C\t1111.1tc The most pcss1m1sric outcome.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 3
Managing Systems Projects
100 Exercises
Exercises
Quest ions
I. Draw a pro1ect rriangle that shows rhe relationship among project cost, scope, and time.
2. \Vrite the S(.Tipt for a one-minute explanation of basic project management concepts.
3. Explain the differences bcrwecn a Gann charr and a PERT/CP~I chart.
4. \Vhat are the three main task parrerns t)'Pes? Provide an example of each.
5. Why is the critical path important?
6. What is a srrucrured walk-through?
7. What arc the rwo main ways project starus is reported to management?
8. What i~ a significanr advanrnge of project management sofrware?
9. List the basic tasks in a risk management plan.
1 O. Explain Brooks' law.
Discussion Topics
Projects
I. When using a project rriangle to illustrate conflicti-ng priorities, Microsoft suggests rhar if rhe problem
is in the fixed leg, work on rhe other rwo legs. For example, if rhe project must nor exceed rhe budger
and it is starting to run over, adjust rhe schedule, or the scope, or hoth. However, if the problem is nor
related ro rhe fixed leg, rhe adju~rmenr mighr have to be in the remaining leg. So, when faced wirh an
inflexible budget (fixed leg) and the schedule is slipping (problem leg), rhe project's ~cope (remaining
leg) mighr have robe adjusred. Why is explaining this siruarion ro management sometime~ a very difficulc
cask for chc sysccms analyst?
2. lf you are managing a large project, would you prefer Gantt charts or PERT/CPM charts ro represent
project status? Explain why.
3. Consider a scenario where a cask is dependent on another task being started bur nor necessarily completed.
for example, a prOJect may depend oa a cask being started and one-fourrh compleced before
the group could start 1heir porrion of the project. Do you think this situation occurs frequently in systems
pro1ects? Wh>• or why not?
4. Some project management applications can be quire expensive. As a manager, how would you justify
the purchase of this sofrware?
5. Risk analysis is rypically a two-step process: qualitative risk analysis and quantitative risk analysis.
As a systems analyst, for which sores of project management decision!. would you use the results from
qualitative risk analysis? 1-rom the quantitative risk analysis?
1. Think of all the tasks chat you perform when you p urchase a car. Include any research, decisions,
or financial issues that rel are ro the purchase. Crea re a \X'BS that shows all the rnsks, their estimated
duration, and an)' predecessor rasks.
2. Figure 3-27 shows a \XfBS with l L tasks. Note tbat each rask has an ID, a description, durarion, and
a reference to predecessor tasks, if any, which must be completed before the task can begin. Also note
that dependent casks can have one predecessor task or several. Construct a PERT/CPM chart from
rhese tasks. Recall that rhis is done as a rwo-step process: (l) display the casks and task patterns, and
(2) enter start and finish rime.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... .... .,...~ • ........._ .... .._.,.,.. o-... ..,._ .,,.,.. _..,.~ ,........., ................. .._ ... ..,.,...,.~"
........... ........ ..., .......................... -.., .n..-. ....-i k-s c~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase I
Systems Planning
Exercises
I 0 I
• I
2
3
..
5
6
7
B
9
10
II
Descr ipt ion
Develop Plan
Assign Tasks 4
D uration
( Days)
Obtain Hardware 17
Programming 70
Install Hardware 10
Program Test 30
Write User Manual 25
Convert Files 20
System Test 25
User Training 20
User Test 25
Predecessor
Tasks
2
3
..
5
5
6
7,8
9,10
FIGURE 3-27 Example of a work breakdown structure listing 11 tasks.
together with their descriptions. durations, and predecessor casks.
3. Many of roday's projects involve team members scanercd across different time zones and in different
phy~ical locations. Moreover, the projects may have adopted an agile mechodology, which reduces
cycle time dramarically. Wrire a brief report rhat summarizes some of the key differences a manager
would face managing chi~ rypc of projecr, as opposed to a traditional pro1ecc.
4. Go to the websites for project management rools (besides Microsoft Project), such as Apptivo (www
.apptit'O.com ), GanttPro1ecr (www.ganttprojed.biz), Ganner (wwmga11Ner.com), smarrshcet (u11uw
.s111arts/Jeel.comlprod11d-to11r/gm1N-charts), }vlonday (U11t•w.mo11day.com), and Trello (www.trello.com).
I:xplorc each program's fearures and describe what you like and don't like.
5. Perform an Internet research co learn more about project risk management and write a summary
of the resulrs. Be sure to search for cbe classic book titled Waltzing with Bears: Managing Risk 0 11
So(tw<1re Projects, by Tom Demarco and Timothy Lister.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

PHASE
Systems analysis is the second of five phases in the systems development life cycle. In the
previous phase, systems planning, a preliminary investigation was conducted to determine the
project's feasibility.The output of that phase, the preliminary investigation report. is used as input
to the systems analysis phase, where a system requirements document is created that captures
the needs of the all stakeholders.
A successful project manager must determine the requirements before starting the design
process. not the other way around. It may be tempting to "just do something" to give the
appearance of productivity, but a systems project that does not satisfy business requirements
serves no useful purpose.
Chapter 4 focuses on the requirements engineering process. This includes system requirements,
team-based techniques, gathering requirements through interviews and other methods,
gathering requirements in agile projects, representing requirements. validating and verifying
requirements, and requirements tools.
Chapter 5 focuses on data and process modeling techniques that analysts use to show how
the system transforms data into useful information. This includes logical versus physical models,
data flow diagrams and symbols, drawing data flow diagrams. drawing context diagrams, drawing
diagram 0 DFDs, drawing lower-level OF Os, data dictionaries, and process descriptions.
Chapter 6 focuses on object modeling techniques that analysts use to create a logical
model. This includes object-oriented analysis, objects, attributes, methods, messages, classes,
relationships among objects and classes, the Unified Modeling Language (UML), and tools.
Chapter 7 focuses on development strategies for the new system and plans for the transition
to the systems design phase.This includes traditional versus web-based systems development,
evolving trends, in-house software development options, outsourcing, offshoring. Software
as a Service (SaaS). selecting a development strategy, the software acquisition process, and
completion of systems analysis casks.
103
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 4
Requirements Engineering
••
•• • •
••
......
•••••••••••
······----···· ·····---··-·· - •••••
•••
•
---· --
Requirements
Engineering
Chapter 4 is the first of the four chapters m the
systems analysis phase. This chapter describes the
requirements engineering process: gathering facts
about a systems project. creating models that will be
used to design and develop the system, and verifying
and validating that the models are correct before
proceeding to the next phase of the SDLC.
The chapter includes three "Case In Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the issue of considering a request by a supervisor to
identify departments that reported the lowest ratings in
a survey that was supposed to be kept anonymous.
LEARNING OBJECTIVES
Whe11 you finish tl1is chapter, you should be able to:
1. Explain system rcquiremenrs and rhc challenges
associated with the rcquircmcnrs engineering process
2. Compare and contrast funcnonal and
non-functional requirements
3. Apply team-based rcquircmcnrs engineering
techniques, including joinr application development
UAD), rapid appltcaaon development (RAD), and
agile method~
4. De1'elop a face-finding plan for gathering
requirements
5. Conduct an interview to gather sy3tem
requircmcntS
6. Use other requirement~ garhering rcchniqucs,
including document review, observation,
questionnaires and surveys, brainstorming,
sampling, and research
7. Explain how requircmcnrs arc gathered in agile
projects
8. Utilize different requircmenrs representation
techniques, including natural language,
diagram~, and mo<leb
9. Explain how ro validate and verify requiremenrs
10. E.x:plain bow roob can help wirh requirements
engineering acciv1ti~
CONTENTS
4. 1 System Requiremenrs
4.2 Team-Based Techniques
Case in Poinr 4.1: 'orch Hills College
4.3 Gathering Requirements
4.4 Garnering Requirements Through lnrerviews
4.5 Gathering Requirements Using Other
Techniques
Case in Point 4.2: CyberStuff
4 .6 Gathering Requirements in Agile Projects
4.7 Represenring Rcquircmcnrs
Ca3e in Point 4.3: Digital Pen Transcription
4 .8 Validating and Verifying Requirements
4.9 Tools
A Question of Ethics
4. 10 Summary
Key Terms
Exercises
f"........., ,.,.r...., t ..... 4•111..-.•...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........,.., ........... ._ ... ..,.,...,.~"
~------.. ... ~ ........................ -..,.n..-.....-ik-sc~ c....,a..-.,.,...,. ..... ID>_... ........ _ .. ~ ....................... ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 2
Systems Analysis
4.1 System Requirements
105
4. I SYSTEM REQUIREMENTS
During the first part of the srstems analysis phase of the SDLC, systems analysts must
idenrify and describe all system requirements. A system requirement is a characteristic or
feature that must be included in an informarion system to satisfy business requirements
and be acceprable to users. System requirements serve as benchmarks to measure the
overall acceprabiliry of the finished system.
Because system requirements arc the focus of the start of the systems analrs1s phase,
it's important to get rhcm correct, right at rhc start of the process. Any problems with
the requirements will have a ripple effect that could negacively affect subsequent phases
of the DLC. In facr, poor requirements engineering is a leading cause of failed projects.
Requirements engineering is composed of three main activities:
1. Gathering requirements: 1111derstanding the problem
2. Representing requirements: describing the problem
3. Validating and verifying requirements: agreeing upon the problem
Each of these activities is described in more decailt in this chapter. The output of
requirements engineeri ng are requirements docun1enrs that capture the essence of
what the system should do. These documents are the input to the next step in the
SDLC, data and process modeling, which is described in Chapter 5.
4.1.1 Types of Requirements
Requirements can be classified according to various characteristics. For example,
requirements may be primarily for the system user, in which case they are referred to
as requirementS definitions. Requirements may also be primarily for the engineering
team, in which case they arc referred to as requirements specifications.
System requirements can also be classified as functionaJ and non-functional. A
functional requirement is a statement of the services a system provides. Examples of
functional requirements include the folJowing:
• The website shall report online volume srariscics every four hours and hourly
during peak periods.
• The inventory system shall produce a daily report showing the part number,
description, quantiry on hand, quanriry alJocated, quantity avaiJable, and unit
cost of all sorted by pare number.
• The contact management system sball generate a daily reminder list for all sales
representatives.
• Each input form must include date, time, product code, customer number, and
quantity.
• The system must provide logon securiry at the operating system level and at the
application level.
A non-functional requirement is a statement of operational system constraints.
Non-functional requirements are also known as quality attributes. Examples of functional
requirements include the following:
• Data entry screens must be uniform, except for background color, which can be
changed by the user.
• The ~)·stem must support 25 users online simuJtaneously.

Chapter 4
Requirements Engineering
106 4.1 Syscem Requiremencs
• Response rime muse nor exceed four seconds.
• The system must be operational 7 days a week, 365 days a year.
• The sysrcm should work on Windows and Nlac platforms.
Non-funcrional requirements may be more critical rhan funcrional rcquiremcnrs;
if the former are not satisfied, the system is useless. Conflicts berween different
non-functional requirements arc common in complex systems. For example, a user
may requcsr chac a sysrem be 100% secure but very usable--rwo requirements chat
arc hard co reconcile.
4.1.2 Requirements Challenges
Requirements present numerous challenges to the systems analyst. Three of the most
imporrant arc imprecision, agreement, and creep.
IMPRECISION: Requirements arc often imprecise because rhcy are usually represcnccd
using natural language, such as the examples shown in Secrion 4.1.1. Natural
language is expressive, bur it is prone to misintcrprerarion. Ir is not uncommon for
vnrious i.rakeholders to completely dlisagrec as to the mea ning of a simple req uirement.
It is for chis reason chat other techniques are used to represent requirements, as
described in Secrion 4. 7.
A requirement may be a high-level abstract statement of a service or of a system
constraint, bur it can also be a derailed mathematical specifica tion. T his is because
requirement~ often berve rwo functions: as a basis for a bid for a contract, and as the
basis for rhe cotitract itself.
If rhe requirements are the basis for the contract bid, it muse be open to interpretation.
Bur if the requirements are the basis for rhe contract itself, it must be defined in
detail. These rwo constraints are difficult to satisfy.
AGREEMENT: One of the main problems with requirements is getting everyone co
agree on the exact meaning of the requirements statements. Jn other words, we want
ro develop requirements in such a way that, upon completion of the system, borh the
systems analyse and rhe client can agree on whether or nor a specific requirement has
been met.
In theory, requirements should be both complete and consistent. A requirement is
complete if it includes descriptions of all faci lities needed by the system. In pr::ictice,
it's 11npossible to corn plerely describe the requirements for a complex system.
A requirement is consisrenr if there are no conflicts or contradictions in the
description of rhc system facilities. In practice, ensuring char there are no conflicts in
the system requiremencs when there may be thousands is quite challenging.
CREEP: There are many social and organizational factors that influence sysrem
requirements. For example, business changes inevitably lead to ch:mging requirements-usually
more of them ;ts the project progresses. T his is particularly true for
long-lived projects where the personnel involved change over rime. This phenomenon
is known as "feature creep."
Rapidly changing requirements can cause numerous problems for systems analysts
and other ream members. This is particularly true for project!. that follow a traditional
waterfall model of the SDLC. It is partly for this reason rhar agile methods are
popular: They explicitly address changing requirements as part of rhe project's management
structure.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
4.1 System Requirements
107
4.1 .3 Additional Considerations
In addition to the three challenges ourlined earlier, syscems analysts muse consider
three important supplementary factors: ( 1) scalability, which determines how a system
will handle future gro\\'th and demands; (2) security, which 1s all-imporrnnc for
today's networked systems; and (3) che coral cost of ownership, which includes all
future operanonal and support coses.
SCALABILITY: Scalability refers co a system's ability to handle increased business
volume and transactions in the future. Because it will have a longer useful life, a scalable
S)'Stem offers a bener rerum on the initial invesanent.
To evaluate scalability, information is needed about projected future volume for all
outputs, inputs, and processes. For example, for a web-based order processing system,
one needs to know the maximum projected number of concurrent users, the periods
of pc:ik onlinc activity, the number and types of data items required for each transaction,
and the method of nccessing and updating customer files.
Even to print customer statements, the analyst needs to know the number of active
accounts and h:we a forecast for one, rwo, or five years because char information affeccs
fucure hardware decisions. In addirion, wich realistic volume projeccions, reliable cosc
estimates for rcl:ued expenses, such as postage and online charges, can be provided.
Similnrly, to ensure thac a web-based hotel reservation system is sufficiently scalable,
the anal)'St would need ro project ncrivity levels for several years of operation. For
example, one might forec:ist the frequency of oaline queries :ibout room availability
and e~timate the time required for e:ich query nnd the average respon~e time. With that
information, server transaction volume and nerwork requirements could be estimated.
Transaction volume has :1 significant impact on operating costs. When volume exceeds
a system's limitations, mainrenance costs increase sharply. Volume can ch:inge dramatic:illy
if a comp:iny expands or enters a new line of business. For example, a new lntemet-b:ised
marketing effort might require an additional server and a 24-hour technical support.
Darn storage also is an important scalability issue. The analyst must determine
how much datn storage is required currently and predict future needs based on system
activity and growth. Those requirements affect hardware, software, and network
bandwidth needed to maintain system performance. Data retention requirements
must also be considered to determine whether data can be deleted or archived on a
specific timetable.
SECURITY: Jn rhc past, security was considered an add-on to a system'& de ign.
This is particul:irly true for legacy sysrems that have been deployed for some time.
Nowadays, security is so important for networked systems that it has changed from a
non-functional requirement to a functional requirement. ln other words, security is :in
ei.sential consider:ition for all systems development.
incorporating security as a first-class requiretnent is particularly important in light
of the seemingly endless news reports of 1nassive data breaches. These hacks tele:isc
personal information from online systems at a scale previously unseen. lf the systems
h:id been m:ide with security in mind from the beginning, they would be much harder
to infiltrate.
The ch:illenge with security as a system requirement is that it is often in conflict
with other user requirements. For example, a requirement that the system should be
accessible online using n web interface immediately makes securing the system much
more challenging. The systems analyst must attempt co reconcile and prioritize the
conflicting requirements during the requirements engineering process.

Chapter 4
Requirements Engineering
108 4.2 Team-Based Techniques
57°10
v
TOTAL COST OF OWNERSHIP: In addition to direct costs, systems developers must
identify and document indirect expenses that contribute to the total cost of ownership
(TCO ). TCO is especially important if the development team is as!.essing several alternative!..
Afcer considering the indirect costs, which are not always apparent, a syscem
thar seems inexpensive iniriaUy migbt actually rurn our ro be rhe cosrliesr choice. One
problem is that cost estimates rend to understate indirect col.ts such as user support
and downtime productivity
losses. Even if accurate figures
are unavailable, syscems
analysts should try to identify
TCO for Cloud Computing
indirect costs and include them
in TCO estimates.
Because cost control is
29°10
FIGURE 4-1 Total cost of ownership when migraung co the cloud can be significandy less
than current computing platforms.
so important, vendors ofren
claim that their products or
services will reduce T CO significantly.
For example, one
of the most common reasons
to migrate n legacy system to
the cloud is reduced TCO. As
shown in Figure 4- 1, cloud
computing offers rhe opportunity
for lower operational
costs due to the our ourcing
of expenses such as ca pita I
investment in exchange for a
pay-as-rou-go pricing model.
4.2 TEAM-BASED TECHNIQUES
The IT department's goal is to deliver the best possible information system, at
the lowest possible cost, in the shortest possible time. To acbjeve the best results,
systems developers view users as partners in the development process. Greater user
involvement usually results i11 better communication, faster development times, and
more satisfied users.
The traditional model for systems development was an IT department that used
structured analysis and consulted users onlr when their inpur or approval was
needed. Although the TT staff still has a central role, and structured analrsis remains
a popular merhod of systems development, mosr IT managers invire system users to
parricipare actively in various development tasks.
As described in Chapter 1, ream-based approaches have been around for some rime.
A popular example is joint application development UAD), wh ich is a user-oriented
technique for fact-finding and requirements engineering. Because it is not linked ro a
specific development methodology, systems developers use JAD whenever group input
::ind inreraccion are desired.
Another popular user-oriented method is rapid application development (RAD).
RAD resembles a condensed version of the entire SDLC, with users involved every
seep of the way. While JAD typically focuses only on fact-finding and requirements
determination, RAD provides a fast-track approach to a full spectrum of systems
development tasks, including planning, design, construction, and implementation.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems Analysis
4.2 Team-Based Techniques
109
Finally, as described in Chapter 1, agile merhods represent a recent trend that
srresscs intense interaction between systems developers and users. JAD, RAD, and
agile methods arc discussed in the following seccions.
4.2. 1 Joint Application Development
Jome application dc\.clopmcnc UAD) is a popular fact-finding technique that brings
users 111to the development process as active participanrs.
USER INVOLVEMENT: Users have a vital stake in an information system, and
they should participate fully in rhe development process. Many years ago, rhe IT
department usually had sole rcsponsibiliry for systems development and users had
a relatively passive role. During rhe development process, the IT staff would collect
information from users, define system requirements, and construct the new system. At
various stages of che process, che IT staff might ask users to review the design, offer
comments, and submit changes.
Today, users rypically have a much more active role in systems development. IT
professionals now recognize that successful systems must be user oricnrcd, and users
need to be involved, formally or informally, at every stage of systems development.
One popular strategy fo r user involvement is a JAD team approach, which
involves a cask force of users, managers, and IT µrofessionals who work togcrhcr to
gather information, discuss business needs, and define the new system requirements.
JAD PARTICIPANTS AND ROLES: A JAD team usually meets over a period of days
or weeks in a special conference room or at an off-sire location. Either way, JAD
participanci. should be insulated from rhe distraction of day-co-day operations. The
objecti,·e is to analyze the existing system, obtain user input and expectations, and
document user requirements for the new system.
The JAD group usually has a project leader, who needs strong interpersonal
and organizational skills, and one or more members who document and record the
results and decisions. Figure 4-2 describes typical JAD participants and their roles.
IT staff members often serve as JAD project leaders, but that is not always the case.
JAD PARTICIPANT
JAD protect leader
Top management
Managers
Users
Systems analysts and
other IT staff members
Recorder
ROLE
Develops an agenda. acu as a facilitator. and leads the JAD session
Provides enterprise-level authorization and support for the project
Provide department-level support for the project and understanding of
how the project must support business functions and requirements
Provide operational-level input on current operations. desired changes,
input and output requirements. user interface issues, and how the project
will support day-to-day tasks
Provide technical assistance and resources for JAD team members on
issues such as security, backup. hardware. software. and network
capability
Documents results of JAD sessions and works with systems analysts to
build system models and develop CASE tool documentation
FIGURE '4-2 Typial JAD partlcipancs and roles.

Chapter 4
Requirements Engineering
I I 0
4.2 Team-Based Techniques
Syscems analysts on rhe JAD ream participate in discussions, ask questions, rake
note , and provide support to rhe team. If CASE tools are available, analysts can
develop models and enter document ation from the JAD session directly into the
CASF tool.
A typical JAD session agenda is shown in Figure 4-3. The JAD process involves
intensive effort by all ream members. Because of the wide range of input and constant
interaction among the participants, many companies believe th:u a JAD group produces
the best possible definition of tbe new system.
Project leader
Top management (sometimes
called the project owner or
sponsor)
Project leader
Open discussion session,
moderated by project leader
JAD team members working
in smaller group sessions,
supported by IT staff
--------
Group leaders
Open discussion session,
moderated by pro1ect leader
Project leader
• Introduce all JAD team members
• Discuss ground rules, goals. and objecuves for the JAD sessions
• Explain methods of documentation and use of CASE tools, if any
• Explain the reason for the project and express top management
authorization and support
• Provide overview of the current system and proposed project
scope and constraints
• Present outline of specific topics and issues to be investigated
• Review the main business processes, tasks, user roles. input. and
output
• Identify specific areas of agreement or disagreement
• Break team into smaller groups to study specific issues and assign
group leaders
• Discuss and document all system requiremenu
• Develop models and prototypes
• Report on results and assigned tasks and toptcs
• Present issues that should be addressed by the overall
JAD team
• Review reporn from small group sessions
• Reach consensus on main issues
• Document all topics
• Present overall recap of JAD session
• Prepare report that will be sent to JAD team members
FIGURE 4-3 Typical agenda for a )AD session.
)AD ADVANTAGES AND DISADVA.NTAGES: Compared with traditio nal
meth ods, J AO is more expensive and can be cumbersome if the group is too large
relative co the size of rhe project. M any companies find, however, that JAD a llows
key users to participate effectively in the requirements engineeri ng process. When
users participate in rhe sysrems development process, they arc more likely ro feel a
sense of ownership in the results and support for the new sysrem. When properly
used, JAD can result in a more accurate statement of system requirement , a better
understanding of common goals, and a stronger commirment to the success of the
new system.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
4.2 Team-Based Techniques
I II
CASE IN POINT 4.1:
N ORTH H ILLS C OLLEGE
North Hills College has decided to implement a new registration system that will allow
students to register online as well as in person. As IT manager, you decide to set up a JAO
session to help define the requirements for the new system.The North Hills organizaoon
is fairly typical, with administrative staff that includes a registrar. a student support and
services team, a business office, an IT group, and a number of academic departments. Using
this information, you start work on a plan to carry out the JAD session. Who would you
invite to the session, and why! What would be your agenda for the session, and what would
take place at each stage of the session!
4.2.2 Rapid Application Development
Rapid application development (RAD) is a team-lbased technique that speeds up
information systems development and produces a functioning information system.
Like JAD, RAD uses a group approach bur goes much further. \Xlhtle the end product
of J AD is a requ irements model, the end product of RAD is the new information sys·
rem. RAD is 3 complete merhodoloh')', with a four-phase life cycle that p:.uallcls rhe
cradicional SDLC pha!ies. Companies use RAD to reduce cost and development rime
and increa!ie the prohabiliry of success.
RAD rel ies heavi ly on prototyping and user involvement. The RAD process allows
u!ier!i to examine a working model as early as possible, determine if it meets their
neeru., and suggest necessar}' changes. Based on user input, the prototype is modified,
and the interactive process conrinues until the system is completely developed and
users are i.atisfied. The project team uses CASE tools to build the prototypes and create
a concinuou!i stream of documentation.
RAD PHASES AND ACTIVITIES: The RAD model consists of four phases: requirements
planning, user design, construction, and cucover, as shown in Figure 4-4. 1
ote
the continuous inreraction between the user design and construction phases.
Requirements planning. The requirements planning phase combines element~ of the
systems planning and l>ystems analysis phases of the SDLC. Users, managers, and IT
staff members discuss and agree on business need s, project scope, constraints, and
sy~tem requirements. The requirements planning phase ends when the team agrees on
the key issues and obtains management authorization to continue.
User design. During the user design pha ~e , users interact with systems analysts
and develop models and prototypes chat represent a ll system processes, outputs, and
inputs. T he RAD group or subgroups typically use a combination of JAD techniques
and CASF, rools co translate user needs into working models. User design is a continuous,
interactive process that allows users to u nderstand, modify, and eventua ll y
approve a working model of the system that meecs cheic needs.
Construction. The construction phase focuses on program and application development
tasks similar to the SDLC. In RAD, however, users continue co participate and
still can suggest changes or improvements as acrual screens or reports are developed.
Cutover. The curovcr phase resembles the final tasks in the SDLC implementation
phase, including data conversion, resting, changeover to the new system, and user
training. Compared with traditional methods, the entire process is compressed. As a
result, the new S)'Stem is built, delivered, and placed in operation much sooner.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 4
Requirements Engineering
I 12
4.2 Team-Based Techniques
Requi rements Plannlng
Task s
• Users, managers, and IT
staff agree upon business
needs, project scope, and
systems requirements
• Obtain approval to
continue
Continuous interaclton
between the user design
and construction phases
User Design Tasks
• Interact with users
• Build models and
prototypes
• Conduct intensive
JAD-type sessions
User
Design
Construction Tasks
• Program and
application
development
• Coding
• Unit, Integration,
and system testing
Cutover
CutoverTasks
• Data conversion
• Full-scale testing
• System changeover
• User training
FIGURE 4·4 Tho fo11r ph11s~ of tile R.AD rno<!el ;i,~ ~quire111entt planning, user design, connruction, arid
cucover. Note the continuous lnceractlon between the user design and construction phases.
RAD OBJECTIVES: The main objective of all RAD approaches is co cue developmenr
rime and expense by involving users in every phase of sysrems development. Because
iris a conrinuous process, RAD allows rhe developmenr ream ro make necessary modificarions
quickly, as the design evolves. In times of right corporare hudgers, iris especially
imporranc co limit che cost of changes chat typically occur in a long, drawn-our
development schedule.
In addition to user involvement, a successful RAD team muse have IT resources,
skills, and management support. Because ic is a dynamic, user-driven process, RAD
is especially v::iluahle when a company needs an information :.yMem to support a
new business function. By obtaining user input from the beginning, RAD also helps a
development ream design a system that requ ires a highly interactive or complex user
interface.
R.AD ADVANTAGES AND DISADVANTAGES: RAD has advantages and
disadvantages compared with rraditiooal structured analysis methods. The primary
advantage is that systems can be developed more quickly with significanc cosr
savings. A disadvanrage is rbat RAD srresses rhe mechanics of the sysccms irsclf and
docs nor emphasize rhe company's suategic business needs. The risk is that a system
mighr work well in rhe shore term, but the corporare and long-term objectives for che
S)'Srcm might nor be mer. Anorber pocenrial disadvantage is char the accclcrared rime
cycle might allow less rime co develop quality, consistency, and design standards.
RAD can be an arrracrive alrernarive, however, if an organizarion understands rhe
possible risks.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
4.2 Team-Based Techniques
113
4.2.l Agile M ethods
Chapter I explained that agile methods attempt to develop a system incrementally by
buildmg a series of prototypes and constantly adjusting them to u er requiremenrs. A~
the agile process continues, developers revise, extend, and merge earlier versions into
the final producr. An agile approach emphasizes continuous feedback, and each incremental
step is affected by what was learned in the prior steps.
As agile methods become more popular, a large con1munity of agile-related software
and &ervices ha~ evolved. Many agile developers prefer not to use CASE toob at
all, and as ~hown in Figure 4-5 rely instead on whiteboard displays and arrangements
of movable sticky notes. This approach, they believe, reinforces the agile strategy:
si1nple, rapid, flexible, and user oriented.
-
- ~
i
-
- •
,.
- - a-
I
•• I •
-
- -,...
-
• - 1
- •
,,:::
•
I
FIGURE 4-5 Reinforcing the agile stntegy: simple, rapid.flexible. and user oriented.
S..., ~d..,. 'I IO l<n 'Vt'f1 lfTI
Scrum is anod1er agile approach. The name cornes from the rugby term scr11111, where
team members lunge ar each other to achieve their objectives, as shown in Figure 4-6.
ll1e systems development version of Scrum involves the same intense interaction, though
it is more mental than physical. ln a Scrwn session, agile ream members play specific
roles, including colorful designations such as pigs or chickens. These roles arc based on
the old joke about the pig and chicken who discuss a restaurant where ham and eggs
would be served. I lowever, rhe pig declines, because that role would require a total
c01nmirmenr, while for rhe chicken, ir would only be a contribution.
Jn the agile world, rhe pigs include the product owner, the facilitator, and the
development team, while rhe chickens include users, ocher stakeholders, and managers.
Scrum sessions have specific guidelines that emphasize time blocks, interaction,
and team-based activities thar result in deliverable software. An agile ream uses a
series of scrums to pause the action and allow the players to reset the game plan,
which remains in effect until the next scrum.
_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __....................... ~~·~---- ···---~~ - .,.-"~...........--......

Chapter 4
Requirements Engineering
I 14
4.3 Gathering Requirements
FIGURE 4-6 In a rugby scrum. team members prepare to lunge at each other to achieve their objectives .
.... ~~ tlCf h~~ ""'
AGILE METHOD ADVANTAGES AND DISADVANTAGES: Agile, or adaprive, methods
are very flexible and cfficienr in dealing wirh cbange. The)' are popular because
rhey srress ream inreracrion and reflecr a set of community-based values. Also, frequenr
deliverables consranrly validare rhe projecr and reduce risk.
I lowever, some porenrial problems exist. For example, ream members need a high
level of technical and interpersonal skills. Also, a lack of structure and documenrarion
can introduce risk factors, such as blurring of roles and responsibilities, and loss of
corporate knowledge. Finally, rhe overall projecr may be subject to significant change
in cope as user requirements continue to evolve during the projecr.
4.3 GATHERING REQUIREMENTS
Gathering requirements is the fi rst step in the requirements engineering process. This
step is also known as requirements elicitation or fact-finding (collecting information).
Whether working solo or as a me1nber of a team, during requirements gathering, the
systems analyst will use various teclu1jques, including interviews, document review,
observation, surveys and questionnaires, sampling, and research.
Although software can help gather and analyze requirements, no program actually
gathers them automatically. First, the information needed must be identified. Typically,
this activity begins by asking a series of questions, such as the following:
• \'<i'hat bu'>iness functions are supported by the current system?
• What strategic objectives and business requirements must be supported by the
new sysrem?
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
4.3 Gathering Requirements
llS
• \Xlhat arc the benefits and TCO of rhe proposed system?
• \XThat transactions will the system process?
• \Xlhar information do users and managers 111eed from the system?
• Must the new sy~rem interface with legacy systems?
• What procedures could be eliminated by business process reengineering?
• What security issues exist?
• What risks are acccprable?
• What budget and rimerable constrainrs will affecr sysrems development?
To obtain answers to these questions, the analyst develops a face-finding plan,
which involves answers to five familiar questions: who, what, where, when, and how.
For each of those questions, one also must ask another very important question: why.
Some examples of rhese questions are as follows:
1. \'(I/Jo? \'V'ho performs each of the procedures within the system? Why? Arc the
correct people performing rhe activity? Could other people perform rhe casks
more effectively ?
2. \'(/hat? What is being done? What procedures are being followed? Why is the
process necessary? Often, procedures are fo llowed for many years and no one
knows why. Question why a procedure is being followed ar all.
3. \'(/here? Where are operations being performed? \Vhy? Where could they be
performed? Could they be performed more efficientlr elsewhere?
4. \'(!hen? \'V'hen is a procedure performed? Why is it being performed ac chis
ame? ls this the best time?
5. I low? I low is a procedure performed? Why is it performed in that manner?
Could it be performed better, more efficiently, or less expensively in ~ome ocher
manner?
There 1s a difference between asking whar is being done and whar could or
should be done. The sysrems analyse first must understand the current siruation.
Onl)' then can rhe question of whar should be done be answered. Figure 4-7
liscs rhe basic questions and when rhey should be asked. Note thar the first two
columns relarc co rhe current system bur the third column focuses on rhe proposed
system.
CURRENT SYSTEM
PROPOSED SYSTEM
Who does It! Why does this person do ltl Who should do itl
What Is donel Why Is it donel What should be donel
Where is it donel Why is it done there! Where should It be done!
When Is It donel Why Is It done then! When should It be donel
How is it donel Why Is It done this way! How should It be donel
FIGURE 4-7 Sample quesaons during requirements elicitation as the focus shifts from the current system co
the proposed system.

Chapter 4 Requirements Engineering
I 16
4.4 Gathering Requirements Through Interviews
4.4 GATHERING REQUIREMENTS THROUGH INTERVIEWS
interviewing is an imporrant requirement gathering technique during the systems
analysis phase. An interview is a planned meeting during which the analyse obrains
information from another person. The skills needed to plan, conduct, document, and
evaluate interviews successfully must be understood.
4.4. 1 The Interview Process
After identifying che information needed, as described earlier in rhe chapter, the interviewing
process commences, which consists of seven steps for each interview:
I. Determine the people to interview.
2. E.srablish objectives for the interview.
3. Develop interview questions.
4. Prepare for rhe interview.
5. Conduct the interview.
6. Documenr rhe interview.
7. Evaluate the interview.
STEP I: DETERMINE THE PEOPLE TO INTERVIEW: To ger an accurate picture, rhe
analyse mu~t select che right people to interview and ask chem the right questions.
The preliminary investigation involved mainly middle manager or department heads.
Now, during the systems analysis phase, people from all levels of rhe organization
should be interviewed. In some situations, it might be prudent to interview stakeholders
that are nor members of the organization, because their opinion is valuable.
Although interview candidates can be selected from the formal orgamzarion charts
reviewed earlier, one must also consider any informal structures that exist in the organization.
Informal structures usual!)' are based on interpersonal relationships and can
develop from previous work assignments, physical proxjmity, unofficial procedures,
or personal relationships such as tbe informal gathering shown in Figure 4-8. In an
informal structure, some people have more influence or knowledge than appears on
FIGURE 4-8 When setting up interviews. an analyst should look
outside a formal organization chart to identify people who might
provide valuable information.
c 1 #.f"Sl-- .....ay LU"'
4
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
4.4 Gathering Requirements Through Interviews
I 17
an organizarion charr. The analysr's knowledge of rhe company's formal and informal
srrucrures helps derermine rhe people ro inrervie'v during the systems analysis phase.
Should several people be interviewed at the same time? Group interviews can
ave time and provide an opporrunicy to observe interacrion among the participant<;.
Group interviews also can present problems. One person might dominate the convcration,
even when questions are addressed specifically to others. Organization level
also can present a problem because the presence of senior managers in an interview
might prevent lower-level employees from expressing themselves candidly.
STEP 2: ESTABLISH OBJECTIVES FOR THE INTERVIEW: After deciding on the
people to interview, objectives for tbe session must be established. First, the general
areas to be discussed should be determined, and then the facts to be gathered should
be listed. Soliciting ideas, suggesrions, and opinions during thc interview is also a
good idea.
The objectives of an inrerview depend on the role of the person being interviewed.
Upper-level managers can provide the big picture to help understand the system as a
whole. Specific details about operarions and business processes are best learned from
people who actually work wirh the sysrem on a daily basis.
In the early stages of systems analysis, interviews usually are general. As the
fact-finding process continues, however, the interviews focus more on specific topics.
Interview objectives also vary at different stages of the investigation. Interviews
should be as brief as possible (though as long as needed), since time is so valuable m
employees, e.~pecially managers. By sening specific objectives, a framework is created
that helps the analyst decide what quescions to ask and how ro phrase them.
STEP 3: DEVELOP INTERVIEW QUESTIONS: Creating a Standard list of interview
questions help to keep the session on track and avoid unnece~ar) tangents. Also,
if everal people who perform the same job are interviewed, a standard question list
permits a comparison of their answers. AJtbough there may be a list of specific questions,
the mterv1ewer might decide to depart from ir because an answer to one quei.­
tion leads to another topic that warrants pursuing. Thar question or topic then should
be included m a re' 1 ed set of questions used ro conduct future interviews. If the
question proves to be extremely important, it may be needed ro return to a previous
interviewee to query him or her on the topic.
The interview should consist of several different kinds of questions: open-ended,
closed-ended, or questions wirh a range of responses. When phrasing questions, :ivoid
leading questions that suggest or favor a particular reply. for example, rather than
asking, "What advantages do you see in the proposed system?" ask instead, "Do you
see any advantages in the proposed system?"
Open-ended questions. Open-ended questions encourage spontaneous and
unstructured responses. Such questions are useful to understand a larger process
or draw our rhe interviewee's opinions, attitudes, or suggestions. Here are some
examples of open-ended questions:
• \Vhat arc users saying about the new system?
• How is rhis cask performed?
• Why do you perform the task that way?
• How are the checks reconciled?
• What added features would you like to have in the new billing system?

Chapter 4
Requirements Engineering
I 18
4.4 Gathering Requirements Through Interviews
Also, an open-ended question can be used ro probe further by asking: ls rhcre anything
else you can rell me abour rhis ropic?
Closed-ended questions. C lo~ed -ended questions limit or restrict the response.
Closed-ended questions are used wbea informarion chat i more specific is needed
or when facts must be verified. Examples of closed-ended questions include the
following:
• How many personal compurers do you have in this department?
• Do you review the reports before rhey are sent our?
• How many hours of training does a clerk receive?
• Is the calculacion procedure described in the manual?
• How many cusromers ordered products from rhe website lasr month?
Range-of-response questions. Range-of-response questions are closed-ended questions
chat ask the person ro evaluate something by providing limited answers ro
specific responses or on a numeric scale. This method makes it easier co tabulate the
answers and interpret che results. Ra nge-of-response questions might include the
fol lowing:
• On a scale of I co 10, with 1 the lowest and 10 the highest, how effective was
your training?
• How would you rate rhe severity of rhe problem: low, medium, or high?
• Is rhe system shutdown something that occurs never, sometimes, often, usuall>•,
or always?
STEP 4: PREPARE FOR THE INTERVIEW: After setting the objccti\'eS and developing
the quesrions, preparing for rhe incerview is next. Careful preparation is essenrial
because an interview is an important meeting and nor just a casual char. \Xfhen the
interview is scheduled, suggest a specific day and time and let the interviewee know
how long the meeting is expecced ro last. Ir is also a good idea to send an email or
place a reminder call rhe day before the interview.
Remember rhat rhc interview is an inrerruprion of the other per~on 's routine,
so rhc interview should be limited re> no more than one hour. If business pressures
force a postponement of the meeting, schedule another appoinrment as soon as ic
is convenient. Remember co keep department managers informed of meetings with
cheir srnff members. Sending a message to each department manager listing planned
appointments is a good way co keep them informed. Figure 4·9 is an example of such
a message.
A list of topics should be se11c to an interviewee several days before rhe mcecing,
especially when detailed in£ormatioo is needed, so the person can prepare for the
interview and minimize the need for a follow-up meeting. Figure 4-J 0 shows a sample
message chat lists specif ic questions and confirms the date, time, location, purpose,
and anticipated duration of the interview.
If there are questions about documents, ask the interviewee to have samples avaiJable
at the meeting. The advance memo should include a list of the documents co
discuss (if it is known what they are). Also, a general request for documents can be
made, as the analyst did in the email shown in Figure 4· 10.
(....,..... J:gi ( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __....................... ~~·~---- ···---~~ - .,.-"~...........--......
I '
I
4.4 Gathering Requirements Through Interviews
•••
d •• I) 0
-
°"""'-·
Phase 2
B
Systems A nalysis
119
From: Soon Tiiiy- t• f~ ....
-I em~ M U..Mw,.....,. ,....a~..,_.. I ....o .......... fWe .-.out uw""" •••a. Miii I wetM ..._• ""9l!t _.. tie¥Wlll
~ ol,,...... ..rr'° ~ tN 1'11.W IYlhl'ft. ,._.. iM. me io.w 6 O'lt ,.....,.. 9CNdlolle • OK:
•ff__....,_
·-i-..-11.. , .-
. _ ..........-:u.. 1·-
1 ... ,.. k1'0W, I MM to,,,.. ..... .,.,, ottw.,..... WI ,...., ••• tl•*'lll..,. r. ~w ~It netCS4f I Nft ta~ ..... tfllt .... leml
.,......., .,,.... ..... tM end ti the~ ... rt ........... copy"' ct. ayllCm ... ~ dow"*" .. toon .. ~ ...... ble u.,.... M¥t ·~
~ . ...... ·-~ Tt\tnld,
FIGURE 4-9 Sample message to a department head about interviews .
•••
d •• I)
0
8
Cc:
llcc
TM-....,..,_"'¥~""'°'.,.., \fl ....,.~• l oa.-., oa.o. 1.L rm~.,. .. ,.... t....o ~ "°"""',....,...,..,
..... ..,. x ,._...., , ..,., .. _.,...,.~...,.~~.-e~w . .,..~u.'" wcu.,...,.tN __
-• Wt'
tJ'W,.. ~ M"'f •s...,•• "*'.....,at .. ~ 1octbotl&1
• 0. .,._...,. ~,..... .......... ~ ~ tit tN: ... .,"""' ,,..,-?
• W"llC ..,,,,., ~ .... 0 ..... .,. ,...,.,.. .,. the,..... ~?
• HIDW....,. .. .,.... ·~~ !ft
• Wt'9 .. ~· .ll'\ tht~411cltMAon~"
~,.,... wipiCll
If""" h9W! "'" ~-..,.....,,..or-..... O\IC dOni '*" thl: GM"IWft s...-em. P'MM No-.. UIOl9 ....._.._•I wn rnicw ""-"".._,.we nllefll
TM"b ,_yew~
.......
Scott Tii ey
FIGURE 4-1 0 Sample message to confirm an interview.
Two schools of thought exist about the best location for an interview. Some
analysts believe that interviews should take place in the interviewee's office, whereas
other analysts feel that a neutral location such as a conference room is better.
Supporters of interviews in the interviewee's office believe that is the best locntion
bccnu~e it m:.ikel> the interviewee feel comfortable during the meeting. A second
argument in favor of che interviewee's office is that the office is where he or she has

Chapter 4
Requirements Engineering
120 4.4 Gathering Requirements Through Interviews
the easiesr access co supporting material that might be needed during the di cussion.
If a complete list of copies is provided in advance, however, che interviewee can bring
the necessary items co a conference room or other location.
Supporters of neutral locations srress the importance of keeping interruptions to a
minimum so both people can concentrate fully. In addition, an interview that is free of
interruptions takes less rime. If the meeting does take place in the interviewee's office,
tactfully suggest that all calls be held until the conclusion of the interview.
STEPS: CONDUCT THE INTERVIEW: After detennining the people to interview,
setting che objectives, and preparing the questions, a specific plan for the meeting
should be developed. When cond ucting an interview, begin with introductions,
describe the project, and explain tbe interview objectives.
During the interview, ask questions in the order in which they were prepared and
give the interviewee sufficient time to provide thoughtful answers. Some answers will
lead co additional questions, which should be asked in a logical order. Establishing a
good rapport with rhc interviewee is important, especia lly if this is the first meecing. If
the other person feels comfortable and at ease, they will probably provide more complete
and candid answers. T he analyst's primary responsibility during an interview is
co listen carefully to the answers. Analyses sometimes hear only what they expect co
hear. Concentrate on what is said and notice an)' nonverbal communication that takes
place. This process i called engaged Hstening.
After asking a question, allow the person enough time to think about the question
and arrive ar an answer. Studies have shown rhar the maximum pause during a conversation
i ~ usually rhree to five seconds. After that interval, one person will begin
talking. An analyst needs co be patient and practice his or her skills in many acrnal
interview !>iruarions to be successful.
When all the questions have been asked, summarize the main points covered in
the interview and explain the next course of action. For example, mention that a
follow-up memo will be sent or that the interviewee should send certain requested
information after the meeting. When the interview has concluded, thank the person
and encourage him or her to reach out with any questions or additional comments.
Also, when the interview ends, it is a good idea to ask the interviewee whether he or
she can suggest any additional topics that should be discussed.
After an interview, sumuiarize the session and seek a confirmation from the other
person. By stating the interviewer's understanding of the discussion, the interviewee can
respond and provide corrections, if necessary. One approach is to rephrase the interviewee's
answers. For example, the analyse could say, "If I understand you correctly,
you arc saying rhat .... "and then reiterate rhe information given by the inrcrviewcc.
STEP 6: DOCUMENT THE INTERVIEW: Although taking notes during an interview
has both advantages and disadvantages, it should be kept co a minimum. It 1s a good
idea to write down a few notes to remember key poin ts after the interview but avoid
writing down everything that is said. Too much writing distr::1crs the other person and
makes ir harder ro establish a good rapport.
After conducting the interview, record the information quickly. Set aside rime right
after the meeting to record the facts and evaluate the information. For that reason,
try not to schedule back-to-back interviews. Studies have shown char 50o/o of a conversarion
is forgotten within 30 minutes. Therefore, use the notes ro record the facrs
immediately so they will not be forgotten. Sun1marize the facts by preparing a narrative
describing wbar cook place or by recording the answers received next to each
question on the prepared list.
Small, portable recorders are effective tools for interviews, but some people arc
uncomfortable when they are used. Before using a recorder, discusr. ics use with the
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
4.5 Gathering Requirements Using Other Techniques
121
interviewee. Assure the interviewee rhar rhe recording will be erased after its contents
are transcribed into note form and that rhe inrerview can be stopped ar any time ar
the inrer\'iewee's request. If sensitive questions are asked, or the interviewee wants ro
answer a question without being recorded, explain that the recorder can be turned off
for a period of rime during che incerview.
Instead of u~ing a traditional recorder that calls anenrion to its presence, an incerviewer
can use built-in audio (or even video) recording features on a notebook or
mobile device. Also, as pointed our in Section 4.9, an interviewer can use powerful
informarion management software, such as Microsoft OneNote, co record the meeting,
store rhe resulrs, and create a searchable file for easy access. lrrespecrive of che mechanism
used co record che meeting, all participants should be aware that what they say is
being recorded.
Wherher or not rhe meeting is recorded, listen carefully to the interviewee's
responses so good follow-up questions can be asked. Otherwise, a second visir
might be needed to ask the questions missed the firsr rime. Also, remember that each
recorded interview takes twice the amount of ri1111e, because the analyst must listen to
or view the recorded meeting again after conducting the interview itself.
After the meeting, a memo should be sent to the interviewee, expressing appreciation
for his or her time and cooperation. In the memo, note the dare, rime, location,
purpose of rhe interview, and rhe main points discussed, so the interviewee has a written
summary and can offer additions or corrections.
STEP 7: EVALUATE THE INTERVIEW: In addition to recording the facts obrained
in an interview, rry co identify any possible biases. For example, an interviewee who
tries to protect hi~ or her own area or function might give incomplece answers or
refrain from volunteering information. Or, an interviewee with strong opinions about
the current or future system might distort the facts. Some interviewees mighc answer
quescions in an arrempr to be helpful even though they do nor have rhe necessary
experience to provide accurate information.
Some interviews are unsuccessful irrespective of the amount of preparacion. One
of the main reasons could be rhar the interviewer and the interviewee did not get
along well. Such a siruarion can be caused b)' several facrors. For example, a misunderstanding
or personal1ry conflict could affect the interview negatively, or the interviewee
might be afraid that the new sysrem will eliminare or change his or her job.
In other cases, the interviewee might give onJy shon or incomplete responses to rhe
open-ended questions. If so, switching ro closed-ended questions, or questions with a
range of replies, may elicit more favorable responses. If that stilJ does nor help, find a
tactful way to conclude the meeting.
Continuing an unproductive interview is difficult. The inrerviewce could be more
cooperarive later, or the analyse might find the information required elsewhere. If fai l­
ure to obtain specific information will jeopardize rhe success of the project, the supervisor
should be informed, who can help decide what action to take. The supervisor
might contact the interviewee's supervisor, ask another systems analyst to interview
the person, or find some other way to get the needed information.
4.5 GATHERING REQUIREMENTS USING OTHER TECHNIQUES
In addition ro interviewing, syMems analysts use other requirement gathering techniques,
including document review, observation, questionnaires and surveys, sampling,
and research. Such techniques are used before interviewing begins to obtain a
good overview and to help develop bener interview questions.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 4
Requirements Engineering
122 4.5 Gathering Requirements Using Other Techniques
4.5. 1 Document Review
Document review c:in help the analyse undersrand how the current system is supposed
to work. Remember that system documenrarion sometimes 1s our of d:itc. Forms
can change or be discontinued, and documented procedures often arc modified or
eliminated. It is prudenr to obtain copies of actual forms and operating documents
currently in use, and ro review blank copies of forms, as well as samples of actual
completed forms. Document samples can be obtained during interviews with the people
who perform that procedure. If rhe system uses a software package, review the
documentation for that software.
4.5.2 Observation
The observation of current operating procedures is another fact-finding technique.
Seeing the system in action provides additional perspective and a better understanding
of system procedures. Personal observation also allows the analyst ro verify statements
made in interviews and deterounc whether procedures really operate as they
arc described. Through observacion, it might be discovered that neither the system
documentation nor rhe interview statements are accurate.
Personal observation also can pro vide important advantages as the development
process continues. For example, recommendations often arc better accepted when
they arc based on personal observation of actual operations. Observation also can
provide the knowledge needed to rest or install future changes and can help build
relationships with the users who will work wirh the new system.
Plan observations in advance by preparing a checklist of specific casks to observe
and qucscions co ask. Consider the following issues when preparing che lisc:
• Ask sufficient questions co ensure a complete understanding of rhe present system
operation. A primary goal is to idenrify the methods of handling sicuarions
that arc not covered by standard operating procedures. For example, what
happens in a payroll system if an employee loses a rime card? \Vhar is rhe procedure
if an employee starts a shift 10 minutes late but then works 20 minutes
overtime? Often, rhe rules for exceptions such as these arc nor written or formalized;
therefore, try ro document any procedures for handling exceptions.
• Observe all rhe steps in a transaccion and note the docu1nents, inputs, oucpurs,
and processes involved.
• Examine each form, record, and report. Determine the purpose each item of
information serves.
• Consider each user who works with the system and the following questions:
What information does tbat person receive from other people? Wh:ir information
does this person generate? How is the information communicated? How
often do interruptions occur? How much downtime occur)? I low much support
does the user require, and who provides it?
• Talk ro the people who receive current reports to sec whether the reporrs arc
complete, timely, accurate, and in a useful form. Ask whether information can
be eliminated or improved and whether people would like to receive additional
information.
As people are observed at work, as shown in Figure 4-11, consider a factor called
the Hawthorne Effect. The name comes from a well-known study performed in the
Hawthorne plane of rhe Western Electric Company in the 1920s. The purpose of the
study was co determine how various changes in the work environment would affect
(....,..... J:gi( ..... I_,.. 4 111.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
4.5 Gathering Requirements Using Other Techniques
123
employee productivity. The surprising result was that productivity improved during
observation whether the conditions were made better or worse. Researchers concluded
that producriviry seemed to improve whenever the workers knew they were
being obsen·ed.
FIGURE 4-1 1 The Hawthorne swdy suggested !hat worker productivity improves during observaaon. Always
consider the Hawthorne Effect when observing the operation of an existing synem.
.....
Although some recent srudies have raised questions about the original findings, be
aware that observation can and does have an effect on normal operations. With this
in mind, always give advance notice ro the supervisor in that area. In some situations,
it might be helpful to explain the purpose of the visit to the people being observed.
4.5.3 Questionnaires and Surveys
In projects where it is desirable ro obrain input from a large number of people, a
questionnaire can be a valuable tool. A questionnaire, also called a survey, i~ a document
containing a number of standard questions that can be sent to many individuals.
Questionnaires can he used ro obtain information about a wide range of topics,
including workloads, reports received, volumes of transactions handled, job duties,
difficulties, and opinions of how the job could be performed better or more efficienrly.
Figuie 4-12 shows a sample questionnaire that includes several different question and
response formats.
A typical questionnaire starts with a heading, which includes a tirle, a brief
statement of purpo e, the name and telephone number of the contact person, the
deadline date for completion, and how and where to return the form. The beading
usually is followed b)• general instructions that provide clear guidance on how
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~----···---~~ - .,.-"~ ........... --......

Chapter 4
Requirements Engineering
124 4.5 Gathering Requirements Using Other Techniques
,._ ..._...._
........................ _ .. _... ...-~...............
.......... ...... ..._,...... to answer rhe questions. Heading~ also arc used to
_....,._._.,,......__....... ---·-­
tt•W .... __ .._., .......... -.----·· ...
-­
I_ ............,..,...._........__
,,_
··­ ·­ -·-
a.0.,. ............--.........
l
...
--· •••
··-
....
,.
---
introduce each main section or portion of the survey
and include instructions when rhe type of question or
response changes. A long questionnaire might end with a
conclusion that thank~ the participants and reminds them
how to return the form.
What about the is ue of anonymity? Should people
be asked to sign the questionnaire, or is tr bener to allow
anonymous responses? The answer depend~ on two questions.
First, does an analyst really need ro know who the
respondents arc in order to march or correlate information?
For example, it might be important to know what
percentage of users need a certain software feature, but
..........,....___.....,..l specific usernames might not be relevant. Second, docs
the questionnaire include any sensitive or controversial
topics? Many people do not want to be identified when
answering a question such as " H ow well has your super­
---
....,,.. lUOOltT'IOMI
.............................. , ...... visor explained the system to you?" In such cases, anonymous
responses might provide better information.
Wben designing a questionnaire, the most importa.
..........................,...,............,_____,..
_....,,,__.._IN.............
ant rule of all is to make sure that the questions collect
- -
rhe right data in a form that can be used to further the
fact-finding effort. Herc arc some additional ideas to keep
in mind ·when designing the questionnaire:
- • Keep the questioonaLre brief and uscr-fricndlr.
• Provide clear instructions chat will answer all anticipated
questions.
- -
FIGURE '4-12 Online version of a sample questionnaire.
Does it follow the suggested guidelines!
• Arrange the questions in a logical order, going from
simple to more complex topics.
• Phrase questions to avoid misunderstandings; use simple terms and wording.
• Try not to lead the response or use questions that give clues to expected
answers.
• Limir the use of open-ended questions that are difficulr to tabulate.
• Limit the use of questions that can raise concern~ about job security or other
negative issues.
• Include a secrion at the end of the questionnaire for general comments.
• Test the questionnaire whenever possible on a small test group before fina lizing
ir and distributing ro a large group.
A questionnaire can be a traditional paper form, or it can be created in a fill-in form,
and the data can be collected on the internet or a company intrnnct. Before publishing
the form, protect ir so users can fill it in but cannot change the layout or design.
O nline survey websites, such as SurveyMonkey and Google Forms, ca n also be used
to create and manage questionnaires.
4.5.4 lnterviewsVersus Questionnaires
\'<i'hcn seeking input from a large group, a questionnaire is a very useful cool. On the
other hand, if detailed information is required from only a few people, then each
(....,..... J:gl( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
4.5 Gathering Requirements Using Other Techniques
125
person should probably be interviewed individual!)•. ls it bener co interview or use
a questionnaire? Each sicuacion is different; consider the rype of information, time
constraints, and expense factors.
The interview is more familiar and personal than a questionnaire. People who
are unwilling co put critical or conrro,·ersial comments in writing might talk more
freely in person. ~l oreover, during a face-co-face interview, the interviewer can react
immediately co anything che interviewee says. If surprising or confu~111g statements
arc made, the topic can be pursued with additional questions. In addition, during a
personal interview, the analyst can watch for clues co help determine if responses are
knowledgeable and unbiased. Participation in interviews also can affect user anirudes
because people who arc asked for their opin ions often view the project more
favorably.
Interviewing, however, is a costly and rime-consuming process. IJ1 addition to the
meeting itself, both people must prepare, and the interviewer has to do follow-up
work. When a number of interviews are planned, the rotal cost can be quite subsrnntial.
The personal interview usually is the most expensive fact-finding technique.
ln contrast, a questionnaire gives many people the opportunity to provide input
and suggestions. Questionnaire recipients can answer the questions at their convenience
and do not ha vc to set aside a block of time for an interview. If the questionnaire
allows anonymous responses, people might offer more candid responses than
they would in an interview.
Preparing a good questionnaire, however, like a good interview, requires skill and
time. If a question is misinterpreted, its meaning cannot be clarified as easi ly as in a
face-to-face interview. Furthermore, unless questionnaires arc designed well, recipients
mighr view rhem as inrrusive, rime-consuming, and impersonal. The analysr should
elect rhe rechnique char will work besr in a particular siniarion.
4.5.5 Brainstorming
Another popular method of obtaining input is called brainstorming, which refers to
a small group disCu$s1on of a specific problem, opporruniry, or issue. Thi'! technique
encourages new ideas, allows team parricipation, and enables participants to build
on each other's inputs and thoughts. Brainstorming can be structured or unstructured.
In struccured brain\torming, each participant speaks when it is his or her turn
or passes. In un\ tructured brainstorming, anyone can speak ac any rime. At some
point, the resulrs are recorded and made pare of che fact-finding documenratton
process.
4.5.6 Sampling
When studying an information system, examples of actual documents should be collected
using a process called sampling. The samples might include records, reports,
operational logs, data entry documents, complaint summaries, work requests, and
various types of forms. Sampling techniques include systematic sampling, stratified
sampling, and random sampling.
Suppose there is a list of 200 cusromers who complained abour errors in their
statements, and a representative sample of 20 customers will be reviewed. A
systematic !>ample would select every cench customer for review. To ensure that the
sample is balanced geographically, however, a stratified sample could be used to select
five customers from each of the four postal codes. Anocher example of stratified
sampling is to select a certain percencage of rransaccions from each postal code, rather
than a fixed number. Finally, a random sample selects any 20 customers.

Chapter 4
Requirements Engineering
126 4.5 Gathering Requirements Using Other Techniques
The main objective of a sample is co ensure that ir represents the overall popularion
accurately. If inventory transactions are being analy7ed, for example, select
a sample of tran actions char is typical of actual inventory operations and docs not
include unusual or unrelated examples. For insrance, if a company performs special
processing on the last business day of rhe month, char day is not a good time to sample
typical daily operations. To be useful, a sample must be large enough to provide a
fair reprcsenrarion of the overall data.
Sampling should also be considered when using interviews or questionnaires.
Rather than interviewing everyone or sending a quesrionna1re to the entire group, a
sample of participants can be used. Sound sampling techniques muse be used to reflect
the overall population and obtain an accurate picture.
4.S.7 Research
Research is another important fact-finding technique. Research can include the Internet,
IT magazines, and books to obtain background information, technical material,
and news about industry trends and developments. In addition, attending professional
meetings, seminars, and discussions with other IT professionals can be very helpful in
problem solving.
The Internet is rin extremely valuable resource. Using the Internet, the analyst can
access information from federal and state governments as well as from publishers,
universities, and libraries around the world. Online forums and newsgroups arc good
resources for exchanging information with other professionals, seeking answers co
questions, and monitoring discussions that are of mutual interest.
All major hardware and software vendors maintain websites with information
abour product<> and services offered by the company. There arc also websites
mainrained by publishers and independent firms that provide links co hundreds of
hardware and software vendors. Examples of popular websites for IT professionals
include Ars Technica, CNET, Info World, TechCrunch, and the Wlal/ Street journal's
Technology pages (shown in Figure 4-13 ).
-~--- . . _,. - ... ..
'VSJ lICll --·
- ·---
.........
_ ---
- -- "" ...................... .,_,. w.•• .......... _._ -a.
---
......_...._
~...._ ......... <-. -
--­ ~-·
--~
.,,..._. __
........ ~
........ ~
.
r...J ..... ~c:.ar...
_......._..,._
__
\
f\>llllcal Rtallly: Buy Ads ._ on Fatfbook or lllik
_............. Loi.Ins the ElecUoo
...,._ ...
... --··
..........
-·-· ..
_ -..
.......... -- -
,....._.,_,.. ~ _ ....,............. ------·~
... ,_._
....... ·- .......___
_...,... __ _
... .....__........,_ .......................
--­
·--­
......_...................._._... -...............
...,_~ ..... --........ . -----·
__ .....,._...,._
-
1--
_.,._
1
"'
• -
·--·- ~
---- .. --· ,_...._,.
!-··!
FIGURE 4. 13 The WoH Sr:reetjoumo/'sTechnology website contains valuable infonnadon
for IT professionals.
~re-= .. ~ ~• n.l.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
4.6 Gathering Requirements in Agile Projects
127
Research also can involve a visir ro a physical location, called a site \tsit, where the
objective is to observe a system in use at another location. For example, if a firm's
human resources information system is the subject of study, it might be beneficial co
see how another company's system works. Site visirs also are important when considering
the purchase of a sofrware package. If the sofrware vendor suggests possible
sites to vi~it, be aware that such sires might constirute a biased sample. A single site
visit seldom provides crue picrures, so try co visit more than one installation.
Before a site visir, prepare just as for an interview. Contact rhe appropriate manager
and explain rhe purpose of the visir. Decide what questions will be asked and
what processes will be observed. During the visir, observe how rhe S)'Stem works and
note any problems or limiracions. Also learn about the support provided by the vendor,
the quality of the system documentation, and so on.
CASE IN POINT 4.2: CYBERSTUFF
CyberSwff is a large company that sells computer hardware and software via telephone and
online. CyberSwff processes several thousand transactions per week on a three-shift operation
and employs SO full-time and 125 part-time employees. Lately. the billing department has experienced
an Increase In the number of customer complaints about incorrect bills.You have been
tasked with finding out why this is happening.
During your preliminary Investigation, you discovered that some CyberStuff representatives
did not follow established order entry procedures.You feel that with more Information.
you might find a pattern and identify a solution for the problem, but you are not
sure how to proceed.
Is a questionnaire the best approach, or would interviews be better? And whether you
use interviews, a questionnaire, or both techniques. should you select the participants at
random, include an equal number of people from each shift. or use some other approach?
How do you proceed?
4.6 GATHERING REQUIREMENTS IN AGILE PROJECTS
Lf agile methodi. are used for requirements gathering, a variation on interviews
that focuses on features, user ~tories , scenarios, and storyboards is used. A feature
(sometime~ called an epic) is a simple, bigh-level statement of a requirement. A
feature has a descriptive name, an estimate of its size in terms of derived requiremenrs
or user stories, and a priority. Features are typically provided by the stakeholders
through initial interviews with rhe systems analyst.
User stories represent more fine-grai ned requirements. Taken together, a set of user
stories forms a fearure. A user story also has a descriptive name, along with a i.imple
sentence of the form "As a I user role], I want [action] so that [goal I." User roles,
actions, and goals arc terms that represent a category of stakeholder, a particular
effect, and an outcome, respectively. User stories also include an optional condition
of satisfaction, wh ich can be used as a guide to determine whether or not the requirement
was satisfied by the produce. A user story is: 1neanr to be succinct and is often
drawn on a 3" x 5" index card (or the software equivalent).
A scenario is a real-world example of how users will interact with the system. A
scenario describes a parricular ser of seeps raken or events that wiU occur while the
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 4
Requirements Engineering
128 4. 7 Representing Requirements
system is used for a specific function. Ir is used to refine rhe system requirements ro
better reflect actual usage of the sysrem.
A storyboard is a simple graphic organi7..er rhar helps systems analysts visuali7..C rhe
srarus of a project. A sror)•board can be as rudimentary as a wall with <;rick)' norcs.
There arc also many software roots that enhance storyboards while still maintaining
their essential feel.
Because agile methods are iterative in nature, requirements are gathered and successively
refined. They begin as features, which are then spllC mro smaller user stories,
which in rurn are refined inro scenarios. Agile methods are particularly well suited ro
pro1ccrs where rhe requirements are expected to change frequently.
4. 7 REPRESENTING REQUIREMENTS
Once requirements have been gathered, they must be recorded. Keeping accurate
records of inrerviews, faces, ideas, and observations is essential to successful systems
development. As information is garhered, the importance of a single item can be
overlooked or complex system derails can be forgotten. The ability ro manage infor-
1narion is rhe mark of a successful systems analyst and an important skill for all .IT
professionals. The basic rule is to write it down. Analysts should document their work
according to the following principles:
• Record information as soon as it is obtained.
• Use the simple'lt recording method possible.
• Record findings in such a way rhat someone else can understand them.
• Organize documenrarion so related material is located easily.
There arc several techniques used to do this, ranging from an unordered collection of
sentences to a structured database of formal models. Whatever representation is chosen,
proper!)' managing the requirements over rhe lifetime of a project is a key to irs
success.
4. 7. I Natural Language
The vast majoriry of requirements are represented using unstructured natural language,
that is, plain English. Examples of these requirements were shown in Section
4. ·1.1. This represcnrarion is easy to create but is prone co problems such as imprecision
and a lack of shared understanding.
Requirements represented as unstrucrured natural language can he ~tored in a simple
file, in a database that may facilitate sea rch ing its contents, or in an Excel spreadsheet.
The larrer choice is a popular one, because most systems analysts are familiar
with rhe root, and chey are likely to have access co it already.
An improvement upon unstructured natural language is structured natural language.
This representation rags part of the requirement, rather like an XML document.
This facilitates automated processing of the requirement statements, but it's not
very user-friendly.
Requirements represented as structured natural language can be stored on a simple
index card. The Volere shell from the Atlantic Systems Guild, shown in Figure 4- 14,
i~ a mature method of representing single requirements on a 3" x 5" card. There are
several tools that mimic these fearures, providing automation while maintaining the
simple representational format.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
4.7 Representing Requirements
129
There arc also formal techniques, based on mathematics,
that can be used to represent complex requirements.
Languages such as VDM and Z are used for this purpose.
They have the advantage of mathematical consistency, but a
major disadvantage of this technique is that many systems
analysts are unfamiliar with the language's consrrucrs,
which can affect the requirements' understandability.
lrrespecttvc of the natural language cechnique
chosen, md1v1dual requirement<; must be collected
into a requirements document. This document is the
official statement of what is required of rhe syscem by
the users. The Volere template is a good template for a
comprehensive requirements document. It is populated by
atomic requi rements from the Volcre shells.
FIGURE 4-14 TheVolere shell.
~ A tr• \... 1 r
Volere
CASE IN POINT 4.3:
DIGITAL PEN TRANSCRll'l ION
You are the lead systems analyst on a large project.A big part of your responsibilities is to handle
the system requirements. Extensive interviews have taken place, and you have written down
your notes using a digital pen system.This system recognizes letters and words while you write
on paper and srores them in digital format on your computer. In this way. the requirements are
written in unstructured nawral language but stored digitally, which means they can be searched
and processed. Do you think it would be worthwhile to edit the transcription and insert tigs to
delineate key terms in the requirements, so that a CASE tool could better analyze them/There's
a lot of effort required to do the manual tagging. but the rewards could be better requirements.
How would you perform the tradeoff analysis!
4.7.2 Diagrams
~lany people are more visual rhan texrual. For them, diagrams are an excellent choice
co repre!.enr system requirements. Diagrams help users, managers, and IT professionals
understand the design of a system. Diagramming involves graphical methods and
nontechnical language that represent the system at various stages of development.
During requirements engineering, the analyst can use various cools co describe business
processes, requirements, and user interaction with the system.
Systems analysts use diagram1ning and fact-finding interactively-first they build
fact-finding resu lts into diagrams, then they study the diagrams to determine whether
additional face-finding is needed. To help chem understand system requirements,
analysts use fu nctional decomposition diagrams, business process diagrams, and dara
flow diagrams. Any of these diagrams can be created with CASE cools or stand-alone
drawing tools if desired.
FUNCTIONAL DECOMPOSITION DIAGRAMS:
A fun ctional decomposition
diagram (I-OD) is a mp-down representation of a. fu nction or process. Using an f DD,
an analyst can show business functions and break chem down inco lower-level func·
tions and processes. Crearing an FDD is sin1ilar co drawing an organization chart:
Scare at rhe top and work downward. Figure 4-15 shows an FOO of a library system
drawn with the Visible Analyst CASE cool. FDDs can be used at several stages of
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 4
Requirements Engineering
130
described in Chapter I, a bu\iness proce~ s
i
~
!
a
E
.. ..
~·
,. model (BPM) represents one or more
Pfoce11 Order
Create Sh1.pp1ng
-t Prepare 81111no H
busi11ess processes, such as handling an
Oata
~
airline reservation, filling a product order,
--ti;
.. ~
or updating a customer account. During
c
;;; requirements engineering, analysts ofren
-..
w
create diagrams that use a standard
!!
Q.
syntax called business process modeling
~
i '
Assign
a s Obtain Crtidil " Validate Credit Customer
notation (BJ>MN). BPMN includes
011• I-+
3 '-
--
Status
H
Number various shapes and symbols to represent
events, processes, :1 nd workflows.
4. 7 Representing Requirements
systems development. During requirements engineering, analysts use FD Os to model
business functions and show how they are organized into lower-level processes. These
processes translate into program modules during application development.
Human
Resources
Finan: e &
AccOUlbng
Operalons
Budge:ing
Bock
Management
Personnel
AssigfT1'1ef11
Add&
Remove Books
CheckolJ&
RetumBooks
Arctwe CheckolJ
l.Jst and Use' l.Jst
FIGURE 4- 15 This Visible Analyse FDD shows a library system with five top-level functJons. The Library
Operadons function includes cwo additional levels of processes and sub-processes.
BUSINESS PROCESS DIAGRAMS: A~
I
FIGURE <4- 16 Using the Visible Analyst CASE tool, an analyst can create a
busine.ss process diagram.The overall diagram Is called a pool. and the cwo
separate customer areas are c:alled swim lanes.
When creating a business process diagram
using a CASE tool such as Visible
Analyst, the diagram automatically
becomes part of the overall model. In
the example shown in Figure 4- 16, using
s.-. ..,.,___,,. ""' ''"' - """"'...,,. BPMN terminology, the overall diagram is
called a pool and che designated customer areas arc called swim lanes. Integrating BP~1
into the CASE development process leads to faster results, fewer errors, and reduced cost.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
4.7 Representing Requirements
131
DATA FLOW DIAGRAMS: \Xforking from an FDD, analysts can creace daca now
diagrams (DFOs) co show how che syscem scores, processes, and cransforms daca.
The DFD in Figure 4-17 describes adding and removing books, which is a function
shown in the Librar)' Managemenc diagram in Figure 4-15.
ore char the cwo boxes
in che DFD repre'lenc processes, each with various inpucs and outputs. Additional
le,·els of informacion and decail are depicted in orher, related DFDs. Daca and process
modeling is deM:rihed in derail in Chapter 5 .
.. Add----
Boob
,.
Bool<Tllo ---2..!.. - ~ .
Ir'"':' - -
AWlOl's
A61'S"'
~ Boob Updaled AIA!"Ol'S
Doob
'.
'.
Boolcs
"
• •
4. 7 .3 M odels
FIGURE 4-1 7 This Visible Amlyst DFD shows how books are added and
removed 1n a library system.
'
Models provide a more formal representation of system requirements. They arc often
depicted as graphical in nature, so they share some of the cbaractcriscics of rhc techniques
described in Secrion 4.7.2. But models have an additional feature: The underlying
language has semantics, which means the diagram has a significance that can be
aucomatically analyzed by a CASE rool.
The Unified Modeling Language (UML) is perhaps rhe most widely used modeling
technique for visual izing and documenting software sysrems design. UML uses
object-oriented design concepts, but it is independent of any specific programming
language and can be used ro describe business processes and requirements generally.
SysML is a dialecr of UML and has become the sitandard for Model-Based Sysrems
Engineering (M BSE) applications.
UJ\llL provides various graphical cools, such as use case diagrams and sequence
diagrams. During requirements engineering, a systems analyse can utilize the
UJ\llL co represcnc the informacion syscem from a user's viewpoinr. Use case dia­
!,'Tams, sequence diagrams, and other U~1L concepcs are discussed in more derail in
Chaprer 6, along with other object-orienced analysis conceprs. A brief description of
each technique follows.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

~~~~~~~~~-
Chapter 4
Requirements Engineering
132
4. 7 Representing Requirements
Customer
Submits
card O..ta
FIGURE 4-18 This Visible Analyst use case diagram
shows a sales system, where the actor Is a customer and
the use case is a credit card validation.
' ¥<' I I f "'" f "1\/ •4 'Y'i I C ~ I •I Jll'I
USE CASE DIAGRAMS: During requirements engineering,
S}'Stems analysts and users work together to
document requirements and model system functions.
A use case diagram visually represents the interaction
between users and the information system. In a use case
diagram, the user becomes an actor, with a specific role
that describes how he or she interacts with the sy5tem.
Systems analysts can draw use case diagrams freehand
or use CASE tools that integrate the use cases into the
overall systems design.
Figure 4-18 shows a simple use case diagram for
a sales system where the actor is a customer and
the use case involves a credit card validation that is
perforn1ed by the system. Because use cases depict
the system through the eyes of a user, common
business language can be used to describe the
transactions. For example, Figure 4-1 9 shows a table that documents the credit
card validation use case, and Figure 4-20 shows a student records system, with
several use cases and actors.
SEQUENCE DIAGRAM: A sequence diagram shows the timing of interactions
between objects as they occur. A systems analyst might u~e a sequence diagram to
show all possible outcomes or focus on a single scenario. Figure 4-21 shows a ~imple
sequence diaE,'Tam of a successful credit card validation. The interaction proceeds
from top to bottom along a vertical rimeline, while the horizonral arrows represent
messages from one object co another.
Name of Use Case:
Actor:
Description:
Successful Completion:
Alternative:
Precondition:
Postcondition:
Assumptio ns:
Credit card validation process
Customer
Describes the credit card validation process
I. Customer clicks the input selector and
enters credit card number and e)(piration date
2. System verifies card
3. System sends autho rization message
I. Customer clicks the input selector and
enters credit card number and e)(piration date
2. System rejects card
3. System sends rejection message
Customer has selected at least one item and
has proceeded to checkout area
Credit card information has been validated
Customer can continue with order
None
FIGURE 4-19 This table documents the credit card validaaon use case shown in Figure 4-18.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
I '
I
Phase 2
Systems A nalysis
4.8 Validating and Verifying Requirements
133
Registration
System
Student
Advisor
lnstruttor
Record
Grades
Registrar
FIG URE 4-20 This Vislble Analyst use case diagram shows a student records system.
Sou~: •r• I ~ 1 .... 1tk pC'f'Tn1 "' 1 •om\l'~I~ !)~CoiporatlO'\-
Customer Credll
Card Cutlomen
Enter Card Number
V•lldate
Card.:Credll Card
Cu1toma11
I
I
I
I Verify Card Number
I
I
I
I
Authortlation
FIGURE 4·21 ThisVlsibleAnalyst sequence diagram shows a
credit card vatldatlon process.
Soutt•:ti. V..ll. wl'1;:> onl -iV ·bicS~~ ·
4.8 VALIDATING AND VERIFYING REQUIREMENTS
Requirements validation and verificarion (V&V) is concerned with demonstrating
that the requirements define the system that the customer really wants. Since require·
ments error costs arc high, V&V is very important; it is many times more expensive
to fix a system later in the SDLC rhan iris to fix it during requirements engineering.
Requirements V&V focuses on answering rwo important questions:

Chapter 4
Requirements Engineering
134 4.9 Tools
• Validation: Are rhe correct requirements stared?
• Verification: Are the requirements stated correctly?
To answer these questions, the following requirements anributes should be
checked:
• Validity: Does rbc system provide the functions that best support rhe customer's
needs?
• Consistency: Are rhere confliccing requirements?
• Completeness: Are all funcrioos required by rhe customer included?
• Realism: Can che requiremenrs be implemented given avmlahle budget and
technology?
• Verifiability: Can the requirements be checked?
• Comprehensibility: Is the requirement properly understood?
• Traceability: Is the origin of rbe requirement clearly seated?
• Adapt:ibiliry: Can the requirement be changed without a large impact on ocher
requirements?
To check rhese, the following techniques can be used:
• Requirements reviews: Systen1atic manual analysis of the requirements.
• Prototyping: Using an cxecucable model of the system to check the
req u i remcn rs.
• Test-case generation: Developing resrs for requirements co check testability.
• Automated consistency anaJysis: Checking the consistency of a srrucrured or
formal requirements descripcions.
Consider requirements reviews. Regular reviews can be held while the requirements
are initially being formulated. Ideally, the systems analyse and the customer
(and perhaps other key scakeholders) should be involved in the reviews. The reviews
can be formal (with complete documentation) or informal. The key is that good communicauons
berween analyses, customers, and others can resolve problems ar an early
stage, which is better for everyone.
4.9 TOOLS
All requirements engineering activities can be helped through rhc judicious use of
tools. For example, many software programs are available co help record and document
information elicited during the requirements gathering process. This type of
productivity software includes automation, word processing, spreadsheet, database
management, presentation graphics, and collaboration software programs. Although
Microsoft Office is the best-known set of productivity software programs, ocher vendors
offer produces in each of these categories.
A pcr5onal information manager (PIM), such as Microsoft Outlook, includes a
personal calendar, a to-do list with priorities and the capability co check off completed
items, and powerful contact management features. Outlook can manage email
and appointments and supports collaboration and team projects.
Although a PL\il such as Microsoft Outlook can handle day-to-day activities,
tasks, and schedules, it is nor the best wa)' co capture and organize large amounrs of
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
4.9 Tools
135
information. lnsrcad, analysts use information management sofrware such as Microsofr
OneNore, which is a powerful, flexible tool that can handle many differenr types of
input, including text, handwritten notes, images, audio and video recording, web link~,
and much more. One ore is included in several versions of the Office suire.
Figure 4-22 show~ anorher popular Pl~1 called Evernote. Ir is available for free
on mosr computing plarforms, including smanphones and on rhe web. There are also
premium versions available on a monchly subscriprion model. Evernote does a great
job of handling all sorts of mulcimedia concent, adding free-form nores, and providing
templates for organizing projects. It also syncs files across all devices.
4 Evemote
-· ., Ll _;__...J
FIGURE 4-ll Evernole offers a free version of its popular infonnation managemenl software for mon
computing platforms. Including smartphones and on the web.
Sowcc
Using word processing sofrware such as rvlicrosoft Word, the analyst can create
repons, summaries, tables, and forms. In addicion ro standard document prepararion,
the program can help organize a presentation wirb templates, bookmarks, annotations,
revision control, and an index. Fill-in forms can also be creared ro conduct surveys
and quesrionnaires, as described earlier in this chaprer.
Spreadsheet software, such as Microsoft Excel, can help track and manage
numeric dara or financial informarion. fn fact, Excel is one of the most popular ways
of representing requirements in an informal manmer. Graphs and charrs can also be
generarcd thar display rhe darn and show possible parrerns. The statistical functions
in a spreadsheer can be used to tabulate and analyze quesrionnaire data. A graphical
formar often is used in qualiry conrrol analysis because it highlights problems and
their po sible causes, and iris effective when presenting results to management. A
common tool for showing rhe disrribution of questionnaire or sampling results is a
vertical bar cha re called a histogram. Most spreadsheet programs can create histograms
and other charts chac can display the daca collected. Figure 4-23 displays a typical
histogram char might have resulted from rhe questionnaire shown in figure 4- 12.
Database management software allows the analyst co document and organite
fact-finding results such as events, observations, and daca samples. A database prograrn
such as Microsoft Access can be used to manage the details of a complex project,
create queries to retrieve specific informarion, and generate custom reports.

Chapter 4
Requirements Engineering
136 4.9 Tools
.,
•
... - -
....
Ii..
'1l
..
e
..
A B c D E (j
1 Question 2:
2 What percenblge of your time do you spend processing niqulsltlon•?
3
4 C•l!QO'Y Number
s < 20% 11
6 20-3t% 21
1 .o.tit% 36
8 60-7t% 2A
9 80% or mora !I
10
11
12
13
14
1 !>
16
11
18
Question 2 results
40 -
35
30 +-------1> Jl-------1
25 'll---:::::----1
20 +-------a. . ~-'
15 .___-f.; :1--1 ,,1--1 .1-----1
10 -'--'....,._ _,, ..._ ... ..._ ...
5 ..... ; --n-~
·
0 ~-.._.-........... -.....................- ..
<20% 20- 40- 60- 80% or
39% 59% 79% more
,. 194 • •1 SheetJ St (11.-u ID • ~-======::=======================~·
____ . _ __,'
FIGURE 4·ll This histogram displays the results from Question 2 In the questionnaire shown
In Figure '4-12.
Presenrarion graphics software, such as tvlicrosoft PowerPoint, is :i powerful tool
for organ i.ling and developing formal presentations. Presentation graphics programs
enable the creation of org:inizarion charts that can be ui.ed in a preliminary inve~cigation
and later during requirements engineering. These high-quality charts also can be
included in written reports and management presentations.
Collaborarion sofrware is the latest weapon in the struggle co boost productivity.
People work m reams and use web-based software such as Google Docs and Microsoft
Office 365 co access data and share files. Google and others are betting char cloud com·
puring wi ll create a vinual workplace, where people will be able co interact in real time,
with all the benefits of a traditional face-to-face workplace bur none of che limirarions.
When it comes co creating diagrams char
represent requirements, Microsoft Visio is a
popular graphic modeling cool char can produce
a wide range of charts and diagrams .
Visio includes a library of templates, stencils,
-.._ - --
I "
'•
~
fJ c: •. ]l
:l·
0
..
-
•••
- •I•
1
FIGURE 4-24 Th1sV1sio drawinc uses drag-and·drop shapes
to represent a business process.
and shapes. An analyst can use Visio co create
many types of visual models, including business
processes, flowcharts, network diagrams, organization
charts, and many more. For example,
in Figure 4-24, the :inalyst used drag-and-drop
shapes to represen r a business process .
For more forma l models of rcquircmcnrs,
special-purpose tools such as IBM Rational
DOORS are used. These cools faci litate the use
of UML (and SysM L) co model sysrcm requirements
in a way that enables desirable characteristics,
such as traceability, where rhe origin of a
requirement i~ connected back co the requirement
itself, which in turn is linked forward co
design artifacts, code fragment~, and even rest
cases in the SDLC. Figure 4-25 illustrates some
of the capabilities of DOORS Next Generation.
le
(....,..... J:gi( ..... I_,.. 4 111.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
4.10 Summary
137
FIGURE 4-25 IBM DOORS Is a to0I for capturing. analyzing, and tr.icing system requirements.
ISM C. P r&
Your supervisor manages the corporate office where you work as a systems analyst. Several
weeks ago, after hearing rumors of employee dissatisfaction, he asked you to create a
survey for all IT employees.After the responses were returned and tabulated. he was disappointed
to team that many employees assigned low ratings to morale and management
policies.
This morning he called you into his office and asked whether you could identify the
departments that submitted the lowest ratings. No names were used on the individual
survey forms. However, with a little analysis, you probably could identify the departments
because several questions were department related_
Now you are not sure how to respond.The expectation was that the survey would be
anonymous. Even though no individuals would be identified, would it be ethical to reveal
which departments sent in the low ratings/ Would your supervisor's motives for wanting
this information matter1
4.1 0 SUMMARY
The systems analysis phase includes three activities: requirements engineering,
data and process modeling, and consideration of development scrategies. The main
objecu,·e is co understand rhe proposed project, ensure char ir will support business
requirements, and build a solid foundation for the systems design phase. Requirements
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 4
Requirements Engineering
138 4.10 Summary
engineering irself is composed of three main parts: ( 1) garhering rcquiremenrs,
(2) represenring requiremencs, and (3) validating and verifying requiremenrs.
During requiremcnrs engineering, che business-relared requircmenrs for rhe new
information sysrcm are idenrified. Scalabiliry is considered ro ensure rhar rhe sysrem
can supporr fururc growth and expansion. Securiry is an essenrial requiremenr of all
modern connccred sysrcms. The TCO is also estimated to idenrify all coses, including
ind1 recr cos rs.
Popular team-based approaches include JAD, RAD, and agile methods. JAD is
a popular, ream-based approach co fact-finding and requ1remenrs engineering. JAD
involves an interactive group of users, managers, and IT professionals who participare
in requiremenrs engineering and develop a greater commirmenc co the project and to
their common goals.
RAD is a team-based technique that speeds up informarion sysrems dcvelopmenc
and produces a functioning information sysrem. RAD is a complete methodology,
with a four-phase life cycle that parallels the cradirional SDLC phases.
Agile mechods attempc co develop a system incremenrnlly by building a series
of prototypes and constantly adjusting them to user requirements. Tools are often
:ivoided and repbced with simpler ailds, such as whiteboards and sticky notes to faci l­
itate communication.
The requirements gathering process includes interviewing, document review, observation,
questionnaires, sampling, and research. Successful interviewing requires good
planning and strong interpersonal and communication skills. The sysrems analyst
musr decide on rhc people to interview; ser interview objectives; and prepare for, conduct,
and :inalyzc incerviews. The analyst a lso might find ic helpful ro use one or more
software rools during facr-finding.
Systems analysts use various tools and techniques ro represent system requirements.
N:irural language, srrucrured or unstrucrured, is still the default. Requirements
can be stored as simple text in a plain file or in an Excel spreadshcer.11ley can :ilso be
srored online for automated search and analysis.
Diagrams are another way of represenring requirements. They are suic:ible for analysrs
who arc more visually oriented. They can a lso capture complementary aspects of
the system reqmrements. Sample diagram rypes include FDDs, busine s process diagram!>,
and DfDs.
Nlodels provide a more formal represenration of system requirements. The UML
is a widely used method of visualizing and documenting i.ofrware de!>ign through the
eyes of the bu~iness user. UML cools include use case diagrams and sequence diagmms
ro represent actors, their roles, and the sequence of trans:iccion!. that occurs.
Systems :inalysts should carefully record and documenr factual information as it
is collected, and various software tools can help an analyst visualize and describe an
informorion system .
Requirements V&V is concerned wirh demonstraring that the requirements define
the system that the customer really wants. Validarion :isks if the correct requircmenrs
:ire srated, while verification asks if the requiren1cnts arc stated correctly.
All requirements engineering activities can be helped through rhc judicious use
of tools. They provide automated support for req uirements atrriburcs such as rraceabiliry.
For very large systems with thousands of requirements to manage, CASE tool
aS!.isrn nee is necessary.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
Key Terms
139
Key Terms
aaor An external enm> wirh a ~pt.'Cific role. ln a use case model, a<.<ors are u>ed !O model mierac.:tion
w11h 1hc >)\lem.
agile method• ~)>leim deH~lopmem methods !ha1 anempt to de,elop a system incrememally h) buildmg
a series of protOt) pes and constantly adiusang them rouser reqwremeots. Also calltd adapuvt
method>.
brain~tomung A fact-finding technique for gaining information rhrough the use of a small group d1scu~sion
of a specific problem, opporrunir), or issue.
bu\ine<>\ pr<~.,., model (BPMJ A b'l"aphical representation of one or more husine>> prnce~e>.
bu.,inc\\ prcx:c\\ modeling notation ( BP~ ) A standard set: of >hape> and 'ymbol> used to rtpre~cnc
evcnL,, proc.e"~• and workOow> in compucer-ha,\ed modding cool>.
clo;cd-endcd qucsuoos Queries thm Imm or restrict che range of responses. Used 10 the 1men 1ew process
when sp«1fic mform.irion or facr verificanon ts desired.
cons1rue1ion phase A ph.1se rhnt focuses on progr,un and applkanon development tasks s1mil.1r to rhe
SDLC.
cuun·cr pha'c A pha\C chat resemble' rhc final ca~ks in che 501 C implementation pha,c, including dam
converoion, te,ring, chnnflcovcr m rhe new •ysrem, and tL~er rraining.
data Oow diagram (DFD) Diaflram rh:u ,how~ how che syscem scores, proces,e•,, and tran,form' data
into u,cful information.
document re•icw A review of b.iselme docurnemauon. A useful fact-finding techuique tllJt helps ,rn .111.1-
lyst underst.ind how the current system rs supposed co work.
eng.igcd lmcmng lne ab1lary ro reall} concenrrare on whar someone as saying and .tvo1d the temptauon
to he.ir "h.1t is e'l.pteted. Alw includes noricmg nonverbal communicanon.
epic In an awlc rro1ccr, a •imple, h1gh-lcvel •caccmcnt of a requirement. Sec feature.
fact-finding The procc•s of pthcring rcquircmenr•. Sec requirement\ elicitation.
feature lo an agile pro1cc1, a sample, high-level staremem of a requirement. See epic.
fill ·in form A template used 10 collect data on the lmemet or a compan) intranet
functional dccornpo\ltion diagram (FOO) A top-down representation of husine'' function\ and pro·
ce..>;e<.. '"'"called a 'truccure chart.
functional requirement A 'taiement of rhe -;en ice, a ..ysrem providei..
H;m 1home Ufcc1 A phenomenon where emptor~ who know chey arc bemg obsef\ ed .ire more
producttvc.
histogram A ~ommon tool for showing rhe d1str1burion of quesrionna1re or sampling results. It take• 1he
form of a vcmcal bar charr.
informal \lructurc An organi73rion based on interpersonal relationships, which can develop from prcvi
ou~ work n~~ignmcnr~, physical rruximiry, unofficial procedures, or per~ona l rclation~ h ip>.
intcr"icw J\ planned meeting during which i11formario11 is obrnined from onorhcr pcr,011.
join1 applica1io11 dcvclopmcni UAD) A systems development tecb.aique !h.ir uses a rask force of users,
manager>. and IT profc>>tonal~ who work rogether to gather information, dii;cu~> bu;in~> n~cd>, and
define the new S)'Stcm requirements.
lcadtng qucsuons Queries th.11 suggcsr or fovor a particular reply.
non-fun<11onal requirement\ A sratemt'nt of operational sysrcm con~tramt~.
ob~cnauon A facr-fmd1n~ technique where an analrsr sees a system in dctton. Obsen·auon allow' th<'
veraficanon of statements made in interviews.
oix:n·cnded quc\lion~ Quenc> that allow for a range of answers. The)' encourage spontaneous and
umtru~1ured respon!>e> and are u..eful in under..canding a larger proces>.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 4
Requirements Engineering
140 Key Terms
pcl"Jonal information manager (PIM) A cool chac helps manage rnsks and schedules. Many handheld
devices also indude tlus luncuon.
pool Tiie merall d1a11ram 1n BPMN.
produ,,,, II) .,.,r''""" Applic:mons wc:h as word proce\~inµ, .,pread_~heec, dat.iba..., manaitemtnt, and
preo,cnranon 11raphic., program'>.
quahf) annbur~ Su non-functional requiremems.
quescionna1rc A document conrainmg a number of srandard questions that can be scnr co many individuals.
Also called a survey.
random ,ample A ~elecrion rnken in a random, unplanned manner. For example, a random \ample mighc
be n >ample char 'ele•"ts nny 20 cusromers.
rn1111.:-ur-re,pon'c quc\UOn> Closed-ended quescions that a>k the p<!r,un to evaluate >omctliing hy pm­
' id11111 limited an\wtr> to specific re,ponses or 011 a numeric >ca lc.
rapid .1pphca11on de,·clopment (RAD) A ream-based technique that speeds up mformA non sysrems developmcn1
.ind produces a funcrioniug information system. RAD is simil.1r in concept co JAL) buc goes
furrher by including all phases of che SDLC.
requirement~ definition~
A description of che sysrem requirements from the user's poinc of view.
rcquircmcnl\ elicitation The process of gathering requirement~. Sec f.tcJ-findinjl.
requirement\ engineering Used in rhe ~)'l>-Yem< planning pha-;e of rhe SDLC It involve; fact findini: m
de.,.ribl: the ~urrenr sy,rcm and identify rhe requirement> tor the new \)'.tcm.
rcquircmeng plnnning pb:ise A phase ch:u combines elements of the systems plJnrung Jnd systems Jn:1l­
)S1s phas~ or rhe SDLC.
rcqULremcnts •pcc1fica11ons A descnpnon of che system reqwremenrs from the Jnalyst or engineering
ceam's point of \1cw.
rc,c;irch ,\n imporranr fact-finding technique thar includes rhe review of journal~, periodicals, and
hook• m ohr:un h:ickgmund information, rechnical marenal, and new• about mdu-rf)' trends and
de• elopmenr~.
'an1plrnq A pr<><.-e" where an an:ilr<t colleas e'<ample, or a•-rual document,, wh1~h ~oul<l mdude
rc~urd,, report;, or variou~ fum1~.
scalab1l11~ A characrerisnc of a system, 101plying chat the S)'Slem can be expanded, modified, or downsized
cas1l) to mecr the rapidly changing needs of a business enrerpnse.
<ccnario< In an agile project, a real-world example of how users w1ll 10tcr.1ct wnh the system.
~rum ;\ popubr rechniquc for agile projecr managemcnr. Derived from a rugby rerm. In Scrum, rc~m
memhe~ play specific roles nnd interact in intense •es•ions.
\Cqucncc dia11rnm /\ UML diagram th3t 'hnws the riming of transaction~ between ohjccn, a' rhey occur
durin!I ~y~tcm execution.
~itc vis11 A mp 10 a physical location to observe a system Ln use at :1nocber location.
~1ra11ficJ
~ample A set memc 1s collected across fwJCtional ure:i>. l-ur example •• 1 ct'rr.1111 pcrccnrjge of
trnn~acrion< from every work shift, or five cusromers from cuch of four zip code~. could be a 'tr<uified
'ample.
'toryboard In an agile project, a simple graphic organi1er rhar helps system< ;in.ily~ts vi~ua l iu rhe •mtu'
of a project.
\tru~turcd br.iin\lorming A group discussion where each parricipant speab "hen it i> his or her tum or
~unc)
pas~'·
A dcxument conra1n10g a number of standard questioll!i rhat t:J.11 b.: .ent to mJny 111J1v1<lual>.
Also called a que~11onMirc.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

' I
I
I
Phase 2
Systems Analysis
Key Terms
I 4 1
swim lane> In .i bu•ine'; pr<><.e<>\ diagram, che overall diagram is called a pool and the des1gna1ed C:U>
tomer area> are c:alled >w1m !:inn.
S)s.\11 A dialect of U/\iL 2, used for representing requiremerus (and other thing;). pmn.inl) m .\IBSL
applications.
system rcqu1Ccment A charac1ens1ic or fe;irure that musr be included in an mformauon S) stem to sans!)
bu~ine~\ requirements and he accc-prable ro users.
'Y\lcma11c \ample A \ample char occur~ ac a predeccrmincd pcriodiciry. For example, every tenth cu<comcr
record mighr he sclccred a~ a sy~emaric sample for review.
wtal co-r of o"ncnh1p (TCO) A numhcr used in assessing cosrs, which include' ongoini; 'upporc and
mamcenance co\t' ,1, well 3> acquisinon cosr •.
uaceabi!Jty ·1 be Jbtht)' co follow a reqtmemellt backward to JtS ongms and forw.1rd through the SDLC
to link design documcnrs, code fragments, .rnd 1esr artifacrs.
Unified Modeling l anguagc (UMI ) A widely used method of visualizing and documenunp. softw,1rc systems
design. UML uses objccc-oricntcd design concepts. bur iris iudcpcndcnr of any specific programming
language and c.in be used 10 describe business processes and requiremcms generally.
un\lructurcd brain,turmini: A i:mup di~ussion where any parricipanr can speak at any time.
u_\e ca\c diagram A vi,ual repre~enrntion chac represenrs the inreracrion between u'er~ and the informati<>n
'Ystem in lJM L.
user d~ign ph.ise In tht> phase, users inter.1c1 with systems 3Jl:tlyscs and develop models and protott~
thdt represent all S)srtm processes, ourpurs, and inputs.
user stories In Jn agile pro1ecr, a ser of more refined requtremenrs derived from features.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 4
Requirements Engineering
142 Exercises
Exercises
Questions
I. \'(lhar is a srstem requiremenr and what are the three challenges it presents co the
S) stems analyst?
2. Is the requirement "The system shall respond within 2 seconds" a functional or
non-functional requirement?
3. What is scrum?
4. \'(lhar five questions typically are used in fact-finding?
5. Provide rhree examples each of closed-ended, open-ended, and range-of-response
questions.
6. Explain how the observation fact-finding technique works, including the
I lawthorne Effect.
7. Wh:it is rhe rel:irionship berween user stories and fcarures in :igi le projecrs?
8. What is an FDD and why would you use o ne?
9. What is the difference between validation and verificat ion of sysrem
requirement~?
10. Why is rraceabiliry important in tool support for requirements engineering?
Discussion Topics
I. JAD requires strong interpersonal and communicacion skills on the part of the
sysrems analyst. Are those skills different from che ones that an analy~r needs
when conducting one-to-one inten•iews? Explain your answer.
2. Agile methods use rapid development cycles to iteratively produce running versions
of the system. How would these shorrer cycles affect the abiliry of the analyst
ro manage sysrem requirements?
3. A group meeting sometimes is suggesred as a useful compromise bcrwccn mrerviews
and questionnaires. In a group meeting, a systems analysr meets with a
number of users at one time. Discuss the advantages and disadvantages of group
mccrin~.
4. Research the Internet, magazines, or textbooks co find examples of visual aids,
including a bar chart, pie chan, line chart, table, diagram, and bulleted lisr. How
effective was each example? Find at least one example char you could improve.
Explain your choice.
5. Traceability is an important requirements atcribute. lt'!> one of the things that
should be checked when performing V&V of the syMem requirements. Describe
how you would manually check traceability for an existing system and list a few
features of a CASE tool rhat you think wou ld help you with the task.
Projects
I. Use the requiremcncs gathering techniques of document review, observ:ition,
brainstorming, sampling, and research co capture the requirements of a typical
elevator control system. Use narural language and the UML to represent the siruauon
where people on different floors push the ''Up" button at the same time.
2. Prepare a presentation summarizing JAD and RAD. Explain how they differ
from traditional facr-finding merhods. What arc the m:iin advantages of teambased
methods?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

' I
I
I
Phase 2
Systems Analysis
Exercises
143
3. Design a questionnaire ro learn what srudenrs think of the registration process at
your school. Apply the guidelines you learned in this chapter.
4. Create an FDD similar to the one in Figure 4-15 but showing your school mstead
of the librar) example.
5. A desirable characteristic of a requirement is that it be borh consisrenr and complete.
Examine several requirements engineering CASE tools and document how
(if ar all) they support automated consistency analysis for validatmg :rnd verifying
requirement<;.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter S
Data and Process Modeling
Data and Process
Modeling
Chapter S is the second of four chapters in the systems
analysis phase of the SDLC. This chapter discusses
data and process modeling techniques that analysts use
to show how the system transforms data into useful
information. Data and process modeling involves three
main items: data flow diagrams, a data dictionary, and
process descriptions. The deliverable, or end produce,
of data and process modeling Is a logical model that will
support business operations and meet user needs.
The chapter includes three "Case in Point" discussion
questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the issue of how to respond to subtle but insistent
requests by an IT manager In a systems analyst's new
organization for proprietary information related to
the business processes used by the analyst's previous
employer. which is a competitor of the analyst's current
company.
LEARNING OB ECTIVES
W/Jen you finish tbis chapter, you sl101tld be able
to:
l. Describe rhe relarionship bcrween logical and
physical models
2. Explain data flow diagrams
3. Draw rhe four basic dara flow diagram symbols
4. Explain the si.~ guidelines used when drawing
data flow d1agr:ims
5. Draw context diagrams
6. Draw diagram 0 data flow diagrams
7. Draw lower-level darn flow diagrams
8. Explain how to level and balance data flow
diagrams
9. Create a darn dictionary
IO. Apply process description tools in modular
design
CONTENTS
5. 1 Logical Versus Physical Models
5.2 Data Flow Diagrams
5.3 Data Flow Diagram Symbols
5.4 Drawing Dara Flow Diagrams
5.5 Drawing a Context Diagram
5.6 Drawing a Diagram 0 01-D
5.7 Drawing Lower-Level DFDs
Case in Poinr 5.1: Big Ten Univcrsiry
5.8 Data Dictionary
5.9 Process Description Tools in Modular Design
Case in Point 5 .2: Rock olid Outfitrers (Parr 1)
Case in Point 5 .3: Rock Solid Outfitters (Part 2)
A Question of Ethics
5. 10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 2
Systems Analysis
5.2 Data Flow Diagrams
145
5.1 LOGICAL VERSUS PHYSICAL MODELS
During rhe requiremenrs engineering process described in Chaprer 4, face-finding
techniques were used ro invesrigare rhe currenr sysrem and idenrify user requirements.
Chaprcrs 5 and 6 explain how char information is used ro develop a logical model of
rhe proposed system and documenr the sysrem requirements. A logical model shows
what rhe sysrem musr do, regardless of how ir will be implemented physically. L1rer,
in rhe S)'Srems design phase, a physical model is built that describes how rhe system
will be consrrucred.
While srrucrured analysis cools are used ro develop a logical model for a new
informarion sysrem, such cools also can be used to develop physical model of an
information system. A physical model shows how rhe system's requirements are
implemented. During rhe systems design phase, a physical model of rhe new information
system •~created chat follows from the logical model and involves operational
tasks and techniques.
To undersrnnd rhe relationship between logical and physical models, think back
to rhe beginning of the systems analysis phase. To understand how the current tasks
were carried our in the existing system, the physical operations of the existing system
were studied before the logical model. Many systems analysts create a physical model
of rhe currem S)1srem and then develop a logical model of the currenr system before
tackling a logical model of the new system. Performing that extra step allows them to
understand rhe current system better.
Many analysts follow a four-model approach, which means that they develop a
physical model of the current system, a logical model of the current system, a logical
model of the new system, and a physical model of the new system. The major benefit
of the four-model approach is rhat it provides a clear picrure of current system
functions before any modifications or improvements are made. Thar is important
because misrakes made early in syscems de\•elopment will affect later SDLC phases
and can result in unhappy users and additional cosrs. Taking additional steps to
avoid these potentially costly mistakes can prO\'e to be weU worth the effort. Another
advantage is thar the requirements of a new information system often are quite
similar to those of rhe current information system. especially where the proposal is
based on new computer technology rather than a large number of new requirements.
Adapting the current system logical model to the new system logical model in these
cases is a straightforward process.
The only disadvantage of the four-model approach is the added rime and
cost needed to develop a logical and physical model of rhe current sysrem. Most
projects have very right schedules that might nor allow rime ro create the current
system models. Additionally, users and managers want ro see progress on rhe new
system-they are much less concerned about documenting the current sy:.tem.
The ~ystems analyst must stress the importance of careful documencation and
resist the pressure to hurry the development process at the risk of creating serious
problem:. later.
5.2 DATA f LOW DIAGRAMS
Systems analysts use many graphical techniques ro describe an information system.
One popular method is to draw a set of dara flow diagrams. A data flO\\ diagram
(DFD) uses various symbols to show how the system transforms input data into useful
informatton. Other graphical tools include object models, which are explamed in

Chapter S
Data and Process Modeling
146 5.3 Data Flo w Diagram Symbols
Chaprer 6 (Object Modeling), and enriry-relationship diagrams, which arc described
in Chapter 9 (Dara Design).
During the sysrems analysis phase of che SDLC, the systems anal)'St creates a
visual model of the information system using a set of OFDs. In his seminal book The
Visual Display of Quantitative 11(ormatio11, aurhor and renowned academic Edward
Tufte provides guidance on crearing effecrive diagrams to concisely convey complex
111formation. A DFD is an example of this rype of visual e'<planation of system
behavior.
A DFD shows how data moves through an inforrnanon system but does not show
program logic o r processing steps. A ser of DFDs provides a logical model that shows
what the system does, nor how ir does it. Thac discinction is important because focusing
on implementation issues at this point would restrict the search for the most effective
system design.
5.3 DATA FLOW DIAGRAM SYMBOLS
DFDs use fou r basic symbols that represent processes, data flows, data stores, and
entities. Several different versions of DFD symbols exist, but they all serve the same
pu rpose. DFD examples in this rexr use the Gane and Sarson symbol set. Another
popular symbol set is the Yourdon sym bol set. Figure 5- 1 shows examples of both
version'>. In this text, symbols are referenced using all capital letters for the symbol
name.
Gane and Sarson Symbols
Symbol Name
Yourdon Symbols
APPLY
PAYMENT
Process
APPLY
PAYMENT
BANK DEPOSIT
Data Flow
BANK DEPOSIT
I I
STUDENTS
Data Store
STUDENTS
CUSTOMER
External Entity
CUSTOMER
FIGURE S- 1 Data flow diagram symbols, symbol names, and examples of the Gane and
Sarson and Yourdon symbol sets.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.3 Data Flow Diagram Symbols
147
5.3.1 Process Symbols
A process receive input data and produces ourpur rhar has a different content, form,
or both. For instance, the process for calculating pay uses rwo inpurs (pay rate and
hours worked) to produce one output (total pay). Processes can be very simple or
quire complex. In a typical company, processes might include calculating sale trends,
filing online insurance claims, ordering inventory from a supplier's y tern, or verifying
email addresses for web customers. Processes contain the business logic, also
called busine s rules, that transforms the data and produces the required resulrs.
The symbol for a process 1s a rectangle with rounded comers. The name of the
process appears inside the rectangle. The process name identifies a specific function
and consists of a verb (and an adjective, if necessary) followed by a singular noun.
Examples of process names arc APPLY REl\lT PAYMENT, CALCULATE COMMIS­
SION, ASSIGN Fl Al GRADE, VERIFY ORDER, and FILL ORDER.
Processing derails arc nor sho,vn in a DFD. For example, there might be a process
named DEPOSIT PAYMENT. The process symbol does nor reveal the business logic
for the DEPOSIT PAYMENT process. To document the logic, a process description is
created, which is explained later in this cbapteL
In DFDs, a process symbol can be referred to as a black box, because the inputs, outputs,
and general functions of the process are knov.m, but the underlying details and logic
of the process arc hidden. By showing processes as black boxes, an analyst can create
DFDs that show how the system functions bur avoid unnecessary detail and clutter. When
the analyst wishes ro show additional levels of detail, he or she can zoom in on a process
symbol and creacc a more in-depth DFD that shows the process's inrernal workingswhich
mighr reveal even more processes, dara flows, and data stores. In this manner, the
information )'Stem can be modeled as a series of increasingly detailed picrures.
The network rourer shown in Figure 5-2 is an example of a black box. An
observer can see cables rhar carry data inro and ouc of the router, but rhe rourer's
internal operations are nor revealed-on!)' che results are apparent.
FIGURE 5·2 A router acts like a block box for network data. Cables
carry data In and out, but internal operations are hidden inside the case.
""' .. I'
5.3.2 Data Flow Symbols
A data flow is a path for data to move from one part of rhe information system to
another. A dara flow in a DFD rcpresenrs one or more data irems. For example, a daca
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
148 5.3 Data Flow Diagram Symbols
flow could consist of a single dara item (such as a student ID number), or it could
include a set of data (such as a class roster with student ID numbers, names, and
registration dates for a specific class). Although che DFD does not show the detailed
contents of a data flow, that information is included in the darn dictionary, which is
de'ICribcd later in this chapter.
The symbol for a data flow is a line with a single or double arrowhead. The data
flow name appears above, below, or alongside the line. A data flow name consists
of a singular noun and an adjective, if needed. Examples of dara flow names are
DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER, and COMMIS­
SION. Exceptions co the singular name rule are data flow names, such as GRADING
PARAMETERS, where a singular name could mislead the analyst into thinking a single
parameter or single icem of daca exists.
Figure 5-3 shows correct examples of data flow and process symbol
connections. Because a process changes rbe data's content or form, ar least one
data flow must enter and one data flow must exit each process symbol, as they
do in the CREATE rNVOICE process. A process symbol can have more than one
outgoing data flow, as shown 111 tbe GRADE STUDENT WORK process, or more
than one incomi ng data flow, as shown in the CALCULATE GROSS PAY process.
A process also can connect to any o ther symbol, including another process
symbol, as shown by the connection benveen VERIFY ORDER and ASSEMBLE
ORDER in Figure 5-3. A data flow, therefore, must have a process symbol on at
least one end.
SERVICES PERFORMED
CREATE
INVOCE
INVOICE
GRADED WORK
l­
o
w
a:
a:
0
0
SUBMITIED WORK
HOURS WORKED
PAY RATE
GRADE
STUDENT
WORK
CALCULATE
GROSS
PAY
STUDENT GRADE
GROSS PAY
ORDER
VERIFY
ORDER
ACCEPTED
ORDER
ASSEMBLE
ORDER
INVENTORY
CHANGE
FIGURE S-3 Examples of correct combinations or data flow and process symbols.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
S.3 Data Flow Diagram Symbols
149
Figure 5-4 shows three data Aow and process combinations that must be avoided:
• Spontaneous generation. The APPLY INSURANCE PREMIUM process, for
instance, produces output but has no input data flow. Because it has no input,
the proce s is called a spontaneous generation process.
• Black hole. CALCULATE GROSS PAY IS called a black hole process, which is a
proce&s that has input bur produces no output.
• Gray hole. A gray hole is a process that has ar least one input and one ourpur,
but the input obviously is insufficient to generate rhe output shown. For example,
a date of birth input is nor sufficient ro produce a final grade output in the
CALCULATE GRADE process.
Spontaneous generation, black holes, and gray holes are impossible logically in a
DFD because a process must act on input, shown by an incoming data flow, and produce
output, represented by an outgoing data flow.
S.3.3 Data Store Symbols
A data ~ tore is used in a DFD to represent
dara that the system stores because one or
more processes need to use the dara ar a
later time. For instance, instructors need to
store student scores on rests and assignments
during the semester, so they can assign final
grades at the end of the term. Similarly, a
company stores employee salary and deduction
data during the year in order ro print
\Y/-2 forms with total earnings and deductions
ar the end of rhe year. A DFD does nor
show the derailed contents of a data store-­
the specific structure and data elements are
defined in rhe dara dictionary, which is discus&ed
later in this chapter.
The phy ical characteristics of a daca &tore
are unimportant because the logical model
is the only concern at this point. Also, the
length of time that the data i~ ~tored i& unimportant-it
can be a matter of seconds while
a transaction is processed or a period of
months while data is accumulated for yearend
processing. What is important is that a
process needs access to the data at some later
APPLY
POLICY NUMBER INSURANCE PAYMENT AMOUNT
PREMIUM
HOURS WORKED
DATE OF BIRTH
CALCULATE
GROSS PAY
CALCULATE
GRADE
PAY RATE
FINAL GRADE
IFIGURE 5-'4 Examples of Incorrect combinations of data flow and
process symbols. APPLY INSURANCE PREMIUM has no input and is
called a spontaneous generation process. CALCULATE GROSS PAY has
no outputs and is called a black hole process. CALCULATE GRADE has
:an input that is obviously unable to produce the output. This process is
called a gray hole.
time.
In a DFD, rhc Gane and Sarson symbol for a data store is a flat rectangle that is
open on the right side and closed on the left side. The name of the data store appears
between the lines and idenrifies the data it contains. A data store name is a plural
name consisting of a noun and adjectives, if needed. Examples of data store names
arc STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS,
PURCI IASE ORDERS, OUTSTANDING CHECKS, INSURANCE POLICIES, and
EMPLOYEES. Exceptions to the plural name rule are coUective nouns that represent
multiple occurrences of objects. For example, GRADEBOOK represents a group of
students and their scores.
....
(.)
UJ
a:
a:
0
0
z

Chapter S
Data and Process Modeling
I SO
5.3 Data Flo w Diagram Symbols
A data store must be connected to a process with a data flow. Figure 5-5 illustrates
typical examples of data stores. Since data scores represent data storage for use by
another process in the furure, in each case, che data store has ac least one incoming
and one outgoing data flow and is connected to a process symbol wich a data flow.
POST
PAYMENT
CREATE
INVOICE
ADMIT
PATIENT
1-
u
w
a:
a:
0
DAILY
PAYMENTS
CUSTOMER
PAYMENT
u
DAI LY INVOICE
PAYMENT DETAIL
INVOICE
ACCOUNTS
RECEIVABLE
PAYMENT
DETAIL
ADMISSION
FORM
PATIENTS ·1
SYMPTOM
TREAT MENT
PREPARE
DEPOSIT
POST
PAYMENT
DIAGNOSE
PATIENT
TREAT
PATIENT
FIGURE 5-S Examples of correct use of dat:a ttore symbols in a dat:a flow diairam.
Violations of the rule that a data store must have at least one mcoming and one
outgoing data flow are shown in Figure 5-6. In che first example, rwo dara stores are
connected mcorrectly because no process 1s between them. Also, COURSES has no
incoming data flow and STUDENTS has no outgoing data flow. In the second and
rhird examples, rhe data stores lack either an outgoing or incoming data flow.
1-
u
w
a:
a:
0
u
z
COURSES
CLASS
LIST
I
POST
PAYMENT
CUSTOMER
PAYMENT
BOOK
FLIGHT
FLIGHT
RE OU EST
STUDENTS
I
DAILY
PAYMENTS
I
PASSENGERS
I
FIGURE S-6 Examples of incorrect use of data store symbols in a data flow diagram.Two data
stores cannot be connected by a data flow without an intervening process. and each data store
should have an ouigoing and incoming data flow.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.3 Data Flow Diagram Symbols 151
There is an exception to the requirement that a data store must have at least one
incoming and one outgoing data Aow. In some siruarions, a data store has no input
data Aow because it contains fixed reference data that is nor updated b)• the system.
For example, consider a data store called TAX TABLE, which contains withholding
ta-.: data that a company downloads from the Internal Re\•enue Service. When the company
runs its payroll, the CALCULATE \XflTHHOLDI G process accesses data from
this data store. On a DFD, this would be represented as a one-way outgomg data Aow
from rhe TAX TABLE data score into the CALCULATE WITHHOLD Ii G process.
5.3.4 Entity Symbols
T he symbol for an entity
is a rectangle, which may
be shaded to make ir look
three-dimensional. T he name
of the entity appears inside the
symbol.
A DFD shows only cxrernal
entities th:H provide data to rhe
sysrcm or receive output from
the system. A DrD shows the
boundaries of the system and
how the system interfaces with
the outside world. For example,
a cusromer enriry submits an
order to an order processing
system. Other examples of
entiti~ include a patient who
supplie~ data to a medical
record~ sy~tem, a homeowner
who receives a bill from a ciry
property tax S)•Mem, or an
accouncs payable system that
receives data from the compan)•'s
purchasing system.
DFD entities also are called
terminator) because they are
data origins or final dcsrin:irions.
Systems analysts call an enriry
that supplies data to rhe system
a source and an enriry that
receives data from the system
a sink. An enriry name is the
singular form of a dcparm1ent,
an outside organiz;:irion, other
information system, or a person.
An external entity can be a
source or a sink or both, bur
each entiry must be connected
ro a process by :i d:ita Aow.
Figure 5-7 and Figure 5-8 show
correct and incorrect e-.::imples
of this rule, re pecrively.
l­
o
w
a:
a:
0
CUSTOMER
APPLY
PAYMENT
VERIFY
TIME
CARD
PAYMENT
BANK
PREPARE
DEPOSIT
BANK
DEPOSIT
ORDER
CUSTOMER
VERIFY
ORDER
INVOIC E
TIME
CARO PAYCHECK CREATE
EMPLOYEE
PAYCHEC1<
FIGURE 5-7 Examples of correct uses of e>nemal entitles on a cnu flow diagr.tm.
PAYROLL
DEPARTMENT
CUSTOMER
BANK
I-
0 w
PAYCHEC K
a:
PAYMENT BANK
DEPOSIT
a:
0
0
z
ACCOUNTS DAILY
RECEIVABLE
PAYMENTS
EMPLOYEE
FIGURE 5-8 Examples of incorrect uses of external ent1t1es on a cnu flow doagr.tm. An
external entity must be connected by a cnca flow to a process and not directly to a data store
or co another external entity.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I

Chapter S
Data and Process Modeling
152 5.4 Drawing Dae.a Flow Diagrams
S.3.S Using DFD Symbols
\'<'ith an undersranding of the proper use of DFD symbols, the next step is co construct
diagrams chat use these symbols. Figure 5-9 shows a summary of the rules for
using DFD symbols.
Correct and Incorrect Examples of Data Rows
LJ LJ
Process
to Process
./
LJ D
Process
to External Entity
./
LJ
Process to Data Store
I I ./
- '·
D D x
External Entity to External Enllty
D
I I
External Entity to Data Store
x
'-I I I I
Data Store to Data Store
x
FIGURE S-9 Examples of correct and incorrect uses of data flows.
5.4 DRAWING DATA fLOW DIAGRAMS
During requirements engineering, interviews, questionnaires, and ocher techniques
were used to gather facts about the system, and it was explained how the various
people, departments, data, and processes fit together to support business operations.
Now a grnphical model of the information system is created based on the fact-finding
results.
To learn how to draw DFDs, examples of two information systems will be used.
The first example is a grading system rhat instructors use co assign final grades based
on the scores that students receive during the term. The second example is an order
system that a company uses to enter orders and apply payments against a customer's
balance.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
S.4 Drawing Data Flow Diagrams
153
When drawing a context diagram and other DFDs, these guidelines should be
followed:
• Draw the context diagram so it firs on one page.
• Use the name of the infonnarion system as the process name in the context diagram.
For example, the process name in Figure 5-10 1s GRAD! G YSTEM.
, ore that rhe process name is the same as the system name. This is because
the conte>.t diagram shows rhe entire information system as if it were a single
proce!.s. For processes in lower-level DFDs, use a verb followed by a de criptl\e
noun, such as ESTABLISH GRADEBOOK, ASSIG FINAL GRADE, or PRO­
DUCE GRADE REPORT.
• Use unique names within each ser of symbols. For instance, the diagram in
Figure 5-10 shows only one enrity named STUDENT and only one data flow
named FINAL GRADE. Whenever the entity STUDENT appears on any other
DFD in the grading S)'Stem, ir indicares that it is the same entity. Whenever the
FINAL GRADE data Aow appears, it indicates that ir is rhc same dara flow.
The naming convention also applies to data stores.
• Do not cross lines. One way to achieve that goal is to restrict the number of
symbols in any DFD. On lower-level diagrams with multiple processes, there
should not be more than nine process symbols. Including more than nine symbols
usually is a signa l that rhe diagram is too complex and that the analysis
should be reconsidered. Another way to avoid crossing lines is to duplicate an
entity or a data store. When duplicating a symbol on a diagram, make sure
to document rhc duplicarion to avoid possible confusion. A special notation,
such as an asterisk, nexr to rhe symbol name and inside rhe duplicated symbols
signifies that they are duplicared on the diagram.
STUDENT
RECORDS
SYSTEM
FINAL
GRADE
SUBMITTED
WORK
STUDENT
o ...
CLASS ...... GRADED
ROSTER ~ WORK
GRADING
SYSTEM
process o
represents lhe .
entire gred1ng sys1em
GRADING
PARAMETERS
'
'
GRADE REPORT
unique reference
number for
each process
INSTRUCTOR
FIGURE 5- 10 Context diagram DFD for a grading system.

Chapter S
Data and Process Modeling
I 54
5.5 Drawing a Context Diagram
• Provide a unique name and reference nlLmber for each process. Because it is the
highesr-levcl DFD, the contexr diagram concains process 0, which repre encs
the entire infonnacion sysrem, bur does not show the incernal workings. To
de~cribe the next level of detail inside process 0, create a DFD named diagram 0,
which will reveal additional processes thar must be named and numbered. As
lower-level DFDs are created, assign unique names and reference numbers to
all processes, until che logical model is completed.
• Obtain as much user input and feedback as possible. TI1e main objective is to ensure
that the model is accurate, is easy co understand, and meets the needs of its users.
5.5 DRAWING A CONTEXT DIAGRAM
The first srep in constructing a set of DFDs is co draw a context diagram. A context
diagram is a rop-level view of an information system that shows the sysrem's boundaries
and scope. To draw a context diagram, stare by placing a single process symbol in rhe
center of the page. Tbe symbol repres·ents the entire information system, and ir is identified
as process 0 (the numeral zero, and nor tbe letter 0). Then place the S)•Stcm entiries
around the perimeter of the page and use data flows to connect the enriries to the central
process. Data stores are not shown in the concext diagram because they arc contained
within the system and remain hidden until more detailed diagrams are created.
To determine which entities and data flows to place in the context diagram, begin
by reviewing the system requirements to identify aU external data sources and desti·
nations. During that process, identify the entities, the name and content of rhe data
flows, and the direcrion of the data flows. If that is done carefully, and rhe job of
fact-finding was done well in the previous stage, drawing the context diagram should
be relatively easy. !'\ow review the following context diagram examples.
EXAMPLE: CONTEXT DIAGRAM FORA GRADING SYSTEM: The context diagram
for a grading ~ystem is shown in Figure 5- 10. The GRADING SY TEM process is at
the center of the diagram. The three entities (STUDE 'T RECORDS SYSTE~1, STU­
DE :T, and INSTRUCTOR) are placed around the central process. lnreracrion among
rhe cencral process and the entities involves six different data flows. The TUDENT
RECORDS SYSTEM entity supplies dara through rhe CLASS ROSTER daca flow
and receives darn chrough che flNAL GRADE daca flow. The STUDENT enciry supplies
dara through the SUBMITTED WORK data flow and receives data through the
GRADED \VORK data flow. Finally, che INSTRUCTOR entiry supplies data through
rhe GRADING PARAMETERS data flow and receives daca through the GRADE
REPORT data flow.
EXAMPLE: CONTEXT DIAGRAM FORAN ORDER SYSTEM: The context diagram
for an order system is shown in Figure 5-11. Note chat the ORDER SYSTEM process
is at the center of the diagram and five entities surround the process. Three of the
entities, SALES REP, BANK, and ACCOUNTING, have single incoming data flows
for COMMISSION, BANK DEPOSIT, and CASH RECEIPTS ENTRY, respectively.
The WARE! IOUSE entity has one incoming data flow-PICKING LIST-char is,
a report chat shows the items ordered and their quantity, location, and sequence to
pick from the warehouse. T he WAREHOUSE entity has one outgoing data flow:
COtvlPLETED ORDER. Finally, the CUSTOMER entity has two outgoing data flows,
O RDER and PAYMENT, and rwo incoming data flows, ORDER REJECT OTICE
and INVOICE.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.6 Drawing a Diagram 0 DFD
155
CUSTOMER
ORDER
- PICKING
ORDER UST
REJECT
NOTICE
WAREHOUSE
INVOICE 0
PAYMENT
ORDER
SYSTEM
COMPLETED
ORDER
CASH
BANK
RECEIP TS
COMMISSION DEPOSIT ENTRY
SALES
REP
BANK
ACCOUNTING
FIGURE S· 11 C.:.nte>n diagram DFD for an order system.
The context diagram for the order system appears more complex than the grading
sy~cem becau1.e tt has two more entities and three more data flows. What makes one
~y~tcm more complex than another is the number of components, the number of levels,
and the degree of interaction among irs processes, entities, data stores, and data flows.
5.6 DRAWING A DIAGRAM 0 DFD
In the previous step, it was explained how a context diagram provides the most
general view of an information S)'Stem and contains a single process symbol, which is
like a black box. To show rhe derail inside the black box, a DFD diagram 0 is created.
Diagram 0 (the numeral zero, and not che letter 0 ) provides an overview of all the
components that interact to form the overall system. lt zooms in on the system and
shows major internal processes, dara flows, and data scores. Diagram 0 also repeats
the entities and data flows rhar appear in the context diagram. When the context diagram
is expanded into DFD diagram 0, all the connections that flow into and out of
process 0 must he retained.
EXAMPLE: DIAGRAM 0 DFD FOR A GRADING SYSTEM: Figure 5- I 2 shows a
context diagram ar rhe top and diagram 0 beneath it. Note that diagram 0 is an
expansion of process 0. Also note chat the three same entities (STUDENT RECORDS
SYSTEt.1, STUDENT, and I STRUCTOR) and che same six data flows (FINAL
GRADE, CLASS ROSTER, SUBMITTED WORK, GRADED ~'ORK, GRADING
PARAMETERS, and GRADE REPORT) appear in both diagram!>. In addition,
diagram 0 expands process 0 to reveal four internal processes, one data store, and
fi,·e additional data flows.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
156
5.6 Drawing a Diagram 0 DFD
Conlexl Diagram for Grading System
STUDENT
RECORDS
SYSTEM
FINAL
GRADE
SUBMITTED
WORK
STUDENT
CLASS
ROSTER
0
GRADING
SYSTEM
GRADED
WORK
GRADING
PARAMETERS
•
GRADE
REPORT
INSTRUCTOR
Diagram 0 for Grading Syslem
STUDENT
RECORDS
SYSTEM
2
ASSIGN
FINAL
GRADE
STUDENT
GRADE
3
GRADE
STUDENT
WORK
FINAL
CLASS GRADE GRADING
ROSTER
DETAIL
SUBMITTED
WORK
GRA OED
WOR K
1
ESTABLISH
GRADEBOOK
CLASS
GRADEBOOK
01 GRADEBOOK
I
STUDENT
GRADING
PARAMETERS
4
CLASS
DETAIL
INSTRUCTOR
GRADE
REPORT
PRODUCE
GRADE
REPORT
F IGURE 5- 12 Context diagram and d~gram 0 for the grading system.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.6 Drawing a Diagram 0 DFD
157
Note that each process in diagram 0 has a reference number: ESTABLISH
GRADEBOOK is I, ASSIGN FlNAL GRADE is 2, GRADE STUDENT \X!ORK is
3, and PRODUCF GRADF REPORT is 4. These reference numbers are important
because the)' identify a cries of DFDs. If more detail were needed for ESTABLISH
GRADEBOOK, for example, a diagram 1 would be drawn, because ESTABLISH
GRADEBOOK is process 1.
The process numbers do nor suggest char the processes are accomplished in a
sequennal order. Each process always is considered ro be available, active, and awaiting
data co be processed. If processes musr be performed in a specific sequence, the
information should be documented in the process descriptions (discussed later in this
chapter), nor in the DFD.
The FINAL GRADE data flow output from the ASSIG FINAL GRADE process
is a diverging data Aow that becomes an input to the STUDENT RECORDS SYS­
TEM entity and co the GRADEBOOK data store. A diverging data Aow is a data Aow
iu which the same data travels to rwo or more diHereot locations. l11 that situation, a
diverging data Aow is the best way ro show the flow rather than showing rwo identical
data flows, which could be misleading.
If the same data flows in borb directions, a double-headed arrow can be used to
connect the symbols. To identify specific data flows into and out of a symbol, however,
separate data Aow symbols with single arrowheads should be used. For example,
in Figure 5-12, the separate data flows (SUBMIITED WORK and GRADED WORK)
go into and out of rhe GRADE STUDENT WORK process.
Because diagram 0 is an exploded version of process 0, it shows considerably more
derail than the context diagram. Diagram 0 can also be referred ro as a partitioned
or decomposed view of process 0. When a DFD is exploded, the higher-level diagram
is called the parent diagram and the lower-level diagram is referred to as the child
diagram. The grading system is simple enough that no additional DFDs arc needed
to model che syscem. At chat point, che four processes, the one data score, and the I 0
data Aow can be documented in the data dictionary.
\Xlhen a sec of Of'Ds is created for a system, the processing logic is broken down mto
smaller units, called functional primitives, which programmers will use co de\'elop code.
A functional prinuci"e is a process that consists of a single function rhat 1s not exploded
further. for e'<ample, each of the four processes shown in the lower portion of Figure
5-12 is :i functional prnninve. The logic for a functional primitive is documented by
wriong a proce!.s description in the data dictionary. Later, when the logical design is
implemented as a physical system, programmers wiJJ transform e:ich function:il primitive
into program code and modules that carry our the required steps. Deciding whether
to explode a process further or determine that it is a functional primitive is a marcer of
experience, judgment, and inceraction with programmers who musL translaLe the logical
design imo code.
EXAMPLE: DIAGRAM 0 DFD FORAN ORDER SYSTEM: Figure 5-13 is the diagram
0 for an order system. Process 0 o n the order system's context diagram is exploded to
reveal three processes (FILL ORDER, CREATE INVOICE, and APPLY PAYMENT},
one data store (ACCOUNTS RECEIVABLE), two additional data flows (INVOICE
DETAIL and PAYMENT DETAIL), and one diverging data Aow (lNVOICE).
The following walk-through explains the DFD shown in Figure 5- 13:
L A CUSTOMER submits an ORDER. Depending on the processing logic, che
FILL ORDER process either sends an ORDER REJECT NOTlCE back to rhc
customer or sends a PICKING LIST to the WAREHOUSE.
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~ --- - ·· · ---~~-.,.- "~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,. .., ~..,._.. .............. ~ ..

Chapter S
Data and Process Modeling
158 5.7 Drawing Lower-Level DFDs
2. A COMPLFTED ORDER from rhe \'V'AREHOUSE is inpur ro rhc CREATE
INVOICE process, which ourpurs an INVOICE ro borh rhe CUSTOMER
process and rhe ACCOUNTS RECEIVABLE dara store.
3. A CUST01'1ER makes a PAY1vl8'.T that is processed by APPLY PAYMENT.
APPLY PAYMENT requires INVOICE DETAIL input from rhe ACCOUNTS
RECEIVABLE dara store along with the PAY1'1ENT. APPLY PAYMENT also
ourpurs PAY1'1ENT DETAIL back to the ACCOill'.iS RECEIVABLE dara
store and ourpurs COMMlSSION ro the SALES DEPT, BANK DEPOSIT ro the
BANK, and CASH RECEIPTS ENTRY ro ACCOUNTING.
ORDER
1
FILL
ORDER
PICKING
UST
CUSTOMER
ORDER
REJECT
NOTICE
WAREHOUSE
INVOICE
2
CREATE
INVOICE
COMPLETED
ORDER
DI ACCOUNTS
RECEIVABLE
INVOICE
DETAIL 3
PAYMENT
DETAIL
PAYMENT
COMM,SSION
APPLY
PAYMENT
BANK
DEPOSIT
CASH
RECEIPTS
ENTRY
SALES
DEPT
BANK
ACCOUNTING
FIGURE S- 13 Diagram 0 DfD for the order system.
The walk-through of diagram 0 iUustrates the basic requirements of the order
system. Examine the detailed description of each separate process to learn more.
S. 7 DRAWING LowER-LEVEL DFDs
This set of lower-level DFDs is based on the order system. To creace lower-level diagrams,
leveling and balancing techniques must be used. Leveling is rhe process of drawing a
series of increasingly detailed diagrams, until all functional primicives are identified.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.7 Drawing Lower-Level DFDs
159
Balancing mainrains consistency among a set of DFDs by ensuring that input and output
dam flows align properly. Leveling and balancing are described in more derail in the following
sections.
EX AMPLE: LEVELING EXAMPLES: Leveling uses a series of increasingly derailed
DFDs to de&cnbe an information S)'stem. For example, a system might consist of
doi.ens, or even hundreds, of separate processes. Using leveling, an analyst scares
with an overall view, which is a context diagram with a single process symbol.
Next, the analyst creates diagram 0, which sho,vs more detail. The analyst contmues
to create lower-level DFDs until all processes are identified as functional
primitives, which represent single processing functions. More complex systems
have more processes, and analysts must work through many levels to identify
the functional primitives. Leveling also is called exploding, partitioning, or
decomposing.
Figures 5-13 and 5-1 4 provide an example of leveling. Figure 5-13 shows diagram
0 for an order system, with the FILL ORDER process labeled as process 1. Now
consider Figure 5- 14, which provides an exploded view of the RLL O RDER process.
Note rhat FILL ORDER (process l ) actually consists of three processes: VERIFY
O RDER (process 1. 1 ), PREPA RE REJECT NOTICE (process L.2), and ASSEMBLE
ORDER (process 1.3).
CUSTOMER
ORDER
ORDER
REJECT
NOTICE
1.1 I 2
PREPARE
VERIFY
REJECT
ORDER REJECTED NOTICE
PRODUCT
ORDER
DETAIL CREDIT I
STATUS
ACCEPTED
ORDER D2 CUSTOMERS
CREDIT
HISTORY
I
1.3
PICKING
PICKING
DETAIL
LIST
D3 PRODUCTS ASSEMBLE
WAREHOUSE
ORDER
INVENTORY
CHANGE
FIGURE S-14 Diigram I OFD shows details of the FILL ORDER process in the order system.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
160 5.7 Drawing Lower-Level DFDs
As Figure 5-14 shows, all processes are numbered using a decimal notation
consisting of the parent's reference number, a decimal point, and a sequence number
within the new diagram. In Figure 5-14, the parent process of diagram I 1 process I, so
the proces cs in diagram 1 have reference numbers of 1.1, 1.2, and I. 3. If process 1.3,
ASSE~ I BLE ORDER, is decomposed further, then it would appear in diagram 1.3 and
the processe!> in diagram 1.3 would be numbered as 1.3.1, 1.3.2, I. 3.3, and so on.
This numbering technique makes it easy to integrate and idenrify all DFDs.
\'Qhen Figure 5- 13 and Figure 5-14 are compared, it is apparent that Figure 5-14
(the exploded FILL ORDER process) shows two data stores (CUSTOMER and
PRODUCTS) that do nor appear on Figure 5-13, which is rhe parent DFD. Why not?
Tiie answer is based on a simple rule: When drawing DFDs, a data store is shown
only when rwo or more processes use that data store. The CUSTOMER and PROD­
UCTS data stores were internal to rbe FILL ORDER process, so the analyst did not
show chem on diagram 0, which is the parent. When the FILL ORDER process is
exploded into a diagram 1 DFD, however, three processes ( l.J, 1.2, and 1.3) interacting
with the two data stores are now shown.
Now compare Figure 5-14 and Figure 5-15. Note that Figure 5-15 shows the same
data flows as Figure 5-14 but does not sbow tbe CUSTOMER and WAREH OUSE
entities. Analysts often use this technique to simplify a DFD and reduce unnecessary
cluner. Because the missing symbols appear on the parent DFD, that diagram can be
used to identify rhc source or destination of rhe data flows.
•
ORDER
ORDER
REJECT
NOTICE
1 1 1.2
PREPARE
VERIFY
REJECT
ORDER REJECTED NOTICE
ORDER
PRODUCT
DETAIL CREDIT
I
STATUS
ACCEPTED
ORDER
D2 CUSTOMERS
CREDIT
HISTORY
I
1.3
D3
PRODUCTS
PICKING
DETAIL
ASSEMBLE
ORDER
PICKING
UST
INVENTORY
CHANGE
FIGURE 5-15 This diagram does not show the symbols that connect to data flows entering or leaving
FILL ORDER on the context diagram.
BALANCING EXAMPLES: Balancing ensures that the input and output data flows
of the parent DFD are maintained on the chjld DFD. For example, Figure 5- 16 shows
two 0 1- D : The order S)•stem diagram 0 is shown at the cop of che figure, and the
exploded diagram 3 DFD is shown ac the bottom.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.7 Drawing Lower-Level DFDs
161
The rwo DFDs arc balanced because the child diagram at the bottom has the
same input and output Aows as rhe parent process 3 shown ar the top. To verify rhe
Order System Diagram O DFD ,
ORlJEA
flil
ORDER
P<CKING
UST
CUSTOMER
ORDER
REJECT
NOTICE
I
WAREHOUSE
INVOICE
I D1 I ACCOUNTS
2
CREATE
INVOCE
COMPLETED
ORDER
I
RECEIVABLE
-- -""
ll"YMENT
DETAIL
INVOICEf
DETAIL 3
I
.
PAYMENT
-
I
APF'\.Y
COMMISSION
-
PAYMENT I
•
' - -i ' !!AN!!'
DEPOSIT
CASH
RECEIPTS
ENTRY
SAlES !IANJ( ACCOUl"1"NO
DEPT
Order System Diagram 3 DFD
I
I
I
I
I
I
I
CVS TOMER
1NllOICE
DEll'&. ID' ACCOU'<TS
I
, - - - t I RECEIVAlll.E I
I
31
' PAYMENT
I
I
POST I
PAYMENT I PAYUENT I
I \
OET.tJL
-- - - - - - - ,, - - - - - .. - --...
CUSTOt.IER
DAILY
PAYMENT
1
I
"'I
32 33
PAYMENT
tw1.Y OOMMISS
AAl'MENTS
EARNED
ACCOUNT1NG
PAYMENT
PREPAA£
DEPOSIT
ACCOUNTING
I
..
PAYMENT ENTRY
I
- 1 BANK - -----
~
DEPOSIT
RECEIPTS ENTRY
<.'Xst-1'" ---
H
ION
I
I
I
I
I
I
I
I
PAY
COMMISSION
- - -
i~: ss~ ON
BAM<
ACCOIJNf,NG
SALES
REP
FIGURE S- 16 The order system diagram 0 is shown at the top of the figure. and the exploded diagram 3 DFD
(for the APPLY PAYMENT process) is shown at the boaom.The two DFDs are balanced because the child diagram
at the bottom has the same Input and output flows as the p;arent process 3 shown at top.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
162 5.7 Drawing Lower-Level DFDs
balancing, note that the parent process 3, APPLY PAYMENT, has one incoming dara
flow from an external enriry and three outgoing data flows to external entities. Fxamine
the child DFD, which is diagram 3. Ignore the internal data flows and count the
data flows co and from external entities. From the diagram, it is evident chat the three
processes maintain the same one incoming and three outgoing data flows as the parent
process.
Another example of balancing is shown in Figures 5-17 and 5-18. l11e DFDs in
the e figures were created using the Visible Analyst CASE tool.
Figure 5-17 shows a sample concext diagram. The process 0 symbol has cwo input
flows and two output flows. Note char process 0 can be considered as a black box
... uo.c ..,. .... ,," ' T
• I• 1-.
EXTERNAL INPUT DATA OUTPUT DATA EXTERNAL
ENTITY A FLOW1
-----
FLOW 1 ENTITY C
1 .
I
I
I
I OUTPUT DATA
INPUT DATA
I PROCESSO
FLOW2
I FLOW2
I .
• •
EXTERNAL
EXTERNAL
ENTITY B
ENTITY D
FIGURE 5- 17 Examples of a parent DFD diagram. showing process 0 as a black box.
t;.iJ ¥ lol A I A -. :& J•I • \ !:J-Q'l.-"l"\ '- "T.l
•- wJ "~I -' • •
----------------,
3
I
1
I INPUT DATA UT OATA I
-
EXTERNAL • FLOW I FLOW I I EXTERNAL
ENTITY A PROCESS 1 PROCESS3
ENTITYC
I
' I
I
I INTERNAL INTERNAL I
DATA DATA
I
I
FLOW1
.
FLOW2
I
I 1041 DATA STORE 1 los DATA STORE 2 I
I
I
INTERNAL
INTERNAL
I DATA DATA
I
FLOW3 FLOW4
I
I
I 2 I
INPUT DATA
OUTPUT DATA
I
EXTERNAL I FLOW 2 FLOW 2
EXTERNAL
ENTITY 8 I PROCESS2
•
ENTITY 0
I
'
----------~----- I
FIGURE 5- 18 In the next level of detail. the process 0 black box reveals three processes, tw0 <ba scores, and
four internal data ffows---gll of which are shown inside the dashed line.
I
(....,..... J:gl( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
S.7 D raw ing Lower-Level DFDs
163
with no inrernal derail shown. In Figure 5-18, process 0 (che parent DFO) is exploded
inro rhe nexr level of detail. Now rhree processes, rwo dara scores, and four inrernal
dara Aows are visible. Note that the derails of process 0 are shown inside a dashed
line, 1ust as if the inside of the process was visible.
The DFDs in Figures 5-17 and 5-18 are balanced because rhe four data flows into
and out of process 0 are maintained on the child DFD. The DFDs also are leveled
because each internal process 1s numbered co show that it is a child of the parent
process.
CASE IN POINT 5.1:
B1G TEN U N1VERs1n'
You are the IT director at Big Ten University.As part of a training program, you decide to draw
a DFD that includes some obvious mistakes to see whether your newly hired junior analysts
can find them.You came up with the diagram 0 DFD shown in Figure 5-19. Based on the rules
explained in this chapter, how many problems should the analysts find?
1 2 3
STUDENT ID
TENTATIVE
MEET
CHECK
NUMBER
SCHEDULE
ASSIGN
WITH
OPEN
AO\llSOR AOlllSOR CLASSES
FINAL
CLASS
SCHEDULE
INSTRUCTOR
CLASS
ROSTER
05 CLASS ROSTER
STUDENTS
ATTENDING
SCHEDULE
OF OFFICE
HOURS
D6 SEATING C HART
4
STUDENT ID
FINAL
NUMBER CALCULATE GRADE
STUDENT GRADE 04 GRADES
FIGURE 5- 19 What are the mistakes in this diagram 0 DFD!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter S
Data and Process Modeling
164 5.8 Data Dictionary
5.8 DATA DICTIONARY
A set of DFDs produces a logical model of the system, but the details within those
DFDs are documented separarely in a data dictionary, which is the second component
of stn1crurcd analysis.
A data dictionary, or data repository, is a ccnrral storehouse of information about
the system's data. An analyst uses rhe data dictionary to collect, document, and
organi1c specific facts about the system, including the contents of data flows, data
stores, entities, and processes. The data d ictionary also defines and describes all data
elements and meaningful combinarions of dara elements. A data clcmcnr, also called
a data item or field, is che smallest piece of dara that has meaning within an information
system. Examples of data elements are student grade, salary, Social ccurity number,
account balance, and company name. Dara elements are combined into records,
also called daLa structures. A record is a meaningful combination of related data elements
that is included in a data flow or ret:iined in a data score. For example, an auto
parts store inventory record might irnclude part number, description, su pplier code,
minimum and maximum stock levels, cost, and list price.
Significant relationships exist among the items in a data diction~iry. For example,
darn stores and data flows are based on data structures, which in rurn are composed
of data clements. Data flows are connected to data stores, entiLies, and processes.
Accurately documenting these relationships is essential so the data dictionary is consistent
with the DFDs. The more complex the system, the more d ifficult it is co maintain
fu ll and accurate documentation. Fortunately, modern CASE tools simplify the
task by flowing documentation automatically from the modeling diagrams into the
central repository, along with information entered by the user.
A CASE repository ensures data consistency, which is especially imporranc where
multiple srsrems require the same data. In a large company, for example, the sales,
accounting, and shipping systems all might use a data element called CUSTOMER
NU.tvlBER. Once the CUSTOMER NUMBER element has been defined in the repository,
other processes can access it, data flows, and data stores. The result is that all
sysrems across the enterprise can share data that is up to date and consistent.
5.8. 1 Documenting the Data Elements
Every dara element in the dara dictionary muse be documented. Some analysts like to
record their notes in online or manual forms. Ochers prefer ro enter rhe information
directly inro a CASE rool. Irrespective of the specific CASE tool used, rhc objecrive is
the same: ro provide clear, comprehensive information about the data and processes
rhat make up the system.
Figure 5-20 shows a sample screen that illustrates how a data element representing
o SOCIAL SECURITY NU.tvlBER might be recorded in the Visible Analyst dara dictionary.
Regardless of the terminology or method, the following attributes usually arc
recorded and described in the data dictionary:
• Data element name or label. The data element's standard name, which should
be meaningful to users.
• Alias. Any name(s) other than the standard darn element name; this Jlternate
name is called an alias. For example, if there is a dat:i element named
CURRENT BALANCE, various users might refer to it by alternate names such
as OUTSTANDING BALANCE, CUSTOMER BALANCE, RECEIVABLE
BALANCE, or AMOUNT OWED.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
S.8 Data Dictionary
165
• Type and length. Type refers ro
whether chc data element conrains
numeric, alphabetic, or character values.
Length 1s the maximum number
of character~ for an alphabetic or a
character data element or the maximum
number of digits and number
of decimal posirions for a numeric
data element. In addition to text and
numeric data, sounds and images
also can be stored in digital form.
In some systems, these binary data
objects are m:inaged and processed
just as traditional data clements are.
for example, an employee record
might include u digitized photo
image of the person.
• Default 11al11c. The default value is the
value for the data clemenr if a value
otherwise is not entered for it. For
example, all new cu~tomers might
have a default value of $500 for the
CREDIT LIMIT data element.
• Acceptable t•al11es. Spccificarion of
the data element's domain, which is
the set of values permitted for rhe
data element. These values either can
i.w I SOCIAi. sicUltl'TY NUMlllJt I of4
Enbybpc
~ 1-s.a..cy-
A!Us: SSH
:::===:::___
\/oJues & TJ!I< n lengsh: !IN
~ O.twlt.- None
Acc.-- Mf-"'9'1--
Notes; 5oufCC Appl1c1tton rorm
Sttun1y Pl)"Oll dq>tnmonl
long Nome:
R"'f>O"sib~ \Ml". PoyniH d~l
A rtOO!bi't objt<t llbfl an bt uP to 128 ctilrxt11s ID!lo. Jlld tllt Int c:IQ/xtt1 l'l\&St bt
• mtter.
FIGURE S-20 A VlsibleA!Qlyst screen describes the data element named
SOCIAL SECURITY NUMBER.
be specifically listed or referenced
in a table or can be selected from a -~....- -,,.- l
specified range of values. Also indicare if a value for the data element 1s optional.
Some data clements have additional validity rules. For example, an emplo)'cc's
salary musr he within the range defined for rhe employee's job classification.
• Source. The specification for the origination point for the data element's values.
The source could be a specific form, a depam11ent or an outside organization,
another information system, or rhe result of a calculation.
• Security. Identification for the individual or department that has access or
update privileges for each data clement. For example, only a credit manager
has the aurhority to change a credit limit, while sales reps are authorized co
access dara in a read-only mode.
• Responsible 11ser(s). Identification of the user(s} responsible for entering and
changing values for the data clement.
• Description and comments. This part of the documentation permits che entry
of addirional norcs.
S.8.2 Documenting the Data Flows
In addirion to documenring each dara elcmenr, all data flows in the data dicrionary
must be documented. Alrhough terms can vary, the typical attribures arc as follows:
• Data flow 11ame or label. The data flow name as it appears on che DFDs.
• Description. Describes the data flow and irs purpose.
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..
-

Chapter S
Data and Process Modeling
166 5.8 Data Dictionary
• Alternate name(s). Aliases for che DFD dara flow name(s).
• Origin. The DFD beginning, or source, for che dara flow; the origin can be a
process, a dara score, or an entiry.
• Destmation. The DFD ending poinc(s) for the dara flow; che destinarion can be
a process, a dara store, or an entiry.
• Record. Each daca flow represents a group of related dara elements called a
record or data srrucrure. Ln mosc data dictionarie~. records are defined separately
from the data flows and data scores. When records are defined, more
than one data flow or data store can use the same record, if necessary.
• Volume and frequency. Describes the expected number of occurrences for che
data flow per unic of time. For example, if a company has 300 employees, a
T IME. CARD dara flow would involve 300 transactions and records each week
as employees submit their work hour darn.
5.8.3 Documenting the Data Stores
every DrD data srore in rhe data dicrionary must be documented. Figure 5-21 shows
che definition of a data score named lN STOCK. Typical characteristics of a darn store
a re as follows:
• Data store name or label. The dara store name as it appears on the DFDs.
• Description. Describes the data srore and its purpose.
• Alternate name(s). Aliases for che DFD daca store name.
• Attrib11tes. Standard DFD names that enter or leave che data score.
• Volume and freq11e11cy. Describes the cscimaced number of records in the dara
store and how frequently they are updated.
I. This data Store has
an altemauve name.
or alias.
2. For consistency. data
flow names are stan·
dardlzed throughout
the data dictionary.
3. It Is important to
document these
enimates because
they will affect
design decisions In
subsequent SDLC
phases.
....
..........
--
l ....
, ........
...
...
J
FIGURE 5-21 A Visible Analyst screen that documents a data store
named IN STOCK.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
P hase 2
Systems A nalysis
S.8 Data Dictionary
167
5.8.4 Documenting the Processes
Every proces<; mu t be documenred, as shown in Figure 5-22. The documentation includes
a description of the process's charaaeristics and, for functional primitive , a process
description, which is a model that documenrs the processing seeps and busme<;s logic.
The following are typical characteriscics of a process:
• Process name or label. The process name as it appears on the DFDs.
• DescrtfJ/1011. A brief <;tacement of the process's purpose.
• Process 1111mber. A reference number that identifies the process and indicates
relationships among various levels in the system.
• Process description. This section includes the input and output data flows. For
functional primicives, the process description also documents the processing seeps
and bu~iness logic. The next section explains how co write process descriptions.
I . The process num·
ber identifies mis
process.Any subprocesses
are numbered
I. I, 1.2, 1.3,
and so on.
2. These data flows
will be described
spcclflcally elsewhere
in the data
diccionary.
"""'
...,..r,,.-
1 '1--1+- ·• ·
L'""'""""
_____ __,
°'8qlpl!Oft [ ftc.(tf'l tit •¥rt~.....,_ NMd tifl l·-W ....... IN<t h•IWiWltf
rr,,. .,._, .._. ~ .. Cltttlll UAl\l!o MfJO! "1 OflM
"9cMc
~ 0...-4.lf.t.._ UCllD<mll:~ M.CllflOOlllllll
- [
-- ,___, -.. ....
--Qp t- ...
·-·
A ""8111tor'f~--oP'I.. te '-l.a C!Wlet" ........ W'9 h ~.,.. M
FIGURE S-22 A Visible Analyst screen that descnbes a process named
VERIFY ORDER.
5.8.5 Documenting the Entities
By documenting all entities, the data dictionary can describe all external encities char
interact with rhe system. Typical characteristics of an entity include the following:
• Entity 11a111e. The enricy name as it appears on the DFDs.
• Description. Describe the entity and its purpose.
• Alternate na111e(s). Any aliases for the entity name.
• Input data flows. The standard DFD names for the input data flows co the entity.
• Output data (10111s. The standard DFD names for the data flows leaving the entity.
5.8.6 Documenting the Records
A record is a daca srrucrure chac contains a set of related data elements that are stored
and processed together. Data flows and data stores consist of records that must
......... ""_.. ... .-.. ............... _
.. __ __.... ................... ~~·~----···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter S
Data and Process Modeling
168 5.8 Data Dictionary
be documented in the data dictionary. Characteristics of each record mu~t also be
defin ed, as shown in Figure 5-23.
Typical characteristics of a record include the following:
• Record or data structure name. The record name as it appears in the related
data flow and daca store entries in che data dictionary.
• De(i11itio 11 or description. A brief definition of the record.
• Alternate name(s). Any aliases for che record name.
• Attributes. A list of all the daca elements, or fields, included in rhe record. The
dara elemenc names must march exactly those entered in the dara dicrionary.
o.....- 1.oc...... ......
laMI
EIU'.Dlt STAM
""'Y lYPI'
Oac.vP'IOftl I C:witomtr (fedC d.tt•
.
Alflf\:
Attrlbults: ....... ,,,, ....glh
...
lftJ ill !JI CUSTOMllt MJMll!l Ch• CUSlOMlll STATUS Ch" ......
.....
FIGURE S·ll A Visible Analyst screen that documents a record. or data
structure. named CREDIT STATUS.
'"' J
y
l
I.
2.
This data structure
is named CREDIT
STATUS.
The CREDIT
STATUS data
structure consists
ofcwo data
elements:
CUSTOMER
NUMBER and
CUSTOMER
STATUS CODE.
5.8.7 Data Dictionary Re ports
The data dictionary serves as a central storehouse of documcnration for an informa·
rion sysrem. A data dictionary is created when rhe system is developed and is updated
constantly as rhc system is implemented, operated, and maintained. In addition co
describing each daca clement, dara flow, dara store, record, emity, and process, the
darn dictionary documenrs the relationships among these components.
Many valuable reporrs can be obtained from a data dictionary, including the following:
• An alphaberizcd list of all data elements by name
• A report describing each daca element and indicaring the user or dcparrmenc
chat is responsible for daca entry, updaring, or delerion
• A report of all data flows and daca stores char use a particular dara clcmenc
• Detailed reports showing all characteristics of data elements, records, dara
flows, processes, or any ocher selected item stored in the dara dictionary
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

I '
I
Phase 2
Systems A nalysis
S.9 Process Description Tools in Modular Design
169
5. 9 PROCESS DESCRIPTION TOOLS IN MODULAR DESIGN
A process d e~cription documents the derails of a functional primitive and represents
a specific set of processing steps and business logic. When a functional primitive is
analyzed, the processing steps arc broken down into smaller unirs in a process called
modular design. Using a set of process description tools, a model is created chat is
accurate, complete, and concise. Typical process description tools include scrucrured
English, decision rabies, and decision crees.
5.9. 1 Process Descriptions in Object-Oriented Development
This chapter deals with srrucrured analysis, but the process descriptions can also he used
in object-oriented (0 -0) development, which is described in Chapter 6. As explained in
Chapter I, 0 -0 analysis combines data and the processes that acr on the data into things
called objects, and similar objects can be grouped together into dasse~, and 0 -0 processc~
are called methods. Although 0-0 programmers use different rermi11ology, they create the
same ki11d of modul::ir coding structures, except
that the processes, or methods, are stored inside
the objecrs, rather than as separate components.
5.9.2 Modular Design
Modular design is based on combinations
of three logical structures, sometimes called
control structures, which serve as building
blocks for the process. E.ach logical strucrure
must have a single entry and exit point. The
three structures are called sequence, selection,
and iteration. A rectangle represents a step
or process, a diamond shape represents a
condition or decision, and the logic follows the
Imes in the direction indicated by the arrows.
l. Sequence. The complerion of steps in
sequential order, one after another, as
shown in Figure 5-24. One or more of the
steps might represent a subprocess that
contains addirional logical strucrurcs.
2. Selection. The complerion of one of
two or more process steps based on
the resu lts of a rest or condirion. In
the example shown in Figure 5-25, the
sysrem rests the input, and if the hours
are greater than 40, ir performs the
CALCULATE OVERT IME PAY process.
3. Iteration. The completion of a process
step thar is repeated until a specific condition
changes, as shown in Figure 5-26.
An example of iteration is a process that
conrinues to print paychecks until it
reaches the end of the pa)•roll file. Iteration
also is called looping.
VERIFY
PRODUCT
CODE
-
PRICE
VERIFY
FIGURE 5-2<4 Sequence structure.
NO
YES
FIGURE S-25 Selection structure.
YES
NO
FIGURE 5-26 lte~tion structUre.
VERIFY
STOCK
LEVEL
CALCULATE
OVERTIME
PAY
PRINT
PAYCHECK
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
170 5.9 Process Description Tools in Modular Design
&oorltP< --==-----~
Sequence, selection, and iteration structures can be combined in various ways to
de cri bc proces ing logic.
5.9.3 Structured English
Structured English is a subset of standard English that describes logical processes
clearly and accurately. \Xlhen using strucrured English, be mindful of the following
gu1delt11es:
....
• Use only the three building
blocks of equence, selection, and
iteration.
~ f •••'f"C<•~.,.... NW!lf 9fll1 -dl1 ~Y1.,..,_,~,~ I • Use indentation for readability.
........
"-'c- 111pt.1f Ml..._. 01U1U. C'-'0!1 STAlUl, H<OJC1 OOAl
On«sll_. ~ ...._. fllfwll llUCTlD°'°"MXlPTmOltCtl
-
~--
,_.. M Ch OftOIJt
W CUSltWO!Sl~MCOOl •" """''~004'1. • OtC
o....- AC<CPTlOO«DU
[I,.
OV!pue '1•CttDOfl0.-l
°""' ......
+---1---1 Structured English
statements
FIGURE 5.27 The VERIFY ORDER process description includes logical rules and
a structured English verst0n of the policy. Note the alignment and indentation of
the logic statements.
• Use a Ii mired vocabulary, including
standard terms used in the dara
dictionary and specific words that
de cri be the processing rules.
An example of srrucrured
English appears in Figure 5-27,
which shows the VERIFY ORDER
process that was illustrated earlier.
Note that the strucrured English
version documents the actual logic
char will be coded into the system.
Srruccured English can help
process descriptions accurate and
understandable to users and system
developers.
Structured English might look
familiar to programming srudenrs
because it resembles p'eudocode,
which is used in program design.
Although the techniques are similar,
the primary purpose of structured Eaglisb is ro de~cribe the underlying business logic,
while programmers, who are concerned with coding, mainly use pseudocode as a
~horth::md notation for the actual code.
Following structured English ruJes ensures that process descriptions are under­
Mandahle to users who must confirm that the process is correct, as well as to other
analysts and programmers wbo must design the information sy~rem from the
descriptions.
S.9.4 Decision Tables
A decision table is a logical structure that shows every combination of conditions and
outcomes. Analysts often use dccisio11 tables to describe a process and ensure that
they have considered all possible situations. Decision rabies can be created using tools
such as M icrosofr PowerPoint, Word , or Excel.
TABLES WITH ONE CONDITION: If a process has a single condition, there only are
rwo possibilirie-;-yes or no. Either the condition is present or it is not, so there are only
two rules. For example, to trigger an overtime calculation, the process condition mighr
be: Are the hours greater than 40? If so, the calculation is made. Otherwise, it is not.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f• ,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&. ...-.~ ~ij
r..a...w...,..._...., ...., ...,...... .,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,....

I '
I
Phase 2
Systems Analysis
S.9 Process Description Tools in Modular Design
I 7 1
TABLES WITH TWO CONDITIONS: Suppose there is a need to create a decision rable
based on rhe VERIFY ORDER business process shown in Figure 5-28. When documcnring
a process, it is importanr ro ensure char every possibility is listed. In chis example, rhc
process description co ntain~ two conditions: product srock sratus and cuscomer credit
srarus. If both conditions arc mer, rhc order is accepted. Otherwise che order 1s rejecred.
VERIFY ORDER Business Process with Two Conditions
• All order will be accepted only if the product is in stock and the customer's credit status 1s OK.
• All other orders will be rejected.
FIGURE 5-28 The VERIFY ORDER business process has two conditions. For an order to bi! accepted. the
product must be In stock and the customer must have an acceptable credit status.
After all the conditions and outcomes have been identified, rhe nexr step i~ to create a
decision tnhle simil:ir co the one shown in Figure 5-29. Nore that each condition has rwo
possible v:ilues, so the number of rules doubles each time another condition is added.
For example, one condition creates two rules, two ,conditions create four rules, three
conditions create eight rules, and so on. In rhe two-condition example in Figure 5-29,
four pos~ibilities exist, bur Ruic I is the only combination that will accept :in order.
TABLES WITH THREE CONDITIONS: Suppose the company now decides rhar rhc
credit manager can waive the customer credit requirement, as shown in Figure 5-30.
Th:.ir creates a third condition, so there will be eight possible rules. The new decision
cable might resemble rhc one shown in Figure 5-31.
1. Place the l"i'----VERIFY ORDER Process
nameofthe ~
process ma I 2 l 4
heading at
~ Credit status is OK
y y N N
the top left.
\!,/---. Product 1s in stock
y N y N
2. Enter the
conditions
under the
heading. with
one condition
per line.
to represent
the customer
status and availability
or products.
3. Enter all potential
combinations ofY/N
for the conditions.
Each column represents
a numbered
possibility called a
rule.
4. Place an X on the
actJon entries area for
each rule to indicate
whether to accept or
reiect the order.
Accept order
Reject order
x
}--W
x x x --@
FIGURE 5-29 Example or a simple decision table showing the processing logic or the VERIFY ORDER
process. To create the table. follow the four steps shown.
VERIFY ORDER Business Process with Three Conditions
__ _.
• An order will be accepted only if the product is in stock and the customer's credit status is OK.
• The credit manager can waive the credit status requirement.
• All other orders will be rejected.
FI GURE 5-30 A third condition has been added to the VERIFY ORDER business process. For an order to be
accepted, the product must be in stock and the customer must have an accepable credit status. However. the
credit manager now has the authority to waive the credit saws requirements.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter S
Data and Process Modeling
172 5.9 Process Description Tools in Modular Design
First, the Y-N patterns must be filled in, as shown in Figure 5-3 1. The best way
to assure that all combinations appear is rouse parterns like these. The first condition
uses a pattern of Y-Y-Y-Y followed by -N-N-N, the second condition uses
a repeating Y-Y-1 -N pattern, and rhe pattern in the third condition is a series of
Y-N~.
VERIFY ORDER Process with Credit Waiver (initial ve rsion)
I 2 3 4 5 6 7 8
Credit saws is OK y y y y N N N N
Product is In stoek y y N N y y N N
Waiver from credit manager y N y N y N y N
Accept order x x x
Re1ect order x x x x x
FIGURE 5-l 1 This decision 1:1ble is based on the VERIFY ORDER conditions shown in Figure S-30. With
three conditions. there are eight possible combinations or rules.
The nexr seep is very important, regardless of the number of condirions. Each
numbered column, or rule, represents a different set of conditions. The logic muse be
carefully analyzed and che outcome for each r ule shown. Before going further, srudy
the cable in Figure 5-31 co be sure the logical outcome for each of the eight rules is
understood.
\Vhen all the ourcomes have beeo determined, the next step is ro simplify rhe rable.
ln a multi-condition cable, some rules might be duplicates, redundant, or unrealistic.
To simplify the table, follow rhese steps:
I. Stud> each combination of conditions and outcomes. \Xlhen there are rules with
three conditions, only one or two of chem may control the outcome, and the
ocher conditions simply do not matter.
2. If there are conditions that do not affect the outcome, mark them with dashes
( -) as shown in the first table in Figure 5-32.
3. Now combine and renumber the rules, as shown in the second table in
Figure 5-32.
Afrer following these steps, Rules 1 and 2 can be combined, because credit status
is OK in both ru les, so the waiver would not matter. Rules 3, 4, 7, and 8 also can be
combined because chc product is not in stock, so other conditions do noc matter. The
resulr is rhar instead of eight possibilities, only four logical rules concrol rhe Verify
Order process.
MULTIPLE OUTCOMES: In addition co mu ltiple conditions, decision rabies can have
more than rwo possible outcomes. For example, the sales promotion policy shown in
Figure 5-33 includes three conditions: Was the customer a preferred customer, did the
customer order $1,000 or more, and did the customer use our company charge card?
Based on these conditions, four possible actions can occur, as shown in the decision
table in Figure 5-34.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
S.9 Process Description Tools in Mo d ular Design
173
VERIFY ORDER Process with Credit Waiver (with rules marked for
combination)
I 2 3 .C 5 6 7 8
Credit status 1s OK y y N N
Produet 1s in stock y y N N y y N N
Waiver from credit manager
y N
Jt
Accept order
x
Re1ect order x x x x x
I . Because the
product is not in
stock. the other
conditions do not
matter.
2. Because the
other conditions
are met.the
waiver does not
matter.
VERIFY ORDER Process with Credit Waiver (after rule combination and
simplification)
I 2 3 .C
(COMBI NES
(COMSINES
PREVIOUS 1, l) (PREVIO US S) (PREVIOUS 6) PREVIOUS J, 4, 7,1)
Credit staws Is O K y N N
Produet is in stock y y y N
Waiver from credit manager y N
Accept order x x
Reject o rder x x
FIGURE S-32 In the first decision table.dashes have been added to indicate that a condition is not relevant. In
the second version of the decision table. rules have been combined following the steps shown below. Note that in
the final version. only four rules remain. These rules document the logic and will be transformed into program code
when the system is developed.
SALES PROMOTION POLICY -
Holida y Season
• Preferred customers who order $1 .000 or more are entided to a 5% discount and an
additional 5% discount rf they use our charge card.
• Preferred customers who do not order S 1,000 or more will receive a $25 bonus coupon.
• All other customers w ill receive a $5 bonus coupon.
FIGURE S-33 A sales promotion policy with three conditions. Note that the first statement contains tw0
separate conditions: one for the 5% discount and another for the additional discount.
Sales Promotion Po licy (initial version)
Preferred customer y y y y N N N N
O rdered S 1,000 or more y y N N y y N N
Used our charge card y N y N y N y N
5% d iscount x x
Additional 5% discount
x
$25 bonus coupon x x
$5 bonus coupon x x x x
FIGURE S-34 This decision table 1s based on the sales promotion policy in figure S-33.This 1s the 1n1t1al
version of the table before simplification.

Chapter S
Data and Process Modeling
174 5 .9 Pro c ess Description Tools in Modular Design
As explained in rhe preceding section, most rabies can be simplified, and this one is no
exception. After studying rhe condirions and outcomes, the following becomes apparent:
• In Ruic I, all three condirions are mer, so both 5% discounts apply.
• In Ruic 2, a preferred customer orders $ 1,000 or more bur does not use our
charge card, so only one 5% discount applies.
• Rules 3 and 4 can be combined into a single rule. \Vhy? If preferred customers
do nor order $ 1,000 or more, it does not matter whether they use our charge
card-either way, they earn onJy a S25 bonus coupon. Therefore, Rules 3 and 4
really arc a single rule.
• Rules 5, 6, 7, and 8 also can be combined into a ~ingle rulc-hecause if rhe person
is not a preferred customer, he or she can only receive a $5 honus coupon,
and the other conditions simply do not matter. A da~h is inserted if a condition
is irrelevant, as shown in figUie 5-35.
If dashes are added for rules that are not relevant, the table should resemble the
one shown in Figu re 5-35. When the results are combined and simplified, only four
ru les rema in: Rule 1, Rule 2, Rule 3 (a combination of initial Rules 3 and 4), and
Ruic 4 (a combination of initial Ru les 5, 6, 7, and 8).
Sales Promotion Policy (final version)
I 2 3 4 5 6 7 8
Preferred customer y y y y N N N N
Ordered $1 ,000 or more y y N N
Used our charge card y N
5% disco unt x x
Additional 5% discount
x
$25 bonus coupon x x
$5 bonus coupon x x x x
FIGURE 5-lS In chis version of me decision table. dashes have been added to indicate chat a condition is not
relevant.As chis point. le appears mac several rules can be combined.
Decision tables ofren are rhe best way ro describe a complex set of conditions.
Many analysts use decision rabies because they are easy ro construct and understand,
and programmers fi nd it easy to work from a decision table when developing code.
CASE IN POINT 5.2: llocK SouD O u rn ITt:Rs (PART 1)
The marketing director at Rock Solid Outfitters, a medium-sized supplier of outdoor climbing and
camping gear; has asked the IT manager to develop a special web-based promotion. Rock Solid will
provide free shipping for any customer who either completes an online survey form or signs up
for the Rock Solid online newsletter.Additionally. if a customer completes the survey and signs up
for the newsletter, Rock Solid will provide a $ 10 merchandise credit for orders of $ I 00 or more.
The IT manager has asked you co develop a decision table that will reflect the promotional rules
that a programmer will use. She wantS you ro show all possibilities, and then to simplify the results
to eliminate any combinations that would be unrealistic or redundant. How will you proceed!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

' I
I
I
Phase 2
Systems Analysis
S.9 Process Description Tools in Modular Design
175
5.9.5 Decision Trees
A decision tree is a graphical represencarion of che conditions, actions, and rules
found in a decision table. Decision crees show the logic structure in a hori1ontal form
chat re embles a tree with the roots at the left and the branches to che right. Like
flowcharts, decision trees are useful ways to present the system to management. Decision
trees and deci~ion tables provide the same results but in different forms. In many
s1ruanons, :i graphic 1s the most effective means of communication.
Figure 5-36 is based on the sales promotion policy shown in Figure 5-33. A decision
tree is read from lefr to right, with the conditions along the various branches and
the actions at the for right. Because the example has two conditions with four resulting
sets of actions, the example has four terminating branches at the right side of che
tree.
Preferred
customer?
y
Ordered
$1 ,000 or
more?
Y
Used our
charge card?
,---------<
y
---
5% discount and
an additional 5%
discount
--- 5% dlacount
N
'------------ $25 bonus coupon
N
N'--------------------~ S5bonuscoupon
FIGURE 5-36 This decision tree example is based on the same Sales Promotion Policy shown 1n the decision
ables in Figures S-34 and S-35. Uke a decision table. a decision tree shows all combinations of conditions and
outcomes.The main difference is the graphical format. which some viewers may find easier to interpret.
\Xlhether co use a decision table or a decision tree often is a matter of personal
preference. A decision cable might be a better way ro handle complex combination~
of conditions. On the other hand, a decision tree is an effective way to describe a relatively
simple process.
CASE IN POINT 5.3: RocK Souo 0ITTFITIFRS (PART 2)
The IT manager at Rock Solid Outfitters thinks you did a good job on the decision table task
she assigned to you. Now she wants you to use the same data to develop a decision tree that
will show all the possibilities for the web-based promotion described in Part I of the case. She
also wants you to discuss the pros and cons of decision tables versus decision trees. How shall
you proceed this time!
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter S
Data and Process Modeling
176 5.10 Summary
This is your first week in your new job at Safety Zone, a leading producer of IT modeling
software. Your prior experience with a. smaller competitor gave you an edge in landing the
job, and you are excited about joining a larger company in the same field.
So far, all is going well, and you are getting used to the new routine. However. you are
concerned about one issue. In your initial meeting with the IT manager. she seemed very
interested in the details of your prior position, and some of her questions made you a little
uncomfortable. She did not actually ask you to reveal any proprietary information, but she
made it clear that Safety Zone likes to know as much as possible about its competitors.
Thinking about it some more, you try to draw a line between information that is OK to
discuss and topics such as software specifics or strategy that should be considered private.
This is the first time you have ever been in a situation like this. How will you handle !ti
S. I 0 SUMMARY
Structured analysis tools can be used to develop a logical model during one systems
analysis phase and a physical model during the systems design phase. Many analyses
use a four-model approach, which involves a physical model of the current system, a
logical model of the current system, a logical model of the new system, and a physical
model of the new system.
During data and process modeling, a systems analyst develops graphical models
to show how the system transforms data into useful information. The end product of
data and process modeling is a logical model that wilJ support business operations
and meet user needs. Dara and process modeling involves three main tools: DFDs, a
data dictionary, and process descriptions.
DFDs graphically show the movement and rransformarion of data in the information
sy rem. DFDs use four symbols: The process symbol transform data, the data
flow symbol shows data movement, che data store symbol shows dara ar resr, and the
external entity S)'mbol represents someone or something connected ro the information
system. Various rules and techniques are used to name, number, arrange, and annotate
the ~et of DFDs to make them consistent and understandable.
A set of DFDs is like a pyramid \Vith the context diagram at the top. The context
diagram represents the information system's scope and its external connections bur not
its inremal workings. Diagram 0 displays the information syscem's major processes,
darn stores, and dam flows and is the exploded version of the context diagram's process
symbol, which represents the entire information system. Lower-level DFDs show
additional detail of the information s,ystem through the leveling technique of numbering
:1nd partitioning. Leveling continues until the functional primitive processes arc
reached, which are nor decomposed further and are documented with process descriptions.
All diagrams must be balanced to ensure their consistency and accuracy.
l11c data dictionary is the central documentation tool for structured analysis. All data
elements, data flows, data stores, processes, entities, and records are docwnentcd in the data
dictionary. Consolidating documentation in one location allows the analyst to verify the information
sysrcm 's accuracy and consistency more easily and generate a variety of useful reporcs.
Each functional primitive process is documented using structured English, decision
tables, and decision trees. Structured English uses a subset of standard English that
defines each process with combinacions of the basic building blocks of sequence, sclecnon,
and iteration. Using decision tables or decision trees can also document the logic.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

' I
I
I
Phase 2
Systems Analysis
Key Terms
177
Key Terms
alias A term used m various Jara d1cttonaries 10 indicate an altemare name, or J name other than rhe
;,randard Jar.1 dcmem name, rhar 1s used co de.cribe the same data element.
balanunit A pr<><.c:-.\ u>ed to mam1.1m .:on~1scency among an enrire seri~ of dfagram•., mdudin11 mpu1
and output data Omn, Jara definmon, and pr0<.-e-;s dc::>cripuon~.
blad. ho' t\ metaphor for a proce>\ or an acrion that produces rc~ult~ an a non-rran\parcnt or nonoh-crvahle
manner. In OFO~. a proce<.~ appears as a black box where che inpul', output\, and general
function of the prcx:C\~ arc known, bur rhe underlying demi ls are not ~hown.
black hole A process rhar has no output.
business logK Rules 10 derermme how a system handles data and produces useful informauon, rcflecnng
the operanonal rcqu1remenrs of rhe bustness. E..xamples include adding the proper amo•tnt of sales tJll.
to invoices, calcul.111ng customer balances and fmance charges, and deternunmg wherher a customer
is eligible for ,1 volum~ - bascd discount. Also called business rules.
bu"n''" rule, Sec hminc\\ lo111c.
child diagrnm The lower-level diagram in an exploded DFD.
context diagram A rop-lcvcl view of an informarion system that shows the bound<lrics ond ~cope.
conrrol ~trucrurc
~crvc as building blocks for a process. Conrrol structures have one entry ond cxir
point. '1 be) may be completed m sequential order, as the resulr of a rest or condmon, or repe.ncd until
J >pec1fic condmon ch.111ges. Also c.alled logic.ii structure.
data Jiu1onal') A ~c:nrral \torc:hou'c: of information about a >Y>tc:m'> data.
dara cli:mcnr 1\ ''"Jllc <:haracttri~c11: or fau ahout an cntil)-. A data clcrnc:m, fidd, or arrributt" the
'malle>t pic.:t of data that ha• meaning within an information sy,tcm. For example, a 'KK:1al Security
number or companr name could be example~ of a daca element. Alo;o called data item.
data Oo" A path for data to mo•e from ooe part of the informarion S) stem to a nor her.
data Oo" diagram !DfD) Diagram rhar shows how the S)"Stem scores, processes, and rraosforms dara
11110 useful informauon.
cilia item Sci! datJ dc:mc:nt.
Jar.a rc:po\llOI') t\ wmhol u>ed 111 DFO, to reprl!l>cllt a siruarion in which a s)stem mu\t rc:1a111 data
becau;,e cme or more prcK:~'-<"\ nc:c:d 10 use rhat stored data at a later time. u,c:d inrerchan11~hly wnh
the term dat.1 'tore.
data nore Su data rcposllOI) .
dara 'itructurc A m~anmgful comhmar1on of related data element<> rhar are included 111 a data flow or
retained ma data siorc. A frame\\ Ork for organizing and storing data.
dcci\ion table A ta hie char shows a logical structure, with all possible comhmatiom of condi11011\ and
re~u h ing acnon\.
dcl:i,ion rrcc A graphical rcprc;,c111,11ion of rhc conditions, actions, and rule> found in ;1 dcci,ion 1:1blc.
decompo~in11 Anorher w:1y of conveying a process or >ysrem char has been broken down from .1 general,
top-level view 10 more dct.1i l. 1 he rerms exploded and part1tio11ed also can be used.
dia11mm 0 A diagr.1111 dcpic1111g rhc fir~r level of derail below the mirial conrext diagram. Diagram 0
(lcroJ 7.ooms rn on rhe context diagram and shows rna1or processes. darn flows, and d(l(a \tores, as
well as repeating che external enricies and data flows thac appear in the context diJgram.
di•crgmg dara flow A darn flow in which che same dam rra\"els co rwo or more different locarions.
domain The set ot value<; pcrmmcd for a d:na elemenc.
enut• A person, a pla1.:e, J rhmg, or an evem for which dara is collecred and m.110t;11ned. !'or example. an
ouhne >JI~ >»tcm mJ) mdude enm1~ n:tmed CUST0~1ER. ORDER, PRODUCT . .ind SUPPLIER.
explodtnit A J1agr;im 1s s.~td to be exploded 1i 11 "drills down" ro a more derailed or expanded view
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 5
Data and Process Modeling
178 Key Terms
field A ~mgle char.1crens11c or fact abour an enriry. A field, or anribuce, 1s 1hc ~m.iUest pie.:c of d.11a th:u
h.i; mumng wuhm an rnformation system. For example. a Social S«ut1t} numlx:r or company name
could!)( e~amples of a field. The rerms data eleme11t, data item, .ind field are used m1crchangeably.
four-moJd approach A ph)">ical model of the currenr system, a logu:al moJd of thc L-UITtnt \)\!em, a
loi;1cal model of rhe new S)-.rem, and a physical model of rhe new >y>tcm are all developed.
funuional pnm1tl\e A >mgle function char 1s nor exploded furrher. The logi~ for fun~t1onal prumrive' is
J0<;umcntcJ m a J~ta dictionary proct'.Ss description.
Gane and Sarson A popular symbol sec used in DFDs. Processes, data flows, dat.l scores, and exrernal
enrmcs all have a unique symbol.
gr:iy hole A process with an lllput obviously insufficient to geuerare the shown output.
i1cr.11ioo The complenon of a process step chat is repeated unttl a spectfic condiuon changes.
lcvdin11 The prt>ec" of drawinµ a scrie- of increasingly detailed diai:ram~ to rcai:h 1hc dc,ircJ IL-vd of detail.
logical model Shows what a S)n;rcm mu>r do, regardle's of how it will be implemented phy,ically.
logical s1ruccure See cooirol scruccure.
looping Refers ro a process step that is repeated until a specific condition ch.1nges. !·or example. a
process that continues ro prmr paychecks unul 11 reaches the end of the payroll file 1s loopin11. Also
known .is rcpem1on.
modular design A design that can be broken do\\n inro logical blocks. Also known as partitioning or
1op·dow11 design.
p.arcnt Jiai.:ram The hi11hcr or more !Op-kvd dia11ram in an exploded DFD.
panitionini: The brcakini: down of overall objective• into •uh..y•rcm' and mudulc•.
ph) ~ical model A model chat describes how a system will be consrructed.
proccS> Procedure or ta.k that users, managers, md JT scaff members perfom1. Aho, the logic.11 rules of
.i S)Stcm chat are .ipplted ro rrmsform data mto mea.rungful utform.iuon. ln l)ll)s, a process receives
tnput d.11a and produces ourput that bas a ctiHerenr content. form, or both.
proccs~ 0 In a DfD, process 0 (zero) represenrs the entire infom1.ition sy:;rcm but does nm sho" the
internal workings.
pnK~" d~~-rtption A dcxumenrarion of a functional prnn1rivc':; detail;, whkh repre\Cnh a '>pc:~1fic.: sec of
prt><:c:<>,mg >rep\ and bu.,mcss logic.
p'cudocodc A rechnique for rcpreseming program logic.
record A set of related fields that describes one instance, or member of an entif), such a~ one customer,
one order, or one product. A record mighr ha'e one or do£ens of field~. depending on \\h3c mformanon
is needed. Also called a tuple.
~eleccion A control strucrure 111 modular design, it is rhe complenon of two or more proce~~ steps based
on rhc re~ults of :i test or condicion.
,cqucncc The completion of sreps in sequential order, one 3.fter :lllother.
\inl.. An cxtcrn,d entity chat receives daca from an informarion syMcm.
\nurcc An external cnriry rhat supplies data roan information system.
~pontancou~ generation An unexplained generation of data or information. With re~pccr ro DrDs,
proccs;es c:mnor spomaaeouslr generace data flows-they must have an inpur m have an oucput.
)trui;1ured [nglt>h A subser of standard English char describe> logical proccsse; dearly and JCCur3rel).
tcrmmalUr A D~D >ymbol that mdtcares a dara ongrn or final dc;rmarion. Al>o called an C'(tcrnal emit).
•altdtr) rule~ Chech thar are applied ro dara elemems when data is entered to ensure thar rhc value
entered is valid. For e..;ample, a validiry rule mighr require thar an employee·~ ~ala') numl>cr l>c wirnin
rhe cmplo)cr's predefined range for rhar position.
)ourdon A type of srmbol ser rhar 1s used in DFDs. Proccsse>, data flows, data stores, .ind exrcmal
cnriucs each have a unique symbol in rhe Yourdon srmbol set.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. ............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

' I
I
I
Phase 2
Systems Analysis
Exercises
179
Exercises
Questions
I. \Xlhar is rhe relationship bcrwccn logical and physical models?
1. What is the function of a DFD in the SDLC?
3. Draw examples of rhe four basic DFD symbols.
4. \Xlhar are the six guidelines to follow when drawing DFDs?
5. What is rhe difference bcrween a conte"''t diagram and diagram O?
6. \Xlh1ch symbol is not used in a coarext dfagram?
7. I low would you level a DFD?
8. How would you balance a DFD?
9. What is a dat:i clement?
I 0. What is rhe purpose of a decision rable?
Discussion Topics
I. How would you convince management char following a four-model approach is wise?
1. \'V'hen might it be :ippropriare co violate the "no crossed lines" guideline in DFDs?
3. \'<'hat is the relationship berween system requirements and context diagrams?
4. How might CASE cools be used to document rhe design of a data dicrion:iry?
5. Some systems analysts find it berrer to start with a decision table, and then construct a decision tree.
Others believe it is easier to do ir in the reverse order. Which do you prefer? Why?
Projects
1. The data flow symbols shown in Figure 5-1 were designed by Ed Yourdon, who was a well-known IT
author, lecrurer, and consulcant. t.1an)' IT professionals consider him to be among the most influenrial
men and women in rhe software field. Learn more about ~1r. Yourdon by visiting online resources and
write a brief re\•iew of his work.
2. Explore rhree CASE tools that provide the ability to dra\\ the four basic DFD symbols and describe
what you liked and disliked about each tool.
3. Draw :i context diagram and a diagram 0 D FD char represents the information system at a rypical
library.
4. Create a decision rable with three conditions. You can make one up or use a scenario from everyday
life. Eirher way, be sure co show all possible ourcomes.
5. Explore the use of Structured English to describe processes in fields other rhan systems analysis.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... . ... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 6
Object Modeling
Object Modeling
Chapter 6 is the third of the four chapters in the
systems analysis phase of the SDLC. This chapter
discusses object modeling techniques that analysts use to
create a logical model. In addition to structured analysis,
object-oriented analysis is another way to represent and
design an information system.
The chapter includes three "Case in Point"
discussion questions to help contextuali1e the concepts
described in the text. A "Question of Ethics" considers
the situation where an employee wants to skip a course
and just sit the exam and requests a copy of the training
materials from someone else who took the course.
LEARNING OBJECTIVES
When you fi11is/J this chapter, yo11 should be
able to:
1. Demonstrate how objccr-orientcd analysis can
be used to describe an informarion system
2. Explain whar an objecr represenrs in an informa·
tion sysrcm
3. Explain obiect artribures
4. Explain objecc mcrho<ls
5. Explain objccr messages
6. Explain classes
7. Explain relarion~hips among objccrs and classes
8. Draw an objecr relarionship diagram
9. Demonscrace use of the UML ro describe
objecr-oriented l.ystems, including use cases,
use case diagrams, class di:igrams, sequence
diagrams, scare transirion diagrams, activiry dia·
grams, and business process models
lO. Explain how roob can bupporr object modeling
CONTENTS
6. 1 Objecr·Orienrcd Analysis
Case in Point 6.1: TravelBiz
6.2 Objects
6.3 Attributes
6.4 ~lethods
6.5 ~l essages
6.6 Classes
6.7 Relationships Among Objecr~ and Classes
6 .8 The Unified Modeling Language (UML)
Case in Poinr 6.2: Hilltop Motors
Case in Poinr 6.3: Train rhe Trninerb, Inc.
6.9 Tools
A Question of Ethics
6. 10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

' I
I
I
Phase 2
Systems Analysis
6.2 Objects
181
6.1 OBJECT-ORIENTED ANALYSIS
As seated in Chapter I, rhe mosr popular systems development options are structured
analysis, object-oriented (0-0) anal)·sis, and agile methods. The table in Figure 1-17
shows rhe three alrernati,·es and describes some pros and cons for each approach. As
tbe rable indicares, 0-0 methodology is popular because it inregrares easily wirh 0-0
programming languages such as C++, Ja,·a, and Python. Programmers also ltke 0-0
code because it is modular, reusable, and easy to maintain.
Object-oriented (0 -0 ) anal y~ i s describes an information system by idenrifying
things called objects. An object represents a real person, place, event, or rransacrion.
For example, when a patient makes an appointment to sec a doctor, the patient is an
object, the doctor is an object, and the appoinanent itself is an object.
0-0 analysis is a popular approach that sees a system from the viewpoint of the objects
themselves as they function and interact. The end product of 0-0 analysis is an object
model, which represents the information system in rerms of objects and 0 -0 concepts.
Chapter 4 stated that the Unified Modeling Language (UML) is a widely used
method of vi~ua l izi n g and documenti ng an information system. ln this chapter, the
UML is used to develop object models. The first step is ro understand basic 0 -0
terms, incl uding objects, attributes, methods, mes.sages, and classe~ . This chapter
shows how systems analysts use those terms ro describe an information system.
CASE IN PO INT 6.1: T RAVELBIZ
TravelBiz is a nationwide travel agency that speciali1.es in business traVel. It has decided to
expand into the vacation travel market by launching a new business division calledTravelFun. The
IT director assigned tw0 systems analysts to create a flexible and an efficient information system
for the new division. One analyst wants to use traditional analysis and modeling techniques for
the project, while the other analyst wants to use an 0-0 methodology. Which approach would
you suggest and why?
6.2 OBJECTS
An object represenrs a person, a place, an event, or a transaction that is significanr ro
the information ~ysrem. In Chapter 5, DFDs were created that treated data and processes
separately. An object, however, includes data and the processes that affect that
data. For example, a customer object has a name, an address, an account number, and
a current balance. Customer objects also can perform specific tasks, such as placing
an order, paying a bill, and changing their address.
Consider a simplistic example of how the UML might describe a famjJy wirh parents
and children. UM L represenrs an object as a rectangle with the object name at
tbe cop, fo llowed by rhc object's attributes and methods.
Figure 6- 1 shows a PAR ENT object ~vi th certain attributes such as name, age, sex,
and hair color. If there arc nvo parents, then there arc rwo instances of the PA RENT
object. T he PA RENT object can perform methods, such as reading a bedtime story,
driving the carpool van, or preparing a school lunch. When a PARE rT object receives
a message, it performs an acrion, or method.
For example, the message GOOD NIGHT from a child nught cell rhc PARENT
object to read a bedtime srory, while the message DRrYE from another parent signals
chat iris rhe PA RF.NT object's turn co drive in the carpool.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 6
Object Modeling
182
6.2 Objects
PARENT Object
Instances of
the PARENT Object
Cllaracter.stlCS
that describe tile
PARENT object
Task.s tllat the
PARENT objoct
can perform
Name
Age
Sex
Hair color
Attributes
...........
•a "ill
a1111112m ui.-.
Mary Smith
Age25
Female
Red
Ahmec:IAll
Age34
Male
Brown
AnthonyGrMna
Age 42
Mate
Brown
FIGURE 6- 1 The PA RENT object has four attributes and two methods. Mary Smith, Ahmed All, and
Anthony Greene are Instances or the PAREN T •object.
Continuing with the fami ly example, che CHJLD object in Figure 6-2 posse ses che
same artrilrntes as the PARENT object and an additional arrribute thac shows the number
of siblings. A CHllD object performs certain methods, such as picking up roys, eat·
ing dinner, playing, cooperating, and getting ready for bed. To signal the CHILD object
to perform those casks, a parent can send certain messages that rhe CHILD objecr will
undcrsrand. For example, rhe DINNER'S READY message cells a CHILD obiect to
come to the rable, while rhe SHARE \XfJTH YOUR BROTHER/SISTER message tells a
Cl ll LD object co cooperate wich other CHILD objects.
Characteristics
that describe the
CHILD Object
Tasks that the
CHILD objecl can
perform
CHILD Object
CfSD
Attributes
Name
Age
Sex
Hair color
Number of slbllngs
•...,
-··
tl?h•lfr
.........
,..,
D Ji I
Instances of
the CHILD Object
James Smltll
Age3
Male
Red
Amelia All
Age 1
Female
Brown
MlatyGreene
Age t2
Female
Blonde
FIGURE 6-2 The CHILD object has rive attributes and five methods.James Smith. Amelia Ali. and
Mosty Greene are Instances or the CHILD object.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

I '
I
Phase 2
Systems A nalysis
6.5 Messages
183
6.3 ATTRIBUTES
An object has certain attributes, which are characteristics that describe the object. If
objects are similar to nouns, attributes are similar co adjectives that describe the characteristics
of an object. For example, a car has attributes such as make, model, and
color. Some ob1ects might have a few attributes; ochers might have doz.ens.
Systems analysts define an object's attributes during the systems design proce~s. ln
an 0-0 system, ob1ecrs can inherit, or acquire, cercain attribuces from other objects.
Objects can have a specific attribute called a state. The state of an object i an
adjective that describes rhe object's current status. For example, depending on the
stare, a student can he a future srudenc, a current srudenr, or a past student. Similarly,
a bank account can be acrive, inactive, closed, or frozen.
6.4 METHODS
An object also has methods, which are rasks or functions that the object performs
when it receives a message, or command, to do so. For example, a car performs a
method called OPERATE WIPERS when it is sent a
message with the wiper conrrol, and it can APPLY
BRAKES when it is sent a message by pressing the
brake pedal. A method defines specific tasks that
:in object can perform. Ju~r ::is objects are similar co
nouns ::ind ::irrribuces are similar to adjecrives, meThods
resemble verbs rhar describe what and how an object
does something.
Consider a server who prepares fries in a fascfood
re!.taurant. A systems analyst might describe the
operation as a method called r.10RE FRIES, as shown
in Figure 6-3. The t.10RE FRIES method includes the
steps required to heat the oil, fill the fry basket with
frozen potato strips, lower it into the hot oil, check for
readines!>, remove che basket when ready and drain the
oil, pour the fries into a warming tray, and add salt.
Method:
MORE FRIES
Steps:
t Heat oll
2. All fry basket with frozen
potato strips
3. Lowe< basket Into hot oil
4. Check for readiness
5. When ready, raise basket
and let drain
6. Pour fries Into warming
lfllY
7. Add salt
FIGURE 6-l The MORE FRIES method requires the
server to perform scvcn specific steps.
6.5 MESSAGES
A message is ~1 command that tells an
object co perform a certain method. For
example, the message Pf CK UP TOYS
directs rhe CHILD class to perform
a ll the necessary steps to pick up the
toys. The Cl llLD class understands the
message and executes the method.
The same message to rwo different
objects can produce different results.
The concept that a message gives
different meanings to different objects
is called pol> morphism. For example, in
Figure 6-4, the message GOOD NIGHT
signals the PARENT object to read a
PARENT
Causes Ille
PARENT oo,ect lo
read a bedlime SlQ(y
Message: GOOD NIGHT
DOG
Causes the DOG
obJOCI to go ro sleep
CHILD
Causes lhe CHILD
object ID gel ready
for bed
FIGURE 6-4 In an example or polymorphism. the message GOOD NIGHT
produces different results. depending on wtuch ob1en receives 1L
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 6
Object Modeling
184 6.6 Classes
INSTRUCTOR
bcdrime story, but the same message to rhe CHILD object signals it to get ready for bed.
If the family also had a DOG object, the same message would tell the dog to leep.
An object can be viewed as a black box, because a message to the object triggers
changes within the object without specifying how the changes must be carried our.
A gas pump is an example of a black box. \Vhen the economy grade 1s selected at a
pump, it is not neces ary to think about how the pump determines the correct price
and selects the right fuel, as long as ir does so properly.
The black box concept is an example of encapsulation, which means that all
daca and methods are self-contained. A black box docs not want or need outside
interference. By limiting access to internal processes, an ob1ccr prevents its internal
code from being altered by another object or process. Encapsularion allows objects
to be used as modular components anywhere in the system, because objects send and
receive messages but do not alter the internal methods of other objects.
0-0 designs typically arc implemented with 0-0 programming languages. A major
advantage of 0-0 designs is that systems analysts can save time and avoid errors by
using modular objects, and programmers can translate the designs into code, working
with reusable program modules that have been tested and verified. For example,
in Figure 6-5, an INSTRUCTOR object sends an ENTER GRADE message roan
Message:
ENTER GRADE
STUDENT
RECORD
FIGURE 6-5 In a school Information system. an INSTRUCTOR object sends an
ENTER GRADE message to an instance ol the STUDENT RECORD class.
instance of the STUDENT RECORD
class. Note that the INSTRUCTOR
object and STUDENT RECORD class
could be reused, with minor modifications,
in ocher school information
systems where many of the attributes
and mcrhocls would be similar.
6.6 C LASSES
An objecr belongs to a group or category called a class. For example, Ford Fiestas
belong ro a class called CAR. An instance is a specific member of a class. A Toyota
Camry, for example, is an instance of the CAR class. Ar an auto dealership, many
insranccs of rhc CAR class may be observed: rhe TRUCK class, the ~11NIVAN class,
and the SPO RT lITlLITY VEHICLE class, among others.
All objccrs within a class share common attributes and methods, so a class is like
a blueprint or template for all tbe objects within tbe class. Objects within a class can
be grouped into subclasses, which arc more specific categories within a class. For
example, TRUCK objects represent a subclass within rhe VEHICLE class, along wirh
other subclasses called CA R, M INTVAN, and SCHOOL BUS, as shown in Figure 6-6.
Nore that all four subclasses share common traits of the VEHICLE class, such as
make, model, year, weight, and color. Each subclass also ca n possess traits that are
uncommon, such as a load lim it for the TRUCK or an emergency exit location for the
SCHOOL BUS.
A class can belong to a more general category called a supcrcla~s . For example, a
NOVEL class belongs co a superclass called BOOK, because all novels are books in
this example. T he NOVEL class can have subclasses called HARDCOVER, PAPER­
BACK, and DIGITAL.
Similarly, consider a fitness cenrer illusrrared in Figure 6-7 char might have
students, instructors, class schedules, and a regisrration process. As shown in
Figure 6-8, the EMPLOYEE class belongs to the PERSON superclass, because every
emplO)'Ce is a person, and the rNSTRUCTOR class is a subclass of EMPLOYEE.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
6.6 Classes
185
Class
Subclass
Common
allnbulH
Common
methOds
Make
Model
Yur
Weight
Color
...
-..
Vlllat E
Attributes
Attributes
lmlYAN
Attributes
Uncommon
ottnbutes
Attributes
Load limit
FIGURE 6-7 A typical flmess center might
have students. Instructors. class schedules, and a
registration process.
SI<> I 1!1,.,'Shttlr1 1
'""
Uncommon
allttbutes
SCHOOL BUS
Attributes
Emergeoncy e•il location
FIGURE 6-4 The VEHICLE dass includes common attributes and methods.
CAR. TRUCK. MINIVAN. and SCHOOL BUS are instances of the VEHICLE class.
Superclass
Supeictass
name
Common
attnbu1os
r:Com:::::mo=n'---,:A.111
PERIOH
Attributes
Name
--:r Date of birth
........
•11 ..
Class
name
Class
Attributes
Social Security number
Uncommon Telephone number
attributes Hire date Subelass
methods ... name
Title
Uncommon ...
Pay rate
7 0
Giit ....
llJltiodl
Uncommon
attrlbutos
methods 0
•
Uncommon
methods
Subclass
WllRUCIOR
Attributes
lnatructor type
Avatlabillty
FIGURE 6-8 At the fitness center, the PERSON subclass includes common attributes and methods.
EMPLOYEE is a dass within the PERSON superclass. INSTRUCTOR is a subclass within the EMPLOYEE class.
......... ""_.. ... .-.. ............... _
.. __ __.... ................... ~~·~----···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 6
Object Modeling
186 6.7 Relationships Among Objects and Classes
6. 7 RELATIONSHIPS AMONG OBJECTS AND CLASSES
Relationships enable objects to communicate and interact as they perform business
functions and transactions required by the system. Relationships describe what
objects need to know about each other, how objects respond to changes in other
objects, and the effects of membership in classes, superclasses, and subclasses. Some
relationships arc stronger than others (jusr as a relationship berween family members
is stronger than one between casual acquaintances). The strongest relationship is
called inheritance. Inheritance enables an object, called a child, to derive one or more
of its attributes from another object, called a parent. In the example in Figure 6,9,
the INSTRUCTOR object (child) inherits many traits from rhe FMPLOYEE object
(parent), including SOCIAL SECURITY NUMBER, TELEPHO E NUMBER, and
HIRE DATE. T he INSTRUCTOR object also can posses~ additional attribures, such
as TYPE Of I STRUCTOR. Because a ll employees sh:ue cercnin attributes, rhose
attributes are assumed through inheritance and do not need to be repeated in the
INSTRUCTOR object.
Inheritance
Parent
Attributes
So<:lal Security number
Telephone number
Hire date
Title
Pay rate
....•••llOlllt
1lt LS
CIAO 7 'ct 111'
Child Inherits
•llWCIOR
Attributes
Type ol lnslNCtor
So<:lal Security number
~:.,.._--h Telephone number
Hlredate_J
Tiiie
Pay rate
FIGURE 6,9 An inheritance relationship exists between the INSTRUCTOR
and EMPLOYEE objecLS. The INSTRUCTOR (child) object Inherits characteristics
lrom che EMPLOYEE (parent) class. and can have additional attributes of Its own.
After objects, classes, and relationships have been identified, an object relation,
ship diagram can be prepared to provide an overview of the sy~tem. Thac model
is used as a guide to continue co develop additional diagrams and documenracion.
Figure 6, J 0 shows an object relationship diagram for a fitne~s cencer. Note rhac che
model shows che objects and how they interact to perform business functions and
transactions.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
6.8 The Unified Modeling language (UML)
187
EMPLOYEE
Isa
MANAGER
OFRCESTAFF
INSTRUCTOR
Indicates
avallabillty
RTNESS-CLASS
FITNESS-CLASS
SCHEDULE
Takes
roster
ST\JDENT
FIG URE 6-10 An object relationship diagram for a fitness center.
6.8 THE UNIFIED MODELING LANGUAGE (UML)
just as strucrnred analysis uses DFDs to model data and processes, systems analysts
use UM L co describe 0-0 ~yscems. Chapter 4 explained that UM L ts a popular
technique for documenting and modeling a system. UML uses a set of symbols to
represent graphically the various components and relationships within a system.
Although che UML can be used for business process modeling and requirements
modeling, it is mainly used to support 0-0 system analysis and to develop object
models.
6.8. 1 Use Case Modeling
A use case represents the seeps in a specific business function or process. An external
entity, called an actor, initiates a use case by requesting the system to perform a
function or process. For example, in a medical office system, a PATIENT (actor) can
MAKE APPOINTMENT (use case), as shown in Figure 6-11.
Note that the UML symbol for a use case is an oval with a label that describes the
action or event. The actor is shown as a stick figure, with a
label that identifies the actor's role. The JiJJe from the actor
to the use case is called an association, because it links a
particular actor to a use case.
Use cases also can interact with other use cases. When
the outcome of one use case is incorporated by another use
case, we say that the second case ttses the first case. UM L
indicates the relationship with an arrow char points at rhe
use case being used. Figure 6- 12 shows an example where a
student adds a fitness class and PRODUCE FITNESS-CLASS
ROSTER uses the results of ADD FITNESS-CLASS to
generate a new fitnes.'>·clas.'> roster. Similarly, if an instructor
changes hts or her availability, UPDATE TNSTRUCTOR
h FORMATIO 11ses the CHA GE AVAILABILITY
PATIENT
(Actor)
MAKE APPOINTMENT
(Use Case)
FIG URE 6- 11 In a medical office s11tem. a
PATIENT (actor) can MAKE APPOINTMENT (use
case). The UHL symbol for a use case is an oval.The
actor is shown as a stick figure.

Chapter 6
Object Modeling
188
6.8 The Unified Modeling Language (UML)
Student
Instructor
Add Rtness-Class
Change Avallablllty
<<U5eS>>
<<USeS>>
Produce Frtnes~lass
Roster
Update lnslructor
ln1ormatlon
FIGURE 6- 12 When a student adds a class, PRODUCE FITNESS-CLASS ROSTER uses the
results of ADD FITNESS-CLASS to generate a new roster. When an instructor changes his or
her availability, UPDATE INSTRUCTOR INFORMATION uses the CHANGE AVAILABILITY use
case co update the Instructor's Information.
use case to update the
instructor's in formation.
To creare use cases, start
b)' reviewing rhe information
that gathered during
the requirements modeling
phase. The obrective is to
identify the actors and the
functions or transactions
they initiate. For each use
case, develop a u~e case
description in the form of
a table. A use case description
documents the name
of the use case, the actor, a
description of the use case,
a step-by-step list of the
ra~ks and actions requi red
for successful completion,
a description of alternative
courses of action, preconditions,
posrcondirions, and
assumptions. Figure 6-13 shows an example of the ADD NEW STUDENT use case
for the fitness center.
ADD NEW STUDENT Use Case
Add New Student
Name:
Actor:
Description:
Successful
completion:
Alternative:
Precondition:
Postcondition:
Assumptions:
Add New Student
Student/Manager
Describes the process used to add a student to a fitness-class
1. Manager checks FITNESS-CLASS SCHEDULE ob1ect for availabihty
2. Manager notifies student
3. Fitness-class is open and student pays fee
4. Manager registers student
1. Manager checks FITNESS-CLASS SCHEDULE object for availability
2. Fitness-class Is full
3. Manager notifies student
Student requests litn ess-class
Student is enrolled in fitness-class and fees have been paid
None
FIGURE 6- 13 The ADD NEW STUDENT use case description documents the process used to add a current
student into an existing dass at the fimess center.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
6.8 The Unified Modeling Language (UML)
189
\'V'hen use cases arc idcnrified, al l rhe relaced cransacrions should be grouped inro a
single use case. For example, when a horcl customer reserves a room, rhe rescrvarion
S)'Srem blocks a room, updares rhe occupancy forecasr, and sends rhe cusromer a
confirmarion. Those cvcnrs are all part of a single use case called RE ERVE R00~'1,
and the specific acrions are ~tep-by-srep casks within the use case.
6.8.2 Use Case Diagrams
A u~e ca~e diagram is a visual summary of several related use case!. w1chm a sy~tem or
subs) stem. Consider a C) pica I au co service deparr:menc, as shown in Figure 6- 14. The
service department involves customers, service writers who prepare work orders and
invoices, and mechanics who perform che work. Figure 6-15 shows a possible use case
diagram for the auro service department.
FIGURE 6-1 '4 A cyplal auto service department might involve custome". service
write"
..
who prepare work orde" and invoices. and mechanics who perform the wo/1(.
"
\'<'hen a use case diagram is crearcd, the first step is co ide11cify the sysrcm
boundary, which is represented by a recrangle. T he system boundary shows whar is
included in rhe system (inside che recrangle) and whar is nor included in rhe system
(outside the rectangle). After the system boundary is identified, use cases are placed
on the diagram, the actors arc added, and the relationships shown.
CASE IN PO INT 6.2:
H1u.;roP MoroRs
You were hired by Hilltop Motors as a consultant to help the company plan a new information
system. Hilltop is an old-line dealership, and the prior owner was slow to change. A new management
team has taken over. and they are eager to develop a first-class system. Right now, you
are reviewing the service department. which is going through a major expansion. You decide to
create a model of the service department in the form of a use case diagram. The main actors
in the service operation are customers. service writers who prepare work orders and invoices,
and mechanics who perform the work. You are meeting with the management team tomorrow
morning. How would you create a draft of the diagram to present to them?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 6
Object Modeling
190 6.8 The Unified Modeling Language (UML)
Use Case Diagram: Auto Service Department
Requests
service
Writes
Customer
Update
Service
Writer
Update
Work
Schedule
Mechanic
Performs
work
Prepare
Invoice
FIGURE 6-1 S A use case diagram to handle work at an auto service department.
6.8.3 Class Diagrams
A cl:u~ diagram shows the object classes and relationships involved in a use case. Like
a DFD, a class diagram is a logical model, which evolves into a physical model and
finally becomes a functioning information system. In ~rructurcd analysis, enritics, data
stores, and processes are transformed into data structures and program code. Similarly,
class diagrams evolve into code modules, daca objects, and other system components.
In a class diagram, each class appears as a recrangle, with the class name at the
top, followed by the class's attributes and method~. Lines &how relationships berween
classes and have labels identifying the action that relates the two classes. To create
a class diagram, review the use case and identify the classe~ that panicipate in the
underlying business process.
The class diagram also includes a concept called cardinality, which describes how
instances of one class relate to instarnces of another class. For example, an employee
might h:ive e:irned no vocation days or one vacation day or many vacation doys.
Similarly, an employee might have no spouse or one spouse. Figure 6- 16 shows
v:irious UML notations and cardinaliity examples. Note char in Figure 6· 16, the first
column shows a UML notation symbol that identifies the relationship shown in the
second column. The third column provides a typical example of che relationship,
which is described in the last column. In the first row of the figure, the UML notation
0 .. • identifies a zero or many relation. The example is thar an employee can have no
payroll deductions or many deductions.
Figure 6-17 shows a class diagram for a sales order use case. Note rhat the sales
office has one sales manager who can have anpvhere from zero to many sales reps.
Each sales rep can have anywhere from zero to many customers, but each customer
has only one sales rep.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
6.8 The Unified Modeling Langu age (UML)
I 9 1
UML Nature of the Example Description
Notation Rellltlonshlp
o .•
Zero or many
0 .• 1 Zero or one
Employee
Payroll Deduction
1 0 . •
Employee
H
Spouse
0 .. 1
1 One end only one I Office Manager
H
Sales Office
t: One or many
1 1
An employee can have no payroll
deductions or many deductiOns
An employee can have no spouse or
one spouse
An olfoce manager manages one and
only one olfice.
Order
H Item Ordered One order can include one or many
items ordered
t..•
FIGURE 6· 16 Examples of UML notations that Indicate the narnre of che relationship between instances of one class
and instances of another class.
S11h!s Manager
Attributes
1
Manages
Methods
Manages
Methods
1 1
Assigned
o ..•
Attributes
Methods
Methods
Attributes
Includes
1 . .-
Items Ordered
Attributes
Methods
Methods
FIGURE 6-17 Class diagram for a sales order· use case (attributes and
methods omitted for clarity).
CASE IN POINT 6.3: TRAIN THE TRAl:."JERS, INC.
Train the T ralner develops seminars and workshops for corporate training managers, who in tum
train their employees. Your job at Train the Trainer is to put together the actual training materials.
Right now, you are up against a deadline. The new object modeling seminar has a chapter on
cardinality. and the client wants you to come up with at least three more examples for each of
the four cardinality categories listed in Figure 6-1 6. The four categories are zero or many. zero or
one. one and on"t one. and one or many. Even though you are under pressure, you are detennined
to use examples that are realistic and familiar to the students. What examples will you submit/
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 6
Object Modeling
192 6.8 The Unified Modeling Language (UML)
6.8.4 Seque nce Diagrams
A ~cqu ence diagram is a dynamic model of a use case, ~howing the inreracrion among
classes during a specified rime period. A sequence diagram graphically documents
the use case hy showing che classes, r:he messages, and the riming of the messages.
Sequence diagrams include symbols that represent classes, lifelines, messages, and
focuses. These symbols are shown in Figure 6-18.
a,,112
Life line
Message 1
I
I
Focus Focus I
I
Message 2
I
I
I
I ~ Lifeline
*
FIGURE 6 -18 A sequence diagram with two cla.nes. Notice the X that
indicates the end or the Cl.ASS 2 lifeline. Also noace that each message is
represented by a line with a label that describes the me=ge, and that each
class has a focus that shows che penod when messages are sent or received.
C LASSES: A class is idcnrified by a rectangle with the name inside. Classes char send
or receive messages arc shown ar the top of the sequence diagram.
LIFELINES: A lifeline is identified by a dashed line. The lifeline represents the time
during which the object above iris able ro interact with the other objects in the use
case. An X marks the end of rhe lifcljne.
MESSAGES: A message is identified by a line showing direction that runs between
two objecrs. The label shows the name of the message and can include additional
information abour the contencs.
A focus is identified by a narrow vertical shape that covers the lifeline.
FOCUSES:
The focus indicates when au object sends or receives a message.
Figure 6-19 shows a sequence diagram for the ADD NEW STUDENT use case in
the fitness center example. Note that the vertical position of each message indicates
the riming of the message.
6.8.S State Transition Diagrams
Earlier in this chapter, it was explained that state refers to an object's current status.
A state rran ~ i t ion diagram shows how an object changes from one scare co another,
depending on events that affect the object. AU possible states must be documented in
the state transition diagram, as shown in Figure 6-20. A bank account, for example,
could be opened as a NEW account, change co an ACTIVE or EXISTING account,
and eventually become a CLOSED or FOR:vtER account. Another possible stare for a
bank account could be FROZEN, if the account's assers are legally anached.
(....,..... J:gi ( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
6.8 The Unified Modeling language (UML)
193
Request
I
I
fitness-class Check I
I I I
I Notify
Focus I I I
I Pay I I
I Register I
I
I
I
*
FIGURE 6- 19 The sequence diagram for the ADD NEW STUDENT use case. The use case
dcscripdon for ADD NEW STUDENT Is shown in Figure 6-13.
Bank closes account
Opens
account
Makes l1rst
deposit
Act
Existing
Customer closes account
Assets
attached
Frozen
FIGURE 6-20 An example of a sate crans1don diagram for a bank account.
ln a state transition diagram, the states appear as rounded rectangles with the
stare names inside. The small circle ro rhe left is rhe initial stare or rhe point where
the object first interacts with rhe system. Reading from left ro right, the lines show
direction and describe the action or event that causes a transition from one state to
another. The circle at the right with a hollow border is the final state.
6.8.6 Activity Diagrams
An acti\ity diagram resembles a horizontal flowchart that shows rhe actions and
evenrs as they occur. Activity diagrams show the order in which rhe actions rake
place and identify the outcomes. Figure 6-21 shows an activity diagram for a cash
withdrawal ::it an ATM machine. Note that the customer initiates the activity by
inserting an ATM c::ird and requesting cash. Activity diagrams also can display
multiple use cases in the form of a grid, where classes are shown as vertical bars and
actions appear as horizontal arrows.
Sequence diagrams, state transition diagrams, and activity diagrams are dynamic
modeling tools that can help a systems analyst understand how objects behave and
interact with the system.

Chapter 6
Object Modeling
194
6.8 The Unified Modeling Language (UML)
Customer
Inserts
ATM card
Card is
accepted
Custom41r
enters PIN
PIN ts
accepted
Customer
requests
~sh
Sufficlenl funds available
ATM
ltd Justs
balance
ATM
provides
cash
Sufficient funds nol available
ATM
notifies
customer
FIGURE 6-2 1 An activity diagram $howing the a.ction$ and evcnrs Involved In wlLhdrawlng cash from an ATM.
6.8. 7 Business Process Mode ling
In addirion to sequence diagrams and acrivity diagran1s, business process modeling
(BPM) can be used to represent the people, events, and interaction in a system. BPM
initially was discussed in Chapter 4 as a requircmenc diagramming tool, bur ir can be
used anytime during tbe systems development process. BPM works well with object
modeling, because both methods focus on the actors and the way they behave.
There arc a number of cools supporting BPM. For example, on Windows, the
Bizagi N!odclcr rool supports business process modeling and simulation using the
standard BP:tvl notation. On the w1ac, Visual Paradigm supports the creation of BP.M
diagrams {and several other modeling notations). Figure 6-22 shows a sample BPM
for an online discussion cycle.
~ Tl·-·
l'M•WflftN
•
Ollcv.on 0••.
Nt .. , ...
.........
u-- -i ,_ .. ,,__
r a; ~__,.i o--
.........
1--M')
•
.... ' _ ,.. 111.
~
1oc •.-...........
IYOu9" •• Of c •••
-..... ,_
...
...
.. ....
c .,,..nc. c.. 1----"
.,__
FIGURE 6-22 A BPM for an online discussion cycle.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
6.10 Summary
195
6.9 TOOLS
Object modeling requires many types of diagrams to represent the proposed
system. Creating the diagrams by hand is time consuming and tedious, so systems
analysts rely on tools to speed up the process and provide an overall framework for
documenting the system components. In addition, cools ensure consistenq' and provide
common links so that once objects are described and used in one pare of the
design, they can be reused mulriple times without further effort.
There arc many CASE tools tailored to UML. Tools such as Visio are popular for
drawing UM L diagrams, but they lack semanrics: They are useful for creating visually
pleasing figu re , but they have no knowledge of the underlying artifacts. This means a
system~ analyst can create diagrams that appear co be correct but are in fact incorrect
when it comes to rhe rules of the UM L.
To overcome this shortcoming, proper systems modeling tools, such as Cameo
Systems Modeler or IBM's Rational product family, are typically used. These rool
underlttand the meaning of the diagrams they hel!P create, wh ich suggests it's difficult
to create a UM L diagrnm that is syntactically incorrect. These tools al!.o provide
traceability, an important feature in the SDLC that links design artifacts backward ro
requirements and fo rward to development and testing.
Your company sent several staff members for UML training by an outside vendor.
Everyone who attended the training received a copy of the instructor s materials. which
included study guides and sample exam questions and solutions.
After completing the training course, you are eligible to sit a certification exam. If you
pass the exam, you will be credentialed as a "UML Expert" by an independent agency. You
can parlay these credentials into a higher salary and boost your career.
A coworker who did not attend the training asks for a copy of the training materials.
He wants to take the exam without "wasting his time in class." Should you give him a
copy of the training materials1 If you do, how might this diminish your accomplishments?
If you don't. would you be hurting the team by not helping another member become more
knowledgeable about the UMU
6.10 SUMMARY
This chapter introduced object modeling, which is a popular technique th::it
describes a system in terms of objects. O bjects represent real people, places, events,
and rransactions. Unlike structured analysis, which treats data and processes
separately, objects include data and processes that can affect the data. During the
i.mplemenrntion process, systems analysts and programmers transform objects into
program code modules that can be optimized, tested, and reused as often as necessary.
0-0 terms include arrributcs, methods, messages, and classes. Attributes arc
characteristics that describe the object. Methods a re tasks or functions that the object
performs when it receives a command co do so. O bjects can send messages, or commands,
that require other objects to perform certain methods, or tasks. The concept
that a message gives different meanings to different objects is called polymorphism. An
object resembles a black box with encapsulated, or self-contained, data and methods.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... . ... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 6
Object Modeling
196 6.10 Summary
Classes include objects that have similar attributes, or characteristics. Individual
members of a class are called object instances. Objeccs within a class can be grouped
into s ubcla s~es, which are more specific categories within the class. A class also can
belong to a more general category called a superclass.
Afrer identifying the objecrs, classes, and relationships, an object relationship diagram
is prepared chat hows the objecrs and how chey interact co perform business
fun crions and cransacrions. The Strongest relationship between object~ is inheritance.
The UML is a widely used method of visualizing and documenting an information
system. UML techniques include use cases, use case diagrams, class diagram~,
sequence diagrams, state transition d iagrams, and activity diagrams.
A use case describes a business situation initiated by an actor, who interacts with
the information system. Each use case represenrs a specific transaction, or scenario.
A use case diagram is a visual summary of related use cases within a S)'Stem or subsystem.
A class diagram represents a detailed view of a single use case, showing the
classes that participate in the underlying business transaction, and the relationship
among class instances, which is called cardinality. A sequence diagram is a dynamic
model of a use case, showing the interaction among classes during a specified time
period. Sequence diagrams include lifelines, messages, and focuses. A state transition
diagram shows how an object changes from one state to another, depending on events
that affect the object. An activity diagram resembles a horizontal flowchart that
shows accions and events as they occur in a system.
In addition co object models, business process modeling (BPM) can be used ro represenc
the people, evencs, and interaction in a sysrem.
CASE tools provide an overall framework for system documentation. CASE cools
can speed up rhe development process, ensure consistency, and provide common links
that enable reuse during 0 -0 analysis.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
Key Terms
197
Key Terms
acti\lt) J1<lgram A diai,-ram rh<lr re-.emble!> a borizonral flowcbarr chat •how~ the acnon; and eveni- 3\
the) occur. Act,.lt) diagram; sho" the order in which acno11> rake place and idennf) the out~ome.
actor An external emit) wnh a spectfic role. In a use case model. actors are used to model mtcran1on
with the system.
aunbutc A sm1dc char.icrensnc or fact about an ennty. An annbuce, or field, 1s the smallest p1«e of d.ua
that has meaning wnhm an informanon srstcm. For example, a Social Security number or company
o.ime could be examples of an anribute. In 0-0 analysis, ao attribure is parr of a d.t~s diagram that
describes the -.haractensuc, of ob1ccts in the class. Also kno" n as a data element.
black box A metaphor for a proces' or an action thar produces resulr; in a nun-tramparent or
non-ob,ervablc manner. In daca flow diagram,, a proces~ appears as a black bo" where chc input,,
output,, and 11cncral fonction of the procc\S arc known, but the undcrlyini; dcta1b arc nor ,hown.
cardinal1C) A concept that dc•cribe< how m<tancc• of one entity rdarc to imtancc< of nnuthcr cnmy.
De,eribcd in cntiry· rc l arion~hip dinwams by notation chm indicates comhination~ that include 1ero or
onc·to· mnny, onc·lo-onc, and many-ro·mnny.
child ln i.11herit.1nce, J child is 1he object thar derives one or more arrribuces from another object, called
tbe parem.
cl.ISS A cerm used 111 ob1ecc-or1e11red modelmg ro indic.1te a collection of snrul.ir ob1ec1s.
da,., dia11ra111 A detailed view of a ,inglc U'>c ca•c, ,howing rhc da,~ char parcicipatc in the U'>c ca'>C,
.md dc,.:umcnrini; rhc rclatinn•hip among rhc da<<es.
cncap,ulatoon The idea that all data and methods arc self-contained, as in a black bo"<.
focus In a sequence diagram, a focus md1carcs when an objecr sends or rec(wes a message. It 1s indicated
b) a narrow vertical rcctJngle thJt co,ers the lifeline.
iobcric.tncc At) pe of object relationslup. Inheritance enables an object to derive one or more of its
.i.tmbute~ from another objecc (t.g., an INSTRUCTOR object may lllhecit man) traus £rom che
L/\11'LOYll ob1ecr, such as hire dare).
in.,~n.:c
A ,pcc1fic member of a da>s.
lifeline In a \cqucn"c diagram, a lifeline 1s u..cd ro represent the time during which rhc ob1c<t above it i~
able to mrcract with rhc orhcr objccrs in rb<" u..c ca<e. An X marks rhc end of a hfchnc.
message An 0 -0 command thac cells an ob1ec:t ro perform a certain method.
mcchod Defines sp«1fic casks chac an object must perform. Describes what and how an obiccr does
something.
object RepreM:nt\ a real person, place, C\'ent. or transaction.
objecc model Dc~crihe~ oh1ecr~, which combine darn and processes. Object models are chc cnJ produce
of O·O analybb.
objecc-orienced (0 -0 ) anJly~i; Describes an lnformarion system by idenrifymg things called objects.
An ob1ect reprc,cnt~ a real per<oon, place, evenr, or cransacnon. 0-0 :tnalysis is .1 popular appro,tch
that sees a ~ystem from the viewpoinr of rhc objecrs themselves ,1s they function and interact w1rh 1 he
system.
parent Ill i11herirnncc, n parent i~ the objecr from which the other object, the child, derives one or more
Jttnbucc>.
polymorphm11 The con~cpt chat a me ... age gives different meanings ro diffcrcm ob1cc1s (e.g., a GOOD
NIGi IT message m1ghr produce different rcsulrs depending if it 1s received by a child or the family
dog).
rclatiomhip<> Enable objccr' to communicate and inreract a~ rhey perfonn rhe btmncs' funcnoM and
transaction; required by a syo;tcm. Relationships describe wbar objects need to kno\\ abouc each other,
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 6
Object Modeling
198 Key Terms
how ob1ec1s r~pond to changes in orher objecrs, and 1he effccrs of mcmbcnh1p m classes, superdasscs.
Jnd subclasses.
~cqucncc diagram A diagram rhat sho\\ s tht> timing of transactions bcrwcen ob1ccrs as 1he) occur.
\late An aJ1e~ri•e that de...:ribe; an oh1ecc's current scaru; (e.g., a ;rudmt could be a CURRENT,
rlITURF, or PAST ~1udenr).
•talc tr;m\ltmn J1a11ram !>how' how an oh1cct cbani:"-' from one \tat.: to another, depending on 1he
cvcnc- that affe<:t the object.
subclas\ A funhcr d1v1s1on of oh1ecrs m a class. Subclasses are more ~pccific categories w1rh1n a class.
superclass A more gener.1liicd category ro which objects may belong (e.g., a NOVEL cl.1ss might belong
10 J superclass called BOOK).
W\lcm boundary Shows wha1 is included and excluded from a >yMem. Depicted by n ,haded rccrangle
in u...: ca'c diagram>.
Unified M0Jdm1o: Lm11o:ua)lc (UML) A wicldy used method of vi,uali1.ing and documen1ini; >of1wnrc:
'Y'tcm' dc,ii;11. UM I u'c' 0-0 design concepts, but it;, independent of ony 'Jl«cific rrui.1ra111mini;
lnni;nngc ond can he u~ccl m describe business processes and requirement' f;cncr:tlly.
use case Represents che s1eps in a specific business function or process in UML.
use c:t~c dc~criprion
A dcscnprion in UML char documems the name of the use cJsc, 1he .1ctor, a
dcscrip1ion of the use case, a s1ep-by-srep lisc of the tJsks required for successful completion, and
01her key descnpnons and assumptions.
uw c;hc diai;r.:tm A vi,ual repre..enrarion chat illusrrare-. the interacuon between U'>e" anJ rhe
i11format1on 'l'rcm in UM!..
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

I
Phase 2
Systems Analysis
Exercises
199
Exercises
Questions
I. Whar 1s 0-0 analysis?
1. Define an ob1ect in an information system and provide rhree examples.
3. Define an attribute and provide rhrcc examples.
4. Define a method and provide rhree examples.
5. Define e11caps11/atio11 and explain how ir is used in 0-0 analysis.
6. Define a class, subclass, and superclass and provide rhree examples of each.
7. Explain rhe concept of inherirance in object relationships.
8. Draw an object relationship diagram for a rypical library system.
9. Define a use case and a use case diagram and prepare a sample of each.
I 0. Why is ir imporranr co use a modeling rool and nor just a diagramming rool
during 0-0 analysi~?
Discussion Topics
I. You arc an IT consulranr, and you arc asked co create a new sysrem for a small
real esrarc brokerage firm. You have no experience with 0-0 approach, and you
decide co rry ir. How will you begin? How will the tasks differ from ~rrucrurcd
analysis?
1. Some professionals believe char ir is harder for experienced analy~rs ro learn
object-modeling rechniques, because the analysts are accustomed to thinking
abour data and processes as separate entities. Ochers believe that ~olid analytical
skills are easily transferable and do not see a problem in crossing over ro the
newer approach. Whar do you chink, and why?
3. The concept that rhe same message gives different meanings ro different ob1ects
is called polymorphism. Can you chink of examples where this behavior may
provide une'<pected results?
4. You arc crearing a sysrcm for a bowling alley to manage information about its
leagues. During rhe modeling process, you create a scare transition diagram for
an objecr called League Bowlers. \Xl'har are rhe possible scares of a league bowler,
and what happens to a bowler who quits rhe league and rejoins the following
season?
5. The UML is a large and complex modeling language. How can an IT profc~sional
tell when a UML diagram is correct and nor just visually plea~ing?
Projects
l. Contact the IT htaff ar your school or ar a local business to learn if they use 0-0
programming languages. lf so, determine what languages and versions are used,
how long they have been in use, and why they were selected.
2. Create a prcscnrnrion explaining 0-0 analysis, including definitions of basic
terms, including objects, attributes, methods, messages, and classes.
3. Draw an acriviry diagram showing rhe actions and evenrs involved in depositing
a check to a bank accounr using a mobile app.
4. Investigate business process modeling languages, such as BPEL.
5. Prepare a report on at lease three cools char provide UML support. Use the
tools' capah1liries for crearing class diagrams and sequence diagrams as a key
requ1remenr.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 7
Development Strategies
Development
Strategies
Chapt er 7 is the final chapter in the systems
analysis phase of the SDLC. The main objective of
the systems analysis phase is to build a logical model
of the new information system. Chapters 4, S, and 6
explained requirements modeling. data and process
modeling. and object modeling. Chapter 7 describes
the remaining activities In the systems analysis phase,
which include evaluation of alternative solutions,
preparation of the system requlremenu document,
and pre.sentation of the system requirementS
document to management. The chapter also explains
the transition to systems design.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" concerns
how truthful an answer should be when submitting a
response to an RFP. Is a slight exaggeration acceptable if
it means the company will win the contract!
LEARNING OBJECTIVES
W/Jen you finish tbis chapter, you sl101tld be able
to:
l. Explain the differences between traditional and
web-based S)Stems development
2. Explain how Web 2.0, cloud computing, and
mobile devices may affect systems development
3. Explain how to selecr one of the four in-house
:.oftware development options
4. Explain outsourcing
5. Explain the main advanrages and the unique
concerns of off:.horing
6. Describe rhe concept of Sofrware a~ a Service
7. Explain how a systems :rnalysr helps in selecting
a development strategy
8. Execute the five steps in the software acquisition
process
9. Describe a requesr for proposal (RFP) and a
request for quotation (RFQ)
I 0. Summarize the rasks involved in completing the
srstems analysis phase of rhe SDLC
CONTENTS
7. 1 Traditional Versus Web-Based Systems
Development
7.2 Evolving Trends
7.3 In-House Software Oevelopmenc Options
Case in Point 7.1: Doug·s Sporting Goods
7.4 Oursourcing
7.5 Offshoring
Case in Point 7.2: Turnkey Services
7.6 Software as a Service
7 .7 Selecting a Development Strategy
Case in Point 7.3: Sterling A~sociares
7.8 The Software Acquisition Process
7.9 Completion of Systems Ana lysis Tasks
A Question of Ethics
7.10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 2
Systems Analysis
7.1 Traditional Versus Web-Based Systems Development
201
7.1 TRADITIONAL VERSUS Wee-BASED SYSTEMS DEVELOPMENT
]use a few years ago, a rypical company either developed software itself, purchased
a software package (which might need some modification), or hired consulcants or
outside resources to perform the work. Today, a company has many more choices for
software acquisition, including application service providers, web-hosted software
options, and firms that offer a variety of enterprise-\vide software solucions. This proliferarion
of choices is due in part due to the enormous changes in business methods
and operarions made possible by the Internet.
A systems analyst must consider whether development will cake place in a rra·
ditional environment or in a web-centric framework. There are similarities and differences
with both approaches. For example, in an Internet-based sy~tem, the web
become~ an inregral parr of the application, rather than jusr a communication channel,
and systems analysts need new applicarion development tools and &olutions tO
handle the new systems.
Two represenrarive web-based development environmenrs are Microsoft's .NET
and rhe open source MERN stack. Microsoft describes .NET as a developer platform
for building and running a variety of applica tion types written in C# and
Visual Basic, including web-based, mobile, and traditional deskrop applications.
The acronym M ERN srands for MongoDB, Express, React, and Node. MERN
is used to develop universal applications in JavaScript. MongoDB is a darabase,
and Express, React, and Node arc libraries or frameworks used for full -srack web
development.
Although cherc is a major trend toward web-based architecture, many firms rely
on traditional systems, either because they arc using legacy applications that arc not
easily replaced, or because they do not require a web component to satisl) user needs.
To choose berween traditional and web-based development. consider some key differences
between them. Building the application in a web-based environment can offer
greater benefits (and sometimes greater risks) when compared to a traditional environment.
The following sections list some characteristics of traditional versus webbased
development.
7. 1. 1 Traditional D evelopment In a t.radit.ional systems development.
environment.
• Compatibility issues, including existing hardware and software platforms and
legacy system requirements, influence systems design.
• Systems arc designed to run on local and wide-area company networks.
• Systems often utilize Internet links and resources, but web-based featu res arc
treated as enhancemen ts rather than core elements of the design.
• Development rypically follows one of three main paths: in-house development,
purchase of a boftware package with possible modific~Hion, or use of outside
consultants.
• Scalability can be affected by network limitations and constraints.
• Nlany applications require subsranrial desktop computing power and resources.
• Security issues usually arc less complex than with web-based systems,
because the system operates on a private company network, rather than the
Internet.

Chapter 7
Development Strategies
202 7.2 Evolving Trends
7.1 .2 W eb-Based Development: In a web-based systems development
environme nt
• Systems arc developed and delivered in an Lncerncr-ba~ d framework such as
.NET
• lnrernet-bascd development rrears the web as rhe platform, rather than just a
communication channel.
• Web-based systems are easily scalable and can run on multiple hardware
environments.
• Large firms rend to deploy web-based sysrems as enterprise-wide software solutions
for applications such as customer relationship management, order processing,
and materials management.
• Web-based software treats the software application as a service that is less
dependent on desktop computing power and resources.
• When companies acquire web-based software as a service rather than a product
rhey purchase, they can limit in-house involvement and have rhe vendor insrall,
configure, and mainrain the system by paying agreed-upon fees.
• Web -ba~ed software usually requires additional layers, called middleware, to
communicate with existing software and legacy systems.
• Web-based solutions open more complex security issues that should be addressed.
7.2 EVOLVING TRENDS
In the consrantly changing world of IT, no area is more dynamic than lnrerner rechnology.
Three examples of evolving trends arc Web 2.0, cloud compuring, and mobile
devices. Sysrems analysts shouJd be aware of these trends and consider them as they
plan large-scale sysrems.
NIST Cloud Computing Program - NCCP
DESCRIPTION
a.....,...i. .........................
---.-
,
""""""....,..n..,... .....,..,..... ,••
.
~,.......,. ...
.., ~
---
~ ..... !'@I.....
.... ~,...~
fltolt• Wwt.f~
llltl'Klloa. TNldeuf
___ ... _
NIST Cloud
Computing
Program
... ~.,"" ....... ~ ....... Will l#IW• ......"""*' l(Q1l.
18M(f ..........."'*"" ....... ~,_ ....... Cf ..... ~~ ...
~ CS...S~ C..."*'" •••"""9(P'HSi,a-.... ~ ••...... tM-S ... ...
................... ~ hlkm.tlJl!rtiN ~ ....,.,..-....111•...............,ta...................,................_... ca
._,...,.nm..,................_.~
llirClilwf~ ~"'~-................................ ...
....._••__............._......,.,._......,.... w,,....,..,.
...............-.c...--................................ Ml'W"
............................................_,a...
......... ~.._. .......... WI*" •• kll ....,.,.............
..,.._. ....... .......
FIGURE 7- 1 NIST definition of cloud computing.
5-«< "'
Many IT professionals use the term \''cb 2.0 ro describe
a second generation of the web rhat enables people ro
collaborate, interact, and share information much more
effectively. This new environment is based on conrinuously
available user applications rather than Static HTJ\-1 L wcbpages,
wirhour limitations regarding rhe number of users or
how they access, modify, and exchange data. The Web 2.0
environmenr enhances interactive experiences, including
wikis and biogs, and social networking applications such as
Facebook, Linkedln, and Twiner .
As shown in Figure 7- 1, the National Institute of Standards
and Technology (NIST) defines cloud computing as
"a model for enabling ubiquitous, convenient, on-demand
network access ro a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications, and
services) chat can be rapidly provisioned and relea ed with
minimal management effort or service provider interacrion."
Cloud computing is often represented by a cloud symbol
that indicates a network or the Internet. Cloud computing
can be viewed as an onlioe SaaS and data environment supported
by powerful computers that makes Web 2.0 possible.
(....,..... J:gl( .....,_,.. 41 11.,.. ~-""'_..,.Olp" • ._..,.. -·~·-"*<'f•,... 0w.,,,.._._,..." .......,_,.,..,....,. -~,__.., ,,.......... ~~ij
r..a...w...,..._...., ....,...,.......,..~................. t11ru ..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
7.3 In-House Software Development Options
Phase 2
Systems A nalysis
203
Mobile device~ have become ubiquitous. Smartphones and tablets are now found
in personal use and across the enterprise in most organizations. Today's mobile
devices have enough computing power to provide processing "at the edge," which
means at the end of a network, in rhe user's hands. Developing apps for mobile
devices requires many new platforms, although many of today's development tools
support web-based and mobile application development at the same time.
7 .3 IN-HOUSE SOFTWARE DEVELOPMENT OPTIONS
A compan)' can choose to develop its own systems or purchase (and possibly customize)
a sofrw:ire package. These development alternatives arc shown in Figure 7-2.
Although many factors influence this decision, rhe mosr important consideration is
rhe total cost of ownership (TCO), which was explained in Chapter 4. In addition to
rhcse options, comp:inies also develop user applications designed around commercial
sofrw:ire packages, such as Microsoft Office, ro improve user productivity and
efficiency.
In-house syslem
software
Commercial
soltware
padtage
FIGURE 7-l Instead of outsourcing.a company can choose co develop a system in-house or
purchase and possibly aJstomize a commercial package..
7 .3.1 Make or Buy Decision
The choice between developing ver[>uS purchasing software often is called a make
or buy, or build or buy, decision. The company's IT department makes, builds, and
develops in-hou\e \Oftware. A software package is obtained from a vendor or an
application service provider.
Tht: package might be a standard commercial application or a customized package
designed specifically for the purchaser. Companies that develop f>ofrware for sale
are caUed software vendors. A firm that enhances a c.:ommercial package by adding
custom features and configuring it for a panicular industry is called a value-added
reseller (VAR).
Software package~ are available for every type of business activity. A software
package that can be used by many different types <>f organizations is called a horizontal
application. An accounting package is a good example of a horizontal application
because man)' different businesses or separate divisions that exist in large, diversified
companies can utilize it.
In contrast, a software package developed co handle information requirements for
a specific type of business is called a vertical application. For example, organizations
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~---- ···---~~ - .,.-"~ ........... --......

Chapter 7
Development Strategies
204 7.3 In-House Software Development Options
with special system requirements include colleges, banks, hospitals, insurance companies,
construction companies, real estate firms, and airlines. Figure 7-3 shows a
typical restaurant point of sale (POS) system running on various devices. The organi-
7ations may need verrical applications to handle their unique business requirements
bur often use horizontal applications for basic business needs, such as payroll proce s­
ing and accounts payable.
Thousands of Restaurants Use Restaurant Manager
Tne POS of Chc><ce f0t Restauronts for Neosty 30 Yeors
FIGURE 7-3 Restaurants use vertical applications like point of sale (POS)
systems to support their unique business requirements.
Sour<e; .-
•
Of the in-house software acquisition options-developing a sy rem, bu) ing a
software package, or customizing a software package-each ha~ advantages, disadvantage~,
and cosr considerations, as shown in Figure 7-4. These l>Ofrware acquisition
options are described in detail in the following sections.
REASONS FOR IN-HOUSE
DEVELOPMENT
Saosfy unique business requirements
Minimize changes in business procedures
and policies
Meet constraints of existing systems
Meet constraints of existing technology
Develop Internal resources and capabilities
Satisfy unique security requirements
REASONS FOR PURCHASING A
SOFTWARE PACKAGE
Lower costs
Requires less time to implement
Proven reliability and performance
benchmarks
Requires less technical development staff
Future upgrades provided by the vendor
Obtain input from other companies
FIGURE 7-4 Companies consider various factors when comparing in-house development with the purchase of a
software package.
7.3.2 Developing Software In-House
\Vith an enormous variery of software packages available to handle horizontal
and vertical business operations, why would a firm choose to develop its own software?
Typically, companies choose in-house development to satisfy unique business
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
7.3 In-House Software Development Options
205
requirements, minimize changes in business procedures and policies, meet constraints
of existing systems and existing technology, and develop internal resources and
ca pa biliries.
SATISFY UNIQUE BUSINESS REQUIREMENTS: Companies often decide to develop
software in-house because no commercially available software package can meet
their unique business requirements. A college, for example, needs a course scheduling
system based on curriculum requirements, student demand, classroom space, and
available instructors. A package delivery company needs a system to identif>• the
best combination of routes and loading panerns for the company's fleet of delivery
trucks. If existing software packages cannot handle those requirements, then in-house
developed sofcware might be the only choice.
MINIMIZE CHANGES IN BUSINESS PROCEDURES AND POLICIES: A company
also might choose to develop its own software if available packages will require
changes in current business operations or processes. lnstalling a new software
package almost always requires some degree of clhange in how a company docs
business; however, if the insta llation of a purchased package wil l be too disruptive,
the organization might decide to develop its own software instead.
MEET CONSTRAINTS OF EXISTING SYSTEMS: Any new software installed must
work with existing systems. For example, if a new budgeting system must interface
with an existing accounting system, finding a sofrware package that works correctly
with the existing accounting system might prove difficult. If so, a company could
develop its own software to ensure that the new system will interface with the old
system.
MEET CONSTRAINTS OF EXISTING TECHNOLOGY: Another reason to develop
software in-house is chat rhe new system must work with existing hardware and
legacy systems. That could require a custom design, an upgrade ro the environment,
or in-house sofrware that can operate within those constraints. A systems analyst
addresses the issue of technical feasibiliry during the preliminary investigation. Now,
in the sy~tems analysis phase, the analyse muse determine whether in-house software
development is the best overall solution.
DEVELOP INTERNAL RESOURCES AND CAPABILITIES: By designing a system
in-house, companies can develop and crain an IT staff who understands the
organization's business functions and information support needs. Many firms feel
that in-house IT resources and capabilities provide a competitive advantage because
an in-house ream can respond quickly when business problems or opportunities arise.
For example, if a company lacks internal resources, it must depend on an outside fi rm
for vital business support. Also, outsourcing options might be actraccive, but a series
of shore-term solutions would nor necessarily translate into lower TCO over the long
term. Top managers often feel more comfortable with an internal IT team to provide
overall guidance and long-term stability. In-house development also allows a firm co
leverage the skill set of the IT team, which is already on board and being compensated.
7.3.3 Purchasing a Softwa.re Package
If a companr decides not to outsource, a commercially available software package
might be an attractive alternative co developing irs own software. Advantages of purchasing
a software package over developing soft·Nare in-house include lower coses,
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 7
Development Strategies
206 7.3 In-House Software Development Options
less rime to implement a sysrem, proven reliabiliry and performance benchmarks, less
technical development staff, future upgrades chat are provided by the vendor, and
the ability to obrain input from other companies who already have implemented the
software.
LOWER COSTS: Because many companies use software packages, software vendors
spread the development costs over many customers. Compared with software
developed in-house, a software package almost always is less expensive, parricularly
in terms of initial i11vesnnent. However, even though the initial cost is less, purchased
software can involve expenses caused by business disruption, changing business
processes, and retraining employees.
REQUIRES LESS TIME TO IMPLEMENT: When a software package is purchased,
it already has been designed, programmed, rested, and documented. The in-house
rime normally spent on those tasks, therefore, is eliminated. Of course, rhe
sofrware must still be installed and integrated into the systems environment,
which can rake a significant amount of time. Also, even though implementation
is quicker, TCO can be higher due to added training expenses and software
modifications.
PROVEN RELIABILITY AND PERFORMANCE BENCHMARKS: If the package has
been on the market for any lengcb of rime, any major problems probably have been
detected already and corrected by the vendor. if the product is popular, it almost
certainly has been rated and evaluated by independent reviewers.
REQUIRES LESS TECHNICAL DEVELOPMENT STAFF: Companies that use
commercial software packages often are able to reduce the number of programmers
and systems analysts on the IT sraff. Using commercial software also means that
the IT staff can concentrate on systems whose requirements cannot be satisfied by
software packages.
FUTURE UPGRADES PROVIDED BYTHEVENDOR: Software vendors regularly
upgrade oftware packages by adding improvements and enhancements to create a
new version or release. A new release of a software package, for example, can include
drivers ro support a new laser printer or a new type of data srorage technology.
In many cases, the vendor receives input and suggestions from current users when
planning future upgrades.
INPUT FROM OTHER COMPANIES: Using a con11nercial software package means
that users in other companies can be contacted ro obtain their input and impressions.
Trying rhe package or making a site visit to observe the system in operation may be
very usefu l before a final decision is made. Companies can make use of user groups ro
share experiences with a software package.
7.3.4 Customizing a Software Package
lf the standard version of a software product does not satisfy a company's requirements,
the firm can consider adapting rbe package to meet its needs. Three ways to
customize a software package are as fo llows:
• Purchase a basic package that vendors will customize to suit the project's
needs. Many vendors offer basic packages in a standard version with add-on
components rhat are configured individually. A vendor offers oprions when the
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
7.3 In-House Software Development Options
207
standard applicarion will nor sarisfy all customers. A human resources informarion
sysrem is a rypical example, because each compan)' handles employee
compensation and benefics differently.
• 1 cgotiatc directly with rhe software vendor to make enhanccmcntS to meet the
project's needs by paying for the changes.
• Purchase the package and make project-specific modifications, if this is permissible
under the rerms of the sofrware license. A disadvantage of this approach is
that srsrems analysrs and programmers might be unfamiliar with rhe sofnvarc
and will need time to learn the package and make the modifications correctly.
Addirionally, some advanrages of purchasing a standard package disappear if
the product must be cusromized. If the vendor does the customizing, the modified
package probably will cosr more and rake longer ro obrain. Another issue is fururc
support: Although vendors regularly upgrade their standard software packages, rhey
might not upgrade a customized version. In addition, if the modifications are done by
the company purchasing the sofrwarc, when a new release of the package becomes
available, the company might have to modify the new version on it~ own, because the
vendor will not support modifications installed by the customer.
7 .3.S Creating User Applications
Business requirements sometimes can be fulfilled by a user application, rather th;in a
formal information system or commercial package. User applications arc examples of
user productivity systems, which were discussed in Chapcer 1.
A user applicalion utilizes standard business s<>ftware, sucb as Microsoft Word or
Microsoft Excel, which has been configured in a specific manner to enhance user productiv1ry.
For example, to help a sales rep respond rapidly co customer price requests,
an IT support person can sec up a form letter with links to a spreadsheet chat calculates
mcencives and discounts. ln addition to configuring the sofnvare, che IT staff can
create a user interface, which includes screens, commands, concrols, and features that
enable users to interact more effectively with tbe application.
In some siruauons, user applications offer a simple, low-cost solution. Mosr IT
departments have a backlog of projects, and IT solutions for individuals or small
groups do not always receive a high priority. At the same time, application software
is more powerful, flexible, and user-friendly than ever. Companies such as Apple
and Microsoft offer software suites and integrated applications that can exchange
dara with programs that include rurorials, wizards, and H elp features to guide lessexpericnced
users who know whar they need to do but do not know how to make it
happen.
Many companies empower lower-level employees by providing more access to dara
and more powerful data management tools. The main objective is co allow lower·
level employees more access ro the data rhey rcqUJire to perform their jobs, with no
intervenrion from the IT department. This can be accomplished by creating effecrive
user interfaces for company-wide applications, such as accounting, inventory, and
sa les systems. Another technique is to customize standard productivity software,
such as Microsoft \'Qo rd or Nlicrosofc Excel, ro create user applications. In either
case, empowerment makes the IT deparrment more productive because ir can spend
less time responding to rhe daily concerns and da{a needs of users and more rime on
high-impact systems development projects rhat support strategic business goals.
Empowerment reduces costs and makes good business sense, but Companie
chat adopt this approach muse provide the technical support that empowered users
require. In mo~t large- and medium-sized companies, a sen ice d~k within the IT
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 7
Development Strategies
208 7.4 Outsourcing
deparnnenr is responsible for providing user support. The service desk offers services
such as hotline assistance, training, and guidance to users who need technical help.
Users typically require spreadsheets, dacabase management programs, and other
software packages to meet their information needs. If user applications access corporate
data, appropriate controls must be provided to ensure data security and integrity.
For example, some files should be hidden totally from view; other-; should have readonly
properties, so users can view, bur nor change, the data.
CASE lN POINT 7.1:
Douc's S1•0RTING Goons
Doug's Sporting Goods sells hiking and camping supplies. The company has grown considerably
in the past tw0 years. They want to develop a customer order entry system and hired your
IT consulting firm to advise them about development strategies. They are leaning toward
in-house development because they do not want to depend on outside vendors and suppliers
for technical support and upgrades. They also S'irf they are not interested in selling on the Web,
but that could change in the future. They want to meet with you tomorrow to make a decision.
What will you say to them ac the meeting?
7 .4 OUTSOURCING
Outsourcing is the transfer of information sysrems development, operation, or maintenance
roan outside firm char provides these services, for a fee, on a temporary or
long-term basis. Outsourcing can refer co relatively minor programming tasks: renting
software from a service provider, outsourcing a basic business process (often called
business process outsourcing, or BPO), or handling a company's enrire IT function.
7.4. 1 The Growth of Outsourcing
Traditionally, firms out~ourced IT tasks as a way of controlling coses and dealing \vith
r:ipid technological change. Oracle cites data that ~hows that businesses spend up ro
80°/o of their IT budgets maintaining existing software and !>Y!>tems, which forces IT
managers " ... to spend rime managing tedious upgrade~ in~tead of revenue-generating
IT projects." \Xlhile those reasons srilJ are valid, outsourcing has become part of ::1n
overall IT strategy for many organizations. The outsourcing trend abo has ::1ffecred
software vendors, who have adjusted their marketing accordingly.
A fi rm drnr offers outsourcing solutions is called a service provider. Some service
providers concentra te on specific software applications; others offer business services
such as order processing and customer billing. Still others offer enrerprise-w idc software
solutions that integrate and manage functions such as accounting, manufacturing,
and inventory control.
Two popular outsourcing options involve application service providers and firms
tha t offer Internet business services. These terms are explained in the fo llowing
sections.
APPLICATION SERVICE PROVIDERS: An application sen ice provider (ASP) is a
firm that delivers a software application, or access to an application, by charging a
usage or sub~cription fee. An ASP provides more than a license to use the software;
it rents an operational package ro rbe cusromer. ASPs typically provide commercially
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

I '
I
Phase 2
Systems A nalysis
7.4 Outsourcing
209
available sofrwarc such as darabases and accounting packages. If a company uses an
ASP ro supply a dara managcmenr package, for example, rhe company does nor have
to design, develop, implemenr, or mainrain the package.
INTERNET BUSINESS SERVICES: Some firms offer Internet business ~e r\ ices (lBSs),
which provide powerful web-based support for transactions such a~ order proce sing,
billing, and customer relationship managemenr. Another term for IBS is managed
hosting, because the outside firm (host) manages system operations.
An IBS solunon is attracrive to customers because it offers online data center support,
mainframe computing power for mission-critical functions, and universal access
via the Internet. Many firms, such as Rackspace, compete in the managed cloud services
marker, as shown in Figure 7-5.
o,.."'.,.. , .. •
.._... ..,_........ -· -- -- ---
..
--
--
--
·--
.. - .. - .... ............ ~
_
.. _____ ........
VDU CllOGSf thf Clouds. Wf'll Ma~ge Tll!m for You.
--
....... __..... __ ...., . .._.
---
--~----,.. ... _.
- --
FIGURE 7-S Rackspace managed cloud services.
Sourc.1~ .o;,
7.4.2 Outsourcing Fees
Firms thar offer Software as a Service, rather rhan a product, have developed fee
structures that are based on how rhe application is used by customers during a
specific time period. Several models exist, including fixed fee, subscription, and usage
or transaction. A fixed fee model uses a sec fee based on a specified level of service
and user support. A subscription model has a variable fee based on the number of
users or workstations that have access ro the application. Finally, a usage model
or transaction model charges a variable fee based on the volume of transactions or
operations performed by the application.
When a company considers outsourcing, it should estin1ate usage characteristics co
determine which fee structure would be most desirable and tben attempt co negotiate
a service provider contract based on that model.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 7
Development Strategies
210 7.S Offshoring
7.4.3 Outsourcing Issues and Concerns
\'(!hen a company decides to outsource IT functions, it takes an imponant srep
rhar can affecr the firm's resources, operations, and profitability. IVlission-crirical
IT ~ystems should be oursourced only if the resulr is a cosr-anracrive, reliable
business solution that fits the company's long-term business strategy and involves an
acceprable level of risk. Moving IT work overseas raises even more issue5, including
potential concerns about control, culture, communication, and security.
In addinon to long-term strategic consequences, outsourcing also can raise some
concerns. For example, a company must turn over sensiti\'e data to an external service
provider and trust the provider to maintain security, confidentiality, and quality. Also,
before oursourcing, a company must carefully review issues relating to insurance,
porenrial liability, licensing and information ownership, warranties, and disaster recovery.
Mosr important, a company considering outsourcing must realize that the solution
ca n be only as good as the outsourcing firm that provides the service. A dynamic
economy can give rise to business failures and uncertainty about the furure. ln this
climate, it is especially important to review the history and financial condition of an
outsourcing firm before making a commionent.
Mergers and acquisitions also caa affect ou tsourcing clients. Even with large,
financially healthy fi rms, a merger or acquisition can have some impact on clients and
customers. If stability is important, an outsourcing client should consider these issues.
Outsourcing can be especially attractive co a company whose volume flucruates
widely, such as a defense contractor. In other situations, a company might decide ro
outsource application development rasks to an IT consulring firm if che company
lacks the time or expertise to handle the work on its own. Outsourcing relieves a
company of che responsibility of add ing IT staff in busy rimes and downsizing when
the workload lightens. A major disadvantage of outsourcing is rhar it raises emplo>•ee
concerns about job security. Talented IT people usually prefer posinons where the
firm ts commirred to in-house IT development-if they do nor feel secure, they mighr
decide to work directly for the service provider.
7 .5 0FFSHORING
Off~horing , also known as offshore outsourcing or global out~ourcing , refers ro the
practice of shifting IT development, support, and operations to other countries. In
a trend similar to the outflow of manufacturing jobs over a several-decade period,
many firms arc sending IT work overseas.
IT work can move offshore even fasrer than manufacturing, because it is easier to
ship work across networks and put consultants on airplanes than it is to ship bulky
raw materia ls, bui ld factories, and deal with tariffs and transportation issues. Several
years ago, rhe IT consulting firm Gartner, Inc., accurately forccasted the steady
growth of offshore outsourcing and predicted that outsourcing would evolve from
labor-intensive maintenance and support to higher-level systems development and
sofrware design.
The main reason for offshoring is the same as domestic outsourcing: lower
bottom-line co~ts. Offshore outsourcing, however, involves some un ique risks and
concerns. For example, workers, customers, and shareholders in some companies
have protested this trend and have raised public awarenes5 of possible economic
impact. Even more important, offshore outsourcing involves unique concerns regarding
project control, security issues, djsparate cultures, and effecrive communicarion
with critical functions rhar might be located halfway around the globe.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

' I
I
I
Phase 2
Systems Analysis
7.7 Selecting a Development Strategy
211
CASE IN POINT 7.2: T URNKEY SERVICES
Tumkey Services is an ASP that offers payroll and tax preparation services for hundreds
of businesses in the Midwest. The finn is considering a major expansion into accounting
and financial services and is looking into the possibility of supporting this move by hiring IT
subcontractors in several foreign countries. Turnkey's president has asked you to help him reach
a decist0n. Specifically. he wants you to cite the pros and cons of offshoring. He wants you to
present your views at a meeting of Turnkey managers next week. How will you proceed!
7 .6 SOFTWARE AS A SERVICE
In rhe tradirional model, sofrware vendors develop and sell application packages ro
customers. Typically, customers purchase licenses chat give them the righr to use the
software under the terms o f the license agreement. Although this model still accounts
for a large percentage of software acquisition, a new model, called Software as a
Service (SaaS), is changing rhe picture dramaticallly.
SaaS is a model of software deploymenr in which an applicarion is hosred as a
service provided to customers over rhe lnrerner. SaaS reduces the customer's need for
software maintenance, operation, and support. ln effect, SaaS provides the funcrionaliry
the customer needs, bur without the associated development, infrasrructure, and
maintenance costs.
In a highly compentive marketplace, major vendors constantly srrive co deliver
new and bercer ltolutions. For example, J\1icrosoft claims rhat irs SaaS plarform offers
the best solution and business value. One of their more popular consumer SaaS offering!>
is Office 365, shown in Figure 7-6. This is a full-Aedged version of the tvl icro~ofr
Office smce char runs in a browser window.
Apps
:!. -Offo<•
Wood hul
-
Documents
Reunt
FIGURE 7-6 Microsoft Office 365 provides web-based access to the complete Office suite.
SOU'rc~ l"'l tn tC' itp01·14•,,
7. 7 SELECTING A DEVELOPMENT STRATEGY
Selecting the besr development scrategy is an imporraot decision thac requires companies
co consider multiple factors. The syscems analyst has an imporcant role co
play in this decision-making process. In particular, anal)'zing the coses and benefics of
each development alcernative is a key co providing objective dara co managemenc. A
cosc-benefic checklisc can help guide chis analysis.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 7
Development Strategies
212 7. 7 Selecting a Development Strategy
7.7. 1 The Systems Analyst's Role
Ac ~ome poinc in the systems developmenc process, che company mu~c decide whether
m use an oucsourcing option, develop software in-house, acquire a software package,
develop u~er applications, or select some combination of these solutions. The dcci~ion
depends on che company's currenc and anticipared future needs. It will affccc che
remaining SDLC phases and the systems anal)'St's subsequenc involvement in the
pro1ect. The decision to develop software in-house, for example, will require more
parcic1parion from the sysrems analyst than outsourcing or choosing a commercial
p:ickage. ,\lfan:igcment usually makes a determination after receiving wrinen
recommendations from the IT staff and a formal presentation, which is described later
in this chapter.
Even a single system can use a mjx of sofrware alternatives. For example, a company
might purchase a standard software package to process its payroll and then
develop irs own sofrware to handle tbe interface berween the payroll package and rhc
company's in-house manufacturing cost analysis system.
The evaluation and selection of a lternatives is not a simple process. The objective
is co obrnin the product with rbe lowest TCO, but actual cost and performance can
be difficult to forecast. When selecting hardware and software, systems analysts often
work as an evaluation and selection ream. A team approach ensures that critical faccors
arc not overlooked and that a sound choice is made. The evaluation and selection
ream also must include users, who \viii participate in rhc selection process and feel a
sense of ownership in the new system.
The primary objective of the evaluation and selection ream is ro eliminate system
alrcrnarivcs that will nor meet requirements, rank the alternatives rhar arc feasible,
and present the viable alternatives to management for a final decision. The process
begins with a careful srudy of the coses and benefits of each alternative, as explained
in rhc following section.
7.7.2 Analyzing Cost and Benefits
Financial analysis tools have been around for a long time. From the abacu~ to the
pocket calculator, people have always sought easier ways ro work with numbers. This
section describes cost and benefit analysis and explains popular roots rhar can help a
sysrem~ an::tl)'St examine an IT project.
Chapter 2 explained rhar economic feasibility is one of rhe four feasibility
mea~uremenrs that are made during the preliminary investigation of a systems
request. Now, ar the end of the systems analysis phase of the SDLC, financial analysis
rools and rechniques must be applied to evaluate development strategies and decide
how the project will move forward. Part C of the Systems Analyst's Toolkit describes
three popular rools, which are payback analysis, return on investment (ROI ), and net
present value (NPV). Payback analysis determines how long it takes an information
system co pay for itself through reduced costs and increased benefits. Rclurn on
investmenl (RO I) is a percentage rare that compares the rota! ncr benefits (the return)
received from a project to the total costs (the investment) of the project. The net
present value (NPV) of a project is the total value of the benefits minus the total
value of the costs, with both costs and benefits adjusted ro reflect the point in rime at
which they occur.
These tools, and others, can be used to determine TCO, which was described in
Chapter 4. Ar this stage, the analyst will identify specific systems development srraregies
and choose a course of action. For example, a company might find char its TCO
will be higher if it develops a system in-house, compared with outsourcing the project
or using an ASP.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
P hase 2
Systems A nalysis
7.7 Selecting a Development Strategy
213
An accurate forccasr ofTCO is critical, because nearly 80o/o of roral cosrs occur
after rhe purchase of rhc hardware and software, according to Carmer, Inc. An IT
departmenr can develop irs own TCO escimares or use TCO calculation rools offered
by vendor . For example, as hown in Figure 7-7, HP Enterprise offer-; several free
TCO calcularors ro dererrnine rhe ROI of various development straregies and migration
options.
............ ~
You Buy Once-But You Pay for the Llfecyde
n_,._...,..,......._..,,.......,.~.,,"_._... ....... ..,-"...,
........ ............ ~ .. ~.,.,...,_--.,. ... c..~(TCD) .. ,,...,
...........
·~--~
......
-.... .,.,._ ..........
""...................... C*:JO ................................................ ~ .....
._..,....,...,...._~--.,.,..... w
........... __ --...,..,,..__.....,
................_._............ -... ~.-....
~~--_..-.. ___
WhyS','nd ..... TCOwtaot•: 1eM1
.....
-
UM Ow R-. Mo O' l a rlun TCO - ROI~°''
FIGURE 7-7 HP Enterprise provides se11eral freeTCO calculacon.
Sourc..: tt1 r. H
__ ..__ ...... _
____ ____
7. 7 .3 Cost-Benefit Analysis Checklist
Chapter 2 explained how ro use rhe payback analysis tool during the preliminary
invescigarion ro help determine whcrher a project is economically feasible. Now, all
the financial analy~is rools will be used to evaluate various development strategics.
The best way to apply the tools is co develop a cost-bcnefir checklist with rhe following
sreps:
• List each development srrarcgy being cons~dcred.
• Identify all cosrs and benefits for each alternative. Be sure to indicate when
co~ t s will he incurred and benefirs realized.
• Consider future growth and the need for scalability.
• Include support costs for hardware and software.
• Analyze various software licensing oprions, including fixed fees and formulas
based on the number of users or transactions.
• Apply the financial analysis rools to each alremarive.
• Srudy the resu lt ~ and prepare a report ro management.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 7
Development Strategies
2 14 7.8 The Software Acquisition Process
CASE IN POINT 7.3:
STERLING A ssoclATI.S
SterlingAssociates specializes in advising dients on IT projeccs and information systems development.
Marketing is creating a brochure for prospective new clients, and they want you to
develop a section that describes payback analysis, ROI, and NPV in simple tenns and mentions
the pros and cons of each financial analysis tool. How do you proceed~
7.8 THE SOFTWARE ACQUISITION PROCESS
Although each situation is different, the following section describes a rypical example
of the issues and tasks involved in software acquisition.
Step I: Evaluate the Information System Requirements
Based on the analysis of the system requirements, the system's key features must be
identified; network and web-related issues considered; volume and future growth estimated;
any hardware, software, or personnel constraints specified; and an RFP or a
quotation prepared.
IDENTIFY KEY FEATURES: Whether in-house development or outsourcing
options are being considered, the analyst must develop a clear, detailed list of
features that can serve as an overall specification for the system. Using the data
gathered during fact-finding, which was discussed in Chapter 4, list all system
requirements and critical features. T his information will be included in the system
rcquiremcnb document, which is cbe end product of the SDLC systems analysis
phase.
CONSIDER NETWORKANDWEB-RELATED ISSUES: As the system requirements
are evaluated, the network and web-related issues must be considered. The analyst
must decide whether the system will run on a network, the Internet, or a company
intranet and build these requirements into the design. Also, it must be determined
whether the system will exchange data with vendor or customer systems and ensure
that the system will be compatible.
ESTIMATE VOLUME AND FUTURE GROWTH: The analyse needs to know the
current volume of transactions and forecast futu re growth. Figure 7-8 shows volume
estimates for an ()rder processing system. In addition to current l evel~ , the figure
displays cwo forecasts; one based on the existing order processing procedures and
::inother char assumes a new website is operational.
A comp::irison of rhe two forecasts shows chat the website will genera re more new
customers, process almost 80o/o more orders, and substantia lly reduces the need for
sa les rep~ and support staff. If in-house development is being considered, make sure
that the software and hardware can handle future transaction volumes and data
!.forage requirements. Conversely, if outsourcing is being considered, volume and
usage data is es~ential co analyze ASP fee structures and develop coi.t estimates for
outsourcing options.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

I '
I
Phase 2
Systems Analysis
7.8 The Software Acquisition Process
215
Online Order Processing System Estimated Activity During Next 12-Month Period
CURRENT LEVEL
FUTURE GROW TH
(based on ex1sung
procedures)
FUTURE GROWTH
(assuming new website IS
operational)
Customers 36,500 40,1 50 63,875
Daily Orders l,·435 1,579 2,8 11
Daily Order Lines 7,715 7,893 12.556
Sales Reps 29 32 12
Order Processing 2 4 3
Support Staff
Producu 600 650 900
FIGURE 7-8 Volume estimates for an order processing system showing current activity levels and two forecasts: one based on
the existing order processing procedures and another that assumes a new website is operational.
SPECIFY HARDWARE, SOFTWARE, OR PERSONNEL CONSTRAINTS: The
analyst must determine whether existing hardware, software, or personnel issues wi ll
affect the acquisition decision. For example, if the firm has a large number of legacy
systems or if an Enterprise Resource Planning (ERP) strategy has been adopted, these
factors will have an impact on the decision. Also, the compa11y's policy regarding
outsourcing IT functions mu~t be investigated, and whether outsourcing is pare of a
long-rerm straregy. Wirh regard ro personnel issues, in-house sraffing requircmenrs
must be defined to develop, acquire, implement, and maintain the system-and
determine whether the compan}' is willing to commit to those staffing levels versus an
oursourcmg opnon.
PREPARE A REQUEST FOR PROPOSAL OR QUOTATION: To obtain the informacion
needed to m:ike a decision, che analyst should prepare an RFP or an RFQ. The
two documencs are similar but used in different sicuacions, based on whether or not a
specific software produce has been selected.
A request for proposal (RFP) is a documeot that describes the company, lists
the IT services or products needed, and specifies the features required. An RFP
helps ensure char the organizarion's business needs will be met. An RFP also spells
out the service and support levels required. Based on the RFP, vendors can decide
if rhey have a produce that will meet the company's needs. RFPs vary in size and
complexity, just like the systems they describe. An RFP for a large system can
contain dozens of pages with unique requirements and features. An RFP can be used
to designate some features as essential and others as desirable. An RFP also requests
specific pricing and paymcnr terms. There are several online sources where RFP
templates can be found.
When several responses to an RFP are evaluared, it is helpful to use an evaluation
model. An evaluation model is a technique that uses a common yardstick to measure
and compare vendor ratings.
Figure 7-9 shows two evaluation models for a network project. The evaluation
model at the top of the figure simply lists the key elements and each vendor's score.
The model at the bottom of the figure adds a weight factor. ln this example, each
element receives a rating based on its relative importance. Although the initial scores
are the same 111 both models, note that vendor A has rhc highest point total in the top
example, bur ,·endor C emerges as the besr in the wcighred model.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

~~~~~~~- -~~~~~~~
Chapter 7
Development Strategies
216 7.8 The Software Acquisition Process
Unweighted Evaluation Model for a Network Project
Instructions: Rate each vendor on a scale from I (low) to I 0 (high). then add vendor scores
to calculate total points.
VENDO R C
Price 6 s 9
Completion Date 2 s 8
Layout/Design 8 8 5
References 10 6 3
TOTAL POINTS 26 24 25
Weighted Evaluation Model for a Network Project
Instructions: Rate each vendor on a scale from I (low) to I 0 (high), then multiply the vendor's
score by the weight factor. Add vendor scores to calculate tot.ii points.
Price
Compledon Date
Layout/Deslp
References
TOTAL POINTS
WEIGHT
FACTOR
25
25
35
IS
100
VENDOR A
6 * 25=150
2 * 25 = so
8 * 35 = 280
10 * IS= ISO
630
VENDOR B
5 * 25 = 125
5 " 25 = 125
8 . 35 = 280
6 * 1S = 90
620
VENDOR C
9 . 25 = 225
8 . 25 = 200
s .. 35 = 175
3 * IS = 4S
FIGURE 7 -9 The three vef\dors have che same initial raungs, but the two evaluauon models produce different
results. In the unweighted model at the top of the figure, vendor A has the highest toal points. However. after
applying we1ghong factors., vendor C is the winner. as shown in the model at the bottom of the figure.
645
o standard method exists for assigning the weight factors. Each firm will have
its own approach, which might be tailored to fit a specific situation. An analyse usu·
ally obtains as much input as possible and then circulates proposed values for further
comment and, hopefully, a consensus.
Evaluation models are valuable cools that can be used throughout the SDLC. A
spreadsheet program can be used to build an evaluation model, experiment with different
weighting factors, and graph the results.
A request for quotation (RFQ) is more specific than an RFP. When an RFQ is
used, the speci fie product or service desired is already known; only price quotations
or bids arc needed. RFQs can involve outright purchase or a variety of leasing options
and can include maintenance or tech.nical support terms. Some vendors even provide
convenient RFP o r RFQ forms on their websites. RFPs and RFQs have the same
objective: to obtain vendor replies that are clear, comparable, and responsive, so that
a well-informed selection decision can be made.
Step 2: Identify Potential Vendors or Outsourcing Options
The next step is to identify potential vendors or outsourcing providers. The Internet
is a primary marketplace for all IT products and services, and descriptive information
can be found on the web abour all major products and acquisition alrernacives.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

I '
I
Phase 2
Systems Analysis
7.8 The Software Acquisition Process
217
If vercical applications for specific industries need ro be locared, industry rrade journals
or websites can be used to find reviews for industry-specific sofrware. Industry trade
groups can often provide referrals to companies that offer specific software solutions.
Another approach 1 to work with a consulting firm. Many IT consulranrs offer
specialized services chat help companies select somvare packages. A major advantage
of using a consultant is that rhe analyst can tap into broad experience that is difficult
for any one company to acquire. Consultants can be located by contacting profcsional
organizations or industry sources or simply b)' searching the Internet. Using a
consulranr involves additional expense but can prevent even more costly misrakes.
No matter what rhe topics of interest are, there are sure to be one or more on line
forums where people gather to meet, offer support, and exchange ideas. Forums can
be hosted by private or public entities, or reside in larger communities such as Google
Groups or Reddit, which allow users to join existiug groups or start their own. A
web search can locate forums of interest, or the websites of specific companies, such
as Microsoft, and can provide a valuable source of information for IT professionals,
including biogs, forums, webcasts, and other resources, as shown in Figure 7-10.
·~I '--- -
Alie ""' Mlaooofl c-nity. w.·,. here to help!
--
= 0 ,~ DJ 0 CJ.
- - - - -
~ e co e
-
L>
--- -- --- -- ..
-·-
FIGURE 7-10 Microsoft Community is a valuable resource for IT professionals.
Sovt<tet ~ .. ,. ""
Step 3: Evaluate the Alternatives
After identifying the alternatives, the analyst must select the one that best firs the
company's needs. Information about the options should be obtained from as many
sources as possible, including vendor presentations and literature, product documcntarion,
trade publications, and companies that perform software testing and evaluation.
To learn more abour particular software packages, search rhe Internet using
keywords that describe the application. Websites maintained by consultants and ~ofrware
publishers often include product references and links to vendors. As parr of the
evaluation process, try ro obtain information from existing users, tesr the application,
and benchmark the package.
EXISTING USERS: Existing users can be contacted to obtain feedback and learn
abour their experiences. For large-scale software packages, ASPs and vendors typically
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 7
Development Strategies
218 7.8 The Software Acquisition Process
supply user references. User references are important because it must be known
whether the software package has worked well for similar companies. Be aware that
some vendors limit their reference lists to satisfied clients, so mostly positive feedback
should be expected from those firms.
APPLICATION TESTING: If a software package is one of the options, find out if it is
possible for users in the organization to try the product. For horizontal applications
or small systems, using a den10 copy to enter a few sample transacnons could be an
accepcable test. For vertical applications or large systems, a team of IT staff and users
might need several days or weeks to perform rests.
BENCHMARKING: To determine whether a package can handle a certain transaction
volume efficienrly, a benchmark rest can be performed. A benchmark measures
the time a pack;"tge takes co process a certain number of rrnnsacrions. For example, a
benchmark rest can measure the time needed to post l,000 sales rransacrions.
If benchmarks arc used, remember that a benchmark rest is conducted in a controlled
environment, which might no t resemble the actual dtiy-ro-day situation tit the
project's company. Although benchmarking cannot predict project-specific resu lts,
benchmark resting is a good way co measure relative performance of cwo or more
competing produces in a srandard environment.
Many IT publications publish regular reviews of individutil ptickages, including
benchmark rests, and ofcen have annual surveys covering various categories of sofcwarc.
Most of rhe publications now offer online and mobile versions, wich addicional
features, search capabiliry, and IT Links.
lnform<uion can also be obcained from independent firms that benchmark various
software packages and sell comparative analyses of the results, as shown m Figure 7- 11.
The Transticrion Processing Performance Council {TPC) is an ex.·unple of a nonprofit
organization that publishes standards and repons for its members and the general public.
TPC
- - ·-
-- ·-·-· ·--
·--··- ----·~
-
- e
(1 AHO::i ,1(1,1f1,
Gctxwl
'" CISCO
.If-
FUJITSU ~
-
IBlt IOSpur
- -- TTA i...,_,m
FIGURE 7-1 I The Transaction Processing Performance Council (TPC) is a
nonprofit organizauon chat publishes sundards and reports for Its members
and the general public.
Sour«:..
• '"'~~ '1""'Nl' Cb.t'llt.(:C
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I '
I
Phase 2
Systems A nalysis
7.9 Completion of Systems Analysis Tasks
219
Finally, each package should be marched against the RFP features and rank the
choices. If some features are more important rhan others, give them a higher weight
using an evaluation model similar to rhe one shown in Figure 7- 11.
Step 4: Perform Cost-Benefit Analysis
Review the suggesrions in chis chapter and in Part C of che Systems Analyst's Toolkir to
develop a preadsheet ro idenrify and calculate TCO for each option being considered.
Be sure to include all cosrs, using rhe volume forecasts prepared. If outsourcing options
are being considered, carefully study the alternative fee structure models described
earlier. If possible, prepare charts to show the resulrs graphically, and build in what-if
capab1liry so rhe impact of one or more variables changing can be gauged.
If a software package is being considered, be sure to consider acquisition options.
When software is purchased, a ~oftware license is being boughL that give~ the purchaser
the right to use the software under certain cerms and conditions. For example, rhe licen~e
could allow the software ro be used only on a single computer, a specified number of
computers, a network, or an entire site, depending on the terms of the agreement. Other
license restrictions could prohibit making the soft\vare available to others or modifying the
program. For desktop applications, software license terms and conditions usually cannot
be modified. For large-scale systems, license agreement terms often can be nt::gotiated.
Also consider user support issues, which can account for a significant part of TCO.
If an outsourcing alternative is selected, rhe arrangement probably will include cer·
rain technical support and maintenance. !I in-house development is chosen, the cost
of providing these services musr be considered. lI a software package is purchased,
consider a supplemental maintenance agreement, which offers additional support and
assistance from the vendor. The agreement might provide full support for a period
of time or list specific charges for particular services. Some sofnvare packages provide
free technical support for a period of rime. Atterward, support is offered with a
charge per occurrence, or per minute or hour of technical support time. Some software
vendors contact registered owners whenever a new release is available and usually
offer the new release at a reduced price.
Step S: Prepare a Recommendation
The anal)'St should prepare a recommendation that evaluates and describes rhe
alternatives, together with the coses, benefits, advantages, and disadvantages of each
option. At this point, it may be required to submit a formal system requirements
document and deliver a presentation. Review the suggestions for presenting
written proposals and oral presentations in Part A of the Sysrems Analyst's Toolkit.
Additional suggestions about preparing the system requirements document and the
management presenrarion are contained in the following section.
7. 9 COMPLETION OF SYSTEMS ANALYSIS TASKS
To complete the systems analysis phase, the anal)'St muse finalize the system requirements
document, present their findings co management, and begin the transition ro
systems design.
7.9. 1 System Requirements Document
The system requirements document contains the requiremenrs for the new !>)'Stem,
describes rhe alternarives that were considered, and makes a specific recommendation
to management. This important document is the starring point for measuring the
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 7
Development Strategies
220 7.9 Completion of Systems Analysis Tasks
performance, accuracy, and completeness of the finished system before entering the
systems design phase.
The system requirements document is like a contract that identifies what the system
developer mu t deliver co users. Recall chat system requirements are identified
during the fact-finding process, and a system requirements checklist is created at char
nme. Various examples of system requiremenrs are listed in Chapter 4. The i.ystem
requirements document should be written in language that users can underscand so
they can offer input, suggest improvements, and approve the final version.
Because the system requirements document can be lengthy, they should be formatted
and organized, so it is easy co read and use. The system requirements document
should include a cover page and a detailed cable of contents. An index and a glossary
of terms can be added to make the document easier to use. The content of the system
requirements document will depend on the company and the complexiry of the
system.
7.9.2 Presentation to Manageme nt
The presentation tO management at tthe end of the systems analysis phase is one of the
most criric::il milestones in rhe systems development process. At this point, managers
make key decisions that affect the future development of the system.
Prior to a management presentation, two ocher presentations may be given: one co
the principal individuals in the IT department co keep chem posted, and another pre·
sentation to users co answer their questions and invite feedback. The system requirements
document is the basis for all three presentations, and it (or a summary) should
be distributed in advance so the recipients can review it.
\Xr'hen preparing the presentation, review the suggestions in Part A of the Systems
Analyst's Toolkit, which can help design and deliver a successful presentation. If a
slide presentation is planned, review the Toolkit guidelines for effective presentations.
In addition to rhe rechniques found in the Toolkit, also keep rhe following suggestions
in mind:
• Begin che presentation with a brief overview of the purpose and primary objectives
of the system project, the objectives of thjs presentation, and what decisions
need to be made.
• ummarize rhe primary viable alternatives. For each alternative, describe rhe
coses, advanrages, and clisadvantages.
• Explain why the evaluation and selection team chose the recommended
a !tern:. rive.
• Allow rime for discussion and for questions and answers.
• Obtain a final decision from 1nanagemenr or agree on a timcrablc for rhe next
step in rhe process.
The objecr of the management presenrarion is to obtain approval for the develop·
ment of the system and to gain management's full support, including nece)sary financial
resources. Managemenr probably will choose one of five alternatives: develop an
in-house system, modify a currenr system, purchase or customize a software package,
perform additional systems analysis work, or stop all further work. Depending on
their decision, the next task of rhe systems analyst will be one of the following:
• lmplemenr an oursourcing alternative. If oursourcing is selected, the analyse
will work with representatives of the service provider to achieve a smooth transition
to the new environment.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems A nalysis
7.9 Completion of Systems Analysis Tasks
221
• Develop an in-house system. Begin systems design tasks, as described in
Chapters 8, 9, and 10.
• Purchase or customize a software package_ Negotiate the purchase terms with
the software vendor for management approval. Then, if the package will be
used without modification, the analyst can begin planning the systems implementation
phase. If modifications must be made to the package, the next step
is to start the systems design phase. If the vendor will make the modifications,
then the analyst's next step is to start planning the testing and documentation
of the modifications as part of the systems implementation phase, which is
described in Chapter l l.
• Perform additional S) 1 Stems analysis work. Management might want the analyse
to invesngace certai n alternatives further, explore alternatives nor examined,
develop a prototype, reduce the project scope because of cost constraints, or
expand the project scope based on new developments. If necessary, the analyst
will perform the additional work and schedule a follow-up presentation.
• Stop all further work. The decision mighr be based on the analyst's recommendation,
a shift in priorities or costs, or for o ther reasons. Whatever rhe reason,
if that is managemcm's decision, then there are no additional tasks for the project
other than ro file all the research in a logical location, so it can he retrieved
if the project is reopened in the furure.
After the presenrarion and management decision, the project will begin a transition
to the S)'Stems design phase of the SDLC. If an in-house system is being developed,
or a package is being modified, a model of the proposed system wiU be built, and the
analyst will srart designing the user interface, output, input, and dara structures.
7.9.3 Transition to Systems Design
In a traditional SDLC environment, systems design usually scarred when the systems
analysis phase was done. Using the system requirements specification as a blueprint,
developers transformed the logical design inro a working model that could be rested,
reviewed by users, and implemented. Today, the process is much more dynamic. In
general, systems development is faster, more flexible, and more user oriented. The
introduction of agile development has changed rhe landscape significantly. Depending
on the project, system developers often blend tradirional and cutting-edge development
methods, because what works in one siruarion might nor work in another.
This textbook discusses systems analysis in Chapters 4, 5, 6, and 7 and systems
design in Chapters 8, 9, and 10. However, in a typical IT workplace, all these tasksand
more-are inregrated and managed together.
Regardle~s o f the developmenr method, systems design requires accurate documentation.
Traditionally, a sy!>tem requirements document provided detai led specifications
for output, input, dara, processes, and whatever else was needed. Although agile
merhocli. do not require :.t particular form of documentation, a s uccei.~ful development
team must understand and record user requirements as they evolve during the project.
A logical design defines what must rake place, nor how it will be accomplished.
Logical designs do nor address the actual methods of implementation. In contrast,
a physical design is like a set of blueprints for the actual construction of a building.
Typically, a physical design describes the acrual processes of entering, verifying, and
scoring data; the physical layout of data files and sorting procedures; the format of
reports; and so on. Because logical and physical designs are related so closely, good
systems design is impossible wirhour careful, accurate systems analysis. For example,

Chapter 7
Development Strategies
222 7.10 Summary
the analyst might return ro fact-finding if it was discovered that an important issue
was overlooked, if users had significant new needs, or if legal or governmental
requirements changed.
A junior analyst at a medium-sized IT consulting firm has been asked by her manager to
draft a response to an RFP from a large company that is seeking IT consulting services in
connection with a new accounting system.
As the analyst worked on the RFP. she noticed a specific question about her firm 's
recent experience on this type of system. To the best of her knowledge. the firm has only
worked on one other accounting project in the past three years. When the manager saw
the analyst's draft response, he was upset about the way she answered the question. "You
don't have to be quite that candid," he said. "Even though we only had one formal project,
we do have several people who worked on accounting systems before they came here."
"Yes," the analyst replied, "But that isn't what the question is asking." As he left her
office, the manager's final comment was, "If we want that job, we' ll have to come up with a
better answer." Thinking about it, the analyst isn't comfortable with anything but a straight
answer. Is this an ethical question? What are her options!
7. I 0 SUMMARY
This chapter described system development strategies and the preparation and presentation
of the system requirements document.
Traditional systems must function in various hardware and software environments,
be compatible with legacy systems, and operate within the constraints of company
nerworks and desktop computing capability. Such systems utilize Internet links
and resources as enhancements. In contrast, Internet-based systems treat the web as
the platform, rather than just a communication channel. Many large companies use
web-based systems co handle enterprise-wide applications. Compared to traditional
systems, web-based systems are more scalable, less dependent on specific hardware
and software, and more adaptable to outsourcing the operation and support of a software
application.
Systems analysts must consider •veb-based development environments such as
.NET, M ERN, and various outsourcing options, including ASPs and I BSs. ASPs charge
subscriprion fees for providing application sofrware packages. IBSs offer powerful
web-based servers, software hosting,, and IT support services ro customers.
The web generation called Web 2.0 is fueling the expansion of information sharing,
user collaborarion, and social networking applications such a~ Twiner, Linkedfn,
and Faccbook. Another development, called cloud computing because of the commonly
used cloud symbol for the Internet, describes an overall online software and
data environment, powered by supercomputer technology that i the ultimate form of
SaaS.
If a company chooses to handle ics own software development needs, it can create
in-house systems or purchase (and possibly customize) commercially available software
packages from a software vendor or VAR.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
I '
I
Phase 2
Systems Analysis
7.10 Summary
223
Compared with developing an in-house system, an existing commercial software
package can be an arrractive alrernative, because a package generally costs less,
takes less time to implement, has a proven track record, and is upgraded frequently.
In-house development or customizing a software package might be the best choice
when a standard software package cannot meet specific business requirements or
constraints. In addition to customizing software packages, companies can create
user applications based on standard software that has been specially configured ro
enhance user producnvity.
An 11nporcanr trend that views SaaS, rather than a product, has created new developmenr
options. SaaS 1s a model of software deployment in which an application is
hosted as a service provided to customers over the lnterner.
Offshoring, :ilso known :is offshore outsourcing or global 011tso11rc111g, refers to
the practice of shifting TT development, support, and operations co other countries.
In a trend similar co the ourflow of manufacturing jobs over :1 several-decade period,
many firms are sending IT work overseas. The main reason for offshoring is the same
as domestic outsourcing: lower borrom-line costs. Offshore outsourcing, however,
involves some unique risks and concerns.
The systems analyst's role in the software development process depends 011 the
specific development strategy. In-house development requires much more involvement
than outsourcing or choosing a commercial package.
The most important facror in choosing a development strategy is TCO. Financial
analysis tools include payback analysis, which determines how long it takes for a system
co pay for itself through reduced costs and increased benefits; ROI, which compares
a project's total return with its total coses; and NPV, which analyzes the value of
a projecr by adjusting cosrs and benefits to reflecc che rime thar they occur.
The process of acquiring software involves a series of steps: Evaluate the system
requiremenrs, consider network and web-related issues, identify potential sofnvarc
vendors or outsourcing options, evaluate the alternatives, perform cost-benefit analysis,
prepare a recommendation, and implement the solution. During software acquisition,
a company can use an RFP or an RFQ. An Rf P invices vendors ro respond to a
list of &)·stem requirements and features; an RFQ seeks bids for a specific product or
service.
The S)'~tem requirements document is the deliverable, or end produce, of the systems
analysis phase. The document derails all system requirements and constraints,
recommends the best ~olution, and provides cost and time estimate~ for future development
work. The sr~rem requirements document is t11e basis for the management
presentation. At chis poim, the firm might decide to develop an in-house sy~tem, modify
the current system, purchase or customize a software package, perform additional
systems analysis work, or stop all further work.

Chapter 7
Development Strategies
224 Key Terms
Key Te rms
applicauon \Ct\ ice pro' idtl (ASP) A finn chm delivers a wfrware applicauon, or aC(c.,s IO an appltcarion,
h) chargoni; a u-.ai:c or 'ub..cnpnon fee.
h.,nchmark A mea\urc<. of rhe rime a package rak~ ro procc<s a certain numhcr of tram.1c11on,,
hu1ld or buy A choice between developmg 10-house sofrware and pur.:hasmg software, often called a
but Id or bu)', or make or buy, decision.
bu<ine<< procc<~ our<ourcing !BPOl The oucsourcing of a basic busin~s process. See a/50 outsourcing.
cloud computing An online <;<>ftware and da-i:a em~ronmenc in which applicanon' and 'crvice' arc
Jcce<.-cd and used ch rough an lncerner connection rather than on a local rnmpucer; refer> co the cloud
.,ymhol for the Internet.
evaluation .ind 'ck-.:tion team A group of people involved in ~deurni: h.irdwarc and >Oft ware:. The group
111dudc' \)"tcm~ analy>t\ and users. A team a pproac:h cmurc' 1ha1 cnrical fnctor' arc nor overlooked
and that a sound choice is made.
evaluation model A technique rba r uses a common yardstick to mci1sure and comp.ire vendor ratings.
fixed fee model A service model thar charges a sec fee based on a specified level of service and user
supp0rt.
forum An on line di,cu,,ion on a parcicular copic, where people mecl, offer >upport, and e>echani;e idea,,
glob.ii out.,ourdni: The pracrke of ohifting IT development, >upport, and operation' w other countries.
boruon1al application A software pJckage char can be used by man) d1ffercm types of organwmons.
in-bouic >Oft\\ arc An mfonnation cenrer or help desk wubin the 11 dep.rnmem resp0ns1ble for providmg
user supporr and offering sen-ices such as hodme ass1sr.111ce, tr.lllltng, and gu1d.1ncc ro users who
need teduuc.il belp.
Internet hu'1nC\\ \cn;cc\ (IBS' Scn•iccs rhar provide powerful wcb-bao,cd \upport for iran•action• •uch
a• order pmce<smg, billing, and customer relariomhip management.
l~ical dc,ign The definition of an information system's fun~-rions and feature-., and rhc relanon,hip<
among ir, componenn..
maintcnam:e agr.'Cmeot A >pecification of the condiuons, ch.uge;, .ind tune fr.une for u>efi to com.1ct
the vendor for assistance when che)' have system problems or quesuons.
mal..c or bu~
The choice between de,eloping in-house sofcware and purchasmg soft\\Jre often 1s called a
make or buy, or bmld or buy, deos1on.
man.1gcd ho,t1ng 1\n opcrarion 1< managed by the oursidc firm, or hem. t\nothcr term for me;.,
middlcware Software rhat connects dissimilar applications and enables them to commun1cacc and
e-ichangc data. For exnrnple, rniddleware can link a deparnnentnl darnba'e to a wch server rhn r can
be aClC>~ed by tlienr computers via the Tnrcmet or a company intranct.
mobile dc,·icc )nrnrtphones, cablers, and orb.er computing devices tbar Jre nor permanenrly terhered ro a
desk. They connect to 1he ncrwork wirelessly.
nc1 present l'alue (Nl'V} The rocal va lue of rhe beneffrs minus the total v.1lue of the coqs, with both the
cost~ and benefits being adjusted to reAecr the poinr in tome .it which they occur.
off~horc outmurcini: The practice of shifting IT development, su pport, and operation~ m orhcr
coumrie~.
uff.,horing See nff'ihorc out~ourcing .
outwun.;ng Tbe transfer of information systems development, operJuon, or mamrenance tO an ou t~ide
tmn rbat pro\ldc; the~e ser\1ces, for a fee, on a temporary or long-term ba~•~.
p.i)b;icl.. anal~s·~ A deremurumon of ho\\ long it ca kes an informanoo sy~tcm to pa) for uself through
reduced costs and increased henefirs.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

' I
I
I
Phase 2
Systems Analysis
Key Terms
225
ph},ical d~illJI
A plan for che actual 1mplememarion of che system.
requc\t for propo.,.al (RFP) A wrinen Im of fearures and specificarioru. gi•en co pro>pe<:llve vendor:.
before a >pc.:ific product or pa~kaj\e has been ~b.'ted.
requto't for 1.1uot.auon (RI Q u.,cd 10 obtain a pnce quotanon or bid on a \pcctfic produu or packaj\e.
return on Ul\C\tmcm (ROI) A percemage rate that measure!. profitabw!} by comparing the total net benefirs
(the return) received from a pro1ecr ro rhe roral costs (rbe mvescment) of r:he project. ROI = (rotal
bcncfirs - 1otal cosrs)/total cosrs.
~en-ice d~k A centralized resource staffed by IT professionals char provides users with the supporr they
need ro do cbeir )Obs. Also called help desk.
•en ice prm 1der A firm rhnr offer, oursourdng solucion~. Two popular outsourdng option., involve ASP~
and finm that offer IRS, .
Software J\ a )crvice (\an\) A mu<ld of >ofrwa re <lel i,•cry in which funcrionn liry i, <ldiverc<l 1111 demand
'"a ncrwurk-accc''ihlc '>Crvicc, ra ther rhan a' a tradicional ,oftwarc application that ;, duwnlondcd
and in,tallcd on the cusrnmcr\ compmcr.
sofcwarc license J\ legal agreemeni thar gives users rhe right rouse rhc software under certain cerms nnd
condirions.
softwMe pack.1gc ~frware that is purch.ised or leased from another firm. A corumercit1Uy produced
softw.tre produce. or fonuly or producrs.
'>'tcm requirement' Jo.:umcnt A uo<;ument rhat cunrains the requirement' for the new 'Y'tem, dc...:ribe'
the altcmattve' thar were considered, and makes a •pccific rccommcndattun to mana11cmcnt. It ;, rhc
end producr of rhe 'Y'rcm< nn'11y<i< pha<c.
,ofn,arc 'cndnr Company rh;ir de,·clops <ofr:ware for <ale.
subscription model A sen-ice model that charges a ,·ari<lble fee for an application based on the number
of users or worksrauons char haH' acctss ro che application.
cram.i.:uon model A sen-ict model r:hat charges a variable fee for an applicauon based on rhe \Olume of
transacuoos or oper.mons performed by rhe appltcacion. Also called a usage model.
u,aitc model Su cran,action model.
u~cr apploc.111un Progra1m 1ha1 utili1c ;randard bu~ine>s •oftwarc, •uch a> Mivowft Offilc, wh"h ha'
been confil\urcd in a •pec1fic manner ro enhance user product1v1ry.
mer interface Includes screens, commands, controls, and fea rures rhar enable users to mrernet more
effectively with an applicanon. See <1/so graphical user interface (GUI).
' 'alU•'-addcd rc-.dlcr (VAR ) A firm tha t enhances a commercial package by adding custom feature~ and
conf1gunng 11 for a parucular mdusrry.
vertical application A ,oftwan: package that has been developed ro handle informnrion requirement\ for
a •pcc1fic rype of bu,i n e,~ .
\\'ch 2.0 A ' ccond 11cncr:irion of 1hc web ihnt enables people to collaborate, interact, Jnd ,h,irc on formation
much more dynamically, ba~ed on concinuously available user applications rather than Sto rie
HTM L. web page~. lnrcracrivc experience is n hallmark ofWeh 2.0.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 7
Development Strategies
226 Exercises
Exercises
Questions
I. List three characreristics each of rraditional and web-based development.
2. How does cloud computing support Web 2.0 applications?
3. Why would a company choose in-house sofrware de,·elopment?
4. \Vhat 1s outsourcing?
5. List two reasons offshoring may be risky.
6. What is SaaS?
7. What i!> the primary objeetive of the evaluation and selection team in ~electing a development
strategy?
8. What are the five steps in rhe sofcware acquisition process?
9. What is an RFP, and how does it differ from an RFQ?
10. Explain the relationship between logical and physical design.
Discussion Topics
Projects
I. How has the prolifcrarion of mobile devices affected IT professionals?
2. A~ more companies outsource systems development, will there be less need for in-house system~ analysts?
Why or why not?
3. Select a financial SaaS applicarion, and describe its main features.
4. Suppose you rned to explain the concept of weighted evaluation models to a manager, and she
responded by asking, "So, how do you set the weight factors? ls it just a subjecti\'e guess?" I low
would you reply?
5. What decisions might managemenr reach at rhe end of the systems analysis phase, and what would be
the next step in each case?
I. lnvestigate the ROI of cloud-based software development environments.
2. t-.1any financial cools :ire developed using t-.1icrosoft E.xcel. ldeotlfy three applications builr usmg
Excel, and describe how the)' are used in an organization.
3. Visit the IT deparnnem ar your school or at a local company, and dercrmine wherhcr the sysrcms were
developed in-house or purchased. If packages were acquired, find our whar customizing was done, if
any. Write a brief memo describing the results.
4. Profile three companies rhat provide offshore sofcware development services.
5. Various firms and organizations offer IT benchmarking. Locate an example on the Internet, and
describe its ~crv i ces.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

PHASE
SYSTEMS DESIGN
Systems design Is the third of five phases in the systems development life cycle. In the previous
phase, systems analysis, a logical model of the new system was developed. The output of that
phase, the system requirements document, is used as input to the systems design phase, where a
physical design is created that satisfies the system requirements.
The components of a system are interdependent; therefore, the design phase Is not a series of
clearly defined steps. Although work may start in one area, it is possible to be working with several
different elements at the same time. For example, a decision to change a report format might
require changes in data design or input screens. The design checklist will Include the user interface,
input and output procedures, data design, and system architecture. At the end of this phase, the
analyst prepares a systems design specification and delivers a presentation to management.
The goal of systems design is to build a system that is effective, reliable, and maintainable:
• A system is effective if it supports business requirements and meets user needs .
• A system is reliable if it handles input errors, processing errors, hardware failures, or
human mistakes. A good design will anticipate errors. detect them as early as possible,
make it easy to correct them, and prevent them from damaging the system itself. Other
characteristics of a reliable system include it being available nearly all of the time and
proper backups maintained in case of system failure.
• A system is maintainable if it is flexible, scalable, and easily modified. Changes might be needed
to correct problems, adapt to user requirements, or take advantage of new technology.
Chapter 8 focuses on user interface design. This includes human-computer interaction, seven
habits of successful interface designers, guidelines for user interface design, source document and
form design, printed output, technology issues, security and control issues. and emerging trends.
Chapter 9 focuses on the data design skills that are necessary for a systems analyst to construct
the physical model of the information system. This includes DBMS components, web-based
design. data design terms, entity-relationship diagrams, data normalization, codes, data storage
and access. and data control.
Chapter I 0 focuses on system architecture, which translates the logical design of an Information
system into a physical blueprint. This includes an architecture checklist. the evolution of system
architecture, client/server architecture, the impact of the Internet, e-commerce architecture,
processing methods, network models, wireless networks, and systems design completion.
227
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 8
User Interface Design
••
•• • •
••
......
•••••••••••
······----···· ·····---··-·· - •••••
•••
•
---· --
User Interface
Design
Chapte r 8 is the first of three chapters in the systems
design phase of the SDLC. User Interface design
is the first task in this phase. Designing the interface is
extremely important because everyone wants a system
that is easy to learn and use. This chapter explains how
to design an effective user Interface and how to handle
data security and control issues. The chapter stresses
the importance of user feedback and involvement in all
design decisions.
The chapter includes three "Case in Point" discussion
questions to help contextualize the concepts
described in the text. The "Question of Ethics" considers
the ethical (and possibly legal) constraints on how
far the creative work of others can be used without
crediting the source. for example, In the design of a
company's website.
LEARNING OBJECTIVES
When you fi11is/1 this chapter, you s/Jould be able
to:
1. Explain user interfaces
2. Explain che concept of hum:m-computer imeracrion,
including user-friendly interface design
3. Summarize the seven habits of successful interface
designers
4. Summarize rhe 10 guidelines for user interface
design
5. Design effective source documents a nd forms
6. Explain printed output report design guidelines
and principles
7. Describe three types of printed output reports
8. Discus~ output and input technology issues
9. Describe output and input security and conrrol
issues
10. Explain emerging user interface trends, including
modular design, responsive web design, and
CONTENTS
8 . 1 User Interfaces
8.2 Human-Computer lntcracuon
Case in Point 8.1: Casual Observer Software
8 .3 Seven Habir5 of Successful lncerfoce Designers
8 .4 Guidelines for User lncerfoce Design
Case in Poinr 8.2: Boolean Toys
8.5 Source Documenc and Form Design
8.6 Printed Output
Case in Point 8.3: Laty Eddie
8. 7 Technology Issues
8 .8 Securiry and Control Issues
8. 9 Emerging Trends
A Question of Ethics
8.10 Summary
Key Terms
Exercises
prototyp e~
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
8.1 User Interfaces
229
8.1 USER INTERFACES
A u~er interface (UT) describes how users interact with a computer system and consisrs
of all the hardware, software, screens, menus, functions, output, and features
that affect rwo-way communications between the user and the computer. The user
interface is the key t0 usability, which includes user satisfaction, support for busines~
functions, and system effectiveness.
Traditionally, a chapter on user interface design started wirh a discussion of ourput
because ourpur •~ whar u~ers rouched, viewed, and needed to do their jobs. Today, the
situation is different, for several important reasons:
• Users can design their own output. System designers are more aware of user
needs and desires. A system can maintain dara integrity and still allow users ro
view, sorr, filrcr, and examine dara in any way that helps them do rheir jobs.
There was a rime when rhe MIS depanmenr made those choices and users
had little or no ~ay in the matter. Today, successful applicarions are designed
quite differently-the system developer identifies user needs and then creates a
design that will s:icisfy users and meet corporate requirements.
• Centralized IT departments no longer produce reams of printed reports. Those
reports often gathered dust while sitting on top of file cabinets. \Xlhile a few
examples mighr persist, the overwhelming trend has been to customer-designed
output. The customer might be an individual user, or a community of users,
such as a department. As Chapter 4 pointed out, the IT team must undersrand
user requiremcnrs before creating a solution.
• The user inrcrfacc itself has evolved into a rwo-way channel, with powerful
output capability, and most user information needs can be met wirh creen-generated
darn, which a user can print, view, or save. Well into the 1980s and
be)·ond, a user incerface was a blank character-based screen, which mighr or
mighc nor offer menu choices. ff a user entered a command improperly, che system
responded w1rh an error message, which frustrated u ers and stifled product1v1ry.
~1any hardware-cenrric vendors did not understand the imporrance
of the user mrerface and irs implications.
Apple was a pioneer in user interface development, introducing the graphical user
interface (GUI), complete with mouse and screen icons, in the early 1980s. At char
point, nor many companies were ready for this concept. When software giant Microsoft
finally jumped on rhe GUI bandwagon with its Windows~ operating sysrem, the corporate
doors swung open, and everyone from managers on down said, "How did we ever
do without chis?"
Many indu~try leaders believe chat rhe besr interfaces are the ones that users do
not even notice-they make sense because they do what user!> expect them ro do. For
example, as :.hown in Figure 8- J, Apple believes that designing an exceptional user
incerfoce is essential to a !>uccessful app. Apple has long di~cinguished itself from it5
competitor~ by the incuiciveness of its produces. Apple's command of che marker suggests
that consumers are willing to pay a premium for products that "ju~t work."
When developing older systems, analysts typically designed all tbe printed and
screen output firsc and then worked on the inputs necessary to produce the re~ults.
Often, the user interface mainly consisted of process-control screenl> chat allowed the
user co send commands to rhe syscem. Thar approach worked well with tradirional
systems that simply cransformcd input data into structured output.

Chapter 8
User Interface Design
230 8.2 Human-Computer Interaction
- - - -
Designing for iPhone
Leam how to opi.,..ze the design of your app °'game
l0t the al-screen displays or 1Phone Xs, 1Phone Xs Max, end 1Phone XA
Down.,,.d,
FIGURE 8 - 1 Apple has long been a. leader in creating elegant user Interlaces for Its
products.
SOUi"(~ ~ .\- In<
As information management evolved from centraJized darn proces~ing to dynamic,
enterprise-wide systems, rhe primary focus also shifted-from rhe IT department to
the users themselves. The IT group became a supplier of information technology,
rather than a supplier of information. Today, tbe main focus is on users within and
outside the company, how they communicate with the information system, and how
the system supports the firm's business operations.
In a user-centered system, the distinction blurs between inpur, output, and the
interface itself. Most users work with a varied mix of input, screen ourput, and data
queries as the}' perform their day-to-day job fw1ctions. Because all those casks require
inrcraction with rhe compurer system, the user inrerface is a vital element in the S)'Stems
design phase.
User interface design requires an understanding of human-computer interaction
and user-centered design principles, which are discussed in rhe next section.
8.2 HUMAN-COMPUTER INTERACTION
A user interface is based on basic principles of human-computer inreracrion.
Human-computer interaction (HCij describes tbe relationship between computers
and the people who use rhcm ro perform rheir jobs, like the worker shown
in Figure 8-2. HCT concepts apply to everything from smarrphones to global
networks. In its broadest sense, HCI includes all the communications and
instructions necessary ro enter inpul to the system and to obtain output in the form
of screen displays or printed reports.
Early user interfaces involved users ryping complex commands on a keyboard,
which displayed as green cexr on a black screen. Then came rhe GUI, which was a
huge improvement because it used icons, graphical objects, and pointing devices.
Today, designers strive to translate user behavior, needs, and desire& into an interface
that user!> don't really notice. 18,\.1 has stated char the best user interfaces are "almost
transparent-you can ee right through rhe interface to your own work." In ocher
words, a tran~parcnt interface does not disrracr the user and calls no attention to
itself.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.2 Human-Computer Interaction
231
FIGURE 8-2 HCI Is essential to employee product.ivicy. whether the work Is done In a
traditional office setting or on a construetion site like the one shown In this figure.
A systems analyst designs user interfaces for in-house-developed software and
customizes incerfaces for various commercial packages and user productivity applicarions.
The main objective is ro create a user-friendly design that is easy to learn and
use.
Industry leaders Nlicrosofr and IBM both devote considerable resources to u~er
interface research. Figure 8-3 describes IBM Research's work on HCI. Their stated
goal is to "design ystems that a re easier and more deligbrfuJ for people to use."
Human-Computer Interaction and Data Visualization -
:--..·- -
... = ............ ,....OWl.tll~aMtir---....-....
......... .,.., .. ~ .. ,,. ............ o.. ...... ...
.,., ..... ,.,......,a"'49 ... ~till-....... ....
Olllr~ to ftilt prodllC'bMI ..,_....,..,..............,..._
111•~·~-.....
______
l•chillilo:OC*:oew ..... HuMM~
ill'Wtlt' ...............,.,,.,.. ~...._,. ..,..............
............ l'ld ...........""........... . ltd .................'"....
.._ ..... Ny
..._,
...,...,.....,..,...........,....,..
-=--I.:..:.- ..-
: ·•di.·•• . ~J.~ --~
.. coWiiJrwe - j SOCl'"'I
c otlon . ·'' &- .c "
: [::( ~-1 1=--- · :-~ ~ ,t
- - ' • ' -·,-..Iii 1 • .. Cl)
' !
' I !/j
. o.,.. ......................... ~ .. -~
AtH011wad•••• ... ....,..,~ .. .....,..._.. .. .,....,,.. . ........ td....._ •.,..,.,..
....,...,.,,_....,... ..... ,.,.,.,._..wMClw..,. .... et1n.,..ez• eacot..O•CHLM.1££t'VlS..,...C$CW ill
................. "*,... ........ ~ ......... .......
FIGURE 8-3 IBM's research division is a leAder in exploring human-computer
interaction (H CI).
Sowc•
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~ --- - ·· · ---~~-.,.- "~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 8
User Interface Design
232 8.3 Seven Habits of Successful Interface Designers
Because I ICI has a major impact on user productivity, it get!. lots of anentionespccially
where multimillion-dollar issues are concerned. For example, in the article
"Human-Computer lnceraccion in EJeccronic Medical Records: From the Perspectives
of Physicians and Dara ciencisrs" by E. Bologva er al. from Procedta Computer
Saence 100 (Elsevier, 2016), che authors describe how software usability has a major
impact on rhe medical profession, and noc everyone is happy about it-particularly
phy)icians who often struggle with electronic health records ( !:'. HR\ ) systems that
are poorly designed. In her article, 1'1s. Gardner points out that physicians often
multirask, answering a question about one patient while writing a prescnpnon for
another, and EHR sofrware was nor designed around char rypc of workflow.
CASE IN POINT 8.1:
CASUAL OBSERVER So i:1 \\',\RE
Casual Observer Software's main product is a program that monitors and analyzes user keystrokes
and mouse clicks to learn more about the way employees use their computer systems.
The problem Is that some users feel this is an unwarranted intrusion into their privacy. and
they prefer not to be observed. Some even fear that the data would be used for other reasons,
including performance appraisal. You are a consultant who has been hired by a client firm that is
trying to decide whether or not to use this software.
Before you advise the client, remember the Hawthorne effect, which suggests that
employees might behave differently when they know they are being observed. Finally,
think about the ethical issues that might be involved in this situation. What will you
advise your client, and why?
8.3 SEVEN HABITS OF SUCCESSFUL INTERFACE DESIGNERS
Although IT professionals have different views about interface design, most would
agree rhar good design depends on seven basic principles. Successful interface designers
use these basic principles as a matter of course-they become habits. These desirable
habits are described in the following sections.
8.3. 1 Understand the Business
The inrcrfocc designer must understand rhe underlying business funcrions and how
the sysrem supports individual, departmental, and enrerprise goals. The overall objective
is ro design an inrerface thar helps users to perform their jobs. A good srarting
point mighr be ro analyze a functional decomposition diagram (FDD). As descri bed in
Chapter 4, an FDD is a graphical represenracion of business functions rhac srarcs wirh
major functions and rhen breaks rbem down inro several levels of derail. An FDD can
provide a checklist of user rasks rhat must be included in the interface design.
8.3.2 Maximize Graphical Effectiveness
Studies show chat people learn bener visually. The immense popularity of Apple's
iOS and ~1 ic rosoft Windows is largely che result of their GUls that are easy to learn
and use. A well-designed interface can help users learn a new system rapidly and be
more productive. Also, in a graphical environment, a user can display and work wich
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase 3
Systems Design
8.3 Seven Habits of Successful Interface Designers
233
muhiple windows on a single screen and transfer data between programs. If the interface
supports data entry, it must follow the guidelines for data entry screen design
that are discussed farer in this chapter.
8.3.3 Think like a User
A systems analyst should understand user experience, knowledge, and skill levels. If a
wide range of capability exists, the interface should be flexible enough ro accommodate
novices as well as experienced users.
To develop a user-centered interface, the designer must learn ro think like a user
and see the S)'Stem through a user's eyes. The user interface must be easy to learn,
using terms and metaphors that arc familiar to users. Users are likely to have realworld
experience with many other machines and devices char provide feedback, such
as automobiles, ATMs, and microwave ovens. Based on chat experience, users will
expect useful, undersrandable feedback from a computer systen1.
Carefully examine any poinr where users provide input or receive output. Input
processes shou ld be easy co follow, intuitive, and forgivi ng of errors. Predcsigncd output
should be attractive and easy to understand, with an appropriate level of detail.
8.3.4 Use Models and Prototypes
From a user's viewpoint, rhe interface is the most critical part of the system design
because it is where he or ~he interacts with the sysrem-perhaps for many hours each
day. It is essenrial ro construct models and prorotypes for user approval. An interface
designer should obtain as much feedback as possible, as early as possible. Initial screen
designs can be presented to users in the form of a sroryboard, which is a sketch that
shows rhe general screen layout and design. The storyboard can be created with software
or drawn freehand. Users must test all aspects of che interface design and provide
feedback to the designers. User inpuc can be obtained in interviews, via questionnaires,
and by observanon. Interface designers also can obtain data, called usability metrics, by
using software chac can record and measure user inceracrion with the system.
8.3.S Focus on Usability
The user interface should include all tasks, commands,
and communications berween users and the information
system. The opening screen should show the main options
(Figure 8-4 is an illustration). Each screen option leads to
another screen, with more options. The objective is ro offer
a reasonable number of choices that a user easily can comprehend.
Too many options on one screen can confuse a
user-but coo few options increase the number of su bmenu
levels and complica te rhe navigation process. Often, an
effective strategy is to present the most common choice as a
default bur allow the u~er to select ocher options.
8.3.6 Invite Feedback
-
Register
SludenlS
Enter Grades
STUDENT SERVICES
I
I
Pnnt Grade
Repof1S
Help
Exll System
FIGURE 8-4 The opening screen displays the main
options for a student registration system.A user can click
an option to see lower-level actions and menu choices.
Even after the sysrem is operational, it is important to monitor
system usage and solicit user suggestions. The analyst can determine if system features are
being used as intended by observing and surveying users. Son1erin1es, full-scale operations
highlight problems char were nor apparent when the prototype was tested. Based on user
feedback, 1 lclp screens might need re,;sion and design changes to allow the system ro
reach its full potential.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
-

Chapter 8
User Interface Design
234 8.4 Guidelines for User Interface Design
8.3.7 Document Everything
All screen designs should be documenred for larer use by programmers. If a CASE
root or screen generaror is being used, the screen designs should be numbered and
saved in a hierarchy similar co a menu rree. U er-approved skerches and sroryboards
also can be used to document the user interface.
B)• applying basic user-centered design principles, a systems analyst can plan,
design, and deliver a successful user farerface.
8.4 GUIDELINES FOR USER INTERFACE DESIGN
A system might have advanced cechoology and powerful fearures, bur rhe real rest is
wherher users like it and feel that ir meets their needs. What follows is a set of general
guidelines for successfu l user interface design. These guidelines arc disrilled from years
of best prncrices in the industry. There is some overlap because many of rhe main
guidelines share common elements.
Although there is no standard approach 10 interface
design, these guidelines are a starting point su itable for
rradirional systems development. User interface development
for web applicati.ons or for mobile apps has its own unique
considerations, above and beyond these general guidelines.
Perhaps rhe most important guideline is rhar not all of these
recommendations musr be followed-the best interface is the one
rhat works besr for the users.
8.4.1 Create an Interface That Is Easy t o Learn and Use
I Dau -••IOildl Pluse s1an --..
I Dat a ts nol sultablP.
a-It ti... 1ru.1rucuoru for this
taslt and ti..."'""''°"' tast l
I Not enough a l• to prOCHd.
I T'"' data Is lncorrec:I.
Ple•stt use l he proper format:
Three lette.,. f ollowed by three
numMrs. with no~
EJtomple: CTSU$
FIGURE 8· 5 In the example at the top. the
icons do not have a clear menage. In the
Help text examples at the bottom. only one
message is understandable. The others would
frustrate and annoy most users.
1. Focus on system design objectives, rather than calling arrention
ro the interface.
2. Create a design rbat is easy ro undersrand and remember.
Mainrain a common design in all modules of the interface,
including rbe use of color, screen placements, fonts, and rhe
overaU "look and feel."
3. Provide commands, actions, and ~y rem re~ponses that are
consistent and predictable.
4. Allow users ro correct errors easily.
5. Clearly label all controls, butrons, and icons.
6. Select familiar images thar users can understand, and provide
on-screen instructions that are logical, concise, and cle.1r. For
example, the top screen in Figure 8-5 shows four control
buttons, but none of them has an obvious meaning. Jn the
bottom screen, the first five messages provide little or no
information. The last message i.s rhc only one rhar is easy ro
understand.
7. Show all commands in a list of menu items, bur dim any
commands that are not available ro rhe user.
8. Make it easy to navigate or return ro any level in rhe menu
srructure.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.4 Guidelines for User Interface Design
235
8.4.2 Enhance User Productivity
The interface is where a u er interacts with the system, so it can have a dramatic
effect on productivity. If the interface empowers a user and enables him or her to handle
more complex tasks, the user becomes more productive. Conversely, if the interface
1~ difficult to work with, productivity declines.
I. Organize tasks, commands, and functions in groups that resemble actual business
operations. Group functions and submenu items in a multilevel menu hierarchy,
or rree, that is logical and reflects how users typically perform the tasks.
Figure 8-6 shows an example of a menu hierarchy for an order tracking system.
Customer Order Tracking System
Main Menu
Customers Orders Products
Add 11 New Customer Enter a New Order Enter a New Product
Update Customer Data Modify Order Data Update Product Data
Delete a Cuslomer Csncel an Order Deleta a Product
FIGURE 8-6 This menu hierarchy shows casks. commands. and functions organized into
logical groups and sequences. The structure resembles a functional decomposition diagram
(FOO). which is a model of business functions and processes.
2. Create alphabetical menu hsrs or place che selectioas used frequently at the
top of the menu list. No universally accepted approach co menu item placement
exists. The best strategy is co design a prototype and obtain feedback
from users. Some applicacioas even allow menus to show recently used commands
first. Some users like char feature, but ochers find it distracting. The best
approach is to offer a choice and lee users decide.
3. Provide shorrcurs for experienced users so they can avoid multiple menu levels.
Shortcuts can be created using hot keys that allow a user to press rhe Ale key +
the underlined lener of a command.
4. Use default values if the majority of values in a field are the same. For example,
if 90% of the firm's customers live in Albuquerque, use Albuquerque as the
default va lue in the City field.
5. Use a duplicate vnluc function that enables users co insert the value from the
same field in the previous record, bur allow users to turn this feature on or off
as they prefer.
6. Provide a fast-find feature chat displays a list of possible values a11 soon as users
enter the first few letters.
7. Lf available, consider a natural language feature chat allows users to type
commands or rcquesrs in normal text phrases. For example, many applicat1ons
allow users to request Help by typing a question into a dialog box. The
software chen uses natural language technology to retrieve a list of topics that
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 8
User Interface Design
236 8.4 Guidelines for User Interface Design
match the request. Narural language technology is used in speech recognition
sy rems, text-to-speech synthesizers, automated voice response sysrems, web
search engines, text editors, and language insrrucrion material~.
8.4.3 Provide Flexibility
Suppose that a user wants a screen display of all customer balances that exceed
$5,000 in an accounts receivable system. How should that feature be designed? The
program could be coded to check customer bala11ces against a fixed value of 5000,
which is a simple solution for both the progranuner and the user because no extra
keysrrokes are required to produce the display. However, thar approach is inflexible.
A berrer approach would be to let cite user enter the amount. Or Starr wirh a default
value that displays automatically. Users can press ENTER to accept rhc value or type
in another value. Ofcen the best design strategy is to offer severa I alternatives, so users
can decide what will work best for them.
8.4.4 Provide Users with Help and Feedback
This is one of the most important guidelines because it has a high impact on users.
Never allow Help to slow a user down. Instead, make 1 lelp easy to find but not
around when users don't need it.
I. Ensure that help is always available on demand. Help screens should provide
informarion about menu choices, procedures, shortcut!>, and errors.
2. Provide user-selected help and context-sensitive help. User-selected help displays
information when rhe user requests it. By 1naking appropriate choices through
the menus and submenus, the user eventually reaches a screen with the desired
information. figure 8-7 shows the majn Help screen for the student regiscradon
S)'Srem. Context-sensitive help offers assistance for the task in progress.
Help Topics
Register Studeflts
Print Class Ros1ars
Enter Grades
Print Grade Reports
Index of Help T op1cs
~ct Tedi Supportj
FIGURE 8-7 The main Help screi!n for a student registration
system.
3. Provide a direct route for users co return co the point from where help was
requeMed. Title every help screen co jdentify the topic, and keep help cext simple
and concise. lnserr blank lines between paragraphs to make Help easier ro
read, and provide examples where appropriate.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.4 Guidelines for User Interface Design 237
4. Include conrnct information, such as a celephone extension or email addres if a
deparrment or help desk is responsible for assisting users.
5. Require user confirmation before data deletion (Are you sure?) and provide a
method of recovering data that is deleted inadvertently. Build in safeguards that
prevent critical data from being changed or erased.
6. Provide an "Undo" key or a menu choice rhar allows rhe user to undo rhe
results of rhc most recent command or action.
7. When a user-entered command contains a11 error, highlight the erroneous
part and allow the user to make the correction without rerypmg the entire
command.
8. Use hypertext links to assist users as rhey navigate help topics.
9. Display messages ac a logical place on the screen, and be consistent.
10. Alert users ro lengthy processing rimes or delays. Give users an on-screen progress
report, especially if the delay is lengthy.
11. Allow messages to remain on the screen long enough for users to read them.
ln some cases, the screen should display messages until the user takes some
action.
12. Let the user know whether the task or operation was successfu l or not. For
example, use messages such as Update cornpleted, All transactions have been
posted, or The ID Number iuas not found.
13. Provide a text explanation if an icon or image is used on a control button.
This can be accomplished using a "mouse hover" to displar a pop-up box with
explanation when the mouse is moved over an icon or image.
14. Use messages that arc specific, understandable, and professional. Avoid messages
that arc cute, cryptic, or vague, such as ERROR-You have entered a11
unacceptable L'alue, or Error DE-4-16. Better examples are as follows:
• l:.nter a number from 1 (low) to 5 (high)
• Customer 1111111ber 11111st be 1111meric
• Please re-enter a numeric LJalue
• Oil/ the Acco1111ti11g Department, Ext. 239 for assistance
8.4.5 Create an Attractive Layout and Design
This is a subjective area because reasonable people can differ on what is attractive.
The analyst should consider color, layout, and ease of use. Screen mock-ups and menu
trees can be created and tried on users to gee thei:r input. If in doubt, err on the side of
doing a bit less. For example, blinking messages initially may seem like a good idea,
they might noc be the best choice for the interface design. Also try to avoid too many
fonts, styles, and sizes, which can be distracting. Each separate style should communicate
something-a different level of detail, another copic, mandatory versus optional
actions, and so on.
1. Use appropriate colors to highlight different areas of the screen; avoid gaudy
and bright colors.
2. Use special effects sparingly. For example, animation and sound might be
effective in some situations, but too many special effects can be distracting and
annoying to a user, especially if he or she must view them repeatedly.
_
.........""_......-....... .......... ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~--- - ···---~~ - .,.-"~ ........... --......

Chapter 8
238
User Interface Design
8.4 Guidelines for User Interface Design
3.
4.
5.
6.
7.
Use hyperlinks that allow users to navigate to related topics.
Group related objects and information. Visualize the screen the way a user will
see it, and simulate the tasks that the user will perform.
Screen density is important. Keep screen displays uncluttered, with enough
white space co create an artracrive, readable design.
Display titles, messages, and instructions in a consistent manner and in the
same general locations on all screens.
Use consistent terminology. For example, do nor use the terms delete, cancel,
and erase co indicate the same action. Similarly, the ame sound always should
signal rhe same evenr.
8. Ensure that commands always will have the same effect. For example, if the
BACK control button returns a user to the prior screen, rhe BACK command
always should perform that function throughout the application.
9. Ensure that similar mouse actions will produce the same results throughout
the application. The resu lts of pointing, clicking, and double-clicking should be
consistent and predictable.
l 0. \Xlhen the user enters data tha;c completely fills the field, do not move automatically
co the next field. Instead, require the user to confirm the entry by pressing
the Enter key or Tab key at the end of every fill-in field.
I I. Remember that users are accustomed to a pattern of red = stop, yellow = caution,
and green =go. Stick to that partern and use it when appropriate to reinforce
on-screen instructions.
12. Provide a keystroke alternative for each menu command, with easy-to-remember
letters, such as File, Exit, and Help.
13. Use familiar commands if possible, such as Cur, Copy, and Paste.
14. Provide a \Vindows look and feel in the interface design if users are familiar
with Windows-based applications.
15. Avoid complex terms and technical jargon; instead,
select terms that come from ever)•day business processes
and the vocabulary of a typical user.
___ ...._............ __
...
.... __ ...,..,.
- -
_,.,,.,.. ............. ....
..
FIGURE 8-8 An e~mple of a switchboard introducing
Turbo Tax. The main options are tlearly displayed on an
uncluttered screen-something particularly Important for
users who are hkcly to be confused and/or ner<0us when
beginning the iax preparation process.
Souttg • • ,
8.4.6 Enhance the Interface
A designer can include many features, such as menu bars,
roolbars, dialog boxes, text boxes, toggle buttons, list
boxes, scroll bars, drop-down list boxes, oprion burrons,
check boxes, command buttons, and calendar controls,
among others. Screen design requires a sense of aesrhctics
as well as technical skills. U er feedback should be
obtained early and often as the design process continues .
1. The opening screen is especially important because it
introduces the application and allows users to view the
primary options. The starting point can be a ~witchboard
with well-placed command buttons that allow users to
navigate the system. Figure 8-8 shows the switchboard
of Turbo Tax introducing a tax preparation program.
The main options are clearly displayed on an uncluttered
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.4 Guidelines for User Interface Design
239
screen. The addition of che picrure showing cax professionals ready co help
provides a en e of calm and confidence co che user-someching parricularly
imporcanc for users who are likely co be confused and/or nervous when beginning
the cax prepararion process.
2. Use a conunand buHon co initiace an action such as printing a form or requesting
help. For example, when a user clicks the Find Student command button in
Figure 8-9, a dialog box opens wich instructions.
-
0
•
- ..
r
STUDENT REGISTRATION SYSTEM
-..1cv ...
2019-2020
Cont.ct IT Help at Ext. 2236
for user support
x
SSH 111 .. 11 .. 11 11
Liil N•nwt H.amftton
rlotN..,.e R...,
M I M ,
City New Hope
ST PA
Zlp l2J45
HornePo"°""(S55)9"--
E2I AdYhof Aj•ls~
!a tr•n.al~t Olt
• rvll TlrM
Street 607 w .. 1 5princ Strfft Worll Pl>oM (555) SU-- O PMITune
Courses
Pref · • Nutnbel • SKtJon •
MAT lU 2
-
OS
·
l
IUS
Find Student
Print Record
HELP
--r-ltudtnU
-by•h«llritU.,ol
-"'~""' ,_ -
Fond~
•
P!Nse ent~ a SocYl Security Numbe<.
use the format w u · UU.
a
x
FIGURE 8-9 A dar.a enrry screen for a student registration system.This screen uses several design reacures
that are described in the text. When a user dicks the Find Student command button. a dialog box ls displayed
with instructions.
3. If a sofcware p:ickage is being used, check ro sec if it allows the creation of
cu:.tomized menu bars and coolbars. lf so, consider these opcions.
4. Add a shorccuc feature chac Ices a user select a menu command either by
clicking the desired choice or by pressing the Alt key+ the underlined letccr.
Some forms also use a coolbar that contains icons or buttons that represenc
shortcucs for cxecucing common commands.
5. lf variable inpuc daca is needed, provide a dialog box chat explains what is required.
6. A toggle bunon makes it easy to show on or off stacus-dicking che coggle
button switches co the ocher stare.
_
.........""_......-................. ..__
("..,_..., llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~---- ···---~~ - .,.-"~ ........... --......

Chapter 8
User Interface Design
240 8.4 Guidelines for User Interface Design
7. Use liq boxe~ rhar display rhe available choices. If rhe lisr docs not fir in rhe
box, a scro ll bar allows the user ro move through the available choices. Also, be
sure ro provide another way ro enter data rhat does not align with a specific lisr
choice.
8. Use an option button, or radio bunon, to control user choices. For exa1nple,
if the user can select only one option, display a smtable message (Choose one
item), but if chere is no restriction, display a different message (Choose all that
apply). Use a black dot to show selected options.
9. If check boxes are used to select one or more choices from a group, show the
choices with a checkmark or an X.
10. \Xlhen dares must be entered, use a calendar control that allows the user to
select a dare that rhe system will use as a field value.
8.4. 7 Focus on Data Entry Screens
Data entry is especially important because it is in rhe job description of so many users.
I. Whenever possible, use a data entry method called form filling, where a blank
form that duplicates or resemb les rhe source document is completed on the
screen.
2. Restrict user access ro screen locarions where data is entered. For example, in
the Eventbrirc event management data entry when rhe screen in Figure 8-10
appears, the sysrem should position the insertion point in rhe first data enrry
location. After rhe operator enters an event ride, rhe insertion point should
move auromarically ro the enuy location for rhe next field (Location). A user
should be able to position che insertion poinr only in places where data is
enrcrcd on rhe form.
4 I I
--- -. o --
a-- ...
-
-
- -
---·----
--
---
. ..... ,_
FIGURE 8-10 In this data entry screen for creating ewints. the system generates start and end
dates and times automatically, but these can be changed by the user at any time.A red asterisk, as
shown beside Event Title, indicates required fields. Gray text within the data entry field leis the user
know what information to provide.This text is replaced with user input.
,......,
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
8.4 Guidelines for User Interface Design
241
3. Provide a way ro leave rhe data enrry screen ar any time without entering the
current record, such as a "Cancel" burron. Since che application shown in
Figure 8- I 0 is web based, chis can be accomplished by selecting the" Back"
bunon of rhe browser (not shown).
4. Provide a descriptive caption for every field, and show the user where co enter
the data and che required or maximum field size. Typically, wluce boxes show
the location and length of each field. Other methods used to indicate field locations
are video highlighting, underscores, special symbols, or a combination of
these features.
5. Provide a means for users co move among fields on the form in a standard
order or 111 any o rder the) choose. In a GUI, the user can override the standard
field order and select field locations using the mouse or arrow keys.
6. Allow users co add, change, delete, and vie'v records. Messages such as Apply
these changes? (YIN) or Delete this record?. (YIN) should requfrc users co
confirm the accions. Highlighting che letter N as a defaulc response will avoid
problems if the user presses the Enter key by mistake.
7. Design rhe screen form layout ro march the layout of the source document. If
the i.ource dc>cumenr fie lds srarr at the mp of the form and run down in a column,
the input screen should use the same design.
8. Display a sample format if a user must enter values in a field in a specific format.
For example, provide an on-screen instruction ro let users know that rhe
dare format is MMDDYY, and provide an example if rhe user must enter separators,
such as slashes.
9. In addition to rhe sample format in che preceding rule, it might be better to
use an mput mas!-, which is a template or pattern that reMricts data entry
and prevents errors. Microsofr Access provides standard input masks for
fields such as dates, telephone numbers, postal codes, and Social Securit)'
numbers. In adduion, custom inpur masks can be created, as shown in
Figure 8-1 1. Note char a mask can have a specific format. For example, if a
user enters cext in lowercase letters, che input mask will capitalize the first
letter auromarically.
10. Require an ending keystroke for every field. Pressing the Enter key or che Tab
key should signify the end of a field entry. Avoid a design char moves auromarically
10 rhe next irem when rhe field is full. The latter approach requires an
ending keystroke only when the data entered is less rhan the maximum field
length. It is confusing rouse two different dara entry procedures.
11. Do not require users to type leading zeroes. for numeric fields. For example,
if a three-digit projecr number is 045, rhe operator should be able to type 45
instead of 045 before pressing the Enter key. An exception to that rule might
occur when entering a date, where a leading zero is needed to identify singledigit
monchs or days, such as 06-04-2013.
12. Do not require users to type trailing zeroes for numbers that include decimals.
For example, when a user rypes a value of 98, the system should interpret che
value as 98.00 if the field has been formatted to include numbers with rwo
decimal places. The decimal point is needed only ro indicate nonzero decunal
places, such as 98.76.
13. Display default values so operators can press the Enter key to accept the suggested
value. If the default value is not appropriate, the operator can change ir.

Chapter 8
User Interface Design
242 8.4 Guidelines for User Interface Design
.. -
p
Hllp . .
l_..... ............
...__
----
........... ---.------...... ,.. __ ...........
---
-- ---
-
- .............
.........................................
-·--- ....
-....-------..
Q:li. \lt-tti.l .........
.,__ ,.. .......... __ .......... .,..,, ..
._, __ ..,.
c-... _.,.....__.........,....._....
c-.. -•••
__
__...
....... .......... ..............
~
_., ~"---~
--~---__,.
-... ...................... ________ -.---................
......,....,.. •
... p
Htlp . .
• uw..._.. ....... .i ...
t u... ............. ...
'----·-
llW•-·--
.. * ............. ...
. ....-..........
. ..._ __ .... ... _
' ~---·-
.. .,...
FIGURE 8 -1 1 MicrosoftAccess provides various input masks
for dates, phone numbers, and postcodes, among others. In
addition, it is easy to create a custom mask using the characters
shown here.
56u~e1 ~ e,... ~7.00tl'
14. Use a default value when a field value will be constant for successive records or
throughout rhe data entry session. For example, if records are input in order by
dace, the dare used in che first transaction should be used as the default date until
a new date is entered, at which time the new date becomes the default value.
15. Display a list of acceptable values for fields, and provide meaningful error
messages if the user enters an unacceptable v:ilue. An even better method, which
was described under Rule 5: Enhance the Imerface, is co provide :i drop-down list
box containing acceptable values that allows the user co select a value by clicking.
16. Provide users with an opportunity to confirm the accuracy of input data before
entering it by displaying a message such as, Add this record? (YIN). A positive
response (Y) adds the record, clears the entry fields, and position~ rhe insertion
point in the first field so the user can input another record. If rhe response is
negative (N), the current record is nor added and the user can correct the errors.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

~ s...
8.4 Guidelines for User Interface Design
Phase l
Systems Design
243
Dara enrry screens should also anricipare furure needs. Consider a parts invenror}'
database rhar contains a one-character field for category, such as elecrrical, mechanical,
or hydraulic. The design works well, bur whar if rhe compan)' decides ro break
these overall groups down inro more specific segmenrs? A bener design would anticipate
pos~ible expansion ro two or more characters. For example, in 1999, there was
widespread concern about whar was called rhe Y2K issue because many older programs
used only rwo characters co store the year and might not recogni1e the start of
a new century.
8.4.8 Use Validation Rules
Reducing inpur errors improves data quality. One way to reduce input errors is to
eliminate unnecessary data entry. For example, a user cannol misspell a customer
name if i1 is not entered or is entered automatically based on the user enrering the
customer ID. Similarly, an outdated item price cannot be used if the item price is
retrieved from a master file instead of being entered manually. The best defense
against incorrect dara is to identify and correct errors before they enrer the sysrcm by
using data validation rules, as shown in Figure 8-12. A data validation rule improves
input quality by testing rhe data and rejecting any entry that fails to meet specified
conditions. The design can include at least eight types of data validation ru les.
p
•
~-------.......
--
..
..
.. ...
-·-
-
--
...,, ___
... ..... _
....
____ ,...,._
.... -----.-.---
_____ __.....,. ...-...._._..._
....--~
.____ _
..,
........ .....-......
.. _
• •
•
•
.. ,.... .. _.....__.._.._............... l!OJ • ____ ..._
-·•mtiau
. ---......... -. ..• ,....,_ -~ ..... .._,
............. -_...51111 .......... __._
..... .., ......
........................ _............ ____ ,,,,. ___ _
----... - •4 ... ------ ........ -
FIGURE 8-12 Microsoft Access provides varidauon rules that
can improve daa quality by requiring the input to meet specific
requirements or conditions.
- c
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~----··----~~ - .,.-"~ ........... --......

Chapter 8
User Interface Design
244 8.4 Guidelines for User Interface Design
I. A sequence check can be used when the data must be in some predetermined
sequence. If the user musr enter work orders in numerical sequence, for example,
then an our-of-sequence order number indicates an error, or if rhe user must
enter transactions chronologically, then a transaction with an out-of-sequence
dare indicates an error.
2. An existence check can apply to mandatory data items. For example, if an
employee record requires a Social SecUiity number, an existence check would
not allow the user to save the record until he or she enters a suitable value in
the Social Security number field.
3. A dara I ) pc check can rest to ensure that a data item fits the required data
type. For example, a numeric field must have only numbers or numeric symbols,
and an alphabetic field can contain only the characters A through Z (or a
through z).
4. A range check can be used to verify that data items fall between a specified
minimum and 1naximum value. The daily hours worked by an employee, for
example, must fall within the range of 0 to 24. When the validation check
involves a minimum or a maximum value, but nor both, it is called a limit
check. Checking that a payment amount is greater than zero, but not specifying
a maximum value, is an example of a limit check.
5. A reasonableness check identifies values that are questionable bur not necessarily
wrong. For example, input payment values of $0.05 and $5,000,000.00
both pass a simple limit check for a payment value greater than zero, and yet
both values could be errors. Similarly, a daily-hours-worked value of 24 passes
a 0 to 24 range check; however, the v:tlue seems unusual, ,1nd the system should
verify it using a reasonableness check.
6. A validity check can be used for data items that muse have cerrain values. For
example, if an invenrory system has 20 valid item classes, then any input item
that docs nor march one of the valid classes will fail rhe check. Verifying that
a cusromer number on an order marches a customer number m rhc customer
file is another rypc of validity check. Because the value entered musr refer ro
another value, that type of check also is called referential integrity, which is
explained in Chaprcr 9, Dara Design. Another validity check might verify thar a
new cusromer number does nor march a number already stored in the customer
master file.
7. A combination check is performed on rwo or more fields to ensure that they
arc consistent or reasonable \Vben considered together. Even though all rhe
fields involved in a combination check might pass their individual validarion
checks, rhe combination of the field values might be inconsistent or unreasonable.
For example, if an order input for 30 units of a particular item has an
input discount rate applicable only for purchases of I 00 or more units, then
the combination is inval id; either the input order quantity or the input discount
rare i~ incorrect.
8. Barch controls are totals used to verify batch input. Batch controls might check
data items such as record counts and numeric field torals. For example, before
entering a batch of orders, a user might calculate the total number of orders
and rhe sum of all the order quantities. When the batch of orders is entered,
the order system also calculates the same two totals. lf the system corals do
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
8.4 Guidelines for User Interface Design
Phase l
Systems Design
245
nor match the input totals, then a data entry error has occurred. Unlike rhe
other validation checks, batch controls do nor idenrify specific errors. For
example, if the sum of all the order quantities does not march rhe batch control
total, the only thing known is that one or more orders in that batch were
entered incorrecrly or nor input. The batch control totals often are called ha ~h
total ~ because they are nor meaningful numbers themselves but are useful for
comparison purpo~es.
8.4. 9 Manage Data Effectively
In addition to irs effect on users, data management impacrs company efficiency, producriviry,
and security. To reduce input errors, the system should enter and verify dara
as soon as possible, and each dara irem should have a specific rype, such as alphabetic,
numeric, or alphanumeric, and a range of acceptable values.
It is important ro collect inpur dara as close to irs source as possible. For insrance,
using barcode scanners r:icher rhan manual forms on a warehouse freight dock, or
having sa lespeople use rablers to record orders rather than filling in source documents.
The easiest, mosr accur:ire, and least expensive dara input strategy is automated
dara capture.
In an efficient design, data is en tered only once. For example, if input data for
a payroll system also is needed for a human resources system, the analyse could
design an interface co transfer data automatically, or a central data storage area
could be created char both systems can access. Chapter 9 describes normalizarion,
which is a sec of rules chat can help avoid data design problems. A secure sysrem
also includes audit trails rhat can log every instance of data entry and changes.
For example, the system should record when a customer's credit limit was sec,
by whom, and any ocher information necessary to consrruct the history of a
transaction.
8.4. 10 Reduce Input Volume
This is the final guideline, bur in some ways it sbouJd be the first because it affects all
the resr. When input volume is reduced, unnecessary labor coses are avoided, which in
turn gets the data inro rhe system more quickly and decreases the number of errors.
Therefore, the analyst should start by reducing the number of data items required for
each transaction.
1. Input necessary data onl)•. Do not input a data item unless it is needed by the
system. A completed order form, for exaJnplc, might contain the name of rhe
clerk who took rhe order. If that data is not needed by the system, the user
should nor enter it.
2. Do nor input dara rhar rhe user can retrieve from system files or ca lculate from
ocher dara. This reduces input errors and dara inconsistencies.
3. Do not input constant dara. lf orders are in batches with the same date, then
a user sho uld enter the order date only once for the firsr order in the batch. If
orders are entered online, then the user can retrieve the order date automatically
using the current sysrem date.
4. Use code~. Codes arc shorter than the data they represent, and coded input can
reduce data entry rime. Codes are discussed more in Chapter 9.

Chapter 8
User Interface Design
246 8.5 Source Document and Form Design
CASE IN POINT 8.2:
BOOLEAN TOYS
Suppose you are a systems analyst swdying the order processing system at Boolean Toys. a
fast-growing developer of software for preschool children. You know that many data entry
users have complained about the input screens. Some users would prefer to rearrange the
order of the fields. others would like to change the background color on their screens. and still
others want shortcuts that would allow them to avoid a series of introductory screens.
What if Boolean's users could customize their own data entry screens without assistance
from the IT staff by using a menu-driven utility program? What would be the pros
and cons of such an approach1When should a systems analyst decide a design issue, and
when should users be allowed to select what works best for them?
8.5 SOURCE DOCUMENT ANO fORM DESIGN
No marrer how data enters an information system, the quality of the output is
only as good as the quality of the input. The term garbage in, garbage out (G IGO)
is fami liar to IT professionals, who know that the best time to avoid problems
is when the data is entered. The main objective is to ensure the quality, accuracy,
and timeliness of input data. Unfortunately, the dream of a "paperless office" has
never been realized. Even with RFlD technology and automated data capture, we
still enter data on source documents and fo rms, and instead of a human-computer
interface, systems analysts muse deal with the challenge of a human-paper
interface.
A ~ource document collects inpur dara, rriggers or authorizes an input acrion,
and provides a record of the original transaction. During the input design stage, the
analyst develops source documents that are easy to complete and u e for dara entry.
Source documents generally are paper based but also can be pro,ided online. Eicher
wa)', the design considerarions are che same.
Consider a rime when it was a srruggle to complete a poorly designed form. There
mighc have been insufficient space, confusing instructions, or poor organ1.l.3non-all
symptoms of incorrect fonn layout.
Good form la)'OUt makes the form easy to complete and provides enough space,
both vercically and horizonrally, for users to enter the data. A form should indicate
data entry positions clearly using bla nk lines or boxes and descriptive captions. Also
consider using check boxes whenever possible, so users can select choices easily. However,
be sure to include an option for any input that does not match a specific check
box.
The placement of information 011 a form a lso is important. Source documents
typically incl ude most of the zones shown in Figure 8-13. The heading zone
usua lly contains the company name or logo and the title and number of the
form. The control zone contains codes, identification information, numbers, and
dates rhat are used for storing completed forms. The instruction zone contains
instructions for completing rbe form. The main part of the form, called rhe body
zone, usually cakes up at least half of the space on the form and contains captions
and areas for entering variable data. If rota ls are included on the form, they
appear in the totals zone. Finally, the authorization zone contatns any required
signatures.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
8.6 Print ed Output
24 7
Heading
Zone
Control
Zone
lnstructioo Zone
Body
Zone
Totals
Zone
Authorization Zone
FIGURE 8-13 Source document zones.
lnformanon should flow on a form from left co right and top to bottom to match
the way users read documents naturally. That layout makes the form easy to use for
the individual who completes the form and for users who enter daca into the system
using the completed form.
The same user-friendly design principles also apply to printed forms such a~
invoices and monthly statement , except that heading information usuall)' 1s preprinted.
Column headmgs should be short but descriptive, avoiding non!>tandard
abbre\lat1on!>, wtch reasonable spacing becween columns for bener readability.
The order and placement of printed fields should be logical, and totals should be
identified clearly. When de~igning a preprinted form, contact the form's vendor for
advice on paper sizes, rype styles and sizes, paper and ink colors, field placement, and
other important form derails. The goal is to design a form that is anractive, readable,
and effective.
Layout and design also are important on web-based forms. TI1ere arc many
resources that will help with designing efficient, user-friendly forms. These include
websites that muse conform to the U.S. Federal Government's accessibi lity guidelines,
which can be found online ar http://www.section508.gov.
8.6 PRINTED OUTPUT
Before designing printed output, there arc several questions to consider:
• Why is this being delivered as printed output, rather than screen-based information,
with an option for users to view, print, or save as needed?
• \'<'ho wants the information, why is it needed, and how will it be used?
• \'<'hat specific informarion will be included?
• \'V1ll the printed output be designed for a specific device?

Chapter 8
User Interface Design
248 8.6 Printed Output
• When and how will the information be delivered, and how ofren must it be
updated?
• Do security or confidentialiry issues exist? How will they be managed?
The design process should not begin until these questions have been answered.
ome information probably was gathered during the systems analysis phase. To gain
more understanding, the analyst should meet with users to find out exactly what kind
of output they are requesting. Prototypes and mock-ups can be u~ed to obtain feed ­
back throughout the design process.
8.6. 1 Report Design
Although many organizations strive to reduce the flow of paper and printed reports,
few firms have been able to eliminate printed output totally. Because they are porrable,
printed reports are convenient and even necessary io some situations. Many users
find it handy to view screen output and then print the information they need for a
discussion or business meeting. Prinred output also is used in turnaround documents,
which :ire output documents rhat are later entered back into the sa me or another
information system. In some areas, the telephone or utility bill, for exa mple, might be
a turnaround document printed by the company's billing system. When the required
portion of rhe bill is returned with payment, rhe bil l is scanned into the company's
accounts receivable system to record the payment accurately.
Designers use a variety of styles, fonts, and images ro produce reports that arc
attractive and user-friendly. Whether printed or viewed on-screen, reports must be
easy to read and well organized. Rightly or wrongly, some managers judge an entire
project by the quality of the reports t hey receive.
Databa~e programs such as ~1icrosofr Access include a variery of report design
tools, including a Report Wizard, which is a menu-driven fearure that designers can
use to create reports quickly and easily. Many online web-based database systems also
provide similar report design guidelines.
Although the vast majorit}' of reports are designed graphically, some S)'Stems srill
produce one or more ch aracter-based reports that use a characcer set with fixed spacing.
Pruning character-based reports on high-speed impact pnncer~ 1s a fasr, inexpensive
method for producing large-scale reports, such as payroll or mventory reports, or
registration rosters at a school. This is especially true if multiple copie :ire required.
Users should approve all report designs in advance. The best approach is ro prepare
a sample report, called a mock-up, or prototype, for users to review. The sample
should include typical field values and contain enough records to show all the design
features. Depending on the type of printed output, a Microsoft \"Qord documenc can
be created, or a report generator used, to create mock-up reports.
8.6.2 Report Design Principles
Printed reporrs must be attractive, professional, and easy to read. For example, a
well-designed report should provide totals and subtotals for numeric fields. In the
reporr shown in Figure 8- 14, nore thar when the value of a control field, such as Store
Number, changes, a control break occurs. A control break usually causes specific
actions, such as printing subtotals for a group of records. Thar rype of derail report is
called a control break repo rt. To produce a control break report, the records must be
arranged, o r sorred, in control field order.
Good report design requires effort and attention to detail. To produce a welldesigned
report, the analyst must consider design features )uch as reporr headers and
footers, page headers and footers, column headings and alignment, column spacing,
field order, and grouping of detail lines.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

8.6 Print ed Output
Phase l
Systems Design
249
REPORT HEADER.SAND FOOTERS: Every report should have a report header and
a report footer. The report header, which appears at the beginning of the report, identifies
the report and contains the report title, date, and other necessary information.
The report footer, which appears ac che end of rhe report, can include grand totals for
numeric fields and ocher end-of-report information. as shown in Figure 8-14.
PAGE HEADERS AND FOOTERS: Every page should include a page header, which
appears at the rop of rhe page and includes the column headings that identify the
lden~fying ftelds
Employee Hours
Week ending date: 6128/2019
hours fields
Store Employee Regular Overtime
Number Name Position Hours Hours
Total
Hours
report header
}
} page header
8 Andres, Marguerite Clerk 20.0 0.0
8 Bogema, Michelle Clerk 12.5 0.0
8 Davenport, Kim Asst Mgr 40.0 5.0
8 Lemka, Susan Clerk 32.7 o.o
8 Ramirez, Rudy Manager 40.0 8.5
8 Ullery, Ruth Clerk 20.0 0.0
control break
on Store Store 8 totals: 165.2 13.5
Number field
20.0
12.5
45.0
32.7
48.5
20.0
178.7
}
group footer
17 De Mar!Jnl, Jenniler Clerk 40.0 8.4
17 Haff Lisa Manager 40.0 00
17 R1ttenbery, Sandra Cterk 40.0 11 0
17 Wyer. Elizabeth Clerk 20.0 00
17 Zeogler Cealle Clerk 32.0 00
48.4
40.0
51.0
20.0
32.0
Store 17 totals: 172.0 19 4
Grand totals: 337.2 32.9
191.4
370.1
Page 1
}
}
report footer
page footer
FIGURE 8-14 The Employee Hours report is a detailed report with concrol breaks, subtotals, and grand totals. N ote that a report
header identifies the report. a p~ge header contains column headings, a group footer contains subtotals for each score. a report
footer contains grand totals, and a page footer identifies the page number.
data. The head ings should be shorr but descriptive. Avoid abbreviations unless the
users will understand them clearly. Either a page header or a page footer, which
appears ar rhe borrom of the page, is used ro display rhe report title and the page
number.
Database programs such as Microsoft Access make it easy ro create groups and
!>ubgroup~ based on particular fields. The report can also calculate and display torn Ii.,
average~, record counts, and orher data for any group or subgroup. For example, a
large company might want to see total sales and number of sales broken down by
product within each of the 50 stares. The information shown in Figure 8-15 is part
of Acct!l>!>' on line help that refers co a step-by-step process for creating multilevel
group mg.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 8
User Interface Design
250 8.6 Printed Output
Create a grouped or summary report
OOt.... -'019.-20•8,-2t!1--~ !),
lnlonna1lon IS often - ID undlnland when~ IS - inlO groupL For_,_., . report lhet groups
- by NglOn can hlgllloghl tnnds tNll ,,._,.. moghl go u11110Ciced In lddi1'0t\ ~ tOCllll c.ICh a
...... or a>•~ ot lhl tnl ol wh graup., your repor1 can replKe a lol ol menuel ln!inclO'l ,..th 1
ClbAa!or
.-.:c.a mel;ee worldng "'"" giouped teports 911SY. 'lb.I Cll1 ...... bulc grouped report by ... ng lhl
~ Wlzald. )IOU can edd ~ng and son.>g to an OXlltJng t9pOtl. or )IOU can - grouping and
IOt""O Oll(IOnt tnet have en.ly been dellned.
kind"' di!_ you deolgn- - .,.,
pUllll9l1 Ol'lllne
Not•: Tl* - _,, llllPll' "'----tho
In this article
C..ata a quick grouped or sorted report
Build 1 new grouped report by us.ng the Report Wlzatt:I
Acid or modlly Q""""'111 and sort.ng in an elOSbng report
FIGURE 8- IS MicrosoftAccess includes an easy-co-use tool for grouping data .
Sourc: .. M roi a-- r "'P'
.JOfl
REPEATING FIELDS: Report design is an art, noc a science. User involvemcnc is
csscnrial, hue users ofcen don'r know whar they want without seeing samples. for
example, consider che issue of repeating fields. The sample report in Figure 8- 14
repeats the store number on every row. Is chat a good thing? The best advice is co ask
users what they think and be guided accordingly. A similar issue exiscs with regard to
the overtime hours column. ls ir bener co print the zero·O\'ertime data, or only print
actual hours, so che data srands our clearly? Again, the best answer is usually the one
that works best for users.
CONSISTENT DESIGN: Look and feel are important to users, so reports should
be uniform and consiscenr. When a system produces multiple reports, each reporr
should share common design elements. For example, the date and page numbers
should print in the same place on each report page. Abbreviations used in reporcs also
should be consistent. For example, when indicating a ntuneric value, it is confusing
for one reporc to use#, anorher NO, and a chi.rd NUM. ltems in a report also should
be consistent. ff one report displays the inventor)' location as a shelf number column
followed by a bin number column, that same layout should be used on all inventory
location reports.
8.6.3 Types of Reports
To be useful, ::i report must include the information that a user needs. From a user's
point of view, a report with too Little information is of no value. Too much information,
however, can make a report confusing and difficult to understand. When design·
ing reports, the essential goal is ro match the report co the user's specific informarion
needs. Depending on rhcir job functions, users might need one or more of the reports
described in rhe following sections.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.7 Technology Issues
251
DETAIL REPORTS: A derail report produces one or more lines of ourpur for each
record processed. Because it contains one or more lines for each record, a derail
report can be quite lengthy. Consider, for example, a large auto parts bu5iness. If the
firm stocks 3,000 parts, then rhe derail report would include 3,000 derail lines on
approximately 50 printed pages. A user who wants to locate any part in short supply
has ro examine 3,000 derail lines ro find the critical items. A better alternative might
be an exceprion reporr.
EXCEPTION REPORTS: An exception report displays only those records that meet
a specific condinon or conditions. Exception reports are useful when the user wanrs
information only on records char might require action bur does not need to know the
derails. For example, a credit manager might use an exception report ro identify only
those customers with pasr-duc accounts, or a customer service n1anager might want a
report on all packages that were not delivered wi-rhin a specified time period.
SUMMARY REPORTS: Upper-level managers often want ro sec toral figu res and do
nor need supporting details. A sales manager, for example, might want ro know total
sales fo r each sa les representa tive but not want a derail report listing every sale made
by them. In rhat case, a ~ ummary report is approp riate. Similarl y, a personnel 111:111-
ager might need ro know the rota I regular and overtime hours worked by employees
in each store bu r might nor be interested in the number of hours worked by each
employee.
CASE JN POINT 8.3:
L AZY EoorE
Lazy Eddie is a furniture chain specializing in recliners. Their management has asked you to
review the large number of printed reports that are distributed to Lazy Eddie's 35 store
managers. Management is not sure that the managers actually read or use the reports,
even though the store managers say they want them. Store visits have shown many of the
reports end up sucked on top of filing cabinets. seemingly untouched.
To determine if store managers really use the printed reports. management has asked
you to create a procedure that requires users to review and justify their information
needs. You could design a form that asks if the information still is required, and why. You
could try to get users co decide if a report is worth che cost of producing it. How do you
proceed!
8. 7 TECHNOLOGY Issues
Unlike early innovations such as the mouse and the inkjet printer, most technology
advances today affect both output and input. In a very real sense, output and input
have become interdependent, as rhey are in a user interface, and it is difficult to cite
examples of changes in one that would acn cause, or at least encourage, changes in
the other. For example, new touch-screen input technology generates output that
must be properly designed and sized for a panicllllar device, which might be a smarcphone,
a tablcr, or a 23-inch desktop monitor.
The following sections discuss outpur and input technology separately, bur interface
designers should always be al ere to the possible opportunities, or potential problems,
of input/output linkage.
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 8
User Interface Design
252 8.7 Technology Issues
8.7.1 OutputTechnology
Alrhough business information systems srill provide mosr output as screen di~plays
and printed matter, technology is having an enormous impact on how people communicate
and obtain information. This rrend is especial!)' important ro firms char
use informarion technology to lower their costS, improve employee producriv1ry, and
communicate effectively with their customers.
In addirion to screen output and printed matter, output can be delivered m many
wa)'S. The system requirementS document probably identified user output needs.
Now, in the systems design phase, rhe analyst creates the actual forms, reports, documents,
and orher rypes of output that might be accessed from workstarions, notebooks,
tablets, smarrphones, and other devices. How the information will be used,
stored, and retrieved must also be considered. The following subsections explain va rious
output types and technologies.
INTERNET-BASED INFORMATION DELIVERY: Millions of fi rms use the Internet to
reach new customers and markets around the world. To support rhe explosive growth
in e-commerce, web dcsi&rners must provide user-friendly screen interfaces that display
ourpur and nccept input from cusromers. For example, a business can link irs invenmry
system to its website so the ourput from the inventory system is displayed as an
on line cam log. Customers visiting the site can review the items, obtain current prices,
and check product availabiliry.
Another example of web-based o utput is a system that provides customized
re~ponses to product or technical questions. When a user enters a product inquiry or
requests technical support, the system responds with appropriate information from
an on-site knowledge base. Web-based delivery a llows users to download a universe
of fi les and documents to support their information needs. For example, the web provides
consumers with instant access to brochures, product manual , and parts lists,
while prospective homeburers can obtain instant quotes on mortgages, insurance, and
other financial services.
To reach prospective customers and investors, companies also use a live or prerecorded
\ .. ebcast, which is an audio or video media file distributed over the Internet.
Radio and TV stations also use this technique to broadcast program material to their
audiences.
EMAIL: Email is an essential means of internal and external business communication.
Employees send and receive email on local or wide area networks, including the
Internet. Companies send new product information to customers via email, and financial
services companies use email messages ro confirm on line srock trades. Employees
use ema il to exchange documents, data, and schedules and to share business-related
information they need to perform th eir jobs. In many firms, email has virtually
replaced traditional memos and pri nted correspondence.
BLOGS: \Xleb-based logs, called biogs, are anorher form of web-based output.
Because biogs are journals written from a particular point o f view, rhey nor only
deliver facts to web readers bur also provide opinjons. Biogs are useful for po~ting
news, reviewing currenr events, and promoting products.
INSTANT MESSAGING: This popular form of communication is another way for
individuals and companies ro communicate effectively over the Internet. Although
some users feel that it can be a distraction, others like rhe constant flow of communication,
especially as a team member in a collaborative situation.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
8.7 Technology Issues
253
WIRELESS DEVICES: ~1cssages and data can be transmitted to a wide array of
mobile devices, including rabler computers, smarrphones, and similar wireless produces
rhar combine porrable computing power, multimedia capabilit)', and lnterncr
access.
DIGITAL AUDIO, IMAGES, AND V IDEO: Sounds, images, and video clips can be captured,
srored in d1g1ral format, and cransmirred as output to users who can reproduce
the content.
Audio or video ourput can be attached to an email message or inserred as a clip in
a Nlicrosofr \Xlord document. Businesses also use automated systems to handle voice
transactions and provide information ro customers. For example, using a telephone
keypad, a cusromer can confirm an airline seat assignment, check a credir card balance,
or derermine rhe current price of a mutual fund.
If a picture i!> worrh a rhousand words, then digital images and video clips certainly
are high-value ourpur types char offer a whole new dimension. For example, an
insurance adjuster with a digita l camera phone can take a picture, submit the image
via a wireless device, and receive immediate authorization to pay a claim on the bpOt.
1f unages are a valuable form of output, video clips are even better in some situations.
for example, video clips provide online virtual tours that allow realtors to show off
the best features of homes they are marketing. The user can zoom in or out and rota re
the iJnage in any direction.
AUTOMATED FAX SYSTEMS: An automated fax or f~back sy:.rem allows a
customer ro request a fax using email, via the company website, or by telephone.
The respon e is transmitted in a matter of seconds back co the user's fax machine.
Although most users prefer to download documents from the web, many established
organizations still offer an automated faxback service as another way to provide
inunediate response 24 hours a day to a certain ser of customers. Certain industries
in particular, such as drug scores and doctor's offices, insurance companies, and real
estate brokers, still rely on fax machines as a primary way of communication.
PODCASTS: A podcast is a specially formaned digital audio file that can be downloaded
by internet users from a variety of content providers. Many firms use podcasts
as sales and marketing cools and to communicate witb their own employees. Using
software such as iTunes, users can receive a podcast, launch the file on tbeir computer,
and store it on their porrable player. Podcasrs can include images, sounds, and video.
COMPUTER OUTPUT TO DIGITAL MEDIA: This process is used when many paper
docun1ents muse be sc::inned, stored in digital format, and retrieved quickly. For example,
if an insurance company stores rhousands of paper applic::ition forms, special
software can treat the documents as data and extract inforn1ation from a particular
column or area on rhe form. Digita l storage media can include n1agnetic tape, CDs,
DVDs, and high-density laser disks.
SPECIALIZED FORMS OF OUTPUT: An incredibly diverse marketplace requires
many forms of specialized output and devices. For example:
• Portable, web-connected devices that can run multiple apps, handle multimedia
output, and provide powerful, mulripurpose communication for users
• Retail poinr-of-sale terminals rhat handle computer-based credit cord transactions,
print receipts, and updare inventory records

Chapter 8
User Interface Design
2 54 8.7 Technology Issues
• Auromaric relier machines (AT Ms) that can process bank transacrions and
print deposir and withdrawal slips
• Special-purpose printers rhat can produce labels, employee ID cards, driver's
licenses, gasoline pump receipts, and, in some states, lottery rickets
• Plotters that can produce high-quality images such as blueprints, maps, and
electronic circuit diagrams
• Electronic detection of dara einbedded in credir cards, bank cards, and
employee identification cards
8.7.2 lnputTechnology
Input rechnology has changed dramarically in recent years. ln addition ro traditional
devices and methods, there has been a rapid expansion of new hardware and ways to
capture and enter data into a system, some of which are shown in Figure 8-16. Businesses
are using the new rechnology to speed up the input process, reduce cosrs, and
capture daca in new forms, such as digital signatures.
INPUT TECHNOLOGY
Traditional Evolving Emerging
Keyboard Body motion detection Brain-computer interfaoe (BCI)
Mouse Advanced voice recognition Neural networks
Polnhng devices Biological feedback Arllfcal intelligence (Al)
MicrophOne Embedded magnetic data Advanced motion sensors
OCR (optical character
recogn1lion)
RAD
Two-way satellite interface
MICA (magnetic mk character
recognnion)
Advanced opt'Cal recogn&tiOl'I V1nual environments
Graphic input devices Physical adaptaoon dev>ees 3·0 tecnnok>gy
FIGURE 8- 16 Input devtees can be very traditional or based on the latest technology.
Input methods should be cost-efficient, timely, and as simple a~ possible. Systems
analysts study transactions and business operarions to determine how and when data
should enter the system. Usually, the first decision is whether to use batch or online
inpul meLhods. Each metbod has advantages and disadvantages, and the systems analyst
must consider the following factors.
BATCH INPUT: Using batch input, data entry usually is performed on a specified
rime schedule, such as dai ly, weekly, monthly, or longer. For example, batch input
occurs when a payroll department collcctS rime cards at the end of the week and
enters the data as a barch. Anorher example is a school that enters all grades for the
academic term in a batch.
ONLINE INPUT: Although batch input is used in specific situations, most business
activity requires online data en try. The online method offers major advantages,
including the immediate validation and availability of data. A popular online input
method is ~o u rce data automation, which combines online dara entry and automated
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.8 Security and Control Issues
255
data capture using input devices such as radio frequency idenrificarion(RFID) tags,
magnetic data srrips, or even smarrphones. Source data automation is fast and accurate
and minimizes human invokement in the translation process.
~1any large companies use a combination of source daca automation and a powerful
communication network to manage global operations insranrl)'· Some common
examples of source data automation are as follows:
• Businesses that use point-of-sale (POS) terminals equipped with bar code scanners
and magnetic swipe scanners ro input credit card data
• Automatic teller machine (ATMs) that read data srrip on bank cards
• Factory employees who use magnetic ID cards to clock on and off specific jobs
so the company can track production coSts accurately
• Hospitals that imprint bar codes on patient identification bracelets and use
portable scanners when gathering data on patient treatment and medic:ition
• Retail stores that use porrablc bar code scanners to log new shipments and
update inventory dara
• Libraries that use hand held scanners co read optical strips on books
TRADE-OFFS: Although on line input offers many advantages, it does have some disadvanrages.
For example, unless source data automation is used, manual data entry
is slower and more expensive than batch input because it is performed at the rime the
transaction occur5 and often done when computer demand is at its highest.
The decision to use batch or online input depends on business requirements. For
example, hotel reservations must be entered and processed immediately, bur hotels
can enter their monthly performance figures in a batch. ln fact, some input occurs
naturally in batches. A cable TV provider, for example, receives customer paymenrs an
batches when the mail arrives.
8.8 SECURITY AND CONTROL Issues
A company must do everything in its power to protect its data. This includes not only
the firm's own information bur that of its customers, en1ployees, and suppliers. Most
assers have a value, bu r corporate data is priceless because without safe, secure, and
accurate data, a company cannot function.
The following sections discuss output and input data security and control.
8.8.1 Output Security and Control
Ourpur must be accurate, complete, current, and secure. Companies use various
output control methods to main rain output integrity and secu rity. For example, every
reporr ~hou ld include an appropriate title, report number or code, printing date, and
time period covered. Reporrs should have pages that are numbered consecutively,
identified <lS Page 1111 of nn, <lnd the end of the report should be labeled cle<lrly.
Control totals and record counrs should be reconciled against input totals and
counts. Reports should be selected at random for a thorough check of correctness <lnd
completeness. All processing errors or interruptions must be logged so they can be
analyzed.
Output ~ecuri t y protects privacy rights and shields the organization's proprietary
data from theft or unauthori.ted access. To ensure output securirr, several important
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 8
User Interface Design
256 8.8 Security and Control Issues
tasks must be performed. First, limit the number of printed copies and use a tracking
procedure to account for each copy. \'(Then printed ourput is distributed from a central
location, !>pecific procedures should be used ro ensure th3t the output is delivered to
3Uthonzed recipienrs only. Thar is especially true when reports contam sensirive inform3non,
such 3S payroll data. All sensitive reporrs should be stored in secure 3re3s. All
p3ges of confidential reports should be labeled appropriately.
As shown 111 Figure 8-17, it is important to shred sensitive reporcs, our-of-date
reporrs, and output from aborted print runs. Blank check forms must be stored in a
secure loc3tion and be inventoried regularly to verify that no forms 3re missing. If signarure
scamps 3re used, they must be stored in a secure locanon away from the forms
storage location.
FIGURE 8-17 To maintain output security.it is important to shred sensitive
material.
In most organizations, the IT department is responsible for coordinating output
control and security measures. Systems analyses must be concerned with security
issues as they design, implement, and support information systems. \Xlhenever pos·
sible, security should be designed into the system by using passwords, shielding sensitive
data, and controlling user access. Physical security always will be necess3ry,
especially in the case of printed output that is tangible and can be viewed and h3n·
died easily.
Enterprise-wide daca access creates a whole new ser of security and control issues.
Many firms have responded to those concerns by installing disk less workstations. A
di ~ kl css workstation is a network terminal that supports 3 full -featured user interface
but limits the printing or copying of data, except to certain network resources rhar
can be monitored and controlled. This concept would typically preclude rhe use of
portable storage devices, such as USB thumb drives.
8.8.2 Input Security and Control
Input control includes the necessary measures to ensure that input data is correct,
complete, and secure. lnput control must be the focus during every phase of input
design, starting with source documents that promote data accuracy and quality. \Vhen
a batch input method is used, the computer can produce an input log file thar identi·
fies and documents the data entered.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.9 Emerging Trends
257
Every piece of informarion should be craceabJe back ro the inpur dara rhar
produced ir. Thar means rhe analysr muse provide an audir rrail rhat records rhc
source of each dara ircm and when ir enrered the sysrem. In addirion ro recording
the original source, an audir rrail must show how and when data 1s accessed or
changed, and by whom. All those actions must be logged in an audic rrail file and
monirored carefull}.
A company must have procedures for handling source documents co ensure char
data is nor lost before ic cnrers che system. All source documents char origmare from
outside rhe organi1.acion should be logged when they are received. Whenever source
documents pass between dcparnnenrs, che transfer should be recorded.
Data securit)' policies and procedures protect dara from loss or damage, which is a
viral goal in every organization. If the safeguards are nor 100% effective, dara recovery
utilities should be able co restore lost or damaged data. Once data is entered, che
company should srore source documents in a safe locacion for some specified length
of time. The company should have a records rerention policy that meets all legal
requirements and business needs.
Audit trail files and reports should be stored and saved. Then, if a data file is
damaged, the information can be used to reconstruct the lost data. Dara security
also involves protecting data from unauthorized access. System sign-on procedures
should prevent unauchorized individuals from enttering rhe sysrem, and users should
change their passwords regularly. Having several levels of access also is advisable. For
example, a data enrry person mighr be allowed co view a credit Limit but nor change
ic. Sensitive data can be encrypted, or coded, in a process called encryption, so only
users wich decoding software can read ir.
8. 9 EMERGING TRENDS
The user interface conrinues ro evolve. The widespread use of mobile devices such
as the iPad and other tablcrs, coupled with the ubiquiry of the iPhone and ocher
smarcphones, has greacly influenced user inrerface design. lndeed, key user experience
lessons from chese devices have been rcflecced back into the user interface for mainscream
operaring sy~rems such as Mac OS X and Microsoft Windows.
le is d1fficulc ro predict the future, but the introducrion of che Apple \Xlacch, G<x>glc's
Wear OS, Ficbit's fimess crackers, and other wearable devices promises ro furrher
shake up user incerface design principles. Advanced technology will supporr rhe evolurion,
but rhe real driving force will be user empowerment, which re~u lts in customer
:.atisfacrion, increased producrivity, and bottom-Line savings.
8.9. 1 Modular D esign
ln a modular d c ~ign , individual componenrs, called modules, are created rhat connccr
to a higher-level program or process. In a scrucrured design, each module represents a
specific process, which is shown on a DFD and documented in a process description.
If an object-oriented design is being used, as described in Chapter 6, code modules
rcpresenc classes. Modular design is explained in more detail in Cha peer I I, which
describes systems implemenrarion.
Modules should be designed ro perform a single funcrion. Indcpendenc modules
provide grearcr Aexihiliry because they can be developed and rested individually and
rhen combined or reused larer in che developmem: process. ~1odular design is especially
imporranr in designing large-scale systems because separare reams of analysrs
and programmer can work on different areas and then integrate the resulrs.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 8
User Interface Design
258 8.9 Emerging Trends
8.9.2 Responsive Web Design
Today's conccnc is viewed by users on mulriple devices: compucers, cablcts, and smartphones.
Each device has irs own form factors char can limir rhe user experience. For
example, rhc physical dimensions of a smartphone preclude rhe use of wide mcnusw1thour
forcing rhe user to scroll horizontally coo much.
Responsive web design is an emerging trend chat renders web concent properly,
independencly of rhe device in use. This means the developer only has to focus on
essential user incerfoce issues; how che GUI arrifoccs are presented on che device
is handled automatically by the underling framework. Responsive web design
addre ses various nonfunctional anribuces, including usability, performance, and
maintainability.
Responsive web design relies on a number of underlying technologies, including
CSS3, flexible images, and fluid grids. Page clements are expressed in relative ccrms
(e.g., perccnragcs), racher than absolute cerms (e.g., pixels). This allows rhe conrenr to
"flow " properly in the user interface, irrespective of the display device.
8.9.3 Prototyping
Prototyping produces an early, rapid ly conscructed working version o f the proposed
information system, called a procotype. Prototyping, which involves a reperirive
sequence of analysis, design, modeling, and testing, is a common technique rhac can
be used co design anything from a new home co a computer network. For example,
engineers use a prororype co evaluate an aircraft design before production begins, as
shown in rhe wind runnel testing in Figure 8- 18.
FIGURE 8-18 Wind tunnel testing is a typical example of prototyping.
t-o:J·1.esy off'lAS.A
User inpur and feedback is essenrial ar every srage of the systems devclopmcnr
process. Prororyping allows users co examine a model rhar accurately represenrs
sysrem ourpurs, inpurs, inrerfaces, and processes. Users can " tesr-drivc" rhc model in
a risk-free environmenr and eirher approve ir or request changes. In some siruarions,
the protorype evolves inro the final version of rhe information system. In orher
cases, rhc prororype is inrended only ro validate user requirements and is discarded
afterward.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
8.9 Emerging Trends
259
Perhaps the most intense form of prororyping occurs when agile methods are u~cd.
As described in Chapter I, agile methods build a sysrem by creating a series of prototypes
and constanrly adjusting them to user requirements. As the agile process continues,
developers revise, extend, and merge earlier versions into the final product. An
agile approach empha~i1es continuous feedback, and each incremental step •~affected
by what was learned in the prior steps.
Systems analysts generally use two protoryping methods: system protoryping and
design protoryping.
SYSTEM PROTOTYPING: System prototyping produces a full-featured, working
model of the information system. A system prototype that meets all requirements is
ready for implementation, as shown in Figure 8-19. Because the model is "on track"
for implementation, it is especially important to obtain user feedback and to be sure
that the prototype meets all requirements of users and management.
Planning
/
Implement
the system
FIG URE 8- 19 The end product of system prototyping is a working model of
the information system. ready for proper implementation.
DESIGN PROTOTYPING: Systems analyses also use protoryping to verif)' user
requirements, after which the procorype is discarded and implementation continues.
The approach is called design protot)'ping, or throwaway prototyping. ln this case,
the prororyping objectives arc more limited but no less important. The end product
of design procoryping is a user-approved model that documents and benchmarks the
features of the finished system. Design prototyping makes it possible ro capture user
input and approval while continuing co develop the system within che framework of
the SDLC. Systems analyses typically use design prototyping as they construct outputs,
inputs, and user interfaces.
TRADE-OFFS: Prororyping offers many benefits, including rhe following:
• Users and systems developers can avoid misunderstandings.
• System developers can create accurate specifications for the finished system
ba11ed on the prototype.
• ,\ lanagers can evaluate a working model more eHectivelr than a paper
specification.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 8 User Interface Design
260 8.10 Summary
• S>•Stcms analysts can use a prototype ro develop resring and training procedures
before rhe finished sysrem is available.
• Prototyping reduces the risk and potential financial exposure char occur when
a finished system fails co support business needs.
Alrhough most systems analysts believe rhar rhe advantages of prororypmg far outweigh
any disadvantages, the following porenrial problems should be considered:
• The rapid pace of development can creare quality problems, which are nor discovered
until the finished system is operarionaJ.
• Other sysrem requiremenrs, such as reliability and mamtainabiliry, cannot be
rested adequately using a prororype.
• In very complex systems, the prototype can become unwieldy and difficult ro
manage.
• A client or user might wanr to adopt the prototype with few to no changes,
mistakenly thinking that the prororype will meet their needs though it may
need further customization, leading to increased maintenance costs later in che
SDLC.
One of the systems analysts on the project team thought that he dad a good job of designing
the company's tech support webpage, but his supervisor isn't so sure. His supervisor is
concerned that the design is very similar to a page used by the company's major competitor,
and she asked him whether he had used any HTML code from that site in his design.
Although the analyst didn't copy any of the code. he did examine it in his web browser to
see how they handled some design issues.
The supervisor asked the analyst to investigate webpage copyright issues and report
back to her. In his research, the analyst learned that outright copying would be a copyright
violation, but merely viewing other sites to get design ideas would be permissible. What
is not so clear is the gray area in the middle. The analyst asked you, as a friend, for your
opinion on this question: Even if no acrual copying is involved, are there ethical constraints
on how far you should go in using the creative work of others! How would you answer!
8. I 0 SUMMARY
The chaprer began with a discussion of user inrerface design and HCI concepts. A
GUI uses visu::tl objects and techniques thar allow users to communicate effecrively
with the system. User-centered design principles include understanding rhe business,
maximizing graphic effectiveness, thinking like a user, using models and prororypes,
focusing on usabiliry, inviting feedback, and documenting everything.
When designing rhe user inrerface, it should be transparent; create an inrerface
that is easy to learn and use; enhance user productivity; make ir easy ro obtain help or
correct errors; minimize inpur dara problems; provide feedback; create an attractive
layout and design; and use famjliar terms and images. Control features, such as menu
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... . ... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
8.10 Summary
26 1
bars, toolbars, drop-down lisr boxes, dialog boxes, toggle burrons, list boxes, oprion
burrons, check boxes, and command burrons can also be added. Controls are placed
on a main swirchhoard, which is like a graphical version of a main menu.
The discussion of input design began with a description of source documents and
the various 1.ones in a document, including the heading zone, the control zone, rhe
instruction zone, the body 1one, the totals zone, and the authorization 1one. The discussion
of darn enrry screen design explained the use of input masks and vahdauon
rules to reduce data errors. Input masks are like templates rhar only permit certain
combinations of characters, and data validation rules can provide checks ro ensure
that inappropriate data is prevented from enreri11g the system. These checks can
include dara sequence, existence, range and limit, reasonableness, and validity, among
others.
The chapter described various rypes of printed reports, including detail, exception,
and summary reports. The features and sections of reports, including control fields,
control breaks, report headers and footers, page headers and footers, and group headers
and footers were explained. Other types of output, such as web-based information
delivery, audio output, instant messagi.ng, podcasts, email, and other specialized forms
of output were also discussed.
Batch and on line input methods were also described, as were input media and procedures,
and input volume. Input methods include data capture and data entry. Dara
capture, which may be automated, involves identifying and recording source dara.
Dara entry involves converting source data into a computer-readable form and entering
it inro rhe system. New technology offers optical and voice recognition systems,
biological feedback devices, morion sensors, and a variery of graphical input devices.
Securiry and conrrol were discussed. Ourpur control includes physical protection
of data and reporrs and control of unauthorized ports or devices that can extract data
from rhc system. Input conrrols include audir trails, encryption, password security,
data security, and rhe creation of access levels ro limit persons authorized to view or
use data.
Finally, che emerging trends of modular design, responsive web design, and prototyping
were discussed.

Chapter 8
User Interface Design
262 Key Terms
Key Te rms
audit cra1I A re.:ord of the ;ource of each daca item and when 11 l!ncercd a >y>tem. In add111on IO recording
the cmgmal 'ource, an audu trail mu_\~ sho\\ how and when tbt.1 '' 3l"<:C\\Cd or changed, and hy
"horn. \II the'>e action> mu>t he logged in an audit trail file and monitored carefullr.
authori1,;uion zone Part of a form that contajns any required \lgnaturc'>.
automated f.ix A system rhar allows a cusromer ro request a fax using cmJil, the company website. or
a telephone. The response is cransmirrcd i:n a matter of seconds back to cbe user"s fax ma,hme. See
fall back.
batch A group of dara, usually mpurted mto an mfoananon system at the same mne.
b.uch uintrol A 1n1al u,ed to verify batch input. Batch control> might check data item\ wch 3'> r..-cord
count~ and numeric field totals. For example, before cnterin11 a hatch of order,, a lt'>tr mi11ht .:.1kulatc
the roral number of order; and rhe <um of all rhc order quantiric~. When the hatch of order< i'>
enrcrcd, rhc order i.ystem al'>o calculates rhe same cwo IOtak If the ;y~tcm meals do not match the
111put torn I,, rhcn a tbt:t entry error has t>ecurred.
batch input A proces' where d:ua enrry is performed on a ~pecified cime ~chcdu lc:, ~uch O'> daily, weekly.
monrhl)', or longer. For example, hatch input occur~ when a payroll dq>arm1c11t collect' mne c.1rd' at
the end of the week and enters the data as a batch.
blog An onlme journJl. The rerm is a conrraction of "web log."
calendar control A calendar control allows che user to select a dJtc that the system will d1spla> and store
JS .1 field value.
character·ha'>cd report J\ report created using a single mono-'>paced characcer ...:c.
chccl. box U.;ed to '>elect one or more choices from a group. A check mark, or an X, repre-cnr- .;elected
option'>.
combuuuon chc:d A t) pe of d.11a \ alidacjon check that LS perfonned oo cwo or more field; to ensure
chJt che) arc con~mcnr or reasonable when considered together. ben though Jll the fields involved m
a combmauon check m1ghc pass rheir individual \alidation checks, the comhmauon of chc field values
might be incontjstent or lillrcasonable.
command button Onscreen button that initiates an action such as prinung a form or re<Juesnng Help.
contc"·'cn,irhc A fearurc that i< sen~itive ro rhe currenr conditions when it i\ imokcd. For example,
conte"t·\en'>!tiq: hdp offer- :i5sisrance for a rask in progress.
control hrcJk A control break u~ua ll y causes specific a•-rion~ to occur, ~ud1 .I'> pnn11n11 >ubtotal> for a
11roup of records.
control break report A detail rcporr that focuses on control breaks.
control field order In a conrrol break reporr, the records are arranged or sorted on the same order as the
control fields.
data security Prorccrion of darn from loss or damage and recovers darn when it is lost or damaged.
dam rypc check A type of darn va lidation check rhat is used ro ensure thar o darn item fir~ the requi red
dJm type. For example, a numeric ticld must have onl) numbers or numeric ~ymbt> I ~. and an alpha·
bc11c field can contain only chc characters A through Z or the character~ a through t..
datJ 'alidJtion rule: A me.::hanism to improve input quality by tesung tbe datJ .ind re1e~11ng .111y entry
that f.111~ to meet specified condmons.
default \aluc A "alue that a system displays auroma11cally.
dc\1gn prototyping Creating a protocypc of user requirements, after whu:h the prororypc 1s d1..cardcd
and 1mplementarion connnues. Also called rhrowawar promryping.
detail report A derail report produces one or more lines of output for each record proccs<ed.
dialo11 bo'< Allows a u~r ro enrcr information about a cask that a system wtll perform.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase l
Systems Design
Key Terms
263
d1\klc\\ \\Orl.\lauon A nc1work 1crminal 1ha1 <upportS a full-foarurcd user mtcrfaL"C hu1 limit\ 1he prinl·
ing or cop)·mg of data, c"<ct'pt to certain network r~urccs chac can be monitored and conrrolled
more ea;il).
electronic hcahh record EHR An electronic record of a patienc's bealch information gencrJtcd as the
paacm encounters various health-care prondcrs and shared among muluplc facwncs Jnd a@.enc1~ .
cncr)pllon A proce;; where data 1s coded (converted into unreadable characters) ;o that only tho;e wuh
cbe required au1hor1z.tnon can access the data (usuallr via decoding software).
cucpllon rcpor1 A d1xumcn1 di,playing only 1ho"' rc.:ords chat meet a \p«1lic cunditmn or L·ondit11111\.
Fxccption rcpom arc u\eful when the u<;er wane• information only on records that might require
aL"tllln hut doc.; nor need m know rhe derail~.
exi\tcnce check A cype of d:im validation check chat is used for mandmory darn item\. For cx:imple, if
an employc:c record rc4uirc' a Social Securiry number, an exisrence check would no1 allow the ui.er to
,.we 1hc record u111il he or \he enter., a .,uitable value in the SSN field.
faxback See .1urom.11cd fox .
Conn fillins A very effcc1ivc method of online data enrry where a blank form thJt duplicates or resem·
hies the source document i~ completed on the screen. The user enters rhe da!l1 and rhen movcs to the
11ext field.
form layoul The phr•ical appearance and placemem of data on a form. Form layout make~ the form
ca') m complete and provide' enough ~pace, horh vertically and horizomally, for U\t!f\ m enter the
data.
garb;age m, g.irb.li;c ou1 (GIGO! The concept that rhe quality of rhe ourpur" only"' good'" rhe qual1ry
of the in put.
graphical user interface (GUI) Inc usc of graphical objects and techniques allowing user~ 10 commum·
cate with a s~·srem. A well-designed GUI can help users learn a new S)Stem rapidl) and work with rhe
sys1cm effecuvcl).
bash totals !\ot meaningful numbers 1hentieh es but are u.>eful for comparison purposes. Also knO\\ n as
batch control 101.ils.
human-cnmpu1er 1n1craL"linn (I ICH A d~cnpnon of the n:lanon~hip between computer~ and the people
who u>e them to perform hu~inc<i~ · rclarcd ra5ks. HO concepts appl)' to cvcry-rhing from a PC' de~krop
to the marn menu for a glohal network.
inpul comrol The ntxc''"'1 me:hure• ro ensure rhar input d ata is correct, complete, and \ecurc. 1\ '>Y•·
tern~ anal)M mu\I focu'> on rnput conrrol during every phase of input design, srnmng wi1h \ourcc doc·
umcms 1h:t1 promote d:ua a''uraq and quality.
mput mas!. femplare or pattern char makes 1r easier for users to enter data. Often used 111 automated
forms to guide an unfamiliar user.
limi1 check Occurs when a validmion check involl'~ a minimum or a maximum value, hut nor both.
Checking 1hat a payment amount is greater than zero, bur nor specifying a maximum value. i; an
example of n lunic check.
1;,, box An output mcchani>m that di>plays a liM of choices rhar the user can >elcLl.
menu b.1r A >Ct of user->clcLtable •ofrware applicariun uptiom, usually locarcu acro~s 1hc rop of Lhc
>erccn.
mocl.·up When dc;,igmng a report, a 'ample report is prepared, which 1s a mcxk·up, or pro101ypc, for
users 10re\1cw. rhc s.1mple should include ryp1cal field values and com.tin enough records to ~how all
the de~ign fcamrc\.
modular dc,1gn A deMgn that can be broken down into logical block» Abo known a; partirionmg, or
top-down deMgn.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Chapter 8
User Interface Design
264 Key Terms
module Rel:ued program code or:ganaed into small uruts that Jn~ eaS) to undent.rnd and m.umam. A
complex program could have hundreds or even chousands of modules.
n~tural l~n11ua11c A \<Jftwarc feature that allows u~~ to l)'J>C command, or re<1u"'t' m normal En11l"h
(or other lan1,'llai;c) phra'>CS.
onl1nc dat;i cnin A data enrry method used for most hu~ine'~ activ11)'. The onlinc mcrhod offer. major
advanca~es. mduding che immediate \•alidation and arnilability of data.
opuon button Radio bunons that represenc groups of options. The user can select only one option at a
ume; a ~ele-:ted op11011 contains a black dot. Se!' also radio button.
outpu1 control Methods to mrumam ourpur mregrity and secunry. l'or cx.1mple, C\ery report should
include an appropriate title, repon number or code. primmg dare, and tune period covered. Reporn
should ha\'C pages that arc numbered consecutively, 1dcnn6cd as 1'.1gc X'X of xx, .ind the end of rhc
rcpor1 should be labeled clearly.
output i.ccuri1y Ourpur security prorects privacy rights and bhield~ the nri;ani1ario11·~ propricrnry darn
from 1hch or unnuchorizcd accc,~s.
pa11c footer Appears at rhc hotcom of rhe page and is used to display the name of chc report and 1hc
pa11c numhcr.
pjgc header Appears .u the top of the page and mdudes the coh1lllll he.1dmgs tl1Jt 1denrif) rhe dara.
podcast A wcb-b.1scd broadcast that allows J user ro receive .1udio or 111ulumcd1,1 file5 using music
pla)Cr sofrware such as iTunes, and listen to them on a PC or download them ro a portable MP3
pla}er or smart phone.
protol)pt An e.~rl)', rapidly con<rrucced working ver;ion of rhe propo-.cd mformarion ~y<tcm.
promr) pini; The merhod br which a prorocype is developed. Jc inH>lve- a repc:riri\c ~equcnt:c of an:ilr~i<,
de\l)ln, modclm11, and te;ung. It 1~ a common technique chat can be u-.cd m de\1i;n an) th11111 from a
new home ma computer nerwork.
radio button 8unons rhar represent groups of options. The user can select onl) one opuon ;u .1 ume; a
selected opuon contains a black dor. See also option button.
radio frcqucn() idenrific:iuon RFID) tag An input de,ice used in source data au1oma11on.
range check A type of dara ,·alidation check chac tests data icems ro "enfy chat they fall l'Crwcen a specified
minimum and maximum \'alue. The daily hours worked b) an employee, for e\amplc, mu<c fall
\\ 11h111 1hc rani;e of 0 IO 24.
rca,onahlcnev, check A t) pc ot data validation check tha1 idcmific> v;ilue> 1ha1 arc <1uc,tionablc but not
necc<sanly wrong. For c"Xamplc, input payment values of $0.05 and $5,000,000.00 borh pass a sim·
pie limit check for a payment value greater than 1ero, and yet both value' could he error,,
record~ retention policy Rules designed co meet all legal requirements and busm~s needs for keeping records.
rcpnr1 fonrer Appears at the end of the report, can include grand ror.1ls for numeric fields Jnd ocher endof-rcporr
information.
report header Appears oc the beginning of a report and identifies 1hc report a\ well a• the report title,
d.1rt, and other nc,c.sar)' information.
,croll bar In ll>Cr imcrface design, a scroll b:tr allows the user IO movt' through 1hc av11i lablc choice; for
Jn input field.
(Cqucm:c chccl A t) pe of daia validation check rha1 is used when the data musl be Ill ~omc
predetermined ,equence. If rhc user must enrcr work orders in numerical sequence, for example,
then Jn out-of-,equence order number indicate. an error. lf the user must corer rr:tnSJuions
1.hronolog1c.ill). then a rra~acnon with an out-of-s'<!ueu'c dare 111tLcatts .m error.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Phase l
Systems Design
Key Terms
265
soun:e d;ua auromation A popular onhne inpur method char combines oaline data enrrv and auromarcd
data upturc u<,ing input de"'""' 5Ulh ~ magnenc data scrip> or .wipe ..:aaacri..
source documcm A form used to request and coUect input data, trigger or authorue .in mput .llllon • .inJ
provide a record of the original rransacnoa. During che input design stage. you deYelop source documents
that arc caS} ro complcrc and inexpensive.
noryhoard Skt>tchc~ u~ during promtypmg ro ~how rhe general screen layour and d~1gn.
'ummal) rcpon A reporr 11-.cd h)' indi,idual' at higher lcvch in the organi7ation that indudc' le'~ dct.1il
than report• u-.cd b) lower· le,·el employees.
"'itchboard The U\C of 'ommand burrnns in a u-;er inrerfoce to enable users ro navigate a 'Y'tem and
-eled from 11rou1h of related ta\k-.
sy~tcm prototyping l'roducmg a full-featured, working model of the inform.ttiou sy;tem being
developed.
throwaway protot)pin11 See dc~ign prorocypin11.
tu!(!\lc hutton A GUl clcmcnr used tn rcprc'Cnt on or nff statu•. Clicking the COffillc button >Witchc' tu
the other >rntu•.
wnlhar A Gln clement that contain• icom or button~ that represent •hnrtcurs for executing common
command~.
t0tals zone If ,1 form h.1s dat.1 totals, they will appear in this secrion of rhe form.
1tan}pJrent intcrfocc A user mterfoce thar users don't reaUy notice-a user-friendly interface that does
not dmr.ict rhr usrr .ind c.alls no arrencion to uself.
turnaround dt><.-umcnt Output doc.:umcnt that 1;, later entered back into the ~amc or another 1nforma·
tion 'Y'tcm. A telephone or utility hill, for example, might be a turnaround document printed by the
company·, hilhng ,Y'tcm. When the bill 1' returned with pa)ment, it i' <canned into the company''
account\ rcceivahlc '>)"'>tem m record the payment accuraTely.
u.\ahilu> In u\cr 1ntcrfo1.:c de-1i11n. include< u...:r satisfaction, support for busin"'' funcuon,, and '>'tern
etie~tivenC\\.
u~abilit~ mcuic~ D.tta that u11erface designers can obratn by usmg sofrware chat C.lll re.:ord and measure
user mteracuo11> with the s~srem.
"'er-centered A term that 1nd1carcs the pnmaf)' focus 1s upon rhe user. ln a user-centered system, the d1'·
fincrion blurs between input, output, and the interface irselI.
u'cr interface (Ul) The mechanism rhrough which the user interact' with the system. The interface can
be graphical, textual, aural, or a combinarion of differenr mode~ of interaction.
\•alidity d1e1.:k A rypc ol darn "alidation check that is used for dara icem' rhat mu~t have certain values.
f'or example, if an 111\'cntory ;,y,tcm has 20 ,·alid llcm da~~c;,, thcn any input nem that doc' no1
mJtch one of the va lid dass<'s will foi l the check.
wcbc.1st A onc·WJ) tr.111sm1s~ion of information or training materi.1ls, such as a Wcbinar session, .ivailablc
on demand or for a specific period co online participants.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 8
User Interface Design
266 Exercises
Exercises
Questions
I. Explain Apple's view of user imerfoce design, especially for apps.
2. What is l-ICI?
3. \Xfhy 1s a transparent interface desirable?
4. What are the SC\'en habits of successful interface designers?
5. How would you rank the I 0 guidelines for user interface design in order of importance? Explain your
answer.
6. What are the main principles of source document design?
7. What is che difference berween a derail report, a summary report, and an exception report?
8. How has input technology changed in recent years?
9. What is output security?
10. What are three emerging trends in user interface design?
Discussion Topics
I . Some sy~tem~ analysts argue, "Give users what they ask for. If they want lot~ of report& and reams
of data, then chat is what you should provide. Otherwise, they will feel that you are crying co cell
them how to do their job~." Others say, "Systems analysts should let users know what information
can be obtained from the system. If you Listen to users, you'll never get anywhere because rhey really
don't know wh ::u they want and don't understand information systems." What do }'OU think of these
arguments?
2. Some systems analysts maintain chat source documents are unnecessary. They say that all input can be
entered directly into the system, without wasting rime in an intermediate step. Do you agree? Can you
think of an)' situations where source documents are essential?
3. Suppose your network support company employs 75 technicians who travel constancl) and work ar
customer sires. Your task is co design an informarion system chat provides techmcal data and informanon
to the field team. \Vhat rrpes of output aod mformarion delivery would you suggest for the
system?
4. A user interface can be quite restrictive. For example, rhe interface design might nor allow a user to
exit co a Window!t desktop or co log on co rhe Internee. Should a user interface include such restrictions?
Why or why nor?
5. How is che increased use of smarrphones and tablets, with their smaller screen site, affecting user
inLerface design practices?
Projects
I. Yihit rhc administrative office at your school or a local company. Ask co sec examples of input
screens. Analyze che design and appearance of each screen and try to identify at least one possible
improvement.
2. Search the web co find an especial ly good example of a user interface that includes guidelines in chis
chapter. Document your research and discuss it with your class.
3. Re' iew Seccion 8.2 and the comments abouc EHR usability. Research the currenc status of EHR
usability and de!tcnbe all noteworthy developments.
4. Suggest at lea~r two good examples and rwo bad examples of source document design.
5. Explore the cmergmg area of wearable computing, such as the Apple \Vatch, and comment on the
impact of thehe dences on user interface design.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

Chapter 9
Data Design
Data Design
Chapte r 9 is the second of three chapters in the
systems design phase of the SOLC. During the systems
analysis phase, a logical model of the system was
created. Now, it must be decided how data will be
organized, stored, and managed. These are important
issues that affect data quality and consistency. This
chapter focuses on the data design skills that are
necessary for a systems analyst to construct the physical
model of the information system.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" raises
the important and timely issue of sharing customer data
without their explicit consent.
LEARNING OBJECTIVES
Wl1e11 you finis/J t/Jis c/Japter, you should be
able to:
l. E..xplain basic data design conceprs, including
data srrucrures, DBMSs, and rhe evolution of the
relariot1al databa~e model
2. Explain the mam components of a DB~1S
3. Define the major characrcrisrics of web-based
design
4. Define dara design rerminology
5. Draw enriry-rel::irionship diagram~
6. Apply data normalization
7. Utilize codes to simplify ourpur, input, ;:ind dara
formats
8. Explain dara storage roots and techniques,
including logical versus physical srorage
9. Explain data coding
CONTENTS
9. 1 Dara Design Conceprs
9.2 DBMS Components
9.3 \'<'eh-Based Design
9.4 Data Design Terms
9.5 E.ntiry-Relarionship Dtagrams
Case in Point 9.1: Top Text Publishing
9.6 Dara 'ormalization
Case in Point 9 .2: CyberTo)'S
9.7 Codes
Case in Point 9.3: Madera Tools
9.8 Dara Storage and Access
9.9 Dara Control
A Question of Ethics
9. 1 O Summary
Key Terms
Exercises
I 0. Explain darn control mea~urcs
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
9.1 Data Design Concepts
269
9.1 DATA DESIGN CONCEPTS
Systems analysts must understand basic data design concepts, including data structures
and the evolution of the relational database model.
9. 1. I Data Structures
A data \trucrure is a framework for organizing, storing, and managing data. Dara
structure'> consist of files or rabies char inreracr in various ways. Each file or rable
contains dara about people, places, things, or events. For example, one file or rable
might conrain darn about customers, and other files or cables might store data about
products, orders, suppliers, or employees.
Many older legacy systems urilized file processjng because it worked well with
mainframe hardware and batch input. Some companies still use this merhod to handle
large volumes of srructured data on a regular basis because can be cost-effective in
certain situations. For example, consider a credit card company that posts thous::inds
of daily transactions from a TRANSACTIONS fille to account b::i lances stored in ::i
CUSTOMERS file, as shown in Figure 9-1. For that relatively simple process, file
processing might be an option.
r;w ____ __.
CUSTOMERS
.. ~lliiM
~ 53914
U ·ll-2019 86.S2
Transaction ' Cuatomff O.te I Code lunovnt
flumber , Number
109823497 53914
2100485/6 53914
994184424 X9810
11-03 2019 °'4<g!!
11-04 2019 Re1 .. n
11 04-2019 Owlrgr
no.so
FIGURE 9-1 A credit card company that posts thousands of daily transactions might consider a file processing
option.
23.98
62.67
Over time, the modern relational darabase became a standard model for systems
developers. The following example of an auto service shop wi ll compare the rwo
concepts.
9. 1.2 Mario and Danica: A Data Design Example
Figure 9-2 shows an auto shop mechanic at work. Imagine two shops that arc very
similar bur use two different informarion system .designs. Let's call them Mario's Auto
Shop and Danica's Auto Shop. Mario uses two file-oriented S)'Stems, while Danica
uses a database management system.

Chapter 9
Data Design
270 9.1 Data Design Concepts
FIGURE 9-2 In the example shown here. data about the
mechanic, the customer, and the brake job might be stored in a
file-oriented system or In a dacabase system.
MARIO'S AUTO SHOP: Ivlario relics on rwo
file-<>riented systems, sometimes called file processing
systems, to manage his business. The two
sysrems store data in separate files that arc not
connected or linked. Figure 9-3 ~how Mario's
file-<>riented systems:
• The JvlECHA !JC SYSTEM u~es the
MECHANIC file to store dara abour shop
en1ployees
• The JOB SYSTE~I uses the JOB file ro ~tore
data about work performed ar the shop.
Unforrunarely, using rwo separate systems
means that some dara is stored in rwo different
places, and the data might or might not be consistent.
For example, rliree data items (Mechanic
No, Name, :111d Pay Rate) are srorcd in both
files. This redundancy is a major disadvantage
of file-oriented systems because it threatens data quality and inregriry. In face,
Figure 9-3 includes a typical discrepancy: Jim Jones' pay rate is shown as $18.90 in
the IvlECHANIC SYSTEM. file and$ L9.80 in the JOB SYSTEM file.
r
MECHANIC SYSTEM
-No
MECHANIC
-,.,,_
""°"' 5UIUS
......,....,.
~
!:i!MIOW«
Mecham< N, • Name . Pay Rate . HtreOate . ~lotus . ''"•nee .
112 Le•ir, Robert $15.00 4/17/'lfJlO PMt time No
11 Jones, Jim $15.70 1/15/1998 full ti""' y.,.
13 r
JOB SYSTEM
JOB
JobNo
Worl: Coclf
Houn
Dolt
r..wchan.cNo
~
Poy Rlt•
a
~
...
,!:ll IOll
lob No ·· Wot~ Cod. . Hoon . 0.•~ . M«hanlc No . N""'"
. P.y AAte •
TUN £ l .2 U/6/l019 U l Pilf. Rotwr' s1~.oo
i '"'
110
l\IW<CS ... 0 U/)/201q 11 J.,.,...,fm SllSO
1.14 ALIGN .J.O 12/6/lOJS 2J
"""'"'\\.. y
$20.00
'
FIGURE 9-3 Mario's shop uses cwo separate systems, so certain data must be entered twice. This
redundancy Is Inefficient and can produce erron.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
9.1 Data Design Concepts
271
DANICA'S AUTO SHOP: Danica uses a database managemenr system (DBMS)
wirh rwo separate rabies rhar are joined, so they ace like one l:irge cable, :is shown in
Figure 9-4. In Danica\ SHOP OPERATIONS SYSTEi\1, the cables are linked by the
Mech:inic 1 o field, which is called a common field because it connects the rabies.
Note that except for the common field, no ocher d:ica items are duplicated. The
DB~IS design, also called a relarional database or relational model, was introduced
in the 1970s and continues to be the dominant approach for organizing, scoring, and
managing business data.
SHOP
OPERATIONS
SYSTEM
._
...
,.,Mt
..,..,..
......
.......
..... ...,._,..
....... .., • ..... • fYr Miit • ·-Ollllt • .... • ......... • - ... • WQril, c.- • ...,,,, . 0.. •
t:1 ,., .._,. lti C10 '411'7Df0 ,..,._.. No tt1 0.N ) ' •l'IJnOpt
ti .......... l lSl'CI tJt:'Jtl'Jlllf ...... V• 1IO (iqN(l.S fl l~n
H .... .-i_ '10111 1 ti-1n:r.-- Y• lM M.-oN :SO IZWl!H9
FIGURE 9.4 Danica's SHOP OPERATIONS SYSTEM uses a databa$e design, which
avoids duplication. The data can be viewed as if it were one large table. regardless of
where che data is physically stored.
t.1ario's file-oriented systems show rwo different pay rares for Jim Jones, most
likely because of a darn enrry error in one of chem . Thar type of error could nor occur
in Danica's relational database, because an employee's
pay rate is srorcd in only one place. However, DBMSs are
nor immune ro dara entry problems, which are discussed
in derail lacer m chis chapter.
9. 1.3 Database Management Systems
A database provides an overall framework rhac avoids
data redundancy and l>Upports a real-time, dynamic environment.
Figure 9-5 shows a company-wide data base
that supports four separate information systems.
A database management system (DBMS) is a collection
of cools, features, and interfaces that enables users
to add, update, man:igc, access, and analyze data. From
a user's point of view, the main advantage of a DBMS is
that it offers timely, inrcracrive, and flexible data access.
Specific DB,VIS advantages include the following:
• Scalability. Scalability means chat a system can be
expanded, modified, or downsized easily co meet
the rapidlr changing needs of a business enterprise.
SALES
DATABASE
FIGURE 9-5 In chis enmple, a sales dacabase an
support four separate business systems.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 9
272
Data Design
9.2 DBMS Components
For example, if a company decides to add data about secondary suppliers of
material it uses, a new table can be added to the relational database and linked
with a common field.
• £co110111y of scale. Database design allows becrer utilization of hardware. If a
company maintains an enterprise-wide database, processing is less expensive
using powerful servers and communication nerworks. The inherent efficiency
of high-volume processing on larger computers is called economy of scale.
• enterprise-wide a{Jplicatio11. A DBMS is typically managed by a person called
a database administrator (OBA). The OBA assesses overall requirements and
maintains the database for the benefit of the entire organization rather than a
single department or user. Database systems can support enterprise-wide applications
more effectively than file processing systems.
• Stronger standards. Effective database administration helps ensure that stan·
<lards for data names, formats, and documentation are followed uniformly
throughout the organization.
• Better security. The OBA can define authorization procedures to ensure char
only legitimate users can access the database ancl can allow differem users ro
have different levels of access. Most DB1v1Ss provide sophistica ted security
support.
• Data i11depe11.de11ce. Systems that interact with a DBMS are relatively independent of
how the physical data is maintained. That design provides the DBA Aexibiliry ro airer
data strucn1res without modifying information systems char use the data.
Alchough che trend is toward enrerprise-wide dacabase design, man)' companies
still use a combination of centralized DBMSs and smaller, department-level dacabasc
systems. This is because most large businesses view data as a company-wide resource
that must be accessible to users throughout the company. Ar the same time, other
factors encourage a decenrraJized design, including network expense; a reluctance to
n1ove away from smaller, more flexible systems; and a realization that enterprise-wide
DBMSs can be higl1ly complex and expensive to
Database
Adm 1 n1s1rators
maintain. The compromise, in many cases, is a
clienr/server design, where processing is shared
among several computers. Client/server systems are
described in detail in Chapter 10. As with many
design decisions, the best solution depends on rhe
organization's needs and particular circumstances.
9.2 DBMS COMPONENTS
Users
RelatedtJ
Information
Systems
FIGURE 9-6 In addition to interfac.es for useN. database
administratoN, and related information systems. a DBMS also has
a data manipulation language. a sc.hema and subschemas, and a
physkal data repository.
A DBMS provides an interface between a database
and users who need to access the data. Although
users are concerned primarily with an easy-to-use
interface and support for their business requirements,
a systems analyst must understand all of the
components of a DBMS. ln addition ro interfaces
for users, DBAs, and related systems, a DBMS also
has a data manipulation language, a schema and
subschemas, and a physical data repository, as
shown in Figure 9-6.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.2 DBM S Components
Phase l
Systems Design
273
9.2.1 Interfaces for Users, Database Administrators, and Related Systems
When user~, DBAs, and related information systems request data and senrices, the DBMS
processes che request, manipulate:. the dara, and provides a response. A data manipulation
language (OMI .) conrrols database operations, including storing, retrieving, updating,
and deleting data. tvlost commercial DB~1Ss, such as Oracle and IBM's 082, use a 0~1L.
Some database products, 'iuch as ~1icrosofc Access, also provide an easy-to-use graphical
environment rhat enables users co control operations with menu-dri\"en commands.
USERS: Users typically work with predefined queries and switchboard commands
but also use query languages to access stored data. A query language allows a user
co specify a task without specifying how the task will be accomplished. Some query
languages use narural language com1nands chat resemble ordjnary English sentences.
\Xlith a query by example (QBE) language, che user provides an example of the data
requested. Many database programs also use Strucrured Query Language (SQL),
·which is a language that allows client workstations to co1nrnurucate with servers and
mainframe computers. Figure 9-7 shows a QBE request for all Lime Squeeze or Blue
Candy 2019 Ford Fusions with a power moonroof. The QBE request generates the
SQL commands shown at the bottom of Figure 9-7.
DATABASE ADMINISTRATORS: A DBA is
responsible for DBMS management and supporr­
OBAs are concerned with dam security and inregriry,
preventing unauthorized access, providjng backup and
recovery, audit trails, maintaining the database, and
supporting user need: •. Mo~r DBMSs provide uriliry
programs ro assist the DBA in creanng and updating
data Mructures, collecting and reporting parrems of
database usage, and detecting and reporting database
irregularities.
~
--·-
--
---
--
.._ ____ ......
- --
• ... -- --
- -- -= ~--
II
• - --•
--
..
--ll
-
-__ " _,..,......,._,.......,.._ ,..
....
__
~-===-=·~· ·-..... ~.....
-.c-..............
_..,.
)
)
QBE
request
SOL
commands
RELATED INFORMATION SYSTEMS: A DBMS
can support several related information systems that
provide input to, and require specific data from, che
DBMS. Unlike a user interface, no human intervention is required for rwo-way
communication between the DBMS and the related systems.
9.2.2 Schema
FIGURE 9-7 Using QBE.a user can display all 2019 Ford
Fusions that have a power moonroof and are either Ume
Squeeze or Blue Candy color.
The complete definition of a database, including descriptions of all fields, tables,
and relationships, is called a schema. One or more subschemas can also be defined.
A subschema is a view of the database used by one or more systems or users. A
subschema defines only chose portions of the database tbar a particular system or user
needs or is allowed ro access. For example, ro protect indjvidual privacy, rhe project
management system should nor be permitted to retrieve employee pay rares. In that
case, che project management system subschema would nor include the pay rare field.
Database designers also use subschemas co restrict the level of access permitted. For
example, specific users, sysrems, or locations mjgfhr be permirred ro create, retrieve,
update, or delete data, depending on rheir needs and the company's security policies.
9.2.3 Physical Data Repository
Chapter 5 discussed a dara dictionary, wruch describes all data elements included
in the logical dei.ign. At this stage of rhe systems development process, the data
_
.........""_......-....... .......... ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~--- - ···---~~ - .,.-"~ ........... --......

Chapter 9
Data Design
274 9.3 Web-Based Design
dictionary is transformed into a physical data repository, which also contains the
schema and subschemas. The physical repository might be centrnli1ed, or it might
be distributed at several locations. In addition, the smred data might be managed by
a single DBMS, or several systems. To resolve potential database connectivity and
access problems, companies use OD BC-compliant software that enables communication
among various systems and DB:VISs. Open database connecti,it) (O OBC) is an
industry-standard protocol that makes it possible for software from different vendors
to interact and exchange dara. ODBC uses SQL statements that the DBMS understands
and can execute, similar ro the ones shown in Figure 9-7. Another common
standard is called java database connecti,;ty (JDBC). JDBC enables J:iv:i :ipplicarions
to exchange data with any database that uses SQL statements and is JD BC-compliant.
Physical design issues are described in Chapter I 0, which discusses system :irchitccture,
and in Chapter 11 , which discusses system implementation and data conversion.
9.3 Wee-BASED DESIGN
Figure 9-8 lists some major characteristics of web-based design. Ln a web-based design,
the Internet serves as the front end, or interface, for the DBMS. internet technology
provides enormous power and flexibility because the related information system is
oot tied to any specific combinarion of hardware and software. Access to the database
requires only a web browser and an Internet connection. \~eb-based ~ystems are popular
because they offer ease of access, cost-effectiveness, and worldwide connecriviry-all of
which are vital to companies that must compete in a global economy.
CHARACTERISTIC
Global access
Ease of use
Multiple platforms
Cost effectiveness
Security issues
Adaptability Issues
EXPLANATION
The Internet enables worldwide access, using existing infrastructure
and standard telecommunications protocols.
Web browsers provide a familiar interface that 1s user-friendly and
easily learned.
Web-based design is not dependent on a specific combination of
hardware or software. All that is required is a browser and an
Internet connection.
Initial investment is relatively low because the Internet serves as the
communication network. Users require only a browser. and webbased
systems do not require powerful workstations. Flexibility is
high because numerous outsourcing options exist for development,
hosting. maintenance. and system support.
Security is a universal issue, but Internet connectivity raises special
concerns. These can be addressed with a combination of good design,
software that can protect the system and detect intrusion, stringent
rules for passwords and user identification, and vigilant users and
managers.
The Internet offers many advantages in terms of access, connectivity.
and flexibility. Migrating a traditional database design to the web,
however, can require design modification, additional software, and
some added expense.
FIGURE 9-8 Web-based design characteristics include global access, ease of use. multiple platforms. cost-effectiveness,
security iuues. and adapability issues. In a web-Wed design. the Internet serves as the front end. or interlace. to die
cbcab;lse management system. Access to die database requires only a web browser and an lnU!met conneeuon.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.4 Data Design Terms
Phase l
Systems Design
275
To access data in a web-based system, the database must be connected to the Internet
or inrranet. The daraba e and the Internet speak rwo different languages, howc\·cr.
Databases are created and managed by using \'arious languages and commands that
ha,·e nothing to do with HT~I L, which is the language of the web. The objecti\e is ro
connect the database to the web and enable data to be viewed and updated.
To bridge the gap, it is necessary to use middleware, which is a software that
integrates different applications and allows them to exchange data. ~liddleware can
interpret client requests in HT~1L form and translate the requescs into commands
that the database can execute. When the database responds to the commands,
m1ddleware translates the results into HT~tl pages that can be displayed by the
user's browser, as shown in Figure 9-9. Nore char the four steps in the process can
take place using the Internee or a company intranet as the communications channel.
Middleware is discussed in more detail in Chapter 10.
lw•­
.......,_,
IOM-
)-­
--·--
4bul0-
FIGURE 9-9 When a client worl<staaon requests a web page ( 1), the web server uses middleware to
generate a data query t0 the database server (2). The database server responds (3). and the mtddleware
translates the retrieved data into an HTML page tN.t can be sent by the web server and displayed by rhe
user's browser (4).
Web-based data must be secure, yet easily accessible co authorized users. To achieve
thjs goal, well-designed systems provide security atr three levels: the database itself, che
web server, and the telecommunication links that connect the components of che system.
Dara security is discu~sed in more derail in Section 9.9 and in Chapter 12.
9.4 DATA DESIGN TERMS
Using the concepts discussed in the previous sections, a systems analyse can select a
design approach and begin co construct the systetn. The first step is to understand
data design terminology.
9.4. 1 Definitions
Data design terms include cnrity, table, file, field, record, tuple, and key field. These
terms arc explained in the following sections.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
276 9.4 Data Design Terms
ENTITY: An entiry is a person, a pl~ce, a thing, or an event for which data is
collected and maintained. For example, an online sales system may include enricies
named CUSTOMER, ORDER, PRODUCT, and SUPPLIER. \'<lhen DFDs were
prepared during the systems analysis phase, various entities and data stores were
identified. Now the relationships among the entities wall be considered.
TABLE OR FILE: Data is organhed into tables or files. A table, or file, contains a set
of related records that store data about a specific entity. Tables and files are shown
as two-dimensional structures tbat consist of vertical columns and horizontal rows.
Each column represents a field, or characteristic of the entity, and each row represents
a record, which is an individual instance, or occurrence of the entity. For example, if
a company has 10,000 customers, the CUSTOMER table will include J0,000 records,
each representing a specific customer.
Although they can have different meanings in a specific context, the rerms table
and file often can be used interchangeably.
FIELD: A fi eld, also called an attribute, is a single characteristic or fact abour
an entity. For example, a CUSTOMER enrity might include th.e Customer ID,
Firsr Name, Last Name, Address, City, Stare, Postal Code, and Email Address.
A common fi eld is an attribute thar appears in mo re than one enrity. Common
fields can be used to link entities in various types of relationships.
RECORD: A record, also called a tu ple (rh)'mes with couple), is a set of related fields
that describes one instance, or occurrence, of an entity, such a~ one customer, one
order, or one product. A record might have one or dozens of Cields, depending on
what information is needed.
9.4.2 Key Fields
During the systems design phase, ke}1 fields are used to organize, access, and maintain
data structures. The four types of keys are primary keys, candidate keys, foreign keys,
and secondary keys.
PRIMARY KEY: A primary key is a field or combinarion of fields that uniquely and
minimally identifies a particular member of an entity. For example, in a customer
rnble, the customer number is a unique primary key because no rwo customers can
have the same customer number. That key also is minimal because ir contains no
information beyond what is needed to identify the customer. In a CUSTOMER table,
a Customer ID might be used as a unique primary key. Customer ID is an example of
a primary key based on a single field!.
A primary key also can be composed of t\VO or more fields. For example, if a
student registers for three courses, his or her student number will nppear in three
records in the registration system. If one of those courses has 20 srudenrs, 20 separate
records will exist for that course number-<>ne record for each student who registered.
In the registration file, neither the student number nor the cou rse ID is unique, so
neither field can be a primary key. To identify a specific student in a specific course,
the primary key must be a combination of student number and course ID. In that
case, the primary key is called a combination key. A combination key also can be
called a composite key, concatenated key, or multivalued key.
Figure 9-10 shows four different tables: STUDENT, ADVISOR, COURSE, and
GRADE. Three of these tables have single-field primary keys. Note thar in the
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
9.4 Data Design Terms
277
GRADE rable, however, the primary key is a combination of rwo fields: STUDENT
NUMBER and COURSE 'UMBER.
STUDENT I STUDENT TOTAl ' GPA I ADVISOR
1'
NUMBER NAME CREDITS NUMBER
1035
3397
407D
Linda Mllrk
SamCerr
Kelly Goldman
14
9
8
3.40
3.75
2.50
49
49
23
i----1 common fields ,_ __.,
23
49
Alice Jones
Carlton Smith
8 230
0 ·331
~====~+======~}k•~~~~---11~~ 1
STUDENT II COURSE I GRADE
NUMBER NUMBER I
COURSE I COURSE I CREDIT
NUMBER DESCRIPTION 1 HOURS
CHM112 General Chemistry I s
CSClSl
ENG101
MKT2U
Computer Science I
EnsfLSh Composition
Macfoeting Management
FIGURE 9- 10 Examples of common fields, primary keys. candidate keys. foreign keys, and seconcbry keys.
3
3
3

Chapter 9
Data Design
278 9.4 Dat a Design Terms
CANDIDATE KEY: Sometimes tbere is a choice of fields or field combinations ro use
as the primary key. Any field that can serve as a primary key is called a candidate kc} .
For example, if every employee has a unique employee number, then it could be used
as a primary key. Note that an employee's Social ecurity number would not be a
good choice for a candidate key: Contrary to popular belief, Social Security numbers
are not unique. Because only one field can be designated as a primary key, the field
that contains the least amount of data and is the easiest to use should be ~elected. Any
field that is not a primary key or a candidate key is called a nonkey field.
The primary keys shown in Figure 9-10 also are candidate keys. Another candidate
key is the COURSE DESCRTPTTO field in the COURSE table. What about the
OFFICE field in the ADVJSOR r.able? lt could not be a candidate key because more
than one advisor might share the same office.
FOREIGN KEY: Recall that a common field exists in more than one table and
can be u~ed to form a relationship, or link, between the tables. For example, in
Figure 9-10, the ADVJSOR NUMBER fie ld appears in both the STUDENT table and
the ADVISOR table and joins the tables together. Note that ADVISOR NUMBER is
a primaqr key in the ADVJSOR table, where it uniquely identifies each advisor, and
is a foreign key in the STUDENT table. A foreign key is a field in one table that must
match a primnry key value in another table in order to establish the relationship
between the two rabies.
Unlike a primary key, a foreign key need not be unique. For example, Carlton
Smith has advi~or number 49. T he value 49 must be a unique vnlue in the ADVISOR
table because it is the primary key, but 49 can appear any number of rime!. in the
STUDENT ca hie, where the advisor number serve5 as a foreign key.
Figure 9-10 also shows how rwo foreign keys can serve as n composite primary
key in another rable. Consider the GRADE table at the bottom of the figure. The two
fields that form the primary key for the GRADE table are both foreign keys: the STU­
DE IT NUMBER field, which must match a student number in the STUDE1'1T cable,
and the COURSE NU.t\IBER field, which must march one of the course IDs in the
COURSE cable.
How can these rwo foreign keys serve as a primary key in the GRADE table? Nore
rhat srudenr numbers and course IDs can appear any number of times in the table, bur
rhe combi11atio11 of a specific student and a specific course occurs onl>• once. For example,
srudent 1035 appears four rimes and course CSC 151 appears rhree rimes-but
there is only one combined instance of student l 035 and course CSC 151. Because the
combinarion of the specific student ( 1035) and the specific course (CSC 151 ) is unique,
it ensures rhat rhe grade (B) will be assigned to the proper student in the proper course.
SECONDARY KEY: A secondary key is a field or combination of fields that can be
used to access or retrieve records. Secondary key values are not unique. For example,
to access records for only those customers in a specific postal code, the postal code
field would be used as a secondary key. Secondary keys also can be used to sort or
display records in a certain order. For example, the GPA field in a STUDENT fi le
could be used ro displny records for all students in grade point order.
The need for a secondary key arises because a table can have only one primary
key. In a CUSTOMER fi le, the CUSTOMER NUMBER is the primary key, ~o it must
be unique. The customer's name might be known, but not the customer's number. For
example, to access a customer named James tvlorgan without knowing hi~ cusromer
number, the table is searched using the CUSTOMER Atvl E field as n secondary key.
The records for all customers named James Morgan are retrieved and then the correcr
record il> selected.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
9.4 Data Design Terms
279
In Figure 9-10, student name and advisor names are idenrified as secondary keys,
but other fields also could be used. For example, to find all students who have a particular
advisor, the ADVISOR NUMBER field in the STUDENT table could be used
as a secondary key.
9.4.3 Referential Integrity
Validity checks can help avoid data input errors. One type of validity check, called
referential incegrity, is a set of rules that avoids daca inconsistency and quality problems.
In a relational database, referential integrity means that a foreign key value cannot be
entered in one table unless It marches an existing primary key in another table. For
example, referential integrity would prevent a customer order from bemg enrered in an
order table unless that customer already exists in the customer table. Without referennal
i111egrity, there might be an order called an orphan, because it had no related customer.
In the example shown in Figure 9-10, referenda! integrity will not allow a user
to enter an advisor number (foreign key value) in the STUDENT table unless a va lid
advisor number (primary key value) already exists in the ADVISOR table.
Referential integrity can also prevent the deletion of a record if the record has a
pri1nary key that marches foreign keys in another table. For example, suppose that an
advisor resigns to :iccept a position at another school. The advisor cannot be deleted
from the ADVISOR table while records in the STUDENT table still refer to that
advisor number. Otherwise, the STUDENT records would be orphans. To avoid the
problem, students must be reassigned ro other advisors by changing the value in the
ADVISOR NUMBER field; then the advisor record can be deleted.
When crearing a relational darabase, referential integrity can be built into rhe
design. Figure 9-11 shows a Microsoft Access screen thar identifies a common field
and allows rhc user ro enforce referential integrity rules.
x
JOB
lOONo
Woft.Codir
MlCHAN:C
-· Patble
Httt O•tt
status
lmutanc:t
Edll Re~11onsh1ps
Houn
°"'' IM<NIN<No
-Ply RM>
1 x
~ !l,datm Table}lue-y:
.., JOB ..,
•]
.., Mechanic No ,..
0~§!..c:r~t'f!_"!L~!!l~ti
CCCildo ~ ll<l&:.d Fields
c..c.do ~ l!da:.d ~ds
......... ""_.. ...
FIGURE 9· I I Microsoft Access allows a user to specify that referential integrity rules will ~
enforced In a relational database design.
.-.. ............... _
.. __ __.... ................... ~~·~---- ·· · ---~~-.,.- "~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 9
Data Design
280 9.5 Entity-Relationship Diagrams
9.5 ENTITY•RELATIONSHIP DIAGRAMS
Recall rhar an entiry is a person, a place, a thing, or an event for which dara is
collected and mainrained. For example, entities might be cuscomers, sales regions,
produces, or orders. An information system muse recognize the relationships among
encities. For example, a CUSTONlER entiry can have several instances of an ORDER
cnriry, and an E~ I PLOYEE enriry can have one instance, or none, of a SPOUSE entity.
An entity-relationship diagram (ERD) is a model char shows the logical rclarionships
and interaction among syscem entities. An ERD provides an overall view of rhe
syscem and a blueprint for creating rhe physical data structures.
A doctor
treats
a patient
DOCTOR
TREATS
9.5. 1 Drawing an ERO
The first step is co list the entities chat were idenrified during rhe systems
analysis phase and ro consider the nacure of the r e larion~hips rhar
link chem. Ar rhis stage, a simplified method can be used ro show rhe
relationships between entities.
Although there are different ways co draw ERDs, a popular merhod
is ro represent entities as rectangles and relationships as diamond
shapes. T he entiry rectangles are labeled with singular nouns, and
the relarionship diamo nds a re labeled with verbs, usually in a cop-tobottom
and left-to-right fashion. For example, in Figure 9- l2, a DOC­
TOR entity treats a PATIENT entiry. Unlike dara flow diagrams, ERDs
depict relationships, not data or information flows.
PATIENT
FIGURE 9-12 In an enuty-relaaonship
diagram, entities are labeled with singular
nouns and relationships are labeled with
verbs. The rebuonship is interpreted as
a Slmple Enghsh sentence
OFFICE
MANAGER
VEHICLE ID
NUMBER
SOCIAL
SECURITY
DEPARTMENT
HEAD
1
1
1
1
HEADS
ASSIGNED
TO
ASSIGNED
TO
CHAIRS
FIGURE 9-13 Examples of one-to-one (1:1) relationships.
9.5.2 Types of Relationships
T hree rypes of relationships can exist between entities: one-co-one,
one-to-many, and many-to-many.
A one-to-one relationship, abbreviated 1: l , exists when exactly
one of the second entity occurs for each instance of rhe first entity.
Figure 9-13 shows examples of several l: l relationships. A number
I is placed alongside each of the two connecting lines ro indicate the
I: I relationship.
1
1
1
1
OFFICE
VEHICLE
PERSON
DEPARTMENT
A one-to-man)' relationship,
abbreviated l :M, exists when one occurrence
of the first entity can relate to many
insrances of the second enriry, bur each
instance of rhe second entity can associate
wirh only one insrance of rhe first enri1y.
For example, rhc relationship herween
DEPARTMENT and EM PLOYEE is
one-to-many: One deparrment can have
many employees, but each employee
works in only one deparcmenr at a time.
Figure 9-14 shows several l:M relationships.
T he line connccring the many
entity is labeled with the Jeerer M, and
the number l labels the other connecting
line. How many is many? The first
I :NI relationship shown in Figure 9-14
shows the entities IN DIVIDUAL and
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
9.5 Entity-Relationship Diagrams
281
AUTOMOBILE. One individual mighr
own five auromobile , or one, or none.
Thus, many can mean any number,
including 1ero.
A many-to-man} relation\hip, abbreviared
M:N, exisrs when one instance of the
first entity can relate ro many instances
of rhe second enriry, and one instance
of the second entit)' can relate to many
instances of the first entity. The relation·
ship between STUDENT and CLASS, for
example, is many-ro-many-one student
can take many classes, and one class can
have many students enrolled. Figure 9-15
shows several M:N entity relationships.
One of the connecting lines is labeled
with the letter M, and the lctrer N labels
the other connection.
DEPARTMENT
INDIVIDUAL
CUSTOMER
FACULTY
ADVISOR
1
EMPLOYS
OINNS
PLACES
ADVISES
FIGURE 9-14 Examples of one-to-many (l:M) relationships.
EMPLOYEE
M
---' AUTOMOBILE
M
M
ORDER
STUDENT
STUDENT
M
ENROLLS
IN
N
CLASS
REGISTRATION
PASSENGER
M
RESERVES
SEATON
N
FLIGHT
RESERVATION
---------------l assocoahve entity
ORDER
M
LISTS
N
PRODUCT
ORDER LINE
FIGURE 9-15 Examples of many-co-many (M:N) ~lationships. Notice that the event or transaction that llnlu the
cwo entitles Is an associative entry with its own sec -of attributes and characteristics.

Chapter 9
Data Design
282 9.5 Entity-Relationship Diagrams
Note that an M:N relationship is different from 1 :1 or l:M relationships because
the event or transacrion that links the two entities is acrually a third entity, called an
a\sociati ve entity, that has irs own characteristics. In the first example in Figure 9-15,
the ENROLL IN symbol represents a REGISTRATIO encity chat records each
instance of a specific student enrolling in a specific course. Similar!)·, the RF-SERVES
SEAT ON symbol represents a RESERVATION entity that records each instance of a
specific passenger reserving a sear on a specific flight. In che ch1rd example, the LISTS
symbol represents an ORDER LINE entity that records each instance of a specific
product listed in a specific customer order.
Figure 9-16 shows an ERD for a sales system. Note the various entities and relationships
shown in the figure, including the associative entity named ORDER LINE.
The detailed nature of these relationships is called cardinality. An analyst must
understand cardinality in order to create a data design that accurately reflects all
relationships among system entities.
SALES REP
1
SERVES
M
CUSTOMER
PLACES
M
ORDER
WAREHOUSE
M
ORDER LINE
LISTS
STORES
assocla11ve
enllty
/
N
M
PRODUCT
FIGURE 9- 16 An entity-relationship diagram for SALES REP. CUSTOMER. ORDER. PRODUCT. and
WAREHOUSE. Notice that the ORDER and PRODUCT entities arc joined by an associative entity named
ORDER LINE.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.5 Entity-Relationship Diagrams
Phase l
Systems Design
283
9.5.3 Cardina lity
Afcer an analyst draws an initial ERD,
he or she must define the relationships
in more detail hy u~mg a technique
called cardinality. Cardinality describes
the numeric relationship between two
entities and shows how instances of one
entity relate to instances of another entity.
For example, consider the relationship
between two entities: CUSTOMER and
ORDER. One customer can have one
order, many orders, or none, but each
order must have one and only one customer.
An analyst can model this interaction
by adding cardinality notation,
which uses special symbols to represent
the relationship.
A common method of cardinality
notation is called crow'~ foot notation
because of the shapes, which include
circles, bars, and symbols that indicate
various possibilities. A single bar indicates
one, a double bar indicates one and only
one, a circle indicates zero, and a crow's
foot indicates many. Figure 9- 17 shows
various cardinality symbols, their meanings,
and the UML representations of rhe
relationships. As described 111 Chapter 4,
the Unified Modeling Language (UML) is
a widely used method of visualizing and
documenting software ~ystems design.
In Figure 9-18, four examples of cardinality
notation are shown. In the first
example, one and only one CUSTOMER
can place anywhere from zero to many
of the ORDER entity. In the second
example, one and only one ORDER can
include one ITEM ORDERED or many.
In the third example, one and only one
EMPLOYEE can have one SPOUSE
or none. Jn rhe fourth example, one
EMPLOYEE, or many employees, or
none, can be assigned to one PROJECT,
or many projects, or none.
Most CASE products support the
drawing of ERDs from entities in the
data repository. Figure 9- 19 shows part
of a library system ERD drawn using
the Visible Analyst CASE cool. Nore that
crow's foot notation i~ used to show the
nature of the relarionship~. which are
described in both directions.
......... ""_.. ... .-.. ............... _
UML
SYMBOL MEANING REPRESENTATION
I 111
I p1
Oneorm•ny
I po
Zero,
One •nd only one 1
1.:
or one, o.:
or m•ny
I I I 0 Zero, or one 0 .. 1
FIGURE 9- 17 Crow's foot notation Is a common method of indicating
cardinality. The four examples show how various symbols can be used to
describe che relationships between entitles.
EXAMPLES OF CARDINALITY NOTATION
CUSTOMER PLACES ORDER
One and only one CUSTOMER can place anywhere from zero 10 many of !he
ORDER entity.
ORDER
INCLUDES
One and only one ORDER can Include one ITEM ORDERED or many.
ITEM
ORDERED
EMPLOYEE HAS SPOUSE
One and only one EMPLOYEE can have one SPOUSE or NONE.
EMPLOYEE
ASSIGNED
TO
PROJECT
One EMPLOYEE, or many employees, or none, can be asS<gned lo one
PROJECT, or many projec1s. or none.
FIGURE 9- 18 In the first example of cardinality notation.one and only one
CUSTOMER an place anywhere from zero to many of the ORDER entity. In the
second example. one and only one ORDER can include one ITEM ORDERED or
many. In the third example, one ~d only one EMPLOYEE an tl3Ye one SPOUSE
or none. In the fourth eicample.one EMPLOYEE.or many employees.or none.
can be assigned ro one PROJECT. or many projecu. or none.
.. __ __.... ................... ~~·~----···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-.............. . ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..

Chapter 9
Data Design
284
9.6 Data Normalization
l..ibracy System Data Model
USER
BOOK
ADO NEW
BOOK
AUTHOR
FIGURE 9. 19 An ERO for a library synem drawn with V1S1bleAnalyst. Nott<:e that crow·s foot
notation has been used and relationships are descnbed m both d1rect10M.
CASE IN POINT 9.1: TorTE..'\I Pusus11L'\G
Top Text Publishing is a textbook publishing company with a headquarters location. a warehouse,
and three sales offices that each has a sales manager and sales reps. Top Text sells to
schools, colleges, and individual customers. Many authors write more than one book for
Top Text, and more than one author writes some books. Top Text maintains an active list of
more than 100 books, each identified by a universal code called an ISBN. How would you
draw an ERO for the Top Text information system, including cardinality notation!
9.6 DATA NORMALIZATION
Normalization is the process of creating table designs by assign ing specific fields
or attributes to each table in the database. A table design specifics the fields and
identifies the primary key in a particular table or file . Working with a set of initial
table designs, normalization is used to develop an overall database design that is
simple, Acxiblc, and free of data redundancy. Normalization involves applying a
set of ru les chat can help identify and correct inherent problems and complexities
in table designs. The concept of normalization is based on the work of Edgar Codd,
a British computer scientist, who formulated the basic principles of relational
database design.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase l
Systems Design
9.6 Data N ormalizat ion
285
The normalizarion proces~ rypically involves four stages: unnormalized design,
firsr normal form, econd normal form, and rhird normal form. The three normal
forms consrirure a progression in which third normal form represents the best
design. Most business-related databases musr be designed in third normal form. Note
that normal forms beyond 3NF exist, but they rarely are used in business-oriented
systems.
9 .6. 1 Standard Notation Format
Designing rabies is easier if a ~tandard notation format is used to show a table'!> structure,
fields, and primary key. The standard notation format in the following examples
of an ORDl:.R S)'Stem starts with the name of the cable, followed by a parenthetical
expression that contains the field names separated by commas. The primary key
field(s) is/are underlined, like this:
NAME (FIELD 1, FIELD 2, FIELD 3)
During data design, the analyst must be able to recognize a repeating group of
fields. A repeating group is a set of one or more fields that can occur any number of
times in a single record, with each occurrence having different va lues.
A rypical example of a repeating group is shown in Figure 9-20. If a company
used written source documents to record orders, they might look like this. As
Figure 9-20 shows, two orders contain multiple items, which constitute repeating
groups within rhe same order number. Note that in addition to the order number
and date, the records with mulriple products contain repetitions of the product
number, description, number ordered, supplier number, supplier name, and I 0
status. A repeating group can be thought of as a set of child (subsidiary) records
contained within the parent (main) record.
pnmary key
for ORDER
primary key tor
repeating group
OllDER (Unnor11 1H1 1 ii)
these two
orders have
repeating
croups
OllD£R '1 DATt ii 'M>l>UCT I DUCall'TION NUMUll I SU,"1.1£11 SVl'Plllll ISO
NUMllll OllOfll!D NVMllll NAME
86223 9·1l 2019 304 Bluepdget 7 A-602 Ac:me Yes
633 ~v 1 J 9'1S J~ No
684 Sui-sizmo 4 C-876 Ce bot YM
86390 g 14 2019 121! Stttlw• 12 A-602 Ac~ Ye•
304 Bluepdget 3 A-602 Ac:me ve,
86467 9- l S-2019 304 Blue gadget 144 A·602 Ac:me Yes
FIGURE 9·20 In the ORDER table design. cwo orders have repeating groups that contain several products.
ORDER is the primary key for the ORDER cable. and PRODUCT NUMBER serves as a primary key for the
repeating group. Becaun it contains repeating groups. the ORDER table is unnormalized.
A table design rhar contains a repcaring group is called un.normali1ed. The
srandard norarion merhod for representing an unnormalized design is ro enclose
rhe repeating group of fields within a second ser of parentheses. An example of an
unnormali7ed table looks like chis:
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
286 9.6 Data Normalization
AME (FIELD 1, FIELD 2, FIELD 3, (REPEATING FIELD I, REPEATING
FIELD 2))
Now review the unnormalized ORDER table design shown in Figure 9-20.
Following the notation guidelines, rhe design can be described as follows:
ORDER (ORDER, DATE, (PRODUCT ruMBER, DESCRIPTI01 , NUi\1BER
ORDERED, SUPPLIER U.\.lBER, SUPPLIER NA~1E, I 0 ))
The notation indicates char che ORDER table de~ign contain~ eight fields, which
are listed within the outer parencheses. TI1e ORDER field is underlined to show
that it is the primary kc)'· The PRODUCT NUMBER, DESCRIPTION, NU~tBER
ORDERED, SUPPLIER NUMBER, SUPPLIER NAME, and ISO and NUMBER
ORDERED fields arc enclosed within an inner set of parentheses to indicate that
they arc fields within a repeating group. Note that PRODUCT NUMBER also is
underlined because it acts as the prunary key of the repeating group. If a customer
orders three different products in one order, tbcn six fie lds must be repeated for each
product, as shown in Figure 9-20.
9.6.2 First Normal Form
A table is in first normal form (INF) if it does not contain a repeating group. To
convert an unnormalized design to 1 NF, the table's primary key must be expanded to
include the primary key of the repeating group.
For example, in the ORDER cable shown in Figure 9-20, the repeating group
consists of six fields: PRODUCT NUMBER, DESCRlPTJON, NUMBER ORDERED,
SUPPLI ER NU.tvlBER, SUPPLIER NAME, and ISO. Of the three fields, only
PRODUCT NUMBER can be a primary key becau~e it uniquely identifies each
inMance of the repeating group. Tbe DESCRlPTIOr cannot be a primar)• key because
it might or might nor be unique. For example, a company might sell a large number
of parts with the same descriptive name, such as washer, relymg on a coded part
number to identify uniquel)' each washer size.
\Vhen rhe primary key of the ORDER table is expanded to include PRODUCT
NUMBER, the repeating group is elimmated, and the ORDER table is now in lNF,
as shown:
ORDER (ORDER, DATE, PRODUCT NUMBER, DESCRWflO , NUMBER
ORDERED, SUPPLIER NUMBER , SUPPLIER NAME, JSO)
Figure 9-21 shows the ORDER table in lNF. Note that when the repealing group
is eliminated, additional records emerge-one for each combination of a specific
order and a specific product. The result is more records but a greatly simplified
design. In the new version, che repeatmg group for order number 86223 has become
three separate records, and the repeating group for order number 86390 has become
two separate records. Therefore, when a table is in lNF, each record stores data about
a single instance of a specific order and a specific product.
Also note that the !NF design shown in Figure 9-21 has a combination primary
key. The primary key of the lNF design cannot be the ORDER field alone, because
the order number does not uniquely identify eacb product in a multiple-item order.
Similarly, PRODUCT NUMBER cannot be me primary key, because it appears more
than once if several orders include the same product. Because each record must reflect
a specific product in a specific order, both fields are needed, ORDER and PRODUCT
NUtvlBER, to identify a single record uniquely. T herefore, the primary key is the
combi11atio11 of rwo fields: ORDER and PRODUCT NUMBER.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
9.6 Data Normalization
287
ORDER lnlNF
in 1 NF. 1he primary key Is a unique
combmabon of a specific ORDER
and a speofic PRODUCT NUMBER
OllDER I DAT£ PRODUCT : DESCltll'TlON NUMBER I SUPPLIER SUPPLIER ! ISO
NUMBER I I ORDERED ' NUMBER NAME I
86223 9-13·2019 304 Blue gadget 7 A-602 Acme Yes
86223 9·13·2019 633 Assembly 1 J·995 Jones No
86223 9·13 2019 684 Super gmno 4 C·876 ca bot Yes
86390 9·14 2019 128 Steel widget 12 A·602 Acme Yes
86390 9·14·2019 304 Blue gadget 3 A-602 Acme Yes
86467 9·15·2019 304 Blue gadget 144 A·602 Acme Yes
t
t
1n 1NF
• There are no repeating groups
• The pnmary key Is a unique combination of lWo foretgn key values:
ORDER and PRODUCT NUMBER
• All fields depend on lhe pnmary key, bul some fields do not depend on
1he whole key - only part of it
FIGURE 9·2 1 The ORDER cable as 11 appears in I NF.The repeadng groups have been ehminated. Notke that
the repeating group for order 86223 has become three sepante records, and the repeating group for order
86390 has become two sepante records. The I NF primary key is a combination of ORDER and PRODUCT
NUMBER. which uniquely Identifies each record.
9.6.3 Second NormaJ Form
To understand second normal form (2NF), rbe concept of functional dependence must
be understood. For example, Field A is functionally dependent on Field B if the value
of Field A depends on Field B. For example, in Figure 9-21, cbe DATE value is func·
tionally dependent on the ORDER, because for a specific order number, there can be
only one date. ln concrasr, a produce description is not dependent oo the order number.
For a panicular order number, there mighr be several product descriptions--<>ne
for each item ordered.
A cable design is in second normal form (2NF) if iris in lNF and if all fields char
arc not part of chc primary key are functionally dependent on the entire primary key.
lf any field in :i INF cable depends on only one of the fields in a combination primary
key, rhen the table is not in 2 IF.
Note rhar if a l NF design has a primary key rhac consists of only one field, the problem
of partial dependence docs not arise-because rhe entire primary key is a single
field. Therefore, a I NF table with a single-field primary key is automatically in 2 F.
Now reexamine the I NF design for the ORDER table shown in Figure 9-2 1:
ORDER (ORPER, DATE, PRODUCT NUMBER, DESCRIPTION, NUMBER
ORDERED, SUPPLIER NUMBER, SUPPLIER NA.i\llE, ISO)
Recall that the primary key is the combination of the order number and the
product number. The NUMBER ORDERED field depends on the entire primary key
because NUMBER ORDERED refers to a specific product number and a specific
order number. In contrast, the DATE field depends on the order number, which is only
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
288 9.6 Data Normalization
a part of rhe primary key. Similarly, the DESCRIPTION field depends on the product
number, which also is only a part of rhe primary key. Because some fields are nor
dependenr on rhe entire primary key, rhe design is nor in 2NF.
A standard process exists for converting a cable from 1 NF to 2NF. The objective is
to break the original table into two or more new tables and rea'iStgn the fields so that
each nonkey field will depend on rhe enrire primary key in its table. To accomplish
this, the following steps should be followed:
I. Create and name a scparare cable for each field in rhe existing primarr kcr.
For example, in Figure 9-21, rhe ORDER rable's primary key has two fields,
ORDER and PRODUCT NUMBER, so rwo rabies muse be created. The ellipsis
( ... ) indicates thar fields will be assigned lacer. The result is:
ORDER (ORDER, ... )
PRODUCT (PRODUCT NUMBER, ... )
2. Create ::i new table for each possible combination of the origina l primary key
fields. In rhe Figure 9-21 example, a new table would be created wirh a combination
primary key of ORDER and PRODUCT NUMBER. This rable describes
individual lines in an order, so it is named ORDER LINE, as shown:
ORDER LINE (ORDER, PRODUCT NUMBER)
3. Study rhe three rabies and place each field wirh irs appropriate primary key,
which is the m111imal key on which ir fw1crionally depends. When all rhe fields
have been placed, remove any cable that did nor have any additional fields
assigned co it. The remaining tables are the 2NF version of rhe original cable.
The chree rabies can be shown as:
ORDER (ORDER, DATE)
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER
1UMBER, SUPPLIER
1
AME, ISO)
ORDER LINE (ORDER, PRODUCT NUr.1BERl
Figure 9-22 shows rbe 2NF cable designs. By following the seeps, rhe original lNF
table has been converted into three 2NF rabies.
\Vhy is ir important ro move from INF ro 2NF? Four kinds of problems are found
with 1 rF designs char do nor exist in 2NF:
I. Consider rhe work necessary to change a particular product's description. Suppose
500 current orders exist for product number 304. Changing the product
description involves modifying 500 records for product number 304. Updating
all 500 records would be cumbersome and expensive.
2. I NF rabies ca n conrain inconsistent data. Because someone must enter the
product description in each record, nothing prevents producr number 304 from
having different product descriptions in different records. In face, if product
number 304 appears in a large number of order records, some of rhe marching
product descriptions might be inaccurate or improperly spelled. Even the
presence or absence of a hyphen in the orders for all-purpose gadget would
create consistency problems. If a data entry person must enter a term such
as 10 I Queue Controlfer numerous times, ir certainly is possible char some
inconsisrcncy will result.
3. Adding a new product is a problem. Because the primary key muse include an
order number and a produce number, values arc needed for borh fields in order
to add a record. What value should be used for the order number when no
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
9.6 Data N ormalizat ion
Phase l
Systems Design
289
ORDER ln2NF
PRODUCT In 2NF
ORDER
86223
ORDER
DATE
9-13·2019
'1 PRODUCT DESCRIPTION I SUPPLIER SUPPLIER
NUMBER NUMBER NAME
128 ' Steel widget A-602 Acme
ISO
Yes
86390
9·14·2019
304
Blue gadget
A ·602
Acme
Yes
86467
9·1S·2019
j
633
Assembly
1·995
Jones
No
·~
684
Supergjzmo
C·876
Cabot
Yes
I CJWll UNE In JNf
I
OllOEll
PilOOUCT
NUMll£11
86225 504 7
86225 635 1
86225 68' 4
116390 128 .l2
116390 !!04 3
16467 304 144
•
on 2NF the primary key of ORDER LINE IS a
un combonat1on of two foreign keys
FIGURE 9-l l ORDER. PRODUCT. and ORDER LINE tables in 2NF. All fields are functionally dependent on
die pnrmry key
customer has ordered che product? A dummy order number could be used and
later replaced with a real order number when the product is ordered ro solve
the problem, bur char solution also creates difficulties.
4. Deleting a produce is a problem. If all the related records are deleted once an
order is filled and paid for, whar happens if the only record that contains product
number 633 is deleted? The information about that product number and its
description is lost.
I las the 2 f design eliminated all potential problems? To change a product
description, now just one PRODUCT record needs to be changed. Multiple, inconsistent
values for the product description are impossible because the description appears
in only one location. To add a new product, a new PRODUCT record is created,
instead of creating a dummy order record. When the last ORDER LINE record for a
particular product number is removed, that product number and its description is not
lost because the PRODUCT record still exists. The four potential problems are eliminated,
and the three 2NF designs are superior ro both the original unnormalized rable
and the INF design.

~~~~~~~~
Chapter 9
Data Design
290 9.6 Data Normalizat ion
9.6.4 Third Normal Fo rm
A popular ru le of thumb is that a design is in 3NF if every nonkey field depends on
the key, the whole key, and nothing but the key. A 3NF design avoids redundancy
and dara inccgriC) problems chat Still can exisr in 2NF designs.
Continuing the ORDER example, now review che PRODUCT rable design in
Figure 9-23:
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER NUMBER,
SUPPLfER NA tvlE, ISO)
PRODUCT In 2NF
'
NUMBER
.•
•
PRODUCT I DESCRIPTION SUPPLIER : SUPPLIER I ISO
NUMBER ; NAME
•
128 Steel widget A-602 : Acme Yes
•
304 Blue gadget A-602 Acme Yes
633 Assembly J-995 Jones No
.
684 Super gizmo C-876 Cabot Yes
....................
•
PRODUCT In 3NF
'
PRODUCT
NUMBER
128
''' '
DESCRIPTION I SUPPLIER
Steel widget
NUMBER
A-602
'
SUPPLIER In 3NF
SUPPLIER I SUPPLIER
NUMBER NAME
A-602 Acme
1so
Yes
304
Blue gadget
A-602
J-995
Jones
No
633
Assembly
J-995
C876
Cabot
Yes
684
Supergizmo
C-876
FIGURE 9-23 Wilen tile PRODUCT table Is transformed from 2NF to JNF, tile result Is cwo separate
tables: PRODUCT and SUPPLIER. Note mat In JNF, all fields depend on tile key alone.
The PRODUCT cable is in JNF because ic has no repeacing group~ . T he c:i ble also
is in 2NF bcc:iusc the primary key is a single fi eld. But the table still has four potcncial
problems:
I. To change a supplier name, every record in which that name appears must be
changed. With hundreds, or even thousands of records, the process would be
slow, expensive, and subject to input errors.
2. The 2NF design allows a supplier co have a different name or ISO starus in
different records.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
9.6 Data Normalization
29 1
3. Because the supplier name is included in che O RDER cable, a dummy ORDER
record muse be created co add a new supplier who has not yec been received
any orders.
4. If all the orders for a supplier are deleted, that supplier's number and name will
be lost.
Those potential problems are caused because the design is not in 3NF. A cable
design is m third nom1al fonn (3NF) if it is in 2NF and if no nonkey field is dependent
on another nonkey field. Remember that a nonkey field is a field that is not a
candidate ke)' for the primary key.
T he PRODUCT table at the top of Figure 9-23 is not in 3NF because two nonkey
fields, SUPPLI ER NAME and ISO, both depend on another nonkey field, SUPPLIER
NUMBER.
To converr the rable to 3NF, all fields from the 2NF table that depend on another
nonkey field must be removed and placed in a new table that uses the nonkey field as a
primary key. In the PRODUCT example, SUPPLIER NAME and ISO must be removed
and placed into a new table that uses SUPPUER NUMBER as the primary key. As
shown in Figure 9-23, 3NF divides the 2NF version into two scp<uace 3NF tables:
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER NUMBER)
SUPPLI ER (SUPPLIER NUMBER, SUPPLIER NAME, ISO)
CASE IN POINT 9.2:
CYBERTOYS
You handle administrative support for Cyber Toys, a small chain that sells computer hardware and
software and specializes in personal service. The company has four stores located at malls and is
planning more. Each store has a manager. a technician, and between one and four sales reps.
The owners want to create a personnel records database, and they asked you co
review a cable chat they had designed. They suggested fields for score number. location,
score telephone, manager name, and manager home telephone. They also wane fields for
technician name and technician home telephone and fields for up co four sales rep names
and sales rep home telephones.
Draw their suggested design and analyze it using the normali"Zation concepts you
learned in the chapter. What do you think o f their design and why/W hat would you
propose?
9.6.5 Two Re al-World Examples
A good way to learn about normalization is to apply the
rules to a representative situation. This section presents
two different scenarios: first a school and tben a rechnical
service company. If a step-by-step process is followed, data
designs can be created that a re efficient, maincainable, and
error-resistant.
EXAMPLE I : Crossroads College: Consider the familiar
situation in Figure 9-24, which depicts several entities
in the Crossroads College advising system: ADVlSOR,
COURSE, and STUDENT. The relationships among the
three entities are shown in the ERO in Figure 9-25. The
following secnons discuss normali1.arion rules for these
three entities.
FIG URE 9·24 A faculty advisor, who represents an
em1ty, can advise many students, each of whom can
reginer for one or many courses.
"'
r
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 9
Data Design
292 9 .6 Data Normalization
M
ADVISOR ADVISES STUDENT
TAKES
N
COURSE
FIGURE 9°25 An Initial entity-relationship diagram for ADVISOR, STUDENT.
and COURSE.
Before the normaliz~nion process is
scarred, it is noted that the TUDENT
cable contains field5 rhar rclarc ro rhe
ADVISOR and COURSE cnrirics, so a
decision is made co begin with the initial
design for the STUDEl\'T cable, which
is shown m Figure 9-26. Nore rhac the
rable design includes the student number,
student name, coral credits taken, grade
point average (GPA), advisor number,
advisor name, and, for every course the
student has taken, the course number,
course description, number of credits, and
grade received.
The STUDENT table in Figure 9-26 is
m1nor111aljzed because it has a repeating
group. Tbe STUDENT table design can be
written as:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS,
Gl'A, ADVISOR NUMBER, ADVfSOR NAME, OFFICE, (COURSf. .
CREDIT HOURS, GRADE))
~l..!.i.~B~R,
To convert the STUDENT record to I NF, the primary key must be expanded co
include the key of the repeating grou p, producing:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS, CPA,
ADVISOR NUNlBER, ADVISOR NAME, OFFICE, COURSE NUMBER, CREDIT
HOURS, GRADE)
STUDENT(Umom ... lnd)
STUDENT I STUDENT TOTAL I GPA I ADVISOR I ADVISOll I OFRCE '1 COUllSE I CREOIT I GllAOE
NUMIEll NAME CREDITS NUMBEll ! NAME NUMIEll HOURS
101) Unda 41 l.fiO 49 Smith 82.12 CSCUl 4 a
MKT212 3 A
ENGlOl 3 a
CHM112 4 A
BUS105 2 A
3397 Sam 29 ].(]() 49 Smtih 8212 ENGlOl l A
MKT212 ! c
CSCl.Sl 4 a
4070 Kelly 14 2.90 23 Jones C333 CSCUl 4 B
CHMlU 4 c
ENG101 3 c
BUS1~ 2 c
FIGURE 9-26 The STUDENT table is unnormalized because It contains ;a repeating group that represents the
course each student has taken.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.6 Data Normalization
Phase l
Systems Design
293
Figure 9-27 shows the 1 NF version of rhe sample STUDENT data. Do any of the
fields in the l F STUDENT table depend on only a portion of the primary key? The
student name, total credits, GPA, advisor number, and advisor name all relate only
to the student number and have no relationship to che course number. The course
description depend~ on che course number but not on the srudent number. Onl)' che
GRADE field depends on the entire primary key.
STUDENT In lNF
111 1 NF. 1he pnmary key is a unique combmatlO!l ol a
STUDENT NUMBER and a speofic COURSE NUMBER
1035 Un.U 47 3.60 49 Smith 82U
CSCl.51
4 8
1015 unda 47 3.60 49 Smlllt 82U
MICTU2
l
A
1015 Lindi 41 J.60 49 Sm 1th B2U
ENGlOl
l
B
1035 l..nd1 47 3.60 49 Smrth B2U
1015 Un.U 47 3.60 49 Smith Blll
3397 Sam 29 l.00 49 Smith 82U
3397 5.tm 29 l.00 49 Smith 82U
3397 s.tm 29 3.00
"'
Sm 1th
82U
4(J7Q kelty 14 2.90 23 Jones 033
<IOJO Kelly 14 2.90 23 Jones C333
<IO'IO Kelly 14 2.90 23 JO<> es Clll
"°'°
Kelly 14 2.90 23 Jones 013
CHMll2
8US105
ENG101
MICT2U
CSCUl
CSClSl
CHM Ill
ENGIOl
lkJSUIS
4 A
2 A
l A
3 c
4 B
4 8
4 c
3 c
2 c
rn 1NF.
• There are no repeating groups
• The prmary key Is a unique combtnahon of two foretgn key values: STUDENT NUMBER
and COURSE NUMBER
• All field$ depend on Ille primary key. but some fields do not depend on the whole key - only
part of ii
FIGURE 9-27 The student cable in I NF. Notice that the primary key has been expanded to include STUDENT
NUMBER and COURSE NUMBER.
Following the I NF-2 F conversion process described earlier, a new table would
be created for each field and combination of fields in rhe primary key, and rhe other
fields would be placed with their appropriate key. The result is:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS, GPA,
ADVISOR NUMBER, ADVISOR NAME, OFFICE)
COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUMBER, GRADE)
The original I F STUDENT rable has now been convened into three tables, all in
2NF. In each table, every nonkcy field depends on che entire primary key.
Figure 9-28 shows the 2NF STUDENT, COURSE, and GRADE designs and
sample data. Are all three tables STUDENT in 3NF? The COURSE and GRADE
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
294 9.6 Data Normalization
rabies arc in 3NF. STUDENT is not in 3 F, however, because rhe ADVISOR NAME
and OFFICF fields depend on the ADV1SOR 1UN1BER field, which 1s nor part of che
STUDFNT primary key. To convert STUDENT co 3NF, the ADVI OR NAME and
OFFICE fields are removed from che STUDE. T cable and placed into a cable with
ADVISOR NUtvl BER as che primary key.
STUDENT In ZNF
STUDENT I STUDENT I TOTAL I GPA ADVISOR ADVISOR OFFICE
NUMBEll , NAME CREDITS NUMBER NAME
lOlS ' ' llr>da 47
3.60 49 Smith B2U
COURSE In ZNF
'
COUllSE
NUMBER '
CREDIT
I HOURS
BUSlOS 2
3397 Sam
4070 Kelly
l.00 49 Smith B2U
2.90 23 Jones C333
CHM112 4
CSClSl 4
ENG101 3
MKTlU 3
GRADElnZNF
STUDENT
''' +
! COURSE
''' I GRADE
NUMBER I NUMBER
I
1035 CSCJ.51 B
1035 MKT212 A
1n2NF
• All fields now depend
on the whole pnmary
key, but some fields
aleo might depend on
other fields lhat are nol
pan of the pnrnary key
• The pnrnary key of
GRADE ls a unique
combination of two
foreign key values.
STUDENT NUMBER
and COURSE NUMBER
c.........
103S ENGlOl a
lOlS CHMU2 A
lOlS BUSlOS A
3397 ENG101 A
3397 MICT2U c
3397 CSCUl a
4070 CSCUl a
4070 OiMlU c
4070 ENG101 c
4070 BUSlOS c
FIGURE 9-28 The STUDENT, COURSE, and GRADE tables In 2NF. Notice that all fields are functionally
dependent on the entire primary key of their o-espective tables.
Figure 9-29 shows the 3NF versions of rhe sample data for ST UDENT, ADVISOR,
COURSE, and GRADE. The final 3.NF design is:
STUDENT (STUDENT NUMBER, STUDE1''T NAME, TOTAL CREDITS, GPA,
ADV ISOR NUNIBER)
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.6 Data N ormalizat ion
Phase l
Systems Design
295
ADVISOR (ADVISOR NUMBER, ADVISOR A?vlE, OFFICE)
COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUfy1BER, GRADE)
STUDENT In ZNF
STUDENT I STUDENT I TOTAL I GPA I ADVISOR . ADVISOR I OFFICE
NUMBER NAME CREDITS NUMBER : NAME
1035 Linda 47 3.60 49 Smith 8212
3397 Sam 29 3.00 49 Smith 8212
4070 Kelly 14 2.90 23 Jones 033
STUDENT In 3NF
....•...........
'
ADVISOR In 3NF
' ''' '
STUDENT I STUDENT I TOTAL I GPA I ADVISOR
NUMBER NAME CREDITS NUMBER
ADVISOR I ADVISOR I OFFICE
NUMBER
NAME
101) 47 3.60 49 Smith B2U
3397 Sam 3.00 23 Jones C333
4070 14 2.90 23
FIGURE 9-29 STUDENT. ADVISOR. COURSE. and GRADE tables in lNF. When the STUDENT table 1s
transformed from lNF to lNF, che result is tw0 tables: STUDENT and ADVISOR.
Figure 9-30 hows
the complere ERD after
normalizarion. Now rhere
are four entities: STUDENT,
ADVISOR, COURSE,
and GRADE (which is
an associative entiry).
Note how Figure 9-25,
which was drawn before
GRADE was identified as
an entity, shows that che
M:N relationship between
STUDENT and COURSE
has been converted inco
two l:M relationships:
one relationship between
STUDENT and GRADE
and rhe other rclacionship
bcrween COURSE and
GRADE.
......... ""_.. ... .-.. ............... _
ADVISOR
COURSE
1
1
ADVISES
M
STUDENT
1
RECEIVES
M
SHOWS GRADE
l
M
assoc1atm
enllty
FIGURE 9°30 The entity-relationship diagram for STUDENT. ADVISOR. and COURSE after
normaliution. The GRADE entry was idemified during the normaliution process. GRADE is an
associative enoty that links the STUDENT and COURSE tables
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 9
Data Design
296
-
-- - \
I T-
• ·-
• -
- .. .
-- - - .. ..
•
I ·- \
·-- •
.. -
,..._ .. ,. .......
-
~
-- --
-- -
-
--
FIGURE 9-31 A relational database design for a
computer service company uses common fields co link
the cables and form an overall daca structure. Notice the
one-to-many notation symbols and the primary keys.
which are indicated with gold-colored key symbols.
9.6 Data Normalization
To creare 3NF designs, the nanire of first, second, and
rhird normal forms must be understood. A S)' rems analyst
will encounter designs that are much more complex
than the examples in this chapter .
EXAMPLE 2: Magic J\i\aintenance: .Nlagic Maintenance
provides on-sire service for eleccronic equipment. Figure 9-31
shows the overall database design drnr such a finn might use.
The 6guce contains examples of many concepts described
earlier. The database consists of seven separate rabies, all
joined by common 6elds, so they form an integral data
scructure.
Figure 9-32 shows even more derail, including sample
dara, primary keys, and common fields. Nore rhat rhe
eariries include customers, technicians, service calls,
lW IAIOll ('OOf \
lAllOR COD£
HOURLY-RATl •
• A
Sl5.00
• • $<U.OO
• c
~soo
. 0 SMOO
:::J SUMCl 1.-'-OOAll'
CAU· NUM • lABOR-CODE .
'10796 A
"
107'6 c
10791 B
10799 c
10799 D
10801 A
-x
".J <Um>MIR s
C~T-NUM · CUSHAST · ' CVSHlllST • ' CUST·A~S • CUH-Cll'f • CUU·STAT( ·
• 1456 JonH Albo'1 •J0.11.DrM Dtnv..- co
• 1913 vatdt:J 1nn1 1011 H1lllop Rood Chotlott• ~c
• 2S16 Gonutez Jul"I 67UthSttHt Stott It WA
• 6121 a.111 thly 101 MJlti Slfoet s." Jat1nto CA
• ll7<iO SAruono JIC~le
'""•bt"V c ..... ..... .., "'A
· 1848
---
,
.... 3;JlSm!1hUM H\.ldlOn Fl
~ SOMCf <ALl\ x
x
T
lABOR·HOURS .
• 10796 -14)6 U/U/2019 04
LS • 10797 2136 U/13/2019 17
2.0 • 10791 11/13/201' 04
CAU·N~JM . CUST·NUM . OATf . T[(H·NUM .
s.o • 10799 1456 12/l.S/2019 21
LS - 10800 6J21 U/16/201' 21
1.S I • 10801 14)6 1211"'2019 09
2.5
::;J SEIMCC Pi ITTOfTAll \
CAU·lllUM . PART·NUM .
107'6 00-9192
10796 SS·llll
10797 AB-6784
10799 AB-6784
10799 XC-3133
10800 SS-1024
x ;:J TI'OI
x
'
QTY . TECH NUM . T£CH·lAST . TECH FIRST . HlRE·OATI .
4 • 04 Robison GefTY 6/1/'1008
• 0'9 Wh1tf1eld oa .. d 8/1/2001
2
6 ~ 17 Kaplan
1/1/l'J93
~··
1
• 20 Chood L11land U/1/2003
15
• . 21 Johnson Mane 10/1/2014
8
I i1] PARTS \
I
x
'
PART· NUM . PART·DESC . Tcosr. PRICE . QTY-ON·HANO .
• AB-6784 MffiR $98.50 $125.00 33
• 00-9192 DISC SL30 $1.69 220
• SS-1024 COVER $16.00 $19.7'9 71 Primary Keys
• SS-1099 EMBLEM S38.00 S50.00 41
• '
Common fields
• 5$-lUI JUMPER SU.SO SlS.00 3
• XC·llll CABLE <:6 75 <=7.9!1 77
FIGURE 9-ll Sample data, promary keys, and common fields for the database shown in Figure 9-31.
The design is in )NF. Notice that all nonkey fields functionally depend on a primary key alone.
(....,..... J:gl( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
9.7 Codes
29 7
and parts. Orher tahles srore dara abour labor and pans char are used on specific
service calls. Also nore that all rabies use a single field as a primary key, except the
SERVICE-L.ABOR-DFTAIL and SERVICE-PARTS-DETAIL rabies, where the primary
key requires a combinarion of rwo fields to uniquely identify each record.
9.7 CODES
A code is a ser of letters or numbers thar represents a data item. Codes can be used to
simplify outpur, inpur, and data formars.
9. 7. I Ove rview of Codes
Because codes can represent dara, they are encountered constantly in everyday life.
Student numbers, for example, are unique codes to identify srudents in a school
regisrr:irion ~ystem. Three srudents with the name john Turner might be enrolled ar
the same school, bur <lnly one is srudenr number 268960.
A poswl code is another common example. A nine-digit postal code contain~ n lot
of inform:irion. Por example, the first digit idenciifies 1 of 10 main geographical areas
in the United St:Jtes. The combinarion of the next three digits idencifies a major city
or m:ijor distribution poinc. The fifth digit identifies an individual post office, an :irea
within a city, or a specific delivery unit. The lasr four digirs identify a post office box
or a specific ~rreet address.
For example, consider the zip code 32901-6975 shown in Figure 9-33. This is
called the "5+4" zip code format. The first digit, 3, indicares a broad geographical
area in the southea~rem Unired Srares. The nex't two digits, 29, indicate the area
east of Orlando in Florida. The next rwo digits, 01, represent the city of Nlelbourne,
Florida. The last four digits represent the specific location of the Florida institute of
Technology: 150 W. University Blvd.
Codes can be used in many ways. Because codes are shorter than the data they
represent, they save storage space and costs, reduce dara transmission time, and
decrease data entry rime. Codes also can be used ro reveal or conceal information.
The last two digits of a seven-digit part number, for example, mighr represent the
supplier number or the maximum discounr thar a salesperson can offer.
Finall)', codes can reduce dara input errors in situations when the coded data is
easier to remember and enter than the original source data, when only certain valid
codes arc allowed, and when something within the code itself can provide immediate
verification that the entry is correct.
Broad geographical
locallon In
soUlheastem US
FL
Ot1ando
East
Melbourne
Florida Tech
150 W. Unlvers11y Blvd.
3 29 01 6975
FIGURE 9-33 A zip code Is an example of a significant digit code that
uses groups and subgroups to store data. Th is example is for the zip code
32901-6975. which Is the location of the Florida Institute or Technology in
Melbourne, Florida.

Chapter 9
Data Design
298 9.7 Codes
9.7.2 Types of Codes
Companies use many djfferent cocling methods. Because information system users
mu~c work wirh coded data, the codes should be ea!>y to learn and apply. If it is planned
to create new codes or change existing oaes, comments and feedback from u~rs should
be obtained. The following section describes seven cominon coding methods.
1. Sequence codes are numbers or leners assigned in a specific order. equcncc
codes contain no additional information ocher than an indicarion of order of
enrry into the sy tern. For example, a human resource sysrem issues consccurive
cmplo)•ec numbers ro identify employees. Because the codes arc as~igned in the
order in which employees are hired, rhe code can be used to 'ce thar employee
number 584 was hired after employee number 433. The code, however, does
not indicate the starting date of either person's emplo)'ment.
2. Block sequence codes use blocks of numbers for different classifications. College
course numbers usually are assigned using a block sequence code. JOO-level
courses, such as Chemistry 110 and Mathematics 125, are freshman-level
courses, whereas course numbers in the 200s indicate sophomore-level courses.
Within a particular block, the sequence of numbers can have some addirional
meaning, such as when English 151 is rhe prerequisite for English 152.
3. Alphabetic codes use alphabet lecters to distinguish one item from another
ba~ed on a category, an abbreviation, or an easy-to-remember value, called a
mnemonic code.1'tlany classification codes fir more than one of the following
definitions:
a. Category codes identify a group of related items. For example, a local
department store uses a two-character category code ro identify the
department in which a product is
sold: GN for gardening supplies,
HW for hardware, and EL for
electronics.
ATL ORO u-IR HNO LAX
--- .... __ ------
oFW FRA aDG
-·---
AMS OEN
···-
PHX LAS MAD IAH HKG
--- --- - .-...... ._ .. ~....... ... .................-
MSP o1W aKK SFO MIA
-·-- .....
.. _. __ .... _, ...... .....
JFK LGW EWR _, ___ _...... -·--- ---
SIN ..... NRT
-.......
PEK seA MCO VY! sTL
------ -·---- ---
-·~
......... ..-... -.... ............. _._
FIG URE 9-34 Abbreviations for some of the world's busiest airports.
' "
b. AbbreYiation codes are alphabetic
abbreviations. For example, standard
state codes include NY for New York,
ME for ~l aine, and MN for Minnesota.
Some abbreviation codes arc
called mnemonic codes because they
use a specific combination of lcncrs
that arc easy to remember. Many
three-character airport codes such
as those pictured in Figure 9-34 arc
mnemonic codes, such as ATL for
Atlanta and MIA for Miami. I Iowcver,
some airport codes arc not mnemonic,
such as ORD (Chicago O'Hare) or
MCO (Orlando).
4. Significant digit codes distinguish items by using a series of subgroups of digits.
Postal codes, for example, are significant digit codes. Ocher such codes include
inventory location codes that consist of a rwo-digit warehouse code, followed
by a one-digir floor number code, a two-digit section code, a one-digit aisle
number, and a two-digit bin number code. Figure 9-35 illustrates the invenrory
locarion code l 1205327. \~bat looks like a large eight-digit number is actually
five separarc numbers, each of which has significance.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

9.7 Codes
Phase l
Systems Design
299
Section code
Warehouse location code
'
11 2
'
05 3
'
27
Bin number
Floor number-------
A
~------ Ais le number
FIGURE 9.35 »mple o( a code that uses signifle3nt digits to pinpoint the loation of an inventory item.
5. Derivation codes combine data from different
item attributes, or characteristics. Most magazine
subscription codes arc derivation codes.
For example, one popular magazine uses a
subscriber's five-digit postal code, followedl by
the first, third, and fourth letters of the subscriber's
last name, the last two digits of the
subscriber's house number, and the first, third,
and fourth letters of the subscriber's street
name. A sample is shown in Figure 9-36.
31749 ADE 34 EBE
FIGURE 9-36 A magazine subscriber code is derived from
various parts of the name and addreu.
6. Cipher codes use a keyword to encode a number. A retail store, for example,
might use a 10-letter word, such as CAMPGROUND, to code wholesale prices,
where the letter C represents 1, A represents 2, and so on. Thus, the code,
GRAND, indicates that the store paid $562.90 for the item.
7. Action codes indicate what action is to be taken with an associated item.
For example, a student records program might prompt a user to enter or dick
an action code such as D (to display a record), A (to add a record), and X (to
exit the program).
9.7.3 Designing Codes
H ere arc some code design suggestions:
• Keep codes concise. Do not create codes that are longer than necessary. For example,
if a code is needed to identify each of 250 customers, a six-digit code is not needed.
• A/10111 for expansion. A coding scheme must allow for reasonable growth
in the number of assigned codes. For example, if the company currently has
eight warehouses, do not use a one-digit code for the warehouse number. If
rwo more warehouses are added, rhe code must be increased ro two digits
or changed ro a character code in order to identify each location. The rule
also applies to u~ing a single letter as a character code hecause more than 26
data items might be needed in the future. Of course, more characters can be
added, which is just what the airline industry has done. Most airlines now use
six-character codes char allow millions of combinations.
• Keep codes stable. Changes in codes can cause consistency problems and
require data updates. During the changeover period, all the stored occurrences
of a particular code and all documencs containing the old code will have to
change as users switch ro the new code. Usually, both the old and new codes
arc used for an interim period, and special procedures arc required to handle
the two codes. For example, when telephone area codes change, either area
code (old or new) can be used for a certain time period.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 9
Data Design
300 9.7 Codes
• Make codes unique. Codes used for idencification purposes must be unique co
have meaning. If che code H\V can indicace hardware or houscware, che code is
nor ver)' usefu I.
• Use sortable codes. If products with three-digic codes in the I OOs or the 300s
are of one type, while produces with codes in the 200s are a different type, a
simple sort will nor group all t he products of one type together. In addition,
be careful rhar single-digit character codes will sort properly with double-digit
codes-in some cases a leading zero must be added (01, 02, 03, ere.) to ensure
char codes sorr correcrly.
• Use a simple structure. Do noc code some part numbers wich two letters, a
hyphen, and one digit, and others with one letter, a h)•phen, and two digits.
Avoid allowing both letters and numbers to occupy the same positions wichin a
code because some of those are easily confused. This situation mighc be a good
place co u~e an inpuc mask to assure that the correct data type b entered.
• Avoid co11f11sio11. It is easy ro confuse the number zero (0) and the uppercase
letter 0, or the number one (1 ) with the lowercase letter L (I) or uppercase
lcrrer I. For example, rhe five-character code 5Z08 l easi ly can be misread as
5Z08I, or 52081.
• Make codes meaningful. Codes should be easy to remember, user-friendly,
convenient, and easy to interpret. Using S\Xl as a code for the southwest sa les
region, for example, has far more meaning than the code 14. Using ENG as the
code for the English department is easier to interpret and remember than eicher
XVA or 132.
• Use a code for a single purpose. Do not use a code co classify unrelaced attributes.
For example, if a single code is used to identify the combination of an
employee's department and the employee's insurance plan C)'pe, users will have
difficulty idenrifying all the subscribers of a particular plan, or all the workers
1n a particular department, or both. A separare code for each separate characteristic
makes much more sense.
• Keep codes consistent. Foe example, if the payroll system already is using twodigir
codes for departments, do not create a new, different coding scheme for
rhe personnel sysrcm. lf the two systems already arc using different coding
schemes, cry to esrablish a consistent coding scheme.
CASE IN POINT 9.3: MADERA TOOLS
Madera Tools operates a small business that specializes in hard-to-find woodworking
tools. The firm advertises in various woodworking magazines and currently accepts mail
and telephone orders. Madera Is planning a website that will be the firm's primary sales
channel. The site will feature an online catalog. powerful search capabilities, and links to
woodworking information and resources.
Madera has asked you, an IT consu leant, whether a set of codes would be
advantageous. What codes would you suggest? Provide at least two choices for a
customer code and at least two choices for a product code. Be sure to describe your
choices and provide some specific examples. Also include an explanation of why you
selected these particular codes and what advantages they might offer.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase l
Systems Design
9.8 Data Storage and Access
301
9.8 DATA STORAGE AND Access
Data storage and access involve scraregic business cools, such as data warehousing
and data mining software, as well as logical and physical storage issues, selecrion of
data storage formats, and special considerations regarding storage of date fields.
9.8. 1 Tools and Techniques
Companies use data warehousing and data minj11g as srraregic tools to help manage
the huge quanriries of data they need for business operations and decisions. A large
number of sofr.vare vendors compete for business in chis fast-growing IT sector.
DATA WAREHOUSING: Large firms maintain many darabases, which mtght or
might not be linked together inro an overall structure. To provide rapid access to this
i11formation, companies use software packages that organize and store data in special
configurations called data warehouses. A data warehouse is an integrated collection
of daca that can include seemingly unrelated information, no matter where it is stored
in the company. Because it can link various in£0C1Ination systems and databases, a data
warehouse provides an enterprise-wide view to supporc management analysis and
decision making.
A darn warehouse allows users to specify certain din1ensions, or characteristics. By
selecting values for each characteristic, a user can obtain multidimensional information
from the stored data. For example, in a typical company, n1ost data is generated
by transaction-based systems, such as order processing systems, inventory systems,
and payroll systems. If a user wants ro identify the customer on sales order 34071, he
or she can retrieve the data easily
DliMn•lon•
from the order processing system
by entering an order number.
On the other hand, suppose rhat
a user warns co see June 2019 sales
T!ITl8Penod
results for che sales rep assigned
to jo-l\1ar lndusrne . The data 1s
stored 111 rwo different systems \ 1 I
wirh different darabases: the sales
information ~ys tcm and the human
resources informarion ~ystem, as
!.hown in Figure 9-37. Without a
data warehouse, it would be diffi-
cult for a user to extract darn char
spans several information systems
and time frames. Rather than
accessing separate system~, a data
warehouse stores transaction data
in a format that allows users to
retrieve and analyze the data easily.
While a data warehouse typ­
r
Information
System
Input data
DATA WAREHOUSE
Results
Sates ref)<esenta1ive 121
sold $375.784 10 Jo·Mar
lndustnea during Juno 2019
Sales
1
Human
Resources
Information
System
Input data
FIG URE 9-37 A data warehouse stores dat3 frolTl several systems. By selecting data
dimensions. a user can retrieve specific Information without having to know how or
where the data is stored.
ically spans the entire enterprise,
many firms prefer to use a data mart, which is designed to serve the needs of a specific
department, such as sales, marketing, or finance. Each data mart includes only
the data that users in that depanmcnc require co perform their jobs. There arc pros
and cons to both approaches, and the best solution usually depends on the specific
situation.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
302 9.8 Data Storage and Access
Regard less of rhe overall approach, storing large quanriries of dara is like building
a house-ir doesn'r jusr happen. A well-constructed dara warehouse needs an archirecrure
rhar includes derailed planning and specifications.
DATA MINING: Data mining software looks for meaningful data patterns and relationships.
For example, dara mining sofrware could help a consumer products firm
identify porenrial customers based on their prior purchases. lnformalion about customer
behavior is valuable, but data mining also raises serious ethical and privacy
issues, such as the example in the Question of Ethics feature in rhis chapter.
The enormous growrh in e-commerce has focused attention on dara mining as a
marketing tool. In an article called "Data Mining on the Web" that appeared in the
January 2000 issue of New Architect, a web-based magazine, Dan R. Greening noted
thar web hosrs rypically possess a lot of information about visitors, bur most of it is
of lirrle value. His article mentions tbar smart marketers and business analysts are
using data mining techniques, which he describes as "machine learning algorirhms
thar find buried parrerns in databases, and report or act on those findings." He concludes
by saying thar "the great advan tage of web marketing is thar you can measure
visiror interactions more effectively rhan in brick-and-morrar srores or direct mail.
Dara mining works best when you have clear, measurable goals." Some of rhc goals he
suggesrs are :is follows:
• Increase the number of pages viewed per session.
• Increase the number of referred customers.
• Reduce clicks to d ose, which means average page views to accomplish a purchase
or obtain desired information.
• Increase checkouts per visit.
• Increase average profit per cbeckour.
This t)'pe of darn garhering is sometimes called clickstteam storage. Armed with
this inform:ition, a skillful web designer could build a profile of typical new cusromers,
returning customers, :ind customers who browse but do not buy. Although this inform:irion
would be very valuable to rhe retailer, clicksrream storage could raise serious legal
:ind privacy issues if an unscrupulous firm sought to link :i customer's web behavior to
:i specific n:ime or email address and then sell or otherwise misuse the informarion.
Because ir can derect parrerns and trends in large amounts of data, dara mining is
a valu:ible rool for m:inagers. There is a well-known story about a chain of superm:irkers
that performed a derailed affiniry analysis of purchases and found chat beer and
diapers were often purchased rogetber. Ir is unclear whether or not this story is true,
but without actempting to explain this correlation, the obvious tactic for a retailer
would be to display these irems in the same area of the store. This data mining technique
relies on associariou ru.le learning and is often called mar ket basker analysis.
9 .8.2 Logical Versus Physical Storage
It is important to uuderstand the difference between logical stornge and physical
storage. Logical storage refers to data that a user can view, undersrand, and access,
regardless of how or where that information actually is organized or stored. Tn contrast,
ph y~ica l storage is strictly hardware related because it involves the process of
reading and writing binary data ro physical media such as a hard drive, CD/DVD, or
network-based sroragc device. For example, portions of a documenr might be stored
in differcnr physical locations on a hard drive, but the user secs the document as a
single logical entiry on the compurer screen.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 3
Systems Design
9.8 Data Storage and Access
303
Logical storage consists of alphaberic and numeric characters, such as rhe letter A
or the number 9. As de cribed earlier in rhis chapter, a sec of related characters forms
a field, which dc~cribes a single characteristic, or anribure, of a person, a place, a
thing, or an event. A field also is called a data element or a data item.
When designing fields, space should be provided for che largesr values char can be
ancicipared, wichour allocaring unnecessarily large storage capacities char will nor be
used. For example, suppose a cuscomer order enrry sysrem is being designed for a firm
with 800 cusromers. Ir would be a mistake co lim ic the customer numher field to chrce
or even four characters. Instead, a five-character field wirh leading zeros thar could
store cusromer numbers from 00001 ro 99999 should be considered.
A mix of alphabetic and numeric characters can also be considered, which many
people find easier co view and use. Alphabetic characcers expand the storage capacity
because there arc 26 possible values for each character position. Mose airlines now
use six alphabetic characters as a record locator, which has over 300 million possible
value!>.
A logicaJ record is a set of field values that describes a single person, place, thing,
or event. For example, a logical customer record contains specific field values for a
single customer, including the customer ntunber, name, address, telephone number,
credit limit, and so on. Application programs see a logical record as a group of related
fields, regardless of how or where the data is stored physically.
The term record usually refers ro a logical record. Whenever an application progran1
issues a read or write command, the operating system supplies one logical
record to the program or acceprs one logical record from the program. The physical
data might be stored on one or more servers, in the same building or thousands of
miles away, bur all rhc applicarion program sees is rhe logical rccord-rhe physical
srorage locacion is irrelevant.
9.8.3 Data Coding
Computers represent data as bits (shorr for binary digits) that have only two possible
values: I and 0. A computer understands a group of bits as a digital code that can
be transmitted, received, and stored. Computers use various data coding and storage
schemes, such as EBCDIC, ASCII, and binary. A more recent coding standard called
Unicode also i!> popular. Also, the storage of dates raises some design issues that mu~t
be considered.
EBCDIC, ASCII, AND BINARY: EBCDIC (pronounced EB-see-dik), which stands
for Extended Binary Coded Decimal Interchange Code, is a coding method used on
mainframe compurers and high-capacity servers. ASCII (pronounced ASK-cc), which
stands for American Standard Code for In£ormatJion Interchange, is a coding method
used on mosr personal computers. EBCDIC and ASCII both require eight bits, or one
byre, for each characrer. For example, the name Ann requires 3 bytes of srorage, chc
number 12.345 requires 5 bytes of storage, and the number 1,234,567,890 requires
10 byres of storage.
Compared with character-based formats, a binary storage format offers a more
efficient storage method because it represents numbers as actual binary values, rather
than as coded numeric digits. For example, an integer format uses only 16 bits, or
nvo byres, to represent the number 12,345 in binary form. A long integer format uses
32 bits, or four bytes, co represenr the number 1,234,567,890 in binary form.
UNICODE: Unicode is a more recent coding srandard rhar uses two byres per
character, rather than one. This expanded scheme enables Unicode co represent more

..
Chapter 9
Data Design
304
9.8 Data Storage and Access
than 65,000 unique, mu ltilingual characters. Why is this important? Consider rhe
challenge of running a multinational information system or developing a program
that will be sold in Asia, Europe, and North America. Because it supports \irtually all
languages, Unicode has become a global standard.
Traditionally, domestic software firms developed a product in English and rhen
tran lated the program inro one or more languages. This process was e\.pcnsive,
slow, and error-prone. In contrast, Unicode creates translatable content right from
the srart. Today, most popular operating systems support Unicode, and the Unicode
Consornum maintains standards and support, as shown in Figure 9-38.
~ The Unicode Consortium c.-. .,, ,.,._ , s-
n.-­
OuktlUr>b
C:-0-
n.c •••
•
n.u............ ..
--
..............(C\.OllQ ..
-_ _ -
a.Oii
UTC_,.._
.
QJTC
"1t• I w.-O. •
......... o... CW-11-
7
UTC~ ........ •
... ...
---- ,.Q .•
..
........ -.
• -- ~~.Jd!Llf!JA&Ht0soctrQl.llll t''
wr--110 .. pp1t• l'll.._~
l!lll.Lll!lllllll.Jj--.il!C - ,_., ...,
't W l:lV'IVGil
-·~
- ..
DI
•
2 '
1
•
s
',
I
•
10
11
,,
• 1 M
FIGURE 9-38 Unicode Is an international coding format that represents charaeters as Integers, using 16 bits (two bytes)
per character. The Unicode Consortium maintains standards and support for Unicode.
SouK.t ""'
• c
,,,... "'
STORING DATES: What is the best wa)' to store dares? ·me answer depends on how
the dates will be displayed and wbether rhey will be used in calculations.
At the beginning of the twenty-first century, man)' firms that used only two digits
to represent the year were faced wirh a major problem called the Y2K issue. Based
on rhar experience, most date formats now are based on the model established b)' the
International Organization for Standardization (ISO), which requires a format of four
digits for rhe year, rwo for the month, and two for the day (YYYYMMDD). A dare
stored in rhar format can be soned easily and used in comparisons. If a dare in lSO
form is larger rhan another date in the san1e form, then the first date is later. For example,
20150504 (May 4, 2015) is later than 20130927 (September 27, 20 L3 ).
But wbat if dates must be used in calculations? For
example, if a manufacturing order placed on June 23 takes
three weeks co complete, when will the order be ready? If a
payment due on August 13 is nor paid until April 27 of the
0
t , following year, exactly how late is the payment and how
much inteTesr is owed? In these situations, it is easier rouse
• .!. •
-·
t(21fU
UIS
FIGURE 9.39 Microsoft Excel uses absolute dates In
calculations. In this example. May 4, 2019, ls displayed as
43589.and September 27. 2015.ls displayed as 42274.
The difference between the dates Is 13 I 5 days.
absolute daces.
An absolute date is the total number of days from some
specific base date. To calculate the number of days berween
rwo absolute daces, one dare is suhtracccd from rhc other.
For example, if the base date is January I, 1900, then May
4, 2015, bas an absolute date of 42 128. Similar!)', Seprember
27, 2013, has an absolute date value of 41 544. If rhe earlier
dace value is subtracted from the later one, che re ult is 584
days. A spreadsheet can be used ro determine and displa)
absolute daces easily, as shown in hgure 9-39.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
9.9 Data Control
305
9.9 DATA CONTROL
]use as it is important co secure the physical part of the syscem, as shown in
Figure 9-40, file and database control must include all measures necessary to ensure
that data storage is correct, complete, and secure. File and database control is also
related to input and ourpur techniques discussed earlier.
FIGURE 9_.0 In addition to network monitoring, system securicy includes access codes, data
encryption, pa,sswords. and audit crails.
A well-de 1gned DBM must provide built-in control and secunty features, including
subschemas, passwords, encryption, audit rrajl files, and backup and recovery
procedures to maintain data. The analyst's main responsibility is to ensure that the
DBMS features are used properly.
Earlier in this chapcer, it was explained that a subschema can be u ed ro provide a
limited view of the database to a specific user or level of users. Limiting accei.s to files
and database& is the most common way of procecting stored data. Users must furnish
a proper ui.er ID and password co access a file or database. Different privileges, also
called permi ~s i on~ , can he associated wid1 differenc users, so some employees can be
limited ro read-only access, while ocher users might be allowed ro update or delere
data. For highly sensitive data, additional access codes can be established thar restrict
i.pecific records or fields within records. Stored data also can be encrypted to pre·
vent unauthorized access. Encr yption is the process of converting readable data into
unreadable charnccers to prevent unauthorized access to the data.
All system fi les and databases must be backed up regularly and a series of
backup copies must be retained for a specified period of time. In the event of a file
catastrophe, recovery procedures can be used to restore the file or database to its
current state at the time of the last backup. Audfr log fil es, which record details
of all accesses and changes to the file or database, can be used to recover changes
made since the last backup. Audit fields, which are special fields within data
records to provide additional control or security information, can also be included.
Typical audit fields include the date the record \Vas created or modified, the name
of the user who performed the action, and the number of times the record has been
accessed.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 9
Data Design
306 9.10 Summary
Tip Top Toys is a relatively small division ofWorldwide Enterprises. Worldwide has nine
other divisions, which include insurance, health-care products. and financial planning
services, to name a few.
The corporate marketing director for Worldwide has requested Tip Top's customer
shopping data to target people who might be likely to purchase items or services from
other Worldwide divisions. The database manager is not totally comfortable wich chis and
pointed out Tip Top's web privacy policy, which states "Tip Top Toys. a division of Worldwide
Enterprises, will not share personal data with other companies without a customer's
consent."
The marketing director replied that the statement only applies to outside companiesnoc
other Worldwide divisions. He said he checked with the corporate legal department.
and they agreed. The database manager replied, "Even if it is legally OK, it's not the right
thing co do. Many people take our statement co mean that their data does not leave Tip
Top. At the very least, we should give customers a choice, and share the data only with
their consent."
Do you agree with the marketing director? Why or why not?
9. I 0 SUMMARY
This chaprer conrinued the scudy of the systen1s design phase of rhe SDLC. Ir was
explained rhar files and tables contain data abour people, places, things, or evenrs that
affect the information system. File-oriented systems, also called file processing systems,
manage data stored in separate.
A database consisrs of linked tables that form an overall data Structure. A DB~1S
is a collection of tools, features, and inrerfaces that enable users to add, update, manage,
access, and analrze dara in a dat abase.
DBMS designs are more powerful and flexible than crad1tional file-oriented srstems.
A database environment offers scalabiliry, support for organization-wide access,
economy of scale, data sharing among user groups, balancing of conflicring user
requirements, enforcement of standards, controlled redundancy, effective security,
flexibility, better programmer productivity, and data independence. Large-scale databases
are complex and require extensive security and backup/recovery features.
DBMS components include interfaces for users, DBAs, and related systems; a
DML; a schema; and a physical data repository. Other data management techniques
include data warehousing, which stores data in an easily accessible form for user
access, and data mining, which looks for meaningful patterns and relationships
among d:ira. Dara mining also includes clickstrearn storage, which records how users
interact with :i site, :ind marker baskec analysis, which c:in iJentify pro<luct relacionships
:ind consumer buying patterns.
In a web-based design, the Internet serves as the front end, or interface, for che
DBMS. Access to the database requires only a web browser client and an Internee
conne<..-cion. Middleware can interpret client requests in HTML form :ind cranslate
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase l
Systems Design
9.10 Summary
307
the requesrs into commands rhar rhe database can execute. \'Veb-based dara must he
secure, yet easily accessible ro authorized users. To achieve this goal, well-designed
systems provide security ar rhree levels: rhe database itself, the web server, and the
telecommunication links that connect rhe componencs of the system
In an information system, an entity is a person, a place, a thing, or an event for
which dara is collected and maintained. A field, or attribute, is a single characteristic
of an entity. A record, or tuple, is a set of related fields that describes one msrance of
an entity. Dara 1s 5torcd in files (in a file-oriented system) and cables (in a database
environment).
A primary key is the field or field combination that uniquely and mimmally identifies
a specific record; a candidare kc)' is any field rhat could serve as a primary key. A
foreign key is a field or field combination that muse match rhe primary key of another
file or table. A secondary key is a field or field combination used as the basis for sorting
or retrieving records.
An ERD is a graphic representation of all system entities and the relationships
among them. The ERD is based on entities and data stores in DFDs prepared during
rhe systems analysis phase. The three basic relationships represented in an ERD are
one-to-one ( l: 1 ), one-co-many ( J :M), and many-to-many (M:N). In a M:N relationship,
the two entities arc linked by an associative entity.
The relationship between cwo entities also is referred to as cardinality. A common
form of cardinality notation is called crow's foot norarion, which uses various symbols
co describe rhe characteristics of the relationship.
Normalization is a process for avoiding problems in data design. A I NF record
has no repeating groups. A record is in 2NF if it is in I NF and all nonkcy fields
depend on chc cncirc primary key. A record is in 3NF if it is in 2NF and if no field
depends on a non key field.
Dara design tasks include creating an initial ERD; assigning data elements ro an
entity; normalizing all table designs; and completing the data dictionary entries for
files, records, and data clements.
A code is a set of letters or numbers used to represenr data 111 a system. Using
codes can speed up data entry, reduce data storage space, and reduce transmission
time. Codes also can be used to reveal or to conceal informacion. The main types
of codes are ~equence codes, block sequence codes, classification codes, alphaberic
codes (e.g., caregory codes, abbreviation codes, and mnemonic codes), sig111ficanr digit
code5, dcnvarion code~, cipher codes, and action codes.
Logical storage is information seen through a user's eyes, regardless of how or
where rhat information actually is organized or stored. Physical srorage 1s hardware
related and involves reading and writing binary data to physical media. A logical
record is a related set of field values that describes a single person, place, thing, or
event. Dara storage formats include EBCDIC, ASCH, binary, and Unicode. Dares can
be siored in several formats, including ISO and absolute format.
File and database control measures include limiting access to the data, data
encryption, backup/recovery procedures, audit trail files, and internal audit fields.
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ·· · ---~~-.,.- "~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 9
Data Design
308 Key Terms
Key Terms
I: I .\ type of en!lt) rcl:111onsh1p. A one-ro-one relarionship, abbreviated I: I, e'1srs when exactl) one of
the ~ond enm) occurs for e-.ich instance of the first eouty.
I :M A rype ol cnnn rc'3rion)h1p. A one-to-man>• refanomhip, abbre,·iatctl I :M, cx1>t> when one <><:cur·
rcm.e of the finr cnt1ry .:an be related ro many 0<:currcncc\ of the '-"LOntl cnnty, hut each ou:urrcncc
of the -.ccontl enriry can be associated with only one occurrence of the fil'or cnnl)'.
ahhrc~iat;on cock Alphal>etic ahhreviarion. For example, ~randartl \t,lle codt..., include '"Y for '-:ew
York, ME for ~faine, 3nd MN for Minnesot:L
abwlute date lbe total number oi days from some specific bnse date. fo calcufotc the number of da)'S
between two .1bsolute dat.-s, subtract one date from the other. For example, usmg a bJse date of Janu·
Jr) 1, 1900, September 27, 2012, has an absolute date "alue of 4117!1 Jnd Jul) JJ, 2011, has an absolute
dare of 40737. If rhc earlier dar<' value is subrracted from the IJtcr one, the result is 442 d,1rs.
acuon code Indicates whJt ,1crion is robe taken with an associJted Item. For exJmple, a student records
progrnm might prompt a user ro enter or click an action code such as D (to d1spla> the student's
record}, A (ro add a record), and X (co exit the program).
alphabetic rntlc Use' alphab"c leacr~ to tlisringuish one item from another ha\Cd on a catci:ory, an
Jbhrcvint1011, C>r an ea,y·tC>-remcmber value, called a mnemonic code.
ScanJ, for American Standard C.<Jde for Information lntcrchani:c, a lLita 'mrasc coding method
u'ed on mo~t pcrmna I computers and workstation<.
A~Cll
a~~ociath·e cnriry An enriry thar hns its own set of .irrributes .rnd ch,uacrcnstics. AssoctJt1\·e enrirics are
used to link between many-to-many (M:N) relationships.
attribute A srngle chJractenstic or fact abottt an entiry. An arrnbute. or field. 1s the smallest piece of dJta
th.u h.is meanmg within ao information system. For example • .t 5oc1JJ ~urtC) number or company
n.1me could l>e examples of an armbure. Ln ob1ect-oneored .m.ilys1s, an atmbute as pan of J class d1a·
gram th.it describes the characrenstics of objects in the class. Also kno\\n as J data elemeot.
3.udu field\ <;pccial fields ,~; rh in data records ro provide additional control or '>«Uri!)' informarion.
T)•pical audu fields include rhe dare the record was created or modified, the name of the user who
performed rhe action, and the number oi rimes che record hJ'> been an:.,.,.,.,J.
:audit IO)I file\ Roxord detail~ of all accesses and change> co a file or tl.naha\C and can he u'>Ctl to nx:o•cr
changes made since the last backup.
bad.up fhe process of saving a series of file or data copies to be retJtned for a specified period of mne.
Data can he hacked up conunuously, or ar prescribed intervals.
binary qora~e format A formar that offers efficient storage of numeric data. For t.'xample, when numeric
data t) pes are specified using Microsoft Access, there are a variety of sroragc formats choices, includ·
mg mteger and long mteger, among others.
bit The 'niallc.i unit of darn is one bin:try digit.
block ;cqucncc code Cipher that u;e; blocks of numberb for different cla;~ification'>.
by1e A group of e1ghr bus is called a byre, or a character. A ser of byres forms .1 field, which is an ind1v1tl·
u.11 f.1ct about a person, a pl.ace, a thi11g, or an event.
candidate key ~omctim~ iris po<sible ro have a choice of field~ or field comhinauon~ to use as the pri·
mary key. Anr field thac could serve as a primary key is called a candid.ire kc).
cardinaliC) i\ concept rhar de<cribes how instances of one cnnl)· relate to instance< of another cnriry.
Described in FRDs br norarion rhar indicates combinarions rhat include 1cro or one·rn·many, one-co·
one, anti many-to-man}.
c.ud1naht) notation Code rhat shows relationships between emmes.
o;'jtci;ory cod.~ Cipher;. that identify a group of related 1tem>. !'or e.,a.mplc, j lo..al tlepJrtmcnr >tore ma>
use a l'•o·charactcr category code ro identify the deparrmenr 1n whKh a produll "sold.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase l
Systems Design
Key Terms
309
char.1c1cr A i:roup of c111h1 hot> i~ .:ailed a characrer, or a brre. A ..et of brr~ fonm a field, which i, an
1nd1V1dual f.11.t ahouc a pcr\on, a place, a rhing, or an cvenr.
cipher cod<:'> Use of a kcrword 10 encode a number. A reratl srore, for example, may use a I 0-lctter
word, \uch as Cl\Ml'GROU:-<D, ro code wholes.ile prices, where chc lcncr C reprcscnr~ I, A rep·
rescncs 2, and so on. Thus, the code, GRA:>.D, would indicate char the store paid $562.90 for che
uecn.
clich 10 close fhe average number of page views 10 accomplish a purchase or obtam des1ted
mformJt1on.
did..,trcam \10ra11c R<-<;ordini; wch Vl\itor hchav10r and traffic trend, for later dara m1n1ni:. U\c.
cudc A -.er of lcrter\ or numhef\ chat represents a data item. Codes can be used to ,;mplify output, input,
and darn formats.
combination key A type of dara validation check d1at is performed on rwo or more fields 10 ensure that
they arc consistenr or reasonable when considered rogecher. Even diough all the fields involved in J
combutauon check might pass th~ir indiHdual validation checks, the combi11,11io11 of the field v.1lue>
nught be inconsasccnr or unreasonable.
common field An attnburc rhar appears in more rhan one euriry. Common fields can be used ro link
entities in vacious types of relarionships.
compmire key Somcrime< it i< nccc<<ary for a primary ker m comi\I of a combination of field,. In that
case, the primary key i< called a comhinarion key, composite key, concatenated key, or multivalued key.
conca1e11atcd key Sec ;:on•P<hllc kc) .
cro" ·, £001 oot.iuon A type of cardinaLit) notation. Ir is called crow·s foot 1101atio11 because o( rhe shapes,
wruch uiclude c1tdes, bars, and S)'mbols. that mdtcate vanous poss1btlmes. A sangle bar uid1c.11es one, a
double b.lr and1c.11es one and onl) one, a cU'cle mdicares zero. and a crow's foot mdicates m.iny.
data clement A single char.1ctcrm1c or fact about an enriry. Adara element, field, or .mnbute cs the
smallest pac~ce of data that bas meanmg within an information system. for ex.implc, a Social Sccurit)
number or comp.in) name could be ei..amples of a data l'lemenr. The rean d.J/J item is also used.
data 11cm Sec Jara clement.
data manipulation h1n11uai.:c (0\.fl) A DML controls database operations. including ~torini:. rctncving,
up<latini;, and dclc11n11 data. Mo<e commercial DBMSs, such as Oracle and IBM\ DBl, use J DMI..
data lllMI A spe<1ahled d.u.1base designed 10 serve the needs of a spectfic department, such JS sales,
m.irkeung, or finance. Each data marr includes only rhe dara rhat users m rhac dep.irtment require to
perform their 1obs.
daca mining Lookmg for meaningful patterns and relationships among dt\ca. For example, data mm
ing software could help a consumer products firm identify potential cw.tomers based on their prior
purchases.
data 'tructurc A mcaninf;ful combination of related daca clements that is indudcd in a data flow or
retained in a d<1ra >tore. A framcwork for organizing and storing data.
data woirchnu~c An inrcgrarcd collccrion of darn that can Sltpporr managemcnr analysi~ and dcci~ion
making.
dntaba~c odmoniHr.itM (OBA! Someone who manages a DBMS. The DBA assesses overall requirement~
and ma1or.11ns the darabai.c for the benefit of the entire organuacion rather than a smgle deparrmenr
or user.
Jatab.i>e mJna11cmcn1 >) ;ccm (OBMSi A rnllecnon of cools, features, .ind interface> that enable> u>er> co
add, update, manage, acce~~. and analpe dara in a darabase.
dcnv01tion code Comhonmg dara from different item attributes, or charactcrisnc~, ro build rhc code.
Mo\t magazine sulxcnpnon codes are dcrivarron codes.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 9
Data Design
3 10 Key Terms
f BCOIC Stands for E..'l.tended Bina!") Coded Decimal lntercbaoge Code, a cod mg method used on mamframe
.:ompmers and M>me high-capacity secvers.
cwnonl\ of ,~.de The inhcrenr cfficienc)' of high-volume proces>ing on larger <omputer>. Databa>e
de"gn allmY'> better uulizanon of hardware. If a company maintain\ an enrerpri,e-w1dc databa...,, procc<>\lng
i~ le<>\ ex~n'i"e using a po\vcrful mainframe server instead of u~ing <.C\'eral \mailer compmers.
cncrn>tinn A proce-;~ where data i~ coded (convened into unreadable char.1cter•) '>O rhar only tho~ wirh
the required nurhori1ation can access rhe data (usuallr via de<oding ,oftware)
entity A person, a place, a thing, or an e'·enr for which dara is coUcacd and mamtJ1ned. ~or example, an
onlme sales S)Stem may inc.:lude entities named CUSTOM . .l:.R, ORDJ:.R. l'RODUCf, and SUPl'UER.
cnllt)·-rclauon>lup diagram (ERO) A grapluca1 model of the mformation system that depicts the relanonslups
among system enri11es.
fidd A 'inglc ~harnctcrl<,tic or fact about an cntiry. A field, or attribute, i' the 'mallc~t piece of data that
ha' meaning within an infnnnation ')'stem. For example, a Social Sccurit)' numhcr or company name
could he examples of a field. The terms data element, data item, and field are u'cd intcrchani;cably.
file Each file or rahlc comnins dam a hour people, p laces, things, or evenLs that intera..-1 with the information
'Yl>lcm.
iile-oricnicd sy~tcm A ftle-onented system, also called a file processlllg system, stores .ind manages d.ita
Ill one or more separare files.
first normal form ( LNI') A record is said to be in lNF 1£ 1t does not contain a repe.mng group (,1 set of
data items that can occur any number of times in a single record).
forci~n key A field in one table that must match a primary key \"aluc: in another table in order ro esrabll\h
rhc rcl;uion'>hip between the two tables.
fun•'tionall) dcp<ndent Funnional dependence is an imponant concept for under\tanding the 2l-.'F. The
field X "'aid to be fun,·wm.11ly dependent on rhe fidd Y 1f the \·aluc of X depend, on the \·alue of Y.
For example, an order date is dependent on an order number. for a pamwlar order numhcr, rherc 1s
only one \'alue for rhe order dare. Jn conrra<r, rhe product de-;cription os not dependent on the order
number. For a panicular order number, there might be ~veral product dc><:ription\, one tor each item
ordered.
lntemauonal OrganiLation for 5tandardiLation (150) A networL. of nauon.il ~tand.irds 1m111u1es lrom
over a hundred counmes working in pannership wub 1mcrnanon.il orgaml.lnons, govcmmenrs,
industncs, and bus111css and consumer representanves. The ISO acts as a hndgc llCtween public and
private seetors.
ja\a databa\c conncctivit) UDBC) A >tandard that enables Java application~ to cxch;mge data with any
darJbase th.It uses SQL statements and is ODBC-compliant.
key field\ Ui,ed during the ~)'' terns design phase ro organi1e, accc>>, and mainrnon data \tructure,, The
four typt·~ of key fields arc primary keys, candidate key>, foreign keys, and ~crnndary key~.
lo11ica l record A lo11ical record concain< field values that describe a ~inglc pcr>on, place, thin11, or event.
Applicncion program< see a logical record as a set of field<, rcgardlcs'> of how or where the data is
'torcd phy<1cally.
logical \tOraAc Refer& to information as seen th rough a user's eyes, regardlcs~ of how or where that
information 1; organiLed or srored.
M:l\ A rype of encity relationship. A man}·to-m.1.n} relauouslup, abbrevi.ued M:N, exist> when one
instance of the firq enrity can be related ro many instance<> of the second enmy, and one 1n~t.incc of
the ~ond cnm) can he related 10 many instances of the first ent1t).
man}-to-man) rdatiomhip See \{:N.
markrt h.1d.:et analy<i< A rype of analysis rhat can derecr pattern~ and trend~ in large amounts of data.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase l
Systems Design
Key Terms
311
m1ddlc\\arc 5oft\\arc that conne.:t~ d1\>1m1br apphcanons and enables them to communicate and
c'\,hange data. For c\amplc, m1ddlcwarc can lmk a dcpa rtmcntal databa..c to a \\ cb \cn·cr 1ha1 can
be accessed by client computers via rhe lnrcmcc or a company inrranet.
mnemonic code Cipher~ u~ing a ~p«1fic combanarion of lerrers that arc easr co rcmembcr. Man)'
thrce<haractcr J1rpon codes are mnemonic codes. For example, LAX represents Lo> Angeles.
mulcivalued kc~ Someumes Jt 1s necessary for a primary key co consist of a comb111Jrion of fields. In that
case, the prill1Jry key 1; ~ailed a combuiauon ke), composite key, concatenated key, or mulm alued key.
nookcy field Any field that i'> nor a primar) kc)' or a candidate key;,, called a nonkey field.
nor1nal1uuon A pr<"'"" hv which analy'll• 1dent1fy and corn-ct inherent problems and complc\illc' m
their record dc,ign,.
one·to-man) rclat1on~h1p
See J :M.
one-to-one rclauon\hip Sel' I: I.
open databa>c connectivity (ODBC) An inclusrry-standard protocol that make' it po~'ihlc for ;oftwa1·c
from different vendors ro inrcrncr nnd exchange dnrn.
orphan An unassociared or unrelared record or field. An orphan could be created if J cusromer order
was emercd in an order table where rhar cuscomer did nor already exist in che cuscomer tJble. Refer·
cntial integrity would prevent rhc creation of thi~ orphan.
permissions Uscr-spcc1f1c pnv1ley.es th.Jr derermme the rype of access a user has to a dacabJsc, file, or
dtrectory. Also called user nghrs.
phrical 'tl'f1111t Information 'ttorai;c mcd1ani'rn that is <tri~Tly hardwari; related, ~"t;rnw it invuh·c-- the
process of rcadmg Jnd writing binaf) data to physical me<lia. such .is a h•ud dri\e, fl.ish drive. or DVD.
primal) t..,") \ field or comhm:mon of fields rhar uniquely and minimally identifie' a particular member
of an cnut). For example, 111 a c.:u,t0mer mhle the cu~tomer number is a umquc pnmal') kc) hct:au-.e
no mo c.:u>tomcr' .:an have the !hlmc ~-u>tomer number. That kc) aho i~ m1n11nal bccau-.e n contain.,
no mfnrmannn bcrond what " needed ro identify rhc cusromcr.
query b) c~ampk
QRf 1 A language allow~ the user co pro,;dc an example of the data reque,ted.
quef) lanRuagc Allows a user ro ~rcc1f)· a task wirhour spccif)'ing how the task wtll be accomplished.
Some query languagrs use natural language commands that resemble ordinaf) English senrencrs
record A set of related fields that describes one instance, or member of an emit), ;uch as one customer,
one order, or one produu. A record m1gl11 have one or doreus of fields, depeudmg ou "hat mformauon
1s needed. Al~o called a ruple.
rcco,cry procedure Pmce" for resrorin11 data and rcsrarrin~ a ~ys1cm after an interruption. Recovery
procedure' can be UM"d m rc<rorc a file or database ro its current state at the time of rhc la~r backup.
referential integrity A rypc of validity check. Referential inregriry i< a sec of rule<> thar avoid< dara incon
'i~tcncy and quality problem\.
rela1iooal databa~c A darahnse in which rnhles are related by common fields, creating a unified d.1C,1
strucrnre th.11 provides improved data qualicy and access.
relational model A model u;ed in relational databases. The relattonal model was mtroduced du rang the
1970; and be'ame popular bec.1usc n was fleXtble and powerful.
rcpca111111 group A >CC of one or more field; char can occur any number of rime; in a single rc<:ord, wuh
each occurrence having d1ffcrenr values.
scalabtlit) A characrcri~ric implying rhc system can be expanded, modified, or dowmi1cd easily m meet
che raptdl> changing need~ of a business enterprise.
~cbema The complete definmon of a database, indudmg descriptions of all fields, records, and
relaoon;lups.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 9
Data Design
312 Key Terms
~c~ond normal form (2'\1- A record design is in 2NF if ic is Ill l;\J and u all fields thar arc not pan of
che pnmJI) Ley are depeudem on the enure primar) ke). lf .Ill) field in .1 l~ l rC\:orJ depend; on only
one of rhe fu~lds ma combmanon prunary key, then the record 1s not m 2::-;1. A I ::-;1 record wirh a
primary key rhac ts a single field is aucomaricallr m 2::>:F.
\ccondal') kC} .\ field or comhinarion of fields char can be u~ ro a•CC\S or rcrric,·e rcc:ord\. ~ondary
key \'.llue; are nm unique. For example, co acces; records for only tho..e lu,comcr\ m a '11<!dfic p<>'>-ral
rndc. rhc Jl(l\CJI •ode field could he used as a secondary ke).
\cquenlc wdc Number- ()r letter- assigned in a specific order. Sequcnlc: rndc\ lontain no add111onal
information other than an indicanon of order of entry inro a ;y\ttm.
s111nific;m1 d1111c code Cipher rhar d1srmguishes items by usmg a series of subgroups of dagm. U.S. l'osral
Service iip codes, for example, arc significant digir codes.
\Candard nocarion formm A rcprcscnrnrion cha r makes designing cables easier as ic clearly ~how~ a mblc's
s1ruc1ure, fields, and primary key.
Strucrna·cd Query Uinguagc (SQL) t\ query language char allows PC u ~er ' co communicate with 'crver.,
and mainframe computcn ..
'ubi.d1cma t\ view nf rhc datab:isc used by one or more: syMem; or u;cr;. t\ .,ub.,lhcma defi ne., only
rho' c p<>rtiom of the database char a parncular ' YStcm or u' cr need' or i' allowed m accc".
rablc Lach file or r-.ible contains darn abour people, places, thmgs, or events ch.11 uueracc wirh rhe uuormauon
S)'~tem.
rablc de\ign Speofies the fields and identifies che primary key in a p.1rricular rable or file.
third normal form ( 3"11') A record design is in 3:-.'F if it i< in 2NF and if no mmkC)' field i< dcpcndcm on
anocher nonkey field. A nonkey field is a field that is nm a candidare ke) for the pram:iry key.
ruplc ,\ ruple (rhyme., with .:ouple), or record, is a >et of relace<l ltcld.. chat de-..:nbc<. one in~t:1nce, or
mc:mhc:r of an c:ntatv, wch a; one: c~romcr, one order, or one: produ~'t. A cu pie nui:ht h;l\c: one or do7-
cn< of field<, depending on whac information is needed.
l.,nacode A relam·dy recem coding merhod thar represents duracrers JS mcegers. Unlike l:.BC.:DIC and
ASCII, which use e1gh1 btts for each characrer, Unicode requires 16 bars per characcer, which allows IC
to rcpr~nr more than 65,000 unique cbaracrers.
Uru6c<l \iodclmg Language (Ui\il) A widely used method of vi!.uafumg and documenung sofrware
sy.rems des111.n. U~lL uses ob1ecc--0nemed design conceprs, but 1t 1s tndepcndent of any specific
progranurnng language and can be used to descrihe busmess processes .ind requaremcms genera II).
unnonnali1cd ;\ record rhar contains a repeating group. which mean> rhac a "ngle record ha> mu lt iple
uccurrcnce< of a particular field, with each occurrence having diffcrcnr value<.
Y2K i\\UC 1\ problem faced by mnny fi rm< in rhe rear 2000 hecau'e their C()mpurcr '>Y'>tcam used only
f\\O di1:1r' IO represent rhc yc:ar; most dares now use 11 four-digit format for rhc year (YYYYMMDD ).
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase 3
Systems Design
313
Exercises
Questions
I. \Xlhar is a dam srrucrurc?
1. Brief!)' describe the componenrs of a DB.\ILS.
3. Lisr the major characrerisrics of web-based design.
4. l:.xpl;un primary key, candidate key, secondary key, and foreign key.
5. What arc ERDs and how are they used?
6. How do you convert an unnormalized design to lNF? Lo your answer, refer ro specific pages and
figures in rh1s chapter.
7. How arc codes used in data design?
8. Whar is data warehousing and dara mining?
9. How would a specific date, such as March 15, 2019, be represented as an absolute date?
I 0. How arc permissions used ro control access ro data?
Discussion Topics
Projects
I. Jn the auto shop examples in Section 9.1.2, what arc some problems thar might arise in Mario's
system? \Xlhy won 'r Danica run into the same problems? Provide ~pecific C'Camples in your answer.
2. Many large organizations have had tbeir database system hacked and customer dara srolen. How
should rhe secunry for rhe database be differenr than security for the resr of rhe system? Does ir make
a difference for web-based dara designs? lf so, how?
3. Suggesr rhree rypical business siruacions where referenrial integnry avoids data problems.
4. \Xie use tors of codes m our personal and business live!>. How many can you name?
5. Are there erhical issues ro consider when planning a database? For example, should sensitive personal
dara (such as medical information) be stored in the same DBMS rhar manages employee salary and
benefirs data? \Vhy or why nor?
I. Consider an automobile dealership with chree locations. Dara fields exist for srock number, vehicle
identificarion number, make, model, year, color, and invoice cost. Identify rhe possible candidate keys,
the likely primary key, a probable foreign key, and porenrial secondary keys.
2. Vis1r the bookstore ar your school or in your area. Interview the manager or store employees ro learn
more about the business and the entiries rbar are involved m book~tore operations. Remember that
an cmiry is a person, a place, a thing, or an event that affects an information system. Draw an ERD,
including cardinality, which describes the bookstore's operarions.
3. Cludadwy Chairs sells a parented sear rhar spectarors can take ro youth soccer games. The scat folds
so it is small enough ro fir in rhc glove box of most vehicles. The company opcr:ites a facrory in Kansas
and also contr:icts irs manufacturing projects ro small firms in Canada and Mexico.
An unusual problem has occurred for this small multinational company: People are gemng confused
about dares in internal memos, purchase orders, and email. When the company's database was
originally designed, the designer was nor aware that the format for dares in Canada and Mex~ico
was different from the format used in the Unired Stares. For example, in Canada and Nlexico, the
notation 7/ 1/19 indicates January 7, 2019, whereas in the Uni red Stares the same norarion indicates
July l, 2019. Although ir seems like a small point, the date confusion has resulted in several order
cancellations.
Cludadw) Chairs has asked for your advice. You could suggest writing a simple program ro convert
the dares automaticall)' or design a switchboard command thar would allow users ro select a date
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... . ... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 9
Data Design
314 Exercises
formar as d:na is cnrcrcd. You reali1e, however, rhac Cludadwy Chairs mighr wanr ro do business in
orhcr councrics in rhe fururc. \Xlhar would be che besc course of accion? Should rhc compan)' adapr ro
rhc ~randard of each counrry, or should ic mainrain a single international formar? \Xlhar arc che argumenrs
for each opnon?
4. Use ~11crosofc Access or sinular dacabase software co create a DBMS for the imaginar)' company
called TopTexc Publishing, which is dt'scribed in Cast' in Poinr 9.1. Add several sample records co each
rable and report 10 the class on your progress.
5. Search rhe internet to find information about date formats. Determine whether rhe date formar used
in chc Unired Stares is rhe most common formac.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

~ JIJ»C ....... ~ Al RlilfD l,eocl\olld.,...,. _WOlfi'l'l.~• ......-W.Mdk«iil,_._DIK•dtc--.:......,_...,_.,~-.lit.......... .._.,._.__..,~•\
~ ..._ ..._........, ~...,.._,_..,..., J\&."9 ...--.11......... ~ C'dptl"~~d.tt ......- ............- .....- ..........-.-.....w--...-.11

Chapter I 0
System Architecture
System
Architecture
Chapter I 0 is the final chapter in the systems design
phase of the SDLC. This chapter describes system
architecture. which translates the logical design of an
information system into a physical blueprint. Designing
the system architecture requires consideration of servers.
clients, processing methods, networks, and related issues.
The chapter includes three "Case in Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics" explores
the trade-offs between the potential benefits of Installing
tracking software on users' computers to Improve the
system's response to common usage patterns versus the
ethical issues related to invasion of privacy by constant
monitoring of employees' online activity.
LEARNING OBJECTIVES
W/Jen you finis/, this chapter, yo11 should be able
to:
I . Provide a checklist of issues ro consider when
selecting a system architecture
2. Trace the evolution of !>ysrem architecrure from
mainframes ro current designs
3. Explain client/server architecture
4. Describe Lhe impacl of the lnterner on syi.rem
archirecrure
5. Compare in-house e-commerce dcvclopmenr
with packaged solutions and service providers
6. Explain online and barch processing
7. Describe network models, including hierarchical,
bus, ring, star, and mesh topologies
8. Explain network devices, including routers, gateways,
and proxy servers
9. Describe wireless networking, including wireless
standards, topologies, and trends
IO. Explain rhe final activities in rhe systems design
phase
CONTENTS
I 0. 1
I 0.2
I 0.3
I 0.4
I O.S
I 0.6
I 0. 7
I 0.8
I 0.9
Architecn1re Checklist
Case in Point I 0. J: ABC Systems
The Evolution of Sysrcm Archirccrurc
Client/Server Arcbirecturc
The Impact of the lnrcrnct
E-Commerce Architecture
Case in Poinr 10.2: Small Poraroc~
Processing l\1cthods
crwork Models
Wireless Networks
Case in Point 10.3: Spider IT Services
Sysrems Design Completion
A Question of Ethics
I 0. 10 Su mmary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
I 0.1 Architecture Checklist
317
I 0.1 ARCHITECTURE CHECKLIST
At this point in the SDLC, the objecrive is ro determine an overaU architecture to
implement the information system. System architecture translates the logical design
of an informarion system into a physical structure that includes hardware, sofrware,
network support, processing methods, and security. The end product of the systems
design phase is the system design specification. If this document is approved, the next
step i systems implementation.
Just as an architect begins a project wirh a lisr of the owner's requirements, a system
analyst must consider several issues char will affect the architecture choice. This
is done with an overall architecture checklist:
• Corporate organiz.arion and culrure
• Enterpri c resource planning (ERP)
• Initial and total cost of ownership (TCO)
• Scalability
• Web integration
• Legacy system interface requirements
• Processing options
• Secu riry issues
• Corporate portals
I 0.1.1 Corporate Organization and Culture
To be successful, an information S)'Stem must perform well in a company's
organization and culture. For example, consider cwo large bicycle brands, Green Bikes
and Blue Bikes. Each firm has three operating di,·isions: an Asian subsidiary that
manufactures the bicycles, a factory in Los Angeles that produces bike accessories and
clothing, and a plant in Canada that makes bike carriers, racks, and custom trailers.
On the surface, the t\\ o fi rms are similar, bur they have very different
organ11.ations and corporate culrures. Green Bikes is highly cenrrali1ed and oversees
day-co-day operations from its Los Angeles office. Blue Bikes also has a Los Angeles
executive office hut allows its three business unirs co operate separatel)•, with minimal
corporate oversight. Both firms are successful, and it is unlikely that their managerial
sryles will change anytime soon.
Suppose borh firms asked a consultant to suggest an IT architecture that would
boost productivity and reduce costs. How might corporate organization and
culture issues affect the consultant's recommendation? l11ere is no easy answer ro
that question. The best approach probably would be to srudy day-to-day business
functions, talk ro users at all levels, and focus on operational feasibility issues, jusr as
was done earlier in the development process.
I 0. 1.2 Enterprise Resource Planning (ERP)
Many companies use e nt e rpri ~e resource planning (ERP) software to establish a
company-wide strategy for using IT chat includes a specific architecture, standards
for data, processing, nerwork, and user interface design. A main advantage of ERP is
that it describes a specific hardware and software environment, also called a platform,
which ensures connectivity and easy inregrarion of furure systems, including in-house
sofrware and commercial packages.

Chapter I 0
System Architecture
318 I 0.1 Architecture Checklist
Many companies are extending internal ERP systems to their suppliers and customers,
using a concept called supply chain management ( CM). For example, in a
totally integrated supply chain system, a customer order could cau~c a manufacturing
system to schedule a work order, which in n1m rriggers a call for more parts from one
or more suppliers. In a dynamic, highl)' competitive economy, CM can help companies
achieve faster response, bener customer service, and lower operating costs.
Oracle 1s an example of a company offering ERP solutions. A~ shown in Figure 10-1,
Oracle's ERP products are cloud-based services that support emplO)'ec collaboration,
provide access to information from mobile devices, and deliver data analytics capabilities
co gain insight into business processes.
FIGURE I 0- 1 Oracle offcn ERP solunons as a cloud-based service.
Sour«:~O
•
I 0.1.3 Initial Cost and TCO
The importance of considering economic feasibility and TCO during systems planning
and analysis was discussed earl ier. TCO includes tangible purchases, fees, and
contracts called hard costs. However, additional soft costs of mnnagement, supporr,
training, and downtime are just as important but more difficult to measure.
A TCO analysis should address tbe following questions:
• If in-house development was selected as the best altcrnarive initially, is it still
rhe best choice? ls rhe necessary technical expertise avai lable, and docs the
original cost estimate appear r ealistic?
• If a specific package was chosen in itially, is it still the best choice? Arc newer
versions or competitive products available? H ave any changes occurred in pricing
or support?
• Have any new rypes of outsourcing become available?
• I lave any economic, governmental, or regulatory events occurred that could
affect chc proposed project?
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
Phase l
Systems Design
I 0.1 Architecture Checklist
319
• Have any significanr rechnical developments occurred char could affect rhe proposed
project?
• I lave any major assumprions changed since the compan)' made the build versus
buy decision?
• Are chere an)' merger or acquisirion issues ro consider, whereby rhe company
might require comparibiliry wirh a specific environment?
• Have any new crends occurred in the markerplace? Are new products or technologies
on rhe verge of being introduced?
• Have rhe original TCO estimates been updaced? If so, are there any significanr
differences?
The answers ro rhese questions mighr affecr the initial cost and TCO for the proposed
system. The system requirements and alternarivcs should be reviewed now, before
proceeding ro design rhc sysrem architecture.
I 0. 1.4 Scalability
A nerwork is composed of individual nodes. A node represents a physical device,
wired or wireless, rhar can send, receive, or manage network data. For example,
nodes can be servers, compurers, shared printers, mass storage devices, wireless access
points, or tablets.
Scalability, somerimes also called exrensibiliry, refers co a system's ability co
expand, change, or downsize co meet the changing needs of a business enterprise.
Scalability is especially important in implementing systems char are volume relared,
such as rrans::iction processing S)'Stems. A scalable system il> necessary to suppon a
dynamic, growing business. For example, a scalable nerwork could handle anywhere
from a few dozen nodes co thousands of nodes, and a scalable DB!vlS could supporr
the ::icquisition of an enrire new sales division. When invesring large amounts of
money in a projecr, management is especially concerned about scalability issues rhar
could ::iffecr the system's life expectancy.
I 0.1.S W eb Integration
An mformation system includes applications, which are programs that handle rhe
input, manage the processing logic, and provide the required ourpur. The systems
analyst must know if a new application will be pan of an e-commerce strategy and
the degree of integration with ocher web-based components. As mentioned earlier, a
web-centric architecture follows internee design protocols and enables a company co
integrate the new application into its e-commerce strategy. Even where e-commerce is
not i1wolved, a web-centric application can run on the luterner or a company inrraner
or cxrrancr. A web-based application avoids many of the connectivity and compatibility
problems rhar typically arise when different hardware envirornncnrs arc involved.
In a web-based environment, a firm's external business partners can use standard web
browsers to import and export data.
I 0.1.6 Legacy Systems
A new system might have co interface with one or more legacy systems, which arc
older systems that use ourdared rechnology bur still are functional. For example, a
new markering information system might need co report sales data co a server-b::iscd
accounring system and obtain product cosr data from a legacy manufacturing S)' rem.

Chapter I 0
System Architecture
320 I 0.1 Architecture Checklist
Interfacing a new system wirh a legacy system involves analysis of data formats
and compatibility. In some cases, a company will need co convert legacy fil e data,
which can be an expensive and rime-consuming process. ~1iddleware, which is
di cussed later in this chapter, might be needed to pass dara between new systems
and legacy systems. Finally, to select the best architecture, rhe analyst mu~t know
if the new application eventually will replace the legacy system or will coexist
With it.
I 0. 1. 7 Processing Options
In planning the architecture, designers also must consider how the S)'Stem will process
dara: on line or in batches. For example, a high-capacit)' transacrion processing system,
such as an order entry system, requires more network, processing, and darn storage
resources than a monthly billing system that handles data in batches. Also, if the
system must operate online, 24 hours a day and seven days a week (24/7), provision
must be made for backup and speedy recovery in tbe event of system failure.
The characteristics of on.line and batch processing methods are described later in
this chapter, with examples of each type.
I 0. 1.8 Security Issues
From the simple password prorecrion shown in Figure I 0-2 ro complex intrusion
detecrion systems, security th.rears and defenses are a major concern co a systems analyst.
As the physical design is translated into specific hardware and software, the analyst
must consider security issues and determine
how the company will address rhem. Security is
especially imporrant when dara or processing is
performed at remorc locarions, rather than at a
cenrralized facility. In mission-critical systems,
securiry issues will have a major impact on system
architectu re and design.
FIGURE I 0-2 User IDs and passwords are tr:tditional elements of
syscem security.
I 0. 1. 9 Corporate Portals
Web-based systems introduce addmonal security
concerns, as critical data muse be protected in che
lnrerner environment. Also, firms that use e-commerce
applications must assure customers rhar
their pen.onal dara is safe and secure. The lamentable
number of high-profile securiry breaches in
large corporations in recent years suggest~ that
security issues should play an even larger role in
system architecture considerations. System security
concepts and strategies are discussed in detail
in Chapter 12.
Depending on the system, the planned architecture might include a corporate
portal. A portal is an entrance co a multifunction website. After entering a portal, a
user can navigate to a desrinarion using various tools and features provided by the
portal designer. A corporate portal can provide access for customers, employees,
suppliers, and the public. A well-designed portal can integrate with various other
systems and provide a consistent look and feel across multiple organizational
divisions.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
I 0.2 The Evo lut ion of System Architectur e
321
CASE IN POINT 10.1: ABC SYSlRiS
You are a systems analyst at ABC Systems, a fast-growing IT consulting finn, that provides a wide
range of services to companies that wane co establish e-commerce operations. During the past
18 months, ABC acquired two smaller finns and sec up a new division that specializes 1n SCM.
AligningABC's intemal systems was quite a challenge, and top management was not especially
happy With the integration cost or the timetable. To avoid furure problems, you have decided
to suggest an ERP strategy, and you plan to present your views at the staff meeting tomorrow.
ABC's management team is very informal and prefers a loose, flexible style of management.
How will you persuade them that ERP is the Wirf to go?
I 0.2 THE EVOLUTION OF SYSTEM ARCHITECTURE
Every business informarion sysrem musr carry our three main functions:
• Manage applications thar perform che processing logic
• Handle dara sroragc and access
• Provide ~1n interface rhar allows users ro i1ueract with the system
Depending on the archirecrurc, rhc three functions are performed on a server, on a
clienr, or arc divided berwecn rhc server and che clienr. During system design, rhc analyst
must dererminc where rhe functions will be carried our and ascertain the advanrages
and disadvanrages of each design approach.
I 0.2. 1 Mainframe Architecture
A sen er 1s a computer thac supplies dara, processing services, or other support to
one or more compurers, called client>. The earliesr servers were mainframe computers,
and a sy~rem design where che server performs all rhe processing someume~ is
described as mainframe architecture. Although che actual server does nor have robe a
mainframe, the term mainframe architecture typicalJy describes a multiuser environment
where the ~erver is significanrly more powerful than the client). A sy~tem) :inalysr
should know the history of mainfrrune architecrure ro understand the :.erver's role
in modern system design.
In the I 960:., mainfra me architecture was che 011/y choice. In addition to centralized
data processing, the earliest systems performed all data input and outpur at a
central location, often called a data processing center. Physical dara was delivered or
transmitted in some manner ro the data processirng center, where it was enrered into
rhe sysrem. Users in the organization had no input or output capabiliry, except for
printed reporrs rhat were distributed by a corpora te IT department.
As nerwork technology advanced, companies installed terminals at remote locations,
so that users could cnrer and access data from anyw here in the organization,
regardless of where rhe ccnrralized computer was locared. A terminal included a
keyboard and display screen co handle input and output but lacked independenr processing
capabiliry. In a cenrralized design, as shown in Figure 10-3, rhe remote user's
keystrokes arc cransmirred from his or her renninal to the mainframe, which responds
by sending screen outpur back co che user's screen.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I 0
System Architecture
322 I 0.2 The Evolution of System Architecture
Mainframe
Today, mainframe architecntre still is used in indusrrie~
that require large amounts of processing that can be done
at a central location. For example, a bank might use mainframe
servers to update customer balances each night. In a
blend of old and new technology, many organi1arions arc
moving some of their dara processmg off their mainframes
and into the cloud. Indeed, a mainframe can be used ro
implement part of a cloud compunng infrastruccure.
FIGURE I O·l In a centralized design. the remote user's
keystrokes are transmitted to the mainframe, which
responds by sending screen output back to the user's
screen.
Pnnter
AllUllil
Client
I
I 0.2.2 Impact of the Personal Computer
When PC tecl1nology exploded in the 1990s, powerful
microcomputers quickly appeared on corporate desktops.
Users found that they could run their own word pro·
cessing, spreadsheet, and database applications, without
assistance from the IT group, in a mode caJJed stand-alone computing. Before long,
companies linked the stand-alone computers into networks that enabled the user cli ­
ents to exchange data and perform local processing.
When an individual user works in stand-alone mode, the workstocion performs
a II the functions of a server by storing, accessing, and processing do ca, as well as
providing a user interface. Although stand-alone PCs improved employee productivity
and allowed users to perform tasks that previously required IT department assistance,
~rand -a l one computing could be inefficient and expensive. Even worse, mainraining
data on individual workscarions raised major CODCerns about data security, inregrity,
and consistency. Without a central srorage location, it was impossible to protect and
back up valuable business data, and companies were exposed ro enormous risks. In
LAN
Scanner
' Q
Client
····­
Client
FIGURE I 0-4 A LAN allows sharing of data and hardware, such as
printers and scanners.
some cases, users who were frustrated by a lack
of support and services from the IT department
created and managed their own d:nabases. In
addition co security concerns, rhis led ro data
inconsistency and unreliability.
I 0.2.3 Network Evolution
As technology become available, companies
resolved the problems of stand-alone computing
by joining clients into a local area ncl\\Ork
(LAN) that allows haring of data and hardware
resources, as shown in figure 10-4. One or
more LANs, in turn, can connect to a centralized
server. further adv;:inces in technology made it
possible to creote powerful nerworks that could
use satelUte li11ks, high-speed fiber-optic lines, or
the Internet to share data.
A wide area network (WAN) spans long
distances and can connect LANs rhat are continents
apart, as shown in Figure 10·5. \Xlhen
a user accesses data on a LAN or WAN, the network is transparent because users see
the data as if it were stored on their own workstation. Company-wide systems that
connect one or more LANs or WANs are called distributed systems. The capabilities
of a distributed system depend on the power and capacity of the underlying data
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase l
Systems Design
I 0.3 ClientlServer Architecture
323
communication network. Compared to mainframe architecture, distributed systems
increase concerns about data securiry and integriry because many individual clients
require access to perform processing.
'-ToronlO
I
I.AN
London
WAN
I
~:Jv
LAN
Brisbane
FIGURE I 0-5 A WA N can connect many LANs and link
users who are continents apart.
I 0.3 CLIENT/SERVER ARCHITECTURE
Today's interconnected world requires an information architecture that spans the
entire enterprise. Whether it's a departmental net'.vork or a multinational corporation,
a systems analyst works with a distributed computing strategy called client/server
architecture.
The term clienr/server generally refers to systems that divide processing between
one or more networked clients and a central server. In a typical client/sen·er system,
the client handles the entire user interface, including data entry, data query, and screen
presentation logic. The server stores the daca and provides data access and database
management functions. Application logic is divided in some manner between the
server and the clients.
In a client/server interaction, the client submits a request for information from
the server, which carries out the operation and responds ro the client. As shown in
Figure 10-6, the data file is not transferred from the server to the client--only the
request and lhe result arc transmitted across the network. To fulfill a request from a
client, the server might contact other servers fo r data or processing support, but that
process is transparent to the client.
cue111 submits data
query 10 ser.ier
Server 1tan&mits onto/ the
'9$uftS Of lhe client query
Q
Client
0
CINJnl
FIGURE I 0-6 In a client/server design.data is stored and usually processed on the 5enlel".
_
.........""_......-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~---- ···---~~ - .,.-"~ ........... --......

Chapter I 0
System Architecture
324 I 0.3 Client/Server Architecture
Figure I 0-7 lists some major differences between clienc/server and traditional mainframe
systems. Many early client/server systems did nor produce expected savings
because few clear standards existed, and development costs often were higher than
anticipated. Implementation was expensive because clients needed powerful hardware
and software to handle shared processing tasks. In addition, many companies had an
installed base of data, called legacy data, which was difficult to access and transport
to a client/server environment.
Comparison of Client/Server and Mainframe Systems
Characteristics ClientlServer Mainframe
Basic archHecture Very ftex1b!e Very rigid
Appl1cabon Flexible Highly structured
dollelopmont Fast Slow
Objecl -oriented
Traditional
User environment PC-based Uses terminals
GUI
Text interlace
Empowers the user Constrains the user
Improves productivity Limited options
Security and control Decentralized Centralized
fealures DifficuJt to control Easier to con1rol
Processing options Can be shared and Extensive and
configured In any form programmable
desired
Data storage Can be distributed to AU data 1s stored centrally
options
place data closer to users
1-tardWare/sottware Very l1;ex1ble Very 1191<1
1ntegrabon MultJvendor model Single proprietary 119ndor
FIGURE I 0-7 Comparison of the characteristics of d1entlserver and
rrn11nframe systems.
As large-scale networks grew more powerful, client/server systems became more
cost-effccrive. Many companies invested in clienr/server systems to achieve a unique
combinacion of computing power, flexibility, and support for changing business operacions.
Today, client/server architecture remains a popular form of systems design, using
Internet protocols and nerwork models such as the ones described later in this chapter.
As businesses form new alliances with customers and suppliers, the clienr/scrver concept
continues ro expand tO include clientS and servers outside the organization. Serviccoriented
architecture (SOA) is an example of a networked system where a service can be a
client and a server simultaneously, and it can exist ourside of corporate boundaries.
Cloud computing is seen by some observers as an entirely new concept. Others sec
it as the ultimate form of client/server architecture, where Internet-based computing
becomes the server part of client/server and handles processing rasks, while che T1nernet
itself becomes the platform that replaces traditional networks. The bottom line is
chat it doesn't marcer whether cloud computing is part of a client/server evolution or
a whole new way of thinking about computing. Eicher way, successfu l systems must
support business requirements, and system archirecnrre is an imporranr step in the
systems development process.
I 0.3.1 The Client's Role
The client/server relationship must specify how the processing will be divided between
the client and the server. A fat client, also called a chick client, design locates all or
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~- " .....- ""'*" ....,.._...,.. ..

Phase l
Systems Design
I 0.3 ClientlServer Architecture
325
most of the application processing logic at the client. A chin client design locaccs all or
most of the processing logic at rhe sen •er.
In the late 1990s, un Microsystems (now part of Oracle) was a strong advocate
of thin-client computing, which was also referred to as net-centric computing. The
thin client was a Java-powered terminal, which communicated using standard
Internet protocol~ with powerful servers. Thin cliencs were expected co provide lower
T CO, since maintenance was centralized. However, many users rebelled at the hmtted
funcnonaliry provided by thin clients (e.g., no Microsoft Office) and the latency
problems mherenr in network access to remote applications and dara. In the end, far
clients (e.g., regular PCs) remained popular, even with all their management issues
and higher T CO.
Today's l:iptop computers, cablets, and smarrphones are so powerful rhat the allure
of thin clients has mostly passed, with the exception of access to the cloud for large
datasets and specialized processing needs. The app ecosystem has also changed the
TCO equation in favor of powerful computing for clients at the edge of the system
architecture.
I 0.3.2 Client/Server Tiers
Early client/server designs were called two-tier designs. In a two-tier design, the user
interface resides on the client, all data resides on t he server., and tbe application logic
can run either on the server or on the client or be divided between the client and the
server.
Another form of client/server desit,'11, called a mree-rier design, has become more
popular. In a three-tier dcsi~ , the user interface runs on the client and the dara is
stored on the server, just as with a rwo-cier design. A three-tier design also has a
middle l:tyer between the client and server that processes the client requests and
translate!. them inm data access commands that can be understood and carried
our by rhe server, a'> shown in Figure 10-8 . The middle larer can be considered an
application \ en cr, because it provides rhe application logic, or bu ~ in c~~ logic, required
by che system. Three-tier design~ also are called 1r-rier d esign ~ . to indicate char some
designs use more than one intermediate layer.
0818
Application logic
User interface
Two-tier
Server
..,.. ____ _ _____ ,..
Cllenl
Three-tier
-- - --
Application
serwr --
- --
Client
FIGURE I 0-8 C~racteristJcs of two-tier versus three-tier client/server de$ign.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I 0
System Architecture
326 I 0.3 Client/Server Architecture
The advantage of the application logic layer is thac a three-tier design may enhance
overall performance by reducing rhe data server's workload. The separate application
logic la)'er also relieves clients of complex processing tasks. Because it can run on a
sen·cr that is much more powerful than the typical client work'itarions, the middle
layer i'> more efficient and cost-effective in large-scale sy~ems. Figure I 0-9 hows
where the data, the application logic, and the user interface are located on various
architectures. In a diem/server system, the tiers communicate using software called
middleware, as described in the following section.
Apphcat1on
User
Architecture Data Logic Interlace
Cenlral data Server x x x
processing center
Client
Central server with Server x x
--
remote terminals Client x
Sland·alone Sel'ller 1
client Client x x x
l\.vo·tier Sel'ller x x ---,
cllenVserver Client x x I
Data server x I
Three-tier
cllenVserver Application server x I
,.Client x
I
•
FIGURE I 0-9 The location ol the data. the application logic, and the user Interlace
depend on the type of architecwre.
I 0.3.3 Middleware
In a multitier system, special software called middlev.'aJ'C enables the tiers to communicace
and pass data back and forth. Middle·.vare is sometimes called glueware because it i'i
used co connecr two or more software components in a federated system archirccrure.
Middleware plays an important role in integrating legacy systems and web-based and/
or cloud-based applicarjons. !vtiddleware can also be seen a<: representing the slash in che
term clie11tlser11er.
I 0.3.4 Cost-Benefit Issues
To support business requirements, information systems need co he scalable, powerful,
and flexible. For most companies, client/server systems offer the best combination of
features co meet those needs. Whether a business is t:xpanding or downsizing, client/
server systems enable the firm to scale the system in a rapidly changing environment.
As the size of the business changes, it is easier to adjust the number of clients and
the processing functions they perform than it is to alter the capability of a large-scale
cencra I server.
Client/server computing also allows companies to transfer applications from
expensive mainframes to less-expensive client platforms, sometimes moving heavyweight
processing needs ro rhe cloud\. ln addition, using common languages such as
SQL, clients and servers can communicate across multiple platforms. Thar difference
is important because many businesses have substantial investments in a variety of
hardware and software environments.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
I 0.4 The Impact of the Internet
327
Finally, client/server systems can influence nerwork load and improve response
times. For example, consider a user at a company headquarrers who wants information
about total sales figures. In a client/server system, che server locates the data, performs
the necessary processing, and responds immediately co the client's request. The
data retrieval and proces~ing functions are transparent to the client because they are
done on the server, not the client.
I 0.3.S Performance Issues
\Xlhile it provides many ad\'ancages, client/server architecture does involve performance
is~ues that relate co che separation of server-based daca and networked clients
chat must access che data.
Consider che difference between clienc/server design and a centralized environment,
where a server-based program issues a command that is executed by the server's own
CPU. Processing speed is enhanced because program instructions and data boch travel
on an internal syscem bus, which moves data more efficiently than an external network.
In contrast co the centralized system, a clienc/server design separates applications
and data. Nerworked clients submit data requests ro the server, which responds by
sending data back to che clients. When the number of clients and che demand for
services increases beyond a certain level, network capacity becomes a constraint and
syscem performance declines dramatically.
According co IBM, the performance characteristics of a clienc/server system arc
nor the same as a centralized processing environment. Clienc/server response times
increase gradually as more requests are made, but then rise dramatically when rhe
sysrem nears its capacity. This point is called the knee of the curve, because it marks a
sharp decline in che system's speed and efficiency. To deliver and maintain acceptable
performance, system developers must anricipace the number of users, network rraffic,
:.erver size and locarion, and design a clienc/server architecture that can support current
and furure business needs.
To enhance performance, client/server systems musr be designed so the client contacts
the server only when necessary and makes as few rrips as pos~ible. This is one of
the goab of the HITP/2 prorocol used berween a server and a web brow~er.
Another issue that affecrs client/server performance is data storage. Jusc as processing
can be done at various places, data can be stored in more than one location using
a di~tributed databa\e management ~y~tem (DDBMS). Using a DDBMS offers several
advantages: Dara stored closer ro users can reduce network traffic; the sysrem is scalable,
so new data sires can be added without reworking the system design; and with
data scored in various locations, the system is less likely to experience a cacasrrophic
failure. A potential disadvantage of distributed data storage involves data security: It
can be more difficult to maintain controls and standards when data is stored in various
locations. In addition, the architecture of a DDBMS is more complex and difficult
to manage. From a system design standpoint, the challenge is that companies often
want it both ways-they want the control that comes with centralization and the
flexib il ity associated with decentralization.
I 0.4 THE IMPACT OF THE INTERNET
The internet has had an enormous impact on system archirecrure. The internee has
become more than a communication channel-many IT observers see it as a fundamentally
different environment for system development.

Chapter I 0
System Architecture
328 I 0.4 The Impact of the Internet
c ,/\
D I
8 8
FIGURE I 0-10 Cloud computing.
I 0.4. 1 Internet-Based Architecture
Recall rhar in a rradirional client/server system, rhe client handles the user interface,
a~ shown in Figure 10-9 , and the server (or servers in a mulritier system) handles
the dara and application logic. In a sense, part of che syscem run~ on che client, part
on che server. In contrast, in an Internet-based architecture, in addition co data and
application logic, the entire user ince rface is provided by che web server in the form
of HTML documents char are displayed by the client's browser. hifnng the responsib1liry
for the interface from the client co the server simplifies data transmission and
results m lower hardware cost and complexiry.
The advantages of Internet-based architecture have changed fundamental ideas
about how computer systems should be designed, and we are moving rapidly to a
coral on line environment. At the same time, millions of people arc using web-based
collaboration and social networking applications to accomplish casks that used to be
done in person, over the phone, or by more traditional Internet channels.
I 0.4.2 Cloud Computing
Cloud com puring refers to tbe cloud sy1ubol that often is used ro represent the Internet.
The cloud computing concept envisions a cloud of remote computers rhar provide
a total on line software and data environment thac is hosted by third parties. For
example, a user's computer does not perform all the processing or computing tasks-­
the cloud dues some or all of it. This concept is in contrast to today's computing
model, which is based on networks that strategically distribute processing and data
across che enterprise. In a sense, the cloud of computers aces as one giant computer
that performs rasks for users.
Figure I 0- 10 shows users connected co che cloud, which performs che computing
work. Inscead of requiring specific hardware and software cm che user's compucer,
cloud computing spreads rhe workload co powerful remote ~)'Mems chac are part of
che cloud. The user appears to
be working on a local c;ystem,
but all compuring is acrually
performed in rhe cloud. o
Cloud
sofcware updates or system
maintenance are required of the
user.
Web server
Cloud computing effectively
eliminates comparibilit)' issues,
because the Internet itself is the
platform. This architecture also
provides scaling on demand,
which marches resources to
needs at any given time. For
example, during peak loads,
additional cloud servers mighr
come online auromarically ro
support rhe workload.
Cloud com puring is an ideal
platform for powerful Software
as a Service (SaaS) applications.
As described in Chapter 7,
SaaS is a popular deployment
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
I 0.5 E-Commerce Architecture
329
method where software is nor purchased bur is paid for as a service, much like one
pays for electricity or cable TV each month. In rhis architecn1re, service providers can
easily make updates and changes ro services without involving the users.
Even though cloud computing has tremendous advantages, some concerns exist.
First, cloud computing may require more bandwidth (the amount of data that can
be transferred in a fixed rime period) than traditional clienrl erver networks. Second,
because cloud compurmg is Internet-based, if a user's Internee connecnon becomes
unavailable, the user will be unable to access any cloud-based services. In addition,
there are security concerns associated with sending large amouncs of data over the
Internet, as well as concerns about scoring it securely. Finally, there 1s the issue of
control. Becau e a service provider hosts the resources and manages data storage
and access, rhe provider has complete control of the system. Many firms are wary of
handing over control of mission-critical data and systems to a third-parry provider.
This is particularly true when the cloud provider's servers arc physically located in
another jurisdkrion or country.
Future technology advances will make cloud computing even more feasible, desirable,
and secure. As the IT industry moves coward a web-based architecture, cloud
computing is being marketed aggressively and growing rapidly. Ir has become a cornerstone
of enterprise system architecture and will continue to be for the foreseeable
future.
I 0.4.l Web 2.0
The shifc to Internee-based collaboration has been so powerful and compelling that it
has been named \Xleb 2.0. \Xleb 2.0 is not a reference to a more technically advanced
version of the current web. Rather., Web 2.0 envisions a second generation of the web
that will enable people co collaborate, interact, and share information more dynamical!)'·
Some view Web 2.0 as a stepping stone toward the semantic web, called \Xleb
3.0 b)• !>Orne, where the documents shared on the Internee have semantics (meaning)
and not just syntax (I IT.ML markup).
Social networking sires, such as Facebook, T\viner., and Linkedln, are seeing explosive
growth in the Web 2.0 environment. Another form of social collaboration is
called a wiki. A wiki is a web-based repository of information char anyone can access,
contribute to, or modify. In a sense, a wikj representS the collective knowledge of a
group of people. One of the best-known wikis is \Vikipedia.org, bur smaller-scale
wikis arc growing rapidly at businesses, schools, and other organizations thar want to
compile and share informarion.
One of rhe goals of Web 2.0 is to enhance creativity, interaction, and shared ideas.
In rhis regard, the \Xleb 2.0 concept resembles the agile development proces~ and
the open-source software movement. Web 2.0 communities and services are based
on a body of dat~1 created by users. As users collaborate, new layers of informarion
are added in an overa ll environment known as the Internet operating system. These
layers can contain text, audio, images, and video clips rhat are shared with the user
community.
I 0.5 E-COMMERCE ARCHITECTURE
The huge expansion of online commerce is reshaping the IT landscape. Internet business
solutions must be efficient, reliable, and cost-effective. When planning an e-commerce
architecture, analysts can examine in-house development, packaged solutions,
and service providers. The following sections discuss these options.

Chapter I 0
System Architecture
330 I 0.5 E-Com mer ce A rch itectu re
I O.S. I In-H ouse Solutions
Chaprer 7 descri bed how to analyze advantages and disadvantages of in-house de\'clopmenr
versus purchasing a software package. The same basic principles apply to
system design.
If a decision is made to proceed with an in-house solution, there musr be an
overall plan to help achieve the project's goals. Figure I 0-1 t offers guidelines for
companies developing e-commerce strategies. An in-house solution usually requires a
greater mirial investment but provides more fl exibility for a company that must adapr
quickl)• in a dynamic e-commerce en\'ironment. By working m-house, a company
has more freedom to inregrarc with cusromers and suppliers and is less dependent on
vendor-specific solutions.
Guidelines for In-house E-commerce Site Development
'
Analyze 1he company's busmess needs and dovelop a clear stalement ol
your goals. Consider the experienoe of other companies wllh similar
projects.
Obtain lnpu1 from users who understand lhe business and technology
Issues involved in the projecL Plan for future growth, but alm lor ease of
use.
Oe1ermme whether the rT staff has the necessary skills and experience to
lmplomenl the project. Consider tra1n1ng, additional resources, and the
use or consultants 1r necessary
Consider integration requirements for ex1st1ng legacy systems or
emerprise resource planning. Select a physical 1nfras1ructure carolully so
It will support the appt1cat1on, now and later.
Develop the project in modular form so users can lest and approve the
funchonal elements as )IOU go along
Connect the applicaooo to ex1shng in·house systems and verdy
interactivity
Test every aspect of the site exhauslively. Consider a preliminary rollout to
a pilot group to oblain feedback before a lul launch
FIGURE I 0- 1 1 G uidelines for companies developing e·commerce strategies.
For smaller companies, the decision about in-house web development is even more
critical, because this approach will require financial resources and management attention
that many small companies might be unable or unwilling to commit. An in-house
strategy, however, can provide valua ble benefits, including the fo llowing:
• A unique website, with a look and feel consistenr with the company's orher
marketing efforts
• Complete control over the organization o f the site, the number of pages, and
the size of the fil es
• A scala ble structure to handle increases in sales and producr offerings in rhe
fu ru re
• More flex ibi lity to modify and manage the site as the company changes
• The opp<irruniry to integrate rbe fi rm's web-based business systems with its
other informarion systems, creating rhe potential for more savings and berrer
customer service
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 3
Systems Design
I 0.5 E-Commerce Architecture
331
Whether a firm uses an in-house or a packaged design, the decision abour web hosting
is a separare issue. Alrhough inremal hosring has some advanrages, such as grearcr
control and security, the expense would be much greater, especially for a small- ro
medium-s11ed firm.
I 0.5.2 Packaged Solutions
If a small company is reluctant ro cake on che challenge and complexity of developing
an Internee commerce ~ire in-house, an alternati,·e can be a packaged olurion. rh1~
is crue even for medium- to large-sited firms. Many vendors, including IBM and
Microsoft, offer turnkey systems for companies thac wanr to get an e-busmess up
and running quickly, as shown 111 Figure 10-12 . For large-scale sysrems thac mu~t
integrate wirh exisring applications, packaged solutions might be less attractive.
IBM
- ---
82C and 828 commerce platform for your omnichannel business
Willl • .,...,......._._.... .._.,.._ .......,. wtl~--·
................. 9',...... , ..............,.CM.............._..,.....,._....___
~-- ZldtA a ·~ ....,............ ( I .........
...................._,............,...,_.-.r1......--
FIGURE I 0-12 IBM WcbSphere Commerce offers software solutions for companies that want to get an e-business up and
running quickly.
SoUll"C:.: I O' I WI
I 0.5.3 Service Providers
Another alternative is to use an application service provider (ASP). As explained in
Chapter 7, an ASP provides applications, or access to applications, by charging a
usage or subscription fee. Today, many ASPs offer full-scale lntcrnet business services
for companies char decide to outsource rhose functions.
A sysrcms analysr confronrs a bewildering array of producrs and strategics when
implementing Lntcrnet-bascd sysrcms. A good starring point might be to conJ.ider the
experience of other companies in the same industry. Many firms offer the names of
clients and customers, along wirh chcir success stories. Alrhough chis information may
nor be reliable, it can provide valuable knowledge regarding a vendor's products and
services.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I 0
System Architecture
332 I 0.6 Processing Methods
CASE IN POINT 10.2: S.\tALL PoTAT0 1.~s
Small Potatoes is a family-operated seed business that has grown rapidly. It specializes in supplying
home gardeners with the finest seeds and gardening supplies. Until now, the finn has done all
its business by placing ads in gardening and health magazines and taking orders using a toll-free
telephone number.
Now, the family has decided to establish a website and sell online. but there 1s some
disagreement about the best way to proceed. Some say it would be better to develop the
site on their own, and one of the employees, who is a recent computer science graduate,
believes she can handle the task. Others feel it would be better to outsource the site and
focus on the business itself. Suppose the family asked for your opinion. What would you
say? What additional questions would you ask?
I 0.6 PROCESSING METHODS
ln selecting an architecture, the systems analyst must determine which transactions
will be handled online, and what functions, if any, can be carried out using a batch
processing method.
I 0.6.1 Online Processing
Early computer systems were designed to handle data records as a group, or batch.
Fewer systems use that model today. H owever, even the most advanced online systems
must perform maintenance, post large quantities of data during off-hours when
network traffic is low, and carry out housekeeping tasks just as their legacy computer
ancestors did. This section discusses the online processing capability that is at the core
of powerful, modern systems, and the following section describes the evolution of
batch processing.
An online system handles transactions when and where they occur and provides
output directly to users. Because it is interactive, online processing avoids delays and
allows a constant dialog between the user and the system.
An airline reservations system is a familia r example of online processing. When
on line customers visit the airline's we bsite, they can enter their origin, destination,
travel dates, and rravel times. The system searches a database and responds by
displaying avai lable Aighrs, rimes, and prices. The customer can make a reservation,
enter a name, address, credit card information, and other required data, and
the sysrem creates the reservation, assigns a seat, and updates the flight datab~1se
immed iately.
Online processing also can be used with fi le-oriented systems. Figure 10-13
shows what happens when a customer uses an ATM to inquire about an account
balance. After the ATM verifies the customer's card and password, rhe customer
enters the request (Step l ). Then, the system accesses the account master file using
the account number as the primary key and retrieves the customer'i> record (Step 2).
The system verifies the account number and displays the balance (Step 3). Data is
retrieved and rhe system transmits the current balance to the AT~1, which prints it
for rhe customer.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase 3
Systems Design
I 0.6 Processing Methods 333
Online processing systems have four typical
characteristics:
1. The system processes transacrions completely
when and where they occur.
2. Users interact direct!) with the informaaon
!>ystem.
3. Users can access data randomly.
4. The information system must be available
whenever neces~ary to support business
functions.
I 0.6.2 Batch Processing
Batch processing means char data is managed in
groups or batches. That was an acccprable choice
in the 1960s, and for most firms, it was the only
choice. Today, all businesses need real-rime information
to operate, and batch processing is not
always desirable. However, batch methods can
be efficient and convenient in some siruations.
For example, batch processing can be used
for large amounts of daca rhat must be processed
on a routine schedule, such as weekly
EJ_§~j EJ :::::::::::31
ONLINE
PROCESSING
SYSTEM
CUSTOMER
FILE
ATM QUERY PROCESS
Step 1:
Step 2:
Step 3:
Customer enters his or
her account number and
requests an account
balance
Retrieves current
account balance
Verifies bank account
number and displays
balance on ATM screen
FIGURE I 0 - 13 When a customer requests a balance. the ATM
system verifies the account number. submits the query. retrieves the
current balance, and displays the balance on the ATM screen.
paychecks, daily credit card transaction updates,
or clo~ing stock data that must be calculated and published in the following da)•'s
new!> media. The advantages of batch methods include the following:
• Tasks can be planned and run on a predetermined schedule, without user
mvolvement.
• Batch programs that require major network resources can run at nmes when
costs, and impact on other traffic, will be lowest.
• A batch method is well suited to address securicy, audit, and privacy concerns,
because it runs in a relatively controlled environment.
I 0.6.3 Example
The diagram in Figure I 0-14 shows how a point-of-sale (POS) terminal, such as that
used in a supermarket, might trigger a series of onJinc and batch processing events.
Note rhat chc sysrcm uses onlinc processing to handle data entry and inventory
updates, while reports and accounring entries are performed in a batch. A company
would choose a mix of onlinc and batch processi111g when it makes good business
sense. Consider the following scenario in a typical retai l store:
• During business hours, a salesperson enters a sale on a POS terminal, which is
part of an on line system that handles daily sales transactions and maintains an
up-co-date invencory file.
• \Vhen the salesperson enters the transaction, online processing occurs. The
sy~tem performs calcularions, updates the inventory file, and produces output
on the POS rerminal in the form of a screen display and a printed receipt. At the
same time, each sales transaction creates input data for day-end hatch processing.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I 0
System Architecture
334 I 0.7 Network Models
• When rhe ~core closes, rhe system uses the sales transactions to produce che
daily 5ales report, perform the relaced accounting enrries, and ::maly1e rhe data
to idencify slow- or fasr-moving irems, sales crends, and related issue -such as
store discounrs for rhe next day.
POINT-OF-SALE (POS) PROCESSING
POS POS Sales Daily Sales Daily
Terminal -4 - ... Program Transaction Program _ .,. Sales
(Online) File (Batch) Report
t
Inventory
t
Accounllng
Files
FIGURE 10-14 Many retailel"l use a combination of online and batch processing.When a salesperlon enters the sale
on the POS terminal, the online system retrieves data from the item file, updates the quantity in stock, and produces a
sales transaction record. At the end of the day. a batch processing program produces a daily sales report and updates the
accounting system.
Online or barch processing are totally different bur can work well together. In this
scenario, an online system bandies POS processing, wbich must be done as it occurs,
while a batch mechod provides routine, overnight processing and marketing analysis.
Online processing allows tbe daca to be entered and validated immediately, so the
informarion always is up ro date. However, a heavy volume of online transaction~ can
be expensive for smaller firms, and data backup and recover)' also add to IT costs. In
contrast, when used properly, bacch processing can be cost-effective and less vulnerable
to system disruption.
I 0. 7 NETWORK MODELS
A network allows rhe sharing of hardware, software, and data resources in order
co reduce expenses and provide more capability co users. When planning a network
design, chc sysccms analyst must consider network terms and concepts, including the
OSI model, network modeling tools, network topology, network protocols, and wireless
networks, which arc covered in rhis secrion. Other imporranc issues, such as nccwork
performance and security, arc covered in Chapter 12.
10.7. 1 The OSI Model
The discussion of system architeccure earlier in this chapter already inrroduced basic
network terms such as client, server, LAN, WAN, clienr/scrver architccrurc, cicrs, middlcwarc,
and cloud computing. To fully understand how nerworks are configured, che
Open Sy~rcm~ Interconnection (OSI) model should also be understood. The OSI model
describes how data moves from an application on one computer to an applicarion on
anorher nenvorked compuccr. The OSI model consists of seven layers, and each layer
performs a specific function. The OSI model provides physical design srandards rhar
assure seamless nerwork connectivicy, regardless of che specific hardware environmcnc.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 3
Systems Design
I 0.7 Network Models
335
10.7.2 NetworkTopology
The way a necwork is configured is called the net\>.'ork copology. Topology can
refer co a physical or a logical view of che network. For example, phy~ical copology
describes che actual network cabling and connections, while logical copology
describes che way the components inceract. le is importanc to understand the
disnncrion, because a specific physical topology might be able co support more than
one logical topology. For example, it is noc uncommon to run cabling in a certain
pauern because of physical installation and cosc issues but to use a different partern
for the log1cal topology.
Compucers may be physically arranged in a circular shape, but that mighc or might
not reflect che network topology. The examples shown in Figures 10-15 to 10-19
represent a logical copology, as seen by network users, who may not know or care
about che physical cabling panern.
LAN and WAN networks cypically arc arranged in four patterns: hierarchical, bus,
ring, and star. The concepts are the same regardless of the size of the network, but the
physical implementation is different for a large-scale WAN that spans an entire business
enterprise compared with a sma ll LAN in a single department. These four common
topologies arc described in the following sections.
HIERARCHICAL NETWORK: Jn a hierarchical network, as shown in Figure 10- 15,
one or more powerful servers control the entire nerwork. Departmental servers control
lower levels of processing and network devices. An example of a hierarchical network
might he a retail clothing chain, with a central computer rhac store& data about
sales activity :ind inventory levels and local compucers char handle ~core-level operations.
The ~tore:. tran:.mit data co the central computer, which analyze~ ~ales trend~,
detennine~ optimum stock levels, and coordinates a SCM system. In chis l>ituacion, a
hierarchical network might be used, because it mirrors the acrual operational flow in
the organizanon.
--
FIGURE 10- 15 A hierarchical network with a single server that controls the network.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter I 0
System Architecture
336
I 0.7 Network Models
g
PC
-
g
PC
~B>--~~--~
Termnals U PC
Q - - -
PC Ci} Ci}
s
~/
FIGURE I 0-1 6 A bus network with all the devices
connected to a single communication path.
PC
Oepartmon1a11etver
Te1mina1s
g
PC
FIGURE I 0-17 A ring network with a set of computers that
sends and receives data flowing In one d1rect1on.
One disad,·antage of a hierarchical network is that if
a business adds additional processing levels, the network
becomes more complex and expensive ro operate
and maintain. Hierarchical networks were often
used in traditional mainframe-ba<;ed S)'Stems but are
less common today.
BUS NETWORK: In a bu~ net\\ Ork, as shown m
Figure 10-16 , a single communication path connects
cbe central server, departmental servers, workstations,
and peripheral devices. [nformation is transmirted
in either direction between networked devices, and
all messages travel over the same central bus. Bus
networks require less cabling than ocher topologies,
because only a single cable is used. Devices can also be
attached or detached from the network at any point
without disturbing the rest of the network. Jn addirion,
a fa ilure in one workstation on the network does nor
necessarily affect other workstations on the network.
O ne major disadvantage of a bus network is that
if rhe central bus becomes damaged or defective, the
entire network shuts down. Anorher disadvantage is
that overall performance decl ines as more users and
devices are added, because all message traffic must
flow along the central bu~. This does nor occur in the
treelike srruccure of a hierarchical nerwork or the huband-spoke
design of a star network, where nerwork
paths are more isolated and independent.
The bus nerwork is one of the oldest LAl ropol·
ogies and is a simple way co connect mulriple work·
scarions. Before the proliferation of scar nerworks,
bus networks were very common. They share char·
acceriscics of hardware bus nerworks. Today, che bus
design is less popular, but some fim1s have retained
bus networks co avoid the expense of new wiring and
hardware.
RING NETWORK: Although ring networks arc
st ill around, they are somewhat outdated. rBM
was a leader in ring network technology when they
introduced their token ring LAN, and large companies
who use [BNl mainframe equipment sti ll deploy the
ring network design. A rinA network, as shown in
Figure L0-17 , resembles a circle where the data flows
in only one direction from one device to the nexr. In
function, a ring network can be thought of as a bus
network with rhe ends connected. One di~advanrnge
of a ring network is that if a network device (e.g.,
a PC or a server) fails, the devices downstream from the foiled device cannot
communicate with the network.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 3
Systems Design
I 0.7 Network Models
337
STAR NETWORK: Because of its speed and versatility,
the star network i a popular LAN topology.
A ~tar network has a central networking device
called a switch, which manages the network and
acts a~ a communications conduit for all network
traffic. In the past, a device known as a hub was
used to connect star ncrworks, but a switch offers
advanced technology and much better performance.
A hub or switch functions like a familiar
mulnsocket power strip but with network devices
such as servers, workstations, and printers plugged
in rather than electrical appliances. The hub broadcasts
network traffic, called data frames, to all
connected devices. In concrasr, a switch enhances
network performance by sending traffic only ro
specific network devices that need co receive the
data.
A star configuration, as shown in Figure 10-18,
provides a high degree of network control, because
all traffic flows into and our of the switch. An inherent
disadvanragc of the srar design is rhar rhe entire
Oepartmenllll
~nner
FIGURE I 0-18 A star network with a switch, departmental server,
and connected computers and devices.
network is dependent on the switch. However, in most large star networks, backup
switches arc available immediately in case of hardware failure.
MESH NETWORK: In rhe me~h network shown
in Figure I 0-19 , each node connects to every other
node. While this design is extremely reliable, it also
is very expensive to install and maintain. A mesh
network resembles the lnrerner in that a message
can travel on more than one path. Originally
developed for military applications, the primary
advantage of a mesh ncrwork is redundancy,
because multiple paths provide backup if
communication problems arise or some nodes
become inoperable.
I 0. 7 .3 Network D evices
Nerworks such as LANs or W'ANs can be interconnected
using devices called rourers. A router is a
device thar connects network segmen rs, determines
the most efficienr data path, and guides the flow of
data.
Ci:
I
~.m~
Switch
/; ·~
I ~M•
.,... ~
• 4-------~
Pnnter
PC
•
FIGURE I 0-19 A mesh network is used In situations where a
high degree of redundancy is needed. such as military applications.
The redundant design provides alternate data paths but is
expensive to Install and maintain.
Using a router, any network topology can connect to a larger, dissimilar network,
uch as the Internet. This connection is called a gateway. The example in Figure 10-20
show a star topology, where a switch connecrs nodes in rhe LAN and the router links
the network to the Internet. A device called a proxy server provides Internet connectivit}'
for internal LAN users. The vast majoriry of business nerworks use routers to
integrate che overall network archirecmre.

Chapter I 0
System Architecture
338
I 0.8 Wireless Networks
Departmental
server
1i1,~ I ~
1i1 ~ ,,_~
1i1 / ~ "'~'
0 Q
PC
PC
Proxy server
Router
Internet
FIGURE I 0·20 Routers can be used to create g:iteways between different network topologies and large. dissimilar networks such as che
Internet.
I 0.8 WIRELESS NETWORKS
Alrhough a wired LAN provides enormous nexibility, the cahling cost can be substantial,
a~ well as the inevirnble wiring changes char occur in a dynamic o rganization.
~!any companies find wireless technology co be an arrracrive alternative. A " i rele~~
local area ncrnork (\VLAN) is relatively inexpen~ive co install and is well suited co
workgroups and users who are nor anchored co a specific de~k or location. ~l ose
notebook computers and other mobile devices are equipped with huilt-in wireless
capability, and it is relatively simple to add this fearure to exi ting desktop computers
and workstations in order co sec up a wireless network.
Like their wired counterparts, wireless networks have certain :.tandards and ropologie~,
which are discussed in the following seccions.
I 0.8. 1 Standards
Wireless networks are based on various standards and protocols that still arc evolving.
The mosr popular of these is called IEEE 802.11, which is a family of standards developed
by the Institute of Electrical and Electronics Engi11ccrs (IEEE) for wireless LANs.
Current wireless networks are based on variations of the original 802. 11 standard.
Severa l versions, or amendments, were intended to improve bandwidth, range, and
security. The IEEE 802.11 set of standards changes very rapidly, in large pare due to
pressure from consumer groups and industry leaders moving toward ever-fasrer wireless
nerworks. Wireless network speed is measured in megabits per second (M bps) or
gigabits per second (Gbps).
For example, when the 802.llb standard was introduced in 1999, rhe average
speed was I I I bps. Larer versions, such as 802 .1 l g and 802.11 n, increased bandwidth
to 54 Mbps and 450 Mbps, respeccively, and were widely accepted by rhe
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. . ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 3
Systems Design
I 0.8 Wireless Networks
339
IT industry. Current standards, such as 802.1 l ac, can theoretically reach speeds of
nearly 7 Gbps. The increased speed is accomplished using multiple input/multiple
output (MIMO ) technology to boost performance. MIMO relies on mulciple data
paths, also called multipath design, to increase bandwidth and range.
If wirelesc; capacity continuec; to expand and security issues can be overcome,
\'VLANs could replace wired networks in man)' situations. \'Vireless security is discussed
in detail m Chapter 12.
I 0.8.2 Topologies
Like wired networks, wireless networks also can be arranged in differenc topologies.
The rwo most common network topologies available for IEEE 802. I I WLANs are
the Basic Service Set and the Extended Service Sec. Figure J0-21 shows simplified
models of these topologies.
The Basic Service Set (BSS), also called the infrastructure mode, is shown at the
top of Figure 10-2 1. In this configuration, a central wireless device, called an access
poiJlt or wireless access point (WAP), is used to serve all wireless clients. The access
point is similar to a hub in the LAN star topology, except it provides network services
to wireless clients instead of wired clients. Because access points use a single communications
medium, the air, they broadcast all traffic to all clients, just as a hub would
do in a wired network. Typically, the access point itself is connected to a wired network,
so wireless clients can access the wired ae~vork.
The second wireless topology is the Extended Service Set (ESS), as shown at the
bottom of Figure I 0-21. An ESS is made up of two or more BSS networks. Thus,
using an ESS topology, wireless access can be expanded over a larger area. Each access
point provides wireless services over a limited range. As a client moves :iway from one
access poinr :ind closer to another, a process called roaming automatically allows rhe
client to associate wich the srronger access point, allowing for undisrupted service.
I 0.8.3 Trends
\Vireless cechnology has broughr explosive change co the IT industry and will concinue
co affect businesses, individuals, and societ)·. Even in the ever-changing world of
IT, it would be difficulr ro find a more dynamic area than wireless technology.
With the growing popularit)' of 802.1 1, many firms offer networking products,
services, and information. One of the most significant groups is the \Vi-Fi Alliance,
which maintains a website at www.wi-fi.org. According to che site, the Alliance is a
nonprofit international associ:ition formed in 1999 to certify interoperability of wireless
network produces based on IEEE 802. I J specifications. Products that meet the
requirements arc certified as wireless fidelity (Wi-Fi) compatible. The stated goal of
the Wi-Fi Alliance is to enhance the user experience through product interoperability.
Even though they have many advantages, wireless networks also have limitations
and disadvantages. For example, devices that use the 2.4 GHz band can pick up interference
from appliances such as microwave ovens and cordless telephones that use the
same band. More imporranr, wireless nerworks pose major security concerns because
wireless transmissions arc much more susceptible to interception and intrusion than
wired networks. These issues are discussed in detail in Chapter 12.
ln addition co \Xii-Fi, another form of wireless transmission called Bluetooth is very
popular for short-distance wireless communication that does not require high power.
Examples of Bluerooth devices include wireless keyboards, mice, printers, cell phone
headsets, and digital cameras, among others. People with Bluetooth-equipped phones
or tablets can even beam information ro each other and exchange digital notes.

Chapter I 0
System Architecture
340
I 0.8 W ireless Networks
.. -
i:J ... _ ·--- ··~- ~ --· - :. --
•
-~ .............
....
n
0
...
•
-
...
n
•
- ~·>
-
(Cc~
FIGURE I 0-21 The user in the upper sc:reen has moved out of the BSS
c:overage area and cannot communicate. In the lower sc:reen, the user roams Into
another ESS coverage area and the transition is seamless.
CASE IN POINT 10.3: S1 1 IDER IT SER\'ICLS
Spider IT Services specializes in cuscom network design and installation. Firms hire Spider to
do an overall analysis of their network needs, including a detailed cost-benefit scudy. Recendy,
a problem arose. One of Spider's clients complained that the relatively new network was too
slow and lacked sufficient capacity. Reviewing the case, Spider's top management realized that
the rapidly growing client had simply outgrown the network much earlier than anticipated. How
could this problem have been avoided?
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase l
Systems Design
I 0.9 Systems Design Completion
341
I 0. 9 SYSTEMS DESIGN COMPLETION
System architecture marks the end of the systems design phase of the SDLC. Recall
that in the systems analysis phase, all functional primitives were identified and documented
with process descriptions. The objective then was to identify the system's
functions and determine what each logical module would do, without actempring to
determine how that function would be carried our. ~1oving from analysis to design
tasks, the development process continued wirh consideration of output and user
interface design, dara design, and sysrem architecrure issues. Now, based on a clear
definition of system requirements and design, software applications can be developed,
documented, and reseed as parr of the systems implementation phase of the SDLC,
which is described in Chapter 11.
Developers must also consider system management and support cools that can
monitor system performance, deal with fau lt management, handle backup, and provide
for disaster recovery. These topics are covered in detail in Chapter 12.
The fina l activities in the sysrems design phase are preparing a system design specification,
obtaining ui.er approval, and delivering a presentation to mnnagement.
I 0. 9. I System Design Specification
The system design ~pecifiCltion is a document that presents the complete design for
the new information system, along with detailed costs, staffing, and scheduling for
completing the next SDLC phase-systems implementation.
The system design specification is the baseline against which the operational system
will be measured. Unlike the system requirements document, which is wrirten for
users to understand, the system design specification is oriented toward the programmers
who will use it to create the necessary programs. Some sections of the system
requirements documenr are repeated in the system design specificarion, such as process
descriprions, data dicrionar)• enrries, and data flow diagrams.
The system design specificarion varies in lengrh, so it should be organized carefully.
One rypically includes a cover page, a detailed table of contents, and an index.
The contents of the system design specification depend on company standards and
the complexity of the system. A typical system design specificarion includes rhe following
sections.
I. Management summary. TI1is is a brief overview of the project for company
managers and executives. It outlines the development efforts to dare, provides a
current status report, summarizes project costs, reviews the benefits of the new
system, presents the syscems implementation schedule, and highlights any issues
that management will need to address.
2. System c<>mponents. This section contains rlie complete design for the new
system, including the user interface, outputs, inputs, fi les, databases, and ncrwork
specifications. Sou rce documents, reporr and screen layouts, DFDs, and a ll orher
relevant documentation should be included. Jn addition, the requirements for all
support processing, such as backup and recovery, start-up processing, and file
retention should be included. If the purchase of a software package is part of the
strategy, include any interface information required between the package and the
system being developed. If a CASE design tool is used, design diagrams and most
other documentation can be produced directly from the tool.
3. System e11viro11me11t. This section describes the constraints, or conditions,
affecting the sysrem, including any requirements that involve operations, hardware,
systems sofrware, or security. Examples of operational consrramts include

Chapter I 0
System Architecture
342 I 0.9 Systems Design Completion
transaction volumes thar muse be supported, data storage requirements, processing
schedules, reporring deadlines, and online response rimes.
4. lmpleme11tation req11ire111e11ts. In chis secrion, scare-up processing, initial data
enrry or acquisition, user craining rcquiremenrs, and software tesr plans arc
specified.
5. Time and cost estimates. This section provides derailed schedules, cost esri·
mates, and sraffing requiremears for the systems development phase and
revised projections for the remainder of the SDLC. Toral cosrs-ro·date for the
project and a comparison of those costs with prior esrimates are also presented.
6. Additional material. Other material can be included at che end of the sysrem
design specificarion. In this section, docu1nents from earlier phases can be
inserted if rhey would be hclpfuJ ro readers.
I 0.9.2 User Approval
Users must review and approve the interface design, report and menu designs, data
entry screens, source documents, and ocher areas of the system th<H affect them. The
review and approval process continues throughout the systems design phase. When
the design for a report is complete, the systems analyst should meet with users to
review the protorype, adjust the design if necessary, and obtain wricten approval.
Chapter 8 contains guidelines and suggestions about report design.
Securing approvals from users throughout the design phase is very important.
Thar approach ensures char a major task of obtaining approvals is nor left to rhe end,
it keeps rhe users involved with the system's development, and ir provides feedback
about wherher or nor the project is on target. Some sections of rhe sysrem design
specificarion might not interest users, bur anything rhar docs affect them should be
approved as early as possible.
Ocher IT deparrmenr members also need to review the system design spccificarion.
IT management will be concerned with staffing, costs, hardware and sysrems somvare
requirements, network impact, and the effect on the operating environment when
the new system is added. The programmjng team will want co get ready for its role,
and rhe operarions group will be inreresred in processing support, report distribution,
nerwork loads, integration with other systems, and any hardware or software issues
for which they need to prepare. As a lways, a systems analyst must be a good communicator
co keep people up to dare, obtain their input and suggestions, and obtain
necessa ry approvals.
When rhe system design specification is complete, the document is disrribured to a
rargec group of users, IT deparonent personnel, and company management. Ir should
be distributed at lease one week before a presentation to allow the recipients enough
time to review che material.
I 0.9.3 Presentations
Usually, the systems analyst will give severaJ presentations ar the end of the systems
design phase. The presentations offer an opportunity to explain the system, answer
question~, consider comments, and secure final approval.
The first presencation is to the other systems analysts, programmers, and rechni·
cal support staff members who will be involved in future project phases or operational
support for the system. Because of the audience, the presenration is rechnicall>•
oriented.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 3
Systems Design
10. 10 Summary
343
The nexr presenrarion is to department managers and users from departments
affected by the sy rem. As in the first presentation, rhe primary objective is to obtain
support and approval for the systems design. This is nor a technical presentation; it
is aimed ar user inreracrion wirh rhe system and management's interest in budgers,
schedules, staffing, and impact on the producrion environment.
The final presentation is delivered ro managemenc. By the rime rhis presenrarion
is delivered, all necessary approvals should have been obtained from prior presenranon
, and the users and IT department should be on board. Jusr like the managemenr
presentation at rhe end of rhe systems analysis ph ase, this presenranon has a key
objecnve: ro obrain management's approval and support for the next development
step-systems implementarion-including a solid commitment for financial and other
resources needed.
Based on rhe presentation and the data subniitted, management might reach one of
three decisions: proceed with systems development, perform additional work on the
systems design phase, or terminate the project.
The new accounting system is operational, but feedback from users has been negative.
The most common complaint is chat the system is not user-friendly. Some people in the
IT department think that more user training would solve the problem. However, the IT
manager is opposed to a fresh round of training. "Let's just set up the network to monitor
the users' keystrokes and mouse clicks, and see what the patterns are," he suggested. "We
can analyze the data and come up with tips and suggestions that would make the system
easier to use."
Your initial reaction is chat the IT manager is wrong for two reasons. First, you believe
that monitoring would not be an effective method to learn what users really want. In your
view, that should have been done in the system requirements phase. Second. you are bothered
by an ethical question: Even though the proposed monitoring would involve company
business, the company network, and company time, you feel chat many users would resent
the unannounced monitoring and might feel that their performance or other computing
activities were being appraised without their knowledge.
The IT manager has asked to you to write up a recommendation. What will you say
about the ethical question chat troubles you!
I 0.10 SUMMARY
An information system combines hardware, software, data, procedures, and
people into a system architecture. The architecture translates the system's logical
design into a physical srrucrure that includes ha rdware, software, and processing
methods. The software consists of application programs, also called applica tions,
which handle rhe input, manage the processing logic, and provide the required
output.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter I 0
System Architecture
344 I 0.10 Summary
Before selecting a system archirecrure, rhe analyst must consider FRP, initial cosr
and TCO, scalabiliry, web integration, legacy interface requirements, processing
options, sccuriry issues, and corporate portals.
ERP c tablishes an enterprise-wide strategy for IT resources and specific
srandards for dara, processing, network, and user interface design. Companies can
extend ERP sy terns to suppliers and customers in a process called SCM. A systems
analyst must assess initial cost and TCO and ensure that the design is scalable.
Scalability means that a system can be expanded, modified, or downsi1ed easily
to meet business needs. The analyst also musr consider 1f the system will be webcentric
and follow Internet design protocols and if ir musr interface with existing
S)'Stcms, called legacy systems. Sysrem security is an imporranr concern throughout
the design process, especially for e-commerce applications that involve credit card
and personal data. Processing options affect system design and resources required.
The planned architecture can include a corporate portal that is an entrance to
a multifunction website. Corporate portals can provide access for customers,
employees, suppliers, and others.
A system architecture requires servers and clients. Servers arc computers that
supply data, processing services, or other support to one or more computers called
clients. In mainframe architecture, the server performs all processing, and terminals
communicate with the centralized sysrem. Clients can be connected in distributed systems
to form LANs or WANs.
Client/server architecture divides processing berween one or more clients and a
central server. In a typical cliear/servcr system, the client handles the entire user interface,
including data entry, data query, and screen prescnrarion logic. The server stores
chc dara and provides dara access and database managemcnc funccions. Applicacion
logic is divided in some manner between che server and rhe clients. In a rypical client/
server inreracrion, che client submits a request for informarion from the server, which
carries our the operation and responds to the client. Compared to file server designs,
clienr/~erver systems are more scalable and flexible.
A fat, or thick, client design places all or most of the application processing
logic at the client. A thin client design places all or most of the processing logic at
the server. Compared with mainraining a cenrral server, TCO for fa1 clients can be
higher than for thin clients because of initial hardware and sofcware requirements
and the ongoing expense of mainraining and updating remote client computers.
However, the foe clienl design may be simpler to develop, because the architecture
resembles rradi1ional file server designs where all processing is performed at the
client.
Client/server designs can be rwo-tier or three-tier (also called 11-tier). In a two-
1ier design, the user interface resides on the client, all data resides on the server,
and the application logic can run eit11er on the server or on rhe client or be divided
between the client and the server. In a three-tier design, the user interface runs on the
cl ient and rhe data is stored on the server, just as with a two-tier design. A three-tier
design also has a middle layer between the client and server char processes the client
requests and translates them into data access commands that can be understood and
carried out by the server. T he middle layer is called an application server, because
it provides the application logic or business logic. Middleware is software that
connects dissimilar applications and! enables them ro communicate and pass data.
In planning the system design, a systems analyst also must consider cost-benefit and
performance issues.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __....................... ~~·~---- ···---~~ - .,.-"~...........--......
Phase l
Systems Design
I 0.10 Summary
345
The Internet has had an enormous impact on system architecture. In implementing
a design, an analyst should consider e-commerce architecture, the availabiliry of
packaged solutions, and service providers. The anal)'St also should understand the
concepts of cloud computing and \Veb 2.0, which are shaping the future of Internet
computing. Cloud computing u~es a cloud symbol co represent the Internee. The
cloud, which is transparent to u er , provides a hardware-independent environment
where remote server<; handle all processing and computing functions, and the lnremer
irself replaces traditional nerworks. \Veb 2.0 refers co a new generation of the web
thar encourages people co collaborate, interact, and share information more dyn::imically.
Web 2.0 1s fueling rhe explosive growth of social networking and group-based
commun1canons.
The mosr prevalent processing method today is online processing. Users interact
directly with on line systems th::it continuously process their transactions when and
where they occur and conrinuously update files and databases. In contrast, batch systems
process transactions in groups and execute them on a predetermined schedule.
Many online systems also use batch processing co perform routine tasks, such as handling
reports and accounting entries.
Networks allow the sharing of hardware, software, and data resources in order to
reduce expenses and provide more capability to users. T he network is represented by
a seven-layer model called rhe OSI model.
The way a network is configured is called the network topology. Nerworks typically
arc arranged in five patterns: hierarchical, bus, ring, star, and mesh. A single
mainframe computer usually controls a hierarchical network, a bus nerwork connects
workstations in a single-line communication parb, a ring network connects workstations
in a circular communication path, a star nerwork connects worksrarions to a
central computer or networking device called a s'vitch, and a mesh nerwork connects
every network node to every other node. Wireless networks, or \X'LANs, based on
IEEE 802. I I standards, have seen explosive gro,vth, especially in situations where
the flexib1liry of wireless is important. The IEEE 802.1 lac standard uses 1\ill~I O, or
multipath rechnolog)', which has increased wireless network speed and range. \X'LANs
ha,·e two major topologies: BSS and ESS. Although wireless networks are very popular,
they do have some limitations and disad\•antages, includ111g interference and secunry
concern~.
The system design specification presenrs the complete systems design for an information
~yscem and is the basis for the presentations that complete the sy~tem~ de~ign
phase. Following the presentations, che project either progresses to the systems development
phase, requires additional systems design work, or is terminated.

Chapter I 0
System Architecture
346 Key Terms
Key Te rms
802.11 A famil) of wireless network specifications developed by 1he ll'fl:..
802.1 lac An IEE.I:. wireless network specification, appro,·cd in 2014, that uses c,p.mdcd MIMO technol·
og) to ach1e\e rheoreucal speeds of nearlf ~Gbps \\bile incrcasrng the wireless range and i> backward
companblr w1rh 802.1 la, b, g, and n.
802.11 b An IFEE w1rdc.,, network 'pcoficatton 1111roduced 111 1999 ha"4:d on a fn:c.iue119 of 2.4 Cliz
and maximum handwidrh of 11 Mbp>. Replaced by 802.1 lg.
1!02. I lg \n IFFf. wircle<.• network 'l>Ceification inrroduccd in 200.l ha\cd on a frequency of 2.4 C.H1
and maximum handwidrh ot 54 Mbps; compatible with and replaced 802.11 h, and ha' hcen super·
-eded hy the 802.11 n \londard.
802.l ln An ILEE wireless nerwork specification :idopred in 2009 1h.1t uses J\UMO 1echnology 10 achieve
speeds of 200+ Mbps wlule increasmg rhe wueless r.inge and LS backw.1rd companble wuh 802.1 la, b,
and g.
accc~~ point A ccnrral wireless dC\'1ce rhar provides nerwork services ro wircles~ cl1ems.
ap1llicarion Pnrt of rhe infonnarion sy,tcm, an application handles rhc mpur, mnnnµcs rhc procc"ing
logic, and provides rhe required ourpur.
appli"uion logic The underlying blLsiness rules or logic for an application.
application scf\cr A cornpurer acring as "middlemen" between customers and an organizltion's da1a·
bases and .tpphc:uions. Ofren used to facilit.ire complex business lt'.lllSJCtlons.
b.ind" idtb lbe amoum of data that 1he system can handle in :i fixed ume penod. Bandwidth reqwre·
menrs are expressed tn bus per second {bps).
Ba\I< 'icn ice \<I (B<,'il A wirdcs' ncrwork configuration in wh11:h a central wtrdc'' dcv1<:c called an
a4'.ccss point is uS<"d ro 'iCrve all wfreless clienrs; also called infrastrunure mode.
Bluctnoth \ form of wireless rransmission ,-ery popular for short·di,tancc w1rclc" communication thar
doc' nor require high power.
bu$ nel\\Ork A computer nerwork where a single communication path connect) the mJinframe computer,
server, worh1a11olb, and peripheral devices. loformauou is rr:l.lbmmed m either dtre.:tion from an)
works1anon to another worksraaoo, and any message can be ducc1cd 10 J sprc1f1c de\ICC.
bu\incs> logic Rules reflecrmg the operational requuemenrs of the busmess that determme how a S)·s1em
handles data and produces useful information. E.xamples include adding 1he prop<'r .imoum of sales
tax 10 invoices, calcuforing customer balances and finance charges, and determining whether a cus-
1omer is eligible for a \ olwue-bascd discount.
cl1cn1 \Vork..ia1ion 1ha1 u~crs interact within a client/server de>ign. The": work~tation,, <>r ~ompucer\, arc
'upplicd da1a, procc,>ing scrv1<;cS, or other support from other compu1cr>, 'ailed .,ervcr\.
cl1cn1/,crvcr architecture Generally refer., to systems that divide procc~;,IDJI between one or more net·
worked dienr~ nnd a cenrral ~erver. In a typical client/ server system, rhc dicnr handlc5 rhc entire user
imerfoce, including dnrn cnrry, darn query, and screen prc~enrnrion logic. The ~crvcr ~rorc~ the dnrn
and provides da1a access and database managcmcnr functions. Applicniion logic is divided in some
manner between the ~crvcr and the clients.
corporate ponal A website rhat provides V•triou; tools and fe.itures for .Lil orgnnitauon's customers,
employees, ~upp l icrs, .tnd the public.
d.ita frame~
rrJff1c 0 1 a compurer network.
dara procC\\ing center A ccnrral location where physical data was delivered or trJnsmined in ~ome man·
ncr and entered inro rhe 5ystem. Uo;ers in rhe organi7.at1on had no input or ourpur capabihry, except
tor primed reporrs that \\ere distributed by a corporate IT dcp.inmcn1.
d..,mhu1cd dat.iha•c management >t>lcm !DDB.\.tS) A S)Stcm for managing dat.1 >lorcd .11 more than one
l<><:.mon. U;mg a DDB~S offer~ several advantage;,; Dat.i >1orcd do>er 10 users can reduce nc1work
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Key Terms
Phase l
Systems Design
347
traffic; the sysrem 1s sc.1lable, so new dara s11es can be added without reworking the system design;
and with dat.1 stored in \'Jrtous locanons, the system is less likely to experience a car.1Stroph1c failure.
A potcnnal d1sad"amage of d1smbutcd data storage in"olves data security. Lt can be more difficult to
m.llnwm ~omrob and M.mdards "hen data is stored in various loc.uioos.
dLStnbutcd system C.ompan)'"" 1de S)Stcms th,tt are connecred by one or more LANs or \\IA..'-s. lbe
capab1L1th of a d1smbu1cd system depend on the power and capacity of the underl)mg data communicatton
network.
cntcrpriw rc\ource plannin11 (ERP) \ proces~ that establishes an emerprio;e-wide ~tratq,')' for IT
re-.our~c\. ERP defines a 'pet:ific ar.:hitecrure, including scandard.' for data, proces>mg, network, and
U\er 111tcdac:e dc'>l)\11.
[xtendcd Service \cl (E.\S) A wircle" nc1work configuration made up of rwo or more BSS nc1worh,
which nlluw' wircle" client• to roam from RSS to BSS.
c"tcn,ibil11y Refer\ mo ')'Mcm'• nbility m expand, change, <>r downsize ea~ily to meet the chnnging
need' of a bu~inc'' cmcrpri,c. Also known as 'calability.
for diem A network design drn1 locMes all or most of the application processing logic at the client. Also
c.1lled a truck client design.
gatewa) ( 1) lo business process mg modeling notation, a fork in the process. allo" mg the flow to go one
w.t) or .rnother. (2) A router or other nerwork device used to connect to a larger, d1ssin11lar rypc of
network. such .is the lntcruet.
gigab1ts per second tGbps) A bandwidth or throughput measurement.
glueware Su middlew:irc.
hicrarcharnl nctnork A network Jc,ign where one compurer <rrpicallr a m:tinframe) control; the entire
nemor~. 'ia1cll1tc computer\ or 'ervcn, control lower levels of procc~ml\ and network devic:c,.
HlTP/2 The \CCOnd ma1or \'Cl'\ion or the network protocol used by the web. Rdca,cd '1\ :I 'tandarJ 1n
2015.
hub The center of a star network. Switches in modern nerworks ba\e large!> replaced hubs.
infrJstructurc mode A wireless network configuration in which a central wireless dencc called Jn access
polllt is used to sen e all wrrele~s clients; al>o called BSS.
lruutute or Lle•trical and tlectronics Engineers (1.£IT} A profess1on.1l Of!rauuatton that ~1abhshes srandard,
for tcle<:ommunic:arion•.
Internet npcr:llanjl 'Y'ICm Parr of the Web 2.0 model, an on line compunng environment created by
onlinc communitie• and services, bao;cd on layer• of shared inforn1arion that can contain rcxc, 'mmd
hrte!>, image-., and video clap•.
knee ur 1hc L'Ur\c t\ t)crformance char.1cccriscic of a clienc/~rver computing environme111. Clicnlf~cr•cr
rc,pon~c time' 1cnd IO incrcao;e gradually and then rise dramatically a> the system nears 1r' capacity.
The point where response rimes increase dramatically.
legacy da1a The d<1ra associated with an older, less technologically advanced legacy sysrem.
lcgaC) ~y~tcm Term used to describe older systems that are rypically less technologically advanced than
currently Jvailable s)>rems.
local area ocl\,otk (LAN) A ncrwork design chat allows the sharing of data and hardware, ~uch n; printers
.111d ;•anner;,. Advan,es 1n dJt:t commumcanon 1eclmology ba\e made ar po;;1ble to create powerful
nerworks 1h.11 u~ ~tell1te link~, high-speed fiber-opric lines, or the lntemer to ~hare data.
logical topolORY I\ view ol .1 nc1Work rhac describes rhe way rhe components inreract. rather than the
actual nerwork cabling and connecrions.
mainframe archatc•ture A system Jc.ago where chc server performs all rhe proces;ing.
m~abll\ per ~ccond ( \lbp, A band\-.Jtb or throughput mcasllremcnt.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter I 0
System Architecture
348 Key Terms
mc\h nemork A ne"•ork design in "hich each node connects m c•ery ocher node. \X'hilc this design is
\Cl) rcltable.111s abo expensl\e to install and main!allL
m1ddk,•Me Softw.tre 1h.tt connects d1ss1m1lar appltcaaoos and enables them to communicate and
exchange dara. l'or example, middleware can link a depamncntal database to a Web server thar can
be accessed by client computers ~;a rhe lnrcmet or a company mrranct. Su also glucwarc.
multipath dc,ign A ne"''ork design char relies on multiple data paths to increase bandwidth Jnd range,
u~mg ~UMO technology.
multiple 1nput/mul11plc ourput (MlMO) A wireles; ncru•urkmg c ... <hnolojt) 1n~uqwrated in the IEEE
802. 11 n and 802.1 lac \tandard' that u>e' multiple data \trcam\ and multiple antenna' ro achieve
higher tran,mi"ion 'peed~ and substantially increase wire l c~> range over earlier <iandard,.
nct·ccnnic computing A di~rributcd environment where application' and data arc down l oad~d from
\Crver' :ind e..:changcd wirh peer\ acros$ a ne"vork on an :L\·nt:eded ha\i\.
ncmork wpolog} The W:l)' a nerwork i> configured. LAN and \VAN networb cypically nre nrrnnged in
one of four common parccrns: hierarchical, bub, star, :ind ring.
node A ph)'s1cal device, wired or wireless, rhar can send, receive. or 111Jn.1ge network d,11,1.
11-11cr dc~ign A mulnlcvel design or archirecrure. For example, rhree·uer design~ also .trc called n·ricr
designs, to u1dic:11c char some designs use more 1hao one incermediare IJycr.
onlinc sysccm 11.mdling cr.msactioos when and where they occur and providing ourpur directly ro users.
Bc.:au'c it i, inrerntrive, on line proce~bing avoids tldavb and allo\\., a conbt.1nt dialog bccwten the
u'cr and the ')''tcm.
Open <;~,tern' Interconnection (OST) model Describes how data actually move-. from an application on
one computer roan application on another necworkcd compmcr. The OSI con'i'r~ of ~ven layers,
and c.-ach layer perform' a 'pecific function.
ph) \leaf topolog, The Lonnet.-rion 'rrucrure c>f an acrual network\ cablmi;.
pbrfonn A specific lwrdware and software coofiguraaon char supports l r bus111ess goals such .ts hard·
"are connecunry and easy tnregraciou 0£ furure applicauons. Also called an environment.
po1nt·of·sale {PO!>) Ilic part of an information system that handles datl) sales transaction' and ma111·
tains the onltne mvemory file.
portal An tntrancc ro a multifunction website. After encenng a portal, a user can navig;tce ro a desrina·
rion, using' .trious tools and features pro,ided by the portal desig11er.
pro~y \cncr A ne1work111g device that provides lncerner connccrivtty for 1111ernal I AN u'er..
rin11 nct\\orl. A network re>cmbling a i;ircle of computers rhal communu:ate with each other. A ring net·
work often '' u<cd when proccss111111s performed at local site• rather than ar a ccnrral location.
roamin11 A proce~< rhac allows wireless clicnrs to move from one acccs< point to anorher, auromnricnlly
as<oci:iting wirh rhe srronger acce<~ poinr· and allo \\~ng for uninterrupted ~crvicc.
router A device that connects ne~ork segments, determines the most efficient 1.1.lra pnrh. and guides the
flow ot dJra.
sc.11.lbiltt) A characteristic implying rhe sysrem can be exp;rnded, modiCied, or downsized to meer rhe
r.1 p1dl) changing need< of a business enrerprisc.
~c.1ling on demand The abiliry co macch network resources to needs at any given umc; a feature of cloud
computing. For example, during peak loads, additional cloud ~erver• migh1 come on line aurom.ui·
cally to wpporr mcrcabed workloads.
\cm.imk \\Cb An evolunun of rhe web where the d0<;umen1• •hared on the Internet have .emannc•
(meaning) and not just >ynrax (1-ITML tn."lrkup). Sometimes called Weh 3.0.
~cr"\cr
Compurer m a chent/scr"\'Cr destttn rhat suppbcs data, procc~mg, and ser"\1ccs ro chcnr
"ork~tanon<.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Phase l
Systems Design
Key Terms
349
stand -~lonc When personal computers first appeared ID large numbers ID the 1990, users found that rhey
could run rhe1r own word processing, sprcadsheer, and database apphcarions. without assistance from
tht' IT group, an a mode called stand-alone computing.
~tar nL"t"ork A ncrwork de,ign ,~,th a central device and one or more workstation'> connected w 1r in a
way that torm' a 'it.lr panern.
'uppl~ cham mana11cmen1 (SCM) The i:oordinacion, incegrarion, and management of material'>, mformation,
and finance' a\ they m(l\e from 'upplier~ to customers, both\\ 1thin and between umipamc,.
In a totally mtcgrarcd \Upply cham, a cu.,"tomcr order could cause a produL"tlon plannm11 'Y'tcm ro
..chcdulc a work order, which in rum could trigger a call for certain pan.. from one: or more 'upplier\.
switch Cenrral networking device an ,, srar nerwork, which manages the network and acts as a conduit
for all network traffic
system architecture A rransl.111011of1be logical design of an information sysrem into ~1 physical structure
that iududes h.irdw.ue. sofrware, network support, and processing methods.
'>'tern dc,i11n \pccifti:ation A document tl1:1t r1·c,c 1H~ rhe complete dco,ii;n for rhe new 111for111n1ion 'Y~·
tcm, along wirh dcta1lcd cmr., 'taffing, and 'chcduling for completing the nc"X"t SOLC pha,c, 'Y'tcm•
implementation. Al•o cnlled the technical design •pecification or the detailed dc•ign specification.
thick client A ')'•tcm Jc,ign thnr locate• mo•r or all of the application proce,,ing logic at chc client. Al•o
called a lat dienc Je,i!,'11.
th.in diem A sysrem design that locates most or JIJ of the processing logic ar the server.
In J chrtt·tier design. the user 1merface runs on che cl.tent aud the d.ua lS stored on the
sener, 1ust as in a rwo-ner des1y,11. A three-nee design also has a nuddle byer between the client Jnd
server rhat processes the chcnr requests and transl.ares rhem into data access commands th.11 c.in be
unde~tood and earned out h) the server.
thr~e - tier d•~igo
tramparcnt A network ;, rran,parcnr i( a uo;er •ee• the daca as if it were stored on hi' or her own
work\tariun.
mo-uer de-.1gn A network de"gn where rhe u,er 1ncerface resides on the client, all data n:,iJ.,., on the
'>Ctver, and the apph.:atton loi;k .:an run either on the ,,.-rvcr or on the client or be divided between the
client <1nd the -.cn·cr.
"cb-ceotnc A strategy or approach that emphasizes a high degree of inregrauon wnh other web-based
component,. A web-cenrric archnecrurc follows Internet desjgn protocols and cnabks a company to
integrate rhe ne\\ applicanon inro its e-commerce strategy.
wide area oemork (\\AN) A network sp.mning long dmances chat can link user> who art commenrs
.ipan.
~r, . 11 Alli.1ncc A nonprofit international a>,ociation formed in 1999 to c:crri(y i111eroperJbil1ry of wire·
lc's network product~ ha~cd on IF.FE 802.11 ~pccificarions.
wiki A wch- ha~cd repository of information [har anyone can access, contribute to, or mudif)'.
\'\'i-1\1:" ll· EE 802.16 speci(ic.11io11~. wh ich .ire expected co enable wireless mulrimcd1.1 npplic.mo11~ w1rh
a range of up to 30 male,.
wirclcs; occc;; pomt (WAPI A cenrral wireless device thar provides network services ro wircles~ clients.
Alsu called Jn Jcce;s point.
\\irclc" ftdclit> (\'l.'i-Fi) F.11111ly of popular IEEE LAN wireless nerworking standard;, abo known as
802. l I, mdudmg 802.1 I a, b, g, and n. 802.11 n is the most rt.'Ccnt Manda rd. 802.11 ac and !!02. I I ad
arc proposed new standard~.
wirclc" local area ncmorl.. ( \'I. LAN) A wircle\s ncrwork that is rclanvdy mexpcns"·e to tn~tall .md i<
well ~mtcd to workgroup' and users who are nor anchored to .i spcciftc desk or locatton.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter I 0
System Architecture
JSO
Exercises
Exercises
Que stions
I. If )'OU had to rank rhc items in the archirecrure checklist, from most important to least important,
what would )OUr liM look like?
2. Whar are the rhree functions rhat every business iniormation srstem must carry our, irrespective of
system architecrure?
3. Whar ts client/server arch1recture?
4. What has been the impact of rhe Internet on system architecture?
5. What are the differences between in-house e-commerce development with packaged solurion~ and
service providers?
6. What are the advantages of on line and batch processing, respectively?
7. Explain the five main network models.
8. What functions do routers, gateways, and proxy servers serve in a nerwork?
9. What role do srandards play in wireless networking?
10. List the sections of a system design specification and describe the contents.
Discussion Topics
I. How i~ the proliferation of mobile devices that are locally powerful, use app) in)tead of fullfledged
Jpplications, and rely on wireless network connectivity changing sy)tcm architecture design
considerations?
2. E-commerce has seen explosive growth in recent years. \Vhat are the most important reasons for this
trend? \Vi ii it continue? \'Vhy or why not?
3. ls batch processing )rtll relevant? Why or why not?
4. What are the main differences bcn,1een the BSS and ESS wireless topologies?
5. One manager scares, "\'Vhen a new S)'Stem is proposed, I want a wrinen report, not an oral presentation,
which is like a sales pirch. I only want to see the facts abouc coses, bcnefirs, and schedules.~ Do
you agree w1rh thar poinr of view?
Projects
1. Visit the IT department at your school or a local company ro learn about the network they use.
Describe the network and draw a sketch of the configuration.
2. Prepare a 10-minutc ralk explaining Web 2.0 and cloud computing to a college class. Using the text
and your own Internet research, briefly describe the five most important point~ you will include in
your presentation.
3. Perform research on the Internet to identify a service provider that offer~ web- ba~ed busincs5 solutions,
and wrire a reporr describing rhe firm and its services.
4. Perform research on the Tnterner to learn about emerging trends in wireless networking and typical
costs involved in the install::irion of a wireless LAN.
5. Examine the role wireless networks arc having in the developing world. Why are some pl::ices bypassing
LANs and physical cabling altogether and moving ro a wireless S)'Stem archirecrure? What are the
advantages and disadvantages of this?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

PHASE
SYSTEMS IMPtEMENTA~ION
Systems implementation is the fourth of five phases in the systems development life cycle. In
the previous phase, systems design, a physical model of the system was developed. The output
of that phase. the systems design specification, is used as input to the systems implementation
phase. where a completely functioning information system is created.
Successful systems implementation requires considerable effort. After all, without a working
system delivered to the customer, all other phases of the SDLC have little meaning. In
software engineering. the construction phase is often jokingly referred to as "a small matter of
programming"- but of course it's no small matter at all.
Chapter 11 focuses on managing systems implementation throughout the useful life of the
system. This includes quality assurance, application development (structured. object-oriented,
and agile). coding. testing, documentation, and system installation.
351
r..,,...J1DOr-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Managing Systems
Implementation
Chapter I I descnbes the systems implementation phase
of the SDLC. Managing systems Implementation involves
paying constant attention to quality assurance throughout
the activities of application development. coding, testing,
documentation, and installation. The system design
specification serves as a blueprint for constructing the
new system. The initial task Is application development.
which requires systems analysts and programmers to
work together to construct the necessary programs and
code modules. Before a changeover, the system must be
tested and documented carefully. users must be trained,
and existing data must be converted. After the new
system is operational. a formal evaluation of the results
takes place as part of a final report to management.
The chapter includes three "Case In Point"
discussion questions to help contextualize the concepts
described in the text. The "Question of Ethics"
concerns with an issue that all testers have to deal:
when to stop testing. In the example, there is an ethical
question raised about whether or not a 90% pass rate
is sufficient to ship the product, assuming the remaining
bugs will be fixed once the system Is operational.
Whe11 you fi11ish this d1apter, you sho11/d be able
to:
1. Explain quality assurnnce and three techniques
co help improve Lhe finished product
2. Ourline application developmenc
3. Appl)' structured development
4. Apply object-oriented development
5. Apply agile development
6. Explain coding
7. Explain unir, integration, and system resting
8. Diffcrenti:ue between program, system, operations,
and u&er documentation
9. Explain the role of online documentation
I 0. Describe rhe five tasks involved in sysrem
installation
c
I I. I
I 1.2
I 1.3
I 1.4
I 1.5
I 1.6
I 1.7
11.8
11.9
T
Qualiry Assurance
Application Developmcnr
Structured Development
Objecr-Orienred Development
Agile Development
Coding
Testing
Case in Point 11.1: Your Move, Inc.
Documentation
lnsralla ti on
Case in Poinr I 1.2: Globa 1 Cooling
Case in Po inr 11 .3: Yorktown lndusrries
A Question of Ethics
11.10 Summary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ... . ... .,...~ • ........._ . ... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., .... ............. .._ ... .., .,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ .... .................... ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
if' uuo 4
y.st:o1ns; rnp1o:n
I 1.1 Qualicy Assurance
f f 1 ll I ITV -.
353
In toda)''S competitive business environment, companies are intensely concerned
with the quality of their products and services. A successful organization must
improve quality in every area, including its information systems. Top management
must provide rhe leadership, encouragement, and support needed for high-quality
IT resources.
No marrer how carefully a system is designed and implemented, problems can
occur. Rigorous testing can detect errors during implementation, bur it is much less
expensive ro correct mistakes earlier in che development process. The main objccrive
of quality assurance (QA) is co avoid problems or co identify chem as oon as possible.
Poor qualiry can result from maccurace requirements, design problems, coding
errors, faulry documentation, and ineffecrive cesring.
To improve rhe finished produce, sofrware systems developers should consider best
practices in sofrware engineering, systems engineering, and incernarionally recognized
quality sr:1ndards.
I 1. 1.1 Software Engineering
Software engineering is rhe disciplined application of engineering principles to the
creation of complex, long-lived applications. le is an amalgam of people, process, and
technology. Software engineering is broader than just development. Ir includes five
technic:1l activity areas: requirements, design, construction, testing, and maintenance
and evolution. Jc is supported by nontechnical ac1tiviries such as cost and effort estimation,
project management, and process improvement.
The website for rhe Sofrware Engineering Insricure (SEJ) ar Carnegie Mellon
University is shown in Figure J 1-1. SEI is a leader in software engineering and
provides quality standards and suggested procedures for software developers
and systems analysts. SEl's primary objective is ro find better, faster, and lcssexpensive
methods of software development. To achieve thar goal, SEI designed an
influential ser of software development standards called tbe Capabilit) Maturity
M odel (C~lM ) , which has been used successfully by thousands of organizations
around the globe. The purpose of the model is ro improve software quality, reduce
development rime, and cur costs. The five maturity levels of the software CM~1 arc
shown in Figure 11-2.
After rhc original software CMM was released and updated, orher CMMs were
introduced. Evcnrually the SET csrablished a new model, called Capability Maturiry
Model Integration (CMMI)•, that integrates software and systems development
into a much larger framework. The CMMI tracks an organization's processes,
using Five maruriry level~, from Level I, which is referred to as unpredicrable,
poorly controlled, and re:1crive, ro Level 5, in which rhe optimal result is process
improvemenr.
11.1.2 Systems Engineering
Systems engineering nor only builds upon software engineering bur also includes
ocher parts of the overall sysrem, such as hardware, networks, and interfaces. Trade
organilarions such as INCOSE and the IEEE Systems Council provide guidance on besr
practices :111d emerging technologies in systems engineering. As shown in Figure 11-3,
systems analyses can bcnefir from a holistic approach to large-scale problem solving by
adopting a broader pcrspccrivc.

354
I I. I Quality Assurance
(.ar---llrlJ..nlal\rnih
~~ln<toMP
FIGURE 11 -1 The Software Engineering Institute at Carnegie Mellon University has had profound
Influence on software engineering research and pracoce.
~ c." ... "
Process improvement
strategies defined and used
Level 5
Op11m1z1ng
Quality management
strategies defined and used
Level4
Managed
Level 3
Defined
Process management
procedures defined and used
Level2
Repeatable
Product management
procedures dellned and used
Level 1
Initial
Essentially uncontrolled
FIGURE 11 · 2 The CMM has five maturity levels. from Level I (1nldal), which is
essentially uncontrolled development. to Level S (opamiz1ng). In which process
Improvement strategies are defined and used.
~~ c;c.,, ... ,
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

I 1. 1 Qualicy Assurance
if' uuo 4
y.st:o1ns; rnp1o:n
355
WHAT IS SYSTEMS ENGINEERING?
Systems .ngonttrs •re M the heart of ueatJng successful new Systems TMy are responsible for the system concept.
Mehotect~ •nd design. They •Nly?e and manage compluoty and risk. TMy dKide how 10 menure whether the deployed
System actually works as lntendtd. They are responsible for a mynad of ocher facets of system ueatoon. Systems
engoneenng Is the d•scophne that makes th~ succl!SS possible - thetr tools, techmques, methods. knowledge, standards.
pnncop~. and concepts The launch of successful Systems can invariably be traced to ~trw and effearw systems
eng1neenn1
FIGURE 11-3 INCOSE's view of systems engineering.
So1.lrceJ INC°O~( !Pl I 1•""' C ""I' lf> ~)' ~ 1 F 1! ''11
I 1. 1.3 International O rganization for Standardization
\Vhar do automobiles, water, and software have in common?
Along with thousands of other produi;:ts and servii;:es, they are
all covered by standards from the International Organization
for Standardization (ISO), which was discussed in Chapter 9.
ISO standards include everything from internationaUy
recognized symbols, such as those shown in Figure 11-4
to the ISB1 numbering system that identifies this text. In
addition, ISO seeks to offer a global consensus of what
constitutes good management practices that can help firms
deliver consistently high-quality products and servicesincluding
software.
Because software is so important to a company's success,
1nany firms seek assurance that sofrwace systems, either
purchased or developed in-house, will meet rigid quality
standards. In 2014, ISO updated a set of guideljnes, called
ISO 9000· 3:2014, that provided a QA framework for
developing and mainraining software.
A company ca n specify ISO standards when it purchases
sofrware from a supplier or use ISO guidelines for in-house
software developmcnr to ensure rhat rhe fina l resulr measures
up to ISO standards. ISO requires a specific development
plan, which ourlincs a step-by-seep process for transforming
user requiremencs inco a finished product. ISO standards can
be quite detailed. For cxt1mplc, ISO requires that a software
supplier document all tesung and maintain records of rest
results. If problems are found, they must be resolved, and
any modules affected muse be retested. Additionally, software
and hardware specifications of all test eqwpmenr must be
documented and tncluded in the test records.
p
''
r
+
FIGURE 11-4 ISO symbols include lntemationally
recogni:ted symbols.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

356 I 1.2 Application Development
I ~
Application development is the process of constructing the programs and code
modules that serve as the building blocks of the information S)'Stem. In Chapter I,
it was explained that structured analysis, object-oriented (0-0) analysis, and agile
methods are three popular development options. Regardless of the method, the
objective 1s to translate the design into program and code modules that will function
properly.
Regardless of whether structured analysis, 0-0 design, or agile methods are used,
even a modest-sized project might have hundreds or even thousands of modules. For
this reason, application developmenc can become quite complex and difficult to manage.
At this srage, project management is especially important co control schedules
and budgets.
Users and managers are looking forward to the new system, and it is very important
to set realistic schedules, meet project deadlines, control costs, and maintain quality.
To achieve these goals, the systems analyse or project manager should use project
management tools and techniques similar to those described in Chapter 3 to monitor
and control the development effort.
I 1.2.1 Review the System Design
At this point, it is helpful to review t he tasks involved in the creation of the system
design:
• Chapter 4 focused on requirements modeling and how to use functional
decomposition diagrams (fDDs) to break complex business operations down
into smaller units, or functions.
• Chapter 5 focused on structured data and procel.!t modeling, and dara flow diagrams
(DFDs). The development of process descriptions for functional primitive
processes that documented the businebS logic and proces~ing requirements
was also discussed.
• Chapter 6 focused on an 0-0 model of the new system that included use case
diagr:ims, class diagrams, sequence diagrams, state transition diagrams, and
activity diagrams.
• Chapter 7 focused on selecting a development strategy.
• Chapter 8 focused on designing the user interface.
• Chapter 9 focused on data design issues, analyzing relationships berwecn system
entities, and constructing entity-relationship diagr:ims (ERDs).
• Chapter LO focused on overall system architecture considerations.
Taken together, this set of tasks produced an overall design and a plan for physical
implementation.
I 1.2.2 Application D evelopmentTasks
If traditional strucmred or 0-0 methods were used during system design, the process
of translating the design into a functioning application can begin. If an agile development
method was selected, development begins with planning the project, followed
by laying the groundwork, assembling the team, and preparing to interact with rhe
customers.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
I 1.2 Application Development
357
TRADITIONAL METHODS: Building a new system requires careful planning. After
an overall strategy is e tablished, individual modules must be designed, coded, tested,
and documented. A module consists of related program code organized into small
units that are easy to understand and maintain. After the modules are developed and
tested individually, more testing takes place, along with thorough documentation of
the entire system, as shown in Figure 11-5.
DEVELOP - +f
~ Test Document
~ .__M_od_uJ_es__, .__Mod
u_le-:s~,,
• Integration
Te.sting
•
System
Tesung
•
Ooa.unentahon )
FIGURE 11-S The main steps in tnditional application development.
When program modules arc created using suucrured or 0-0 methods, the
process starts by reviewing requirements documentation from prior SDLC phases
and creating a set of program designs. Lf a documentation file was built early in
the development process and updated regular!}', there is a valuable repository of
information. The documentation centerpiece is the system design specification,
accompanied by diagrams, source documents, screen layouts, report designs, dara
dictionary entries, and user comments. If a CASE tool was used during rhe systems
analysis and design process, the analyst's job will be much easier. At this point, coding
and resting taskl> begin. Although programmers typically perform the actual coding,
IT managers usuall y assign systems analysts co work with them as a team.
AGILE METHODS: If an agile approach is decided upon, intense communication
and collaboration will now begin between the IT ream and the users or customers.
The objective is to create the system through an iterative process of planning, designing,
coding, and testing. Agile projects use various iterative and incremental models,
including Extreme Programming (XP) as shown in figure 11-6. Agile development
and XP arc discussed more later in this chapter.
11 .2.3 Systems Development Tools
Each systems development approach has its own set of tools that has worked well for
that method. For example, structured development relies heavily on DFDs and structure
charts; 0-0 methods use a variery of UML diagrams, including use case, class,
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

358 I 1.2 Application Development
sequence, and transition state diagrams; and agile methods rend ro use spiral or orher
iterative models such as the example shown in Figure 11-6.
System developers also can use multipurpose rools to help them tr:mslatc rhe system
logic into properly functioning program modules. These generic tools include
ERDs, flowchnrrs, pseudocode, decision table , and decision trees.
Test
.scenarios
New user S1ory
r:::=-1 Preparation
~
Release
planning
New
Customer
version Acceptance approval r:==1
.. test• ·~
Next
iteration
FIGURE I 1-6 Simplified model of an XP project. Note the empt.a.sis on lte~tlon and testing.
ENTITY-RELATIONSHIP DIAGRAMS: During data design (Chapter 9), the use of
ERDs to show the interaction among system entities and objects was described. An
ERO is a useful tool regardless of which methodology used, because the various
rel:nionships (one-to-one, one-to-01any, aod many-to-many) must be understood and
implemented in the application development process.
FLOWCHARTS: As described in Chapter 5, flowcharts can be used to represent
program logic and arc very useful in visualizing a modular design. A flowchart
represents logical rules and interaction graphically, using a series of symbols
connected by arrows. Using flowcharts, programmers can break large systems into
subsysrems and modules char arc easier to understand and code.
PSEUDOCODE: Pseudocode is a technique for representing program logic.
Pseudocodc is simi lar co srrucrured English, which was explained in Chapter 5.
Pseudocode is nor l::inguage-specific, so it can be used to describe a software module
in plain English without requiring strict syntax rules. Using pseudocode, a systems
an.ilyst or a programmer can describe program actions that c.in be implemented in
any programming language. Figure 1 1-7 illustrates an example of pscudocode th.it
documents a sales promotion policy.
DECISIONTABLESAND DECISIONTREES: As explained in Chapter 5, decision
tables and decision trees can be used ro model business logic for an information
system. In addition ro being used as modeling tools, analysts and programmers can
use decision tables and decision trees during system development, as code modules
chat implement the logical rules are developed. figure l l -8 shows .in example of a
decision tree that documents the sales promotion policy shown in Figure 11 -7. Nore
that the decision tree accurately reAecrs che sales promotion policy, which has three
sep.irare conditions and four possible outcomes.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
I 1.3 St ructured Development
359
SAMPLE OF A SALES PROMOTION POLICY
• Preferred customers who order more than $1.000 are entided to a 5% discount. and
an additional 5% discount if they used our charge card.
• Preferred customers who do not order more than $1.000 receive a $25 bonus
coupon.
• All other cuStomers receive a $5 bonus coupon.
PSEUDOCODEVERSION OF THE SALES PROMOTION POLICY
IF customer is a preferred customer, and
IF customer orders more than $1 ,000 then
Apply a 5% discount. and
IF customer uses our charge card. then
Apply an additional 5% discount
ELSE
ELSE
Award a $5 bonus coupon
Award a $25 bonus coupon
FIGURE 11 ·7 Sample of a sales promotion policy with logical rules (top) and a pseudocode version of the
same policy (bottom). Note the alignment and indentation of the logic statements in the pseudocode.
Preferred
customer?
y
Ordered
more than
$1,000?
Used our
charge card?
y
---
N
5% discount and
an addltlonal 5%
discount
5% discount
"'-~~~~~~~~~~~- S25bonuscoupon
N
N
SS bonus coupon
FIGURE 11 ·8 Sample decision tree char refleas che sales promotion policy 1n Figure 11-7. Like a decision
table. a decision tree shows che aa1on co be taken based on certain properties.
I I l STD• 1t"'T'11 s:n S:VS:t nP - -
Structured application development usually involves a top-down approach, which
proceeds from a general design ro a derailed structure. After a systems analyst docu·
ments the system's requirements, he or she breaks the system down into subsystems
and modules in a process called partitioning. T his approach also is called modular
design and is similar co constructing a leveled set of DFDs. By assign ing modules to
different programmers, several development areas can proceed at the same time. As
explained in Chapter 3, project management software can be used to moniror work
on each module, forecast overall development time, estimate required human and
technical resources, and calculate a critical path for rhe project.
Because all the modules must work together properly, an analyst must proceed
carefully, with constant input from programmers and IT n1anagemcnt to achieve a
sound, well-integrated structure. The analyst also must ensure that integration capabilit}
is built into each design and thoroughly rested.
_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

360 I 1.3 Structured Development
I 1.3. 1 Structure Charts
Srrucrure charrs show rhe program modules and rhe relarionships among rhem. A
~rructurc chart consists of recrangles rhac represenc rhe program modules, wich arrows
and other symbols rhar provide additional informarion. Typically, a higher-level module,
called a control module, directs lower-level modules, called ~ubordinate module~ . In
a srructure charr, symbols represenc various actions or conditions. Structure charr
symbols represent modules, data couples, control couples, conditions, and loops.
MODULE: A rectangle represeocs a module, as shown in Figure I J-9. In the figure,
vertical lines ac rhe edges of a rectangle indicate char module 1.3 is a library module. A
library module is reusable code and can be invoked from more than one poinr in rhe chart.
DATA COUPLE: An arrow wich an empty circle represents a data couple. A daca
couple shows dara that one module passes to another. In rhe dnra couple example
shown in Figure 11 -10, rhe Look Up Cuscomer Name module exchanges data with
rhe Maintain Customer Daca module.
Module I
Maintain Customer Data
•
I IModde 1.311}
Library
Module
Subordinate
Module
FIGURE 11-9 An example of structure c.han modules.
I Look Up Customer Name
FIGURE 11 - 10 Anexampleof
a structure cha.rt data couple.
CONTROL COUPLE: An arrow wirh a filled circle represenrs a conrrol couple. A
control couple shows a message, also called a status flag, that one module sends ro
:inorher. In the example shown in Figure 11-11, rbe Update Cusromcr File module
sends an Account Overdue flag back to the Maintain Customer Data module. A
module uses a flag to signal a specific condition or action ro another module.
Maintain Customer Data
Control
Couple
Check
Customer Status
Update
Customer File
FIGURE 11 - 11 An example of a Strucrure chan control couple
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
I 1.3 St ructured Development
361
CONDITION: A line with a diamond on one end represents a condirion. A condition
line indicates that a conrrol module determines which subordinate modules will be
invoked, depending on a ~pecific condition. Jn the example shown in Figure 11-12,
Sort Inventory Parr is a conrrol module with a condition line that trigger~ one of the
three subordmare modules.
Sort Inventory Parts
Sort By Part Name Sort By Part Number Sort By Inventory Value
FIGURE I 1-12 The diagram shoW$ a control module that triggers three subordin~te
modules.
LOOP: A curved arrow represents a loop. A loop indicates that one or more modules
are repeated. In the example shown in Figure 11-13, the Get Student Grades and
Calculate GPA modules are repeated.
Produce Grade Reports
Get Student Grades calculate GPA I Produce Grade Report I
The curved arrow Indicates that these modules are repea1ed.
FIGURE 11- 13 The diagram shows a structure chan; loop with two repeating modules.
I 1.3.2 Cohesion and Coupling
Cohesion and coupling are important cools for evaluating the overall design. As
explained in the following sections, it is desirable to have modules that are highly
cohesive and loosely coupled. Otherwise, system maintenance becomes more costly
due to difficulties in making changes to the system's structure.
Cohesion measures a module's scope and processing characteristics. A module that
performs a single function or cask has a high degree of cohesion, which is desirable.
Because it focuses on a single task, a cohesive module is much easier to code and
reuse. For example, a module named Verify Customer Number is more cohesive than
a module named Calculate and Prinr Statements. If the word and is found in a module
name, this implies char more rhan one cask is involved.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

362 I 1.3 Structured Development
If a module must perform mulriple tasks, more complex coding is required and
the module will be more difficulr to create and mainrain. To make a module more
cohesive, split it into separate units, each with a single function. For example, by
splirtmg the module Check Customer Number and Credit Limit in Figure 1 1-14 into
two separate modules, Check Customer 'umber and Check Customer Credit Limit,
cohesion is greatly improved.
More
Cohesive
Check Customer
Number and
Credit Limit
Less
Cohesive
Check Customer
Number
Check Customer
Credit limit
FIGURE I 1- 14 Two examples of cohesion. Note that the single module on the left is less cohesive than the
two modules on the right.
Coupling descrihes the degree of interdependence among modules. Modules that
are independent are loosely coupled , which is desirable. Loosely coupled modules
are easier ro mainrain and modify, because che logic in one module does nor affecc
other modules. If a programmer needs to update a loosely coupled module, he or
she can accomplish the task in a single location. If modules are rightly coupled,
one module is linked to internal logic contained in another module. For example,
Module A mtght refer to an internal variable contained in Module B. In that case,
a logtc error in the Module B will aifect the processing Ill Module A. For that
reason, passing a status flag down as a message from a control module is generally
regarded as poor design. It is better to have subordinate modules handle processing
tasks as independently as possible, to avoid a cascade effect of logic errors in the
control module.
In Figure .11-15, rhe tightly coupled example on the left shows that the
subordinate module Calculate Current Charges depends on a status flag sent down
from the control module Update Customer Balance. It would be preferable to have
the modules loosely coupled and logically independent. Jn the example on the
right, a status flag is not needed because the subordinate module Apply Discount
handles discount processing independently. Any logic errors arc confined co :i single
location: the Apply Discount moduJe.
I 1.3.3 Drawing a Structure Chart
If :i strucrnred analysis method was used during system design, the structure charts
will be based on the DFDs created during data and process modeling.
Typica lly, three steps are followed when cre:iting a structure chart. DFDs arc
reviewed to identify the processes and methods, identify the program modules and
determine control-subordinate relationships, and add symbols for couples and loops.
Afterward, the structure chart is analyzed to ensure chat it is con-;isrenr wirh the system
documentation.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
if' uuo 4
y.st:o1ns; rnp1o:n
I 1.3 St ructured Development
363
TlghUy
Coupled
Update Customer
Balance
..
I ] t?
-z
.8
E
'
i1 .
z
-
::>
l
~
z ~
()
!
()
l
rJ
Ji!
0
I
Update Customer
Balance
~
-
f5
.8
~ ~1
E
::>
ff
z
a -
..
§
~
.,,
Loonly
0
R ::> Coupled
~
-
'l
~
j
.s
~
.$ ~ z
'lJ"' ;:;
!; ~
I
,j
i
()
8 .,
8
j
..
il
i
z
Calculate Current
Charges
Apply
Discount
Calculate Current
Charges
FIGURE 11-15 An example of clghdy coupled and loosely cou,pled structure charu.
STEP I . REVIEW THE DFDS: The first step is co review all DFDs for accuracy and
complereness, especially if changes have occurred since the sysrems analysis phase. If
objecr models also were developed, rhey should be analyzed co identify the objecrs,
the methods that each ob1ecr musr perform, and rhe relationships among the objects.
A method is similar ro a functional primirive and requires code co implement the
necessary acrions.
STEP 2. IDENTIFY MODULES AND RELATIONSHIPS: Working from rhe logical
model, functional primirivcs or object methods arc transformed into program
modules. When analyzing a sec of DFDs, remember chat each DFD level represenrs
a processing level. If DFDs arc being used, one works way down from the context
diagram to the lower-level diagrams, identifying control modules and subordinare
modules, until rhe funcrional primitives are reached. If more cohesion is desired,
processes can be divided into smaller modules chat handle a single rask. Figure 11-16
shows a structure chart based on the order system from Chaprer 5. Note how the
three-level structure chart relates co the three DFD levels.
STEP 3. ADD COUPLES, LOOPS, AND CONDITIONS: Next, couples, loops, and
conditions arc added ro rhe scrucrure chart. If DFDs are being used, rhc data flows
and the data dictionary can he reviewed co identify the dara elements rhac pass from
one module to anorhcr. In addirion madding che data couples, control couples arc
added where a module is sending a control parameter, or flag, ro another module.
Loop:. and condirion lines char indicate repetitive or alremative processing seeps arc
also added, as shown in Figure 11- 16. If an object model w:is developed, the class
diagrams :ind object relationship diagrams can be reviewed co be sure char the inceraction
among the objeccs is fully undersrood.

364
I 1.4 Object-Oriented Development
Order System
ModuleO
Relalea to context
diagram
Fill Order
Module 1
Create Invoice
Module2
Apply Payment
Module 3
Relates to diagram
ODFD
Relalea to diagram
1 DFD
VenfyOrder
Module 1.1
Prepare Reject
Nolice
Module 1.2
Assemble Order
Modu:e 1.3
FIGURE 11 - 16 A structure chart based on the order system DFDs in Chapter S.The three-level structure
chart relates to the three DFD levels.
At this point, the structure cbart is ready for careful analysis. Each process, data
element, or object method should be checked ro ensure that the chart reflects all previous
documentation and that rJ1e logic is correct. All modules should be srrongly
cohesive and loosely coupled. Often, several versions of the chart must be drawn.
Some CASE tools can help analyze the chart and identify problem areas.
I I
" •-=,.,-.
0 -0 methods were described in Chapter 6. 0-0 analysis makes it easier to translate
an object model directly into an 0-0 programming language. This process is called
object-oriented development (OOD). Although many structured design concepts also
apply to 0 -0 methodology, there are some differences.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
I 1.4 Object-Oriented Development
365
I 1.4.1 Characteristics of Object-Oriented Development
When implemenring a ~rrucrured design, a structure chart is used ro de5crihe the
interaction herween program modules, as explained earlier. In contrast, when
implementing an 0 -0 design, relationships between objects already exist. Because
object interaction is defined during rhe 0-0 analysis process, the object model 1rself
represenrs rhe application's strucrure.
As Chapter 6 explains, ohjecrs contain both dara and program logic called
methods. Indt\lidual ob1ect instances belong to classes of objects with similar
characteristics. The relationship and interaction among classes are described using a
class diagram, such as the one shown in Figure 11-17. A class diagram includes rhe
class attributes, which describe the characteristics of objects in rhe class, and methods,
which represent program logic. For example, the Customer class describes customer
objects. Customer attributes include Number. ame, Address, and so on. Methods for
the Customer class include Place order, Modify order, and Pay invoice, among others.
The Customer class can exchange messages \vith the Order class.
Customer
Attributes
Number
Name
Address
...
Methods
Place order
Mod1ly order
Pay invoice
...
1
Places
o .. •
Order
Item
Allflbutes
Number
Customer
Allnbutes
Number
Description
Date
o .. • Includes 1 ~ .• Price
.. ..
Methods
Verify credil stalus
Verify Item status
Apply discount
... .
Methods
Change stock level
Change min-max
Reorder
FIGURE 11 -17 A simplified class diagram for a customer order
processing system.
In addition ro class diagrams, programn1ers get an overview of object interaction
by using object relationship diagrams char were developed during rhe 0 -0 analysis
process. For example, Figure I 1- 18 shows an object relationship diagram for a fitness
center. Nore chat rhe model shows the objects and how rhey interact co perform business
functions and transactions.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
..

366 I 1.4 Object-Oriented Development
EMPLOYEE
ts a
MANAGER
OFFICE STAFF
INSTRUCTOR
Determines
A TNESS·CLASS
SCHEDULE
rostor
Takos
Adds
STUDENT
FIG URE I 1- 18 An object-relationship diagram for a fltness center.
Properly implemented, object-oriented development can speed up projects, reduce
coses, and improve overall quality. However, these results arc nor always achieved.
Organizations sometimes have unrealistic expectations and do nor spend enough
rime learning about, preparing for, and implementing the OOD process. For example,
no one would build a bridge without an analysis of needs, supporting data, and a
derailed blueprint-and the bridge \Vould nor be opened for traffic until it had been
carefully inspected and checked ro ensure that all specifications were met. 0-0
software developers sometimes forger that the basic rules of architecture also apply to
their projects.
In summary, ro secure the potential benefits of 000, systems analysts must carefullr
analyze, design, implement, cesc, and document rheir 0-0 projccrs.
I 1.4.2 Imple mentation of Object-Oriented Designs
\Xi'hcn a programmer translates an 0 -0 design into an application, he or she ana·
lyzcs the classes, attributes, methods, and messages that arc documcnred in rhe object
model. During chis process, the programmer makes neces~ary revisions and updates to
class diagrams, sequence diagrams, state transition diagrams, and activity diagrams.
The programmer's main objective is co translate object methods into program code
modules and <lerermine what evenr or message will trigger the execution of each module.
To accomplish the task, rhe programmer analyzes sequence diagrams and scare
transition diagrams that show the events and messages that trigger changes t(> an
object. 0 -0 ::ipplicacions are called event-driven, becau~e each event, transaction, or
message triggers a corresponding action. The programmer can represent the program
steps in pseudocode initially or use CASE tools and code generators ro create 0-0
code directly from the object model.
I 1.4.3 Object-Oriented Cohesion and Co upling
The principles of cohesion and coupling also apply to 0-0 application development.
Classes should be as loosely coupled (independent of other classes) as possible. In
addition, an object's methods also should be loosely coupled (independent of other
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
if' uuo 4
y.st:o1ns; rnp1o:n
I 1.5 Agile Developmenc
367
methods) and highly cohesive (perform closely related actions). By following the e
principles, classes and object arc easier ro understand and edit. 0-0 programmer
who ignore cohesion and coupling concepts may end up creating a web of code that
is difficult to maintain. \'(then code is scattered in various places, editing becomes
complicated and expensive.
.. .... ... VJ:I nPM!'" ·-
As stared in Chapter I, agile development is a distinctly different systems development
method. le shares many of the steps found in traditional development bur uses a
highly iterative process. The development team is in constant communication with the
primary user, who is called the customer, shaping and forming the system to match the
customer'~ specifications. Agile development is aprly named because it is based on a
quick and nimble development process that easily adapts to change. Agile development
focuses on small teams, intense communic.1tion, and rapid development iterations. The
four key values of agi le software development are shown in Figure 11-19.
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
FIGURE 11- 19 The manifesto for agile software development.
$ck.lr'(.el r 4 l'I ...,. TM
Programmers can use popular agile-friendly lai1guages such as Python, Ruby, and
Perl. However, agile methods do not require a specific progra1nming language, and
programmers also use various 0-0 languages such as Java, C++, C#, and others.
As with traditional methodologies, agile development has both positive and negative
characteristics. Today, agile methodology is very popular for software projects. Its
supporters boast that it speeds up software development and delivers precisely what the
customer wants, when the customer wanes it, while fostering teamwork and empowering
employees. However, rhcre arc drawbacks ro this adaptive rather than predicrivc
method. Critics of agile development often claim chat because it focuses on quick
iterations and fasr releases, ir lacks discipline and produces systems of que rionablc
quality. In addition, agile methodology generally does not work as well for larger
projects becau e of rheir complexity and chc lack of focus on a well-defined end product.

368 I I .S Agile Development
Before implementing agile development, the proposed system and development
methods should be examined carefully. As experienced IT professionals know, a
one-si1c-firs-all solution does nor exist. For more information on agile method , refer
to the discussion of systems development methods in Chapter I and agile methods
such as Scrum in Chapter 4.
I 1.5.1 Extreme Programming
XP is an agile development method. It is an iterative approach, as shown 111 1-igure 11 -20,
where a ream of users a nd developers immerse them elves in sy~tems development. XP
supporters emphasize values such as simplicity, communication, feedback, respect, and
courage. Success requires strong con1minnent to the process, corporate support, and
dedicated team members.
= :J ~ ~ The Values of Extreme Programming
............... .. ,._ ,
Extreme Programming (XP) is based Feedba.ck: We will Lake every iteration
on values. The rules we just examined are the commitment seriously by delivering working
natural extension and consequence of software. We demonstrate our sonwarc early
maximizing our values. XP isn't really a set of and often then listen carefully and make any
rules but rat.her a way to work in harmony changes needed. We will Ullk about lhe
with your personal and co.rporate values. Start project and adapt our process 10 it, nol the
with XP's values listed here then add your other way around.
own by reflecting them in the change$ you
make to the rules.
Respect: Everyone gives and reels the respect
they deserve as a valued team member.
Simplicity: We will do what is needed and Everyone cootributes value even ir it's simply
asked for, but no more. This will maximize enthusiasm. Developers respect the expertise
the value created for the investment made to of the customers and vice versa. Management
dale. We will take sma.11 simple steps to our respects our right 10 accept n:spon ibility and
goal and mitigate failures as they happen. We receive authority over our own work.
will create something we are proud of and
rnainlllin it long tcnn for reasonable oosts.
Communication: Everyone is part of the
team and we communicate face lo face daily.
We will work together on everything from
requirements to code. We will create the best
solution 10 our problem that we can together.
FIGURE I 1-20 The five core values of XP.
Courage: We will tell the tJUth about
progress and estimates. We don't document
excuses for failure because we plan to
succeed. We don't fear anything because no
one ever works alone. We will adapt to
changes when ever they happen.
XP uses a concept called pair programming. In pair programming, rwo
programmers work on the same task on the same computer; one drives (programs)
while the ocher navigates (watches). The onlooker examines the code strategically to
sec the forest while the driver is concerned with the individual trees immediately in
front of him or her. The two discuss their ideas continuously rhroughour rhe process.
Another important concept in XP is that unit rests are designed before code is
wricten. This rest-driven development (T DD) focuses on end results from the beginning
and prevenrs programmers from straying from their goals. Because of rhc magnitude
and intensity of the multicycle process, agile testing relies heavilr on automared
resting methods.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
11.6 Coding
369
I 1.5.2 User Stories
uppose that a cu~tomer has requested a sales rracking system. The first step in an
agile process, like any other de,·elopment method, would be to define the system
requirements. The customer begins by meeting with programmers and providing user
stories. A u\er ~tOI) is a short, simple requiremencs definition. Programmers review
user stories to derermine the project's requirements, priorities, and scope. Here are
three user story examples:
• As the sales manager, I want to identify fast- or slow-moving items so I can
manage 011r i11ve11tory more effectively.
• As a store manager, I need enough lead tinie to replenish my stock, so I don't
nm 0 111 of hot items.
• As a sales representative, I want to offer the best selection of fast-selling items
and clear out the old stock that is not moving.
User stories do nor deal wirh technical details and arc so short that they arc often
written on index cards. Each user story is given a priority by the customer, so the
requirements can be ranked. Jn addition, programmers assign a score to each user
story that indicates rhe esrimared difficulty of implementation. This information helps
the team form a plan and assign irs resources. Projecrs are often composed of many
user stories, which taken rogerher form epics, from which programmers can estimate
the scope, time requirements, and difficulty of the project. In addition to the user stories,
frequent foce-ro-face meetings with customers provide a higher level of derail as
rhc project progresses.
I 1.5.3 Iterations and Re leases
The team must also develop a release plan, which specifies when user storie will be
implemented and the timing of the releases. Releases are relatively frequent, and each
system release is like a prototype that can be rested and modified as needed.
User stories are implemented in a series of iteration cycles. An iteration cycle
includes planning, designing, coding, and testing of one or more features based on
user stories. At the beginning of each iteration cycle, which is often two weeks long,
the team holds an iteration planning meeting to break down the user stories into
~pecific tasks chat arc a~signed co ream members. As new user storie~ or feature~ are
added, the team reviews and modifies the release plan.
A~ with any development process, success is determined by the customer's
approval. The programming team regularly meets with the customer, who tests prototype
releases as they become available. This process usually results in additional
user ~tories, and changes are implemented in the next iteration cycle. As che project's
code changes during each iteration, obsolete code is removed and remaining code is
restructured co keep rhe system up to dace. The iteration cycles continue until all user
stories have been implcmcnrcd, tesred, and accepted.
Coding is the process of rurning program logic into specific instructions char the
computer system can exccure. Working from a specific design, a programmer uses a
programming language co transform program logic inro code statements. An individual
programmer might creare a small program, while larger programs typically arc
divided into modules char several individuals or groups can work on 5imultaneously.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

370 I I. 7 Testing
Each developer has rheir favorire programming environment and s randard~ ro
make coding easier. Visual Basic, Java, and Python are examples of commonly used
programming languages, and many commercial packages use a proprietary set of
commands. As the trend roward Internet-based and mobi le applications continues,
HTM UXM L, JavaScripr, Swift, and orher web-centric languages will be used
extensively.
To simplify the inregrarion of system components and reduce code development
time, many programmers use an integrated development en' ironmcnr (IDE). IDEs can
make 1r easier to program interactive software products by providing built-in tools
and advanced features, such as real-rime error derection, syntax hmrs, highlighted
code, class browsers, and version control. Apple Xcode and Microsoft .NET are
popular ID Es. In addition ro these commercial packages, programmers can use opensource
ID Es such as Ecl ipse.
Earlier chapters explained rhar systems analysts use application generators, report
writers, screen generarors, fourth-generation languages, and other CASE tools that
produce code directly from program design specifications. Some commercial applications
can generate edirable program code directly from macros, keysrrokes, or mouse
actions. For example, IBM's RationaJ toolser can generate code fragmenrs based on
UML design documents. T his can help with QA.
After coding, a programmer must rest each program co make sure it functions correctly.
Lacer, programs are reseed in groups, and finally che developmenc ream must
test the entire sysrem. T he first step is co compile the program using a CASE. rool or
a language compiler. This process detects syntax errors, which arc language grammar
errors. The programmer corrects the errors unril the program executes properly.
Next, rhe programmer desk checks the program. Desk checking is rhc process of
reviewing the program code co spot logic errors, which produce incorrect results.
This proccs can be performed by the person who wrore the program or by other
programmers. Many organizations require a more formal type of desk checkmg called
a ~tructurcd walk-through, or code review.
Typically, a group of three ro five IT staff members participares in code review.
The group usually consists of project team member~ and might include other programmers
nnd analysts who did not work on the project. The objective is ro have a
peer group identify errors, apply quality standards, and verify that rhe program meets
the requirements of the system design specification. Errors found during a structured
walk-through are easier co fix while coding is still in the developmental stages.
In addition to analyzing logic and program code, the proje~-r team usually holds a
session with users called a design walk-through, to review the interface with a cross
section of people who will work with the new system and ensure that all necessary
features have been included. This is a continuation of the modeling and prototyping
effort that began early in the systems development process.
The next step Ln application development is co initiate a sequence of unit testing,
integration resting, and system testing, as shown in Figure 11-21.
I I. 7. I Unit Testing
The testing of an individual program or module is called unit testing. The objective is
to identify and eliminate execution errors that could cause rhe program to terminate
abnormally and logic errors that could have been missed during desk checking.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
yst:o1ns; rnp1o:n
11.7 Testing
37 1
system test
Unit Test
Program 1
1ntegrabon test
Unit Test
Program 2
integrabon test
-
UM Test
Program 3
Integration test
Unit Test
Program 4
-
UnttTest
Program 5
UnitTest )
Program 6
integration test
FIGURE 11-2 1 The ftrn step in testing is unit testing. followed by integration testing and
then system tesung.
Test data should contain both correct data and erroneous data and should test
all possible situations that could occur. For example, for a field that allows a range
of numeric values, the test data should contain minimum values, maximum values,
values outside the acceptable range, and alphanumeric characters. During resting,
programmers can use software tools to determine the location and potential causes of
program errors.
During unit resting, programmers must test programs that interact with other
programs and files individually, before they are inregrared into the system. This
requires a technique called stub resting. In stub testing, rhe programmer sin1Ulares
each program outcome or result and displays a message to indicate whether or nor
the program executed successfully. Each stub represents an entry or exit point that
will be linked later to another program or data file.
To obtain an independent analysis, someone other than the programmer who
wrote rhc program usually creates the test data and reviews the results. Systems
analysts frequently create tcsr data during rhe sysrems design phase as part of an
overall rest plan. A tc\t plan consists of derailed procedures that specify how and
when rhe resting will be performed, who will participate, and what rest data wi ll be
used. A comprchen ive rest plan should include scenarios for every possible siruarion
the program could encounter.
Regardless of who creates the tesr plan, the project manager or a designated
analyst also reviews the final test results. Some organi1..ations also require u~r~ ro
approve final unit resr resulcs.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

372 I I. 7 Testing
11.7.l Integration Testing
Testing two or more programs that depend on each other is called integration
te\ting. For example, consider an information system with a program that checks
and validates customer credit status and a separate program that updates data in the
customer master file. The output from the validation program becomes input to the
master file update program. Testing rhe programs independently does nor guarantee
that the data passed between them is correct. Only by performing mregranon restmg
for this pair of programs can one ensure that the programs work together properly.
Figure 11-21 shows integration testing for several groups of programs. Note that a
program can have membership in two or more groups.
Systems analysts usually develop the data tbey use in integration testing. As is the
case with all fonns of testing, integration test data must consider both normal and
unusual situations. For example, integration resting might include passing cypica I records
between rwo programs, followed by blank records, to simulate an unusual event or an
operational problem. Test data that simulates actual conditions should be used because
the interface that links the programs i.s being tested. A testing sequence should not move
ro the integration test scagc unless it h.as performed properly in all unit tests.
I I. 7 .3 System Testing
After completing integration resting, system testing is performed, which involves
the entire information sysrem, as shown in Figure 11-21. A system test includes al l
likely processing situations and is intended to assure users, developers, and managers
that rhe program meets al l specifications and that all necessary features have been
included.
During a system test, users enter data, including sample:. of acrual, or live, data,
perform queries, and produce reports to simulate actual operating condirions. All
processing options and ourputs are verified by users and the IT project development
ream to ensure char the S)'Stem functions correctly. Commercial !>Ofrware packages
musr undergo sysrem testing similar ro that of in-house developed systems, alrhough
unit and integration resting usually are nor performed. Regardless of how rhe system
was developed, system resting has rhe following major objectives:
• Perform a final rest of all programs
• Verify that the system will bandle aU input data properly, both valid and
invalid
• Ensure char the IT staff has the documentation and instructions needed to
operate the system properly aod that backup and restart capabilities of the
system arc adequate (the derails of creating this sort of documentation are discussed
later in this chapter)
• Demonstrate that users can interact with the system succe!>sfully
• Verify that all system components are integrated properly and rhar actual processing
situations will be bandied correctly
• Confi rm that rhe information system can handle predicted volumes of dara in a
timely and efficient manner
Successful completion of system resting is the key rouser and management
approval, which is why system tests sometimes are called acceptance tests. f inal
acceptance resrs, however, are performed during systems installation and evaluation
wirh actual user data, as described later in this chapter.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

1'111110 ~y.stonu; !ilf!IOOl
11.8 Documentation
373
How much testing is necessary depends on rhe situation and requires good
judgment and input from other IT staff members, users, and management.
Unfortunate!), IT projccr managers often are pressured ro finish resting quickly and
hand the system over to users. Common reasons for premature or rushed tesnng
are demands from u~er~, righr systems development budgers, and demands from top
management to finish projects early. Those pressures hinder the resring process and
often have detrimental effects on rhe final product's quality.
Tesring can be a cost-effective means of providing a quality product. Every error
caught durmg resting eliminates porenrial expenses and operational problems. No
system, however, is I OOo/o error-free. Often, errors go undetected until the system
becomes operational. Errors that affect the integriry or accuracy of data must be corrected
immediately. Minor errors, such as typographical errors in the user interface,
can be corrected later.
Some users want a system that is a completely finished product, whi le others
realize that minor changes can be treated as maintenance items after the system
is operational. ln the fi nal analysis, a decision m ust be made whether or nor to
postpone system installation il problems are discovered. If conflicting views exist,
management will decide whether or not to install! the system after a fu ll discussion
of the options.
You work at Your Move, Inc., a large retailer specializing in games of all kinds. The company is in
the final stages of developing a new inventory management system. and the IT manager wants
you to handle the testing.
"Be sure you put lots of errors into the test data." she said. "Users are bound to
make mistakes, and we need to design built-in safeguards that will catch the mistakes, and
either fix them automatically or alert the user to the problem."
Of course. this comment makes a lot of sense, but you've never done this before. and
you wonder how to proceed. Should you try to invent every possible data error1 How will
you know that you've thought of every siwation that could occur1 Consider the problem,
develop an approach, and write up your plan in a brief memo.
Docu1ne11tation describes an info rmation system and helps the users, managers, and
IT staff who must interact with it. Accurate documentation can reduce system downtime,
cut costs, and speed up maintenance tasks. Figure 11-22 shows an example of
the Rigi research environment that can automate the documentation process and help
software deve l ope r ~ generate accurate, comprehensive reference material through
derailed source code analysis.
Documentation is essential for successful system operation and maintenance. In
addition co supporting a system's users, accurate .documentation is essential fo r IT
staff members who must modify the system, add a new feature, or perform maintenance.
Documentation includes program documentation, system documentation,
operations documentation, and user documentation.
r..,,...JID)r-..1--. 4•111.-.•.._..... ,~.n .... .,...~ • ........._ .... ..__..,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

374 11 .8 Documentation
-..,,,_...., __ 7'1lGIO)W.JID
Science of Computer Programming
R -
Rigi- An environment for software reverse engineering, exploration,
visualization, and redocumentation
Holger M. Kienle, Hausi A. Miiller·
'"'-"""'"'"~
AlTICLE INP O
_.......,,
liet'ffltd JO IWlwtllbtt lOOt
ltctCcNed lt1 tf\llifd form 15 oet*t 2009
Acttplfd JO Orrullit'r DB
Av•lllble Df'lw 10 NOYf'mbrf 2009
ll)'wiorG:
,....,. lllrwr4e ~flllntttm& __•Ion
,.... ..... 1<11 ..
Tool requltttlWfttl
ABSTRACT
Th• Rlp envtronlTlC'llt IJ 1 lllitWt rewth tool di.It P<O'idet lllnaJon•l•tl' to .....,.
l'fllinttr toltw.,. sy><<nu. Wlth Rill Lorae JYSl..,,t <1n bt1n1lyud. lntm<1t..iy .. plattd,
tummorlztd. ind da<umm...S. TblJ IJ 1uppon<d with P•ll•fS to tJClt.a lnfonNdon from
10Urce code • .n f'XCNote fonNt to 5CO~ tJttrac:ltd ln!orm•tion. ~Ml)"Ht ro m.nsform
and •bwact lnform.uton. • scripdl\I l>l\IUil&• and llbmy to '"'°""'" ch• _..,,
ind i Yl:SiYllution tna(nt to rnttr•ctivel.)' oplore 1nd m•nlpu.1~tt lntorm.ulon fn tht
fonn or cyp<d. dltoct<d. hl<mthlc.l 1roplu. In thl• P<P<f we dr>cnbt Rlal't m.iln
compoaents ..nd funruomlltlo!. ond ,...., Its lmpoct on ..,..,.., .,,p,.,..riO& ,.,.,rdi.
1\11tbennot .. wt ditcuu Rlp't Mdllt<a"" ind dttiCn dtdJlont thlt led to • dtcouplln&
tJI l!Qjor functiaruli~ •nd ~ble LOOI vc:1tn~bU11y1 inttropen.bibty md tnd .. uwr
programm.tbltity.
Cl 20<IG llMYitt IV All "&hti m<Md
FIGURE 11 ·ll Rigl Is a research environment that uses reverse engineering technology to
provide software redocumentation capabilities to support program understanding.
Sow-<•
•:O'l.. ·If"'
I 1.8. 1 Program Documentation
Program documcntacion describes the inputs, outputs, and processing logic for all
program modules. The program documentation process stans in che systems analysis
phase and continues during systems implementation. Analrsts prepare overall documentation,
such as process descriptions and report layouts, early in the SDLC. This
documentation guides programmers, who construct modules chat are well supported
by internal and external comments and descriptions that can be understood and
maintained easily. A systems analyst usually verifies that program documentation is
complete and accurate.
System developers also use defect tracking software, sometimes called bug tracking
~oft ware, ro document •ind track program defects, code changes, and replacemenc
code, called patches.
I 1.8.2 Syste m Documentation
System documentation descri hes the system's functions and how they arc implemented.
System documentation includes dara dictionary entries, DFDs, object models,
screen layouts, source documents, arnd the systems request that initiated the project.
System documentation is a necessary reference material for the programmers and
:rnalysts who must support and maintain the system.
Mo5t of rhc system documentation is prepared during rhe sy~cems analysis and sys·
rems design phases. During the systems implementation phase, an analyst musr review
prior documentation co verify thar ic is complete, accurate, and up to dace, including
any changes made during the implementation process. For example, if a screen or
report has been modified, the analyst must update the documentation. Updates co the
system documentation should be made in a timely manner to prevent oversights.
(....,..... J:gl( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

I 1.8 Documentation
if' uuo 4
y.st:o1ns; rnp1o:n
375
I 1.8.3 Operations Documentation
If the informanon system environment involves a mainframe or centrali1ed servers,
the analyst must prepare documentation for the IT group that supports cenrrali1ed
operations. A mainframe installarion might require the scheduling of batch johs and
the distribution of printed reports. In this type of environment, the IT operations staff
serves as the first point of contact when users experience problems with the system.
Operations documentation contains all the information needed for processing and
distributing on line and printed output. Typical operations documentation mcludes the
following information:
• Progr:im, systems analyst, programmer, and system identification
• Scheduling mformation for printed output, such as report run frequency and
deadlines
• Input files and where they originate; output files and destinations
• Email and report distribution lists
• Special forms required, including online forms
• Error and informational messages to operators and restarc procedures
• Special instructions, such as security requirements
Operations documentation should be clear, concise, and available online if possible.
If the IT department has an operations group, the documentation should be
reviewed with them, early and often, to identify any problems. By keeping the operations
group informed at every phase of the SDLC, operations documentation can be
developed as the project progresses.
I 1.8.4 User Documentation
User documentation consists of instructions and information to users who will interact
with the system and includes user manuals, help screens, and online tutorials.
Programmers or systems analysts usually create program documentation and system
documentation. To produce effective and clear user documentation-and hence have
a successful project-someone with expert skills in this area doing the development
is needed, just as someone with expert skills developing the software is needed. The
skill set required to develop documentation usually is not the same as that to develop
a system. This is parttcularly rrue in the world of online documentation, which needs
to coordinate with prinr documentation and inrranet and lnternet information. Technical
writing requires specialized ski lls, and competent technical writers are valuable
members of the IT team.
just as a \ystem cannot be thrown together in several days, documentation cannot
be added at rhe end of the project. While this has always been rrue of traditional
user documentation, thi~ i ~ an even more critical issue now that online help and context-sensitive
help are often used. Context-sensitive help is part of the program and it
has to be rested roo.
Systems analysts usually arc responsible for preparing documentation LO help users
learn the system. In larger companies, a technical support team that includes technical
writers might assist in the preparation of user documentation and training materials.
Regardless of the delivery method, user documentation must be clear, understandable,
and readily accessible to users at all levels.
User documentation includes the following:
• A system over\'iew that clear!}' describes all major system features, capabilities,
and lim1rations
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

376 11.8 Documentation
• Description of source document content, preparation, processing, and samples
• Overview of menu and dara entry screen options, contents, and processing
instrucrions
• Examples of reports that are produced regularly or available at the user's
request, including samples
• Security and audit trail information
• Explanation of responsibiliry for specific input, output, or processing
requirements
• Procedures for requesting changes and reporting problems
• Examples of exceptions and error situations
• frequently asked questions (FAQs)
• Explanation of how to get help and procedures for updating the user manual
I 1.8.S Online Documentation
Most u~ers now prefer online documentation, which provides immediate help when
they have questions or encounter problems. Many users are accustomed to context-sensitive
help screens, hints and tips, hypertext, on-screen demos, and other userfriendly
features commonly found in popular software packages; they expect the same
kind of support for in-house developed software.
If the system will include online documentation, that fact needs to be identified
as one of the system requirements. If someone other than the analysts who arc developing
the system will create the documentation, that person or group needs to be
involved as early as possible to become familiar with the software and begin developing
the required documentation and support material. In addition, system developers
must determine whether the documentation will be available from within the
program or as a separate entity in che form of a tutorial, slide presentation, reference
manual, or website. lf necessary, links should be created within the program that will
take the user to the appropriate documentation.
Effective online documentation is an important productivity tool because it
empowers users and reduces the time that IT staff members must spend in providing
telephone, email, or face-to-face assistance. Interactive tutorials are especially
popular with users who like to learn by doing, and visual impact is very important.
The use of You Tube as a host for tutorial videos has become commonplace. f or
example, Figure 1 1-23 shows LeamCode.academy, which is a popular YouTube
channel offering free web development and website design tutorials.
In addition to program-based assistance, the Internet offers an entirely new level
of comprehensive, immediate support. Many programs include links to websites,
intranet sites, and Internet-based techllical support. f or example, the Cisco Systems
website shown in Figure l l-24 offers a wide range of support services and social
media links that allow Cisco users to collaborate and share their knowledge.
Although online documentation is essential, written documentation material also
ii. valuable, especially in training users and for reference purposes. Systems analysts
or technical writers usually prepare the manual, but many companies invite users to
review the material and participate in the development process.
No matter what form of user documentation the system requires, keep in mind that
it can take a good deal of rime to develop. The time between finishing software coding
and the time when a complete package- including documentation-can be released to
users is entirely dependent on how well the documentation is planned in advance. If
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
I 1.8 Documentation
377
LeamCode.academy
56 1169 ..iblcnbefs
HOME
VIDEOS
Pl.AYLISTS
COMMUNITY CHANNELS ABOUT
161.822 •• 10 mot" .... '°
A complete roedmep to being 1 succe11ful web elev In 20181
The mlndmap wnh aa of lht links; http /lbl1 lyt2p63dS9
Node.JS course!: Imps l/gumrl*d com/1/lqGFI
Jump 10 •section:
• Buie Front End 2 04
• No Matter Which ROUie You T1ke: 4 57
• Front End Englne«: 7 29
R£AOMORE
Fl GU RE I 1 ·ll LearnCode.academy Is a popular You Tube channel offering free web development tutorials, website design
tutorials. and more.
5ourc~ 1- n I"" ""
c ...
"'
Cisco eommun.ty
·---
-- •
•
-­
·-
-·- .__ - -·-
FIGURE 11-24 The Cisco Support Community invites users co contribute valuable experience and documentation using
soc:ial media.
the completion of the project includes providing user documentation, this issue needs
to be addre~ed from the very beginning of the project. Determining what the user
documentation requirements are and ascertaining who will complete the documents
are critical co a time!)' release of the project.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

378 I I . 9 Installation
eglecring user documentation issues until after all the program i complete often
lead to one of two things: (1) the documenrarion will be thrown rogether quickly jusr
ro gcr it our the door on rime, and ir more than likely will be inadequate; or (2) ir will
be done correctly, and rhe product release will be delayed con~iderably.
User training typically is scheduled when rhe system is installed. The training
<;essions offer an ideal opportunity ro distribute the user manual and explain rhe
procedure~ for updaring it in rhe future. Training for users, manager~, and IT sraff is
described l:1rer in this chapter.
I I 0 I ~ 1 :Ttn
After system resting is complete, the resulrs are presented to nrnnagement. The test
results should be described, the sratus of all required documentation updated, and input
from users who participated in syste1n testing su1nmarized. Oemiled time schedules,
cost estimates, and staffing requirements for making the system fully operational
should also be provided. If system resting produced no technical, economical, or
operational problems, management determines a schedule for system insralhnion.
T he following syste1n installation tasks are performed for every information systems
project, whether the applicarioll is developed in-house or purchased as a commercial
package:
• Prepare a separate operational and test environment
• Perform system changeover
• Perform daca conversion
• Provide training for users, managers, and IT staff
• Carry our posr-implemenrarion rasks
I I. 9. I Operatio nal and Test Environments
Recall thar an environment, or platform, is a specific combination of hardware and
sofrw:1re. The environment for the actual system operation is c:1lled the opcrnrional
en\ ironmenr or production environment. The environment char analysts and
programmers use ro develop and maintain programs is called rhe t c~ t environment.
A separate rest environment is necessary to maintain sysrem securiry and integriry
and prorecr rhe operarional environment. Typically, the resr environment resides on a
limited-access worksration or server located in the IT department.
Access co the operational environment is !United to users and must strictly be controlled.
Systems analysts and programmers should not have access ro the operational
environment except co correct a system problem or to make authorized modific:1rions
or enhancements. Orherwise, IT department members have no reason ro access rhe
day-LO-day operorional system.
T he rest environment for an infor mation sysrem contain~ copies of all programs,
procedures, and resr data files. Before making any changes to an operational sysrem,
rhe analyst must verify them in rhe resr environment and obtain user approval.
Figure 11-25 shows the differences between test environments and operational
environments.
An effective resring process is essenrial co ensuring product qualiry. Every
experienced systems analyse can teU a story about an apparent!)• innocent program
change char was introduced without being tested properly. In chose stories, rhe
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
379
innocent change invariably ends up causing some unexpected and unwanted changes
to the program. After any modification, rhe same accepcance tests that were run when
the system was developed should be repeated. By rescricring access to the operational
area and performing all tests in a separate environment, the system can be protected
and problems that could damage data or interrupt operations avoided.
IT Staff
Test Environment
Authorized
Changes
Users
Procedures
Programs
Programs
FIGURE 11 -lS The teSl environment versus the operational environment. Note that access
co the test environment is limited to IT staff. while the operational environment is restricted co
users.
The opcrarional environment includes hardware and sofrware configurarions
and settings, syMem uriliries, telecommunications resources, and any ocher
component!> that might affect system performance. Because network capability is
critically important in a clienc/ser\'er environment, connectivity, specificatiorn., and
performance muse be verified before installing any applicarions. All communication~
features in the rest environment should be checked carefully and then checked again
after loading the apphcarions into the operational environment. The documentation
should identify all network specifications and settings, including technical and
operational requiremencs for communicarions hardware and software. If network
resources must be built or upgraded to support the new system, the platform muse be
tested rigorously before system installation begins.
11 .9.2 System Changeover
System changeover is the process of putting the new information system online and
retiring the old system. Changeover can be rapid or slow, depending on the method.
The four changeover methods are direct cucover, parallel operation, pilot operation,
and phased operation. Direct curover is similar to throwing a switch that instantly
changes over from the old system to the new. Parallel operation requires that both
systems run simultaneously for a specified period , which is the slowest method. T he
other methods, pilot and phased operation, fall somewhere between direct cutover
and parallel operntion. Figure 1 1-26 illuscrates the four system changeover methods.
DIRECT CUTOVER: The direct curover approach causes the changeover from the
old system to the new sysrem to occur immediately when che new system becomes
operational. Direct cutover usually is the leasr expensive changeover method because
the IT group has ro operate and maintain only one system at a rime.

380 I I . 9 Installation
OldSJ I tr
DIRECT CUTOVER
Old9)111R
Ntlw &ylfen I
PARALLEL OPERATION
PILOT OPERATION
Oldew••••
PHASED OPERATION
FIGURE 11 -26 The lour system changeover methods.
Direct cutover, however, involves more risk than other changeover methods.
Regardless of how thoroughly and carefully testing and traming is conducted, some
difficulties can arise when the system goes into operation. Problems can result from
data situations that were not rested or anticipated or from errors caused b)• user<; or
operators. A system also can encoun ter difficulties because live data typically occurs
in much larger volumes than test data.
Although mitial implementation problems arc a concern with all four
changeover methods, they are mosr significant when the direct cutover approach
is used. Detecting minor errors also is more difficult with direct cutover because
users cannot verif)' current output by comparing it to output from the old system.
~lajor errors can cause a system process to terminate abnormall y, and with the
direct cutover method, reverting to the old system as a backup option is not
possible.
Companies often choose rbe direct cutover method for implementing commercial
software packages because they feel tbat commercial packages involve less risk
of total system failure. Commercial software is certainly not risk-free, but the software
vendor usually ma intains an extensive knowledge base and can supply reliable,
prompt fixes for most problems.
For systems developed in-house, most organizations use direct curover only for
noncritical situations. Direct cutover might be the only choice, however, if the operating
environmenr cannot support both the o ld and new systems or if the old and new
sys rem~ arc incomparible.
Timing is very important when using a direct cutover strategy. Most systems operate
on weekly, monthly, quarterly, and yearly cycles. For example, consider a payroll system
that produces output on a weekly basis. Some employees are paid twice a month,
however, so the system also operates semimonthly. !vlonthly, quarterly, and annual
reports also require the system to produce output at the end of every month, quarter,
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
381
and year. When a C)'clical information system is implemenced in che middle of any cycle,
complete processing for the full cycle requires information from both the old and rhe
new !.ysrems. To minimize rhe need ro require information from rwo different systems,
C)•clical information sy terns usually are converted using rhe direct cutover method at
the beginning of a quarter, calendar year, or fiscal year.
PARALLEL OPERATION: The parallel operation changeover merhod require chat
both the old and the new information systems operate fully for a specified period.
Data is input 1nco boch systems, and output generated by the new system is compared
with che equivalent output from the old system. When users, management, and
the IT group are satisfied chac the new system operates correctly, rhe old system is
terminated.
The mosr obvious advanrage of parallel operation is lower risk. lf the new system
docs not work correctly, rhe compall)' can use the old system as a backup until appro·
priace changes are made. lr is much easier co verify that the new system is working
properly under parallel operation rhan under direct cutover, because the output from
both systems is compared and verified during parallel operation.
Parallel operation, however, docs have some disadvantages. First, it is rhc costliest
changeover method. Because both the old and the new systems are in fu ll operation,
the company pays for both systems during the parallel period. Users must work in
both systems and the company might need temporary employees to handle che ex'tra
workload. In addition, running both systems might place a burden on rhe operating
environment and cause proces~ing delays.
Parallel operation is not practical if the old and new systems are incompatible
technically or if rhe operaring environment cannot support both systems. Parnllcl
operation also is inappropriate when the rwo systems perform different fum: rion~ or
if rhe new sysrem involves a new method of business operarions.
PILOT OPERATION: The pilot operation changeover method involves
implementmg the complete new system ar a selected location of the company.
A new sales reporrmg system, for instance, might be implemented in only one
branch office, or a new payroll system mighr be installed in only one department.
In these examples, che group char uses the new system first is called the pilot
sire. During pilor operation, the old system continues to operate for rhe entire
organization, including che pilot sire. After the system proves successful ar the
pilot sire, ir is implemented in the rest of the organization, usually using rhe direcr
curover method. Therefore, pilot operation is a combination of parallel operation
and direct cutover methods.
Restricting the implcmenrarion co a pilot site reduces the risk of system failure,
compared with a direct curover method. Operating both systems for only the pilot
site is less expensive than a parallel operation for the entire company. ln addition, if
a parallel approach ro complete the implementatEon is used lacer on, the changeover
period can be much shorter if the system proves successful ar rhe pilot sire.
PHASED OPERATION: The phased operation changeover method allows rhe new
sysrem to be implemented in srages, or modules. f or example, instead of implementing
a new manufacturing system all at once, the materials management subsy~tem
is installed first, then rhe production control subsystem, then the job cost subsystem,
and so on. Each subsysrem can be implemented by using any of the other three
changeover methods.
Analysts sometimes confuse phased and piloc operation methods. Both methods
combine dtrecc cutover and parallel operation to reduce risks and costs. With phased
_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

382 I I. 9 Installation
operation, however, only a part of the system is given to all users, while pilot operarion
provides the enrire system burro only some users.
One advantage of a phased approach is that the risk of errors or failures is limited
co the implemented module only. For instance, if a new producnon control subS)'Stem
fail5 to operate properly, thar failure might not affect the new purcha5ing subS)'Stem
or the ex1sring shop floor conrrol subsystem.
Phased operation is less expensive than full parallel operation because the analyst
has to work with only one part of the system at a time. A phased approach is not possible,
however, if the system cannot be separated easily into logical modules or segments.
In addition, 1f the system involves a large number of separate phases, phased
operation can cost more than a pilot approach.
Figure 11-27 shows that each changeover method has risk and cost factors. A
systems analyst must weigh the advantages and disadvantages of each method and
recommend rhe best choice in a given situation. The final changeover decision will be
based on input from the IT staff, users, and management-and che choice must reflect
the nature of the business and the degree of acceptable risk.
R
I
s
K
High
Medium
Low
,__
low
I
Direct
cut over
-
Pi IOI
operation
Phased
operabon
. -
-
Parahel
operabon
Med1Um
,______ ____ __,
COST >
•
High
FIGURE 11-27 Relauve risk and con charactensacs of the four c~ngeover methods.
You are a systems analyst at Global Cooling. a leading manufacturer of air conditioning units.
You are leading a team that i.s developing a new production scheduling system. The project is
now in the application development stage. You are in the final stages of integration testing. Your
supervisor is eager to implement the new application ahead of schedule and asked if you could
trim system testing from two weeks to three days and use a direct cutover method instead
of the parallel changeover method that originally was planned. Write a brief memo expressing
your views.
11.9.3 Data Conversion
Data conversion is an important pan of the system installation process. During data
conversion, existing data is loaded into the new system. Depending on the system,
data conversion can be done before, during, or after the operational environment is
r..,,...J1DOr-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
383
complete. A data conversion plan should be developed as early as possible, and rhe
conversion process should be resred when rhe resr environment is developed.
When a new system replaces an existing sysrem, rhe data con\'ersion process
hould be automated, if possible. The old sysrem might be capable of exporting data
in an acceptable format for che new system or in a srandard format, such as A Cll
or ODBC. Open database connecri\ iry (ODBC) is an industry-standard protocol
that allows DB~lSs from various vendors ro interact and exchange data. Nlost database
vendors provide ODBC dri,·ers, which are a form of middleware. As discussed
in Chapter 10, middleware connects dissimilar applications and enables chem to
communicate.
If a srandard format is nor available, a program co extract the data and convert
it to an acceprable format must be developed. Data conversion is more difficult
when the new system replaces a manual systetn, because all data must be entered
manually unless it can be scanned. Even when the data conversion is automated,
a new system often requires additional dara items, wbich might require manual
entry.
Strict input controls should be maintained during the conversion process,
when data is extremely vulnerable. System control measures should be in place
and operational to protect data from unauthorized access and to help prevent
erroneous input.
Even with careful data conversion and input controls, some errors will occur. For
example, duplicate customer records or inconsistent pan numbers mighr have been
tolerated by rhe old system but will cause the new system to crash. Mosr organizations
require that users verify all data, correct all errors, and supply every missing data item
during conversion. Alrhough rhe process can be time consuming and expensive, ic is
essenrial rhar rhe new system be loaded with accurate, error-free dara.
11.9.4 Training
No S)'Stem can be successful without proper training, whether ir in,•olves software,
hardware, or manufacturing. A successful informarion system requires training for users,
manager;, and IT staff members. The entire systems development effort can depend on
whether or noc people undersrand the system and know how ro use it effecrivel)•.
TRAINING PLAN: A training plan should be considered early in the syscems
development process. As documentation is created, consider how to use the material
in future training sessions. When the system is implemented, it is essential ro provide
the right training for che right people ar the right rime. The first step is ro idenri fy
who should receive training and whar training is needed. The organjzation should be
carefully examined to determine how the system will support business operations and
who will be involved or affecced. Figure 11-28 shows specific traini11g topics for users,
managers, and IT staff. Nore rhat each group needs a mix of general background and
detailed informarion ro understand and use the system.
As shown in Figure I 1-28, the three main groups for training are users, managers,
and IT staff. A manager docs not need to understand every submenu or feature, but
he or she does need a system overview to ensure chat users are being trained properly
and are using the system correctly. Similarly, users need to know how to perform their
day-ro-day job functions, bur they do not need ro know how rhe company allocates
system operational charges among user departments. IT staff people probably need
the mo r information. To support the new system, they must have a clear understanding
of how the system functions, how it supports business requirements, and rhe skills
that users need ro operate the system and perfonn their tasks.
......... ""_.. ...
_
.-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,.., ...,..., ~..,._.. .............. ~ ..
__.... ................... ~ ~·~ --- - ·· ·---~~-.,.- "~ ........... --......

384
I I. 9 Installation
System overview
Key terms
Start·up and shut down
Main menu and submenus
Icons and shortcut keys
Ma)Or system functions
Onkne and external Help
Frequent y asked questions
Troubleshooting guide
Hand ing emergencies
G otect origin
Cost-benefit analyslS
Support for business goals
Key IT contact people
Handt ng system charges
Major reports and displays
Requesting enhancements
User training
USERS
MANAGERS
TRAINING
Project history and justification
System architecture
System documentation
Typical user questions
Vendor support
Logging and resolving problems
Technical training for IT staff
User and management lraming
IT STAFF
FIGURE 11-28 Examples of tr.lining topics for three different groups. Users. man~ers . and IT saff members
have different training needs.
Afrcr the ohjccrives arc idenrified, how the company will provide rraining must be
determined. The main choices are to obtain training from vendors, outside training
firms, or use IT sraff and other in-house resources.
VENDOR TRAINING: If the system includes the purchase of sofrware or hardware,
then vendor-su pplied training is one of the fea tures that should be included in the
requests for proposal (RFP) and requests for quotation (RFQ) chat are sent to potentia
l vendors.
Many hardwa re and software vendors offer training programs free or at a nominal
cosr fo r the products they sell. [n other cases, the company mighc negotiate the
price for training, depending on their relationship with the vendor and the prospect of
fu ture purchases. The training usuall y is conducted at the vendor's sire by experienced
trainers who provide valuable hands-on experience. If a large number of people need
training, classes mar be held at the co111pany's location.
Vendor training often gives the best return on training dollars because it is focused
on products rhar the vendor develop ed. The scope of vendor training, however,
usually is limited to a standard version of the vendor's software or hardware. The
vendor's training may have robe supplemented with in-house training, especially if
the IT staff customized the vendor's package.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, - Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
385
WEBINARS, PODCASTS, AND TUTORIALS: Many vendors offer web-based
craining options, including webinars, podcasts, and rucorials. A webinar, which
combines che words web and seminar, is an Internet-based rraining session thac
provides an inceracrivc experience. Most webinar are scheduled evencs with a group
of preregistered users and an online presenter or instructor. A prerecorded webmar
session al o can be delivered a a webcast, which is a one-way cransmission, whenever
a user want~ or needs training support.
A podcast refers to a web-based broadcast that allows a user co download multimedia
files to a PC or portable device. Podcasrs can be prescheduled, made available on
demand, or delivered as auromaric updares, depending on a user's preference. An ad\'antage
of a podcast is chac subscribers can access the recorded material anywhere, anytime.
A tutorial ts a series of on line interactive lessons that present materia I and provide
a dialog with users. Software vendors can develop tutorials, or a company's IT team
can develop them. They can also be developed by chird parties for popular software
packages and sold separately online.
OUTSIDE TRAINING RESOURCES: Independent training firms can also provide
in-house hardware or software training. If vendor training is not practical and the
project organization docs not have the internal resources to perform the training, outside
training consultants can be a viable alternative.
The rapid expansion of informarion technology has produced tremendous growth
in the computer-training field. Many training consulranrs, institutes, and firms are
available that provide either standardized or customized training packages. For example,
many people now use one of the many sources of online training, such as Udemy
shown in Figure 11-29, ro sarisfy their training needs. Assistance can also be sought
from nonprofit ources with an interest in training, including universities, industry
associarions, and information management organizarions.
Q --.......... .._____ 'U ..... -
.....
l'ht,..,.,.,..,..... ........., <OWf'Mt.
c.... ...... llCIO.l9_,......,.
...._,...........,....
. - ..
-
-- ..
.. .
... .__
FIGURE 11-29 Udcmy 1s one of many sources of onltne uaining.
So.ft.:
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

386 I I . 9 Installation
TRAININ G TIPS: The IT sea ff and user departments often share re pon~ibiliry for
developing and conclucring rraining programs for internally developed software. If rhe
organi1ation has a service desk, their staff might be able to handle user training.
Multimedia is an effective training method. Presentation software, such as
Microsoft PowerPoint or Apple Keynote, can be used to design training ses ions that
combine slides, animation, and sound. Programs that capture actual keystrokes and
mouse action,, such as Camtasia and Panopto (shown in Figure 11 -30), can be used
to replay rhe screens as a demonstration for users. If a media or graphic arrs group
is available, they can help prepare training aids such as videos, charts, and orher
insrrucnonal materials.
Panopto
• .......... c-.t
'°'....... f'O'ldl«.e!O\ lllncuas ~ -
• LM ...... W.."""°' ..,.._ ~ ..
Flexible video recording software for any
presentation .
.......
..................,.................. llll'llla,,.., ! ~.,
.......... ~ ............ ......,_...~........ ,.._.~•--••"'1.,.:1 tad.witll'...,. .. llfiM tOll.-0
..................... ....... ~_...., .,.~
__... .... .............
.....-.;
~ (.... ~ ·-- .... = •
..,., ....... _.... ,.,...,..
.......... ~.., ...... _......___.09 ....... .,....,...., .......
FIGURE 11 -30 Panopto is a screen capture and video presentation program that can be used to prepare
webcasu and online l~ ming materials.
~tc:• J'~~ CO'"'
Keep the following guideJjnes in mind when developing a training program:
• Tram people in grottps, rvith separate tra111i11g programs for d1st111ct groups.
Group training makes the most efficient use of rime and training facilities.
In addiuon, if che group is small, trainees can learn from the questions and
problems of ochers. A training program must address the job interest and
skills of a wide r::inge of participants. For example, IT sta ff personnel and
users require very different information. Problemi. often a r i~e when bome
participants have technical backgrounds and others do not. A single program
will not meet everyone's needs.
• Select the most effective place to conduct the training. Training employees at
rhe company's location Qffers several advantages. Employees incur no travel
expense, they can respond to focal emergencies that require immediate arten·
tion, and training can take place in the actual environment where the system
will operate. There can be some disadvantages, however. Employees who are
distracted by telephone calls and other duries will not get the full benefit of
the training. In addition, using the organization's computer facilities for rrain·
ing can disrupt normal operarions and limit rhe amount of actual hands-on
trJ111111g.
• Provide for learning by hearing, seeing, and doing. Some people learn best
from lectures, discussions, and question-and-answer sessions. Others learn best
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
387
from viewing demonstrations or from reading documentation and other material.
Most people learn besr from hands-on experience. Training that support
each type of learning hould be provided.
• Rely 011 prev1011s trainees. Airer one group of users has been trained, they
can assist others. Users often learn more quickly from coworker~ who share
common experience and job responsibilities. Using a train-the-trainer strategy,
knowledgeable users can be selected who rhen conduct sessions for others.
When utilizing train-the-trainer techniques, the initiaJ training must include not
only the use of the application or system but also some instruction on how to
present the materials effectively.
INTERACTIVE TRAIN ING: Usually, a relationship exists between training methods
and costs. Training an airline pilot in a state-of-the-arr simulator is quite different
from helping corporate users learn a new inventory system. Obviously, training budgets
arc business decisions, and IT staff sometimes has ro work with the resources
that are available, rather than the resources they wish chey had. Most people prefer
hands-on training. However, other less-expensive methods can be used, including
training manuals, printed handouts, and online materials.
If a new ~ysrcm is being launched and the resources to develop formal training
materials are lacking, a series of dialog boxes chat respond with help information
and sugge tions whenever users select various menu topics can ~rill
be designed.
A good user interface also includes helpful error messages and hints, as discussed
in Chapter 8. However, rhe most effective training is interaccive, self-paced, and
multimedia-based. Online training and video rucorials are discussed in the following
sections.
ONLINE TRAINING: Regardless of the insrrucrional method, training lessons should
include step-by-step instructions for using the fearurcs of the information system.
Training materials should resemble acrual screens, and tasks should be typical of a
user's daily work-the more realistic, the better. Video lessons arc particularly popular
onlinc. For example, Figure 11-31 shows a sample lesson on learning Python in an
online rutorial from lynda.com.
Sophisticated online training systems may offer interactive sessions where users
can perform practice rasks and view feedback. Online training materials also should
include a reference section that summarizes all options and commands, lists all possible
error messages, and lists whar actions rhe user should take when a problem
arises.
When training is complete, many organizations conduct a full-scale rest, or
~i mula ti o n , which is a dress rehearsal for users and lT support srnff. Organizarions
include all procedures, such as those thar they execute only ar the end of a month,
quaner, or year, in the simulation. As questions or problems arise, the participants
consult the system documenrarion, help screens, or each other to determine
appropriate answers or actions. This h1ll-scale test provides valuable experience
and builds confidence for everyone involved with the new system.
11.9.S Post-lmplementationTasks
Once the new system is installed and operational, two additional tasks must be performed:
(J) prepare a post-implementation evaluation, and (2) deliver a final report
to management.
......... ""_.. ...
_
.-................. ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> -"'Allf'W ~-........ . ...... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~ ~·~--- - ·· ·---~~-.,.- "~ ........... --......

388
I I. 9 Installation
Python Euentlel Training
o. .... -i.w Trenscrlpt View Oflllne El<Ofdse Fllft
_ - -(5)
..
D\Atto _ - ·-~--ft K-~GI""""'
owv• .._.-... ..,_..,
""""'°V Gooll'O •.,__... •-""Ill'..._.....,""""' J."'
au•astiowlOUM~llOC.- •rq;.s.,_.,.._......,.~
TM CW (Orrililfl N ~al N lllnQl.-oe Jyl'W Md 1M09. 11 ..... IO I aid,._,_
wct\•.,...oa•:&::4.,.,• .......... LWf'....,JtoMatlld~n.....,•-...:
"""''°
__
... ~ ,...... ~ Udant..end ,.,..,"'°"'...............
..... , "·--.. Ol ... '11111--0!L
-"'-""" ·-·· -... ~-----.. """"'-
FIGURE 11 -31 A sample lesson on learning Python in an onhne tutorial from lynda.corn.
Sout"CS " "f1 • •• ~
•• 1
-
'ih''
'l&''P.'
-
POST-IMPLEMENTATION EVALUATION: A post-implemencauon evaluarion
assesses rhe overall quality of rhe information systen1. The evaluation verifies rhar the
new &ysrcm meets specified requirements, complies wid1 user objectives, and produces
the anticipated benefirs. In addition, by providing feedback to the development ream,
the evaluation also helps improve IT development practices for future projects.
A posr-implemenration evaluation should examine all aspects of the development
effort and the end product-the developed in.formation system. A typica l evaluation
includes feedback for the following a reas:
• Accuracy, completeness, and timeliness of information system output
• User satisfaction
• System reliability and maincainabiliry
• Adequacy of system controls and securit)' measures
• Hardware efficiency and platform performance
• Effectiveness of database implementation
• Performance of the IT team
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

if' uuo 4
y.st:o1ns; rnp1o:n
11.9 Installation
389
• Completeness and quality of documencation
• Quality and effectiveness of training
• Accuracy of cost-benefit estimates and development schedules
The same fact-finding techniques can be applied in a post-implementation evaluation,
wluch were used to determine the system requirements during the systems analysis
phase. \Xlhen evaluating a system, the following should be done:
• Interview members of management and key users
• Observe users and computer operations personnel actually working with the
new information system
• Read all documemation and training materials
• Examine all source documents, output reports, and screen displays
• Use questionnaires to gather information and opinions from a large number of users
• Analyze maintenance and help desk logs
Figure 11 -32 shows the first page of a sample user evaluation form for the new
information system where users eva luate 18 separate elements on a numerical scale,
so the results can be tabulated easily. Following that section, the form provides space
for open-ended comments and suggestions.
- -
iili ~._,,_ . ................. oc Cl
,.._a-'"- ........
...... ..........,., •
" •
(!)
t!:I
x
•
Q
~
POI DOCUMI NI lJBRARY.
U..,tv. ......... ,...M
,.,,_ ,
"""tit.,....._ ttlf ~,,._ r
,..,......,yow .~
jo.t·
,~.. __ ,...__,.,..._,..... ..._..._ ..........
llM•I IDOi
mmo °"""'
I """'................ .
1 J s
t ~ ...... o1111.tm111Kiof! I 2 l s
l l.e«olv.e l 2 J '
• .-.......- l J • s •
'
___ _
USll INfUtfACI
> 0.l'ffyol._Ntt .....
,
l s •
......_ 2 l > I
I ( ;ne ~---.. 2 l > •
I
, J s
• °' '
(\lrlJy tttOf mttallf'l I z J • s 6
..
~lty
-II c..-
10 " twnlO\ol lrlPIA tnOr• l • s •
INK>ltMAllON lfCHHOlOG't' STAFF
U toop.,r .11on
·----'
,
J 5
•
2 ,
"_... ky
6
t l ~· - I J ' $ 6
I• ~Jnt of Pl()flN 2 J $
•
S'i ~IQl\·,.t.Jlt J • s
•
,.._lllG
,
_ __ I 2 l
" """"""- • s
, 11 ..
""iOlltWffti!'9
'
I J 5 J • 5
•
'
'
FIGURE 11 -32 Sample user evaluation form.The numerical scale allows easy tabulation
e1f resulu. FolloWing this section. the form provides space fe1r open-ended comments and
suggestions.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-................ ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .......,..""_......-................. ..__ __.... ................... ~~·~---- ··----~~-.,.-"~...........--......

390 I I . 9 Installation
\'(lhcncvcr possible, people who \·vere not directly involved in developing the system
should conduct the post-implementation evaluation. IT sraff and users usually
perform the evaluation, although some firms use an internal audit group or independent
auditors to ensure the accuracy and completeness of the evaluation.
\'(then to perform a post-implementation evaluation for a new system is nor always
clear. Users can forget details of the developmental effort if too much time clap cs
before the evaluation. Afcer several months or a year, for instance, users might not
remember whether they learned a procedure through training, from user documentation,
or by experimenting with the system on their own.
Users also might forget their impressions of IT team members over nme.
An important purpose of the post-implementation evaluation is to improve the
quality of IT department functions, including interaction with users, rraining, and
documentation. Consequently, the evaluation team should perform the assessment
while users arc able to recall specific incidents, successes, and problems so they can
offer suggestions for improvement.
On the other hand, if the evaluation is done too soon, the users may not be able to
provide sufficient feedback due to la.ck of experience with tbe new system. Post-implementation
evaluation is primarily concerned with assessing the quality of che new
system. If the ream performs the evaluation too soon after implementation, users will
not have enough time to learn the new system and appreciate its strengths and weaknesses.
Although many IT professionals recommend conducting the evaluation after
at le3st six months of system operation, pressure to fin ish the project sooner usually
results in an ea rlier evaluation in order to allow the IT department to move on co
other tasks.
Idea ll y, conducting a posr-implemenrarion evaluation should be srandard practice
for all information systems projects. Sometimes, evaluations are skipped because
users are eager co work with the new sysrem or because IT staff members have more
pressing priorities. In some organizat ions, management might nor recognize the
imporrance and benefirs of a post-implementation evaluation. The evaluations are
extremely important, however, because they en3ble the development ceam and the
IT department to learn what worked and what did not work. Otherwise, developers
might commit the same errors in another system.
FINAL REPORT TO MANAGEMENT: At the end of each SDLC phase, a final report
is submined to management, and the systems implementation phase is no exception.
The report should include the following:
• final versions of all system documentation
• Planned modifications and enhancements to the system that have been
identified
• Reca p of all systems development costs and schedules
• Comparison of actual costs and schedules to the origin31 estimates
• Post-i mplcmcncation evaluation, if it has been performed
The final report to management nla!ks the end of systems development work. T he
nexc chapter examines the role of a systems analyst during systems operation, security,
and support, which is the final phase of the SDLC.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

1'111110 ~y.stonu; !ilf!IOOl
11 . 10 Summary
39 1
You like your new job as lead systems analyse at Yorktown Industries. You were pleased that
your development team completed the new human resources system ahead of schedule and
under budget. You looked forward to receiving the post-implementation evaluation because you
were confident that both the system and the development team would receive high marks from
users and managers.
After the system operated for one month, you received a call from your supervisor.
who told you that you would have to handle the evaluation-even though you headed
the development effort. You told your supervisor that you did not feel comfortable
evaluating your own team's work. You explained that someone who was not involved in
its development should do an independent evaluation. Your supervisor responded that
he had full confidence in your ability to be objective. He explained that no one else was
available and he needed the evaluation quickly so he could move forward with the next
stage in the corporate development plan.
You are troubled about the situation. What should you do, and why?
A team member is handling the testing for the new accounting system, and right now she
is very upset about the most recent results. "It seems like every time we fix one problem.
another pops up! After ten days of testing and adjusting, we are meeting over 90% of the
goals and benchmarks. If we're looking for perfection, we'll never make the implementation
deadline for the new system, and the users will be all over us. Not to mention top
management's reaction to a delay. I'm sure we can resolve some of these issues after the
system becomes operational."
How would you respond to this statement? Are ethical issues involved? What are your
respons1b11ities, as an employee, as an IT professional, and as a coworker?
'I 10 u,.. ...
The systems implcmencarion phase consists o f app lication development, resting,
installation, and evaluation of the new system. During application development,
analysts determine the overa ll design strategy and wo rk with programmers ro
complete design, coding, resting, and documentation. QA is essenti:.il during rhc
implemencation phase . .tvlany companies utilize software engineering concepts and
quality srandards esrablished by the ISO.
Each systems development approach has its ow n set of tools. For example,
structured development relies heavily on DFDs and structure charts. A ~tructure chart
consists of symbols that repre ent program modu les, data couples, control couples,
conditions, and loops. 0-0 methods use a variety of U.tvlL diagrams, 111clud111g
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

392 11.10 Summary
use case, class, sequence, and rransirion srare diagrams. Agile methods tend ro u~e
iterative and incremental models.
System developers also can use more generic tools ro help them translate the system
logic inco properly functioning program modules. These tools include FRDs,
nowcharcs, p~eudocode, decision tables, and decision trees.
Cohesion measure a module's scope and processing characterisncs. A module that
performs a single function or cask has a high degree of cohesion, which is desirable.
Coupling measures relationships and interdependence among modules. Modules
that are relanvely independent are loosely coupled, which is desirable. Cohesion and
coupling concepts are nor only used in structured development but also applicable to
000.
Typically, three steps are followed when creating a structure chart. DFDs and
object models arc reviewed to identify the processes and methods, identify the program
modules and determine concrol-subordinace relationships, and :idd symbols for
couples and loops. The structure chart is chen analyzed co ensure char it is consistent
with the system documentation.
If an agile development approach is used, then the customer creates user stories
char describe required feat ures and priority levels. In agile methodology, new system
releases arc made after many iterations and each is test-driven carefully by rhe
customer.
Programmers perform desk checking, code review, and unit testing rasks during
application development. Systems analysts design the initial rest plans, which include
rest steps and rest data for integration resting and system resting. Integration testing i ~
necessary for programs char interact. T he final step is system resting for the completed
sysrcm. System resting includes users in the resting process.
In addition co system documentation, analysts and technical wricers al~o prepare
operations documentation and user documentation. Operations documenration provide<>
instructions and information co che IT operations group. User documenrarion
consists of instructions and information for users who interact with the ~ystem and
includes user manuals, help screens, and tutorials.
During the installation process, an operational, or production, environment is
established for the new information system char is completely separate from the test
environment. The operational environment concains live data and is accessible only
by authorited users. All future changes co the system must be verified in the rest
env1ronmenc before they are applied co the operational environment.
System changeover is the process of putting che new system into operation. Four
changeover methods exist: direct cutover, parallel operation, pilot operation, and
phased operation. With direct curover, the old system scops and the new system
:.tarts simultaneously; direct cutover is the least expensive but the riskiest changeover
method. With p:irallel operation, users operate both the old and new information
systems for some period of time; parallel operation is the most expensive and least
risky of rhe changeover methods. Pilot operation and phased operacion represent
compromises bccween direct cutover and parallel operation; both methods arc less
risky than direct cu rover and less costly than parallel operation. With pilot operarion,
a specified group within the organization uses the new system for a period of time,
while the old system continues to operate for the rest of the users. After the system
proves successful at the pilot sire, it is implemented throughout the organization. With
phased operation, the system is implemented in the entire organization, bur only one
module at a rime, until the entire system is operational.
Dara conversion often is necessary when installing a new informarion system.
\'Qhcn a new system replaces a computerized system, rhe dara conversion process
~hould be automated if possible. The old system might be capable of exporting data
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
if' uuo 4
y.st:o1ns; rnp1o:n
I 1.10 Summary
393
in a format rhar the new system can use, or the data might have to be extracted and
converted to an acceptable format. Dara conversion from a manual system often
requires labor-intensi,·e data entry or scanning. Even when data con,·ersion can he
automated, a new ystem often requires additional data items, which might require
manual entry. Strict mpur controls are important during the conversion process ro
protect data integrity and qualiry. Typically, data is verified, corrected, and updated
durmg the conversion process.
Everyone who interacts with the new information system should receive training
appropriate co his or her role and skills. The IT department usually 1s responsible for
training. Software or hardware vendors or professional training organizanons also
can provide training. When a training program is developed, remember the following
guidelines: train people in groups; utilize people already trained to help train others;
develop separate programs for distinct employee groups; and provide for learning by
using discussions, demonstrations, documentation, training manuals, tutorials, webinars,
and podcasts. Users learn better with interacrive, sell-paced training methods.
A post-implementation evaluation assesses and reports on rhe quality of the new
system and the work done by rhe projecr ream. Although it is best if people who
were not involved in rhe systems developmenr effort perform the evaluation, that is
not always possible. The evaluation should be conducted early so users have a fresh
recollection of the development effort bur nor before users have experience using the
new S)'Stem.
The final report to management includes the final system documentation, describes
any furnre system enhancements that already have been identified, and details the
project coses. The report represents the end of the development effort and the beginning
of the new system's operational life.

394 Key Terms
Key Terms
dcccptancc tc>t lesnng involves the ennre information syscem. mdudtng JU typic.il pro.:essmg suuanons.
During .m acceptance cesr. users emer data. indudmg samples 0£ actual or lne datJ, perform queries,
and produce report< ro simulace acrual operating condmons. All proce~~mg options and ourpuc~ arc
'enfied by users and the IT project de,·elopmem ream ro ensun• rh.11 chc S)Scem funetion~ correetl).
~metunc> known as ii syscem 1e.1.
apphcarion dc1 clopmcnr The pro.:ess of construeting the programs and code module> thJt are the
building blocks of dn mformarion syscem. Application devdopmelll 1s b.1ndled by an apphcanon
development group w1thtn a traditional IT deparrmem thac 1s composed 0£ systems analyses and programmers
who h.indle information system design, dc1·clopmcnr, and 11nplc111cm.11ion.
aurihutc A <ingle characreri<ric or face ahout an entity. An anrihuce, or field, 1' rhe 'mallesc piece
of darn chat hn' meanini; wi chin an information system. For example, n Social Sei.;uncy number
or company name could he examples of an attribute. In 0-0 ana ly'i', an a11ribu1c ;, pan uf
a da" dinµram rhat dc~cribe< the characteri\tic' of objnr' in the da''· Al'o known a' a Jara
element.
hui: tmcking ,oftwarc System developers use defect tracking ,oftware, 'omctimc' en lied huµ tr;ick·
inµ >11ftwarc, ro document and crack program defects, code chanµc~, and replacement code, c:illed
p.Hchc,,
Capabtliry Marurtty Model (Ci\L\.1)• A model developed by ~El th.u in1egra1es software nnd sysrems
developmem into a process 101provemenr framework.
Cdpahility Maturity Model lntq;ration (Cl\1 \11)" An SF.1-dcvdopc:d procc" to improve quality, reduce
development time, and cm co~t<. A C:0-1\.1 track~ an organi1 .• 11inn·, ,.,ftware development goal• .ind
pracuces, using f1,e maturity levels, from Level 1 (relarively urutJble, inefrectwc software) 10 Level 5
(S-Ofl\\.ire rh.u 1s refined, efficient. and reliable).
code rc\lcw A rcv1c\\ ot 3 projcu ream member'~ work by other member\ of rhe team 10 'POI logic
error<. Generali)', ~ yHem• analV'lts review the work of other ')'tern' anal)'"'• and proJ,'Tam·
mer> re,·iew the work of other prO!!rammers, as a form of peer rc,1ew. 'itrucrured walk-rhrough•
'hould rake place rhroughour the SDLC and are called requirement\ review,, de•ii;n rcl'icw<>, code
re1 IC\\,, or te>ring re\ie\\ ,, depending on che phase in which they 1ic.:ur. 1\1\0 known :I\ 3 ,crucrun:d
walk-1hrouµh.
codini: The procc'' of turning program logic into specific in~truction> thar a compurer \)\!Cm can
cxccure.
,ohcs1on A measure of a module's scope and processing characreris11c~. A module 1ha1 performs a ~mgle
funcnon or task ha~ a high degree of cohesion, which is desirable.
conduion A specified action or state in a structure chart.
control couple Tn a ~rrucrure chart, a concrol couple shows a message, al'o called a flag, which one mod·
ule stnds to an11thcr.
control module In a >1ruc1urc chart, a control module is a hi17her-lcvcl module rhar dirc•t~ lower-level
modulc•., called •ubordinate modules.
coupling Mea~urcs rebrionships and imerdependence among modules. The opposue of cohesion.
cu~romcr
Primary u~er of a system, service, or product.
clat.1 c<1nvcl"\1nn Fx1sring data i~ loaded into the new system, transformed as needed. Depcndin~ on the
~y~ccm, dara convcr,ion can be done before, during, or after the opcranonJI environment is complcre.
dacn couple In a structure chart, a daca couple show' data that one module pas'c' to another.
defect rrad.in~ soft\\arc Sysrem dc,·elopers use defect tracking software, sometime; called hug track·
ing software, ro document and crack program defects, code change>, and replacemenr code, called
p3t<hC>.
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

ftn:aso
Sy5to11u; ril I n1
Key Terms
395
dc>igo ".ilk-through A scss.1on wuh users to rev1e" the mtexface "1th a cross secnou of people who will
work with 1hc new system. This is a connnuanon of the modelmg and protorypmg cffon that ~an
eMl) m the S)Stems de,·clopmcnr proccss.
dc'ik chccl.11111 The pr11<:c\\ of rc,;cwing the program code tel spot logic error<, which produce mcorrcct
raults.
dir"ct cut0,cr The dircu cumver approach cau\C'l the changeover from the old •y,tem to the new\) 'item
w oc~ur 1mmediatd) "hen the new 'Y'tcm hec:omo operational.
docurnen1.11Jon M.11enJl 1h.11 explJll> a •y>1em, helps peopll' intl'ract with it, and mdude. progrJm documemauon,
system documencarion, operations documenranon. and user documenta11on.
Oowchar1 A diagram used to describe program logic that represems logic-JJ rules and iutcracuon graphically
u'mg a <enc~ of srmhols connected by arrows. flowcharrs can be useful m v1sualmng modular
progr.un designs.
integrated dc,clopmcnt en\ irunmcnt (IDE) A suire uf inrq,'f.nted mols co make it eaoier w plan, con­
\trt11:t, and maintain l 'flCcific ,ofcware produce. An fDE is designed to allow the easy mtewation of
>Y\tcm componcnl' with le.- 1i111e hcing >pent on developing code for lnreractive module,.
1nlL)lrat1on to,ung The tc,ting of two or more prowams that depend on em:h other.
JSO \1000-3:2014 A se1 of gu1delmes established and updated by the ISO ro provide a QA £r.11neworl..
for de, eloping and m.1itUJmu1g software.
iteration <:>de An Jg1le development cycle tha1 includes planning, designing. coding. and tes11ng one or
more features based on user stories.
i1eration planning mcctmg In agile developmenc, a meeting held ar rhe beginning of each iteration qdc
to break down u'>C:r \toric<> into '>pe-:1fk t:isks that are a~ig:ned co ream membc:".
l1hra11 module In ;i \tructurc chart, a l1bral) module 1> a module that" re~hlc and can be invoked
from more than one p<"nt in the chart.
logic error M1s1akes m the undcrlring logic that produce incorrect results.
loop lo ;i s1ructure chart, a loop md1cates that one or more modules are repeJted.
loo.,cl) rnuplcd \lodulc• that arc rclath·dv independent. loosely coupled module> arc easier 10 maintain
and modify, h«au•e the logic in one module d<>e!i not affect ocher modules.
method., In a clas' diagram, methods repre<;enr program logic.
modular design A de,ign thai can be broken down into logical blocks. Also known as parnnonang, or
top-down design.
module A module cons1srs of related program code organized mro small urnts thar are eJS)' to understand
and 111a111t;11n. A complex program could have hundreds or even rhousauds of module~.
obic<l-urion1cd dc,tlo1>mcn1 (OOD) The proce;s of translating an object modd di reedy mio an 0 -0
r rogramming lani;ungc.
onlinc dornmcntation Provides immediate help when u•crs have questions or encounter problem,.
open da1.1ba•c connec1ivi1y (ODUC) An ind115try-srnndard prococol that make' it po,5ihlr for ~oftwarc
from different ~endors to inrer.1c1 and eAcbange data.
opcrotiooal cnvirunmcnt The environmenr for rbe actual sysrem operation. It includes hardware and
softw.ue wnf1gurnrion~. S]Stcm urilicies, and communications resoutces. Also ~.tiled the produ<tmn
en\ Lronment.
opcrauon~ documcntauon Contains all the mformarion needed for processing and d1smbut1n1t onlmc
and printed output.
pair pro11rammmiz A practice 111 XP in which rwo programmers work on che same ca•k on the 5ame
computer; one drive., (program5) while rhe other navigates (warchcs).
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

396 Key Terms
parallel opcra1io11 The parallel operauon changeo"ec method reqwres th.it bo1h the old and 1he new
mforma11on srsrems opera~ fully for a specified period. Data ts mpur mto both systems, and ourpur
gcncrarcd by rhc new srsrcm is compared with rhe equ1\'alenr ourput from the old system.
part111on1ni; The hreakmg down of ovaall ohjecti"e> inro subsyMem~ and module,.
p.itch Replacement code th:11 1s applied co fix bugs or i.e.:urn:y bolo in ~oft ware.
phased opcrnuon rhe phased operarion method allows a new system to be tmplemenred m srages, or
modules.
pilot opcr.uioo fllc pilot operation changeover method involves implemen11ng rhe complete new sysrem
at J selC'Cted location of the company.
pilor me In a pilot operauon. the group chat uses the new sysrem first ts cJlled the p1lo1 sne.
podca•t A wch·ha,ccl hroadca>i that allows a u'cr co r1.-.:civc audio or multimedia files U\in)l mu\ic
player software, <uch a• iTune<, and listen co chem on a PC or download them to a portable MP ~
pbycr or •man phone.
pm1-1mplcment;uion evaluation An assessnu:m of chc overall qualiry o f the information •}Stem. The
cvalunrion vcrific~ that the new system meet;; 'pccificd rcc1uircmcnr,, complic• w11h u<cr ohjcctivc,,
and achieve' rhc anticipawd benefits. In addition, by providinJl feedback to rhc development team, chc
evaluntinn nl"' help' im prove IT development practice.\ for future project\,
procch improvement The framework used to integrate software and systems development by a new Sf.I
model, CM.i\11.
produccion cmoronmcnt fhe envttonmenr for the actual system oper.iuon. Ir mcludes hudwarc .rnd
wfrwarc configurations, S)Stcm uulitics, and communications resources. Also cJllcd rhc operauonal
enHronmcnr.
program documen1.mon Preparation of program documenrauon StJrtS Ul the systems .1nalys1s phase
and con11nues durmg systems unplemenration. Systems arul)sts prepare overJll documentanon, such
as process dc<;enpuons ;ind report la}·outs, earl)' in the SDLC. Programmers pro' 1de documcnrauon
b} construcnng modules that are well supported b)' internal and external comments and descnprions
thJt can be under~rood and m.iimamed easily.
p'cudt><:odc A techmquc for rcprcscnnnll program IOf,'1C on !K"mi-~rrucrured pro\c.
qu:ahl) a\\urnncc (QA) A proce~~ or procedure for mimmmng error< and cn,unng quality in product'I.
Poor qualil)' can result from inaccurace requirements, design problem~. coding error~, faulcy documcnra11on,
and ineffecrive ce~ring. A QA ceam reviews and res~ a ll .1pphca t 10n~ and ')'rem' chanse'>
co vcrof) >pccifi~ation' and ;,oftware quality Mandard!>.
release plan ln agile development, a plan chat specifies when user stones will be 11nplemc111ed and the
riming of the release~. ReleJses arc relanvcl)' freq uent, and each rclc.isc is treated .1s a system proro­
C)'PC rhor can be rested and modified as needed.
>1mul.11ion A dress rehear.al for users and IT supporr staff. Org.111i.t.a11ons typ1c.tlly mclude all procedures,
such .ts those thar rhey execuce only ar the end of a month, quarter, or ye.1r, 111 their simulations.
~ofr".1rc engineering A software dc'"elopmem process rhar scrcsscs solid design, effcc1ivc structure, occurnrc
documcnr.trion, and careful testing.
\l.ttu1 Oa11 In >trucrured opplicnrion development, an indicator thac nllows one module 10 send a mes·
>.lgc IO .rnothcr module.
strunurc chart A top-down representation o f business fu nctions and proc:cs~n. Also ca lled an FDD.
~tructurcd "alk-through A re1·iew of a project ream member's work b) other memher> of the ream. Generally,
\ysrcms onalyi.rs review che wock of other systems analysts, and programmer<; review the work
of other programmers, as a form of peer review. Strucmred wall-through> ;,bould tJke pla<e throughout
the SDL(. and .ire called rcqu1remenrs reviews, design reviews, code renews, or resnng re1·1ews,
dcpcndini; on rhc phase in which they occur.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

ftn:aso
Sy5to11u; ril I n1
Key Terms
397
>tub te>ring A form of tc,ring where the programmer simulates each program outcome or re; ult and d1> ·
pla)> a m.:1>>agc to 1ndKate whether or not the program executed >OCC~>full). Ea,h ,tub rcprc>cnh an
enrry or c,11 point that will be linked later to another program or data file.
subordinate module A lower-leHI modul<' ma structure chan.
S)nt.i" error l'rogramnung languag<' grammar error.
\y\lcm d1angc0>cr The pro<.e" of punin11 the new information S)'Stcm onlinc and re11nni: the old '>''"
tern. ('hangcovcr can he r:ipid or 'low, depending on rhc method.
~)>tern documcntarion A de\Criprion of a <;y~rem\ functions. and how thcr are implemented. The analy't
prepare' mo\t of the ~)'\tern documentation dunng the sy><ems :rnaly.,1s and '>)'\tern'> de.,ign pha'e'.
Sy;,tcm do1.u111cnrarion indude;, d:1ta dictionary enrries, DFD>, object model;, i.<:recn la)·our-, ,uur<.c
document,, and the 'Y'tcms rcquc't that i111tiatcd the pro1cct.
system tcsuug A form of tesnng mvolving .rn enrtre informariou system and t0cludcs aU typ1c.tl processing
sirnat1ons. During a system rest, u~crs cnrcr dara, inch1ding samples of acrnal or live darn, perform
queries, and produce reports to simulate acrnaJ opcraring conditions. Al l processing oprions and
outputs :ire verified by users .md the rr project development team ro ensure rhat the system funcnons
correctly.
1est data The dJtJ used tn un1r resting. Tesr dara should conrain both correct data and erroneous d.Ha
and should test all possible sm1arion.s that could occur.
tc\1-dri>cn dc,clnpment (mO) i\n XP concept that unit rests arc dc,igncd before code i' written, fucm·
inf: on end rc,ulr; and prc,·cnring programmers from 'rmyini.; from their goak
te..I cm ironmcnr The cmironmcnr that :maly<ts and programmers uo;e rn develop and maintain
program,.
t~I plan A plan designed b> a S)Stems .tnalrsr that includes test steps and test dat.1for1megrauon test·
mg .ind S)Stem tesnng.
u11htly coupled If modules are nghd) coupled, one module refers to internal logic contained in another
module.
top-dm• n approach \ dc<il,'ll approach, alw called modular dc<ign, where the <)"'Item< analrr define<
the overall ohicctivc, of rhe <)"<tern and rhen hreaks them down into <ubsyscem\ and module\. This
brc:akmg-down procC\~ al .. o "c:illc:d paninoning.
training plan A .. uc1.c\\ful information '>"cm requires training for users., manager,, and n ;tall
mcmhcr.,. ll1c cnnrc: <y<rcm< dcvclopmcnr effort can depend on wherhc:r or nor people undcr\tand
the 'l'~tcm and know how m u<c ir effecri,·dy. The training plan is a document that derail' tht\C
requirement~.
train-the-trainer A strategy where one group of users has been rrained and can assist others. Users ofrcn
le:1m more qutGkly from coworkers who share common experience and job respo11s1b1li11es.
tutorial A serie; of onhne imeracuve les;ons that present material Jnd provide a di:1log with user;.
unit tc\ling The 1c,ting of an indi vidu:il program or module. The objective i> to idc111ify :1nd eli minate
c-ccc:ution error~ that could ca u'c: rhc program ro tcm1inate abnormally ,111d logic errors that could
have been mi5,cd during desk checking.
mer dncumcntat1on l n<trucnon~ and information ro users who will interact with the sy~tem. I nclude~
u\Cr manua l ~, help ~rcen<, :ind rurorials.
user stOf} In agile de"elopmcnt, a \horr, simple requirements definition provided b) the (u.,tomer. Pro
grammers u;,e uoer storieo t0 detem1ine a project's requirements, prioriue>, and scope.
"ebca>l A one-wa) rr:imm1ss1on of mformarion or rraining materials, such as a webmar i.es;ion, J\J1lable
on dcru;rnd or for a opec1fic period to onlme pan1apants.
"cb1oar An lntcmct·bJ;,ed rra1mng '~>Ion that provides an mteracuvc experience. The word u•tbmilr
combines the words web and semmilr.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

398 Exercises
Exercises
Questions
I. Whar i~ QA?
2. Whar is appl1carion dcvclopmenr?
3. Explain how srrucrure charts are used in application developmenr.
4. Should classes be rightly coupled or loosely coupled in 000? Explain why.
5. Whar is pair programming?
6. What role do IDEs play in coding?
7. Describe three main rypes of rcsring and the order in which they arc performed.
8. Whar are the differences be1ween program, system, operations, and u~er documentation?
9. Whar is rhe role of onlinc documentation?
10. What is the difference be1wcen :rn operational environment and a test environmenc?
Discussion Topics
I. Di~cuss the three technique~ u~ed m improve QA.
2. What arc rhc mosr significant differences among structured, 0-0, and agile merhods? Whar do rhey
have in common?
3. Experienced programmers sometimes eschew IDEs for handcrafted mols, ofren connected in a pipeline
to facilitate complex work flows. What advantages and disadvantages would this approach have over
sophisricared IDF..s?
4. Your supervisor said," lnregrarion testing is a waste of rime. If each program is tested adequately,
integrarion res ring 1sn 'r needed. Instead, we should move on to system testing as soon as possible. If
modules don't interact proper!)', we'll handle it then.~ Do you agree or disagree with this commenr?
E.xplain your answer.
5. Suppose rhar you designed a rurorial ro rrain a person in chc use of specific sofrware or hardware,
such as a web browser. \'<'har specific informacion would you want co know about the rcc1p1enr of che
training? How would rhat information affecr che design of che training material?
Projects
1. Using rhe marerial in chis chapter and your own Internet research, prepare a presemation on rhe pros
and cons of agile development methods.
2. In this chapter, you learned abour rhe importance of testing. Design a generic rcsr plan char describes
rhe testing for an imaginary sysrem.
3. Which sysrcm changeover mcrhod would you recommend for an air traffic conrrol system upgrade?
Explain your answer.
4. Design a generic posr-implemen tation evaluation form. The form should consist of questions char you
could use co eva luate any information system. The form should evaluate the training received and any
problems associarcd wirh rhe program.
5. C reate an online training module using one of the systems discussed in this chaprer, such as Udemy or
lynda.com, on the topic of managing systems implemenrarions.
r..,,... JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-s c~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

PHASE
Systems support and security is the final phase in the systems development life cycle. In the
previous phase, systems implementation. a functioning system was delivered. The system now
moves Into the support phase, where the analyst maintains the system, handles security issues,
protects the integrity of the system and its data, and is alert to any signs of obsolescence.
Security concerns have become a matter of national importance. Major security breaches at
large corporations are unfortunately quite commonplace. Sadly, system security Is rarely solved
by a simple app--it requires a disciplined approach that affects virtually all wks in the SDLC.
Chapter 12 focuses on managing systems support and security throughout the useful life of the
system. This includes user support, maintenance tasks. maintenance management. performance
management. security levels, backup and recovery, system retirement. and future challenges and
opportunities.
399
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 12
Managing Systems Support and Security
Managing
Systems Support
and Security
Chapter 12 describes systems support and security
wks that continue throughout the useful life of the
system. The systems support and security phase begins
when a system becomes operational and continues until
the system reaches the end of its useful life. Throughout
the development process, the objective has been to
create an Information system that is efficient, easy to
use, and affordable. After delivering the system, the
IT team focuses on support and maintenance tasks.
Managing systems support and security involves three
main concerns: user expectations, system performance,
and security requirements.
The chapter includes three "Case In Point"
discussion questions to help contextualize the concepts
described in the text. There are cwo "Question of
Ethics" scenarios in this chapter. The first scenario
concerns known security vulnerabilities In a system and
what should be done about them. The second scenario
is about divulging personal information, social media, and
free speech.
LEARNING OB ECT VES
W/Je11 you fi11is/J this d1apter, you s/Jould be able
to:
I . Describe u!ter supporc acr1viries
2. Define the four rypcs of maincenance
3. Explain seven strategies and cechniques for
maintenance managemenr
4. Describe techniques for system performance
management
5. Explain l>yscem security concepts and common
attacks against rhc system
6. Explain three tasks related ro risk management
conceprs
7. Assess syscern security at six levels: physical
securit>', nerwork security, application security,
file security, user security, and procedural security
8. Describe backup and disaster recovery
9. Lt~t six foccors 1nd1canng chat a sy~tem has
reached the end of its useful life
10. Lise future challenges and opporcunities for IT
professionals
CONTENTS
I 2. 1 User Support
I 2.2 ~1aintenance Tasks
Case in Poinc 12. I: Oucback Outsourcing, Inc.
12.3 ~1aintcnance Managemenr
12.4 System Performance Managcmenr
12.5 System Security
I 2.6
Security Levels
Case in Point 12.2: Outer Banks Counry
Case in Point 12.3: Chain Link Consulcing, Inc.
12.7 Backup and Recovery
12.8 System Retirement
12.9 Future Challenges and Opporrunitics
A Question of Ethics
I 2. 1 0 Su111mary
Key Terms
Exercises
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase 5
Systems Support and Security
12. 1 User Support
401
12.1 USER SUPPORT
A systems analyst is like an internal consultant who provides guidance, support,
and training. Successful systems often need the most support because users want
to learn the features, try all the capabilities, and disco\·er how the system can help
them perform their tasks. In most organizations, more than half of all IT department
effort goes into supporting existing systems. Companies provide user support in
many forms, including user training and a help desk to provide technical support and
assistance. This help can be provided in-house or outsourced.
12. 1.1 User Training
Chapter 11 described rhe initial training that is performed when a new sysrem is
introduced. Additionally, new employees must be trained on the company's information
systems. If significant changes rake place in the existing system or if a new version
is released, the IT department might develop a user training package. Depending
on the n~llure of the changes, rhe package could include online support via email, a
special website, n revision to the user guide, a training manual supplement, or formal
training sessions. Training users about system changes is similar to initial training.
The main objective is to show users how the system can help them perform their jobs.
12. 1.2 Help Desks
As systems become more complex, users need constant support and guidance. To
make data more accessible and ro empower users, many IT departments create help
desks. A help desk, also called a service desk, is a centraJized resource staffed by IT
professionals who provide users with the suppon they need to do their jobs. A help
desk has three main objectives: (1) show people bow to use system resources more
effectivclr, (2) provide answers to technical or operational questions, and (3 ) make
users more productive by reaching rhem how to meet their own information needs. A
help desk is the first place users rum when they need information or assistance.
A help desk does nor replace traditional IT maintenance and support activities.
lnsread, help desks enhance productivity and i1nprove utilization of a company's
infomiarion resources.
Help desk representatives need strong interpersonal and technical skills plus a
solid undersranding of the business because rhey interact with users in many departments.
A help desk should document carefully all inquiries, support rasks, and activity
levels. The information can identify trends and common problems and can help build
a technical support knowledge base.
A help desk can boost its productivity by using remote control ~oftwa re , which
allows IT staff ro ta ke over a user's workstation and provide support and troubleshooting.
One example of such a software application is GoToMyPC by Citrix,
shown in Figure 12- 1.
During a rypical day, rhe help desk staff members might have to perform the fo l­
lowing casks:
• Show a user how to create a data query or report that displays specific business
information
• Resolve network access or password problems
• Demonstrate an advanced feature of a system or a commercial package
• Help a user recover damaged data
......... ""_.. ...
_
.-....... .......... ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~ -........ . ...... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~ ~·~--- - ···---~~-.,.-"~ ........... --......

Chapter 12
Managing Systems Support and Security
402 12.1 User Support
• Offer rips for bener operation
• Explain an undocumented software feature
• Show a user how to use web conferencing
• Explain how to access the company's intranet or the Internet
• Assist a user in developing a simple database to rrack rime spent on variou5
projecrs
• Answer questions about sofcware licensing and upgrades
• Provide informarion about system specifications and che cosr of new hardware
or software
• Recommend a system solution that integrates data from differenr locations to
solve a business problem
• Provide hardware support by installing or reconfiguring devices such as scanners,
printers, network cards, w ireless devices, optical drives, backup devices,
and multimedia systems
• Show users how to maintain data consistency and integrity among a desktop
computer, a notebook computer, and a hand held computer or smartphone
• Troubleshoor sofrware issues via remote control utilities
Work more efficiently wit h Go ToMyPC Remot e Desktop Software
No matter where you are or what you nttd to do. remote access benefits both you and your business.
~~\\\\\\llllUIQ~~
:s ~~\\\\IUU/11.1,,
or
IS ~
~
~ ~
"-
~ 0 0 fl:!
~ ~
N
'11111 11\\\ •
'
Reduce Your Commute Connect While Traveling Be Home More
Avood ttwdodv u&lhc~ m •nd.,,... ,_..,.,
~by wort<~ from homeduroncnJV\.,.,...
No rnore wpor>tlon """ielV - .......,comp..ter it
....,"VI• coupleU1>uwov. Just IQ&., from
MM>thet computer or mcboledeYi<At.
"'"''" tho. Pf"-"' Mn ond Mt-b VoU ,_
IOdovau< job. ond be'-In Ii""' !..-d...,,.,
FIGU RE 12- 1 Remote access software, such as Go ToMyPC shown here. lets users access their PCs from anywhere-even with their
smartphones or tablets.
s~ru: r.otorntot. ('Q'TI
In addition to functioning as a valuable Lnk between IT staff and users, the help
desk is a central contact point for all IT maintenance activities. The help desk is
where users reporr system problems, ask for maintenance, or submit new systems
requesrs. A help desk can utilize many types of automated support, just as outside
vendors do, including email responses, on-demand fax capability, an online knowledge
base, frequently asked questions (FAQs), discussion groups, bullerin boards,
and automated voice mail. Many vendors now provide a live chat feature for online
VISltOrs.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
12.2 Maintenance Tasks
Phase 5
Systems Support and Security
403
12. 1.3 Outsourcing Issues
As discussed in Chapter 7, many firms outsource various aspects of application
development. This trend also includes outsourcing IT support and help desks. As with
most business dec1s1ons, oucsourcing has pros and cons. Typically, the main reason
for outsourcing is cosr reduccion. Offshore caU centers can rrim expen~es and free up
valuable human resources for producr development.
However, firms have learned char if tech supporr quality goes down, customers
are likely co notice and might shop elsewhere. Critical factors might include
phone wait rimes, supporr sraff performance, and online support cools. The
real question is wherher a company can achieve rhe desired savmgs wichouc
endangering It~ reputation and customer base. Risks can be limited but only
if a firm rakes an acrive role in managing and monitoring support quality and
consistency.
12.2 MAINTENANCE TASKS
The systems supporr and security phase is an important component of toral cost of
ownership (TCO) because ongoing maintenance expenses can determine the economic
life of a system. Figure 12-2 shows a typical pattern of operational and maintenance
expenses during the useful life of a system. Operational coses include items
such as supplies, equipment rental, and sofrware leases. ore that the lower area
shown in Figure 12-2 represenrs fixed operational expenses, while che upper area represents
maintenance expenses.
TOTAL
($)
maintenance
expenses
operalional
costs
----------Systems Operation---------_.
TIME
FIGURE 12-2 The total cost of operating an information system includes operational and maintenance costs.
Operational costs (green) are relatively constant. while maintenance costs (purple) vary over t,ime.
Maintenance cxpen~cs vary significantly during the system's operational life
and include spending to support maintenance activities. Maintenance activities
include changing programs, procedures, or documentation to ensure correct
system performance; adapting the system to changing requirements; and making
the system operare more efficiently. Those needs are met by different types of
mamcenancc.

Chapter 12
Managing Systems Support and Security
404 12.2 Maintenance Tasks
Examples of Maintenance Tasks
12.2. 1 Types of Maintenance
Corrective Maintenance
Diagnose end foe logoe errora
~ de19d1119 ..iwont calllong
Restore p<oper conllgure1ion aeaingt
Debug P<OQfllfO ooOt
Update clnvers
Uti ize remote control aoftwate tor problem cflagnosls and resotuuon
Adaptive Maintenance
Add Online capabiltty
Add support tor mobda devlCM
Add new data ontry Held 10 109u1 screen
Install links 10 wobslta
Create employee portsl
Perfective Maintenance
Upgrade or replace ouldalo<I hardware
Wnle macros to hllndle rope111o11e tasks
Compress syslem filea
Opumize user desklOp Mllllngs
Upgrade w1raless network capablllty
Install m0ta povterlul network tetVer
Preventive Maintenance
Install new anWltUS toftwaro
OevelOp standard bed<up ecl>edllfe. oncludong o"·a.te
and do<ld-basecl stral9glea
lmplemeol reg.-.ir Clefragmenia1 en pioceu
Analyze J)<Olllom t9pot1 lot i-.. r,,.
TVilen •• ~ connecltOnS
Oe\191op .-g.-ccwnng conliden1.alcy rulM and
unaul>orm1d use of company IT r-..
Alrhough some overlap exists, four q rpes of maintenance rasks can be idenrified, as
shown by the examples in Figure ·12-3. Corrective maintenance is performed to fix
errors, adaptive maintenance adds new capability and
enhancements, perfective maintenance improves efficiency,
and preventive maintenance reduces the possibility
of future system failure. Some analysts use the term
mai11tena11ce to describe only correcti'e maintenance
that fixes problems. It is helpful, however, to view the
mainteoancc concept more broadly and identify the
different types of tasks.
Maintenance expenses usually a rc high when a
system is implemented because problems must be
detected, investigated, and resolved by corrective
maintenance. Once the system becomes stable, costs
usually r emain low and involve minor adaptive
maintenance. Eventually, both adaptive and perfective
maintenance activities increase in a dynamic business
environment.
Near rhe end of a system's useful life, adaptive and
corrective maintenance exp enses increase rapidly, bur
perfective maintenance typically decreases when ir
becomes clear that the company plans ro replace the
system. Figure 12-4 shows rhc typical pancrns for each
of the four classifications of maintenance acriviries over a
system's ]ife span.
FIGURE 12-3 Co~rove maintenance fixes errors and
problems.Adaptive maintenance provides enhancemcnu
to a system. Perfective maintenance improves a system's
efficiency. reliabihty. or maintainability. Prevcnuve
maintenance avoids future problems.
12.2.2 Corrective Maintenance
Corrective maintenance diagnoses and corrccr errors in
an operational system. To avoid introducing new problems,
all maintenance work requires careful analysis
before making changes. The best maintenance approach
is a scaled-down version of the SDLC itself, where investigation,
analysis, design, and testing are performed before
implementing any solution. Recall from Chapter 11 the
differences between a test environment and an operational environment. Any maintenance
work that could affect the system must be performed first in the rest environment
and then migrated to the operational system.
IT support staff respond to errors. in various ways, depending on the namre and
severity of the problem. Most organizations bave standard procedures for minor
errors, such as an incorrect report title or an i1nproper format for :i data clement.
In a typica l procedure, a user submits a system request rhat is evaluated, prioritized,
and scheduled by the system admiojstrator or the systems review committee. If the
request is approved, the rnaintenance tean1 designs, tests, documents, and implements
a solution.
As stared in Chapter 2, many organizations use a standard online form for systems
requests. Jn smaller firms, the process might be an informal email message. For more
serious situations, such as incorrect report totals or inconsistent dara, a user submits a
system request with supporting evidence. Those requests receive a high priority and a
maintenance team begins work on the problem immediately.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....- ""'*" ....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "-> - "'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,..., ~ ..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
12.2 Maintenance Tasks
Phase 5
Systems Support and Security
405
Immediately Earty Middle Later
After Operallonal OperatlOl'lal Operational
lmplementatlon Lrle Life Life
Correcnve
Maintenance
High Low Low Htgh
AdaplMI
Maintenance
(Minor
Enhancements)
Adaphve
Maintenance
(Ma1or
Enhancements)
None Medium Mecium
None None Medium to High Medium to High
Perfective
Maintenance
Low
Low to Medium Medium Low
Preventive
Maintenance
Low Medium Medium Low
FIGURE 12-4 Information systems maintenance costs depend on the type of maintenance and the age
of the system.
The wor~r-case siruarion is a sysrem failu re. If an emergencr occurs, rhe mainre·
nance ream bypa ses the initial steps and cries to correct rhe problem immediately.
This often requires a parch, which is a specially 'vrin en sofrware module chat provides
temporary repmrs so operations can resume. ~1eanwhile, a wrirren systems
request t~ prepared by a user or a member of the IT department and added to the
maintenance log. When rhe system is operational again, rhe maintenance ream determines
the cause, analyzes rhe problem, and designs a permanenr solution. The IT
response ream updates rhe rest data fi les, thoroughly tesrs rhe sysrem, and prepares
fu ll documentation. Regardless of how the priorit ies are sec, a standard ranking
method can be helpful. For example, Figure 12-5 shows a three-level framework for
IT supporc potential impact.
PRIORITY
Level I
Level 2
Levell
IMPACT
Significant impaa on IT operations,
secur ity. or business activity that r equires
Immediate attention.
Some impact on IT operations, security,
or business activity. Requires prompt
attention, but operations can continue.
Little or no impact on current IT
operations, security, or business activity
Implement patch as soon
as possible.
Patch as necessary and
begin Implementation
prior to next release.
Implement in the next
release.
FIGURE 12-5 This three-level ranking framework for IT support considers potential impact and response
urgency.

Chapter 12
Managing Systems Support and Security
406 12.2 Maintenance Tasks
The process of managing sysrem support is described in more detail in Section 12.3,
including an overview of maintenance tasks and a procedural flowchart.
12.2.3 Adaptive Maintenance
Adaptive maintenance adds enhancemenrs roan operarional system and makes the
sy~rem easier to use. An enhancemen t is a new feature or capability. The need for
adaptive maintenance usually arises from business environment changes ~uch as new
produces or ~ervices, new manufacturing technology, or support for a new web-based
opera non.
The procedure for minor adaptive maintenance is similar to routine corrective
maintenance. A user submits a system request that is evaluated and prioririzcd by
che systems review committee. A maintenance team then analyzes, designs, tests, and
implements the enhancement. Although the procedures for rhe two types of main tenance
arc alike, adaprivc maintenance requires more IT department resources than
minor correcti ve maintenance.
A major adaptive maintenance project is like a small-scale SDLC project because
rhe development procedure is similar.Adaprive maintenance can be more difficu lc
than new systems development because the enhancements must work within rhc con·
straints of an existing system.
12.2.4 Perfective Maintenance
Perfective maintenance involves changing an operational system to make it more
efficient, reliable, or maintainable. Requests for corrective and adaptive mainte·
nancc normally come from users, while the lT department usually iniriares perfective
mamrenance.
During system operation, changes in user activity or dara panerns can cause a
decline m efficiency, and perfective maintenance might be needed ro restore performance.
\'Vhen users are concerned about performance, it should be determined if a
perfecrive mamrenance project could improve response rime and sysrem efficiency.
Perfecrivc maintenance also can improve system reliabtliry. For example, input
problems mighr cause a program ro terminate abnormally. By modifymg the daca
entry process, errors can be highlighred, and users notified that they must enter
proper daca. \'Vhen a sysrem is easier co maintain, support is less cosrl)' and less risky.
In many cases, a complex program can be simplified to improve mainrainabiliry.
In many organizations, perfective maintenance is not performed frequently enough.
Companies with limited resources often consider new systems development, adaptive
maintenance, ::t nd correcti vc maintenance more important than perfective maintenance.
Managers and users constantly request new projects, so few resources arc available for
perfective maintenance work. As a practical matter, perfective maintenance can be performed
::ts part of another project. For example, if a new function must be added to a
program, perfective maintenance can be included in tbe adaptive maintenance project.
Perfective maintenance usually is cost-effective during rbe middle of the system's
operational life. Early in systems operation, perfective maintenance usually is nor
needed. Later, perfective maintenance might be necessary bur have a high cosr. Perfective
maintenance is less important if the company plans ro discontinue rhe system.
When performing perfective maintenance, analysts often use a technique called
sofrwarc rccngineering. Software reengioeering uses analytical techniques to identify
potential quality and performance improvements in an information system. In rhat
sense, sofrware reengineering is similar ro business process rccngmcering, which seeks
ro simplify operations, reduce cosrs, and improve quaJiry.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase S
Systems Support and Security
12.2 Maintenance Tasks
407
Programs rhar need a large number of mainrenance changes usually arc good
candidares for rcengineering. The more a program changes, rhe more likely iris ro
become inefficienr and difficulr ro maintain. Detailed records of maintenance work
can idenrify systems wirh a hi rory of frequent corrective, adaptive, or perfecr1ve
maintenance.
12.2.5 Preventive Mruntenance
To avoid problems, preventive maintenance requires analysis of areas where trouble is
likely ro occur. Like perfective maintenance, tbe IT department normally miriares preventive
maintenance. Preventive maintenance often results in increased user satisfaction,
decreased downttme, and reduced TCO. Preventive maintenance competes for IT
resources along with other projects and sometimes does nor receive the high priority
that it deserves.
Regardless of the cype of maintenance, trained professionals must support computer
systems, just as skilled technicians must service the particle detector at CERN
shown in Figure 12-6. In both cases, the quality of the maintenance will directly affect
the organization's success.
FIGURE 12-6 Technicians use a motorized Ii~ to get into position by the
ATLAS particle detector at CERN. Regardless of the type of system. tr;ioned
professionals must perform high-quality maintenance.
Soi.lrc:e: Al iA r 11 ~ N
You are a systems analyst at Outback Outsourcing, a firm that handles payroll processing for
many large companies. Outback Outsourcing uses a combination of payroll package programs
and in-house developed software to deliver custom-made payroll solutions for its clients. Lately,
users have flooded you with requests for more new features and web-based capability to meet
customer expectations. Your boss, the IT manager, comes to you with a question. She wants to
know when to stop trying to enhance the old software and develop a totally new version better
suited to the new marketplace. How would you answer her?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 12
Managing Systems Support and Security
408 12.3 Maintenance Management
12.J MAINTENANCE MANAGEMENT
System maintenance requires effective management, quality assurance, and
cost control. To achieve these goals, companies use various strategics, such as
a maintenance ream, a maintenance management program, a configuration
management process, and a maintenance release procedure. In addition, firms use
version conrrol and baselines ro rrack system releases and analyze the system's life
cycle. These concepts arc described in the following sections.
12.3. 1 The Maintenance Team
A maintenance team includes a sysrem administrator and one or more systems
annlyst& and programmers. The system administrator should have solid technical
expertise, and experience in troubleshooting and configuring operating systems and
hardware. Successful analysts need a strong CT background, solid analytical abilities,
good communication skills, and an overall understanding of business operations.
SYSTEM ADMINISTRATOR: A system administrntor manages computer and network
systems. A system administrator must work well under pressure, have good
organizational and communication skills, and be able to understand and resolve complex
issues in a limited time frame. In most organizations, a system administrator has
primary responsibility for the operation, configuration, nnd security of one or more
system•,. The system administrator is responsible for routine mninrennncc and usually
is nuthoriz.cd to rake preventive action to avoid an immediate emergency, such as a
server crash, nerwork outage, security incidem, or hardware failure.
SYSTEMS ANALYSTS: Systems analysts assigned to a maintenance tenm nre like
skilled derecrives who investigate and rapidly locate the source of n problem by using
analysis and synrhesis skills. Analysis means examining rhe whole in order ro learn
abour rhe individual elements, whiJe synthesis involves srudying rhe pnrrs roundersrand
the overall sysrem. In addirion to strong technical skills, an annlrst must have a
solid grnsp of business opernrions and functions. Analysts also need effecrive mrerpersonnl
and communications skills, and chey musr be creative, energeric, and enger for
new knowledge.
PROGRAMMERS: In a small organizarion, a programmer might be expected ro
handle n wide variety of tasks, but in larger firms, programming work rends robe
more specialized. For exnmple, typical job titles include nn npplicn tion~ programmer,
who works on new systems development and maintenance; a systems proi,rrammer,
who concentrates on operacing system software nnd utilities; nnd a database
programmer, who focuses on creating and supporting lnrge-scnle dntabnse S) 1 Stems.
Many IT departments also use a job title of programmer/analyst to designntc
positions thnr require n combination of systems analysis and programming skills.
ORGANIZATIONAL ISSUES: IT managers often divide systems nnalysts and
programmers into two groups: One group performs new system development,
::ind the other group handles maintenance. Some organizations use a more flexible
approach and assign IT staff members to various projects as they occur. By
integrating development and suppont work, the people developing the system assume
responsibility for maintaining ir. Because the team is familiar with the project,
additional training or expense is unnecessary, and members are likely to have a sense
of ownership from the onser.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.3 Maintenance Management
409
Unfortunately, many analysts feel that maintenance is less interesting and less creative
than developing new systems. In addition, an analyst might find it challenging
to troubleshoot and support someone else's work that might have been poorly documented
and organi1cd.
Some organi1ation5 that have separate maintenance and new systems groups
rotate people from one assignment to the other. \Xfhen analysts learn different skills,
the organization is more versatile, and people can shift to meet changing business
needs. For instance, S)'Stcms analysts working on maintenance projeccs learn why it is
important to design ea5ily maintainable systems. Similarly, analyses working on new
systems get a better appreciation of the development process and the design compromises
necessary co meet business objectives.
One disadvantage of rotation is chat it increases overhead because rime is lost
when people move from one job co another. When systems analysts constantly shift
between maintenance and new development, they have less opporruniry to become
highJy ski!Jed at any one job.
Newly hired and recently promoted IT sraff members often are assigned to maintenance
projects because their managers believe that tl1e opportunity ro study existing systems and
documentation is a valuable experience. ln addition, tl1e rnini-SDLC used in many adaptive
maintenance projects is good training for the full-scale systems development life cycle. For
a new systems analyst, however, maintenance work might be more difficult than systems
development, and it might make sense to assign a new person to a development ream
where experienced analysts arc available ro provide training and guidance.
12.3.2 Maintenance Requests
Typically, maintenance requests involve a series of steps, as shown in Figure 12-7.
After a user submits a requesr, a system adminisrcator determines whether immediate
action is needed and whether chc request is under a prescribed cost limit. ln nonemergencr
requests char exceed the cosr limit, a system review committee assesses the
request and either approves ir, with a priority, or rejects it. The system administrator
notifies :iffccced users of the outcome.
Users submit mosr requests for corrective and adaptive maintenance when rhe
S)'Srem is nor performing proper!)• or if they wane new features. IT staff members usually
initiate requesrs for perfective and preventive maintenance. To keep a complete
maintenance log, all work must be covered by a specific request that users submir in
writing or by email.
INITIAL DETERMINATION: When a user submits a maintenance requesc, the sy~rcm
administrator m:ikcs an initial decermination. If rhe request is justifiable and involves
a severe problem chat requires immediate attention, the system administrator rnkes
action at once. In justifiable, but noncritical, situations, the adminisrraror determines
whether the request can be performed within a preau thorized cost level. If so, he or
she assigns rhe maintenance tasks and monitors the work.
THE SYSTEM REVIEW COMMITTEE: When a request exceeds a predetermined cost
level or involves a major configuration change, the system review committee either
approves it and assigns a priority or rejects ir.
TASK COMPLETION: The system administrator usually is responsible for assigning
maintenance tasks to individuals or to a maintenance ream. Depending on rhe
situation and the company's policy, the system administrator might consider roraring
assignments among rhe IT staff or limiting maintenance tasks ro certain individuals or
teams, as explained in the pre\•ious section.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 12
Managing Systems Support and Security
410
12.3 Maintenance Management
Start
User sends maintenance
request IO system
edminostralor
Systems review commlnee
>---1 assesses requost and
assigns prooroty or rejects
Yes
Yes
System administrator
assigns maintenance
tasks and monuOfS
Che wO<I<
No
Yes
System admn1strator
adv ses systems revoew
comm.nee and al'ected
users of Che staws and
outc0me
End
FIGURE 12· 7 Although the procedure varies from company to c;ompany. the chart shows a typical
process for handling maintenance requests.
USER NOTIFICATION: Users who initiate main tenance requests expect a prompt
response, especially if the situation rurectly affects their work. Even when corrective
action cannt1t occur immediately, users appreciate feedback from the ~ystem administrator
and should be kept informed of any decisions or actions that could affect chem.
12.3.3 Establishing Priorities
ln man)• companies, the system review committee separates maintenance and new
development requests when setting priorities. In other organizations, all requests are
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.3 Maintenance Management
411
considered mgethcr, and the most important project gets top priority, whether it is
maintenance or new development.
Some IT managers believe that evaluating all projects together leads to the best
possible dec1s1ons because maintenance and new development require similar IT
department resources. In IT departments where maintenance and new development
are nor integrated, it might be bener to evaluate requesrs separate!>'· Another
advantage of a c;eparate approach is that maintenance is more likely to receive a
propornonal share of IT department resources.
The most important objective is to have a procedure that balances new
development and necessary maintenance work to provide the best support for
business requirements and priorities.
12.3.4 Configuration Management
Configuration management (CM), sometimes referred to as change control (CC), is a
process for controlling changes in system requirements during software development.
CM also is an important rool for managing systea1 changes and costs after a system
becomes operational. Jvlost companies establish a specific process that describes how
system changes must be requested and documented.
As enterprise-wide information systems grow more complex, CM becomes critical.
Industry standards have emerged, such as the IEEE's Standard 828-2012 for CM in
systems and software, as shown in Figure 12-8.
• Wort<1111 Group
Standard Details
lhll ~~-the mlnlmwn reqv•••~ iu for proc.ues ror
Conflslntaon ~ment(CM} in sysiems and softw•r• ·~·na. The
-.>pUCltion or tNs sund¥d applies to 11f1 form. ci.u. or type of soflw•re or
syst..,,. Th.s rwlSiOn of the sunclatd tl<Plnds the plWIOOJS _...,n to ticpllln
CM. indud11& ldMIJl)'vl& and Kq<Wlng confliurltJOn lltmS. conuolinc chqn.
rtpOfllng the sutUS of conllgur•non Items. os -11 u sollYwe builds and
ffiuse enganH<lna. Its ptedecesso< defined only the contentS or• soflw•re
configurallon rnanagtmtnl plan. This stllldard ..xlruMS wNI CM l(IJVltlff are
10 be don._ wtwn thty are to~ In the ure cycle. and wh.11 plllnnlnc end
mouras are roqu~. It Blso descrlba the content areas ror •CM Plan. The
SUlnd•rd 5UppolU ISOllEC/IEEE 12207'.20081nd ISOllEC/IEEE 1528&:2008and
adheres to the terminology In ISO/IEC/IEEE Std 2•765 Ind the 1nrormatlon Item
requlrtrnents of 1£EE Std ~5939TM
FIGURE 12· 8 IEEE Standard 828-2012 for configuration management in systems and software engineering.
Soul'C« r
Ctvl is especially imporranc if a system has mulciple versions that run in different
hardware and software environments. C?vf also helps to organize and handle documentation.
An operational system has extensive documentation that covers develop·
ment, modification, and maintenance for all versions of the installed system. Most
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 12
Managing Systems Support and Security
412 12.3 Maintenance Management
documcncation material, including the inicial systems request, project management
dara, end-of-phase reports, dara dicrionary, and the IT operations and user manuals,
is stored in the IT departmenr.
Keeping track of all documentation and ensuring that updates arc distributed
properly arc important aspectS of CM.
12.3.S Maintenance Releases
Keeping track of maincenaDce changes and updates can be difficult, especially for a
complex system. When a maintenance release methodology is used, all noncritical
changes arc held u11til rhey can be implemented at the same time. Each change is
documented and installed as a new version of the system called a maintenance release.
For an in-house developed systcn1, the rime between releases usually depends on
the level of maintenance activiry. A new release ro correct a critical error, however,
might be implemented immediately rather than saved for the next scheduled release.
When a release method is used, a numbering pattern distinguishes the different
releases. In a typical system, the initial version of the system is J .0, and the release
that includes the first set of maintenance changes is version l. l. A change, for
example, from version 1.4 to 1.5 indicates relatively minor enhancements, while
whole number changes, such as from version 1.0 to 2.0 or from version 3.4 to 4.0,
indicate a significant upgrade.
The release methodology offers several advantages, especially if rwo reams per·
form maintenance work on the same system. \'Vhen a release methodology is used, all
changes arc rested together before a new system version is released. This approach
results in fewer ver~ions, less expense, and less interruption for users. Using a release
methodology also reduces the documentation burden because all changes arc coordinated
and become effective simultaneously.
A release methodolo&'Y also has some potential disadvantage~. Users expect a rapid
response to their problems and requests, but with a release methodology, new fea·
tures or upgrades are available less often. Even when changel> would improve sy~rem
efficiency or user productivity, rhe porential savings must wait until rhe next release,
which might increase operational costs.
Commercial software suppliers also provide maintenance relea!>CS, often called
ser.ice packs, as shown in Figure 12-9. As Microsoft explainl>, a service pack contains
all the fixes and enhancements that have been made available since rhe last program
version or service pack.
12.3.6 Version Control
Version control is the process of tracking system releases, or versions. When a new
version of a system is installed, rhe prior release is archived or stored. If a new version
causes a system ro fail, a company can reinstall the prior version ro restore operations.
In addition to tracking system versions, the IT sraff is responsible for con fig·
uring systems that have several modules at various release stages. For example, an
accounting system mighr have a one-year-old accounts receivable module that must
interface wirh a brand-new payroll module.
Many firms use commercial applicarions to handle version control for complex
S)'Stems. There are also numerous free and open-source alternatives. For example, one
of the most popular version control systems is git, which is shown in Figure 12-10.
Git 1s a free and open-source program designed for dil>tributed systems. It is relatively
easy to use, is available across most major platforms, and is supported by the dcvel·
oper community.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.3 Maintenance Management
4 13
Service Pack and Update Center
.. • '
.. _
,
~--
:]
A-pod<Clllil•----..,.~--......... -
----..--.. ~ ... ot ~Oftlht ___
t«~ Mld ,..bu.,.. lmptc nlWJ'll.Md fl4IPO". b MWt)'pa ot Jwdwwt....,.......,.. rc-i ~
h t.te:1 MtWCt peck 10 h$ t..,, W"~ CO._ Slt'w<e PICb W tt:lowl lO "'"""-"to .,,,g1.
....,..... .............. ,..,,~....... -
...,........,,,,._
1 .......__ fhe it<OllWl•odlld '1tftd H1ol.a0""1f I009'-~ W(h l'I 'Mf'lk• p«ks II to tum or. "1t
u "" lo<Wl-l.l,Wl_& .... ly ,..,.____...
)'OU Mid ft reedy to~ tn ~ 10. t.ipdten M '"'°"""l<Aftt d0w1 °m lldld """*"',.,.,. \ltlf'lt
• """"""connec:llOn. lttm 1NWW llbo.C. ~ W"""'°"" tO \IP to
FIGU RE 12-9 A Microsoft service pack provides access to updated drivers. tools. security patches, and customerrequested
product changes.
Source: I
It
+ git local bmnchmg-on-the-chcap
Git is a frtt and OP"l llOUn:C di.stn"buted ~control ~em
daigned 10 handle ~ihing from small to \-et)' large projects ,.;th
~and efficimcy.
Cit u easy to lt'M'll and has a tmy foolprint "1th ligbJ
pmonnancc. It outc:a-SOI tools like Sub>usion. CVS, Perforce,
and CleatCue Wlth features like chap k>al brandii ft • con~ment
aaglng atta!', and mulupl wort1lows.
·----
About
,._,. a "°"~
t>ownload•
"' .
"'""" ... -
CUlcL.-1'et111r .. W..,, rdrM..
..... ~ ......
°"---­
Documeni.tlon
,,.
Community
o..-..i· .......................
•nd--
-FIGURE 12-1 0 Git is a popular free version control system.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 12
Managing Systems Support and Security
414 12.4 System Performance Management
12.3. 7 Baselines
A baseline is a formal reference point that measures system characrenstics at a
specific time. Systems analysrs use baselines as yardsticks to document features and
performance during che systems development process. The three t ype~ of baselines are
functional, allocated, and produce.
The functional baseline is the configuration of the system documented at the
beginning of the project. It consists of all rhe necessary system requirements and
design constraints.
The allocated baseline documents the system at the end of the design phase and
identifies any changes since the functional baseline. The allocated baseline includes
resting and verification of all system requirements and features.
The product baseline describes the system at the beginning of system operation.
The product baseline incorporates any changes made since the allocated baseline and
includes the results of performance and acceptance tests for the operationa 1 system.
12.4 SYSTEM PERFORMANCE MANAGEMENT
Years ago, when most firms used a central computer for processing data, ir was relatively
simple to manage a system and measure its efficiency. Today, companies use
complex networks, client/server systems, and cloud computing environments to support
business needs. A user ar a client workstation often interacts with an informacion
system that depends on ocher clients, servers, networks, and data located throughout
the company. Rather than a single computer, it is the integration of all those components
thac determines the system's capability and performance.
To ensure satisfactory suppon for business operations, chc IT department muse
manage system faults and intern1ptions, measure system performance and workload,
and anticipate furure needs. In many situations, IT managers use automated software
and CASE tools to help wich these tasks. Automated tools can provide valuable assistance
during the operation and supp-Ort phases. ~!any CASE tools mclude system
evaluation and maintenance features, such as the followmg:
• Performance monitors that provide data on program execution times
• Program analyzers chat scan source code, provide data element cross-reference
information, and help evaluate the impact of a program change
• Interactive debugging analyzers char locate the source of a programming error
• Reengineering rools
• Automated documentation capabilities
• Network activity monitors
• Workload forecasting tools
In addirion w CASE tools, spreadsheet and presentation software ca n be used to
calcularc trend~, perform what-if analyses, and create attractive charts and graphs ro
display the results. Information technology planning is an essential part of the business
planning process and often part of the presentations made co management.
12.4. 1 Fault Management
No matter how well it is designed, every system will experience some problems, such
as hardware failures, software errors, user mistakes, and power outages. A system
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-.............. ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-..................- .................................. ~~·~---- ···---~~-.,.-"~...........--.......
Phase 5
Systems Support and Security
12.4 System Performance Management
415
administraror muse derecr and resolve operational problems as quickly as possible. That
cask, often called fault management, includes monitoring the system for signs of trouble,
logging all S)'Stem failures, diagnosing the problem, and applying corrective action.
The more complex the system, the more difficult ir can be ro anal)'Ze S)'mptoms
and isolare a cause. In addition ro addressing the immediate problem, it i~ important
ro evaluate performance patterns and trends. For example, the Acrivicy ~1onitor
applicarion shown in Figure 12-11 runs on Apple's :\1ac OS X to display CPU, memory,
energy, disk, and network accivicy of all running applicarions in real time. Similar
programs, such as the Resource Monitor, are available on \Vindows. Faulr managemenr
software can help identify underlying causes, speed up response rime, and
reduce service outages.
""1/i4y MoMar !All P-J
CPU JHrnoty Energy OiSk +g_tgj.j,i Q-
"9cfftHt'"f
....,.,..lff-
0 -.. .,..~-
_...,.a
_ " ....
UMft'411\Aigtnt
--
.......
_ .,..., _.,.... -- -- PIO IJMr
IUtOll 70tCI 27,207.480 7,•'7 ... • 0-
11;, Ml 11.1 Ml '°·"" 74,.... ,, •• WIMy
8 t Ml 64 $ M8 45_,115 itt,t2t 112 .., 1tO!Mdnn•tnl"'-"''"'"'
')Ml .,, "' 12,21• 12,228 '' '°°'
no u .. 2 "' s,11<1 1, 111 n• -
'11 l(ll . _. ... . .... 7,21(1 1117 ... ..,
2toU JI !Cl 2i1 J2 H16& ,...,..,
22,Ka 2eM1 4.:S7-S M-,Ne 45111 JW'**"i
12KI t45U 105 1•1 M1>4 ltllbfr
121(8 ,.,_ 397 6 u -
70.. 10.. 1H 1H 1111 -
UQ M1Q "'4 7tl 20«....,
11 ICI 210 227 111 11 ...
... 1(1- 111 Q u ,... 1121 ....,
I
-
- ow
·-- ---­
.........
--­
"'"'
0 llCtliio ......
..
.. ..... ~-··­ '()... ~.
...... JCftd
--­ ...
........
11Q ,.... .. - --
15~ ,_,... 171 1,J:l• 20J1....,
.... -!Ca .. '70 1M< -
•21<• .... u .. 1171 -
na aoca 11 n 1--
•G. 1JD 14 tt llM .-.Y
7q 00 U l1 1110-
IQ
IQ
'"''
7D U
,.
21
21 no•
DI...,,.,
....,____
4 Q IOICB 10 •2 tMO....,
• u ,, ic:a 12 , . l0201 ,...,.
.... ,... .. 11 .... -
SQ Maby\ell 11 11 1817 .....,
10 ID I 12 171~
10 7U SS1 1a tOOt 1Ulley
1U >OU It 11 111 toec
-- 20- • 7 20•• -
,,..,,.. o- 2 a '°-
_,. 0..... 0- 0 0 11 -
-- 0- o.,,.. 0 0 ... -
"---~~~~~~......;.~~~-'-~~~~~~~~ ~~~~
- WI 40' 011.261
""'-.... Ha.711.,.
PtJCMt• llf\i'MO;
....,.,....,... 2.7•2
FIGURE 12· I I The Activicy Monitor application on Apple·s Mac OS X displays CPU,
memory, energy. disk. and network activity of all running applications in real time.
Soi.Ire.•: •1 I
Although sysrem adminisrrarors must deal wicb system faults and interruptions as
they arise, the besr strategy is to prevent problems b}' monitoring system performance
and workload.

Chapter 12
Managing Systems Support and Security
416 12.4 System Performance Management
12.4.2 Performance and Workload Measurement
In e-busine s, slow performance can be as devastating as no performance at all. erwork
delays and applicarion borrlenecks affect customer sarisfocrion, user product1viry,
and business resulrs. In fact, many IT managers believe that network delays do
more damage than actual s roppages because they occur more frequently and are difficult
to predict, derecc, and prevent. Customers expect reliable, fast respon~e 24 hours
a day, seven days a week. To support rhac level of service, companies use performance
management software.
To measure system performance, many finns use benchmark testing, which uses
a set of standard rests to evaluate system performance and capacit)'· In addition co
benchmark testing, performance measurements, called metri c~ , can monitor the number
of transactions processed in a given rime period, che number of records accessed,
and che volume of online data. Network performance metrics include response time,
bandwidth, rhroughput, and turnaround rime, among others.
RESPONSE TIME: Response time is the overall ti1ne between a request for system
activity and the delivery of the response. In the typical online environment, response
time is measured from the instant the user presses rhe Enter key or clicks a mouse
burron until the requested screen disjplay appears or printed output is ready. Response
rime is affected by the system design, capabilities, and processing methods. If the
request involves network or Internet access, response rime is affected by data commu·
n i ca ri on factor~.
Online users expect an immediate response, and they are fru~rrared by any appar·
cnr lag or delay. Of all performance measurements, response time is the one that users
notice and complain about most.
BANDWIDTH AND THROUGHPUT: Bandwidth and throughput are closely related
terms, and many analyses use them interchangeably. Bandwidth describes the amount
of data chat the system can transfer Ui a fixed time period. Bandwidth requirements
are expressed in bits per second. Depending on the system, bandwidth can be
measured in kilobits per second (Kbps), megabits per second (Mbps), or gigabics per
second (Gbps). Analyzing bandwidth is similar to forecasting the hourly number of
vehicles thar will use a highway in order to determine the number of lanes required.
Thro ughput measures actual system performance under specific circumstances
and is affected by nerwork loads and hardware efficiency. Like bandwidth, throughput
is expressed as a data transfer rare, such as Kbps, Mbps, or Gbps. J usr as traffic
jams delay highway traffic, throughput limitations can slow system performance and
response rime. Thar is especially true with graphics-intensive systems and web-based
systems rhar arc subject to Internet-related conditions.
In addition to the pcrfonnance metrics explained in rhe previous sccrion, system
administrators measure many other ;performance characteristics. Although no standard
set of metrics exists, several typical examples arc as fo llows:
• Arrivals: The number of items that appear on a device during a given observation
rime.
• Busy: The rime that a given resource is unavailable.
• Completions: The nwnber of arrivals that are processed during a given obser·
vation period.
• Queue length: The number of requests pending for a service.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.4 System Performance Management
417
• Service time: The rime ic rakes to process a given rask once ir reaches rhe front
of che queue.
• Think nme: The rime it takes an application user to issue another requesr.
• Urili1arion: How much of a gh•en resource was required to complete a task.
• Wait time: The time that requests must wait for a resource to become available.
TURNAROUND TIME: Turnaround time applies to centralized bacch processing
operations, such as customer billing or credir card sratement processing. Turnaround
rime measures the time between submitting a request for information and the
fulfillment of the request. Turnaround time also can be used to measltre the quality
of IT support or services by measuring the time from a user request for help to the
resolution of the problem.
The IT department often measures response time, bandwidth, throughput, and
turnaround time to evaluate system performance both before and after changes to
the system or business information requirements. Performance data also is used for
cost-benefit analyses of proposed 111ainte11a11ce a111d to evaluate systems that are neari11g
the end of their economically useful lives.
Finally, management uses current performance and workload data as inpur for the
capacity planning process.
12.4.3 Capacity Planning
Capacity planninA is a process rhar monitors current activity and performance levels,
anricipares future acriviry, and forecasts rhe resources needed to provide desired levels
of service.
The firsr srep in capacity planning is ro develop a current model based on the
system's prcscnr workload and performance specifications. Then future demand and
user requircmcnrs arc projccced O\'er a one- co three-year time period. The model
is analyzed to see whar 1s needed to maintain satisfactory performance and meet
requirements. To assist in the process, a cechnique called what-if analys1 can be used.
\'('hat-1f analysis vanes one or more elements in a model m order to measure rhe
effect on other elcmenrs. I-or example, what-if analysis might be used to answer
questions such as the following: How will response rime be affected if more client
workstations were added to the network? Will the client/server system be able to
handle the growth in salelt from the new website? What will be the effect on server
throughput if more memory is added?
Powerful spreadltheet tools also can assist in performing what-if analysis. For
example, Microsoft Excel contains a feature called Goal Seek that determines what
changes are necessary in one value to produce a specific result for another value. ln
the example shown in Figure 12-12, a capacity planning worksheet indicates rime the
system can handle 3,840 web-based orders per day, at 22.5 seconds each. Excel calculates
this automarically using the simple formula =86400/B4 for cell BS. (There arc
86,400 seconds in a 24-hour day.} The user wants to know the effect on processing
time if the number of transactions increases to 9,000. As the Goal Seek solution in the
bottom figure shows, order processing will have co be performed in 9.6 seconds to
achieve that goal.
During plan capacity, detailed informarion is needed about the number of
transactions; the daily, weekly, or monthly transaction patterns; the number of

Chapter 12
Managing Systems Support and Security
41 8 12.4 System Performance Management
., . . .
.. ....._ ..... ..l....... '"'"'.. u..t.a ~ ... _ lw.·~ • -~.... """'-"
.. •
.. I ( 0 f •
CAPAOTY PlANNING ANALYSIS
DATA:
• Proc~..nc lirlw lsteonds) per Web si11!' ore!«: 22.S
> M.J•imum WPb b.i"'!d ordl'fs 11tr day 3.MO
•
1
--
..
I
9
10
ll
u
,.
11 -.~ ...
IS
It
11
"••
_,
1 CAPAcnv PLANNING ANALYSIS
_
?
"
fclul MU t
.....
gs- 't
DATA:
•
PrO<:~\in& 11me (S«onds) per Web site order· 96
, MilXlmum Web ·b.l~ orders per day 9.000
•
1 Goo<S.-S.-
• "4ill i •.._...n Cd IS
tOWlillaMM--..
' 10
ICCO
II
,........ t,.GCIC
ll
u I Co I
I) "'
16
17
II
...
-·
FIG URE 12- 12 In this Goal Seek example, the user wants to know the effect on processing time if the number of
daily transactions Increases from 3.840 to 9,000.
'
)(
queries; and the number, type, and size of all generated reports. If rhe system
involves a LAN, network traffic levels must be estimated to determine whether or
not the existing hardware and software can handle the load. If the system uses a
client/server design, performance and connectivity specifications must be examined
for each platform.
Mosr important, an accurate forecast of future business activities is needed. If
new business functions or requirements arc predicted, contingency plans should be
developed based on input from users and management. The main objective is to ensure
that rhc system meets all future demands and provides effective support for business
opcrarions. Some firms handle their own capacity planning, while others purchase
software such as ldcra's Uptime ln&astructure Monitor, shown in Figure 12-13.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.5 System Security
419
I D :::: R A - ,_t_ - - ·· • ..,._
... ..... • a.ii. .. _.:..
--- --
•
Unify IT Performance Monitoring end Oplim1Z11tion
Upt m I f str ct Mo tor
- -
Iii
--
<'>
A,t I .. llCe ~ ........,.. c.,.aty~
c-c...--l'OU' -~llul·----·:t-... ein
Mr:.iwor QIW1 JO,.! dOeP. ~.,_,COL C' 1; ft ~ f9'DO"llnO •*C*' *es
•-N"8QT._ _..,,....,_,.....,... -
...,,~ .,.......--y-
.,........-...,io--. ...)IOU~.......... al._.,,
--.. ._,..,11--·-­
--pjlnnlng
~--...-
-y ,,,.,.._,. ~""" Uk!XINX.
-H"U..NovvOQ. Yi111111W.....
- Cll*!llt_,.,.....__._
..,_- ~
-~--·"""'-
_ond_)IOU_llel1g!W- \J!JllPlelnloonu<V•---
... _ "'" ... collOdlW""" """"'"' ....... .-- -111<141b1 ._ -
~ ...,_
... _. ............ .
C.,.Cft)t ~and PtotetM ........."",.
• ~/ lod$ JM ptebl1m• tMlar9 i1'~ twcJpert trw f'IOe dltlceraf
___,,<O"""'Y____ -.--·--..
boet ~ I 't4Wt.;ei 9"AOiilNrG ~ larlQdng.....,, hltlf'l Qf'..,,. an 01iCAI
.. -
~----...................
·
__...,"""'O~ CP\A ond llQ ._................ -
------~-....
--1ay0u-..go<- ... _...,.,., __ ._. ..
Start for FREE
FIGURE 12· I 3 ldera's Uptime lnfristru«u~ Mo'1itor i$ ~11 ~pl~ of taPit;ity planning software ;ind
services.
S.WC« .Js;lrl.
....._.
I 2.5 SYSTEM SECURITY
Security is a viral part of every informarion system. Security
protects the system and keeps it safe, free from danger, and
reliable. Jn a global environment char includes 1nany types of
cbreacs and anacks, security is more important than ever. This
section includes a discussion of sysrem security concepts, risk
management, and common attacks against the system.
12.5.1 System Security Concepts
The CIA triangle in Figure 12- 14 shows the three main elements
of system secu rity: confidentiality, integrity, and availability.
Confidentiality protects information from unauthorized
disclosure and safeguards privacy. Integrity prevents
unauthorized users from creating, modifying, or deleting
information. Availability ensures rbat authorized users have
timely and reliable access co necessary information. The first
step in managing IT securiry is ro develop a securiry policy
based on these rhree elements.
Confidentiality
Integrity
lntoml8tlon
Availability
FIGURE 12-1 4 System security must provide
Information confidentiality. integrir:y, and
avallabilir:y (CIA).

Chapter 12
Managing Systems Support and Security
420
Risk Management
ldenllly
FIGURE 12-15 Risk management requires
continuous risk identification, assessment, and
control.
12.5.2 Risk Managem e nt
12 .5 System Security
In the real world, absolute security is not a realistic goal. Instead,
managers must baJance the value of the assets being protected,
potential risks co the organi1arion, and security costs. For example,
it might not be worth installing an expensive video camera monicoring
system co protect an empty warehouse. To achieve the best
results, most fi rms use a risk management approach that involves
constant arrenrion co three interactive casks: risk identification, risk
assessment, and risk control, as shown in Figure I 2- 15.
Risk identification analyzes the organi1arion's assets, threats,
and vulnerabilities. Risk assessment measures risk likelihood and
impact. Risk control develops safeguards that reduce risks and their
impact.
RISK IDENTIFICATION: The first step in risk identification is to
list and classify business assets. An asset might include company
Threat Categorie s and Examples
THREAT CATEGORY
Extortion
Hardware and software failures
Human erTOr or failure
Natural disasters
Service railure
Software attack
Technical obsolescence
Theft of physical or intellectual
property
Trespau and espionage
Vandalism
EXAMPLE
Hacker steals trade secrets and threatens to release
them if not paid.
Router stops functioning. or software causes the
application server to crash.
Employee accidentally deletes a file.
Rood destroys company bu1ld1ng and necworked
systems.
Electricity is disrupted and brings the entire system
down for hours.
A group planes destructive software, a vi rus, or a worm
into a company network.
Outdated software is slow, difficult to use. and
vulnerable to attacks.
Physical server is stolen, lncellectual property is
stolen or used without permission: may be physical or
electronic.
Employee enters unlocked server room and views the
payroll data on a forbidden system.
Attacker defaces website logo, or destroys CEO's hard
drive physically or electronically.
FIGURE 12- 16 System threats can be grouped into several broad categories.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.5 System Security
421
hardware, software, data, networks, people, or procedures. For each asser, a risk
manager rares rhe impacr of an arrack and analyzes possible rhrears. A threat is an
internal or exrernal entiry rhar could endanger an assec. For example, rhrear caregones
might include narural disasters, software attacks, or theft, as shown in Figure
12-16.
Next, the risk manager identifies vulnerabilities and how they might be
exploited. A 'ulncrabilit) is a security weakness or soft spot, and an exploit 1s an
arrack thar takes advantage of a vulnerability. To identify vulnerabilities, a risk
manager might ask questions like these: Could hackers break through the /)roxy
server? Could em/)loyees retrieve sensitwe files without pro/)er a11thorizat1011?
Could people enter the computer room and sabotage our servers? Each vulnerability
is rated and assigned a value. The ourput of risk identification is a list of assets,
vulnerabilities, and ratings.
RISK ASSESSMENT: In IT security tern1s, a risk is the impact of an attack
multiplied by the likelihood of a vulnerability being exploited. For example, an
impact value of 2 :ind a vulnerability raring of 10 would produce a risk of 20. On
the other hand, an impact value of 5 and a vulnerability rating of 5 would produce
a risk of 25. When risks are calculated and prioritized, critical risk~ will head the
list. Although rntings can he subjective, rhc overall process provides a consistent
approach and framework.
RISK CONTROL: After risks are identified and :issessed, they must be controlled.
Control me:isure might include rhe following examples: We could place" firewall
on the proxy server. \Ve could assign permissions to sensitive files. \Ve could
install biometric devices to guard the computer room. TypicaU)', management
choo es one of four risk control straregies: avoidance, mirigation, transference,
or :icceprnnce. A"o1dance eliminates the risk by adding protective s:ifegu:irds. For
example, to pre\ent unauthorized access to LAN computers, a secure firew:ill
might be insr:illed. ~1i1igarion reduces the impact of a risk by careful plannmg
and preparntion. For example, a company can prep are a disaster recovery plan
in case a natural disaster occurs. Transference shifts the risk to another asset or
party, such as an insurance company. Acceptance means that nothing is done.
Companies usu:illy accept a risk only when the prorection clearly is nor worrh rhe
expense.
The risk managemenr process is ireracive-risks arc constantly identified, assessed,
and controlled. To be effective, risk managers need a combination of business knowledge,
IT skills, :ind experience with securiry roots and rechniques.
12.S.3 Attacker Profiles and Attacks
An attack is :i hostile act that cargets the system, or the company itself. Thus,
a disgruntled employee, or a hacker who is 6,000 miles away, might launch an
arrack. Attackers break into a sysrem to cause diamage, steal informarion, or gain
recognition, among o rher reasons. Attackers ca n be grouped into categories, :is
shown in Figure 12-17, while Figure 12-18 describes some common types of
attacks. Companies combat security threats and challenges by using a multilevel
srrategy.

Chapter 12
Managing Systems Support and Security
422 12.5 System Security
Attacker Charact eristics
ATTACKER
C yberterrorist
Employee
Hacker
Hacktivlst
Script kiddie
Spy
DESCRIPTION
Attacks to advance political. social. or ideological goals.
Uses unauthorized information or privileges to break
into computer systems, steal information. or cause
damage.
Uses advanced skills to attack computer systems with
malicious intent (black hat) or to expose Haws and
improve security (white hat).
Attacks to further a social or political cause; often
involves shutting down or defacing websites.
Inexperienced or juvenile hacker who uses readily
available malicious software to disrupt or damage
computer systems, and gain recognition.
Non-employee who breaks into computer systems to
steal information and sell it.
SKILL SET
High
Vanes
Vanes
Low
High
FIGURE 12-17 IT security professionals have names for various types of attackers.
Types of Attacks and Examples
ATTACK
Back door
Denial of service or
distributed denial of
service
Dumpster diving
Mail bombing
Malicious code
Man in the middle
Password cracking
Phishing
Privilege escalation
EXAMPLES
Attacker finds vulnerability in software package and exploits it.
One or more computers send a stream of connection requests to
disable a Web server.
Attacker scours the trash for valuable 1nformatt0n that can be
used to compromise the system.
Enormous volumes of email are sent to a target address.
Attacker sends infected email to the target system. Attackers may
use viruses, worms, T ro1an horses. keystroke loggers. spyware, or
scripts to destroy data. bog down systems. spy on users, or assume
control of infected systems.
The attacker intercepts traffic and poses as the recipient, sending
the data to the legitimate recipient but only after reading the
traffic or modifying it.
Hacker attempts to discover a password to gain entry Into a
secured system. This can be a dictionary attack. where numerous
words are tried, or a brute force attack. where every combination
of characters is attempted.
F<llse DNS (Domain Name Server) information steers the user to
the attacker's website. Attackers trick users into thinking they are
visiting a legitimate site, such as a bank site. then attempt to obtain
bank account numbers. usernames. and passwords.
Employee tricks a computer into raising his or her account to the
administrator leYel.
(continues)
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

12.6 Security Levels
Phase 5
Systems Support and Security
423
ATTACK
Sniffing
Social engineering
Spam
Spoofing
EXAMPLES
Network traffic is intercepted and scanned for valuable
information.
An attacker calls the service desk posing as a legitimate user and
requesu that his or her .password be changed.
Unwanted, useless email is sent continuously to business email
accounts, wasting ome and decreasing productivity.
IP address is forged to match a trusted host. and similar content
may be displayed to simulue the real site for unlawful purposes.
FIGURE 12- 18 Attacks can take many forms. as this table shows. IT security managers must be able to detect
these attacks and respond with suitable countermeasures.
12.6 SECURITY LEVELS
To provide i.ystem security, six separate but intenrelated levels must
be considered: physicn l security, network security, application secu·
rity, fi le security, user security, and procedural security. Like the
chain shown in Figure 12- 19, system security is only as strong as
the weakest link. The following sections describe these secltrity lev·
els, and the issues that must be addressed. Top management often
makes the final strategic and budget decisions regarding security,
but systems analysts should understand the overall picture in order
to make informed recommendations.
12.6. 1 Physical Security
The first level of system security concerns the physical environment,
including IT resources and people throughout rhe company. Special
anention must he paid ro critical equipment located in operations centers,
where servers, network hardware. and related equipment operate.
Large companies usually have a dedicated room built specifically for
Security Levels
Physical
Network
Application
File
Procedural
IT operations. Smaller firms might use an office or storage area. Regnrdless of its si1e and
shape, an operations center requires special protection from unwanted intrusion. In nddi·
tion to centrally located equipment, all computers on the nerwork mu~t be secure because
each server or work~mtion can be a potential access point. Physical access ton computer
represencs an enrry point into rhe system and must be conrrolled and protected.
OPERATIONS CENTER SECURITY: Perimeter security is essential in nny room or
area where computer equipment is operated or maintained. Physical access must be
controlled tightl y, and each entrance must be equipped with a suitable security device.
AU access doors should have internal hinges and electron1agnetic locks that arc
equipped with a bnn ery backup system to provide standby power in the event of a
power outage. When the battery power is exhausted, the doors should fa il in a closed
position, but it :.hould be possible for someone locked inside the room to open the
door with an emergency release.
To enhance security, many companies are installing biometric scanning ~}'!.tem!i , which
map an individual's facial fcarures, fingerprints, handprint, or eye characrerisrics, as
shown in Figure 12-20. These high-tech authentication systems replace magnetic identi·
ficntion badges, which can be losr, stolen, or altered. Apple's Face ID system, described
in Chapter 2, is an example of a biometric security system for smarrphone and mobile
......... ""_.. ... .-.. ............... _
User
FIGURE 12-19 Each security link has a
specific focus. and the overall chain Is only as
strong as the weakest ltnk.
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

Chapter 12
Managing Systems Support and Security
424 12.6 Security Levels
FIGURE 12-20 Companies use biometric scanning to analyze
the features of the eye's iris. which has more than 200 points that
can be measured and used for comparison.
devices, as discussed in the section on portable
computers char follows.
Video cameras and morion sensors can be used
to monitor computer room securiry and provide
documenrarion of all ph)'5ical acriviry in rhe area.
A morion sensor uses infrared technology ro decect
movement and can be configured to provide audible
or silent alarms, and to send email messages when
one is triggered. Other types of sensors can monitor
remperacure and humidity in the computer room.
Morion sensor alarms can be accivated at rimes
wben there is no expected acrivity in the computer
room, and authorized technicians should have codes
co enable or disable the alarms.
SERVERS AND DESKTOP COMPUTERS:
If possible,
server and desktop computer cases should be
equipped with locks. This simple, bur important,
precaution might prevent an intrude; from modifying the hardware configuration
of a server, damaging rhe equipment, or removing a disk drive. Server racks should
be locked to avoid the unauthorized placement and retrieval of keystroke loggers. A
keystroke logger is a device that can be inserced between a keyboard and a computer.
Typically, the device resembles an ordinary cable plug, so it does not call attention
to itself. The device can record everything that is typed into the keyboard, including
passwords, while rhe system conrinues to function normally. Keysrroke loggers can
be used legitimately co monitor, back up, and restore a system, but if placed by an
intruder, a keystroke logger represen cs a serious security threat.
In addition to hardware devices, keystroke logging software also cxi5ts. A keystroke
logging program can be disguised as legitimate software and downloaded from the
Internet or a company network. The program remains invisible to the user as it records
keystrokes and uploads the information to whoever installed the program. uch malicious
oftware can be removed by antivirus and antispyware software, discussed farer
in the Application Security section.
Tamper-evident cases should be used where possible. A tamper-evident case is
designed co show any attempt co open or unJock the case. In the event that a computer
case has been opened, an indicator LED remains lit until it is cleared with a
password. Tamper-evident cases do nor prevent intrusion, but a security breach is
more likely co be noticed. Many servers now arc offered with tamper-evident cases as
part of their standard configuration.
Monitor screen savers chat hide tbc screen and require special passwords to clear
should be used on any server or workstation that is left unattended. Locking the screen
::after a period of inactivity is another safeguard. A BIOS-level password, also called a
boot-level password or a power-on password, can also be used. This password muse
be entered before the computer can be started. A boor-level password can prevent an
unauthorized person from booting a computer by using a secondary device.
Finally, companies must consider electric power issues. In mission-critical systems,
large-scale backup power sources are essential to continue business operations. Jn other
cases, computer systems and network devices should be plugged into an uninterruptible
power \upply (UPS) that includes battery backup with suitable capacity. The UPS
should be able to handle shorr-rerm operarions in order ro permir an orderly backup
and sysrem shutdown.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.6 Security Levels
425
PORTABLE COMPUTERS: When assessing physical securiry issues, be sure ro
consider additional security provisions for notebook, laptop, and tablet computers.
Because of their small size and high value, rhese computers are tempting rargets
for thieve and indusrnal spies. Alrhough rhe following suggesrions are incended
as a checklist for notebook compurer securiry, many of rhem also apply ro de:.ktop
workstations.
• Sclecr an operaring system rhar allows secure logons, BIOS-level passwords,
and srrong firewall prorccrion. Log on and work wirh a user account char has
limited privileges rather rhan an adminisrraror accounr and mask rhc administrator
account by giving ir a different name chat would be hard for a casual
intruder ro guess.
• Mark or engrave the computer's case with the company name and address, or
a teach a tamper-proof asset ID tag. Many hardware vendors allow corporate
customers to add an asset ID tag in the BIOS. For example, after powering up,
the following message may appear: Property of SCR Associates-Company
Use Only. These measures might not discourage a professional thief, but might
deter a casual rhief, or at leasr make che computer relatively less desirable
because it would be more difficult to use or resell. Security experts also
recommend using a generic carrying case, such as an artache case, rather than a
custom carrying case chat calls attention ro itself and its contents.
• Consider devices that have a builc-in fingerprint reader or facial recognition
-·
sy1item.
••
• ,\itany notebook computers have a Universal Security
Slot (USS) that can be fastened co a cable lock or laprop
alarm. Again, while these precautions migbt nor deter professional
rhieves, they might discourage and deter casual
thieves.
• Back up all viral data before using the notebook computer
outside the office. Save and rranspon highly sensitive
data on remo' able media, such as a flash memory device,
insread of the compurer's hard drive.
• Use tracking sofrware char directs the laptop to periodically
contact a ecuriry cracking center. if the notebook is
stolen, the call-in identifies the compurer and its ph)•sical
location. Armed with this information, the security tracking
center can alert law enforcement agencies and communications
providers.
• Apple, Google, and Microsoft offer services to locate lost
customer sma rtphones. The services also permit remote
data wipe and factory reset of the devices. For example,
Apple's Find My iPhone app is shown in Figure 12-21.
Apple also provides a similar cloud-based service.
• While traveling, try co be alert to pocential high-risk situations,
where a thief, or thieves, mighr create a disc:racrion
and attempt to snatch the compure r. These situations often
occur in crowded, noisy places like airport baggage claim
areas, rental car counters, and security checkpoints. Also,
when travelmg by car, score rhe computer in a trunk or
lockable compartment where 1t will nor be visible.
Find My iPhone
-
ApplelO a~
FIGURE 12-21 Apple's Find My 1Phone app
helps customers locate lost devices and perform
remote data wipes and factory resets if needed.
~.. ....
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......

Chapter 12
Managing Systems Support and Security
426 12.6 Security Levels
• Establish stringent password protection policies that require minimum length
and complexity and set a limit on how many rimes an invalid password can be
entered before the system locks itself down. In some situations, con ider establishing
file encryprion policies to protect extremely sensiti\'e file~.
Outer Banks County is a 200-square-mile area in coastal North Carolina. and you are the
IT manager. The county has about a hundred office employees who perform clerical tasks in
various departments. A recent budget crisis has resulted in a wage and hiring freeze. and morale
has declined. The county manager has asked you to install some type of keystr0ke logger to
monitor employees and determine whether they are fully productive. After your conversation,
you wonder whether there might be some potential privacy and security issues involved.
For example, does an employer have a duty to notify its employees that it is monitor·
ing them/ Should the employer notify them even if not required to do so/ From a human
resources viewpoint, what would be the best way to approach this issue/ Also, does a
potential security Issue exist/ If an unauthorized person gained possession of the keystroke
log, he or she might be able to uncover passwords and other sensitive data.
What are your conclusions? Are these issues important, and how would you respond
to the county manager's recommenda-tion/ Before you answer. you should go on the
Internet and learn more about keystroke loggers generally. and specific products that
currently are available.
12.6.2 Network Security
A network is defined as two or more devices that arc connected for the purpose of
sending, receiving, and sharing dara, which is called nerwork traffic. In order ro connect
to a network, a computer must have a network interface, which is a combination
of hardware and software thar allows rhe computer to inccract wich rhc nerwork. To
provide security for nerwork traffic, data can be encrypted, which refers to a process
of encoding the data so it cannor be accessed withour authoriLation.
ENCRYPTING NETWORK TRAFFIC: Nerwork traffic can be intercepted and possibly
altered, redirected, or recorded. For example, if an unencr) pted, or plain text,
password or credit card number is transmitted over a network connection, it can be
stolen. When the traffic is encrypted, it still is visible, but its content and purpose arc
masked.
Two commonly used encryption techniques are private key encryption and public
key encryption. Private key encryption is symtnctric because a single key is used co
encrypt and decrypt information. While this method is simple and fast, it poses a fun·
damenral problem. To use symn1etric encryption, both the sender and receiver must
possess chc sa me key beforehand, or it must be sent along with the message, which
increases the risk of interception and disclosure.
In contrast, public key encryption (PKE) is asymmetric, because each user has
a pair of keys: a public key and a private key. Public keys are used to encrypt messages.
Users can share their public keys freely, while keeping their private keys tightly
guarded. Any message encrypted with a user·s public key can only be decrypted with
that user's private key. This method is commonly used in secure onlinc e-commerce
S)'Stems.
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Phase 5
Systems Support and Security
12.6 Security Levels
427
WIRELESS NETWORKS: As discussed in Chapter 10, wireless nerwork M:curity is a
vital concern because wireless transmission is much more vulnerable than traffic on a
wired nerwork. H owever, if wireless traffic is encrypted, any data that is intercepted
by an unintended recipient will be useless to the intruder.
The earliest form of wireless security, called Wtred Equi\'alent Pri\'aC} (\VEP),
required each wireless client to use a special, pre-shared key. Although many home
and small office nerworks used rhis method, it provided relatively weak protection.
WEP was replaced by \Vi-Fi Protected Access (WPA), which offered major security
improvements based on prorocols created by the Wi-Fi Alliance. The most
recent wireless security enhancement, called WPA2, further strengthens the level of
wireless protection. WPA2 is an extension of \VPA based on a full implemenration
of the IEEI::. 802.11 i Standard. According co che Wi-fi Alliance, the WPA2 standard
became mandatory for all new devices seeking Wi-Fi certification after 2006. WPA2 is
compatible with WPA, so companies easi ly can migrate co the new security standard.
PRIVATE NETWORKS: It is not always practical to secure all network traffic.
Unfortunately, encrypting traffic increases che burden on a nerwork, and can decrease
nenvork performance significantly. Jn situations where network speed is essenti:i l,
such as a web server linked to a database server, many firms use a private network
to connect the computers. A private network is a dedicated connection, similar to a
leased telephone line. Each computer on the private nerwork must have a dedicated
inrerface to the network, and no interface on rhe network should connect to any point
outside the network. In this configuration, unencrypted traffic safely can be transmitted
because it is not visible and cannot be intercepted from outside the network.
VIRTUAL PRIVATE NETWORKS: Privare nenvorks work well with a limited num·
ber of computers, but if a company wanrs to esca blish secure connections for a larger
group, it can create a \•irrual private network. A virtual private network (VPN) uses a
public network, ~uch as rhe lncerner or a company inrranet, to connect remote users
securely. Instead of using a dedicated connection, a VP1 allows remote clients to use
a special key exch::inge that must be authenticated by the VPN. Once authentication
i~ complete, a secure nerwork connecrion, called a runnel, is established berween che
client and the access point of the local incranet. All craffic is encrypted through the
VPN tunnel, which provides an additional level of encr)•prion and ~ecurity. As more
companies allow employees to work from home, a VP can provide acceptable levels
of security and reliability.
PORTS AND SERVICES: A port, which is identified by a number, is used to route
incoming traffic ro rhc correct application on a computer. In T CP/lP networks, such
as the Lnternet, all traffic received by a computer contains a destination port. Because
the destination port determines where the craffic will be routed, the computer sorrs
the traffic by port number, which is included in the transnutted data. An analogy
might be a large apartment building with multiple mailboxes. Each mailbox has the
same street address, but a different box number. Port security is critically important
because an ;Htacker could use an open port to gain access to the system.
A senice is an application thar monitors, or listens on, a particular port. For
example, a typical email application listens on pore 25. Any traffic received by that
port is routed to the email application. Services play an important role in computer
secu rity, and they can be affected by pore scans and denial-of-service attacks.
• Port scans. Port scans attempt to detect the services running on a computer
by trying to connect to various pons and recording the pons on which a
connecrion was accepted. For example, the result of an open poet 25 would
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 12
Managing Systems Support and Security
428 12.6 Security Levels
indicate that a mail server is running. Port scans can be used to draw an
accurate map of a nerwork, and pinpoint possible weaknesses.
• Denial of service. A denial of service (DoS) attack occurs when an attacking computer
makes repeated requests co a service or services running on certain pores.
Because the target computer has to respond to each requesc. it can become bogged
down and fail co respond to legitimate requests. A much more devastating attack
based on this method is called a distributed denial of service (00oS) attack. This
attack involves multiple attacking computers that can synchronize DOS attacks
and immobilize a server, as shovm in Figure 12-22. A DDoS attack is an example
of the type of serious cyberanacks that United States Computer Emergency Readiness
Team (US-CERT), shown in Figure 12-23, was created to address.
Attacker
Bornet
Target
FIGURE 12-22 In a DoS attack. an attacker s;ends numerous authentication requests with false recum
addresses. The server tries unsuccessfully to send ovt authentication approval and IS evenruatly disabled by the
Roor of requests. More sophisticated DoS attacks are distributed (DDoS).as shown In rh1s figure. Instead of a
sangte computer, the atacker uses an army of botnets (computers unknowingly infected wirh malware that are
difficult to trace) to attack the argeL
US-CERT ..
..... Ml & .. >lr'!l.. (A"f••\ f'~,K4'<W\ ... , ••,~.,,_ •t1•'l >•t'I..•,,••• ••
0
FIGURE 12-23 The US-CERT is a key player in the battle against cybersecurlty threats.
Sol.ire« JL ~
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.6 Security Levels
429
FIREWALLS: A firewall is the main line of defense berween a local nerwork, or
inrranet, and the lnterner. A firewall musr have ar leasr one nerwork inrerface wirh rhe
Internee, and ar lease one nerwork inrerface with a local network or inrraner. Firewall
software examines all nerwork rraffic senr to and from each nerwork inrerfoce. Preset
rules esrabli~h certain conditions that determine whether the firewall will allow the
traffic to pass. \Xlhen a matching rule is found, the firewall automatically accept~.
re1ecrs, or drops the traffic. When a firewall rejects traffic, it sends a reply md1cacing
chat the traffic 1s not permissible. When a firewall drops traffic, no reply is sent.
Firewalls can be configured to detect and respond co denial-of-service arcacks, port
scans, and ocher suspicious acriviry.
Figure 12-24 shows a basic set of firewall rules for a company chat has a web
server and a mail server. In this example, the firewall would accept public web server
traffic only on ports 80 and 443 and public n1ail server traffic only on port 25. The
firewall would allow private LAN traffic to any destination and port.
INTERFACE
DESTINATION
PORT
ACTION
Public
Web Server 80
Accept
2
Public
Any
Web Server 443
Accept
3
Public
Any
Web Server
Any
Reject
4
Public
Any
Mail Server
2S
Accept
5
Public
Any
Mail Server
Any
Reject
6
Public
Any
Any
Any
Drop
7
Private
LAN
Any
Any
Accept
FIGURE 12-24 Exampll!S of rull!S !hat detenn1ne whether U,., firewall will allow traffic to pass.
NETWORK INTRUSION DETECTIO N : Suppose an intruder attemprs to gain access
co the system. Obviously, an intrusion alarm should be sounded when certain acriviry
or known attack patterns are detected. A network intrusion detection system (NIDS)
is like a burglar alarm that goes off when it detects a configuration violation. The
NlDS also can alert the adminisrrator when it detects suspicious network traffic patterns.
An NIDS requires fine-tuning to detect the difference between legitimate nerwork
traffic and an atrack. It is also important that an NIDS be placed on a switch or
other nerwork device that can monitor all netwolfk traffic. Although an IDS requires
some administrative overhead, it can be very helpful in documenting the efforts of
attackers and analyzing network performance.
12.6.3 Application Security
In addition to securing the computer room and shielding network traffic, it is necessary
to protect all server-based applications. To do so, the analyst must analyze the
application's functions, identify possible security concerns, and carefully study all
available documentation. Application security requires an understanding of services,
hardening, applicarion permis~ion s , input validation techniques, software parches and
updates, and software logs.

Chapter 12
Managing Systems Support and Security
430 12.6 Security Levels
SERVICES: The necwork security secrion explained how a service is an applicacion
char monitors, or listens, on a particular port. Which sen'ices arc running can be
determined by using a port scan utilicy. If a particular application is nor needed, ir
should be disabled. This will improve syscem securiry, performance, and reliability.
An unnecessary or improperly configured service could create a vulnerability called
a \ecurity hole. For example, if a loosely configured File Transfer Protocol (FTP) service
i~ available co a hacker, he or she might be able to upload desrrucnve code co the
server.
HARDENING: The hardening process makes a system more secure by removing
unnecessary accounts, services, and features. Hardening is necessary because the
default configuration of some software packages might create vulnerability. For
example, inicial software settings often include relatively weak account permissions
or file sharing controls. Hardening c:an be done manuall)' or by using a configuration
template, which speeds up the process in a large organization.
Hardening also includes additional protection such as antivirus and ancispyware
sofrware. These programs can detect and re1nove malware, which is hostile software
designed to infilcrace, damage, or deny service co a computer syscem. Malwarc
includes worms, Trojan horses, keystroke loggers, and spyware, among ochers.
APPLICATION PERMISSIONS:
Typically, an application is configured to be run
on ly by users who have specific rights. For example, an admini~crntor account,
or superu~cr account, allows essentially unrestricted access. Other users mighc
be allowed co enrer darn, but nor ro modify or delete existing data. To prevenc
unaurbori.Ged or desrrucrive changes, rbe application should be configured so char
non-privileged users can access rhe program but cannot make changes to built-in
funccions or configurations. User rights, also called permis~ion~ , are discussed in more
detail in the file security section.
INPUT VALIDATION: As discussed in Chapcer 8, when designing che user interface,
input validation can safeguard data integrity and security. For example, if an application
requires a number from 1 to 10, what happens if an alphabetic character or the
number J 1 is entered? If the application is designed properly, it will respond wich an
appropriacc error message. Chapter 8 also explained daca entry and validarion checks,
which are imporcanr techniques char can improve data integrity and qualiry. Failure
to validate input data can result in output errors, increased maintenance expense, and
erratic system behavior.
PATCHES AND UPDATES: In an operational system, security holes or vulnerabilities
might be discovered at any rime. Patches can be used co repair these holes, reduce
vulnernbiliry, and update che system. Like any other new software, pacche~ mu~c be
tested carefully. Before applying a parch, an effort should be m•1de ro decermine the
risks of 110/ applying the patch, and the possibi lity chat rhe p•HCh might affect ocher
areas of che system.
lvlany firms purchase software packages called third-party software. Patches
released by third-party sofrware vendors usually are safe, but any parch must be
reviewed carefully before it is applied. Because researching and applying patches is
time consuming and expensive, many software vendors offer an automatic update
service chat enables an application to contact the vendor's server and check for a
needed patch or update. Depending on the configuration, available patches can be
downloaded and installed without human intervention or might require approval by
IT managers. Although it is convenient, automatic updating carries substantial risks,
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.6 Security Levels
431
and should be used only if changes can readily be undone if unexpected results or
problems develop.
SOFTWARE LOGS: Operating systems and applications typically maintain a log
that documents all event:., includmg daces, cimes, and other specific information. Logs
can be important in understanding past attacks and preventing future intrusions. For
example, a partern of login errors mighc reveal the details of an intrusion arrempt.
A log also can include S) stem error messages, login histories, file manipulauon, and
other informauon that could help track down unauthorized use. Sofrware logs should
be monitored constantl)• to determine if misuse or wrongdoing has occurred. As
explained in the nerwork security section, an NIDS can alert a system administrator
whenever suspicious events occur.
12.6.4 File Security
Computer configuration settings, users' personal information, and other sensiti ve data
arc stored in files. The safccy and prorccrion of these files is a viral clement in any
computer security progrnm, and a systems analyse needs to consider the importance
of encryption or encoding fi les ro make them unreadable by unauthorized users, and
permissions, which can be assigned co individual users or to user groups.
ENCRYPTION: As explained in che section on necwork secu rity, encryption scrambles
the contents of :i file or document to protect ic from unauthorized :iccess. All
corporate data must be protected, bur encryption is especiaUy important for sen!>iti ve
macerial such as personnel or financial records. User data can be encrypted u&ing features
built-in to most modern operating systems.
PERMISSIONS: File security is based on establishing a set of permissions, which
describe the rights a user has to a particular file or directory on a server. The mosr
common permissions are read, write, and execute. Typical examples of permissions
include the following:
• Read a file: The user can read the contents of the file.
• Write a file: The user can change the contents of the file.
• Execute a file: The u~e r can run the file, if it is a program.
• Read a directory: The user can list the contents of the directory.
• Write a direcrory: The user can add and ren1ove files in the directory.
When assigning file permissions, a system administrator s11ould ensure that each
user has only the minimum permissions necessary ro perform his or her work-nor
more. In some firms, the system administrator has broad discretion in assigning these
levels; in ocher companies, an appropriate level of management approval is requi red
for any permissions above a standard user level. nn any case, a well-documented and
enforced permissions policy is necessary co promote file security and reduce system
vulnerahiliry.
USER GROUPS: Individual users who need to collaborate and share files often
reque~c a higher level of permissions char would enable any of chem co change file
content. A better approach, from a system adminisrracor's viewpoint, might be to
create a user group, add pecific users, and assign file permissions to the group,
rather than to the individuals. M any firms use chis approach because it allows a
user's rights to be determined by his or her work responsibilities, rather than by
_
.........""_......-....... .......... ..__
("..,_...,llll!O( ...... ..--. .\) ....... ~ "-> - "'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,..., ~ ..,._.. .............. ~ ..
__.... ................... ~~·~--- - ···---~~ - .,.-"~ ........... --......

Chapter 12
Managing Systems Support and Security
432 12.6 Security Levels
job title or rank. If a person is transferred, he or she leaves certain groups and joins
others that reflect current job duties.
12.6.S User Security
User ecunry involves the identification of system users and consideranon of user-related
security issues. Regardless of other security precautions and fearures, security
ullimarely depends on S)'Stem users and their habits, practices, and willingness to support
security goals. Unfortunately, many system break-ins begin with a user account
that is compromised in some way. Typically, an intruder accesses the S)Stem using
the compromised account a11d may attempt a privilege e\calation attack, which is an
unaurhorilCd ancmpt to increase peirmjssion levels.
User security requires identity management, comprehensive p:issword protection,
defenses :igainst social engineering, an effective means of overcoming user resistance,
:ind consideration of new technologies. These topics arc discussed in the following
sections.
IDENTITY MANAGEMENT: Identity management refers to controls and procedures
necessary to identify legitimate users and system components. An identity management
strategy must balance technology, security, privacy, cost, and user productivity.
ldenrity management is an evolving technology that is being pursued intensively by
corporations, IT associations, and governments.
Carmer has described identity management as a "set of electronic records that
represent ... people, machines, devices, applications, and service ."This definition
suggests that not just users, but also each component in a system, must have a veri·
fiable identiry rhar is based on unique characteristics. For example, user :iuthenrica·
rion might be based on a combinacion of a password, a Social Securit)' number, an
employee number, a job title, and a physical locarion.
Bec:iuse of rhe devasraring consequences of intrusion, IT managers should give rop
priority to 1denrity management strategies and solutions.
PASSWORD PROTECTION: As the section on physical security point our, a secure
system must have a password poucy rhar requires mjnimum length, complexity, and a
limit on invalid login attempts. Although passwords are a key element in any security
program, users often choose passwords that arc easy to recall, and they sometimes
resent having ro remember complex passwords. For example, for several years in a
row, one of rhe most common computer passwords has been" 123456," an unfortu·
narc choice rhar is trivially easy to crack.
As long as passwords are used, IT managers should insist on passwords rhat have
a minimum length, require a combination of case-sensitive letters and numbers, and
must be changed periodicall y. Unforrunately, any password can be compromised if a
user writes it down and stores it in an easily accessible location such as a desk, a bulletin
board, or under the keyboard.
Several yea rs ago, a hacker made headlines by gaining acccs~ to the email account
of a political candidate. The intruder signed on as the candidate, requested a new
password, guessed the answers to the security questions, and was ahle ro enter the
accounr. These actions were totally illegal and constituted a serious felony under federal
law.
SOCIAL ENGINEERING: Even if users are protecting and securing their passwords,
an intruder might anempt to gain unauthorized access to a system using a
tactic called ~ocia l engineering. In a social engineering attack, an intruder uses social
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.6 Security Levels
433
interaction ro gain access ro a computer system. For example, the intruder might pretend
robe a new employee, an outside technician, or a journalist. Through a serie of
questions, rhe intruder tries to obtain the information chat he or she needs to compromise
the system. A common ploy i~ for the attacker to contact several people in the
same organi1ation and use some information from one source ro gain credibility and
entry to another source.
An mrruder also might contact the help desk and say, " Hi. This is Anna Dressler
from accounting. I seem to have forgotten my password. Could you give me a new
one?" Although this request might be legitimate, it also might be an attacker trying to
access the system. A password never should be given based solely on this telephone
call. The user should be required to provide further information to validate his or her
identity, such as a unique employee TD, a telephone extension, and a company ema ii
address.
One highly publicized form of social engineering is called pretexting, which is a
method of obtaining personal information under false pretenses. Pretexting is commonly
used as part of identity theft, wherein personal information or online credentials
are stolen and used for illegal purposes. The Federal Trade Com1nission's division
of Privacy, Identity & Online Security has a section dedicated to helping consumers
battle identify theft. The best way to combat social engineering attacks is with
employee education, more training, and a high level of awareness during day-ro-day
operations.
USER RESISTANCE: Many users, including some senior managers, dislike tight security
measures because rbe measures can be inconvenient and time consuming. Sysrems
analyst11 should remind users chac rhe company owes the best possible securiry co its
customer~, who have entrusted personal information to che firm; ro its employees,
who also have personal information stored in company fi les; and ro its shareholders,
who e"<pecr the company co have a uitable, effective, and comprehensive security
program char will safeguard company assets and resources. \Vhen users understand
this overall commirmenr ro security and feel that rbey are pan of ic, they are more
likely ro choose hener passwords, be more alen co security issues, and contribute ro
che overall success of the company's security program.
NEW TECHNOLOGIES: In addition to traditional measures and biometric devices,
new technologies can enhance security and prevent unauthorized access. For example,
the security token shown in Figure 12-25 is a
physical device that aurhenticares a legitimate
user. Some firms provide employees with security
cokens that generate a numeric validation
code, which the employee enters in addition to
his or her norm::d password.
Unfortunately, new technology sometimes
creates new risks. For example, a powerful
search application can scan all the files, documents,
emails, chars, and stored webpages nn
a user's computer. Although this might provide
a convenient way for users ro locate and
retrieve their data, ir also can make ic easier
for an intruder ro obtain private information,
especially in a multiuser environment, because
che program can recall and display almost
anything stored on the computer. Also, if an
FIGURE 12-25 Security tol<ens, which come in various forms. can
provide an addmonal level of secunty.
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 12
Managing Systems Support and Security
434 12.6 Security Levels
inrrudcr uses rhc rerm password in a search, the program mighr be able ro find password
reminders char are srored anY'vhere on che computer. To increase privacy for
multiuser compurers, each user shou Id have a separate accounr, wirh individual u ernamcs
and passwords.
Business and personal users also should use caurion when they consider cloudbased
srorage and services. In this environment, where rhe rechnology changes
rapidly, rhe besr ber may be ro work wirh well-established vendors, who can provide
significant cloud securiry experience and safeguards.
12.6.6 Procedural Security
Procedural security, also called operational security, is concerned with managerial
policies and controls that ensure secure operations. In fact, many IT professionals
believe that security depends more on managerial issues than technology. Management
must work to establish a corpora te culture that stresses the imporra11cc of security
ro the firm and its people. Proced ural security defines how particular tasks arc to
be performed, from large-scale data backups to everyday tasks such as storing emails
or forms. O ther procedures might spell o ut how co update firewall software o r how
security personnel sho uld treat suspected attackers.
All e mployees sho uld understand tha t they have a personal rcspcrnsibiliry for security.
For exam ple, an employee handbook mig ht require that users log o ut of their system
accounts, clear their desks, and secure a ll documents before leaving for the day.
T hese policies reduce the risk of dumpster diving attacks, in which an inrruder raids
desks or trash bins for valuable information. In addition, paper shredders should be
used to destroy sensitive documents.
Procedural securiry also includes safeguarding certain procedures chat would be
valuable to an anacker. The most com mon approach is a need-to-know concepr,
where access i~ limited to employees who need the information to perform sccuriry-related
tasks. ~1any firms also a p ply a set of classification levels for access to
company documents. For example, highly sensitive technical documents mighr be
available only to rhe IT support ream, while user-related materials would be available
to mo~t compa ny employees. If classification levels a re used, they hould be identified
clearly and enforced consistently.
Procedural security muse be supported by upper ma nagement and fully explained
to all employees. The organization must provide training co explain rhe procedures
and issue reminders from time to time that will make securiry issues a prioriry.
Chain Link Consulting is an IT consulting firm that specializes in system security issues. The company's
president has asked you to help her put together a presentation to a group of potential
clients at a trade show meeting next month. First, she wants you to review system security issues,
considering all six security levels. Then she wants you to come up with a list of WWi'fS that Chain
Link could test a client's security practices, in order to get a real-world assessment of vulnerability.
To make matters more interesting, she told you It was OK to be creative in your recommendations,
but not to propose any action that would be illegal or unethical. For example.
it would be OK to pose as a job applicant with false references to see if they were being
checked, but it would not be appropriate to pick a lock and enter the computer room.
Your report is due tomorrow. What will you suggest?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12. 7 Backup and Recovery
435
12. 7 BACKUP AND RECOVERY
Every sysrem musr provide for data backup and recovery. Backup refers ro copying
data at prescribed intervals, or continuously. Recovery in,·olves restoring the data and
restarting the system after an interruption. An overall backup and recovery plan that
prepares for a potential disaster is called a disaster recovery plan.
12.7. 1 GlobaJTerrorism
The tragic events of eptember 11 , 2001, and increased concern about global terrorism,
have led man)' companies to upgrade their backup and disaster recovery plans.
Heightened focu!. on di~asrer recovery has spawned a whole new industry, which
includes new cools and srrategies. Many rT professionals fee l that terrorism concerns
have raised security awareness throughout che corporate world. Although they are
separate topics, backup and disaster recovery issues usually are intertwined.
12.7.2 Backup Policies
The cornerstone of business dara protection is a backup policy, which contains
detailed instructions and procedures. An effective backup policy can help a firm continue
business operations and su rvive a catastrophe. The backup policy should specify
backup media, backup types, and retention periods.
BACKUP MEDIA: Backup media can include rape, bard drives, optical storage, and
onlinc storage. Physical backups must be carefully identified and stored in a secure
location. Offsiting refers to the practice of storing backup media away from the main
business location, in order ro mitigate the risk of a cacastrophic disaster such as a
flood, a fire, or an earthquake. Even if the operating system includes a backup utility,
many system administrators prefer to use specialized third-part)' software that offers
more options and ben cr controls for large-scale operations.
In addition to on ire data storage, cloud-based storage is growing rapidly. Many
companies use onlinc backup and retrieval services offered b)• leading vendors. For a
small- or mcdium-si1ed firm, this option can be cost effective and reliable.
BACKUP TYPES: Backups can be full, differential, incremental, or contmuous. A full
backup is a complete backup of every file on tbe system. Frequent full backups arc
time consuming and redundant if most fiJes are unchanged since the last full backup.
Instead of performing a full backup, another option is to perform a differential
backup, which is foster because it backs up only the files that are new or changed
since the last full backup. To restore the data to its original state, the last full backup
is restored first, and then the last differential backup is restored. Many IT managers
believe that a combination of full and differentia! backups is the best option because
it uses the least amount of storage space and is simple.
The fastest method, called an incremental backup, only includes recent files that
never have been backed up by any method. This approach, however, requires multiple
steps to restore the data--One for each incremental backup.
Most large systems use continuous backup, which is a real-time streaming method
tbat records all system activity as it occurs. This method requires hardware, software,
and substantial network capacity. However, system restoration is rapid and
effective because data is being captured in real time, as it occurs. Continuous backup
often uses a redundant array of independent disks (RAJD ) system that mirrors the
data. RAID S)'Stcms are called fault tolerant because a failu re of an)' one disk docs

Chapter 12
Managing Systems Support and Security
436 12. 7 Backup and Recovery
not disable the system. Compared co one large drive, a RAID design offers better
performance, greater capacity, and improved reliability. \X/hen installed on a server,
a RAIO array of multiple drives appears co rhe computer as a single logical drive.
Figure 12-26 shows a comparison of various backup methods.
Comparison of Backup Methods
BACKUP TYPE CHARACTERISTICS PROS AND CONS
Full Backs up all files. Slowest backup time and
requires the most storage
space. Rapid recovery
because all files are restored
in a single step.
Differential Only backs up files that Faster than a full backup and
are new or changed requires less storage space.
since the last full All data can be restored in
backup.
just two steps by using the
last full backup and the last
differential backup.
Incremental Only backs up files that Fastest backup and requires
are new o r changed the least storage space
since the last backup of because it only saves files
any kind.
that have never been backed
up. However. requires many
restore steps-<>ne for each
incremental backup.
Continuous Real-time, streaming Very expensive hardware.
method that records software, and network
all system activity. capacity. Recovery is very
fast because system can be.
re.stored to just be.fore an
interruption.
TYPICAL
FREQUENCY
Monthly or
weekly.
Weekly or daily.
Daily or more
often.
Usually only
used by large
firms and
network-based
systems.
FIGURE 12-26 Comparison of full, differential. incremencal,and continuous backup methods.
RETENTION PERIODS: Backups are scored for a specific retention period after
which they are cicher destroyed or cbe backup media is reused. Retention periods can
be a specific number of months or years, depending on legal requirements nnd company
policy. Stored media must be secured, protected, and in ventoried periodically.
12.7.3 Business Continuity Issues
Global concern nbout terrorism has raised awareness levels and increased top
management support for a business continuity strategy in the event of an emergency.
A disaster recovery pion describes actions to be taken, specifics key individuals and
rescue authorities to be notified, and spells out the role of employees in evacuation,
mitigation, and recovery effons. The disaster recovery plan should be accompanied by
a test plan, which can simulate various levels of emergencies and record the responses,
which can be analyzed and improved as necessary.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.8 System Retirement
437
After personnel arc safe, damage to company assets should be mitigated. The plan
might require shutting down systems to prevent further daca loss or moving physical
assets to a secure location. Afterward, the plan should focus on resuming business
operations, including the salvaging or replacement of equipment and the reco,·ery
of backup data. The main objective of a disaster recovery plan is ro restore busmess
operations to pre-disaster levels.
Disaster recovery plans are often part of a larger business continuity plan (SCP),
which goes beyond a recovery plan, and defines how critical business functions can
continue m the event of a major disruption. Some BCPs specify the use of a hot sire.
A hot site is an alternate IT location, anywhere in rhe world, that can support critical
systems in the event of a power outage, system crash, or physical catastrophe. A hoc
site requires data replication, which means that any transaction on the primary system
must be mirrored on the hot site. If the primary system becomes unavailable, the
hot site will have the latest data and can function seamlessly, with no downtime.
Although hot sites are attractive backup solutions, they are very expensive. I lowever,
a hot site provides the best insurance against major business interruptions. In
addition to hot sires, business insurance can be important in a worst-case scenario.
Although expensive, business insurance can offset the financial impact of system failure
and business interruption.
12.8 SYSTEM RETIRE"1ENT
At some point, every system becomes obsolete and is ripe for retirement. For example,
in the 1960s, punched cards represented the cutting edge of data management. Dara
was stored by punching holes at various positions and was retrieved by machmcs char
could sense the presence or absence of a punched hole. Mose full -size cards stored
only 80 characters, or byres, so more than 12,000 cards would be needed ro store a
megabyte. Punched cards were even used as checks and utility bills. Today, this technology
is obsolete.
Con~rantl)' changing technology means char every srsrem has a limited economic
life span. Analysts and managers can anticipate system obsolescence in several ways
and ir never should come as a complete surprise.
A system becomes obsolete when it no longer supports user needs, or when the
platform become!. outmoded. The most common reason for di~conrinuing a sy!.tem is
that it has reached the end of irs economically useful life, as indicated by the following
signs:
• The system's maintenance history indicates that adaptive and corrective maintenance
are increasing steadily.
• Operational cosrs or execution times are increasing rapidly, and routine perfective
maintenance docs not reverse or slow ·che trend.
• A sofnvnre package is available that provides che same or additional services
faster, better, and less expensively than the current system.
• ew technology offers :.t way to perform the same or :.idditional functions more
efficiently.
• ~lainrenance changes or additions are difficult and expensive ro perform.
• Users request significant new fearures to support business requirements.
Systems operation and support continue until a replacement system is installed.
Toward the end of a system's operational life, users are unlikely ro submit new

Chapter 12
Managing Systems Support and Security
438 12. 9 Future Challenges and Opportunities
requests for adaptive maincenance because they are looking forward to the new
release. Similarly, the IT staff usually does nor perform much perfective or preventive
maintenance because rhe system will nor be around long enough to justify rhe cost.
A system in it final stages requires corrective maintenance only to keep the system
operational.
User sati~faction typically determines the life span of a system. The critical success
factor for any system is whether or not it helps users achieve their operanonal and
business goals. All negative feedback should be investigated and documented, because
it can be the first signal of system obsolescence.
Ar some point in a system's operational life, maintenance costs stare to increase,
users begin to ask for more features and capability, new systems requests arc
submitted, and the SDLC begins again.
12. 9 fUTURE CHALLENGES AND OPPORTUNITIES
There is an old saying that rhe only constant in life is change. The same is true for
information technology-except thait the rate of change in IT seems to increase every
year. Rapid change can present numerous challenges to organizations and individuals,
but it can also offer exciting new oppornmicies. The secret to success is to be ready
for the changes that are bound ro occur and be proactive, nor reactive.
No prudent professional would Starr a complex journey without a map and a plan.
To navigate the futu re of information technology, companies require ~rrategic plans,
which were discussed in Chapter 2. An individual also needs a plan co reach to a specific
goal or desrinarion. This section discusses rrends and predictions rhar will affect
all IT professionals. To prepare for the challenges ahead, individuals will need to plan
and develop their knowledge, skills, and credentials.
12.9. 1 Trends and Predictions
Navigaring an IT career can be compared to sailing a ~mall ship in difficult seas.
Even a veq• good captain with a clear map for guidance will be subjected to forces
and circumstances that are sometimes beyond their control. What can be done is co
understand these forces and try to prepare for them. Figure 12-27 describes some
w111ds of change rhat may influence IT trends, including globali1arion, cechnology
integration, service orientation, cloud computing, and the workplace of the future.
In addition ro the trends described in Figure 12-27, most firms will face economic,
social, and political uncertainty. 1vlany IT experts believe that in this environment, the
top priorities will be the safety and security of corporate operations, agility and the
abi liry to quickly respond to changing market forces, and bottom-line TCO. Herc arc
some examples of possible trends and developments over the next few years:
• Cybcrcrime will increase significantly, with negative financial, social, and
national securit)' implications.
• Smartphoncs and tablets will become the dominant computing plarform for
mosr users, bypassing the trad itional PC or laptop as the device of choice.
• Software as a Service (SaaS) will become the norm, which will affect business
models and consumer costs as the industry moves from a purchase ro a leasing
model for computer applications.
• Cloud computing will become the principal computing infrastructure for rhe
enterprise, which in turn will enable software-as-a-service and lower TCO.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Phase 5
Systems Support and Security
12.9 Future Challenges and Opportunities
439
TREND
DESCRIPTION
IMPACT ON IT
GENERALLY
IMPACT ON FUTURE
SYSTEMS ANALYSTS
Globalization
New lands of corporaoons will
be globally integrated. driven
by the Internet. and free of
traditional trade barriers.
language skills will be exi:remely
important. Technology will open
new opportunities for developmg
countries to compete more
effectjyely. Knowledge worl<ers
will communicate and collaborate
across borders and boundaries.
Work will be done 24'7 across
multiple time zones.
Systems analysa will be directly
affected by global uends. They will
probably wort< for more finns '"
their careers. be exposed to more
mfonnati0n, need more teehnical
skills. and see greater change than
at any time in history.
Technology
Int egration
Powered by an enormous
mcrease in computing
power. new IT models will
include networks with smart.
interconnected deVJces such
as communication systems.
automobiles, entertainment,
transportation lnfrastrucwre,
and "smart" power grids.
New tec.hnology will drive ma1or
changes in how persona.I and
business services are provided.
Firms will compete in a global
marketplace that will reward
Innovation. creativity, and positive
soc.ietal outcomes.
The systems analyst will need
a. mix of business s~ and
technical skills. He or she will have
a unique opporwnity to work
at the Intersection of business
operations and IT. Synergy
between technology growth and
globalization will create jobs and
opportunities for people with the
right skills.
Service
Orie ntation
A business model of computing
where processing capabilities
and data storage are leased
(rented) instead of bought
(owned). Computing capabilities
are seen as servtees used
on-demand. hke electricity or
water, rather than as managed
programs.
Service orientation is a paradigm
shift. It represents a matunng
of the field. where end users no
longer care about technical details
as much as business functionality.
IT systems will be built using SOA
(service-oriented architecture)
to enable current and new
functionality to be delivered as
services to customers.
Systems analysts will need to
Increase their business acumen to
wort< effectively in a service-oriented
IT enwonment. Technical slolls wtl
still be needed. but services are
about fulfilling business requirements.
Cloud
C o mputing
Cloud computing is a new
model for delivering business
and IT services. It will have a
profound impact on business
strategies, including product
innovation, markeong. customer
relationships. and social media.
Cloud computing provides the
IT infrastructure that enables
service orientation.
The full potential of cloud
computing will be realized by
firms that can integrate cloud·
based infrastructure. services.
servers. data access, and a secure
environment. Creativity and
innovation will be rewarded. and
competition will be intense. Cloud
computing will lower TCO by
reducing capital expenditures.
Like any new technology. systems
development for cloud-based
applications will be a challenge
for some and an opportunity
for others. Regardless of the
development method or platform.
an analyst will need business savvy
and technical know-how to help an
organization take full advantage of
the cloud.
The Wortcplace
In the face of worldwide
competition and enormous
technology change, finns will
stress innovaoon. vision, and
the ability to adapt rapidly. The
abihty to think critically will be
Vita).
Successful IT workers must be able
to innovate. analyze. communicate
effectively, and "think outside the
box." The winners will be those
who can adapt to change and
embrace new technology and new
ways of doing business.
Students prepanng for the
workplace of tom0rrow will
need a strong skill set. Systems
analysts will be expected to bnng
convnunlcations, modeling. problem·
solvtng. decision malung. and critical
thinking skills to the workplace -
and to be aware of ethical issues that
might afect them.
FIGURE 12-27 Major trends and their impact on IT in general and on future systems analysts.

Chapter 12
Managing Systems Support and Security
440 12. 9 Future Challenges and Opportunities
• lnsourcing (the moving of jobs from off-shore location~ back home) will
increase, due to economic factors such as higher wages in emerging markers,
improved automation through che use of sophisticated manufacturing robots,
~ecurit)' concerns from outsourced components (hardware and software) developed
overseas, and political pressure co pre erve johs.
It is entirely possible that large enterprises would require suppliers to certify their
security credentials and sourcing policies. Another issue might relate to the growth of
cloud computing and large-scale data centers such as the one shown in Figure 12-28.
Access controls and issues related co international law concerning ownership and
surveillance of network acriviry between the data centers and cusromers around the
world will become progressively more imporrant as the digital life of companies and
individuals are placed online.
FIGURE 12-28 The rapid growth of data centers and cloud computing has increased security
and privacy concerns.
Oleo y ... I'\ •tod ...,
It's also possible that large enterprises will require suppliers to certify their green
credentials and sourcing policies. One issue might relate ro the explosion of data
sLorage and server farms, such as tbe one shown in Figure 12-28. These server farms
can use massive amounts of electricity, for normal operation and for cooling, which
affects the environment and the corporate bottom line.
12.9.2 Strategic Planning for IT Professionals
A systems analyst should think like a small business entrepreneur who has certain assets,
potential liabilities, and specific goals. Individuals, like companies, must have a strategic
plan. The srarring point is to formulate an answer to the following question: I lave career
goals been scr for rhe next year, che next chree )'Cars, and the next five years?
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Phase 5
Systems Support and Security
12.9 Future Challenges and Opportunities
441
Working backward from these goals, intermediate milestones can be de\'cloped. An
analyst's career can be managed just as an IT projecr would be managed. The project
management tool~ described in Chapter 3 can be used to construct a Gantt chart or a
PERT/CPM chart using months (or years) as rime unics. Once the plan is developed, it
should be monitored regularly to stay on track. As with an agile enterprise, progress
toward satisfying career goals should be corrected as needed.
12.9.3 IT Credentials and Ce rtification
In recent years, cechmcal credentials and certification have become extremely important
to IT emplo} ers and employees. In a broad sense, credentials include formal degrees,
diplomas, or certificates grnntcd by leanling institutions to show that a certain level
of education has been achieved. The rerm certification also has a special meamng that
relates 10 specific hardware and software skills that can be measured and verified by
examination. l·or example, a person might have a two- or four-year degree in Information
Systems and possess an JSTQB foundation level certification shown in Figure 12-29,
which attests to the person's software testing knowledge and skills.
~B -S--.'-'flo.. ___ ...
Cortollcatlont
l1nefit.1
Resources
Certifications
Whether you test software most of your day or just part of your day, software
testin& certifications build your path to jobs and promotions.
ISTQ8 C.." ........,, 11 the most "°"""'' sol-'· .... 1..una certif\c:atlon "" the .....id with mote than
570.000 tKtmt cert;.'lcates awarded .aoss 100+ count.-. ASTQB is lhe o!lk:ial U.S. ctnillcato>
tic.d tor ISTQ8. That's wily American COllllM!HS d1edt With us to se•ul you are~ !'led.
•
• --hoall.\J
• l
Foundation level Certlftcatlon (CTFL)
• -Tm!na CASTQe)
lSTOB Found.11lon Lovd M>ttwaie tntlna certiflatoon <CTFU os a cuecr e:;$C!llial '°' those
l nit soltwa .. Whether you IOS1 IOftware all clay or jUSt part llme !llrou£h A&ll o..ot>s
Of Conl l'IUOll1 De!IW<y you need ISTQB Found411on level te: "I cortfhcat en (C'Tfl.)
c ..... -
•
•
• T • Anolpt(ISTQIJ
FIGURE 1 l-29 ASTQB has created a very successful scheme for certifying software testers.
S~tte:Arr t 1r1S. tt· . .1111 ._( .di .d '"• • :rn
Rapid changes in rhe IT field require professionals adopr a life-long learning
approach ro managing their career. Even advanced degrees from universities have
a short half-life, which means continuing education credits are needed to maintain
competency. Nlany professional organizations offer continuing education courses and
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

Chapter 12
Managing Systems Support and Security
442 12. 9 Future Challenges and Opportunities
crcdcnrialcd ccrrificarcs, such as che ACM and the IEEE, as do IT industry leaders
such as tvl icrosoft, Cisco, and Oracle.
12.9.4 Critical Thinking Skills
In addicion co ccchnical skills, S)'Stems analysts must have soft skills, such as communications,
interpersonal, and perceptive abilities. In fact, employers often lament the
fact that their new hires are technically adept but lacking in these ocher areas. For a
successful career, these areas must be mastered too-parucularly for more M:nior leaderlthip
positions in the organization.
IT professionals also need critical thinking skills to succeed in the workplace.
Perhaps the most important skill taught to students in school is how to learn, so chac
chey can adapt to dynamic enviromnents later in their career. For example, it's not so
imporcanL for developers to know che lacest programming languages as it is for them
robe able to learn a new programming language very quickly.
T he importance of critical thinking skills has been recognized for some time. They
have been part of the higher cognitive levels of Bloom's taxonomy of learning objectives
in education for many years. What has changed-particularly within information
technology-is rbe relative importance of critica l thinking skills for long-term
ca recr success.
Our digital society is inundated with massive amounts of data. Data mining,
sophisticated algorithms, and technical innovation are important, but the most valuable
asset is an employee who can solve problems. The IT community has become
interested in critical chinking skills that can help a person find, organize, analyze, and
use che information that he or she needs on the job. Many employers now seek critical
thinkers who can locate data, identify important facts, and apply their knowledge
in real-world decisions.
Many training courses exist for technical skills bur developing critical chinking
skills is equally imporrant. Performing practice tasks that resemble actual workplace
casks can develop critical thinking skills. Studying systems analysis and design can
help, because it provides a solid foundation in techniques for developing models,
organi1ing data, and recognizing panerns. Just as with hardware or software skills,
formal cerrificarion is valuable in the job marketplace, but the greatest value is in
lean1ing rhe skills and using them to achieve career goals.
Many 111strucrors find that individual and ream-based exercises can strengthen
critical thinking skills. Examples include games, puzzles, brainstorming, crearive
problem-solving, decision tables, working with ethical questions, Boolean logic, Venn
diagrams, :ind using cause-and-effect tools such as Pareto charts, X-Y diagrams, and
fish bone diagrams, al l of which are found in this text.
12.9.5 Cyberethics
As computers permeate more and more of our lives, the decisions made by IT professionals
can have serious implications. Situations may arise involving ethical considerations
that arc not easy to resolve. Nevertheless, ethical, socia l, and legal aspects of IT
arc ropics that today's systems anaJyst should be prepared ro address.
In the rwo scenarios presented in the following "Question of Ethics" section, ask
yourself what would you do? Where would you draw the line? I low much would
you be willing co risk doing what you thought was the right thing? The decisions you
make could well affect your job and future employment (Scenario I ), bur rhcrc arc
other situations where rhe implications can be even more severe (Scenario 2).
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

12. 10 Summary
Phase S
Systems Support and Security
443
SCENARIO I : You have just completed a routine security audit on the company's
information systems, and you found several areas of vulnerability. For example, file permissions
have not been updated in some time, no comprehensive password policy exists, and
network traffic is not fully encrypted. You noted these areas, among others. in a report to
your supervisor. The report included specific recommendations to fix the problems.
Your supervisor responded by saying that budgets are tight right now. and she could
not approve your requests to resolve these issues. As an IT professional. you are very
uncomfortable with the risk level. but you have been unable to sway your supervisor.
When you discussed the situation with a colleague, he said, "Why worry about itl If it's
good enough for her. it should be good enough for you."
What do you think of your colleague's advice, an.d why! Is this an ethical question I If
you are stiff is uncomfortable, what are your options/
SCENARIO 2: You work for a large IT company. The company is presented with a legal
directive from the federal government to divulge personal data regarding some of the
company's customers who are suspected of wrongdoing.
You feel that this Is a violation of the customers' privacy and you are reluctant to comply
with the request. Your boss tells you the company has no choice; it must follow the
law. You are told you can always resign from the company if you feel so strongly about the
situation.
Instead of complying or resigning, you go public. You use the media to advocate your
point of view for freedom and privacy, even while knowing that your actions will have
far-reaching consequences. Instead of just losing your job, you risk losing your freedom
and your future.
Did you do the right thing! Are you a hero of free speech or a criminal (and possibly
even a traitor)1What other options were available to you1What should the company have
done when you went public! What should the government do1
12.10 SUMMARY
Systems support and security cover rhe period from the implementation of an
information system until the system no longer is used. A systems analyst's primary
involvement with an operational system is to manage and solve user support
reque&ts.
Corrective maintenance includes changes to correct errors. Adaptive maintenance
satisfies new systems requ irements, and per fective maintenance makes the
system more efficient. Adaptive and perfective maintenance changes often are called
enhancements. Preventive maintenance is performed to avoid future problems.
The typical maintenance process resembles a rniniarure version of the systems
development life cycle. A system request for maintenance work is submined and
evaluated. lf it is accepted, the request is prioritized and scheduled for the IT group.
The maintenance team then follows a logical progression of investigation, analysis,
design, development, testing, and implementation .
r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

Chapter 12
Managing Systems Support and Security
444 12.10 Summary
Corrective maincenancc projects occur when a user or an IT sea ff member rcporcs
a problem. Standard maintenance procedures usually arc followed for rclacivcly
minor errors hue work often begins immediately when users reporc significant errors.
In concrast to corrective maintenance, adaptive, perfective, and prevcncive maintenance
projects always follow rhe organization's srandard maincenance procedures.
Adaptive maintenance projects occur in response to user requescs for improvements
co meet changes in the business or operating environments. The IT staff usually initiates
perfeccive maintenance projects to improve performance or maintainability.
Aurom:ncd program restructuring and reengineering are forms of perfeccive maintenance.
In order to avoid future problems, IT staff perform prevenrive maintenance,
which involves analysis of areas where trouble is likely to occur.
A maintenance team consists of one or more syscems analyses and programmers.
Systems analysts need the same talents and abilities for maincenance work as chcy use
when developing a new system. Many IT departments arc organized into scparacc
new development and maintenance groups where staff members are rocated from one
group to the other.
Cl\11 is necessary to handle maincenance requests, to manage different versions
of the information system, and co distribute documentation changes. Maintenance
changes can be implemented as they are completed, or a release methodology can
be used in which all noncritical maintenance changes are collected and implemented
simultaneously. A release methodology usually is cost effeccivc and advantageous for
users because chcy do not have to work with a conscantly changing system. Sysrcms
analysts use functional, allocated, and product baselines as formal reference poincs to
measure syscem characreriscics at a specific rime.
Sysrem performance measurements include response rime, bandwidrh, rhroughpur,
and nirnaround rime. Capacity managemenc uses those measurements co forecast
what is needed to provide future levels of service and support. Also, CASE tools that
include S)'Stem evaluation and maintenance fearures can be u cd durmg che S}'Sccms
operation, securicy, and support phase.
Security is a viral pare of every information system. System security is dependent
upon a comprehensive security policy chat defines how organizational a~ets arc co be
procected and how attacks are ro be responded to.
Ri&k management creates a workable security poltq• by idenufying, analy1ing,
anticipating, and reducing risks to an accepcable level. Because mformatton systems
face a wide array of threats and attacks, six separace but interrelated security levels
should be analyzed: physical securiry, network securicy, application security, file
security, user security, and procedural security. Physical security concerns the physical
environment, includi11g critical equipment located in a computer room, as well
as safeguards for servers and desktops throughout the company. Network security
involves encryption techniques, as well as private networks and ocher protective
measures, especially where wireless transmissions are concerned. Application security
requires an understanding of services, hardening, application permissions, input
validation techniques, software patches and updates, and software logs. File security
involves chc use of encryption and pcnnissions, which can be assigned co individual
users or co user groups. User security involves identity management techniques, a
comprehensive password protection policy, an awareness of i.ocial engineering risks,
::111d an effective means of overcoming user resistance. Procedural security involves
managerial concrols and policies that ensure secure operations.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
12. 10 Summary
Phase 5
Systems Support and Security
445
Dara backup and recovery issues include backup media, backup schedules, and
rerenrion periods, as well as backup designs such as RAID and cloud-based backups.
All informarion systems evenrually become obsolere. The end of a system's economic
life usually ts signaled by rapidly increasing maintenance or operating cosrc;,
the ava1lahility of new software or hardware, or new requirements that cannot he
achieved easily by the existing S)Stem. When a certain point is reached, an information
system must be replaced, and the enrire sysrems development life cycle begmc;
again.
Many IT experts predict intense competition in the future, along with economic,
polincal, and social uncertainty. Facing these challenges, top IT priorines will be the
safety and security of corporarc operations, environmental concerns, and borrom-hne
TCO.
An IT professiona 1 should have a strategic career plan that includes long-term
goals and intermediate milestones. An important clement of a personal strategic plan
is the acquisition of IT credentials and certifications that document specific knowledge
and skills. Many IT industry leaders offer cerrification. Ln addition to technical
ability, other skills, such as critical thinking skills, also are extremely valuable.

Chapter 12
Managing Systems Support and Security
446 Key Terms
Key Te rms
acccpt.ancc Ont of four risk control strategies. ln accep1ancc. the nsk is accepted and no1hmg is done.
Ri>L. 1> u>uall)• .iccepted only ti protection from ri>k 1s de.ul} noc worth the expenst.
aJapu-e m:untcnancc AJJs new capabili[)• and enhancements co an exi>lln~ '>)'>lcm.
aJmml\lrator account An :ic.:ount that allows e.-senrtally unrc.,cm.te<l a~.,;e,., to the application.
allo.:atcJ ba.,dine Docwneuts the system ar che end of the de..1gn phase and 1den11fies an> changes since
che funcuonal baseline. The allocared baselme mcludes restmg and Hnf1ca11on of all sysrcm requirements
and fca1urcs.
applications programmer A person who wocks on new systems development and maintenance.
archi'cd The srorage of pre\•ious ,·ersion of a system when a new ver-ion i' in.,mlle<l.
a"ct Hardware, •mftware, daca, nerworks, people, or procedure\ that provide tani:ihle or imangihle hendi1
co an organi7.ariun.
attack A hos1ile ac1 1ha1 cargecs an information system, or an organii.ation itself.
automaiic update service Enables an application 10 conrnct the vendor's server ;rnd check for .t needed
p.trch.
a' ailahili1y One of 1hc 1hrcc main element' <>f sy,cem scciirity: cunfidcnciality, intc:gri1y, and .tvailahilicy
(ClA). t\vailah1licy ensure• chat anthorfacd user' have timely anJ rclinhlc ni;c:c" tu nt-cc"ary
in formarion.
a\Oid:rncc One of four ri<k conrrnl <rracegies. In avoidance, adding prmocci•c <af~uard< eliminate' the ri<k.
bJckup The process of saving a series of file or data copies robe retained for a specified period of time.
l).u.1 CJn be bJcked up eonnnuoudy, or at presenbcd mrer~lls.
b.idup meJ1.1 l.ht.i storage options. including tape. hard drl\e>. opw;Jl stor.ige •• ind onlllle storage.
b.uJ .. up poliC\ Detailed in;m1crion., and procedures for all bad.up>.
b:mJMJlh The amounl of data that the: 1-)'stc:m can hanJlc ma fi'(e<l 11mc pcnod. Band\\ 1dth rcquiremem<
arc cxprc:<;scd in bits pc:r second (bps).
baseline A formal reference pomr rhar measures sysrem charactemllcs at a sp«1fic 11me. !))Siems
analysts use baselines as )'ardsncks co document features and performance during the S)"Stems
developmem process.
b<:ndunark tl!itmg A form of tesung used by companies to measure s»cem performance.
biometric ..canning S) 'tems Mapping an individual's facial tearure~. han<lpnnt, or eye .:haracrerisrio. for
1dc1111fii:at1on purpo...:s.
BIO~-lncl pa\\\\ ord A pa>>word thac must be entered before I he: computer can be Maned. It prevent\ an
unaurhori7cd person from boortng a computer by usmg a secondary device. Also callc.-d a powrr-on
possword or a hom-levcl password.
boo1 lc1·cl password Sec B I O~- lc»cl password.
businc'' continuity plan (BCP) A plan chat defiaes how critical business func1ion~ can continue in cbc
evcnc of a ma1or disruption.
co1p.1ci1> planning A process rhar monitors current activity and performance level~ •• mm:iparc<. furure
Jcllvity, and forcca~t> the resources needed to provide dcsm:d leve l ~ of >crvicc.
ccr1ifica11on A credential an mJ1vidual cams by demonsrra11ng a certain level of knowledge and skill on
a STandardi1cd 1csr.
chanjlc control (CC) A process for controlling changes 111 S)'Stem requirements during software dc\Clnpmcm;
Jim an important tool for managing sy>tem chJnges and .:o•t<. after a s)stCm becomes
oper.:irional.
CIA mangle The three main elements of S)">tem secur1cy: confidenna.1.icy, 1ntegm). and availab1IU).
... ~ JD» (".............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:. .............._ .... ~---11rt~ -,..~---~~
.........,. _ _ .._..........., ..,,.........,..~_.......,_,_,_ ._....~~.. C'ftlpll"&.-..,~fw ..... _ ..........___,_ • .......,......................

Key Terms
Phase 5
Systems Support and Security
447
con6dcnuaht) One of the three main elements of S)'Stem securirr: con.6denrialiry, 111tegnt), and av;11bb1I·
11") (ClA,. Conf1den11aht) prote.:1> inform.moo from uoauthonzed discloser and IHlfeguards pnv.u:y.
confii:urauon manaitemcnt C.\1) A prcxe,s ior conrrolling changes in sy;tem rcqu1remen~ during the
development pha'>C\ or the 'IOLC. CM al'<> is an important tool for managing ')"tern ~hani;e' ;ind
coo;r, after a ')''tern hccomc' opcranonal.
continuou\ backup t\ rcal·rimc 'rreaming backup method chat records all \)'\tern acnv1ty a~ it occur\.
corrccti\c maintenance Changes ro rhe srscem ro fix errors.
credential' Formal qualificarions that include degrees, diplomas, or certificates granted by lcammg msti·
ruuons to •how that a cert.110 le, el of education has been achie,ed.
criucal ri\k When ri~k' nrc categori1.cd and prioriti1..ed, crirical risks (d1o;e with the highe>t 'ulncrabiliry
and impact rauni:sJ he.HJ the li.,t.
cri1ical thinl..ini; ,kilh The ahilot) to compare, da>>ify, evaluate, recogni1.e pancrn;,, analy1c cau'c and
effect, and appl)' logic. Such 'kil l ~ arc valued in the IT indu,try.
data replication In normJl opcraring condirions, any rransaction that occurs on the primary system must
auromt1tic,1lly prop~gace to the hot sire.
datab.i~c programmer A person who focuses on creating and sopporring large·scJle datab,1sc sys1ems.
denial of '>en ice (DOS) An onlinc ;mack that occur' when an attacking computer make~ repeated
rc:quc't' to a >crvic:e or \crvke< running on cermin portS.
differential backup A backup that indudc;, only the file;, chat have changed •mcc the la,t lull hack up.
disaster rcco\ery pl.in A documented procedure consisung of an overlil bJckup and recovery plJn.
distributed drnlJI of ~cn1ce (OOOS) A seC\ice arr.tel. invoh•ing multiple anJcktng computers that can
synchromzc DOS arr.1cks on a su\tr.
dump,tcr dMng R:udmg dc'k' or rra,h hm• For \•aluable informanon.
cn<r)pllon \ prt1<:c<s where data i< coded (convened into unreadable charal'tcr~) w that only tho...: w11h
the required authori1anon c.~n acce-1< the dara (usually via decoding wftwan:).
enhancement A new feature or capabi11ry.
c,pJ011 An arrack that takes advantage oi a system vulnerabiliry, often due to a comb111.mon of one or
more IDlproperly configured seC\ ices.
fault mana111:mcnt The timely detection and rc;,olucion of operarionnl problems. Fault management
include' mon11orini; a\) \!Cm for \l!;n< or trouble, logging :tll sysrcm failun:s, diagno;ini; the problem,
and ~pplyini; n1rrc<t1vc action.
fault 1okran1 A ')"tcm or applicnrion i< <aid robe fault tolerant if rhc failure of one compnncnt doc< not
di•ahlc the rest of rhc ')'<rem or application.
rircwall The main line of defense herwecn a local network, or intrnnet, and the lmcrnet.
full backup t\ complcrc backup of every file on the system.
functional ha,clinc The configurnrion of rhc S)"Stem documented ar the beginning or the project. It con
,ist\ o( .111 the necC>\ary 'l">fCm rcquiremems and design consrrain~.
gigabit> per \ccond (Gbp>) A bandwidth or throughput measurement.
hardenin11 Making a S)'MCm more ;ecure by removmg unnecessary accouor>, oerv1ces, Jnd features.
help dc\k A ccntralit.cd resource staffed br IT professionals th:tt pro•1des user> w11h the ;upport they
need to do their 1obo. A help dcok ha> three main objectives: to sho" people how 10 use\) >1cm
resource~ more cffccuvcly, ro provide an..wcrs co technical or opcranonal questions, and to make
u>er~ more producti\'c b) teaching chem how to meet their own mformation needs. All><> called scrvke
desk or mformauon umrer.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 12
Managing Systems Support and Security
448 Key Terms
hot \ttc A separate 11 locarion, ''hicb migbr be in anocher state or C\CD another counrr>, dut c.in suppon
crmc.il bu;ma; '>)•tern> lll che evenc of a power outage. S)>tem crJ>b, or ph)>K.11 cata;trophe.
1dcnut1 manallemcnt Concrols and procedures nece,sary to idenul) legmmate U'>Cf\ and >)>tcm
componcnr..
idcntit\ thcfc The \tcalmg of personally idcntil)·ing information nnlinc.
11'1 L ll02. I 11 A <ecumy standard for Wi-Fi wrreless networks chat uses the \VPAl prmocol, currcnrlr
rhc mosr secure encryption method for Wi-Fi nerworks.
incremental backup Sa"1ng a copy oi only the files chat have changed since the last full backup.
mtLf;rit) One of the three main elements of !iyscem security: confidenrialiry, intci;riry, and availability
(CIA). lmcwiry prevent\ unaud1urized asers from creating, modifying, or deleting information.
Khp; (kilobit; per •econd) A bandwidth or chroui,-hput measurement.
kcy;irokc logger A dc"ice that can be iuserred berween a keyboard and a c0Ulp1Her 10 record ke)'Slrokes.
log Record typ1call)' kepr by o perating systems and applic.mons rh ar documems .111 evenrs, incl udmg
dJres, 11mes, and 01her specific information. Logs can be im portant 111 lutdersranding pJst attacks and
prevcnring furure inrrus1ons.
m·:untt·nancc acri,~iric\ Chunging pr<>gra n1o;;, prc>ccdurcs, <lr d<x:un1entati<>n t<> c.:n,urc C<>rrcc."t system
performance. Adapting rhe '>ysrem ro changing requiremenrs, and makini; rhc \)'~rem operate more
dlodcndy. Tho,e need' are mer by correcrive, adapO\'e, perfecuve, and pre\entive maintenance.
mainu:nance ""P"ll't' Cost:' thar vary sii,'llificanrly during the t.y,tem\ operation.ii lite and include
\pcnc.hng to •upport mamttnancc ai;t1vit1C>.
ma101cnancc release A formal release of a new system version that cont.uns a number of changes.
maintenance release methodology A system of numbered releases used bi org.101z.111ons (especially soft­
" arc ~endors ) that helps organize mainre:nance clunges and updates.
ma1nren.tnce team One or more 'i)-•rems analyses and programmers workinll on product maintenance
1••ue<> together.
mal\\arc Maliciou\ ;oltware char mighr jeopardize the system\ -.ernriC) or privaq.
megabits per second (.\1bps) A bandwidch or througbpuc measurement.
metric~ Workload measurements, also called metrics, include the number of line> prinred, rhe number of
records accessed, and the number of cransacnons processed Ill a 1.vven tllll<' period.
n111114ation One uf four ri~k c.:ontrul \trarc:gies. Mir1ga1iun reduce; the: 1mpac1 of a mk b) careful pl.1nn11111
and preparanon. For example, a company can prepare a di~a~ter rc<ovcry plan to miri11ate rhc
effecrs of~ narural disaster should one occur.
network Two or more devices rhat a rc connected for the purpme of o;endtng, rc:cciving, nnd sharing dara.
net\\ Ork intcrfoce A combination of hardware and software rhnt allows th<' computer to inrcr.1ct with
the network.
ncc\\orl. intrusion dc1cction ;ystem (NlDS) Software that monitors nerwork traffic to detect •trrempted
111trus1011> or su.picmus nerwork traffic p:atreros and sends a l err~ to network .1dnllm>rr.11ors. Can be
helpful m documenting rhe efforrs o f arrackers and analyzing network performance.
offsit1n14 The practice of srormg backup media away from the main b u ~mc<> lo..:atmn, in c>rder ro mmgare
rhc risk of a carasrrophic disaster such as a Aood, fire, or earthquake.
opcnrnnnal co•rs fypcnses char are incurred after a sysrem is implemented and connnue while the sys
rem is in U\e. E>.amples include sysrem maintenance, supplies, equipment rent.11, and annual ><>ftware
hccn!>C recs.
opcr;s11on,1l ,c<urit) Concerned \\Ith 111.1nageria1 policia and coatrol; th.11 en~urc .e..urc op<ranon;.
Al~o called procedural sccuriry.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Key Terms
Phase 5
Systems Support and Security
449
patch Replacement code that 1s applied to fLx bugs or security boles in software.
!><'rfC~U\e ma1ntcnam.:c Changt."> to a S)'\tem to impr<l\'e efficiency.
permi~~ion\ U.cr-~pe,;1fi. pm 1leg(1, char determine the cype of acco~ a user h~ to a datab.i-.e, hie, or
d1rectol')« Al-.<> called u...:r ni;hl\.
plain tut Data that 1s nor cncryp1ed.
port A posmve 1111e11er rha1 1s med for rouang mcoming traffic to the correct appucaaon on .i computer.
port \c::tn An ancmpl to dct•-.:t 1he '>erncc~ runmni: on a computer by trying 10 conn<'Ct to variou\ port\
and recording the port\ on which a connection wa< accepted.
J><>wCr-un pa\\word 'iu RIOS-lc\cl pa\\word.
prctc,cing Obt.unmg personal inform.uion under false pretenses.
prc,·cnti\c maintenance Change~ to a <ysrem to reduce the possibiliry of fururc f.ulure.
private key cncrypuon A common encryption rcchnoloi;y called PKF.. The private key;., one of a pnir of
key~, and it dcaypt'- data rhnt has heen encrypted wirh the second part of the pair, the puhli<: key.
priva1c ocmork A dcdic,ucd connection, similar ro a leased telephone line.
prhilcge cscalJtion a11.1ck An unciuthorized auemp[ ro increase permission levels.
procedural ,cwrif) Concerned with managerial policies and conrrols char en~ure 'ernre operation;.. Al'o
call.:d op.:r:monal =unty.
produ<I ha,dinc Dc,<ribe, the 'Y'>tcm :It the beginning of optracion. The pro<luu ba..cline inrnrporatc'
an) chani;c' made 'incc the allocated ba•cline and include< rhc results of pcrfunnancc and acceptance
rc't' for rhc operational o;yo;rcm.
progr.immcr/an.llyst A dcs1gn.111on for posinons thar require a combination of S) srems anal) sis and
programming skills.
public key encl") puon (Pll.Ll A common encryption rechnique. Each user on the network bas a pJ1r of
ke) ;: .i pubu~ kc) dnd d pm .ue ke). The public key encrypts dat.i th.it cJU be decrypted "1th 1he
private key.
redundant arny of independent d"k' (R ;\m) A RAID system may be part of an ori;an11.;inun \ backup
and rccO\t~I") plans. A RAID system irurrors the data while processing coorioues. RAU> S)Stems are
called fauh·toleram, be.:ause J failure of any one disk does nor disable the system.
reco,ery The pr<K:c\\ of reqoring data and rescarting a ')'Stem after an inrerrupcion.
remo1e cootrol sofmarc Applications that allow IT staff co rake over a user"s workstanon and pro\lde
.uppor1 and irouble\hooting.
respomc umc The overall ume between a request for sysrem activity and the delivery of 1hc response. In
1he I) p1cal online e11v1ro11111cnt, response mne is measured from the insldnt 1he user presses the l:.NTLR
key or clicks a mou~ hutto11 unril the requesred screen display appears or printed outpur 1s read)'·
rc1ention pcnod Backups are stored for a specific retention period after which they arc either destroyed
or the bJckup media 1; reu;,ed.
rhk An evcnl that could affcu rhc project negatively.
ri-'>k a~~C-'>>ntcn1
Measure; the l1kehhood and impact of risks..
nsk control Develops ;,afeguard~ that reduce the likelihood and irnp.1ct of nsk!..
risk idcnul1cn1ion I 1;ting each risk and asse.,sing the likelihood that it could affect a pro1ect.
risl, management ·1 he proce>S ot idcntif)'ing, evaluating, cracking, and controlling ri;k~ to minimi1e their
1mpa<:t.
security H.irdwarc, ;.ofrwarc, and procedural controls that safeguard and protect a 'Y~tem and 11> data
from intern.ii or e"crnal threats.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 12
Managing Systems Support and Security
450 Key Terms
\ccurit~
\\.-.:urir~
hole Created bl a comblllarion of one or more improper!)· configured services.
poloq A plan chat addre-.!.t'> che chree main element'> of ~)Mem 'IC<:unt): c:onfidenciahry, mtei,'Ticy,
;ind Jva1bb1ht).
\ccunt\ tol...:n A ph)"cal device char authcnucate< a l~oumac.: u..er, 'u.:h a\ a "nart c-ard or lt,·c;hain
devic:c.
wrv1cc An applocanon rhac morurors, or lisrens on, a pamcular pore.
service des!.. A cenrrahzcd resource staffed by IT professionals due provides users \\1th the support they
need 10 do rheir jobs. Also called help desk.
\crvicc: pacl.. ,\ maintenance relea'IC ~upplied
hy commercial ~oftware ;,upplicr\.
\OCial engineering i\n incruder u;es social interaction co gain acce's co a c;omputcr s)";tcm.
soft ~kills Communications, mterpersonal skills. pecceprive abilities, and crinc.il thinking arc soft skills.
Ir profe&sionals must have soft skills as well as technical skills.
~ofm.1re rcenginccring Uses anal ytical techniques to idenufy potential qualiry .ind performance impcovemcncs
111 .in 1nformatio11 system.
'upcru\cr account A lui;in account thar allows c<~ntially llnrc:,tritted accc" ro rhc: apploc.11ion.
'Y'tcm admonhtrator A pc"on who i< rcspon, iblc for t he CM and mainrcnancc of an organi7:uion',
compmcr nctworh.
'YStem~ programmer A person who concenrraces on oix-rating system ~oftw.ire .ind uttlmes.
rampcr-c,idcnt case A case designed ro show any attempt ro oix-n or unlock the case.
tc't plan II plan de<;i!lTicd by a systems anal}•st that include\ test step< and te<t data for integration cestini:
and ')\tern re-;cing.
rhird·parcy sofr,.arc An application that is not de,·cloped in-house.
threat In nsk man.1gemenc, an internal or external oc external enut) that could endanger an asset.
throup.hpur A measurement of acrual ")"Stem performance under specific drcum\tance< and 1' affected h)
nc:rworl.. load, and hard" arc efficiency. Throughput, like bandwidth, i., cxprc, ....-d .i, a data rran.,icr
rare, such as Khps, ~ l hps, or Gbps.
cran,fcrcncc One of fou r risk control srratcgic:s. In transference:, ri,k "shifted co anorher asset or party,
such a< an insurance company.
tunnel A secure network connection esrahlished between the diem and che access point of the local
rntranet.
turnaround time A measure applied to centralized barch proce•smg oper;mom, ;ud1 :i:. cw.tomer billing
or credit card statement processmg. Turnaro<Uld rime measures the time between submnunp. a request
for informatton and rite fulfillme111 of the request. Turnaround ttmc also can be u<cd ro measure 1he
qualtt) of IT support or services by measuring the time from a user request for help to rhe resoluuon
of the problem.
uncnuyptcd Dara chat is not encrypted.
unintcrrupuhlc power \Upply (UPS) Battery-powered backup power ~ourcc rhat cnah l c~ operation~ to
co1111nue during short-term power outages and surge>.
Un1\cr\a( !>ccurity Slot (U~S )
Can be fastened to a cable lock or laptop :ilarm.
u><r r111ht> U;er-spec1fic privileges chat determine the t) pe of ac;ce;;, J user ha' to .1 Jat.1ba,e, file, or
directory. Also called permissions.
U'Cr 1ra1n1n11 packa11c The main objccnve of a user rra1mnp. package 1s to sho" user< how rhc system can
help them perform their jobs.
•m1on control The process of cracking sysrcm releases.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Phase 5
Systems Support and Security
Key Terms
451
•·inuJI pmate ncmorl.. \P'I U'cs a public network co connect remote users secure)). Allow) a remote
client to u~ .1 ;pt.-ctJI ke) exchange that mu;r be authenticated b) the VP1'.
vulocrab1ltt) A '>C\:urit) weakness or soft 'por.
what-if aiul) \I\ A feature of hu"ne'' \upporr sy>rems char allows analy'1~ to define and a''ount for a
wide varier)' of i\\ue' (indudmg i'>>Uc:<. nor completely defined).
\\"1-h Protected Acee~' (WPA) A common merhod used ro secure a wireless network. l b1s approach
rcqui~ each wireless client be configured manually to use a special, pre-shared kc), rather than kc)
pairs. rhe most recent .ind more secure version is \XfPAl.
\\ired lquh alcn1 Privacy (\\LP) One of the e-.irliest methods used 10 secure a wireless network. ;upcrseded
by WPA .111d WJ'A2.
~ ' l'A2 A wirdc" >cumty >tandard ba,ed on 802. 11 i char providt'l' a s1.inific;i11r increa>e 111 pro1cc11on
mer \WP '1nd WPA.
... ~JD»(" .............. .-\l............,.... _.,."'flllll.~-....-..-"*-·,..,_o.:..............._ .... ~---11rt~ -,..~---~~
.........,.__.._..........., ..,,.........,..~_.......,_,_,_._....~~.. C'ftlpll"&.-..,~fw ....._ ..........___,_ • .......,......................

Chapter 12
Managing Systems Support and Security
452 Exercises
Exe rcises
Questions
I. In what form5 can companies provide user support?
2. De~cribe four rypes of syMem maintenance.
3. \Vhat is CM and why is it important?
4. Define the following terms: response time, bandwidth, throughput, and t11r11aro1111d t1111e. I low are rhe
terms related?
5. What is the CIA triangle?
6. Explain the concept of risk management, including risk identification, assessment, and control.
7. What are the six security levels? Provide examples of threat categories, attacker profiles, and types of
attack~.
8. What arc some key issues that you must address when considering data backup and recovery?
9. Provide an example of technical obsolescence and explain how it can be a threat roan information
system.
10. Why is slratcgic planning important for IT professionals?
Discussion Topics
Projects
I. The four types of IT sy5tcm mainrcnance also apply to other industries. Suppose you were in charge
of aircraft maintenance for a small airline. Whac would be a specific example of each type of
maintenance?
2. Assume that your company uses a release methodology for its sales system. The currenr version is 5.5.
Decide whether each of the following changes would justify a version 6.0 release or be included in a
version 5.6 update: (a) Add a new reporr, (b) add a web interface, (c) add data validation checks, (d )
add an interface to the marketing S}'Stem, and (e) change the user interface.
3. How could you use a spreadsheet in capacity planning?
4. \X'hat are the most important IT security issues facing companies today? I lave these changed m the
last five years, and will they continue to change? H ow should companies prepare themselves for security
threats and problems in the future?
5. ~1any people don't back up rheir dara uncil ir's roo late. Once they go through a carnsrrophic loss of
all their work, they tend ro change their habits. \XThac arc some of the better ways ro perform personal
backups, such as cloud-based services?
I. Develop a process for managing change requests and design a form to handle a generic change
request. The process should include a contingency plan for changes that muse be resolved immediately.
2. Visit the IT department at your school or at a local company and find out whether performance
measurements arc used. Write a brief report describing your findings.
3. Security breaches arc in the news all the time. Document a recent hack involving the theft of employee
information or cusromer data. Suggest ways the arcack could have been avoided.
4. Using the Lnterner, locate a software package desig:ned to automate version control. Lbt the key
feature~ and describe your findings in a brief memo.
5. How do you decide if a car should be repaired or replaced? Develop an assessment framework to aid
this decision proces~. Is the framework also applicable ro software systems?
r..,,...JID)r-..1-.. 4•11_.. • ...__. ~ ....... .,...~ • ........._ .... .._.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._ ... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................ ._ .... ._

GLOSSARY
I: I A type of enmy rdu1on"11p. A one-ro-one rclanonship, ilbbrcvi·
Jlcd I: I. nt>I> "hen e,l,tly ont ol 1hc k\:Ond enril) oc<:Un> for e.\ch
1n;uJ1<:c of 1he ftl">t enuty.
l:M A l)pc of ennri rrlo11on>h1p. A one to man} rebt1onship. abbre­
'iatcd I :~I, C•1>b "hen ooc O<.lurrcll<.e ol 1he hr;t enUI) can be
relarcd to many occurttnccs of the <crond enmy. but each occurrence
ol 1he ~ood ct1111) ~n be as>0<1arcd wuh onlt one occurttnce of the
f1r.1 en111y.
801. 11 A famtl' ol w1rc:b<o network tpte1hcatlons d"' eloped by the
l[l:L
101.1 1 ac An llJ.l wirrle" network >pecifica11on, apprm·cd 111 2014,
d1ar uses e\pandcd MIMO rcchnology to achieve chcorctical speeds of
ncJrly 7 GbP> w htle mtr<J\lnJ; thew trek» range and ts backward
companblc wnh 802.11 J, b, g, and n.
801.1 lb An IEE£ wirelc" network >pl'Cilica11on introduced m 1999
ba;ed " " a fre<1uen•y of 2.4 (,111 and maxunum bandwidth of 11
Mbp>. Replaced hy 802.1 lg.
802.1 lg An IEEF wireless nt'1work spocificntion introduced in 2003
ba;cd on J frcqucn<)' of 2.4 C. 111 nnd ma<imum handwiclth etf 54
Mbps: cetmpJclblc with and rcplnccd 802.1 lb •nd h•s been superseded
by the 802. 11 n 'tJndJrd.
802.1 In An IFFI. wirek" network ~petif1cat1on •dopccd m 2009 rhac
uses MIMO te.hnolo1t) to ach1e>e 'peeds of 200+ Mbps while increos·
Uljt tltc "1relc'' r•ngc and 1; ha< kw.ml rnmpat1blt woth 802.1 IJ, b,
Jndg.
abbreviation code AlphobctK ohbrevution. For example, standard
'tJte Cf>ele. ui.111'1r NY for New York, I\!~ for \13111e, •nd Mt\ for
Minnesota.
absolute date Tho roral numhtr of t!Jys from some specific base dace.
To calculate the numhtr of d•ys between two absolurr dares, subtract
one d•te from the Other. For e'lmple. usmg a b:»e due of January I.
l'JOO. '>eptemhtr 27, 2012, h." •n oi.-.olu1e date value of 41179 and
Juh 13. 2011, h.u •n •l>solure date of 407r. If the eatlier dare v3lue
"•ubtrac1cd from the bter one, the rl'\uh "442 da)'>.
acceptance One of four nsk control nrat<g•"'· In acceptance, the nsk
1s ac<'Cptcd and nothmg 1; done. Rbk " u;uallv accepted only if protec·
lion from ml °' dearf) not \\OMh 1he CXJ'<'n>e.
acceptance te-st Tt\t1ng nt\OI,·~ the cnritt 1nform.Jrion S)''\rt:m,
mdudn'lJl all !) p1<al pnx:e»1nR ;m1a11ons. Durmi: an aettp1aoce rest,
user> cntrr dat•, 1ndudmg <.>mpl"' ol actual or h\e dalJ, perform quc·
nes. •nd produce report> 10 >1mubtc actual operanng condmnns. All
proce>\ln!I opll011' and output> are 'erificd hy user~ and rhe IT pro1ect
development team ro en~un: rhar che srsrem funcnons correcrly. Somenmes
kno" n a> a »•tnn ttlot.
ac:c:es1 point A ccnLral \vtrC'lcss dt\'ICC' that prov1dC's ncrn•ork serv1as
w wirelc;s clients.
action code lndkaccs what ornon t> to be tJken "ith an a;sociattd
ucm. for cx•mplr, a .i11dcn1 rccorJ> program migh1 prompt a u<er 10
enter or click an acii<>n code •uch os I) (rn display rhe student's record),
A (to add J re<=ord), and X (10 c•il the progr.11n).
activity /\ny work rh.11 has J hcginnmg ond on end and requires rhc
ui..e of c.:ouipan) rt.~ourt·c, lnc.ludinH people, thnc, :ind/or moaey. Example\
111t:ludt t:ondut:UllK J ~erie~ of interviews, des1gr11ng a report,
seleermg ~ofiwore, woinn11 for rhc deli\ cry of equipment, and training
users. Su ,1/su tn>k
activity diagram 1\ d1•11ram thar rc<emhlcs n hcmzomal flowchart
that >ho"> the •cuon> and c•cnt• »they occur. t\cuvity diagrams
•how tbe order in -.h1<h •wons tale pla<e ond idennly the ourcome.
a«or An external mrtl) w11h • •pccific role. In • u<e case model.
acron MC used to model 1111era<t1on wuh the ')>rtm.
adiiptift ~ntan;ance Add> "'"' cap.h1l11) and mh2n..:c:mcnt< man
existing ~y'Stcm.
administneor account An account that allo"' e.~mally unrc­
•Ulcted acce.• to iM •pphcJtl<lll.
agile methods ~ysrems <k-\clopment m<rhod> th•t attempt to tk•dop
a system mcremcnr.11) h) hmldmg a 'et'I<'• of prorol)·pc, and con·
suntl) ad1usnng them to user requirement~. Also called adapt"e
method,.
aJiu A term U\cd 111 v.tnou~ dat.i dtc.uonan~ to 1nd1e.:Jtr 0111 alternate
name, or a name other than the st.rndard d•ta clement name, thJt is
u;ed tet d<><.rihc the ;3n1e data element.
allocated baseline Do..um<nt• th< >YM<m .u th<" end of the de>1gn
pha<c and idennf1e< nny <hangc' •in<e 1hc funwonJI ha<chne. The
alloc<1ted baseline include> rc;ung ond verif1ca11on of all system
requ1ren1enu. and fe.uurc,,
alphabetic code U>e> nlphahe1 lmcr> to dmini;1mh one ttrm from
•nochcr based on a cJtcgory, "" ahl>rcvfo11011, or on co>r·tO·rcmembcr
value. c•lled • mnemonic .ode.
app t\ software applic.111on that run< on• mobile device, >uch •s J
smart phone or tablet.
application !>art of the mforma11on •rucm, on applk•tton handles the
input. manages the pro<.es;ini: logic, ,md provid~ the required ourput.
application dttelopment rh< pr<x.C>> of <0n\fru<1inj: the pro(tr>lll>
and code modul~ that >re the huildmJI hln.l• ot an 1nforma11on sysrem.
Apphcanon development 1s handlrd h) an apphcanon
dcvelopntCOf jtl'OUp Wllhm a 1uJ1t1ona( rf drp.lrtmcnt rhat IS COm·
posed of 'Y'tcm< an•I) m and pr"l1rammcr\ who handle mfonnanon
s-.tem de.1gn. de• elormcnt. and irnpkmenta11on.
application lifecycle man.a1•~nt (ALM) Actt\lri"' 1h.n cover the
ctlt1tt ~DL(., nt<ludmg ttqu1n:mcnts. dC\ll!J1, dndopmcnt, r<Stlng. and
dcplo) mcnt and management nf softwan: appl1<>11on•.
appliation lock The undrrlpni: bu"""~' nil~ or logic for an apph·
c.31100.
application server A \.<>n1putcr .ic.UnA .l\ ""m1JJl~mc-n • ~'ten cu, ..
tomcr; and .an orgamr.anon'• datal>a<e<i and apphcanon~. Oftrn u<ed to
focilir.ate complex hu.,ncss rransacnons.
appli~tlon servke provider (ASP) A firtn rhat dell\ rr> 2 wfm are
aprlica11on, or acet<>> to an •pphca11on, t>y chJrgrng a usoge or suhscription
fee.
application software Software pn.~ram>, ;u,h n> email, word processors.
spr<ad>heet>, 3nd j;J'.1ph11.' pa.bj.\C-, U>ed by employee\ in typic:il
office \Ccnar1os.
applications programmer A person "ho works on new systems
devclop1ncnt .Jnd mnintcn~tnce.
archived The StofJjl< of previou> V<r>io11 ur a ')'>tcm when J new
vcr"ion I" in\tallC"d.
artificial Int elligence l11e .mempt t0 recre3le natural 1ntell1gencc
through sofiware in mad1ine>.
ASCII S1'111ili for A111criGt11 St.111d,1rJ Code for lnformnuon Inter·
change, a d.tta "orngr <odmi: mrthnJ u<ed 011 mO\I pcr,onnl
computers and worl.<.t•tton>.
asset Hardware. ;ofrware, d,ttJ, network~. people, or prOledures that
provide rang1hle or tntan111ble hentfu roan ori;.in11a1111n.
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..
453

454
Glossary
associative entity An cnmy that has ti> own set oi annburos and
characrcmll•-S. ~'><X1Juve cn1111c< arc u">td to lank ~h\Cen many·toman>
(M:N) rclauo"'hips.
attack A h~nlt act du.t targf't.) an 1nfomuu<1n \))tern., nr n.n orgaru·
uuon itself.
attribute \ '1nglc: ch~r.lctC'rt,11c or fa~r ahout an cnnt)\ An anr1hu1c,
or field. 1s the smalkst p1cct of data that has meaning wnhin an information
S\Sltm. For example. a Soc1•I !.c.:unt) number or cornp•n}
name could he c•.implt"i of an atrnhurc. In oh1m-onented analrsi<, an
attnbute is pan of a dass diagram that d~n~ the charactcrisncs of
ob1«tS rn d1e class. Aho \.nown as• data elcnlt"nt.
audit fields Sp.•ual hdd' within data r<'\.01J, (() rnMde aJdmonal
control or =unry mformannn. l)'r1<.1I .1udn field~ mduJr the dare the
record was created or modified. rhe name of rhc user who performed
the Jlllun, and the number of um<> 1hc 1c,orJ h"' lieen .1,ce-..ed.
audit 101 files Rr<ord derail. ol nil accc'""' nnd <hangcs ro .1 file or
database and can be used ro rc<ovtr ch3ngr< made ~mcc r:he last
backup.
audit trail A r<-..ord of the wur<c of cadt d:na item :ind "hen 1t
cncered 3 syste1n. In Addition tu 1·c,ord1n~ 1he orig1nnl ~ource, ;1n audj1
trail mu<t show how ond when dara 1< acce.-ecl or chaogcd, and hy
whom. AU these action> mu;r be loi:gcd in an audit r:r.111 file and momrore<I
carefully.
authorization zone Puri of ti for111 thJt conra111i any required 'ignatures.
autom:lted fax A sySttm thM allow• a cu~romcr to request a fox
using email, the rnmpJny wtb>11e. 1H .1 tcleph<1ne. The r«po1L•e is
transmmcd m • mJtrrt of sc.onds ba1.k to the u<er's fax machine.
See fa"back.
:lutomatlc update service Enable¥ •n appl1canon 10 contact the 'en·
dor'> scr;cr and chet:k for a nrcdcd pJtth.
anil..t>ility One of the thr.-., m.nn dcmcnr- of <)>rem securu): confi·
drnnalal}\ mrcgnl}·. and ava1l.1h1hf} ((.I \). Ava1lah1lny cn<urc< that
authori.u.-J users h»c umelv •nd rdtJble acct'> to ne<e>>af) tnfoml3-
uun.
;ovoid;once One of four ra>~ control <trJtcg1r<. In avoadanc<. add mg
prorecn•c safeguard< chmanJctl> rhe n~k.
B2B (business·to-buslnHs) A commercial c>:chani;e (e.g .. producrs
or"°" r<.e>) b.:twcrn bu>Ull'>""~· I) pa<Jll) r1ublcJ b) the Internet oc
t"lcctron1c means.
82C (business-to-consumer) A commrmal rxchangc (e.g., produas
or M'.n ich~ bc.-t"·ccn bu.>ult.~~ 3nJ c.on)utncr) c.:<)nducted O\'er the
Internet.
backup The 1mx:e.- <>f <avmf! • <crrc< of file or darn cop1e< ro 1"'
rctamcd for a sp«1f1cd period of ttmc:. Dara c•n l>c backed up connnuously,
or at prL">crrlx-d mtcrvals.
backup media Dara storage options. mdudini: ••pr, hard drhes, oprica1
sroragc, and on line i»torotgc.
backup policy Octaded m<rrurnon< .ind procedures for all hackups.
balancing A proccs< U>Cd tO 111amra1n com1<tc11cy among an entire
series of diagrams, indud1ni: input and ourpur darn nows, d31:t ddinition.
and proccs:'.) dc~crirn1on~.
bandwidth I he nmount of .lnin tlMt thc ,y<rem <a 11 hnndk 1n ,, fixc<i
rime period. ll;Jndwidth rcquireme1m nre e~pre<<ed in b1t1 per second
(bps).
baseline A Formal rc(t"rcncc po1nl t har 1ne~\lJft"S S)'btt'm ch:irattcrisria.
ar .1 <1:><cafic trme. ~y<tcm< anal} \N u•c h.l<cl1n01 •< yardsttck< to docu·
mcnt foar:urcs and pcrforman<C durmg rhc S)·•tcm< dewlopmem
pr<><."t'SS.
Basic Suvice Set (BSS) A w1rcl<\> network wnfigurJt1on m wh1,h •
central mrcl011 dn1cc c.1llcd .in accc<1 point IS used to serve all wireless
cUenrs: also called mfrastru<turc mode.
batch A group of dara, usuolly mpum:d mto an mlormotton system••
the same trmc.
batch control A total used to verify hal(h mpur. Bat<h conrroh might
check dna ircms such a; rc<ord ..:ounh Jnd nunl<n.; field total>. For
example. before cnrcrin11 • bat•h of or.lcr.. J u;cr might •akulate the
roral number ol orders and th.. •um of •II the order qu•nt111cs. \~'hen
rhe barch of order$ as tmtercd, rhe order S}Stem •I~ calcu!JrM the same
two r0<als. If the system tocal• do not mat<h the mpu1 totals, then a
dar:::i entr) error rua. 0<:.urrcJ.
bnch input A pnxe'> \\Ocre Jat3 entr) 1> p<rformcJ on a •pe.1ficJ
nme o;chcdulc, •uch •> d.i1ly, weekly, monthly, or longer. l·or c•.tmplc.
batch input occurs when a pa)'roll dcpanmenr ..:ollcch ume cuds ar
the end of the week and cnrcn the data as a bat<h.
benchmark A llR'la.ure> of the umc a pachA• taka to proca> acertain
number of 1 ransacttons.
benchm;ork tMting A form of re;ung u>CJ by compomc' ro measure
S)'Stem pcrfonn•ncc.
best-case estimate Tiic most opc11n1NU~ ouh.:Onlc.
big data Exrrcmel)' large darasc1; (e.g., pc1ahy1cs) rcquanng 110111rad1-
tion;tl approaches to deal wnh them. ~ometim.- chnrncccri1ed by three
rerms: '"'lu111e, varie1y, .ind vclo<.:.Hy.
binary storage form;ot A form.II r hat uffc" df1cic111 >to1·agc uf
nu11ieric dnta. For e'<.1n1ple, \vhrn nu1n!'rit ttu.1 type!\ nl"'t ~pec i(i cd
using :VUcrosolt Access, rhere are• vnricry of ~torai:c formnrs choice<,
in(ludin.g integt.>r and Joni.; u1tt~t_)t, anio1t~ other),
biometric devices A mei.:h~111~111 u!!ioe<l to unique!) 1Jcntl(y J ~r,on
by a rc:tmJ S<:an or hy 111.1 PP'"ll " f,m.1 I p.ltltrn.
biometric scanning systems /'.lapping .111 1tldl\ 11luul\ foc1al feanircs,
handprinr. or ere charnctcmtrcs for 1den11ficunon purpoo;cs.
BIOS-level password A password tha1 mu11 he cnrercd before the
computer can be stancJ. It pre-ems an unaurhonuJ P<'rson from
boormg a computer bl' using~ sccond•ry J.-i<<. Alw called• poweron
password or a boot-le•cl f'.l>S"ord.
bit llie smallr<t unn of data 1; one lllnaf} d1gu.
black box A mel3phor for a prexes; or an .1<t1on rhat produa' re.uh>
in a noo"{l'ansparem or noo-observ•blc manner. In d.na flow d1Jgrams.
a process appcus a; a bla•k bo' "here th.. input>. output>, Jnd i:encra
I funcnon ol rhc P""""'" •re known, bur the underlying ck131f, Me
nor ,..ho,vn.
bla.ck hole A proce-s thar hu no output.
block sequence code Cipher thJt u""' hlocks of number< for differ·
enr cla~~ifl'---ations.
blockchain A dr>tnbuttd ledger >y>tent. The re<hnologl' under!) mg
B1tco1n.
blog An onlmc 1oun1;1I. The term ts a con1r.1won of"''°" Ing."
Bluetooth A fonn nf wircl"' 1r.n,nm<ion very 1x•pul.r for 'hondisrancc
wirclc" communrc.ttaon thar docs nor require high power.
bOC>t•level password Sec BIOS·levcl pamHard.
bottom-4.tp technique A method for analiting u lnrgc, complex proj
ecr us a series of mdividual 1n,k>, called proj•"<t t<l'k>.
brainstorming A fact-finding tcduuquc for ga111in11111formnuon
through rht use of a small group dl\CU><ion of a 'l''"'f" problem,
opporrunity, or issue.
bring your own device (BYOD) An c-qurpmcn1 m.rn,1gcmcnt model
wh.ere employees a.re in chMge of their devices (e.11., computers, rablecs,
smartphone>) ar work. nor the IT depanment. This 1nduJes dcvi.e
selecnon and serup. program ln\t;.U.111110 and upda11ng, and nerwork
connecrivtf} !including sccunt)").
Brooks' law Frederick Brook .. nn IBM tng1nccr. ol><crved that addini;
more manpower to J lat~ wft"•rc pro1<"<t only make> 11 later.
(....,..... J:gi ( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----··----~~-.,.-"~ ...........--......
Glossary
455
bug tracklna soltware ~t•«m JC\ <lop<"n use Jcf«-r 1r.1dung sohworc,
somctomc' cdllcd bug rrackong software, ro document and rraclc
program ddc-.u. rndc ch.log<>. and ropbctmrot code, called patches.
build or buy A tho1<c bt-c"'"'" JC'\doponjt on-hou'>C >oftwatt and pur·
chasing 'Ofl\\are. often Llllrd • huold or bu), or rndkc or bui. decision.
bus network A cnmputrr network where a single cnmmumcanon
path tonn~h me maontramc mmputer. '>Cne~ \\Orlsrauons, ~d
peripheral ck\lte>. lnformatoon o< tnn<moned on cnher do=-roon from
any worhtanon IO another worhtauon, and any mt>"3gc can be
dlrt'CtN to a >peclfK dc\lce.
bu>iness case Rdcr• m the r<a>0n>. or 1us11f1<anon, for a proposli.
bu1ineu continuity plan (BCP) A plan that ckfincs how cn11cal buson~s.
function~ can conunuc 1n thr C\ent of a ma1or disrupnon.
businus loci< Rule> ro derrrminc how a S)Srcm handles data ~d
producn u"'ful onformanun. rdl~nnll the Op<"ratmnal rcquoromcnt:> of
the busone<<. f.'<ample< include addong rhe proper amounr of sales rilx
to 111\'00<cs, ca kulaunll cu>tomrr balances and fina11cc charges, and
drtermonin11 wh"1her a customer i< elogohle for a \Olume·hased dos·
count. Also .:al led business rules.
business model A graphical rcpre•en1J1ion of bu>onc"'• funtrion>
rhat con~1~ l of bu,1nci.\ prcxC\!tlt.'\, ) Ut...h ai; sa l c~t ,1ccounring. and
purcha•dng.
business process A de.cripuon of 'pccofic event§, tasks, and desired
rt-~ult~.
business proc:eu model (BPM) i\ 11roph1c.1l rq)rc.c111.111on of one- or
1norc hus1nc~, proce'~~.
business process modellna notation (BPMN) A srnndard >Ct of
'hJp<'> aml >)lllOOls u<ed 10 repre<eno tvenos. proceS>e<, and worlcllows
tn rnmputcr·ba;cd rnodclong rool<.
business process outsourdns (BPO) The our<ourcong of a basic
busonc>> pl"O\.c». Su ulsu outwurcing.
busin.ss profile A Jdonouon ol a 1.ompan) '> o.er.111 funcnon;, pr<>­
=5"s. org;in11..a11nn, product<, <en•=· customers. suppliers.
~owpetiton, t..:on~tr.11nt), and furure J1rC\.-i1on.
busln.ss rvlM Ho" a \y,tem handl~ data and produces useful informallon.
Bu""°'' ruks. al«> called bu<onc>• logic, refl<et che opcranonal
roquiremcn" of the bu,mcss. f,Jmple. ondudc adding the proper
,;amount o( ~In ta->-. to 10\ t>Kn., uh.:ul3t1n~ ru'tomer b.ilanch and
finance charges, and cktt'Tmonong "hcthcr a cu<romtt is chgiblc for a
\Olume·bascd d1~oum.
businus rules s..~ bu1incs> loi;1c.
bu5ineu 1upport systems Prn"d" 1ub·related onformauon >upporr tu
users at all leHls of• comp•n).
byte A group of coght bor< 1\ c.illcd a byre. or a character. A set of
bytes foron> a foclJ, "111,h "an inJoviJuJI fact about a per.on, a place.
a 1h1ng. or an r\·cnt.
calendar control A <Jkndar control alkm' rhe user to sckct a dace
that the >y>1em will d1>pl•y and -.ore°' a field value.
candidate key ~0111<11me• 11 i, p<>»1ble to ha' c J choice of fielcl> or
focld cmnh1na11on' ro u<r •~the pronrnry key. Anr focld rhat could scn-c
JS a primary key os tailed a .:andidace key.
Capability Maturity Model (CHM) A model developed by SE! rbat
uHcgrJtc~ ~O h\YJrt ;.uuJ ')''t<'nl1t dC'\•clopn1r-nt u1ro :.t prexes~ i111provcmc11r
framework.
Capability Maturity Model lntesratlon (CMM I) An SEI-<lcvdopcd
pr<Xt.)~ lt> tUlptO\'t qu~hr,.•. rtdu(t develc>pn1enr nme, nnd t.:uc CO!>CS-. A
CMM trJcJ..~ an org.11111.111on\ ,oft" arc dc•tlopmeou goals atid practices,
usoni: fivt marurocy level!, from Level l (relaci\'ely unstJble,
oneffccme sofnvattl to Level.~ (wfmarc that i~ refined, efhcicnt, and
rdoalile).
capacity plannina A pro;:e<;, thot mon11ors current acto\'it) and perforrnant.t
lt":\tl.), ;anL11..1p.i1e> future a.._11VU) • .ind foret.:.:ts..u che: resourt:es
n~dcd 10 provide dt<Jtcd le..rh of .en oce.
cardinality A concept 1ha1 des<:ro"-'< how instance. of one cnnry relate
10 instances of another en tu). ~rohed 1n enrol) -rdauonshop
chagran1> bv 001.1000 !hat ondocJte> <ombonanons th.i ondu<l• uro
<X onr-ce>-man)-. onc-t<>-<>lle'~ 3.nd nun)'·ro-n1any.
cardinality notation C.ode th.11 \ho"' rrbroon\hop< bet"ecn en1111es.
a.se for action ~ p.irl o( the prl'hm1n.iry 1n\:c~n1eanon r<"pon m management
that summJ.nzcs pfO!<-.:t requem and nukt< speofic
recommcndJuons.
CASE tools Pm-.rlul \oftw;trt u..ed on rnmputer-aodcd '),rem> engi·
nernng (CASE! tn help S)Sten" an.1lim de,·elop and ma1nt.11n
mfomutioo srstenu.
category codes Cophe..,. thJr 1dtn11f) a group of related irem>. For
cxanlrlr, a loc.:JI dcp~nnlcnt ~tore n1ay uq- .1 l\\<H.:turatt<'r cat~orl
code ro 1den11fy the dcpJrtmcnt on \\hi<h a product os sold.
certification A credential an ind" odual earns by dcmonsrrJring acer·
ta in le\ d of koowl<Jgc JnJ •I.ill on '' •W1dJrd11cJ tt>t.
change control (CC) A pl"O\.e~' for wmrollong chang~ in system
rcquoremen.-. during 'IOftware dcvdopmenr: al<o •n omportanr rool for
managing system chan{:c; and tn>ti after a Sy\lcm bceomes operational.
char:tcter A jlroup of '11\ht bots 1s called a chaucter, or a byte. A set
of b}te' forms .1 l1dJ, whoch ;, an md1v1tlu.1l fO(:r :1hou1 a pe"on, a
place. a thong, 01· an c'cni.
cha.racter-based report A report created usong a s111glc mono-spaced
character !tCr.
check box U.seJ 10 >elect one or onor< choke> from .1 group. A chc.k
mork, or on X, rcprc~em' >elccm.I op111>11'.
child di31ram The lower-level d1.1grom on on cwlodcd DFD.
child ln onhcrotance, • child '' the ohJt" that derive< one or more
arcributes from anorhrr obtrct. called rhe p.tttnt.
CIA trungle The three m~lll dconenh uf l)'ltm ..c..unly: ;confidmii3l-
1ry, mregroty, •nd a-.olabolot>cipher
codu USt of a kc> word to encode a number. A retail Storr. for
example. mat U5" a 10-lettcr word. •ucb a• C..\l\.IPGROUND, ro code
wbole>.1lc pna.. where the lcucr C rcprC'Cnh I, A rcpre>ents 2, .ind"°
on. Thus. the code, GRAND, would 1ndi.:a1c th.11 the store paod
S56l.90 for the item.
class A term m<'ll m ob1c'\.t·oncnt<.J modeling 10 indicate• coUeruon
o( >1m1lar ob1rc1s.
dau di;agram A d01a1led \ICW ol • <mglc u'iC C35", showing the da<se5
that partlCop.tte on me""" ~;c. and documennng the relanomhop
among me das'>C>.
dkkl to do•• The avtragc number of P~I\• Vte\n 10 le<Ompli.Ji.
purchase or obtam doored mformannn.
c:llckltream storage Rcxordm{: \\Ch v1-.1or hehavoor and traffic
trends for later dara mrnonjt. use.
dient Work~tatJOll thJt UiCf'S. interac.:t within a l licnt/M-n er de~1gn.
lOr-!te work.sto1t1on,, or conipurcr<r., J re 'upplir<l <l:u.1, procclis1ng services,
or other •uprort from other computer•, called server•.
client/server architecture Generally refer> tO systems that divide
processing berween one or more nctworJ..cJ docnt• and J central server.
In a rypical dient/ ,ervct\y<1e111, 1hc dm11 handles rho cnurr u<cr inter·
focc, including J ato emry, Jara tiucry. and ~recn prescn1a11on logic.
The server stores the data and provide> dJIJ "'"""and database managen1ent
funf.:UOn~. Applu.~.itlon loAu. 1fi d1' 1ded nl 'orne n13nner
between the server and the clicnr'-
dosed·ended questions Quwe<, rhao limu or re~tnct the range o(
r~pon~. U~ 10 the llllCr\>IC'W pt(.K:C~) \\<hen 'pt'\lfiC 1nformat1on or
f.ict \.'Cr1ficdUOn 1oe: dr:)1rcd.
cloud computlns An online ;oltwarc and data en' oronment on which
apploc.iJ1on• and senoces are otet<sed and used throujth an Internet
~onuc.:11on rJther th.on on .l l0<.ll w111pu1cr; rdc" 10 the douJ •)mbol
for rhe Internet.

456
Glossary
code A set of lcncr> or numbers 1ha1 reprrscnr.. .i d;ua ucm. C.odcs
can be used 10 s1mphf) output, mput, and data fonnats.
code reYiew A re"c" of a pro1~-r team memhcr'> work by other
members o( the et am 10 >pol lo~ erron. Gcncull). S) stcllb an.1ly>t>
review the '' ork of other \)"".item~ anJl)'\:t,. ttnd rrogr.1n1mC'l""'\ rc\:itw
the \\Ork of other programmers •• ,• form of prcr "'""· Strueturcd
"alk-throuith- >hould ul.c pb<e thruuithou1 the SDLC •ml 3re called
rcqu1rl"01C"nt'\ rc'·tC"\\ ~. dn1tui ~ .C"~· t,;.clJ<- rc,~tew\, cw rc'+nng f<'\'K'"'
depending on the pha~ m which they occur. Al'° known as a Structured
"all.-thruui:Ji. S<>e mvc1urcd wall.-1hrough.
coding The proc.c» of 1urn11111pro11r.tm10111• 0010 'l""1f1c 1m1ruccions
that a computer ~)'\:tern can cxrcurr.
cohesion A 1nta>ure of a module\ ;cope and prc>eess1ng •haractcri>rics.
A module 1hat perform> a 100111• funu ion or task has a high degree
of cohesion, which "desirable.
combination check A t)pc of dall •ahd.111on <heck that 1s performed
on two or more fields fQ ensure 1ha1 they are consis1enr or rea<0na ble
when co1md<rcd tOJt<ther. hcn 1huu~h all the l1tlds involved on a cocnhonarion
check m111ht P"" their mdi\'1dual vahdarion checks, rhc
comhinarion of the field value' m1gh1 be mcon•i\!Cnt or unreasonable.
combination key A type of dn tn vnl1darion check chJ1 i> performed
C>n two or n1ore fields to cn~ u rc chac they arc cor1, i.;;rtnr or r~~t1n.1blc
when com1dcrcd mgcrhcr. llve11 1hough .1ll 1he fi e ld ~ involved 11 n com·
bma1ion chctk nui:hr pa~;, their i11J iv1J ual vahd;itinn checks, the
c.:on'lh1nauon of the: field value' n11Kht be 11u.·011 ' 1 ~ 1 <"11 t or unrt:a ~on ah l t.
command button O n ~rten hutton th11t tn1tiJres nn ,tenon '>uch as
prmung a form or requesting I lclp.
common field An n1tnbu1e rhJI nppear. in more than one enciry. Com-
1non fields c~u1 be usc<l 10 hnk cnuut' 1n v.1nou' t )'pes of relauonsh1ps.
composite key ~mrumcs n 15 nt'..:t~\;try for a pnn1ary kc:y to con\isr
of a ~omhmation of foe Id~. In that~•~. the pr11n>I)' key 1~ "a iled~
combwot1on key. compo>1te l cy, cmi.:.11en~ttd l l!y, or mulm·alued kl!t.
eomp<rter "'sourc" committH A ttroup of le) 111ana~cn. and u~rs
rcspom1hk for c-.lu.11111Jt <y<trm< rcqu~rs. The trrm "sy<;1rms rc•~cw
comnuntt • is also used.
compute...aided •oftware en1lneerln1 (CASE) A t.xhnoque that u""
powerful rrogr.1ms •~lied (.A\! 1tlOI' to rrov1dr an meull framework
for srsrem• dn-,,lopITTC11t. The 1001• •uppon a wide vanny of design
methodolll!l1e., mdud111g >1ru.:111r<'<I anal)'" 1nd ob1<'-"t-<>rien1ed
anal>"''· Al«> rdcrrcd to a< rn111pu1tr-.,dcd <) <trm< cng1nttring.
compute~aided systems en1lneerin1 (CASE) Ser computrl"J1dcd
softw.tre engine<'tlng !CASE).
concatenated by Su composi1e key.
concurrent task A task 1ha1 can be comple1ed ar 1he S>me nme as
(tn parallel wuhl another 1.1<k.
condition A specified acro<>n or srnrr 1n a <rrucrure charr.
confidendality One of 1hc tlircc main tlemenis of sy,tcm security:
confidenualuy. int1'i;tit), .ind ava1lnh1hry (CIA). Confidtni ialuy protc-ct<
1nform.1tion fronl unauthortitd d14lc.: lo~rr nnd ~1fc-guard ., p1i vacy.
configuration management (CM) A 11rocr<s for con1rolhng ch.111gc<
in system rcqulr<mcni; •luring the development phaS('S of the SDLC.
CM al;o 1s .111 imp<i11 a111 tool for 111.111n11i11g ' Y" <lll <h.111grs n11d cosrs
J frcr a '>)'\ tclll h-ccornc< opcrt\donn I.
constraint A rcquircmcm or a cond11ion 1ha11hc sysicm musr satisfy
or an outcon1c thnr chc sy~te 1n 111us1 ach1c\ t.
connruction phase A ph;sc 1hn1 focu"'' on proi;rarn and applicntinn
de>clopment ta>ks \imdJr to the !.DI(...
context diagram 1\ iop·lcvrl >icw of an 1nformanon sys1en1 rhar
>hows the bound.tries anJ s.;opc.
conte_xt-sensltive A ftatu~ char a-1 ~nSlt l \l" to th<'. " urrrn1 conditions
"hen it" invoked. ~or ""'nrlr, conte,r-scnmne heir offers ass1st:lllCC
for a 1ask tn progreJ>.
continuous backup A rral-umc >lf<Jmtn)I b.ickup method that
records all system acnmy •s 11 occu".
'ontrol bnak A control bruk u~uall) c•u~ 'pcc1fk acnons 10 occ-ur,
such a. prm1tng >t1b101al> for a group of n.-..ord>
control b~ "'port A dcwl rcpori 1h.11 lnc.u""" nn control brcal\.
control couple In• .iructurc chan. a control couple mow' a mt'Ssagc.
also called a flag, wluch one moJuk M'llds ru another.
control field order In a cootrol break rt!X>fl, the r«ord~ are arranged
or sortt<I m the same order a> 1hc <-Ontrol held>.
control module In a \tn1cture <h~n. • con1rol module" a h1gher-le•·cl
module that din'Ct> lowcr le•d moJuk-;. called 'uhordmaie modulh.
con trol structu"' Scn·e as buildmi: bl0<.k• tor a pr0<.t'Ss. Control
srructurr:s hJvc one cn•ry t1nd c~ 11 pn1n1.1liC') "'·'Y be complt"tcd 1n
scquennal order, as the result of a tc" or cond111on. or repca1cd unhl J
spe-c1fic rondition change>. Aho called lottical >1rue1ure.
corporate culture A >et of bd1ef,, rules, ir.1d 11ion>, v•lun, and amtud
es mar define a company and mAuence 11< way of domg hu<tne«.
corporate portal A website 1hnt provide> ••ariOu'> tool• .111d foaiurt'S
for a n organ izatio n ·~ cus tu 1 ncr~, cntplO)'CC~. ~upplacr\, and the public.
'orrective maintenance Change> 10 ihe ')'<l<m to f" errors.
cou pling Mrasurcs rclatmn,hi1" •nd 1ntcrdepcndcnce nmong modules.
The opposite of cohesion.
credentials Fonn,tl quJlific.11ions 1har i11d udc degree,. diplomas, nr
ccrttfi<a1es granted by lrarn1ng 111>11 iu11011\ to \ hnw ilrnl a ,crrn111 level
of cducacion has been achieved.
path A series of event> and ac11v111cs wuh no ''••k 11me. If an)
crl~ical
activiry along the cnuc.tl p•th f.tll, behind «hedule, 1hc enurc project
sdtedulc is similarly delayed. As the name tntpht'S, a cntical p•th
indudes all acttvicies that are ,·tt•I to the pco1cc1 ~chedule.
Critical Path Method (CPM) Sho"' s J pro1«• "' • net\• ork dtJ)l,r.tm.
The aCU\lltlC"t are ~hown J.\ \let:tor''t J.ntl the c\·cnl\ art J1,pla~eJ l!t'dph·
ically as oodts. Although CPM dc•elopcd ><:par•1cly from 1hc Program
Evaluauon Re\le\\ Technt4u• (PJ.:Rn. the'"" mc1hod> art C-.\Cfluallv
identical. See also l'IC.RT/Cl'M.
critical ri•k When mks arc ca1cgomcd and pnonnud. crmcal n<ks
(rbose "irh the lu~s1 'ulncrab~ll) Jnd 1mpac1 rannJIS head the list.
critical success f.llcton Vii.I oht«U\ o thJI mu>1 bt Jch1e• ed for 1he
enterprise to folr.Jl us mission.
critical thinkine •kills ~ ah1hry to comp.ire, dJ«1fy, C\'Jluatc,
rec<>gnUe pancms. anal)U' CJU>C and dfc.1. Jnd •pply logic. Such
skills arc valued rn 1ht IT ind1l\I').
crow's foot notation A t)pc of cardm•lny 1101'11(>11. It "c.1lled crow's
foot not.1cion because or the shape>. wh1c.h mcludc circl~. bus. and
S)mbols, that ond1caic VJ nous ro>'1b1l111c:>. A "nglc hM md1C>tc> one, a
double ba r md1cau:s one and only one, a circle 1 nd1Car~ zero, and a
C-C()\\ 's foor: 1 nd1C:l U~S ffi:lO)'·
customer Prunar)' mer ot a ~yi.ten1, M:rvite, or prodtu.:t.
customer ,..,Jationship management (CRM) Many comp• 111rs
1mplcrncnr sysrems to 1111egr.11c ,111 cu<tomrr-rclarcd event'! and rransnc·
rio11s includjng marketing, sales. :.i nd customer ~erv i cc aetivit1cs.
cutover phase A ph.1;c 1hn1 rcsc111blc, the fn1.1l rn;k; lit the SDLC
inlplen1entation pha.;c, in4.:luding J at.t C<lnYCl"'tOll. cc~ t i n g, ch,1ng~1ver
co the new system. and user cr.1ining.
data The raw m,11crtal or ba>ic foct> u;cd b) 111format10 11 >}•lcms.
data center A large con<cnir.111011 ol networked com purer> work1n11
together.
data convenion Ex1s11ng datJ 1• loaded rnto the new ~)11cm, transformed
as needed. Depending on the •ys1cm. data conversion can be
done before. durang, or after thC' opcr.u1011.al c11¥1r<lnment 11t cornplttc.
dab couple In a •tructurc ch.in,,, dJ1,1 •Ouplc show, data that one
module passe5 to another.
(....,..... J:gi ( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,....._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~• ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Glossary
457
data dictionary A ccnrul srorchousr of inlorma11on abour a sysrcm·s
dara.
d"'ta el&ment A .. nglc durJ•lcmuc or fa.r •bom .m mmy. A data
clement. field. nr armhure 1< t~ <mall~t p1ett of dara rhar has m<an­
'"11 \\lthm an mformauon >ysrem. For •~ample, a Social Secuntv
numi,.,r or comp.m) nam< rnuld I'<' <umplts of a data clcm<nt. Also
calll'<I data ncm.
d .. ta n- A path lor WIJ 10 mO\C from on• pan of rhe mformarioo
'}>rem to anothrr.
data flow d~ (DFD) C.raph1cal representation of th• system.
.howmg n sro..-, prtx<"'>\C;, and rran,form> Jara u1to u.tful information.
data frames 1 ralfi< on a computrr network.
data Item ~u data clement.
data manipulation lancuap (DML) A D~R controls database operdl1ons,
1ndud111g •tonnit, ttlnc\ 1n11, upd.mng, and dclenng data. M<1<t
commercial DBMS;. >U<h 3$ Orad< and IBM's 082, use a D~U..
data m..n A •fl<.'<lahzed J31ab:1"' dc"i:,"'ed co serve rhe needs of a
'pcc1fic dqlartmen1, such"' \ale<1, markenng, nr financr. E.acb dara
ma n include> only 1he data rhnc users 111 char dcpamnenr require t0
1wrform thrir 101,.,
data mlnln1 Lookmg for mc;rnmgful pnuerns and rclar1onships
among darn. For example, dnto mining •or"' nre could help a con>umer
prnduct' f1rni 1Jrnu(y potc-ntinl ~u~ ron1 crs ha,cd on their prior purchnscs.
data proceuln1 center A ~entrJI location where physical darn was
dcli\ercJ ~r trJn~1111tttd 1n 'Onle nlJnner Jnd entered into the sys:ten1.
Users in rhc organ1za11on had no input or <>urpur c-Jpab1hty, except for
prnHed report' thJI were d°'rrihurcd i>y J corporarc IT department.
data replication In norm•I npcranni: condmons. any rmnsaccion t har
occ\lrs on the pt1mary >)M•m must aucomatic.1lly propagace co 1be ho1
Site.
d"'t" repository A <) mbol u-cd m DFIX to repr~nt a s1ruattoa in
~ h1ch .& ')''tcnl mu~t rcu1n Jara ~au--e one or more prOt.:.ehe!i. ntt<l
to USC rh•t .iorcd dar.t ·" a I.err nmc. u,ro 1ntrrch•ngcably wnh the
term data store.
data science lmerd1;.;1plmary f1dd rhat bknd> .-omputrr SCICllCC,
math and ~1amn<s, •nd bu<inr.~ methods to analyu large dataS<tS.
Im oh<> :aruf1<.1.il 1nttlhg~11<c. ma<hme le:arnmg and predt<tt\C aoaly1-
1C", and ,... ual11..inon tC\Ch111qucs
dau security Prntccnon of cl.at• from loss nr d.1magc and reco,·crs
dara \\ l><n It " 10>1 or damaged.
data nore Su dara rq>o;1t0<)
data structure \ meanmgful comb1nannn of rclared dara clements
th.II att mcludt:d 1n a dara flow or n:mned m • d:iu store. A framcwor~
for organ11mi; and \lnrmg dar.t.
data type check A t) pc of da1.1 \'alidat1on check mar is used to ensure
tlur a darn ll<m fu; the l't'quired tfata t) pe. For example, a numeric
field musr have only numbers or numeric .ymhol<, and an alphabetic
field can conto111 only 1hc chara.rcrs A rhruugh Z or rhe cbora<:i~rs a
rhrough 1.
data valldatlon rule A mcchnm'm 111 improve inpur qualiry by tcsring
th< dam and re1eu i11~ any enrry that foils to meet specified conditions.
data wa"'house An 111re11r•1cd collccnon of dara that can support
1ntinagcnlcnf {tnn l y~is ond d«t~1on 1n11king.
datab:ue administrator (OBA) Someone who manages• DBMS.
1 he OBA a-<c'"' ovcr.111 rcquire111e 111' and n1amtn1ns rhc daraha<c for
the bcndu of the cnurc organatanon rather than a single department
or user.
datab:ue manacement system (DBMS) /\ cnllccnon of rools, f<arures.
nnd imerfacC\ char enJhles u~rs to add, update, nunage. access,
and analylc data an a database.
database prosrammer .\ p<r.on \\ho focuscs on creanng and supporung
brge-..:alc databaM" >y>tem>.
decision c..ble /\ tJblc that >hO\\S a l<>11ocal >1rucrurc. \\llh all possible
combmanons of conditions •nd ttsulnng acnons.
decision tree A graphic•I rcpr~n1a11on of the conditions. actions.
and rul<-< found 111 a de.:i>mn ul>Je.
decomposins Another \\J) of con'c)mg a P'"'""' or s'"'m that has
been broken 00\\11 from a gC'llcul. IOp-levcl >it\\ m more detail. The
term' cxpln.ld and ('Jrt1tmn~J al'iO ••n i,., u\Cd
default nlue A v•lue !hat a sy,t<m d1spbi-, automancally.
defect tra.ckinc softw..,.. S1·,tem de1elopers usc defc.1 tucking software,
somcttmes cJllcd bug rud..1n11'1lft"\\Jr<,10 dorumcnt •nd track
program ddccts, code d1angC\, 3nd rcplaccmmt code, c.iUed patch<'>.
deliverable A poh>hcd, fmal produ•t, 'u11Jhlc for'" mrended """·
F..nd rroduc" or dehvcrahlr< often coincide w11h the complenon of
e3ch SDLC phase.
denial of service (DOS) An onlmc auack lh.lt <><•ur> when an
attacking con1putcr mJkc\ rcpcdfcd rcquc~f\ to ;i ~Cr'\'1C<' or scn,ccs
ru11n1ng on ctrtain ports.
dependent auk A ta>k " ,.;J to he Jepcndcnt when it ha< 10 be mm·
pleted ma i.cri.11,equerKe.
derivation code Combining dam from different item attributes, or
c:.harac[eri,t1c\, to hu1IJ tht: codi:.1v1tJ\f nlJl-!·''111e ,uh,cripuon code~
arc dcrivtition codes.
design prototyping Crca11ng a protocypc of u-er rcqmremcnt>, after
wluch the pruwtypc i' d1>eartlcd Jnd 11nplcrnenm1on continues. Also
called throwaw,1y prolot)p1ng.
design review Sc~ strucrured \\alk-through.
dcsi1n w:olk-throu1h A ;,c,;io11 with U'Ct\ (()review the ancerface with
a ere><< scctaon of people who wall work wuh the lie\\ l)\lem. Thi< i< a
cominu;itinn of the modehn11 and protot)pmg effort char began e•rly
to the S)">telll> dcvclopmcm pr0<.<».
desk checkins The prn<c" of rc>1c\\ mg the program co.le ro <pot
logic errors. which produce mcOrtt<.1' resuhi.
dewl report A drt.lil n:port produ•C> one or more hn<> of output for
c•ch record proccso,cd.
dj.,gram 0 A diagram deptetmg rhc first level of drta1I below the intnal
context J13i;um. D••IU'•m 0 {zero) toom• 111 on the .:ontnt
diagr•m and <ho"~ ma1or pm.;e\SCS, dJra llo\\ ~. and data stor~ as
well as repeauu~ the C>.tcrnal <nllll<> :md J.ara flo"> 1h:11 appe:u m rh<
contc't d1agra1n.
dialog box Allo"' a ui.cr to cnt<r mfnrma11on about a task rhat a
>y>tem will perform.
differential backup A hJ,kup 1hJ1 1ndutk<. only th< file, thar h;He
changed since the lasr full bJl kup.
direct cutover The direct •Uto\<t approach .:au>t"> the changeover
from the old >t>l<lll to rhc new 't>rcm 10 txcur 1mmedurely when rhe
new •ysrcm becomes orcrataonal.
disaster recovery plan A documented procedure cons1>nng of uo
overall h•ckup and l't'<C>Very pl.in.
discretionary projects Whcr< 111.111.111cmen1 has a chc>1cr an
unplemcnMg a projl"CI, they arc called d1'<Crrtlonary. For cxnmplc,
CJ't"ating a new tcpor1 rur :1 u~c r i ~ ·'" c:xrunpl(' of 3 t.h\Creuonary project.
diskless workstation A racrwork 1crm111al that support< a fu ll-fcarured
user interface bur lim its che pr1111inJ; or copying of darn, ex:cepc ro cerrnin
network rc>oun:c' rh.lt c. 11 be monuorcd and co111rollcd murc easily.
distributed datab:ue mana1ement system (DOBMS) A <ystem for
munaging dum stored nt more thnn one locanon. Using a ODBMS
offers se,era1 .tdv.1t1t~f.tc\: l)Jt.1 \HJrecJ llo-,cr to u"'er~ can reduce
network traffic: the syscem 1s sc~lahlc, '"new data sue• can be added
"11hou1 rcworkmg the •f'tcm design; •nd wuh J,11J >torcd in variou;
loc.1nons. the sprcm "lcs' hkcl) to c~p<n<ncc a carnnroph1c failure.
A potenual d1>.1dvanwgc ol d1smbuced d.lrn smrage 111\olv-. dlta
security. h can be more d1tf1cul1 111 m31111.11n comroJ, anJ standarJs
when datd " stored in ••nous l0<:at1ons.

458
Glossary
distributed denial of service (ODOS) A "rvicc arrack uwolving
muluple an•ckang computer'> that CJn 'ynchrornte DOS attacks on•
server.
distributed system Comp.in) w1Jc 'Y'tem> that art conneued by one
or moro LA:-0:> or WA\:\ I he <•r.1h1ht1c> of• Jo>trihuted S)>tetn
depend on the power dnd c;'lp•c1ry of the underlying d3r.t commumca·
non ncnvork.
Diverging cbta Row A data llu" m whkh the >Jmc data cr.uels to
f\vo or more different locauons.
document review A ,., 1c" of ha«hnc documemanon. A u<cful factfinding
1e<hnique that help' an unal)>t understand how the cum:m
\)')ten\ i~ ~upro!tcd to ,,·orl.
documentation t>latcrldl 1lm <'pl>1n• • 'Y't<n>, hrlp> people mtera<t
\\'ith it, ~uid nKludes pmgr;un dc'k:unlCntJ.uon, >) srenl documenrarion.
opcrJ.taons dOlu1nentJuo1t. and u&ocr documcnrat1on.
domain The'"' of value> pcn111ncJ for a data element.
dumpster dMna R.l1d111K de>k• or tn••h b111> lo1 •ahuble 1nlormarion.
duration The ;unount o( t111\e JI \v1ll La"e tc• co1npJcte a r:isk.
EBCDIC 5tJnds for l'xtendeJ llinary Coded l)eC"im•l lntcrchangc
Code, a coding method u:.cd on mamfrnmc " nnputcrs ~nd some highcdpa<:1ty
~ervt'n ..
e.commerc:e (electronic commerce) 1'"r1•11,ac110114\ (t".H., lluy111g and
selling of goods and 111format1on) that o.:cur cm the lnterner. Includes
both bu~ in l"S!'t·to-cons un1cr and buo.i n cs"~to· bus1nc~'·
economic feaslblllty Achieved ii the prujrcrcd bellefils of the propo;,al
~)\\ tern nul\YC1gh the ~'11 111 a 1 cd 4.:0'it' involvell 111 :u.;t1u1ring,
tnstalling, and opcrJting it.
economy of sa.le The inherent efficiency of h1gh ·\"Olume processing
on l.r11er computer> D.11Jb.1>< J<'ogn Jilow' better utilu.111011 of hard­
\\ are. If a 'omrJny mJ111tam\ an emerpn'lt·w1de d .11aba~. proc~sing
,,, le!.~ e.x~1\·c l»tng .i pc>\\Crful ma1nfrJn1c )Cr\t.'r u&ccad of u.s1ng
.c•cral >mailer wmputcr..
electronic dat.o int~hanae (EDI) 1 hr elCchange of bu<rne\S docu·
mcn1> "'""Cett computers """It a standard elrctro111c format.
electronic health ~cord (EHR) An electronic record of a p.1nenr·s
htahb mformauon gcneurcJ a> the paucm enrnunten. \3nom health·
care pro,1der' anJ •h•red Jrnong mul11rk fa<1l111cs and ~genc1 es.
electronic product code (EPC) lechnolngl th.n u<e< RI ID rag< to
•denttfy and mon11or the mo• cmcm of e3<h 111d1ndual produce. from
the factUI) floor to thr n-t.111 <hedou1 <ountcr.
electronic proof of delivery (EPOD) A <urphrr """'RMI)••!;' on
each crate, CJse. or sh1pponi: umr m cre•rc a digical shipping Im to ver·
ti} rl'CC•pt of i:oo<h.
empowe.rme.nt A bu~1~~~ pr.te.;1u.:.C'.' that place~ rnure respon.s.1bihry
and accounr,1h1hty throui:hout all lcvols of an organi1anon.
encapsulation Tlie idea that all data nnJ me thod~ arc ~e lf-co ntain ed,
as in a blatk box.
encryption A proCC$Ci whert darn 1c; ..:o<lcc.1 (4.:onverred inco unreadable
char.1cters) so that only those" uh the required a u1horiw11on cu 1
occess the darn. (usuJlly via dccod1n1t ~ofr:wa rc)
engaaed Ustenlna T he nb1liry to really conccnrutc on what • <lmcone
i"I soty1 11g ,tn<l .tvou.J 1hc tc1np1.111on 10 hc.1r \Vh;u i, expccrcJ . Al~o
1ncludc5 not1c1ng nonvcrha1 co1nniun1cntion.
enhancement A nc\\ feature or cap.1hihty.
enterprise applications Comp.111y·wide urplicarions, such OS order
ptocC'~1ng \}'!!.1Cm~. l'>~l)'roll ,)-,tctn"i, Jn~J con,p.&n ) l:Um11,un1,at1f.>n~
networks.
enterprise computlna lnforma11on ;y\lcm< thnt .upport company­
'' 1dc data o:wna~cmcnt rC\jutrt"rnenl.). si1i1.h 3":. .. \1tl1nc re~rv:i 1ions or
crcxht card boll mg 'Y"ems.
enterprise resoun:e planninc (ERP) I\ ptO<'cS> that e<>tahhshcs an
emerpnse-w1de >tr~tei:i for rr rcsoum''· ERP defines a <pecific nrchi·
tecturc. ondudmi: >1and.ud; for Jara. pto<c.>1n11. network, and U><"r
mrcrf.icc design.
entity A person. a place. a thing, or a.n e\cn1 for which Jara is collected
anJ ma1nt3tned. I-or eun1plt, ;i.n onl1ne Yh:~ "t).,itm nt.ly
include cn1111cs named C\JSTOMFR. ORl)I R, PRODUCT, and
SUPPLIER.
entity-reladonshlp dlaaram (ERO) A ~r•phi<al moJd of the inlormanon
system th.it dcp~ the rcl~uon(hJP' .amon~ \>strm cnt1ncs.
epic In an agile pro1cct. a "mplc, high· lc\CI qJremcnr of a rcqu>re·
mcru. Su feature.
evaluation and selection team A i;roup of r .. oplc lll\OheJ "'sde.1·
iot> hardware and software. The group mdud«> 'l"cm\ analy<rs and
u>ers. A team approach cn>urt> that <r>uul fauor> 3re not o• crlookcd
and th:tr a sound cho1ct • ~ n1ade.
evaluation model A technique that U'M a common yard<nck 10 measure
and com~>are vendor ratings.
event A rtferencc point thnt m;a.rks 0 1n3jor (X:Curr.:nce. u~d tu moni·
ior progress and mnnage a proJe<t. ~re al>o milestone.
exception report A document d><playmg <)nly those 1·ecord> that
n1e.et a spe\:i fic condition or c<>n t.lilions. Ex1.cpuon rcpc.)rt'! .irt u>eful
v1hcn the user \Y;tnts 111forn1ac1011 only on reeord' that nu~ht r~uire
acnon bur docs not need to know the derails.
ex>.stence eheclc A I) pe of dar,1 valid.u1on <heck rhar is used for mandatori
dara items. For example, if an employee rernrd r•<iuorcs a Sona I
Securit)' numh<:r, an c><;l<tcncc check wnuld nor nllow rhe user m save
the cccord until he or she enters a suotablr value in rhe SSN fidd.
exploding A Joagram 1> >.ml 111 b" exploded of >t •Jroll, down" m n
more detailed or c'pandcd v1c\\
exploit An arrack that r.1kcs •dvant.1gc of ,1 <y11rm •·ulnerab1hl)',
ohen due t0 J combination of one or more improperly ton figured
~rviccs.
Extended Service Set (ESS) A w1rclcs; network conf1gura11on made
up of cwo or more BS5 net\\ork>. \\ hich allow> w1reln' d1c1m 10 roam
from BSS to BSS.
ertensibility Refers to a>) stem\ ab1hl) 10 c'r.1nd, change, or down·
sue ~soly 10 mett the chani:rng need> of~ hu>tn~ cmcrpme. Al><>
known as '>Cal.ib1l1l).
fa~ct·linding
elicitation.
The proce•s of g;ithcrmg rtquircmcntJ. \tt rcqurrcmcnts
fat dient A nccwork de;,1~ thut locues all or mo>• of the apphcauon
processing 10J\IC at the client. Al>o ullcJ a th1tk docnt Je>i~n.
fault man .. gement 1nc timely dcrcctmn and rcsolunnn of operanonal
problems. Fault management includ"5 mon11orrn11 • si·stem for "II"' of
troublc, lCJAA>OI\ JU S)Stcm faolurh, Jo.lgno\lng th• pmhlrm, .md aprlying
corrective action.
fault tolerant A sys1em or applkanon i< ,.,d ltl be foult tolerant 1f the
failure of one component doe\ not dosahlc tl1e ,.,, or rhc sy>rem ur
•pp11ca11011.
faxback See automated fax.
feasibility study An imtiol invest111anon 10 clt>rly identify the nature
and SCC)pe of tht· husillt» 01lportunil)' or prohkm. Aho called prel iminary
invesriga rion.
feature ln an agllc pru1oc1, a >implr. hii;h· levcl >rJtCmcm of a rc<1uire·
n1e nt. .Set epic.
field A s111gle chao·aCLcri"ic or fa<t ahou1 Ml cn11ry. A field, or attn·
hutc. i> the smallest piece of darn thnt hos meaning wuhin an
iofonnauon sysrem. Fur example. ,1 Suct,11 ~e<unty number or company
name could h<: example' of n field. l'hc term~ Od/11 drmml. dat.i
item, and ftdd arc used interchani:eably.
file E3ch file or cable •OlllJtm dJt,1 Jbuut pwple. pbu~s, th1n11s. or
c\o·cnts that interact \\'1th the 1nform01non '>·~• cm.
fife.oriented system A folc·Otl(ntcJ '>'tern. al>11 ••lied a folc proce,sing
•}Stent, store. and nwugh Jara in one or more ><:parate hi ....
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

Glossary
459
fill··in form A 1cmpla1c u...J 10 coll= Jau 011 the ln1emc1 or a cornp3n)'
rnoranrt.
finish day/date The dai• or d•1t when J ta<k "scheduled robe fin·
bhed.
firewall Theo nmn line ol ddcfbC ~ccn • Joal net" ork. or oncnnct.
3ncJ th• l111crnr1.
first nonnal fonn (I NF) A ttcord ''Yid to l>c m I !\F of n doc< noc
conr.un • rtpt'.•nng group (• .ct of data items th.it can ex-cur any nwnb.:r
ol nm"' m • >tn~lco rr.;orJI.
fishbone diaaram An .1nal)m 1<>ol 1h.11r•P"""""1hc pos;1hle c•usn
of. prohlem .1<. vaph1c•I ou1hnc. Alm Cdlled an l•h1kaw• diagram.
fU<ed fee model A <en1'< model tha1 charges a set ftt b'1scd on a
specified lt\el ol s<rv1ce one.I user suppon.
nowchart \ diagram u«d to dc<cnhc program logic rhor represencs
IOjti<.al rule> one.I mt<rJct1011 gr.1plm.Jlly u;ing a series of symbols connecoed
by .1rro"''· l lowd1.r1< c•n he u.efol 111 vi~ u •hLmg modular
progrnm designs.
focus In • 'equencc diagram. a focu; rnd1c.acs wh..-n an ob1cct sends
or receive> .1 mes>n11e. lo 1s 111d1cn1cd bi a narrow venical recrangle cl101
covers 1hc lifel1nc.
foreign key A field 111 one table th.11 must match a primary key val ue
m anoohcr 1:1blc 111 order to csrnbli>h the relntiomh1p between the two
tJblrs.
form filllna A Hf) cffe.;t"e m<1hod of nnhnc da1> cn1ry where a
Mank form rhar dupl1ca1r, or rc-.mble< rhe •ource dncumcnr is completed
on the ~rccn. The u>cr enters the data and then moves ro the
llC\I hdJ.
fonn layout Inc phy'lc.11 appearance and placemenr of dat.1 on a
form. Form layout make• the form easy to complett and promlcs
enoujlh >pJ~. both 1cru{~lly and boruont:tll)'. for us.en to enter che
c.1 ....
fonrm An onlmc J1«.u\\1011 on• ramcubr rnpic, whett ~pie men,
offer suppon. •nd t'l<changc idea•.
fouMnodel .,,proach A phy;i.-al model of the curren1 S) strni. a l<>gial
model of the •urrrnr S) Siem. a IOjllcJI model of me De\\ srsrem, and
a ph) sial model of 1he Ile\\ "'"m •re all de1clopcd.
full backup \ 'omrlc1e badrnp of nery hie on the sy"cm.
functional baseline ~ ronf1gurauon of die S)Sltm documented 31
rhc bq;inmng of the pro1<..:t. lo cons1s1> of all rhe neccs..ar)· sysrem
rrqu1rcme-nr" and ~1gn ..:on\tr.;ur1~.
functional decomposition dlaaram (FOO) A top-down rcprc.c:ntattOn
or hu'1nc>• functtOn' and prol<.-C»CS. Al;o called a structure chart.
functional primitive A •mglc function rhat l< nor exploded funher.
The logic for fu11<.11on•I prim1uves " documented m a da1a diaionary
prn«ss dc"'rtpnon.
functional requir.,ment A \ tattmcn1 of the sen1«>s a system pro·
v1dcs.
functionally dependent Func"trona l dependence 1s an imponant conap1
fur umlcr>1andmf; oltc 2NI'. Thc f1dJ X 1s said to bt fun<.-tionally
dependent on 1he field Y 1f the Y.lluc of X depend~ on the value of Y.
For example, an order dare i~ dependent on nn ordrr number; for a
por11cular order numbcr. 1hcre i> only one value for the order dare. In
conu·as1, tht• produc.:1 de,r1p1tnn 111. nn1 dcpenden1 on Lhe order nuni·
bcr. For n pamcular order numh<r, there might he several prndua
de.criptte>n'· one for each 1tcm ordered.
Gane •nd Sllrson A populJr •imbol ;t1 u>ed rn DFDs. Processes, da1a
now,, cJa13 >IOfC\, ,llld e>tr1nal C11UllC> Jll hdVC ,t unique symhnl.
Gantt chart A homo111.1l l>ar <hart th.111llusrrar<'> a <ehedulc. Dcnlopcd
many ) tar> Jgo hy I lenri L Gantt as a prnducnon control
techmque. Sull arc 111 common use IWa).
garbap in, garbaa• out (GIGO) lbc wn<.cp1 tha1 the qualuy of the
ourpu1 "only,., i;nod a< the quahry of 1he mpur.
pteWlly (I) In bu;mcs. procernng modcl1n11 nooauon, a fork m the
process. allowmg the now to go one WJ} or another. (2) A rourcr or
ocher network dtvi« u!.cd 10 conn"'' tO a lar11cr. d1ssurular type of
OCC\\o'ork, such a~ rht Jntcmct.
gipbits per second (Gbps) A t>andMdoh or 1hrn11ghput mcasurcmm1.
globlll outsourcin& The prJClk:C ol \htfttng IT dntlopment. support.
and OJIC'rauon> 10 ocher countn~.
glueware Su m1ddlcware.
gnphical user interface (GUI) The use of 1tuph1ol ob1«LS and
l("<.:hn1quc!.- allu"'"K Uo,c'r\ 10 ~cHl1n1un1tt.JtC' wuh J ~)'tcrt1. \ v..clldesq;ned
GUI can help u<e" lram • new system r.1r1dly and work with
me sysrtm ·ff~tild).
gray hole A proceu Mth Jn mru1 ob'1ou'I) 11bulf1ctent to gencraoe
1hc <hown ourpur.
iroupware Program; th.11 run on ll network thJI enable""'" to .hare
darn. collaborate on pro1«.1', and work 11 t<.1111>. Al>o <.tllec.l worl·
group <ofowJrc.
hardenlni: Making a ;y,tcm more \Ccurc by removing unn<'Ccss:try
accounts, s.erv1ce:i.. and fe~l1u rc".
hardware The ph) <1c.1l bycr of 1hr 1nfom1Jnon >y"cm, to mdudt
computers, network<. co111mu11tca1ioM equipment. nnd other rcchnol·
ogy-baseJ infrasrruuur<.
hash totals Nm 111can111gful number> 1bem>clvc; bu1 are u>cful for
companson purpo<c<. Also known a< hatch conrrol totals.
Hawthorne Effect A phenomenon whl•rc cmplO)l'<'> who know they
are being ub)lerve<l .irt 1nort produ,ta\.c,
help desk A ce111rall7ed ttmu,.-e ,.,ffed hi Ir profe~1ona l s that rro·
vides user>" 1th 1he suppon the) need to do their 1ob>. A help desk has
thrtt ina1n oh1f\.11\e-.: to 'how ~orl~ how Ct) u~r ')'tc1n rt."M>Ur~e~
mott dfrai,ely, tn pro'1dr >n\\\er< 10 te<hn1c.1I or opera1tonal qucsuo~
and w make U>er> more produ,u'c b) tea,hmi: lhrm ho" 10
mttr 1hc1t own 1nfnrmat1on need-. Al..o ulled .cn ice de,J,, nr infomu·
uon center~
hierlll'Chklll networlc A ncrn ork de.1gn "'here one computer t) pt·
calli a mainframe) <onrrol' the enurr n<IM>rl. \atclluc <ompu1ers or
servers control lo" er Ind< of pro..e;smg and nriwork de'1ces.
histogram A common mot for sho" mg thr d1stnbo11on of question·
D3trc Of >Jmphnjl rc:,uJI,. h tJJ..c, tht form o( ~ \CMlcaJ b.tr<han.
horizontal application A snff\v•re p.id,.;1gc that c•n he used by m.an)'
differenr orpes of orgami.aoon,.
horizontal system A b3'ic >);l<m. •U<h "'on lO\CntOf) or PJ>roU
p3cii.ag.e, 1hat ., -.:<>mn1r•nl¥ u'\.ed h> a ,.1ru:1y <>f l.C>nlpan1c-..
hot site A separate rr locauon, whl<:h might l>c tll another SIJIC or
t:\cn 3nother i..:ounrf), that \:JO .'J,Upport t.:riu~.1 1 bu>nlc>.; ~)~term in th~
C\COt o( ~ pnwer outage, ~y,tcm cra,h, or ph)'\K.al t.lta\ttt>phe.
HTTP/2 The second ma1or vcrnon ol 1hc network protocol used b)
the web. Rel.,,t<t'<l •> n >1andard 111 20 IS.
hub The ce111cr uf a >tar 11<1wurk. ~w11~h•> in 111odtrn network> ha'e
largely replaced huh>.
human-computer interaction (HCI) A dc<cription of the relarionsh1p
berw«n computer. and the people who u>• them to perform
bu,111ess·rclatcd ta<k<. 1 ICI concept< apply I<) c,·crythmg from a PC
desktop 10 1hc ma in menu for a globJl ncm·ork.
identity manai:ement Conrrol; •nc.l prox:cJurc> nece.snry 10 idenciJ)
leguinlatc u\Cri. and ~y~tr1n 1o;;<n11ponenc,,
identity theft The <teahng of pcr<nn•ll) tdenufymg 111for111acion
c>nhne.
IEEE 802. 111 A >«um) ''anJ.ucJ for Wi· F1 w1rrl<>> ne1works that
uses 1he WPA2 protocol, rnrrcntl> 1hc m<»t <ccurc cncriptton method
for Wi-F1 n<rworh.
incremental backup ~ .. mg a cop) ol only thc filo th.1 ha'e changed
sm« the la51 full backup.
c.,,......_ .. <.....,1..,.. "'~~-- ~-•"'fl"ll ~ • ..,._. • ......, •• ,... 0-.. -.-............. ....,,, ....... _,..,....,......._.,..,,.....,.~u,
lM«lllln'_ ............................................ .._.. • .,.._ .. c.s. ....... ~-..... --.......... ,- .. .,,, ................. """"._ ..... ...

460
Glossary
inference n.oles lnsrru•'tmns rha1 direct a knowledge manJgl'menr
»••=to 1Jcnufy dJ1.1 pancm> JnJ rcla11on;h1p>.
Informal nructure An ori;;anotJllQn b•sc:J on 1111trper>0nal relarioosh1ps.
which can dcvrlop from rrcnnu• work a«ognment<. physical
proxonut). unofficoal procedures, or pcNlf!al rela1ionships.
information D.ca thJI lu; bttn <hanged 11110 • u.eful ionn of ootpui.
information 1yst0tm A rnmb111Juon ol 111fonnJ11on 1echnologi. proplc,
and dar• 10 surpon business rtquircmmi.. The five key
componenr> are harJ" .ire. wft"arc, J313, pr<><,.,,;e,, Jnd (><.~pie.
information technol<>sr (IT) A rnmhln• iion of hJrdwarc. "°ft ware.
and crlecommw11ca11ons >V'ICm> 1ha1 <uppon bu me<• opcrJl><>ru,
improve producu\lly, Jnd help m3n;agcr. nuke deci;ion~.
infrastructure mode A w11ele\~ ntcw<>rL. C.:<lnfiJturatton in '''hu.:h a
ccniral w1relcs< dr\ oce c•llcd an acce<s point os used to serve all wire·
less client>; also called BSS.
inhentance A l)pc: of ob1c.1 rda1ion>h1p. l11hcrorance enable. an
oh1cc1 to dmvc one or mote nf ot• aror1bU1l" from another obj<et (e.g .•
an INSTRUCl'O R oh1cct may inhcri1 man) rraors from rhe
E.\IPLOYrE ob1cc1, su<h .1> hore date).
in .. house software An 1n(orn1auon c.:cnn.·r or help dr..;k "'irh1n rhc rr
department responsible for providing u<er •upporr and offering ser·
v1ct:.) ~uch ai, horhnc o~'l'tJll\:C', tr.uninM, Jnll gu1dnnt;( ro u..c'rs \vho
need tccl1111c,1 I hr lp.
Input control The nccc»ary mca;ure> 10 cn>urc thnt inpur darn is
corte...:t. co111plcte, and ~t·•.:u 1 c. A ,y,rer1'' 01'u1ly\t n1u\t focu\ on input
control during ev<r) phase of mpur cl c~ 1 g11, ~1Jrnng with <011rcc documents
char promore da1a .icc ur~cy nnd qualtry.
input ma.sk Ternplart or pJ.tti.·rn 1h ~lr ninl.ei; it ea-.1er for use~ co enter
da1a. Ofren used 111 Ju1om.11cd form' 10 guide .tn unfJmihar us.er.
instance A specific member of a ci.,,,
Institute of Electrical and Electronics Enalneers (IEEE) A profes­
>10tUI otg3Jlll~tton char <St> bit.hrs .iandards for tde<ommunkauons.
intanzible benefits Po.itJ>·c ourcom<" 1har arc d1ffoc11h ro mca•urc m
dollars. Howc,·er. mra1wble bc:ndirs can be •ery important in the calcul.ltton
of c.onom1< f.a,,b1l11y. An nample of an m1an111blc bc:ncfir
might be .i new web•n< thar 1mprovrs 3 comp.lny's image.
lntanclble cosu Imm thar arc d1ffKul1 to mea>urc m dollar rcnm.
>uch >i miplo) ec dM:amfawon.
integrated denlopment environment (IOE) A sune of mtcgrated
tools to nu.kt n c.u1cr ro plan. conmuu, Jnd mamum a >pcci£1c soft.
"are produ<t. An IDl " de.1gnt.J w allow 1 he e•>l' uuq;rauon of
S)"tem componcnr• wnh '"'' tJm< btmg 'pent on dcHlop1ng code for
inrcracu'c modull.,,.
intecrated development envlronmenu (IOE) An opplicanon for
bu1ld111g other whwarc applttauom. l >r•cally 111cludcs • '1sual code
ed1tor:. an tntegraced comp1lcr. ~ dcbuAAcr, a configurar1on ma11agement
'Y~te1n, and a h~\I (rJmC'\YtJtk.
integration testlne 1he1c>iin11 of'" o or mort progra m< tha1 dcpcnd
on each 01her.
integrity One of 1he three main demenr> of S) stem >ecurirr: confidentiality.
mtcg.-it)', and ava1l.i bil1 ry ((;IA). lnrcp,rary prevent< unau1horized
users from crcatin&, modifying, or deleting informarion.
lntematlonal Oraanlutlon for Standardization (ISO) A network
of nnt1011al ~ 1 a 11<l :1 r<l') in\;t1t11te\ (ro n1 over a huniJred C(llHllrlt!) \Yt>rking
1n pnrtncrsh1p \V1rh 1ntcrna11on;1I urgnn 1 z01t 1 o n t.~ govern1nents, indus·
tries. and bu..,11101s ._1 n1.I t..:Ol11'Un1er rrpr~:.cnrnri' f"), Tite ISO ncr!t as a
bridge between public Jnd privarc ~ccrors.
lntemet business services (I BSs) ~r\IC~> rhat provide powerful
\\cb-"'1.ed ;uppon for tunsac11ons •uch n< order prl)(Li»ing, biUing,
and 1,;.u\to1ncr rcl.u10111th1p 1n:in.1gen1..:111.
The lntemet-of·Thlnas (IOT) Oc\ICt<> connected to one annrher o•er
a computer U<.'l\\'Otk.
lntemet oper.atina system PJrt of rhe \Veb 2.0 modd, an onlrnc
computing c-nv1ronmcnt crratcJ h)• onhnc commun1ncs and ~n·icc~:\1
b:i4ie.d on la ye.rs t>f )hared inform;auon th~t ~Jn conr31n rexr~ \{)UnJ
byres. tmagcs, and ''dco dips.
inurview A planned mecroni: during" hKh rnforma11on is ol>t3mtd
from anochu person.
ISO 9000.3:2014 A >et of gwdd1no t-.rablr>hcd •nd updat<.J by the ISO
to proude a QA fr;uncwork for dc'dnpmg and m.11111a1n111g soft" are.
iteration cycle An agile de-·elopmcnr qdc chat mdud~ planning.
des.going. codang, and tbong ooc or more fcarurc. "3,,..J on user >lone!..
Iteration plannlna meetln& In agile de• elopmcnr, a mtttmg hrld at
the beginning of ealh tterauon C)ll~ co ~r<"Ak Jo\\ n U\.Ct stories into
<p<'Ctfic ta'k' that arc ""gncd 10 tC•m mcml>cr<
Iteration The complc11on of a process \lep 1ha1 " repeated un11I •
specific condition changes.
iterative An ad.Jpuve uml1od typk.tlly u-c• a ;p1r.1I Jc,dopmem
model, which build• on a '<rics of 11cra11011<.
java database connectivity OOBC) A <iandnrd 1ha1 enohlc< j'1va
apphcauons to exchange dar.1 wnh any databas• that uses .'>QI. sraremeni;
and" ODBC-complmnt.
joint application development OAO) A 'Y>l<m' dcvrln1>111cnt 1.chniq
uc tlm use~ J ra<k fo"e of"'•"· 111a11.1ger<, and Ir profewnn•I~
who work rogethcr to gather information, disc11;s bu.inc;; need>. and
define the new S)'>lcm requ1rcmc1us.
just·in·time OIT) The exch:m11c or delivery of mformancm when 011d
where 1c 1< needed. for exampl<.1u<r·m·timc mvenrory system• rely on
computtr-to<ompute.r d.tt:i cx~hJngc 10 1n1nlm1lC unncc<."»nry 1nvC'ntor).
Kbps (kilobits p<1r second) A b.intlwodrh or throus;hpu1 n1easureme111.
key fields U..,d cfurin)I th< syMCm< design ph3SC 10 or11on1ZC, ,JC<CS>,
and maintain data structures. r hc four rypcs of key fields arc primary
ke>'<· candidate keys, forccgn keis. and s."<:ondJry key>.
keystroke lou"r ,\ d.-1cc rhJt can be inserted bct\<ecn a ke>l>oord
aod a computer ro rttorJ keysrrokc;.
knee ofthe curve A pcrfunnan~.., chauuemlr< of a d1cnr/<eo er
compuung cnvtroruncnr. Chenr/.c.-·cr re>pnnl<' llm<" rend to m.:rcasc
gradualli and then nsc dranuttally a> the >)>tern near> 1rs capaCtt).
The pomt "here re>ponsc um<" lll<:tU>< drama11ullv.
knowledge ~ A rorular \) '1'111' dc.elopmrnt lnhnrque that U'>CS
a group of users, man•Jler<, and ff profe<\lonal~ who work rog•chcr to
gathtr information. di><uss business need>, and define 1he nc" .,·seem
rcqu1ttmmts.
leading questions Qll<'ncs 1ha1 'UAA<"'I or fa\C1r • panrculJr reply.
tepcy d;ota The 11.ita a<..oc1atcd "1th An oldcr, le<s rcchnnlogocally
ad' a need leg;rc)' S) stem.
lepcy system An older system tha1 " typ1alli less te~hnologically
a d va n ~ed 1h3n ~"Urrtn t ly ava 1:.thle \Y\.te1n• ...
leveling The proc'""' of drawing o 'croe' of m<rcJ<ingly dccn1lc<I diagram_<
ro reach the desired level of dcrntl.
libr ary module In a structure cho n. a hbrnry module t< J module rhat
is r e u~ab le and Cln bt- invoked front nlorc lh:.tn one pc.uni in thi: ,hart.
life.line In a sequence diagram, a lifdtnc 1s u;txl tu « 1>rc'<nl rhc 111nr
during which 1hc objccr •bn\'C it 1s •hie 10 internee wnh rhe other
obj ccrs in rhc u•e <n>c. An X n1.trks rhc end ol a lifchn~.
limit check Occurs. \Yhta n \•alidntion \'.hl-ck invol\'f.") :a m1nin1u1n or .l
n1a ximun1 value, but not hoth. Checking ch.u ~1 pay1ncnt n nl<)Ulll i\'.
gre ater than 7cro. hut nor <10p«ify1ng .i m:.tx1n1um value. is an cxnn1plc
of a limit cbcck.
list box An ourpuc me<hamsm that displays a list of <ho1ce. rhat the
user can ~ele~ t.
local area network (LAN) A ncrwor~ ""'II" rhar allow< 1hc •hanng
of data and hardware, ~uch as prrnrcr> and 1<.anncr.. Ad•3nccs m data
communicauon ttdtnology bJ\C made ir r<»"blc 10 ..-rc•I< pow<rlul
nerworks rhar we 5.l!dhrc lmk•, h1gh·spccd f1bcr-Oplt< Im<", or the
Internee to share dar.t.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
r..a...w...,..._...., ....,...,...... .,..~.................,.t11ru..__.~~ c.....,..~ .........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

Glossary
461
log Record l)pi<•ll) k .. pr hy opcr.umg >y>t<ms and applianons th..,r
docum<nrs .ill t\·tnr<, including dares, nmes, and other Sp<C16c mformnuon.
L~~ '-Jn be 1mponJtU 1n unJt:r,r:and1np, p;)j,t ~rracb and
ptt\·ent1ng furu~ 1ntru\100'-.
lock enw M&.1.kc- m tht unJ..'rl) mg k>glC tholr prodUtt mcomlCt results.
loaial desJan Tht defm111on of an mlomunon '>"em'> hmcnons and
fc..atu~,, and the rcl.Juun~h11"~ tlmnnA 1t~ componrnr~.
loaic&I model ~how• what • ·~°'rem muq do, reg;irdle<s of how ir ";II
be rmplemenr<J ph) >1.:alh
logica.I rteord A l<>g1<JI rn:ord ronmns f1dd ulut"S that dt"scnbt a
smgle pt'l'Wn. plaet. 1h1ng. or C\Cnr • ..\pphcation programs see a logic<'!
re.cord 3\ •I.Cl of f1dd;, rqi;irdl.,..,; of how or \\here tht data" >tored
phy,icall).
locic"I norqe Refer; ro mformanon •• seen through a user's eyes.
rts-trdl<» of how or whtrt 1ha1 mforma11on 1> organu.<d or •tored.
loaica.I structure Ser romrol siruciure.
logic.al topolou A \'l<W of a nrrwork rhar d=nbes the way the componen~
1ntero1C1, rather 1h;.an che .1crual nef\\'Otlc ohhnA :ind connections.
loop In a 'tru,tu« lh.1r1, a loor 1nd1c•re' 1hat one or more niodules
arc repeated.
loopin& Refer> to a t>rou:s' >lCp thnt ;, repcaicd umil • >pedllc rnndition
change<. l·or cx:1mplr, a procoss rhat connnucs m prim paychecks until it
reaches the end of the p;t) roll file is looping. Also known as repetition.
loosely coupled J\lodul-. 1hJ1 arc rel.111vdy mdepcn<lent. Loosdy
coupled module< .ire ea~orr m m,unl3m and modify, hecausc che logic
m one module Joe> not affe.i other module>.
M:N A type of enrny rda11on>hip. A many·to· ma.ny reLrnonship,
aht>rcv1atrd M:N, c\l~ t~ when one m•r•ncc of the firsr enmy can
be related 10 many 111stan<r> of th< >ttond cnm). and one UlStance
of the se<ond enlll) can he related to many onstnnces of the firsr
eornv.
ma.chine 1...,.,,in1 An a.ppli,•11on of rnmpur<r "'~and anilicial
mtrll1grnce th.ir u .... JUIOm.ltcd apf>roncht\ ro panem recognmon and
pred1<.m·e anal) ti<:> b.ikd on lari:c doraseb.
malnfnme architecture A \Y>l<m de\lllfl "hcrc the '<T\ er performs
a.U rhc prt><<'"ng.
ma.inte,,.,,,ce activltle• Chang1ng pn~uim. procedures, or Jocu.
mcn1atKm ttl cn\urc corra.:t \)\tern ptrfonnafkc. Adapung the syscem
to changing requ1,..,menc,, and making the S)"Sron operate more effi·
ticorly. Th~ nttO> ar< m<1 h1 rnrrn:tl\c, adapt1>e, perfccmc, and
prc,·enu\e ma1ntcnarx:t.
ma.inten:ance a&reement A >J><-cificinon of the conduions, charges.,
and tame tr.1nlt' for U\tr' to 4.:0nl:tt.t 1he \'itndur for 3'\~tst.anct ''hen
they h.,·e S) strm problems or qucsnons.
malnten:ance upens.s Cos!\ th.it vary <ignificandy during the system's
opc:ranon31 life ond orn:ludc •pending m '"Pl"'" mamt<nance acrivu:ies.
ma.lntenance l"<llease A formal rclea~ of a nm> <y.rem \'crs1on that
lont.i1n~ a nun1bc1 o( c,;h3nge's.
maintenance l"<lleue methodology A •)>ttrn of numbered rclea$C!S
used by orgoniiauon> (c\pcc1ally \Oftware vendors) that helps Or(l3.rli£C
1nainrc11ancr chan~~s and up<.l:ttc).
maJntenance team ()nc or 1norc lirl)·1ottcm' analy'r" and pr<,gran1mcrs
working on f>roduct 1nn1nrcnance issues together.
make or buy The choice bcrween de>eloping in-house software anti purdia,mg
,oftw,1rc Clftcn "Lnlled n make or buy, nr bwld or buy, decision.
malware Mali,iou< <oftw.irc that nught 1eopardi2e the system's securiL)
or priv3<).
managed hostlna An opcrA11on "managed hy th• our<ide firm, or
hem. Another term for lllS\.
management information •yo<em ( MIS) A computer-b.tS<d tnform.1t1on
\)'tcm u-,cd 1n hu'i1nC'\\ p l.1nn1n1t • ..:onrrQI, dfi-i-,1on making, and
problem >oh mg.
ma.ny-to-many relationship !.u M:1'.
market b;asket •~lysi1 A t)pc: of anal~,,. rh.11 can d<t«t panems
and trtnds in large amounts of data.
m~ per second (Mbps) A b.1nd\\ idrh or throughput measumnem.
menu bar A scr of uscMelntJble -.oft war< appli,Jt1on opnons. \ISuall)
locared a<ro-s 1be lOf' of thr '<teen.
mesh networic A ncrworl Jl'>lgll m "hi<h <a<h node connccrs ro
e\tt) other node. Whal< th" do111n" •crt reliable, II is al..o expc:n'"e
ro install and mo11nta.1n.
message An 0 -0 .:ommand thar tell, an ob1e..1 ro pt'rfonn a cenJio
method.
method Defines •pn:1fic t.td.~ rh.r an ob1m mu'' pe1'form. D«;cnbt•
what and bow •n ob1l..:I Joe, ><>mc1hmi;.
methods In a du\ dui:ram. nmhnd• r<f>tt>ent program logic
metriu Workload 1nc"urcmcnh, al•o called mrtroc•, include the
number of Imes printed, the number of rc..:ord> acccosed, and the number
of tttll\!iH.1C1101l~ prOlC'SSCJ Ill J JC,l\i~O U01(' JXrtOd.
middlcwarc '>oftwarc that connc:crs dm1m1lar apphcanon• and
enables them ro cornmu111cotc and .-change darn. For e~amplc,
middleware 'a11 l111k a departmcnt.11 dntah."c to a Wrh <crvcr that can
be accessed by client computer> vin rhc Internet or a company imrancr.
See ,1/so Mlueware.
milestone A reference po1n1 1ha1 ma l'k• a ma1nr occurrence. Ustd to
moniror progress and mana11c a pro1c,r. See also event.
mission statement A dtx:ur11en1 or )f,lt ~n1 en t that dt"S(;tibcs rhe company
for 1rs stakeholder< and briefly "ate< the wmpnny's overall
purpo.M:, pro<lucb. i.crvu •.:t:~. an<l \i31UC\.
mission .. criticaJ syste.m An 1n(or1nJrton sy-.cem th;i1 '' v1r;1I 10 3 com·
f>:my·, op<:rnnon•.
mitiption One of four ml. control >tra1eii1es. M111~.icion reduces <he
m1p•ct of• ri;k by <.Ueful plJnn11111 ,tnd prcp.uauon. Fur cxampk, a
•Omp•ny can prcp.ue a dba;tcr n-.:u•c<) pl•n lO m111gart the elfoct> of
.i n;uural <ll>a.tcr •hould one 0<.:ur.
mnemonic code C 11>her; u"ng ,, \pt<;1fa comhma11on ol letter\ thar
art easy to remember. Many rhrtt-<oh•racter •irpon codes are mnemoruc
,oc1.,,.. f or cx•mplr, LAX rcpn:..ent' Lt" Ani;d~.
mobile device Smartphoon. t.iblm. and other compunng <kv1cc.
that are not perm.u>cml) tethered to a de.k. The) connect ro the Oft·
work wa~lh,1)-
mock-up When des1gnmg .t repnn. • \•mple rtport 1s prtpared, which
i; a m0<k-up, or protot)'J'<', for u<.<n 10 re-.ew. The umpk should
mcludc typical f1dd \·alur> and rnnraon enough record• ro •how all th<
design fcatutts.
model-based synems encinMrlna ( MBSE) An approach IQ ;prem.
cngmeenng thJ1 rtllt' on domam model•, rather than rrad111onal docu
mems, ro de>i!lll large-;,wile 'YM•m> and con'e) 111formanon between
rng1nccrs.
modelinc A proce« th.11 f>r<>duc ... a grnphocal reprt\tnranon of J concept
or proce;s tha1 \)MCnb developer> can analyte, re>I, and modify.
modular design A dcS1gn tlMl <an he l>rnken down 1nro loi:ocal
blocks. Also known as 1>aruuonin{: c)r 1op-down dc"g11.
module A module rnns1m of rclnccd 1m>i:rnm code organized into
sn1all unll '!t that 11rC' "·''Y 10 undcr,1.1nd nnd 1n:11nta1n. A con1plc;"X program
could have hundreds or e\'Cn rhousands of modules.
Moore's law A predktion that compu11n11 powtr would double every
18 to l4 month, due to 1ncrtn\CJ n11111aturiLation of electron" components.
multlpAth desian A nctworL. Jc>i,:n 1l1J1 reh•-. on mulriflle data parh;
co increase bandwidth and range, u<ing f',·llMO technology.
multiple input/multiple ourput {MIMO) A wirclc~s networking tech·
noloi;> incorporated in rhc 1Lt£ 802.1 1 n and 802.11.ic >fandard> that
uses muluple data s<reJms and mul11ple antenna\ to achieve higher
uan.!truJ~!llon ~pt.'Ct.b anJ ,ub-,c;inuJlly 1n..:rta'IC w1rcle):> r..tnRC O't·ttr e:u·
lier standards.
......... ""_.. ...
.-.. ............... _
("..,_..., llll!O( .....,..___ .\JI..,...~ \b) -
WAlif'W ~-........ •_...••fl" 0-•*._ ......_ ...,..,..,..._, ~ ..,._.,,..,_._, te...-.._""""""._
..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......

462
Glossary
multivalued key ~mcromct ot " nrcc>...-.r)" for ·' primary key to consist
of a combmauon or r1dds. In that ca\c, the rrmiary k•> IS called a
combmanon key. compo>UC k•y. conca1ena1ed kcv. or muluvalued key.
natural lanruare A wfrwarc lca111re rhar allows u~ ro 1ype command'
or rcquC>I> 10 normal t:ngl1>h (or other l1nguJgel phra\es_
net-centric computin& A d1>rnbu1eJ cm ironmrm "here applications
and data arc downloaded from srrvcn and c><changrd w1rh rccr<
across a network on an a> needed "'1>1>.
net pN1sent value (NPV) The total 'aluc of the benefits mmus tbc
101al •aluc of the'""'· woth both the""" and bcnd1r. be1111t adjusted
10 reflect th• point m llln• al whoch the) 0<eur.
network T"o or mored°' !Cl's th.i arc connc..1ed for rl>c purpo<e of
srnding. re«ovmi:. and sharing daca.
networtc dJa&ram A PERT chart also is refer~ ro as a network diagram.
network Interlace A wmbmallon or hardware nnJ software that
allo\\'~ tht> t..01nputer tu 111tcrJ1;.1\\11th1he ntt\\.OrL..
network Intrusion detection system (NIDS) Softwan: 1ha1 monuors
network trJffic 10 detccr 011cmp1cd 1ntruw111s or ,uspicoous ncrwork
traffic 1)attcrns and •end> alem tO ncrwork ad1111n1strators. C.111 be
helpful in dcx:umentin11 the tf(om of art3ckcrs nnd analyzing oerwork
perforn1..incc.
network topology l hc way• 11 c1 wor~ "configured. LAN ond WAN
networks tyricnlly a re arranged 111 one of four common parrern<: hierarchicnl,
bu~, b~t, and ring.
node A phy~JlJ_I dcvu:c, "ired or \vi rel-..~, rhat CJn send. recei\•e. or
man.Ji;< ncrwork UJIJ.
nondi.sc retion~ry project:I \X'ht•rt- 1nJ.n~~rmcrn has no chose~ in
1mplemen11ng J pro1cc1. rhey arr called 11ond1-.;rc11onary. For example.
adding a reporr required hy a new federal law.
non.functional requirements A ~iai.-mem of operJnonal syn<m
COCbtratOl>..
nonkey field Any field 1ha1 1~ not a primMy ~" or a candidate key is
called a nonke) field.
normaliution A proct<>s by "h.-h Jnali;ts 1dtnt1f1 and correct inherent
problems and ~omple'1UCS tn 11>cir record des•Wb·
NoSQL d~tab;ases Oatabase ~1.irm• 1ha1 ~a llar, nonrabular (nonrrbnon•I)
•tructurc ro \!or< and procc-. laf!IC·'<'•k data""".
n-tier desirn A mulul.,,cl dc~ogn Of ar.hnecture_ for <•ample, three·
ncr design• also arc called 11·t1cr dc<1gn<. ro md1ca1e that some design<
use more than one unermedtalt la) er.
object In ob1rtt-Ort<nt•'tl a.nal)>t~ or prow•numni:. an obll"-t represen1s
a rral pcr~f•n, plac:t, t\·tnt~ or cran-.ac.;ut~n.
object model Dc;<;rtbc' ob1c..1s. whi<h rnmbme datJ and prcxesses.
Ob1ccr models arc the end produll of 0 0 analysis.
object-oriented (O·O) •nalysls The .1ct nl undersrnndong an mfor·
mntion system by 1dent1fi "'II t hin it~ called objects. An object represents
a real prr!i>un, pla.t:e, evt>nt, or tran~~u.:1u>n. Ohjec;.1 .. orien1ed :1nal)'St\ i.s a
1>opular .1ppn1.1ch th.u ...,.. J >)'>t<m from chc v1<wpo111r of the nhrccts
themselves•> chey function nnd inrcr.1c1 with the <ysrem.
object-oriented development (000) The process of tr.111sb11ng an
objel"t model dire..lly imo an O·O prowam111i1111 lnngunge.
observation A f.1~1·fin<lmg 1c.h111l1uc wh<rc nu 'maly>I see. n system in
3'.'fton. Ob~n·a ti on allo\Y\ 1l1r v\·ri(K..1t1on of 'itJcen't'nts rnade ul lntetv~V').
offshore outsourcing The prnuice of <h1hn111 IT dcvclnpmeni, '<•P·
tlOrt. and operation< ro orher counme<.
offshorln& Sl>e offshore ouisourcing.
offsldnC The pr3Cl1Ce or '10rtog batkUp flll'<iia 3\U)' from tbe mam
busoncss loanon. rn order 10 ntitti;>tc the nsk. of a catastrophic di>astcr
such a~ a A<><xi, fitt', t>r t"arthqu.1k~ .
one-to-many relation•hip \t•r 1 :M.
one-to-one relation•hip \u I: 1
online da.ta entry A Jat• entry mcothod u...:d for mrnt busmcss a<m·­
ory. The onlme mcrhod offers ma1or advanragN, including the
immcdme validation and ""ul2b1l1f) or wt•.
online documenQtion Pru"t<lt!i. 11nrnt't.11;i1r heir when U\Cf) h3\ e
qt1e'5t1ons or encounter pmllkn1\.
onllne •yst~m Handhng rransamons "hen and where rhq• occur and
prov1d1ng output dtr~tly to user>. &x-;iu~ n 1; 1nccr3\.lt\e, onl1ne pro·
ccssong amid< delay> and .allo>\< .a con\lant J1alojt hcrween tl>c u<er
and the sptcm.
open database connectivity (ODBC) An ondustt) ·\l,rnd.ud rrorocol
that make> u J'O'>iblc for >0frwarc from d1fkrcn1 •end-Ors to interact
and exchange data.
open source Software that" supponcd hy a large 1troup of u<ers and
de•elopers. The sour« rode os made freely •"aol.ahlc.
Open Systems lnt .. rconnection (OSI) model L>c<nobc> how data
acrually moves from an apphcauon on one .;omputer 10 an applicJtinn
on another networked <0111putcr. The OSI rnn•1>1~ of"'"" la) er;,, and
each l.1yct performs a spec1{k fun<11on.
open·ended que•tions Quero°' that nllow for a range of an..,.•crs.
The)' encourage sponrancou> and un,trtKtured rc>pon'<!> .md orf u~ ­
ful in underst.1ntLing a l.irger pr~cti.s.
operational costs bxpcn>cs tltJc arc onrnrrcd a fter a sysrcm ts implemented
nnd conrmuc whole the •»·Stem 1~ on u<e. fxamplc< include
syscem n1ainrenance, supplic). equip1nc 11t rent.ii, nnd annual sofrwar~
I icense foes.
operationaJ environment 1·hc cnvironn1cnt (or the ~ctual *'Y"t<"1n
operacion. It includes hardware ond software configurorio n ~. sysrcm
utilitic), and conln•unicJuon"I rt-.)Ollr\o.c). J\130 c.:.tllc:d tht proJuc.:uon
environment.
operational fe;aslbllity A sysrcm tha< that "111 he u;cd cffccnvel1· after
ir Dl> been devdo(l(d.
operational security Cun<erncd wnh m•cu11rroal p<1l1<1c-. and controls
that ensure secure opcr.mon\. Al'o called pro..cdural >ecunl).
operations documentation Conca1ns all 1he mformauon nttded for
processmg :wd dmrtbunng onhnr •nd printed ou1pu1.
option button R•d10 button> that rcprc\l'.nt lt'°"fl' of upllon\ The
user can <clccr onl)· one or11on at • nme; a ...,le<:ttd npunn contJin' a
black dot. Su .,/so radio button.
orphan Ao unassoc1ar<d or unrd•tcd r«:orJ or held. An orphan <ould
be ~ared 1f •customer order was entered on an order table whcrr that
cusromer drd nor already e\'.ist on the cusromer table. Referential mregnry
would prevent tbc creatton or th~ orphan.
out:put control Met.hoc!> 10 mam1•1n uutpm mt<gntl and S«Unt}­
for example, e\'cry rcporr <hould include an appropriate uric, report
nwnber or code. priming dat<. and umc pcnod <O•cred. Reports
should have p•gc> rhat arc numbered con,<cu11vrl), 1dcnnficd .l< Page
xx of xx. and the end of rhe report should be lat>clcd clearly.
out put security Ou1pu1 securiry protect'! po l\lC)' ni:hrs and <hields
the orga11ll.'111011's pruproo<ary Jara from theft or una11rhun1.cd ac~c".
out sourcing 111e tra n ~ fc r o( infnrn1a1ion ')'(iltnl' de,rlorn1en1, OJ"Cr~t·
t101l, or mainrcn~ncc co an ou1s1dc (1rm th3t provide' t h c~c ~r,·1cc~, for
n fee~ on a 1e1npor:iry or long-tetl'U b.1ii.1~.
page footer Appc.m '11 the bo110111 of the page and i> used tc> Jispla)'
rhc name of rhc report and the p.1gc numhcr.
page header Appears at the mp of rhc p<1ge and ondude< the column
beadini:• tbat 1de 1t1fy 1he dat.o.
pair programming A pr.1.n<r in XP 111 who•h two proi;r.1111mc" Mtrk
on the same rask on the <amc co111p111cr: one drive~ {program~ > wlule
tbc other nangates (war~he>).
parallel operation The pJtallel opcr•llon chJngeover method
requires tbar botb the old and the new tnforrnanon <ynem• opcr.ttc
fully for a s~16cd period. Data IS mpu1 mro horh ~i-ncm~. ~nd output
generated by the new >y .. rm "wmp•red wuh the cqu1v.llcm output
from the old S) stem.
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

Glossary
463
pattnt In 1nhcm•ncc, • parent " the obJ"-' from which the other
ob1cct, the child, dcme, one or more annbures.
pattnt diavam in., higher or more cop-le,·el di•gram io an exploded
DH>.
P;areto chart \ •-rn1<:•I bar guph named for a nonncrnrh cenrury
econonu\f. The b;ir., w ht<h rep~r •arious causes of a problem. :ire
.urangcd in dcsundon11 order. '° 1hc learn c•n focus on the most
1mponan1 .:ause-.
p:artitionin1 The breaking down of o•<rall objeaiYes inco subs}.,;rems
and mc1<lule..
patch Rcpl•ccmcn1 code that 1s arphcd 10 h'< bugs or secunty holes m
soft.,""'·
payback analysis A de1crmma11on of ho" loni:: i1 rakes an infomu-
11on 'Y'lem 10 l'•l' for mdf 1hrough reduced co.rs and mcT<ased
benefit>.
perfective maintenance U.•n11c' w • 'Y"•m ro improve cffici~.
pennisslons Us<Mf't'C1f1c l'riv1lq;cs 1ha1 dercrmme 1he l}'p<' of access
a user has io o darn ha~. file, or d1rccrnr)'. Also called user rights.
penonal digital anlstant A proi::rnm char responds rouser requests
lhrtlU8h .1 n.1rur.1 l 1n1crfJ\.t" 1
'U<.'h ;t\ rrgular \j)CC4"h, to pro' 1de ~1 ss1stJllCC
10 i;cncml-purpo><! qucr1e,, Often embedded en dl-viccs such as
lnrern~t<o11n~1..tcd ~rc.1kcr) and <tni.1r1phrlne\.
penonal information manaacr (PIH) A tool 1ha1 helps manage
task< and .chcdu le~. Many handhelJ dcnccs "Jso include this function.
penon-day rhc Jmount of work 1ha1 <me P""on can complete in one
day.
PERT/CPH ·1 he Progr,1m E\.1 l11a11on Rene" Techmque (PERT) wa5
developed b~ lhC U.~. N.wy IO manage V<r) <omple>. proJt'Ct>. Such
as chc con\lru<llon ol nudcar <uhnurcn.-. At approx1maiel) the
•amc time, the Cntrcal Parh :llethoo (CP.\I) was developed b) pri­
\.alr 111Ju,lr} to tnt'et 'll1tn1t•r projci..l nun:isem~nf ne~J ... The
1mporrant di.ronc11on< bcrwecn the rwo methods ha\'c d1<app<'Jroo
o•cr nmc. and coda) the 1cchmquc L> called ctthcr PERT. CPM. or
PERTICPM.
ph;ued operation The rh.1scd nperanon method allows a ll<'W S)'Sl'<rn
ro ~ unplcmemed on scagcs, or module>.
phyilal deslan A plan for 1hc .oc1ual 1mplcmcnuuon of chc sy..tcm.
physical model \ model tha1 ck'ICTI.,.._ how • •)'stem ,.,11 be consrructcd.
physical stora1e lnforma11on SIOrJj;C mt'<:h•nosm tbJt L> smal) bard­
" arc rcla1cd, i....use 11 '"'·oh cs the rl'OC<'Ss of rcadmg and wntmg
bmary data 10 physical media, such JS a hard dm·e. Oash drive. or
DVD.
physical topology lllc conn<CTion srrucrure of an acrual ncrwork'<
cablnlJZ.
pilot operalion Inc pilot opcro11on choni;cover mec:boJ uwohes
1mplcmcn11ng the cnmrlccr new <y,1cm nt a sclccrcod locanon of the
company.
pilot site In J pilot opcr.1t1on, 1hc group rhot uses rhc new sysrem fuse
" called the r1lo1 "'<.
plain text Dara that cs nm cncrypccd.
platform A >pe<ific ha rdware and software configuration char supports
I r hu~1n<.·~~ goal, 'uch n~ hard\vare connttuvity and cd~Y
mccgranon of fucure apphcar1ons. Also called on cnVJronmem.
podcast A web-hnsed hroaJcnsr rhar allows n user to receive audio or
muhi 111cd1a files using music pla)<r >ofrwarc such as iTum:>. and listen
to them on a PC or download 1hem 10 n ponahlc MP3 pla)tr or snun
phone.
polnt-of·sale (POS) The f"'" of an mfornu11on sy\lcm lh•I hJndLes
d.ul) >a.le> rran .. 1worh and mamtam> 1hc onlmc in' cnrory file.
polymorphism The con.:ep1 1ha1 •message iti'es different meanini:s
to d1flcrcm oh1a:h (c.11 .•• (,0()1) !'\l(,I n mc~sagc 111igh1 produce
diflcrent r~ulti dcpendmg 1f 11 rs rtttl'td by a child or the fanuly dog).
pool The o•tr.a.ll J..agram on SP.\11\.
......... ""_.. ... .-.. ............... _
port A posauve integer 1hat '' u\Cd for rounns 1n1.:om1ng craff1c [O th~
correct applu;a11on on a <ompu1cr.
port scan An ancmp1 ro dctc-, the <oer.•c•' running nn a computcr by
lf)IDIJ to connect to •~nous poM> and ra.ordmp; the portion wbkb a
conn«:t1on \\'a\ accepted.
portal An entrance to • mul11funcnon wcb<.11<. After cntcnnit a ponal.
a mer t"an 1Uv1CJt~ to :a dc>tut3Uon. u.>1ng \3nou~ cool> and f~ture\.
proml.,J h)· th• pon~I dc.,gner.
post-lmplement:ation evaluation ,\n •'~smen1 of tht O•erall quality
of the tnfoflll.11100 ~)>ltm . The cvJluanon 1cnfies tha1 rhe new
sv~1cm mccts spcc1ht'd ttqu1rcmcn1s .... -omplt~ \\-Uh U\C:C oh1c:,t1,-o't and
achine< the .1011c1p.icd bcnefi ... In addmon, h> rro,1dmg fccdhJck m
the devclopmem team. !he C\ alUJllOll JISO help> improve rf developnu.·nt
practlcC"\ fc>r futurt' rto1rcr~.
poweM>n password .S.-r BIOS-levd pa.-w-ord.
predecessor couk A •mglc rnor ta<k upon which rwo or more concurrent
1as~ dcprnd.
preliminary investigation An 1r111onl Jnaly>1< 10 de.rly idc 111fy 1he
nature and scope of chc busi11cos npportu111ty or prohlem. Also cJllcd a
feasibility .rudy.
pretexting Oht.111111lg per'4.•nn l 1nforn1a11un uudcr fJli;e prcren~ei..
preventive malntenanc~ Ch.11lgc' 10 a l\)'~u~ 1 n to rrducc: 1he po~:i. ihiliry
of fururr failure.
primary key A ficl<l or rnmb111a11011 of field' rh.11 uniquely and minimally
idenrif1e, a part1t..:ul.,r 1nembtr of :in enciry. l•or cxan1ple, ln n
customer table chc customer numhcr '' .1 unique prim.1ry key because
no two cus1omcrs <'UR have the >ame cu,tomer number. Th3t key •lso is
minimal b«au.>e 1t conr;uns no 1nrorn1.\t1011 beyond whar 1s needed to
1denrtfy rhc cu~tomer.
priva.te key encryption A 1.'0mmon encrypuon ce.:hnologv call«!
PKE. Tbe pmJ!e L.q "one ul J p•or of kq•, anJ 1t Ja.l)ph data tlut
has been cncryrccd w11h the \CCond part of the rJir, the pultltc key.
private network A dedicated rnnne<:non, \lm1br 10 a lea..ed
rekpbone lmc.
privilege escalation attac:k An unau1honz.,J ancmr• 10 m.:n:asc
permission kvcJ..
probable-case estimate The mo>I Iii.ti) oui<omc is calltd a
probable,,a~ e~tun.alt
procedural secunty ( -oncel'llC'J wuh manag•n•I rol1.1C\ •nd conrrol<
rh•t cn<11rc secure oper•llon•. Also nlled orcranonal secunry.
process Procedure or 13;k 1hat u>cn. manage<'>. •nd IT "aff member,
puform. Also, the loi;JCa l ruin of a <~stem tlta1 are apphcd 10 rrans·
form da1a IOCO mcarungful tnforma11nn. In dat.l no-. diagrams, J
proc:e.s rece.-e> mpu1 dJrn and produce; ou1pu1 1hac ha; a J1ffercm
c..."Qntent, forrn, or hoth.
process 0 In• l)~I). proccs' 0 (1<rol represent< 1hc cnnre information
svstem bur does nof show the on1cnul workmi:s.
process description A Jo.:umcni.mon of a fun1.11onal primiti,,e·,
dcc•il<, which rcprc<cnl\ • <p<'Lif1c 'cl of prtx:c<>1ng <!tp< .ind bu<ine<s
loi;rc.
process improv4'ment T he fr,unework used ro imep;rarc software and
sy.ccms dcvclop111cn1 by• new M:I rnudd. CMMI.
product b;uellne l)e<v1hcs rhc •y;icm nr the hcg1 11111ng of opctalion.
The produc1 baseline incorporatl"> nny change; made since the allotdleU
baselme .ind u1dudc, the rc-.oll' of performan<:c onJ a.ceptance
ccsts for the operational 'Y'lem.
product lifecycle management (PLM) /le. application lifecycle
managcmeo1 (ALM).
production environment The tn\.1ronmcn1 tor 1he ac..ru..tl 'Y~rem
operauon. h include> hardware and <of1warc confogurauom, system
utihues, and commun1cdlions re>our<:-.. Al'o oiled the operational
cnv1ronmenr
productivity softwatt Apploc.11100' <u•h a< word rroccssmg, spreadsheet.
database management, >nd pr~scnmron ~raph1cs programs.
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_...,llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

464
Glossary
product.o0riented C...ompan1cs thdt n1.1nu(acturr l"01npu tc:~. rourrrs,
or m1croch•p~.
Pl'Olram documentation Prep;ir.inon of program documt ntatton
\laru 111 t~ \);tt1rL-. J.n3l);I~ ph.a.;c .1nJ -.;onunuc:~ Jur1ng "")~rems
1mplcmcnt•non. S)Sl<nl\ •nal)\I< rrrp>re O•erall documenta11on, such
as process d~nption• :and rep<>n la1·out>, earl) m the SDLC.
Programmer'\. pro\ 1dt" dc>Cunttn1.i11on b) ~ans;rru"t•n~ moduk4" th:tt are
well supponed b) 1111tmal and c.icmJI commcnh and descnpttons
dut c•n be undcn.tood •nd mJ1nmned ta,il).
Program Evaluation Review Technique (PERT) Su rERT/CP~I .
Pl"Olrammerlanalyst A dC'\1W1•11on fc>r ros1nnn< that require a com·
bmarioo of ~·stems anJl)SIS and prnt;rammmi: skills.
project coordinator The pen.on" ho handl,., admitu>tramc r"'pon­
"bdmcs for tbr dt\do1>1nrnt tram and negottale< wi1h u<er< who
might ba"c co11fhc11ng rcqu1rcmcnr> or "ant changes thar would
require •ddumn.d wnc or e~pen.e.
project creep Inc procc.s by whtth pr<>1«is wtth \cry i;encral scope
dcfin1nons e~pand grndually. wirhom <pcc1fic amhori1ation.
project leader The per-.<111 charRcd w1rh leading• project from •
t('('hn1co l p<rspernvc.
project management rhc pr<>«" of pln1ming, scheduling, mon11oring,
controlling, and rcpor1111g upon the development of M
infor1naaon ~y~ttn1 .
project manager ·1 he pcrwn charged wuh managing• projoc1 frum
an admini<;:tratlvc pcrc;!'>C"Crivc.
project monitoring Guiding. supervl\mg, ond coordinanng che proit<:t
team\ workloJd.
project pl<innina ldcnttlymll pro1«t t." ~' onJ c<timating compleuon
time ond ~<>'>ts.
proiect reportin1 Pro\ 1J1ng ri..-g:ular progri..i.'J reporcs ro managt."menr~
users. •nd the pro1cct tc•m u<cll.
project schedulins rhc crc.mon of,, 'peciftc nmct.1blc m fnciltr4rc
complerion of• project. Also invol··~ ~ l eering ond staffing rhe project
team and ass1w11n11 spcc1li. t•sk; to 1ram member\.
project scope A si-1hc dcttrrmnauon of a pro1e..,\ houndariC" or
extent.
project trianal• The three ma1or cumponm1> ot • pro1ecr: co.,,
scope. and umc. A pro1cct manai;tr rncs ro fmd the opumal balance
among the<e facto~.
properties In obicct-oncnted <0 0 1 analysi>. characteristics cbat
ob1crts mhcm from tht1r da" or I'"'''"' on 1hcir own.
prototype An early, rar1dlt con .. 111x:ted "orking \Cr\1on of rhe prop-OS<'<!
1nformauon >y>1cm.
prototyping The meihod hy which• prmot}p<• "Je>eloped. It
involve< a rcpcltll\e srqucncc of an.11~"'• de"!!"• nl(ldeling, and res1111g.
Ir is a common technique rh•r c11n he u1ed to dc11g11 anything from•
ne''' ho1nc co a compu1er n ctwor~.
proxy server A nerwork1 1111 de' tee 1h:11 provide' ln1ernc1 <onnccnvity
for internal LAN use.-.
pseudocode A tcd1111quc for rcprC>t'llltng progr:im logic in scmi­
~Lructurtd pro~.
public key encryption (PKE) A common c11cryrtion technique. bch
user on the network ho < a patr of key" a ruhlic key and a pl'ivare key.
Tbe public key encrypt> data thJt t11n be J <:<rypted wi1h the priv•te
key.
qualitative risk analysis hJluanni: ri ~ k by emmnri11g the probability
that it will occur :ind 1he d<!!l'l.'C ol unpact.
quality :anurM1ce (QA) A rr.x:cs' or prn<eJurc for m1mmi2ing errors
• 10d ensur<ng quah1y 1n produ•t>- Poor qualuy can re.ult from 1nnccu·
rate reqwrrmtnb, de:)1gn problem\, coJ1ng error'-, tnulry
documcn1a11on •• md mcfft:>.hvc tc<11ng. A Qi\ team re"•" s and tests all
npplicrnons and sy>1cms ,hangts to verify <p.'C1ftca110"' and software
qu;ilt1) >tandard>.
quality attributes Su noo·fonc11on•I rrq111rcmcnis.
quantita.tive risk analysis LvJlu>llng mk Ill ttrnh of the acruJI
1mpaet '" tern1s of dollar.. umc, pro1cct ><.ope. or qu.11111.
query by example (QBE) A language allow> the u1<r to provtde Jn
example of the data rrque>l<'<I.
query language Allows a u~r 10 specify • task "tthout spectf) mi;
ho" trn: ta<k \\Ill be accomrh<hed. !>ornc qutr) bnl(UJj:~ U'iC natur31
language commands that resemble ordinary f.ngh•h •rntcncC".
qu~onnaire A document conmmng • numhc:r of >1ambrd qu<"·
nons that can be -.ettt to """Y 111d1nduJl\. Al"1 <.1lleJ J '""C).
radio button Button> th.at rrpk'Cnt grour• of or1Klll' The U\Cr un
select only one opoon at a nmc' a selected oruon con1>1ns a black dor.
See also option button.
radio frequency identification (RFID) T<'<.hnolOjl) thot U>e> h1i:hfrcquc11cy
radK1 wa\c- tu tnt k phr1<JI ohJC<I\.
radio frequency identification (RFID) ta1 An mput device u<cd 1n
source data autonut•on.
.-andom sample A sele.non taken ma rando1n, un planned manner.
For example, a random .. mple 1111gh1 he• sample tha1 <elc.1s any 20
cusromcrs.
range check A type of daca validation check that tC•lS dn1n items tc)
verify 1hat rbey fall h<!twccn a sped lied 1111nml11m and maximum va lue.
The daily hours worked by n11 employee, for ex.1mrle, must foll w1thm
the range of 0 to 24.
range-of·responso questions Clo1ed ended que>iion• that a~ k the
perwn ro evalu.11c something by providing ltn111ed """'tr> to sped fie
respon<es or on a numeric SCJle.
rapid ;a.pplication development (RAD) A tcJm·hao;cd rcchniquc that
speeds up mforn1't1on systent> dc•elopmcnt Jnd produce. a funrnoning
information S}'Stcm. RAD is sm11lar i11 concept to JAD but goc>
funhcr by including all rh.1\C'\ of the ~Ol C..
reasonllbleness check A rypc ol data vahcL1tton cht'Ck that 1dcn11fics
values that arc quesuooable but not n«.tssanly wron~. For example,
mput payment •·alue> of SO.OS .md SS.000,000.00 bo1h pas; a simple
lim.1tchtck for a p•)mcnt 'aluc greater than uro. and )<t "nth 'aluK
could be errors.
record A M't of ttlJted field. tha1 dc ... nhc:; one m>tan,c. or tn4'tnbtt
of a n cntrt), ~tK:h a" one cu~romcr. one t>rJcr. ()t cMlC' rrcxlu'-1 A Chord
might ha, .• one or dozens of fields. depcndmit on what mfornunon ts
needed. Also called J tuple.
records retention policy Rul"' de>1g11ed to meet Jll lci1-1I require··
mcn1< •nd hu<m"1i< ~' for l ~ring m:ord<.
recovery The procc<<< of restonng dJta and rc<ramng a syorcm after
an interruption.
recovery pro«'Clure Pr0<t1>> for re;tonng data and reHamntt a sistcm
:after an 1ntcrrup11on. RttO\'Cf)' ('rtk.cdurc~ c:;an he usrd ro r~t orr a
file or dorahase ro it~ currcm state at the ttme of the 1.-1 l><1<kur.
,..,dundant """'Y of Independent disks (RAID) A RAID sy<rem may
h<! pon of a11 organtLation'> backup and recovery plan•. A RAID')'"
rem mirrors the dar. while prcxc'""ll ""'""uc>. RAJD <ys1cms are
called fault·rolcranr. because a failure of a11)' on< disk d~< not disable
rhe system.
referential Integrity ,\type o f valtd11y check. Refcm11tal mtt)\I iry i; a
set of rules that avoids dat1 """""' tcncy .111d qualtry prohlcm<.
relational database A da1•base m which t;ihlc< are rcl•tcd hy com
mon fields, crearjng a unified datJ mucrure that provi<lt• improved
data quallly and•«"''·
rel<itional model A moocl U'>Cd'" rcl.mt:ltlal JniabJ<«. The rrb11onal
model was inrroduced during the 1970< and 0«:.1mc porular because 11
w:n flexible and powerful .
relat;onships Enoblc ob1cc1> to co111111um<.t1c •n<l tnlerall .h they
per-form the business fun<11ons .md ir.m<a<tu">n• rcquir<J by a sy\lem.
Relauonsb1ps describe" h3t ob1rtt; oecJ to know about each other.
how ob1ccts tt>pond to <h.lDjtt1> 111 other ub)C<b, •nd the clta;ts of
mcmber\h1p m d.lSsc<. supcrd•"•"'· •nd \uh<:la.~.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Glossary
465
"''"'"'" plan In 1111lr dC\·clnrmen1, • rl•n 1"'11 'r<"h"' "hen l1"7
\tnnn "111 i.., 1mrkmrn1eJ .anJ thr 111111ni; ot tht rd.:.•""· Rd~ art
rd.au\ th trc:qumt, •nd t.k:h rde•,... 1> 1r<'!1td •• • "'rrm protO<YJ'C
th•I .an ht '"''rJ .anJ mod1hcd ' ntt<lcd.
-l• control JOftw&n Arrlt-•1tOll\ th.lt .u .... n " .. tt to ulc
mrr • u<n\ wod-t•non and rm• i<k "'M"'fl "nJ trnuM«hoonn~
~I l"O"P \ ~t of~ or mott htkl• lh.11 '"" ocrur •ny number
ol ton,.. 111 .a ..ngk m:••rd.. "'uh ... ,h '""urrm..c h.1•m11 dtt!n-om ,-.u~
....,Ort rooter .\prc•r. JI •ht md "'the fCJ'<lrt. '"" 1n..luck gr.and
mul\ tor nurncn.: field> Jnd ·~htr cnJ nl rcrnn onformmon.
,..port h4!•der Ari'<'•" .11 tht h<it1nntng of• rrr<>rt •nd 1dmniics rhc
f<J'<lrt •• \\ tll J\ lh<: rcJ'<)rt llflc, .lilt', JnJ UCher n«:CS>'lty infomntioo.
requet ror pro~ (kFP) A "nncn l1>t uf tcaturcs ;i.od specifiQlltlll\
fi!l\l"n tu r••9'J'n-l1\l" \t"OJtar, ht-torr. '\rn.1fh. rtt.x:ILk.t ()f' pl..:kagr:
h.-~ ~l<'Ct<d .
requ•.c for quoabon (RFQ) l otd to ol-t••n • rn.t qut>Uooo or hod
un a •!""•l" pr..Ju.. I u< l\l•k.Oi:t
requ•,..,.,..,tl d4!fi111llon• A Jn..11rnon uf rhc '} -t<'ID rc.iulJTIDetlb
tr1lm 1hr u_\('r\ fl't-JUlt ol \IC".
requ1rTm4!nt1 4!heitatt0n Th< ,...,,.._, ol 11Jth.:·nflll: rtquircmcnts. Su
r • .:di11dtn1t
requirements en1lneenn1 U>ed on the''''""" pl.Jnrun.; plusc of !he
.,f)I ( h uwol'e' U\10Jl ,,'""" l••I f111drn11 tnhni~ur.. <u..h •< onrer·
VJrw•. 'urvry,, oh.crv.mon, .rnd <.1mrl1ni;, 111 dc'llnhc the currt"nr
'Y'lcm all(] 1Jcnnfy 1hc rcquir1'111cn" for 1ht new •)'tern.
requlremenct planning ph;uo A 1ih.l'e 1hJ1 "m1hlnc' dtmems of rhe
'~Mtlll\ j)l,1111111114 and ~y, lrtll\ .111.it,,, ;, rh•'e' nf thr \Of (..
requlrt'mentt •p4!ciflcatlon1 A Jc.crir11011of1hc •y>1cm requirement\
Imm 1hc ,~n•ly\I "' cnginetnng 1,Jm\ ro1nr of \It\\.
~h An imronJnc facr . findm~ 1c.;hn1quc rh.i mdude. die r.-.'icw
ut 111urn•h. rcnoJ ... •I-. •nd r-. .. .i., m uhu1n l-•.l11munJ utlurnunon,
lr<bn1<.Jl nuicrul. Jnd nn-s Jb.JUI mJu\11') rrrnd, md dndopmcnn.
retponM I.Im• Tht o><rJll tunt l>ct"•= ~ tt<1unc for •r""•tm ann·t~
:and rhc ddnrr> n( the rcspon-c. In~ l\~JI onlmr rnnromncnr.
"''"''",,.. unw" mc.t>urrJ trum the 1f\u.uo11hc -· J'lfi'° the EXI1o.R
le) or d,..l,' "'"""' hunnn until the n-.iuc,1cJ "-<«n disrt..i 3ppe&n
or rnnreJ ourrut ,, rcaJ>.
recentlon p<tnod S..clUJ)' .ire •rurcJ tor J '!'<"-''" r•'ttllbon period
~h<1 "h1<.h 1hc1 art c11htr &.rro)-nl nr the l>••kup mcdu is reused.
NlUm 011 lnvtitmcnt (fl0f) \ J'CR.Cllf.l/;l" 1'te lhJt IT1<"3\UrtS rrofir•
~h1hn hi cnmr.in111 the tnrJI nrr l-mrf1t• hhc rr<uml mr1.-rd from a
rrvtl'\.I IO 1hc wul (<hC. 1 the 111\t\tm<lll J of the rru,....1. ROI. 110121
l>cttchb - toul •m••lfmul"""
""I n~f....,.... \ nct\<url rncmhlon11 ~ ur.k nl wmru1rr> rh.at corn·
mun...,rt "'"' t.>ch c><htr. ~ nnc n<Nork oftm "u..-d "htn
rn ... o..n11 "' puturmcJ at lo.:al '"'"" rathtr dun at a crn1nl loc:ttion.
rKk An C\tnt th•t u>uld .1tlc.1 the rrottt-i llCJ;.>11\d).
riJtc .._...,.,II \1ca-urn the hl.d1ho1>.J and •mJ'M.t of mJ.s.
rt>lc confrDI lk•clor> ufqtuJrJ, rh.i rcdo..r the hld1hood mJ
IMJ'.lt.I of n'l.'\.
risk ldenaficadon I l\Mf: c::ich nd, anJ a1<""'"'!1 tht hkd1hood rh:n
11 •ould •fleet • prof'""
rl•k man.1g .. m•nt The prn•.c" 111 i<lr1111ri '"II• .-,1fuJt1n11. 1ra,ku1g.
• 1rul lnnll nll111g n'k' to rn1nh111 7.\'. chr1r 11n1l.U;:c.
risk manaacmcnc plan Include• n rt• 1<w nf tht rro1c.::t'< <cope, stakeholder>,
hudi:e1, ••hcdulc, anJ any mhtr 1mrrornl or C\lcmoJ factors.
th.11 111111111 .ifl«r 1hc rrot«•. Tiir 1>1.in •houl1l Jrfine 1iro1c.:1 roles and
rnr<•11\1h1l11ir-. rl\k 1m11JJ1tmtnt n1eth11<h Jnd pmccdurt\, catcgoro«
of mk\, Jnd <OOllnflCllCV rlan\.
risk ruponM plan A rroarn••, dfon tn :ann.ira1e J ful. .and d..-.cri.be
~n ll•ll<lll r!.n IO Jc-.al "11h fl. ,'\n ctfe>11\r ml tt-l'C>fl>t rl.tn uo ttdu.:e
th<: o>rr.1ll 1mr~a I') m~cn"I! • nfll<'I• and .1rrn'l'n•1< .acnon.
roamin1 .\ rrt, .....,. th,11 -i11t)\\) \\-1rtln> i..lacnt'\ co 1110\C' lrt>nl tlnc
J~\ J'<'lnl tn Jnothtr, JUIOtnJl'IC.lfl)' ~<-"lJllllf: >\llh !ht <rrnni;cr
.11.. A.:O-' pnnt .JnJ all''""'"~ h>r un1ntc:rrupt~d "1'\h•. c .
route,. .\ dfo,, .. ~ ch.it "'"'nc:"l'° nc'"''""l ~cnt,, Ja.:nn1nn chc rJ'kb.I
dtk.imt 1bu r•rh. apJ l(UKk> rht tln\\ ol J.11.1.
sampl1111 .\ rm..n> \\hc:rr .111 nn.al)sr ~olk.;1' .,.. mrln nl .><:<II.ii d•><>
umnth, "'h... h .i1<1ld ""lutk rC\otJ.. rq><>rt'>. or .-.onou• fotn».
scal.lblficy \ 1hJr ...irmu1 ot J '~"cm.1mpl)11ia thJ1 thr "'ccm 1Jn
i.., C"J'•ndrJ. mud1hcJ, m dnwn.ucd c ... 1ly in mrcc rhc r.1rc.JI, ,h;ingmg,,.
.., .... (If J bu>lll< ..., mrerrrue.
sat.ab!. The Jfl1lil) of J •)>rem co '"f"'"J 10 1111-.,t nrw bu>lll<"»
rrqurrt1nrn1' ;anJ \ttlurut'\.
10Jln1 on d•mand !he .1"1!11~ 10 mJt<h flcl\\orl ""'"""co nttd<
.ot ;any ~" .,, nmc: a f.,turt ol doud 1omrunnR. for cx.ompl<, dunug
r<JI. luJd•, i1Jdll111n.ll .luud ••.'f'<r> lntghl U•llK' On fut<' •UluntJlh.;af!\
to <urron 1n. rt.a....J •rnrlln.aJ.._
satte.- d .. rram \ ruol u-cJ b> systcm .1n.al\\h 10 ~urh""U' '"""
rb,, wrn-buun h<t,.rto '"" •MUbks. ,\l,.1,'allt-d ;1.n l\\ dun.
u.....uicK In an •Jill< rn>tn.1 • .a rcat.,.orfd c'Amrlc of ho,. u.cr. "111
mrtra..., \\.1th the 'Y"tcm.
Kh4!dule r .... b11lcy \ rro1«;t .:~n h.c 1mrlc1n<·nrrJ on .111 ""'' pcablc
ttmt' frJmt.
Kh•ma The rnonrlr•c Jcl11111111n of. J.11JhJ,<. 111dud11•K Jr-..ripuom
of .111 f1clJ<, rr..onl>. Jnd rrl.u1nn•h11"
scroll bar In u<er 1111rrf.11.c tlt<ign, n Stroll liJr •llnw< 1he "'er to move
rhr<>u)lh 1hc ,l\ a lf ~b f e <hOM'\ fo1 ,Ill 111flut f1cfd.
Scru"' A popul.1r tr.h11h1ur fur .1gll< pro1<•1 1m n11jlernr111. l>criveJ
frnm a ru111>1 11·nn In "'-rum, te.>m mcm!>rr. 1l.1y ''""'""role• .111J
Lnter;u.'t 1n lnu:n\.C ~\>Ion~.
second nonnal rorm (1NF) \ ra:<>nl JNi:n h 111l~F11ti1> in IM .mJ
d •ll hdch !hJI .orr II<~ r.in of 1ht rom;ary kc) .Ire dcrcnJmt llCI rhc cnbrc
pnm;ary l~ It •ny ftcld 111 • I ~F rccorJ Jerrod• on uni) nnc ot tllc irdJs
ID J rnmbm.it•Jll J'f1l'Ury ....... mm""' rt<unl .. noc '" 1:-.1. A 1:-:r m;orJ
\\tth a rt11n.1ry ln rlut,., • •·• hdd "aucom.11 .. •lly 111 .!:-.I.
secondary tc.y \ ticlJ or'"'"""'"""" of hrld• thJt <Jn ht uwd to
.l'-74.X~~ or n:tnC"\C' rr..:Ut'di. S«ood.an ln \Jlun .lfC' nnc un•~UC". tor
(umrk'. t•• .h
.. '-('' tt\.1,rJ~ f,., onl) chcli(' cu .. romcr'\ 1n .a .. ,,nit ... rt>~I
code. I~ J'l"IJI wdr held "'uld i.c u...,J J• ~ ""'"'Jal} lei.
RC\lnty HJrd,.•rt. «>ttw.orc, Jnd rroaJur•I cnnm•h th.ti ufcpurd
JnJ rr<><t.I J >)'1nll •nd lh dJU from mrcrnal nt r.icrnJl thtc-JI\.
M!Wricy hole ( rr.11...J hv .a <umh1n.a11on of 01\C' or more 1n1rm1"'rh
.:onhgurcJ "'" k.'l'>.
RC1lrity policy \ rbn rh.ar adJtt>-..t\ rhc rhrtt "'''" tlcm~nr. o( \\»
rem .._utll) 1 u1C1hJcn11Jl11-,. mtq:my.:and .11.11bl-1l11v.
wcurity token \ rhl"""' Jc .... < 1lu1 au1ht111 ... .a1t>. kgt11m•1< "~ ..
<U<=h '"' • ,man <Md e>r hyduon dt>-...c.
selection A conttt>I 1tru"turc 1n m•,dul.1r dN-1~n. tt t\ tht c<tmplt·
1100 Clt t\\tt t•r mtJf(' rr,Jt.t,.~ 'UCplo b.a\C:J t>ft thC' rnuh, ul .1 (t'\l t}r
cond1t1on.
.emanllc wtb \n "nlunno or 1hr .. cl- whrrc rhr d .... 11mcn11 1hn<d
on tbc lnccrnct h.11c """'""~' lmcanongi Jnd nol JU>l '1111.l\ (HT\ll
m~rkurt. 'M•nt<lllllc• <•lleJ \\th 3.0.
sequence I ht «lmpklmn or '''1'' 1n -cqucn11.1I nrJrr, nnc al1rr
another .
•cqul!nce check A 1ypc of Jarn •ahJorion dte\.k rlw "mrJ whcn thr
d.ua 111u\l hr ju 1to1nc prcJ1.•trtn1111(:d 'lt·c1urni.:t. II du,• 11,1.•r 1nu'1 tnttr
work nrdor. Ill m11ntr1cil -.c4ucncc. for example. then dn our or
sequence onlcr number 111d1\.JI., an error. I( 1he uk'r 11111'1 cnrer
tr01n\;u .. tuH1\ thronol,~.Jlly, fhcn .11nn~.t«-"l1un ~tth .1n ouc·<,fscqumcr
dare 1nd1Cdl<" Jn crmr.
sequ4!nce code •..;umbt:" ur kncn a"tllJlt-d 111 a '""'"''" orJc,
~lkf'k.C' «.1td('~ .. c.mt.at.n no aJJ1uun.iJ 1J1tornut1on 1>thc-r th.Jin .Jn i.nJ1-
00<W1 ot or<kr "' tnlf) 1n10 • •>~ ·
•.,,,..,_ l!i:D"......,'--- ,•._...__.""'........,... __...•........_ .......-.,.....nw...-.....,..._._.,..,........,............. ._..,...__.."'.....,.~
............_........_..,~_..........,.a.w...................-..c..........----......-...................--,,.......,,.,,...............

466
Glossary
sequence diagram A U.\11 d1JgrJm thJt show' the 11miog of tr<m>acoons
lx-n.ce11 ob1r<:h •<the)' occur during <rtcm exccu11on.
server Com purer on a chent/<cr»er d~1gn thot <upphe< data, process·
in~, .ind~" icn to i.:l1cnt \\ Ork~t.i1wn41 ,
senke An •rphu11on th.it monuur•, or h>tms on.• p•mcular pon.
service <!Mk A ~cntral11ed rt'><>Ur.c \Uficd hy Ir profes<iorutl• that
provi<ks u~r< "uh the •uppon the) need to do their 1obs. Also called
help desl..
service piack A mamttnan<< rcka"" •upph<J by wmmcrual wftware
<upplK'.rs.
servke provider A firm that offer< nut)Our<mg solu11ons. Two popu·
lar out50urctng opnons mvol•·e \5Ps and firn" that offer IBSs.
servic.,.orien~ed A <ompan) that prtmarily offer. information or
<er'1ces or .ell< g<l<ids prodm:ed by othct\.
significant digit code (.1phcr that do<ttngrnshc< items hy using a scnes
of subgroups of d1g1t~. U.S. r ostal Servkc tip code>, for cJG1mplc, a rc
sigmfic;int di11it codes.
slmuladon A tire<> rehcar,al for mer. and Ir •uppurt su ff. Organiza·
11011< typically include all procedure«, 'llch J• thmc that they execute
only ar rhe end of a month, quarier, or year, 1n their simulations.
sink An cxrern:il cnnry chnt rcccavcs thua from un 1nfor111Jtion ~ys te1n.
site visit A trip to .1 phy>i<.1l loc,11io11 w observe (I system 111 use at
another location.
slack time rhc amoum of nine hy which an e1•c111 can f>c lotc without
delaying the pro1ecr. The difference bc1wccn lnte>r completion tune
(LCTI anJ earlic\t wmrlcuon 11111e (ECI ).
soc-ial engineering An 1111ruder u\C\ ~<•llll 1ntrt.li.;11un Ct> N.un access
to • com 1urcT 'Y'tcm.
soft skills Commun1canoM. 11ncrpcr<0nal skills. pcrccpnvc ab1hties.
and crmcal thinkmi: nrc wit •kill._ IT prolc;,1onJls mu>t haw so&
"'111' •• wdl a. 1n.hn1<al ,kill>
software A program run hi rnmpu1r" for a 'p«1f1c fun<uon or 1ask.
Softwa,.., as a Service (SaaS) A model of •oftwJrc dcl1~ery m which
funcrionahl) is dcli1·cred on demand ~> .J nttwork·acccssiblc sen ice,
r:nhcr than as a tradmonal sot"' are apphu11on th.it"' dmrnloadcd
and msralled on rhc cu'tomcr's computer.
software encineerin1 \ )Off\1are Jc• clopmcnt process that srres~
solid design. tffr.:-ri1c 'rruaurt, ae,ut2tc Jocummt~tion, and careful
trsnng.
software license J\ lei;al agrtrmcnl that gives use" the rrglu to use
the software under ccrr.11n rerm~ and condmons.
software pacla1e Software that is pur,h.Jst-d or leased from another
firm. J\ comm<r~ia lly produ<cd w fl\\art prod~t. or fanuly of products.
software reengineerin1 U\e< .rnalylllJI te<hm11uei. 10 idennfy poten·
tial qu•liry .ind (l<'rforninncc 11nprmcmc1m 1n on information sysrcm.
software vendor Company thnr develop> ;,ofrwarc for >ale.
source An e•ccrnal ennry 1ha1supplies 1IJt.1 to ;111 informarion syscem.
source data automation 1\ popu1nr onli11.: input n1c-tho<l that <.:On1-
h1ncs onhne darl'\ entry and nuron1.ucc.I J,ita c~tprL1rc using input device'
such as magnetic dnh\ ~rrip~ or S\\ 1 1pc ~c:i nn c rs.
source document A form u;ed ro rcque.c and collccr input datn, trig·
ger or au1horite .111 input nu ion, nnd provide a raor1I uf the orr1tinal
transaction. l)ur1ng th<" input dc.;ign ~tAKC, rou dcvclor ~ourcr documc·nts
th:lt Jre easy to corn piece nnd lncxpcn~i' c.
spiral model A development model wi1h a scrie• of iterations. or rcvi·
sions, based on u'er fccdbJ<k.
spontaneous generation An unc,pln1ncd gcncr.111on of dJtn or mformauon.
Wi1 h respect 10 OfO,, prncts>e' c.111101 ;pontancousl)
gcneratt dJtn llo\\s-th<) mu\! h•vc an input ro ha.e an output.
rtal<eholder An)Ollt who,. affecrcd hy 1hc <omp•n) \ p<"rfonnJncc,
such as cusromcrs, employee<, suppl1e<', <tockhnldero, and members of
the com.munit).
rtand~ne \'rhen P<'r>Onal <Omputcr. first apl'<'•rtd m l.t'll< numhcrs
in tM 1990, user.. found 1hat lhl') rnuld run their own ''°rd
processing. spreadsheet, and daiaro;,: •pph<.tllnn>, "'1bou1 assi.untt
from the IT group, in >mode CJlled '1Jnd-alonc <Ompuung.
standard not:ation format A ttpt<\ClllJllOO th.it m.1k~ ~igrur1g 1Jbb
easier a.• it clear!) show~ a taMrs <tructutt, ftdds. and pnm•I) kc~.
star network A network design with a central device •nd one or more
worksmions connected to 11 1n a "''> that forms a ;tar pJttern.
start day/date Thr d3) or Jate when J t>'~ 1s 'lhcdultd to hq:m.
sta.te An ad1ccnve that d"'lenhc; an oh1c<t\ curn-nr >IJtU• (r.g .• a
srodenr could he• CURRF.:-.T. FUTURf, or rA~T m1den11,
state transition dlaeram Show< how an ob1e'1 <hangcs from one
srncc to another. depending on the events 1h:rr •ffc..t the ob1eu.
status flag In ~ tru"rured .. •prlu.:ati<>n de,·tlopnu.!rlt, Jn iu<lu:,ltor that
nllows one mod11lc to .;end• mes<.1ge II> '11101hcr module.
storyboard In an agile pro1cct, a simple graphic ori:ani1cr rhat helps
sysrcnl:s annlysrs vi~ u t\liz~ chc 1it:t 1u ~ of.\ projcc.:t.
strategic planning ·1 ht procc~s of 1clrn1ifymg l111111 1cm1 org.rniza·
tional goaJs . .s rrarcgic'i~ nnd resource.
rtrateglc plans The long rnngc plans rhat define 1hc corporate mission
and goal<. Typically defined hy 1op 111nnn11en1en1, w11h inpu1 from
all levels.
str.atified umple /\ -;c:t mcmc 1~ collected acro1\ functional nrcn1. For
cxao1ple. n certain perct*ntaye o( rranut.Ti<>ni from C\ICty \\<Ork .).hift, or
five cusromer\ from ea<.h or four"'' coJ._, <ClulJ he a .rrat1f1l'<l >ample.
structure chA.rt A top-.do\\'O rcpr~cntou ion of hu\1nr'S'S funct1nn\ Jnd
prOO!Sses. Also CJ lied an FDD.
structured ao•lysis A cradmon•I >) >tcm~ dc1dopmenr tt-..hn1qut that
USC'S pha ..... IO pion, JnJl)"IC, Jc<>1gn, llllJ>ltmcnt, Jnd SUJ'J'Orl •n information
sysrem. Proccs<es and dJt3 arc rreatcd "' <cpar•t• components.
structured bralnstormin& A group d1...:u"1on "hen- ca<h p;amcipant
speaks when n rs hrs or her rum or p3'5es
structured English A sub.ct of \landuJ I nghsh 1hat de"nbc. logical
J'Toce<SC' clCilrly and acrnr.ucly.
Structured Query Laocuase (SQL) A qutl') langua1<c ch•t allow>
PC users to communicate \\·1th stn·trs and n1a1n(ramt' computrrs.
structured walk-throush A "'""'' of a pro1c..1 tcJm memher\ worL.
by other memhc..., of the 1eam. C'.en<ralli. 'Y'tcms an.1l)'h rc•icw the
work oi orher S)"Stems analy.rs, and programmer> rev1<\\ the 11ork of
ochre programmtrs, as a (mm ol pttr rrvoew, Stru.111rcd walk·1hroughs
should rake pla"' 1hrolll\hour the SDI C and art CJllcd requirement<
revle'' ~,design review~. lode rcv1C\\'.). or tC)Ung review), df:-pt:ndmg on
1he pha<e in which 1hey occur.
stub testing J\ form of rcsnng ' 'here the pr~r.im 1 ncr s1n1ul.1rc' c<1ch
program outcome or result nnd displays n mcss:111c ro 1ndkatc whcrhcr
or nor rhe progr:un executed \Uc:cc,~fu ll }. [ach )lllh rt.!prfi4!n~ Jn entry
or exir point th:u will be linked l.ucr m :inorher progrnm or d"r.1 file.
subclass A further d1vi, ion of oh1ccu in n cl.l«. \uhc l n,~c~ .ire more
specific caregorlcs \\r1thin n cln'li.
subordinate module A lo\i.rer-level n1otlule u1 a ~ tru l.ture <.:ha rt.
subschema A view cif the dnrnha<r U\cd hy one or more >)Sl<nh or
users. A sullschema defines only thn<c pnrrinn' nl 1hc dntaha<e 1hn1 J
particular >f>ltlll or uocr need, or 1> allowcJ to"""'~ ..
subscription model A servict model th.u ,h.,11es J 'Jnablc le<: for an
apphanon basro on 1hc numhcr of u<cn or worl.'t>llOn< that have
acce;, to tbc appucauon.
successor t.ask E:ich of rhc concurrent tJ.<ks of;> rrcdtces>-Or t,1sk.
~ :B)Jf....,..~ Al._.,._...,.._.._.,. "t..) • ka.,-...i.'IUIJWll w""Jl'l.aflal.••'-*<lf .,... 0.-••,..,.._.....,..:,._",...Alrllflilfl,,...,........, -~,.._..,,.__.,....,.,.. ~,.~
......,...,.__ ........,~..-- .......,...,.......,.._....,....
~ ........
.._.......,..,.....e.... ~ ...
......ih.,~•*...,.~~c....,,_~,

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
Glossary
467
summary report A reporr u~ hv md1v1duals at higher levels m the
ori:•mzatmn thJt mdud~ le~~ deu1I rhan rcpom used by lowtr-levcl
c-lnplo) e~.
supud;us A mnrt jlencrahud •aftgOI') 10 wh>eh obiter< m.lf belong
i<.g.. a 1'0V[L d••» n11ghr h.:long to• •u~rcbss called BOOK).
supeNSer account A lc>i:m a<counr thar allo\\ > """'nuall) unre­
•tncted JC"'°'' 10 the a('l('lh•JllOn.
supply chaln .\ trJdmonal s~·,tcms dtvclopmcnr !«hniqll<' rh•r uses
i>lust• 10 plan. •n•I) u:, design. 1mplcmtnt, 111d supporr an infocmanoo
>) >tetn. Pnxcs<e'> and dar~ att trearcd as scpaure components..
•upply chaln manapment (SCH) The <oorJ1nauon, inlt"jtrauon,
and man.1gemen1 of matcri.11<, inforinanon, and financ" a< thty mon
from suppbc" 10 cu•tomc"· borh '"rhin and bct"CC11.:ompanies. In a
corally mrcgr>red <uppl) chain, a customer order <-Ould cause a produc·
tion pl•nning ;y.rcm ro "hedule a "ork ordcr. which m rum could
tr1~cr a coall for tcna1n ran~ fron1 ont' or n1orc suppht"rs.
survey A d0<.ument conrarninl\ a number of standard questions char
can be .cnt tn m.111y ind1v1duals. Al"' called a questionnaire.
swim lanes In a hu<1ncs< prncc'< d1agmm, the m'trall diagram is
rnlled J pool and 1hc dc>ol(narcd <U>lomer ""'are called >Mm
l ane~.
switch C<:nrral nCt\\'<Hkmg device in a''"' net\vork. wh1<.'h manages
the 1mwork anti°'" a> n •ondui1 for all 11e1work rraffic.
switchboard The use of command hurrons m 3 user interface to
enable ll><rs ro 11avig.11e a •r•iem anJ ><!l«I from groups of related
casks.
SWOT analy•is An cxamma11on of a comp•n) 's >crengths (S), \\eak·
ne"c' (W). Of'lf"lrlllll1t1e<> (0). and rhrc:m (T).
syntax error Programmmi; l.inguai;c gr.immar error.
SysHL A dl3lc.;1 of UMI 2, u<cd for representing reqwrcmtnts (and
other thmjl>). pnmMtl) 1n ~IBSF .1pphca11on_<.
system A >el ol rclarcd cnmponenrs rhat produces SJXC1fic results.
system <>dmonlstrator A pcr<nn who rs r~pom1blc fnr the CM and
maim<nancr of an oq:an1tat1on's compurer nerworls.
system architecture A 1r.10,lat1on of rhe logical do1gn of an mfor·
mauon >)>rem mto • ph)>ical ,rrunun> 1ha11ndude. h:ud"are •
.oft\\ ue. nec--.orl. 'UPJ><>rl. and pr0<ernng mnhods.
system boundary 'ho"< whar i< mduded and .-eluded from a S)'S•
cem. Depicted by a sludtd ttcranglc in use cast diagrams.
system ch;on1eover The pro.;c;. ol puning rhc new rnfocmarioo ~>tern
onlme and rcunng rht old <)'Stem. Changro\'cr can be rapod or
;low, depending on the method.
system deslsn specification A J0<.umem thar P'""""" the complete
dts1gn for rht new 111forina11on •>·<rcm, along with dcca1lcd costs, staff·
mg, and '><hcduhni: for complermg rh ~ next ~OLC pliase. systems
1mplcmcnm1un. Also c.1lled the rcchmcal drs1gn spcc1fic.uion or the:
dct•ilcd deMgn ~pcc1f1.:a11on.
system documenutlon A dc"riJ>tton of n 't"em·s funcciom and
how rhe) nrc unplcmcntcd. The »na l)sr prepare< mo<t of the system
documenrnt ion d11rin11 rhe ~ysrerm analysis and systems design phases.
!>y>1cm documemJ11on meludc\ J,11a domona ry entries, DFDs, object
models, >erecn la)·ou1', source document;, and rhe sysrems request that
iu11inttd the prtJjet.1.
system prototyping l'rnduci1111 .i foll-fc•rurcd, working model of •he
infotmnrion sy>1cm ~'"II de' eloped.
system requirement A char.1<1em11c or feature that mu•t be included
1n do 1nforni.\ntin ,y.,rcn1 to <iJn'f) ho4iinc""i<i rrqu1rrmcnt'i and be
JCcep13blc to U>Ct>.
system requirements doc:ument A <locumt-nr that conram.s the
rrquircmen1> for rht• new 'Y<fem, dt>Senbt-<i rhe akernahHS that were
~ons1drreJ, .ind make>" >p«ifi, ra:ommenJauon to =i;emenr. lt i>
the end rrodu<! of the \)'<ICl11\ ;tn;ll)'"\ pha<e.
system software Pr()jlr.lm> tha1 mnrrol rhe compurcr, mcludmg the
oper.rnng sy<tem. device driver. thM communrcatc w11h hardware. and
lo\\ -le>el u1dt11e..
system tMtins A forin of tcurng invoh mg •n cnurc 1nform.111on <) •·
rem and UlClud.'S •II t>pical prou:>SIDJl 'flUJllOnS. Dunng • <)>ltm test,
users cnrcr dara., including s.implts or Jtrual or live d•ra. perform qu<-­
ncs, and produce repon< to <imularc actual opcranng condmons. All
procnsmi: Option> :and ourpui. in: -.ril1eJ b) u~" and the IT pro1ttt
dtvclopmem ream ro ensure rh~r r he \)\ltm fun.:11011< cnrrtcrly.
systematic sample A ;ample Wt O<CU" at • pttdettTmrned pcnod1c-
11y. For eX;1mplc. e\Cty rcnrh cu>1omcr rc<:orJ 1111!;111 be selected as a
~y\tc:manc ~.tmplc: for fC"\·1cw.
system• analysis and dcsi&n The p~S of dcvdopong mforination
sy.,cms thar cffccfl•ely u>t hJrJware, ;olrwJrc, d.ra, proce<>>t•, and
prople to supron the company\ bu""°'' ob1C'<11vc,.
systems analysts phase The ""'ond SDLC pha.e. The purpose of th1'
pha<c ;, 10 build J l<>itlCJ I model of r he new 't'tern.
system• an;alyrt A J>C'" who plan<, analy1c5, and 1mplemcnr< mfor·
marion sy,tem>. They mO) work 1nrernJlly within a compan) 's IT
deponmenr or I~ l11rcd hy .1 ct1111r.111y "'an indcpendtnr eon<ul1Jnr.
systems deslin phase The rhird Sl)I C: pha<e. TI1e purpose of S)•tems
de>1~n ;, Lo trcalc a blucprim for rhc ne\\ •Y" em rhat will ,ati,fy all
documented requirements. wlm hcr rhc sy<rcm i< heing developed in·
house or purchased n< n paLkngc.
systems development life cycle (SDLC) Ac11v11ics .md foncuons
that systems developers typically perform, rogardle<s of how those
<1ctmhe> and foncuon' fot mto n parucular metho<loloi:y. The SDLC
model mclude• five pha<c<: ( I ) '}"ircm< planning, (2) sy<rems analyst.,
!3) sysrems desil!Jl. (4) •yne1m 1mplcmenrntion, and (5) systems suppon
and "'uiriry.
systems implementation phase The fourth ph.1<0 of the SDLC. Dur·
mg thb ph.uc. the nc" •~>Wm r> rnn;tru~c~pr()!lram; are IHltltn.
tested, and documented, .md rhc S)StCm 1< onnallcd.
systems plannlns phase The f1r<1 pha<e of rhc ~l)l C During rhi<
ph;ise. the sy.icm~ proj<et i:ct' >1aneJ. The pro1n.t propo>31 is e,·aJu·
atcd tO dcterinmc ff< fca<1h1llf). The prOJCCI managemmt ('llan IS
formulated." 1th the help of CASE 1001• "here appropnare.
systtmS prosrammer A pc.>n \\ho \:O"'-entrJt~ on oper.1t1ng S)!lo~
rem software and uulmc-,
systems request A forinal appeal to the IT de('l3rtment that
~ribcs problems ot Jcm.J <h•n11<> man mformauon sy.,rm or
bus111ess process. h m1gh1 pror<>~ enhanctmen1> lor an e-1mng
sysrem, the correcuoo of problem>. or rhc Jc, dormem of an ennttly
oc-w ~)'"tern.
systems request A formJI rcqu<>t rn the IT dcp•trtmcnr th3t descnbes
problems or des1tcd cbangn m Jn 111lu11na11on sy.rcm or business proctss.
h moght propose enhancement< for an cxis11ng <ystt'm, the
correction of problems, or the de,clopmcnt ol an cnnrely n"" >ysrem.
systems reYiew commjttee A Htuup of ke) nl~n::i~er\ 01nJ u .. e~
respon<1hle for evaluatm11 <ystem• reque<r<. The rerm compurer
resoltrl;C!, ..:01umjttcc i ~ t.01 n ett nl~ ~11 ... o u~td.
systems support and security phase Ouru111 rhe <y<rems support and
securiry phase of the SDLC. 1he IT scoff mn1n1.1in•, enhances, and pro-
1a:rs the '>'~ rem.
table l:ich file or rahlc con1,1in• tlar.1 ahour people, pl.ices, rhmg<, or
events that incerncr with the 1nformauon 'Y<tcm.
table design ~pecifie• the f1elJs anJ 1d<n11flr. th< primary key in a
particular t,1hlc or file.
tampe....,,,ident c"'" A cJse dt<igncd to show any ottcmpr to o~n ot
unlock the ca~.
tangible benefit. P<h1me ou1<<m1C' rhar can he meJ<urtd 111 dollar<.
They can result from a de.:teasc 1n cxpcn'e" an increase in revt'nues. or
both.

468
Glossary
Qngible costs l:xpcnscs 1hJ1 have .1 'l''"'llL dollar value. E.xampl<S
mdudc employee s.ilaroes and hardware purchnscs.
task Any worl 1hat has a bq:onnonit and an C11d and requires che use
of u1mp.any rcsour.rs mdudon11 pcoplc, ume, amVor monci- f'<amplcs
include conducting • <cnes of ml1'rv1<""•. designing a rcpon. sdccnng
sofn,Mc, wamng for the Jch•er} of equipment, ;inJ crain1n11 u~rs. &e
also actmty.
task box A <omroncnt of J Pl RT/CP\I chan th.it cootams 1mponao1
.chcdulmg anJ duuuon 1nlom1anon •bou1 a t•>k. Each task ma proj·
cct 1s rcpresert1ed h) 11\ <mn '"'ho' 1111hc Pl RTK.1'111 <han.
task croup A IJSl rh.11 rcrrcsent< sc-cral 3W\ 111es.
task ID A number or code rhar uniquely 1dcnnfies a rask.
task name A brief dcKnpri'c nome fo1 o task, "hich docs nor have ro
be unique 111 the pro1«t. for complc, a 1a-k named Conduct Inter·
VleWS might appcJr m <cv<ral pha~c< Of the projeCt.
task pattern A logical sequence of 1.1'1" m a WBS. Cnn imol"e
""quenll•I ta>k>, 111uh1plr """'"'"' ,,,..k<, and muluple prcJcce»or
tasks.
technical feasibility When an orgnm~rion ha~ the resour<Xs 10
de,·elop or purcha\et in'!.CJll, .ind opcr;.ue 1he S)''\ten1.
technical support Ted1111cal bU(!l>urt "nccc'>sary to sup1><1rt the wide
varicry of IT i.y.icm; nnd u>Cr\. Ir indudc• <ix main funct.ions: npplicauon
<levelo11111('11t, ~y\tc1n1i ~urpon, ui,er tturrorr, d.unh.•).e
admini~rrruion. nct\vork Jdm1111'\tr:tt1nn, and \veh ~uppon. These func·
tion> overlap cons1<lcrJbly and often hnvc different nnmc.> in d1flercnt
COITI p<1 111t"S.
termina.tor A D~D <ymool rh.tt 111d1cacc< a dar.• ong10 or fi 1u l desrinarion.
Also called nn c'rernal cnuty.
test data The dara u~d 111 unit testing. Trst daro should cont:lin both
correct data and crronr<1u\ dMa .rnd <hnuld IC\I all po•mhlc <1tuat1om
[h;n could occur.
test-driven development (TDD) An XP rnn<epc thar unir re"s are
dn1gncd before codr 1> wnnrn, focu<ing on C11d ~•ulrs and preventing
ptO!{rammer> from >trayll\I\ from rf\eir !(Oal•.
test environment The tn•ironrmm rhac anal~"' and program=rs
uSC' 10 dt .. tlor and n1.;i1nta1n prt~rams
test pW> A pbn <k<i1gncd h) • <> 't<m< an~I) ,t thar mdudrs tcsr <Leps
and lt:Sl d:tt.l for uuegr Jtion Ut~un~ JnJ ~)')letn tc~11ng.
testinc review Stt struC1ur.O "alk-rhrough.
thick dient A ,vs1em dc>1tul 1ha1 ltxJI<> most or all of the arplication
proceS<mg loi.1c 01 the chcnt. Al<o called a far chem design.
third normal form (lNF) A record drs1gn 1s 10 3:-\f 1( ir j, m 2:--1'
and 1( no nonley f1dd "dtpcnJ~nt on another nonley field. A nonley
field IS a field 1hat "not a cand1datt key for the primary key.
third-party software An apphca11on that i; not de•elopt:d in-house.
threat In mk management. an 11nernJI or tMernal or e><ternal emiry
th.at could cnda11gcr an a.)~t't.
three-tier deiien In a thrcc·ricr <lc<111n, the "'er intcrfocc runs on thr
client and tbe data i> >tored on the .erver, 1ust ns in a rwo-rie.r design. A
three-tier dc<111n nl<o h,1< a 1111ddlc lnycr hc1wccn 1hc d 1cnr .ind <ervcr
rhar processes rhe client requc'r~ and 1r,in,lnte1 rhem inro dar.1 access
commands chat can be under.1ood <llld carried our by rhe sener.
throughput 1\ mC'•''urC"mcnr o( r1t.ru.1I -.y~1c 1 n pcr(nrn1:1ncc under specific
circumstances ltnd is affected by ncrwork loads and hnrdw<HC
efficiency. Throuw•pu1, hlc b.mdwidth, 1s <xprt>><d as a Jara rramfrr
rare, •uch •< Khr>•· Mhp,, or (1hP'·
throwaway prototypln1 See dc<ign prorotyping.
tlchtly coupled lf moduk'S are tti;htly rnuplcd, <;ne module refers 10
Lnte:rn.aJ l~tc ~ont.uned in Jnc>ther nltKlulc.
toggle button A C..UI dcmcno u<ed to rrprc<enr on or off scarus.
Chckmg tne togglr bun on "'itches ro rho orher •rarus.
toolbar A GUI tlement that i.:ont..lul~ icon\ or hutron~ char rtprtsenr
shom:urs for cxec11nng common command<.
top-down approach A design approJch. :11!>0 called modular design.
"here the S)~l•rn• arul)St dcl1n<"> ti~ O><r•ll ohjnm<"> ol the ')'tern
and rhcn breaks 1hcm down mro •uh,J<t<m• and modules. Thi•
breaking-down prOC<>> 3M I> <•llcJ romCIOllm!(.
tot:al cost of ownership (TCO) A numhrr used m ••<e••1011 cow•,
which includes ongomg supron and mamcenan<e <O<h, •• well a<
acqua..s1non ro~t~.
totals zone If a form h.u data totab, chev "111 arpcar m rhi< <ccnon
oi the form.
traeeability The abwt) co follow a ~quirrm<m b.tck\\ nd to If> ongins
and forward through rhe 5()1 C to linl dt"1gn documcnr>, c<><k
fragments. ond rest arufatrs.
training plan .4. .s.ucce~~ful 1ator1n.i11on !1-)'ifem require' rra1n1nJt (or
users, managers, and IT .raff mrmt>cr<. Ille rnurc <r•rem• dr»clopmrm
effon can depend on whether or no• people undeotand rhe •)>tem and
know how to use 11 effecnvel)" The 1rainm11 pl.111 "•document 1ha1
details thc>t> requirements.
tra.ln·the·traJncr A 4itr01tt~) where one j.\.roup or u'ef\ h:i1i heen
trained and can assist others. Use" of mt lc.1rn more quickly from
coworkers who share common expcricn..ce and job responsibilities.
tra.nsactlon model i\ scn•ice model !11J1 dtn1'!4C>" vnrn1hlc fee for an
application ba!iOO on rhc volu 11c of tran)l\Ct1on1' or opcrarion' per·
formed bi the applicauon. Al>o c.1llcd • u'Jl\C model.
transaction processing (TP) systemi 011<ra1m11.1I 'Y>IClfh ll~<'<l IO
process da) -m-da) recurring busme<~ tran-.c1111n,, such "' cu<tomer
billin11.
tran.sferenc.e One ot (our n~k control stra1c~1cs. In (r,1n\tcrcncc:. nsk
is sh1fred to anorher asset or party, such a• an m•urance compan)'.
transparent A ocrwork is rranspJrcm if J u...,r SttS the dara as 1f 11
Yt'ert 4'tored on h1\ or her O\Yn worL~tJtl<tn.
transparent interface A user mtcrfacc 1hat u>ers don't really no11cca
user-fnt'odlv imecfJcc rhJI Joo no< dmrau the u"'r and calls no
attcnuon to ,;<elf.
tunnel A secure network ronnecuon c<.rabhshcd bcrwcm 1ht client
and the access po1m of the lcxJI tmran<1.
tuple A tuple (rhyme• with couple>. or rrcord, 1s a <cl of rclarrd fields
rhar de<enbes one msr~occ, or mcmhcr of an ennri. •u~h as one cus
romcr, one order, or unr prodU<.I. A ruple m111h1 h3\C one or dm:<.'1•> of
fields, depending on what mformauon 1< nttdcd.
turn..round document Outpul documt-nt tha1 1s later entered back
into the same or another 1nfonn01uon S)Siern. A telephone or unl1ry
bill, for example, m1ghr be a rurnaround documcnr pnnred hy the
compan)"> b1llmg >)Stem When the hill" returned wuh paymeni, 11 1>
scanned u110 the company"< o.cnuim rc.:eivahlr S)<t<m en rt•cnrd rhc
pa)'mem accura<cly.
turnaround time i\ mca;ll~ .1ppl1cd 10 (Cnrral11cd haich procr"'mll
opert1nons, such 1\'i cu~tomcr h1ll1ng or cr~du Cilrd ~rarcnlcnr flrOCCS'i·
ing, Turnaround time mea•ure"' the time bc t w~rn >11bm1mng a request
for informa11on and 1hc fulflll111cn1 of 1he requc<t. T11r11<1round 11me
also t-an be used to mea;ure the q11al1r) of IT support or services by
n1c:asuring the t1n1c from .1 user rr:quc!lit fC1r ht:lp to the rc\olution of the
problem.
tutorial A series of onlinc i111era<11ve le;sun< that presem materinl and
provide a dialog with u<rr<.
two-tier design A network dc;1i;n where the 11~r mterfacc re~1des on
lhe client, nU dJta res1JC.!. on the servcr't and che appl1t.:.1rion logic can
run c11hcr on rhe str\'cr or on the client or h<' d1"1dcd hcrwccn the chenr
and the ser,.er.
unencrypted Data that i> not encryprcd.
Unicode A ~i.ri,dy recent coding n~chod rhar rcprc•C11r< characrers
as integers. Unlike EBCDIC anJ ASCII. "h1ch use c1gh1 h1r. for each
(....,..... J:gl( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.,,._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,....

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ...,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~----···---~~-.,.-"~ ...........--......
Glossary
469
charact<r. Un1wdc rcquirl"S 16 b11, per charactc~ which allows 1t to
rcpr=nt more than 6~.000 unique ch•ucters.
Unified M~linc Lancuace (UML) A widely used mcrhod of ..-1sual·
LLUl8 and do..umennn1t ;ofmarr '>''<rm design. U\{L u.e"
ob1c.:1-onemcd Jcs11tn wn..ept<. hm u is mdcpcndmt of any spcofic
programming language and can h..· u..nl to d~hc busan~ processes
and rcqwtcnu:nr> gcncralh.
unlnterru.ptlbl• power supply (UPS) &ntery•po\\cred b:idup power
wun.:t th;ic en.J.hl("\ <>ptr.1uon~ cu (Onunue dur1n1t shorr .. rcnn p<>\vcr
outage<, •nd iurgC>.
unit tutinc ~ l<'iflng of an ind1ndual program or module.~
ob1~thc 1> to 1den11fy and dmunatc e"ccucion error> thar could cause
the pmgram tn tcmunatt •hnornully •nd lo11ic errors that could have
l:><cn mmcd dunng dcik ch«k1ng.
UniYersal Security Slot (USS) C.m he fastened t0 a c•blc lock or
laptop at.rm.
unnormalized A re~.cud th:it t:.onr31n' ;t repeaung group, which means.
th.1t a >1ngle record h,,, multiple oc.urrcncc~ of a parncular fidd, w-1th
each o..-.:urrencc ha\•mg difforem v•lue..
unstructured brainstorming A group discussion where any partici·
pant l.lll ~1>e:tk ru Jll) 111nt.
usability In mer 11urrfocc dc;ign, include< """r •ati•facuon, •upport
for businc_, fu1mi on~. nnd ~y>tcm cffect1vcncss.
usability m<!trlcs Darn thar mrcrfoce dC'lignen cun obrnin by using
M>ft\\<Jtc that CJ.I\ rt."r..ord .ind 1nc3i.urc u..cr 1nreracr1on.s \\'Uh the- .sy!rlotC.-m4
usaee model Set• tran>ac1 ion model.
use case description A dc-.nption in UMI ch•r documents the name
of the u<c '·'"'· 1he .1ctor, .1 dc<erip11on o( the u<e case, a <1cp-by·stcp
Im uf the ta.b requ1tcd for >11..:CC'->ful wmpleuon, •nd other key
docr1puon; •nd a;;urnp11011,.
use ca.se dla1r~m A \l)UJ.I rcpr('\.entarton thdr 1llu')ltd.tCS th~ tnrcraction
between uier. and the mformauon •y•rem m UML
use a.se Reprei<nts the nc~ in a •pccific busin~ funcnon or proass
ID U)',1L.
uffr appllatlon l'ro1:um, th•t uuhic StJnd.1rd busin~s software.
•u...h •; M1Cro..oft Olh~e, "h1ch ha< been configuttd 1n a specific man·
ocr to enhance u;cr produ.tt\lty.
user deslcn phaM In th" pha\C, u...,n interact with si >temS :malis"
md de' dop moJd, and pro1orypes th21 repr~m aU <ysrem procases.
output>, •nd input<
user documentation ln~rruct10n\ and 1nfonnanon ro users "'ho WJll
mteracr '"th the si;tem. Includes u<er manuals. help screens, and
cutoriah.
us<!r interlace (UI) fhe mcch•msm 1hrough "h1ch the u5C'r intcratts
with the 'Y"Cm. The mtcrfocc can 1-e graphical, te•ru31, aun1l, or 3
combmntion of different modC'I of 1ntcr:icrion.
user Interface Jn,Judt" ...:rcen,, C<)n11nands. controls. and features
thlt enoble u!>Crs to 1111erJct more cffow .. dy w11h an apphca11on.
u1<!r productivity syotems Applirn11ons thar l'rovide employees of all
lo"d< a wide arr.1y of cools m m1provc 1nb performance. fxamples
include ctnail, word proi:es'iing, grn ph1c~. and ccunpan) intraotb.
user rights U><r·•peufk privilei:es thot determine che type of acce>s a
u<cr hn, to a data ha«, file, or dirc<1ory. Al<o Cll lled permission<.
user stories In nn agile pro1oct, a «'I of more rtfincd rcquiremcms
dcmcd from fc.iturc;.
user story In agile development, J ;hon, >imple requiremcnrs ddini·
t1on pro\ 1Jcd h) the 4-U\tUrne-r. Pro~r:tmn1et\ U\e u-.er !.tnrlh to
dctcrm1nc a prOfC'~l·~ rcqu1rcmcnr~. prtor1n~ nnd ~ope.
user trainfnc packace The m31n oh1cmvc of a u~r training package
1s to ;how u~rs ho\\ the s~-stem can help them perfonn their jobs.
user-centered A t<rm th.JI md1catc<, the pnmary ftx:u• is upon the
u~r. In a u5Cr·ccntercd sy<tem, the dmincuon blurs between mpur.
ourput. and tbt interfo«' it!>Clf
user'> Stll.eholJ..r. ""'de and out>1de the i;ompani "hu "1ll 1nteracr
mth the S) <tern
validity check A ryp<" of dJt.l validation check that 1s used for data
1rems that mU!.t tu\e ..:~man '.t.luc>. l·or eumple.1t an tn\enrory !ty~·
rem ha< 10 v•hd 1t•m d""''• then an) input llt:m tlut doc< no< match
one of rhe ,-ahd dJssc• will foil rhe check.
validity rules Check\ that are •pphed ro daD elemenrs when d.1ra 1s
<mered to cmure tlut the \'3lue entered 1> valid. for rumple,• »!tdJt)
rule might require that Jn emploicc\ ;.1l.ir1 nmnbcr he "uhm the
emploier< predefined ran~c for that po<inon.
value-added "'seller (VAR) A fmn that cnhan<e> a <Ommetttal package
hy addm1t cu;rom le•wrrs •nd wnfigur111i:; 11 for a panicular
mduscry.
v .. nion control The proc•>S of trnckmi: si·stcm releases.
vertial applic.atlon A •<>ftware pJckai;c that hu> been developed to
bandle mformauon rcqu1rcmc1m for a ;pcc1lic t)pc of bu<ine<S.
vertlal system A sy<tcm dc<igncd to ntret the unique requirements
of 3 specific bu;ines> or industry, such ll~ a wcb·based retailer or aurosuppl)
store.
virtual private networl( (VPN) U>e' a pu bl1c network 10 conncc1
remote users securely. Allows n rtmme chenr m u<e n spccinl key
exchange thJ1 mu-;t 1"' authenllcJt«I by the VP!".
vulnerability A ~e<.:urity \\i l'JL1u.>~~ or ,oft ~1'>(>1.
waterfall model !'he tradmon.ll modcl of •oftwarc dc,dopment.11
graph tl1at depicts the rc;ult of each SOI C pha<c flowing down 1oto
the next pha"".
Web 2.0 A sc.;ond 11enera11on ol the \\cb thJt enJbb people 10 collaborate,
mtcracr, and •harc mfornuuon much more dynamically,
based on conrinuouslv ••~LIJblc u;cr •pphcauoni ucher 1han sraric
HTML web pJJ.ih. lnterJUl>r expcneri.;e "a h.tllmarL of Web 2.0.
webast A onc-"'*'Y rr.1n,m1ss1on of 1n£orm.;auon or rr.11n1ng marcr1~
such as a Web1nar ~''°"· a,·J1'3hk on dtmlnd or for a spcctftc pcnod
to onlinc panic1pants
web-centric A .. tr•t<g) or aprroa~h tlut cmrlume< a high dqtrtt of
mtcgranon with other wrl>-h.ivcd ~on1roncnt,. A wrl>-cmrnc arch1t«·
mre follow• Internet M'11\ll protocol, and enables a compani' ro
1nlqtralc 1hc nC"w applu;auon uuo It\ t<nntmcn.t' ~fr.Jtqt).
we.binar An lntrmt't ·h~\td 1ra1n1ng "tt'.S\1on 1hat rrov1des ;in 1n1tr-.ac·
nvc c~iienmcc. The word u't'bm.ir comlun~ rhe words u1'b and
sn,uniJr.
weight An llllporta.nt multtpUe:r that n1.lnajtt" f:h ... tor inro csr1n1;,ire-11; 'o
thei can be analyzed.
what-if analysis A kJturc of hu<me'< iupporr <yitem' thnr allows
analy>i> to define anJ J"ount for a wide vancty of 1'SU<> lindudmg
issue' not rnmplctdy drfmcd).
wide area network (WAN) A network <panning long d1<rancc< rhat
can link users who are <ontinenrs aparr.
W i·fi Alliance A 11onpro f11 imcrnatlnn:tl .1>so.:1orion formed in J 999
10 eenily m1ewpernh1lity of wirclc" 11 rrwor~ product< ha<cd on IEEE
802.11 specifirntions.
W I-Fi Protected Access (WPA) A common method used to secure a
wireless network. Tht' .1ppro.1ch re4 u1 rc~ e.\l..h wircle'" client be con·
figured manual!) to use a special, prc·~hnrcd ~ ey, rather than kei pairs.
The most recent nnd more secure \tri1on 1s WPA2.
wild A web-b.tsetl r<)X»itor) ol 111formn11<>n 1hnt •nyone c.tn n.:c..,,,,,
con1r1bute 10, or mod1f1.
W i-Max IH~ H02. lfl <r<:<1f1<aflon<, which ore c><p<"Ctro to enable
wireless multtmedia •pphca11on> wuh n r.rni:e of up to 30 miles.

470
Glossary
W ired Equivalent PrlVllcy (WEP) Onr of rhe r.orltcst methods used
to ""'urea wire)..,., nrtwork, >Upcr...,J•d b) WPA and WPA2.
wireless access point (WAP) A central wirelt-> de' re.- that
pro' 1Ms nctworl.. ;er> ICC> 10 wircie>S chenh. 1\1,0 c•llcd an access
point.
wireless lldellty (Wl·Fl) I Jmil) ul popular I [f.E I.AN w1rcb> net·
worlmq,\ standards. aho kno" n J> 802.11, mdudmg 802.1 la, b. g, and
n. 802.11 n is the most recent .iandard. 802.1 bc and 802. I bd are
proposed new standards.
wireless foul area network (WLAN) A " 1rclr•s network ttiar,.
rclan,dy mcxpcr1>1\'e to install and " well suued to workgroops and
u!.er~ who .ire not :.n~hott:d tt• ;i \ipt."<.:tfi(. d~l: or loc:111on.
work breakdown structure (WBS) A proJclt hrol en down onto•
sen es of smaller tasks. Su alsn Gantt chart: PERT/CPM chan.
worst-case estimate: The most pess1m1stk outcomr.
WPA2 A "irckss se<:Urit) srand.ud bdscd on 802.1 l 1 th•t pro• ,.le, a
significant IOC~.JSC '" rmtccnon O\·cr Wl p and \'(·fl,\.
XY chart A tool used by systrm analy<O to i;rarhicall)· ~how the cnr·
rclaoon ~twc<n rwu v>.nablcs. Alw callrd a "-•tl•r diaf,Um.
Yl K issue A problem f._.d b1 many form, in the )·cu 2000 heuu"'
rbeir computer sysr.-ms used only rwo d1gm to rcrrcsenr rhc year: most
d3res no\\ use a four-d11v1 form,lt for tilt" 1·CJr (YYYY.\1\IDD t.
Yovrdon A t}fX' of >ymbol SCI that" used m l)l·l)s. l'roe<<sc<, d•t•
Row s, da1a store<., and external rnntir< each ha Ye a unique ~ymbol m
the Yourdun >) mhol ><t.
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

INDEX
1:1, 280
l:~l, 280
lNF. See first normal form (I NF)
2NF. See second normal form (2NF)
3NF. See chird normal fonn (3NF)
4GL. See fourth-generation language (4GL)
802.J J, 338
802.11 ac, 339
802.1lb,338
802.1 li,427
802. J Jn, 338
A
abbreviation codes, 298
absolurc date, 304
acceptance, 421
acceptance rc~t~, 372
access poinr, 339
action codes, 299
activity, 78. See also task
activity diagram, 193- 194
actor, 187
adaptive maintenance, 404, 406
adnurustrator account, 430
agile methods, 17, 18,22-24, 113-114.Seealso
agile mechods
advantages and disadvantages, 114
application developmenr, 357, 367-369
Airbnb, 8
Alexa (Amazon.com), 15
alias, 164
allocated baseline, 4 14
ALM. See application life C)•cle management (Au\.i)
alphabetic codes, 298
Ama1on.com, l 5, 53
Amazon Echo Dot, I 5
app,8
Apple, 15, 207, 229-230, 425
Apple Keynote, 386
Apple's rind My iPhone app, 425
Apple's iOS, 232
Apple's Mac OS X, 415
Apple Xco<le, 370
application, 319
logic, 147,325
~ecuriry, 429-432
server, 325
software, 5
systems architecture, 319
application development, 356-359
agile, 357, 367-369
object-oriented, 364-367
structured,356-357,359-364
system design review, 356
tasks, 356-357
tools, 357-359
application lifecyclc management (ALM), 24
application service provider (ASP), 208-209,
331
applications programmer, 408
Apprivo, 89
archived, 4 12
Ars Techn ica, 126
artificial inrelligencc, 15
ASC II, 303
ASP. See application service provider (ASP)
asset, 420
associative entity, 282
ASTQB foundation level certification, 441
ATNl. See automatic teller machine (ATM)
attack, 421
attributes, 183, 276, 365
audit fields, 305
audit log files, 305
audit trails, 245, 257
auchorization zone, 246
automated fax, 253
automatic teller machine (ATM), 254, 332
automatic update service, 430
availability, 4 J 9
a,roidance, 421
B
B2C (busine~s-ro-consumcr), 8
back door a track, 422
backup,305,435-437
backup media, 435
backup policy, 435-436
balancing, 159, 160-163
bandwidth, 329, 4 16-417
baseline,414
Basic Service Ser (SSS), 339
_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ··----~~-.,.-"~...........--......
471

472
barch, 254
bacch concrols, 244
bacch input, 254
bacch processing, 333
BCP. See business concinuit)' plan (BCP)
benchmark, 218-219
benchmark resting, 4 16
besc-case escimate, 79
Big Ten University, I 63
binary storage format, 303
biometric scaonmg systems, 423-424
BIOS-level password, 424
bits, 303
Bizagi Modeler, 194
black box, 14 7, l 84
black hole, 149
Blockchain technology, 52
block sequence codes, 298
biogs, 252
Bluerooth, 339
body zone, 246
Boehm, Barry, 24
Boeing, 11
Bologva, E., 232
boor-level password, 424
bortom-up technique, 77
BP~1. See business process model (BPM)
BP.MN. See busincs~ process modeling norarion
(BPJ\IN)
BPO. See business process outsourcing (BPO)
brainstorming, 125
bring your own device (BYOD), 34
Brooks, Frederick, Jr., 94
Brooks' law, 94
BSS. See Basic Service Set ( BSS)
budget issues, 9 5
bug tracking software, 374
build or buy, 203
business, 8-9
B2B, 9
B2C, 8
case, 47-48
continuity, 436-437
information systems, l 1- 15
ln rcrncr mode I, 8
logic, 147, 325
modeling husinc~s operarions, 9-1 I
process, 9
profile, 9
rules, 19, 147
skills, systems analysts, 30
suppon sysrems, 12-13
business continwty plan (BCP), 437
business issues, 95
business model. 9
business process diagrams, 130
business process model (BPM), 9, 130, 194
business process modeling notation (BPMN),
10, l30
business process outsourcing (BPO), 208
business profile, 9
bus network, 336
byte, 303
Index
c
C#, 201, 367
C++, 22, 181 , 367
calendar control, 24 0
Calendar view, Microsofr Project, 92
Cameo Systems Modeler, 26
candidate key, 278
Capabilicy Maturity Model (CMM)•, 353
Capabilicy Maturity Model lnccgracion (CMMI )~,
353
capacity planning, 4 17-4 19
cardinality, 190, 283
cardinality notation, 283
career opponunities, system~ analysts, 32-33
Carnegie Mellon Univer~ity Software Engineering
lnsritute, 353
CASE. See computer-aided software engineering
(CASE); computer-:iided ~)'~tems engineering
(CASE)
case for action, 68
CASE cools, 24, 47
ERDs, 283
UML, 195
category codes, 298
CC. See change control (CC)
certification, 3 1, 44 I
change conrrol (CC), 411
character-based report, 248
characters, 303
child, 185
child diagram, 157
CIA triangle, 4 19
cipher codes, 299
Cisco Systems, 377
certification, 442
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Index
473
class, 21, 184-185
class diagram, 190-191
clicks ro close, 302
clickstrcam storage, 302
clients, 321
client/server an:hiceccure, 323-327
client's role, 324-325
cost-benefit issues, 326-327
auddleware, 326
overview, 323-324
performance issues, 327
tiers, 325-326
dosed-ended questtons, 1 18
cloud computing, 33-34, 202, 328-329
impact, 439
CM. See configurarion management (CM)
CMM. See Cap.tbiliry Maturity Model (CMM)
CMMI. See Capability Maturiry Model lntcgrarion
(CMMI)
CNET, 126
Codd, Edgar, 284
code,297-300
designing, 299-300
overview, 297
reviews, 87, 370
rypcs, 298-299
coding, 369-370
cohesion, 36 J-'l62
object-oriented development, 366-367
combination check, 244
combination key, 276
command burton, 239
common field, 271, 276
communication
skills, systems analysts, 30
company's financial srarus, 51
company size, 32
com peri rors, 5 3
composite key, 276
computer-aided software engineering, 24. See also
CASE tools
computer-aided systems engineering (CASE), 24.
See also CASE tools
computer resources commirrec, 54
con ca ten a red kc>'• 2 7 6
concurrent task, 83
condition, 36 1
confidentiality, 419
configuration management (CM), 411-412
constraint, 63-64
construction phase, I I I
context diagram, 154-155
coocexr-sensirive, 236
continuous backup, 435, 436
control
break, 248
break report, 248
couple, 360
data, 305
field order, 248
module, 360
risk, 421
structures, 169
user interface design, 255-257
zone, 246
corporate culture, 32
systems architecture, 3 l 7
corporate organization, systems architecture,
317
corporate portal, 320
corrective maintenance, 404-406
cost
intangible, 57
operational, 403
ownership, rotal, 57, 3 18-319
tangible, 57
cost-benefit analysis, 67, 212-213
checklist, 213
software acqu1Smon process, 219
sysrem archirecrure, 326-327
couples, strucrure charts. 363-364
coupling, 362
object-oriented development, 366-367
CP~l. See Critical Path ,\tcrhod (CPM.)
credentials, 441-442
critical path, 85-87
calculating, 85-87
tasks and, 87
Critical Path Method (CPM), 77. See also
PERT/CPM charr
critical risks, 421
critical success focrors, 45
Crirical Thinking Community, 30
critical thinking skills, 30, 442
CRM. See customer relationship managemenr
(CRM)
crow's foot norarion, 283
customer relationship m::inagemenr (CRM), 53
cusromers, 53, 367. See also cusromcr relationship
management (CRM)

474
curover phase, 11 I
CybcrEthics, 442
cybcrterrorist, 422
D
data, 3, 5
anal)'sis, preliminary invesrigarion, 65- 67
control, 305
conversion, 382-383
couple, 360
frames, 337
item, 303
legacy, 6, 324
mart, 30 I
mining, 302
normaliza rion, 284- 297
processing cencer, 321
securiry, 257
strucrure, 269
tesr, 371
type check, 244
validation rule, 243-245
warehouse, 30 I
web-based, design, 274-275
data and process modeling, 144-176
data dicuonaries, 164-168
DFDs. See data flow diagram (DFD)
process descripc1on cools, 169-175
darabase adminisrranon, 28
dacabase administrator (OBA), 272
darabase managemenr S)'Stem ( DB ~I S ) ,
271-274
componenrs, 272-274
darabase programmer, 408
daca center, 5
dara design, 268-307
codes, 297-300
concepts, 269-272
data control, 305
dara storage and access, 301-304
DBMSs, 27 l-274
entity-relationship diagrams, 280-284
example, 269-271
normalization. See normali1ation
terminology, 275- 279
web-based, 274- 275
data dictionary, 164- 168
documenting data flows, 165- 166
documenting data stores, J 66
documenting enritie~, 167
documenting processes, 167
documenting record~, 167- 168
reporrs, 168
structure char t~, 363
dara element, 164, 303
data entry ~reen, Ui.er interface!.,
240-243
data flow. 147-149
di verging, 15 7
data flow diagrams (DFDs), 19, 13 I,
146-152
drawing, 152-154
drawing structure charts, 362-363
examples in creating, l 54-158
symbols, 146-152
using symbols, 152
data item, l 64
data manipulation language (OM L), 2 73
data replication, 43 7
data repository, 164. See also dara dictionary
data score, 149. See also data dictionary
data store symbol, DFDs, 149-151
data strucrures, 164
dares, storing, 304
OBA. See database administrator (OBA)
DB,:\15. See database management sysrem
(DBMS)
DDB~1S. See distributed dJrabasc managemenr
system (DDBt-lS)
DDOS. See distributed denial of service
(DDOS)
decision table, 170-174, 358-359
mulriple outcomes, 172-174
one condition, 170
three conditions, 171-172
two condirions, J 71
decision tree, 175, 358-359
decomposing, 159
default value, 165, 236
defect tracking softwa re, 374
deliverable, 19
denial of service (DoS), 422, 428
dependent task, 83
derivation codes, 299
design prowryping, 259
design reviews, 87
desk checking, 370
desktop computer, securiry, 424
Index

Index
475
dee a i I report, 251
developmenc scracegy, 200-223
co~r and benefir analy~i~, 212-213
evolving rrends, 202-203
in-hou~ sofrware de\'clopmenr oprions,
203-208
offshoring, 210
oucsourcing, 208-2 10
selecrmg, 211-214
software acqms1rion process, 214-219
Software as a Service (SaaS), 211
sysrem analyst's role, 212
sysrems analysis rask completion, 219- 222
rransition to systems design, 221-222
DFD. See dara now diagram (DFD)
diagram 0, 155-158
diagrams, 129-13 I
business process, 130
dara flow, 13 1
functional decomposition, 129-130
sequence, 132-133
use case, 132
dialog box, 239
differenrial backup, 435, 436
digiral assisranr, 15
digiral output, 253
dimensions, 30 I
direcr curover, 379-381
disa~ter recovery plan, 4 3 5
discretionary prorecrs, 60
diskless worksranon, 256
distributed darabase managemenr system
(DDBMS), 327
disrribured denial of service (0005),
422,428
distributed systems, 322
diverging data now, 157
DML. See dara manipulation language (DML)
documentation, 373-378
online, 376-378
operations, 375
program, 374
reviewing in preliminary investigation, 65
sysrem, 374
user, 375-376
user inrerface design, 234
documenting interviews, 120-12 I
documenr review, 122
domain, 165
dumpsrcr diving, 422, 4 34
duration, 82
factors affectmg, 80-81
dynamic priontie~, 59
£
EBCDIC, 303
e-commerce (elecrronic commerce), 8
architecture, 329-332
economic feasibility, 57-58, 67
economy, 53
economy of scale, 272
EDI. See electronic data interchange (EDI)
education, sys rems analysis, 31
EH Rs. See electronic healrh records
(EHRs)
electronic commerce (e-commerce), 8
elecrronic darn interchange (EDI), 9, 52
electronic health records (El I Rs), 232
elecrronic product code (EPC), 52
elecrronic proof of delivery ( EPOD), 53
email, 252
empowerment, 17
encapsulation, 184
encryption, 257, 305, 431
nerwork rra ffic, 4 26
engaged listemng, 120
enhancement, 406
enterprise apphcarions, 5
enrerprise compuring, 11
enrerprise resource planning (ERP), I I,
317-318
enriry, 151, 276
documennng, 167
symbol in DFDs, 151
entity-relationship diagram (ER 0 ), 280-284,
356, 358
cardinality, 283
drawing, 280
rclarionship types, 280-282
EPC. See electronic product code ( EPC)
epic, 127
EPOD. See electronic pre>of of delivery (EPOD)
ERD. See entiry-rcl:nionship diagram (ERD)
ERP. See cnrcrprise resource planning (ERP)
error(s)
human, 420
logic, 370
S)'ntax, 370

476
Index
espionage, 420
ethical i:.:.uei., 35, 69, 96, 176, 195, 222, 260, 306,
343, 391, 443
evaluating interview, 121
eva I ua ti on
model, 215
post-implementation, 388-390
and )election team, 212
evencs, 78
Evernote, 135
Excel (Microsoft), 47, 93, 170, 207, 417
exception report, 251
existence check, 244
existing systems and data, 51
exploding, 159
exploit, 421
Extended Service Ser (ESS), 339
extensibility, 3 19
extorrion, 420
Extreme Programming (XP), 24, 357
F
Faccbook,202,329
face-finding (collecting information)
business ca~ analysi~, 64-67
gathering requircmcnrs, 114-115
fat client, 324
fault management, 414-415
fault tolerant, 435
faxback, 253
FDD. See functional decomposition
diagram (FDDJ
feasibility
economic, 57-58, 67
evaluating, 67-68
operational, 57, 67
schedule, 58-59, 67-68
study, 20, 56
systems requests, 56-59
technical, 58, 67
features, 127
fee, outsourcing, 209
feedback, user interface design, 233,
236-237
field, 164, 276
audit, 305
common, 271, 276
key, 276-279
nonkey, 278
file, 269, 276
processing i.ystem, 270
security, 431-432
file-oriented ~ystem s, 270
fill-in form, J 24
financial analysi). Sec coltt-benefit analy'>is
finish day/dare, 83
firewall, 429
first normal form ( I NF), 286-287
fishbone diagram. 62
fixed fee model, 209
Florida Institute ofTechnolog)', 297
flowchart, 358
foreign key, 2 78
form filling, 240
form layout, 246
forums, 217
four-model approach, 145
full backup, 435, 436
functional baseline, 4 14
functional decomposition diagram (FOO),
129-130,232
functionally dependent, 287
functional primitive, 157
functional requirement, I 05
G
Gane and Sarson, 146
Gantt, Henry L., 76-77
Gantt chan, 76-77
Microsoft Project, 9 J
GanttProject, 89
garbage in, garbage out (GIGO), 246
Gardner, Elizabeth, 232
Carmer Inc., 210
gateway, 337
gathering requirements, 1 14-1 15
in agile projecrs, 127-128
through interviews, 116-121
using other techniques, 12 1- 127
Gbps (gigabits per second), 4 16
gigabits per second (Gbps), 338
GIGO. See garbage in, garbage our (GIGO)
globalization, impact, 439
global outsourcing, 210
glueware, 326
Google, 425
Assistant, 15
Docs, 136
Groups, 217
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Index
477
GoToMyPC (Cicrix), 401
governmenr, 53
graphical user inrerfoce (GUI), 229
gray hole, 149
Greening, Dan R., 302
Groupb (Google), 217
groupware, 14
GUI. See graphical u~er interface (GUI)
H
hacker, 422
hackrivisc, 422
hardening, 430
hardware, 5
hardware failure, 420
hash tocab, 245
Hawthorne Effccc, 122- 123
HC I. See hum:in-computer inreracrion (HCI)
heading zone, 246
help desk, 28, 401-402
Hewlerr-Pack.-ird (HP}, 2 13
bjerarchical network, 335-336
Hillcop Motors, 189
Hilton I lotels, 11
rustogram, 135
Hollerith, Herman, 3
horizontal applicacion, 203
horizontal system, 6
bot site, 437
I IP. See 1 lewlerr-Packard (I IP)
HTMl./X,\H., 370
HTTP/2, 327
huh,337
human-computer interaccion (HCI), 230-232
human error, 420
I
IBM (lncernacional Bu&iness Machines),
3-4,52
082, 273
Rational DOORS, 136
Racional coolset, 370
ring network technology, 336
on user incerfoces, 231
WebSphere Commerce, 331
IBS. See Internee business services (IBS)
IC. See inform.-ition cenrer (IC)
lDE. See integrated development
environment {IDE)
idcnticy management, 432
idenricy theft, 4 33
IEEE. See l n~citute of Eleccric.-il and Electronics
Engineers (IEEE)
rEEE 802.11i,427
incremental backup, 435, 436
inference rules, 13
informal structures, I 16
information, 5
orgamzadonal models, 16-17
inform.-ition center (IC), 243
information system, 4-8
evaluating requiremenrs, software acquisition
process, 2 I 4-216
informa tion technology (IT), 3-4
changing nature of, 3
department, 5 1
crcndsin,33-35
lnfoWorld, 126
infrasrruccure mode, 339
inheritance, 185
in-house software, 203, 204-205
mpur
control, 256-257
mask. 241
security, 256-257
technology, 254-255
installation, 378-391
data conversion, 382-383
operauonal and test environments,
378-379
posr-implemenratton tasks, 387-390
system changeover, 379-382
training, 383-384
i nsta nee, l 84
instant me~saging (IM), 252
lnstirute of Electric.ii and Electronics Engineers
(IEEE), 338
802.llac specification, 339
802.11 b specification, 338-339
802.l lg specification, 338
802.11 n specification, 338
802.11 specifications, 338, 427
instruction zone, 246
intangible benefits, 58
intangible costs, 57
integraced development environment (I DE),
24,370

478
Index
integration testing, 372
integrity, 4 19
interactive training, 387
interface
OBMSs, 272-274
user. See graphical u er interface (GUI); user
interface
International OrganiL.ation for Standardization
(ISO), 304, 355
Internet
cloud computing, 202
commerce, 331
information delivery, 252
mobile devices, 203
operating system, 329
SaaS, 328
system architecture, 327-329
traditional vs, web-based systems dcvclopmcnr,
201
Web 2.0,202
Internet business services (IBS), 209
Internet-of-Things (IOT), 52
interview, I 16
conducring, 120
determining people ro, 116-11 7
developing que~rions, I 17
documenting, 120-12 l
establishing ohjccn\'es, 11 7
evaluating, 12 l
garhering requircmcnrs rhrough, 116-121
preparing for, I 18- 120
process, I 16
qucsrionnaires compared, 124-125
lSO. See International Organi1.arion for
Standardization (ISO)
lSO 9000-3:20 l 4, 355
IT. See information technology (IT)
IT department, role of, 46-47
iteration, 169
cycle, 369
planning meeting, 369
and releases, 369
iterative, 22
J
JAD. See joint application development (jAO)
Java, 22, 181, 367
JDBC (Java database conncctivit)'), 274
]IT. See just-in-time (jlT )
job cities, 32
joint applicarion development UAD), 109- 1l0
advantages and tli~ad,•antagcs, I I 0
panicipants and role , 109- 110
user involvement, I 09
just-in-rime (JIT), 52
K
Kbps (kilobits per second), 416
key fields, 276-279
keystroke logger, 424
knee of the curve, 32 7
knowledge base, 13
knowledge management, 13- 14
L
LAN. See local area network (LAN)
layout, user interface design, 237-238
leading questions, 11 7
LearnCode.academ)', 377
legacy data, 324
legacy systems, 6, 319-320
length, 165
leveling, 158, 159-160
library module, 360
lifeline, 192
limit check, 244
Linkedln, 202, 329
list boxes, 240
listening, engaged, 120
local area network (LAN), 322
log, 431
logical design, 221-222
logical model, 145
logical record, 303
logical storage, 302-303
logical :.rructures, 169
logical topology, 335
logic errors, 3 70
loop, 361, 363-364
looping, 169
loosely coupled, 362
M
machine learning, 15
magnetic data strips, 255
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Index
479
mail bombing, 422
maintenance, 403-414
activiti~, 403
adaptive, 404, 406
agreement, 219
baseline~, 414
configuration management,
411-412
correcave, 404-406
expenses, 403
maintenance ream, 408-409
perfective, 404, 406-407
preventive, 404, 407
priorities, 410-411
release methodology, 4 12
requests, 409-410
version control, 412-413
make or buy (build or buy) decision, 20.3
malicious code, 422
malware, 430
managed hosting, 209
management
fi na 1 reporr to, 3 90
system requirement, 220-221
managcmcnr information system (MlS), 13
managing for success, 94-96
budget issues, 9 5
business issues, 9 5
schedule issues, 96
man in the middle artack, 422
many-to-many relanonship, 281
market basket analysis, 302
Mbp~ (megabits per econd), 338, 416
megabits per second (Mbps), 338
menu bars, 239
mesh network, 337
messages, 22, 183-184
methods, 22, 183
metrics, 416
Microsoh, 331
certification, 442
information resource, 2 17
.NET, 370
network diagrams, 77
project triangles, 75-76
software applications, 207-208
on user interfaces, 231
Microsoft Access, 135, 273
input masks, 24 1, 242
reports, 248
Microsoft Excel, 47, 93, 170, 207, 41 7
f\1icrosoh . 1:.1, 20 I
t-.1icrosoft Office 365, 136
1\1icrosoh OneNote, 121, 135
1\1icrosoft Outlook, 134
Microsoft PowerPoinr, 170, 386
Microsoft Project, 89
Calendar view, 92
critical path, 85-87
displaying WBSs, 8 1-82
Gantt charts, 91
network diagrams, 9 1-92
WBSs, 91
Microsoft Visio, 10, 136
Microsoft Window~, 232
Microsoft Word, 47, 170, 207
middleware, 202, 275, 326
milestones, 78
MIMO. See multiple inpuc/multiple output
(MlMO)
MIS. See management information system (MIS)
mission-critical ~ysrem, 5
mission statement, 45
mitigation. 42 1
M:N, 281
mnemonic codes, 298
mock-up, 248
modeling, 9
user interface design, 233
modular design, 169-1 70, 257, 359
modules, 257, 357, 360, 363
control, 360
MongoDB, 201
Monster.com, 4
Moore, Gordon, 5
Moore's Law, 5
multipath design, 339
mukiplc inpuc/multiple output (Mlt-.10), 339
multivalued key, 276
N
National Institute of Standards and Technology
(NIST), 202
natural disasters, 420
natural language, 128-129, 235-236
.NET, 20 l, 370
net-centric computing, 325
net present value (NPV), 2 12

480
network, 426
administration, 28
devicci., 337-338
interface, 426
local area and wide area, 322-323
models, 334-338
private, 427
~ecurity, 426-429
topology, 335
network diagram, 77
Microsoft Project, 91-92
11etwork inttusio11 detection system
(NIOS), 429
node, 319
11ondiscretionary projects, 60
non-fu1ictional requirement, I 05
nonkey field, 278
normalization, 284-297
first normal form, 286-287
real-world examples, 29 1-297
second normal form, 287-289
standard notation format NOT, 285-286
third normal fonn, 290-291
n-tier designs, 325
0
object model, 181
ob1ect modeling, 180-196. See also
object-oncnred (0-0) analysis
a ttriburcs, 183
class, 184-185
messages, J 83
methods, 183
objects, 181-182
relationships among objects and
classes, 186-l87
tools, 195
U~IL. See Unified Modeling Language (UML)
object-orienrcd (0-0) analysis, 17, 2 1-22, L8 l
object-oriented development (OOD), 364-367
characteristics of, 365-366
cohesion and coupling, 366-367
implementation of designs, 366
objects, 21, 181-182
observation, 122-123
observing in preliminary investigarion, 65
ODBC. See open damba~e connecriviry (ODBC)
offshore outsourcing, 2 I 0
offsiting, 435
OneNote (Microsoft), 121, 135
one-co-manr relationship, 280
one-co-one relationship, 280
online data entry, 254
online system, 332
online t raining, 387
0-0. See object-oriented (0-0) analysis
OOD. See object-oriented development (000)
open database connectivity (ODBC), 274, 383
open-ended questions, 117-1 18
open-source, 89
Open Systems Interconnection model. See OSI
(Open Systems Interconnection) model
operational costs, 403
operational environment, 378-379
opcrationaJ feasibility, 57, 67
operational security, 434
operations center security, 423-424
operations documentation, 375
oprion burton, 240
Oracle Corporation, 273, 318
certification, 442
organizational information models, 16-17
organizacional issues, 408-409
orphan, 279
051 (Open Systems lnrerconnecuon) model, 334
output
control, 255-256
printed, design, 247-251
security, 255-256
technology, 252-254
outsourcing, 208-210
advantages and di~advanrages, 403
fees, 209
growth, 208
issues and concerns, 210
p
page footer, 249
page header, 249
pair programming, 368
parallel operation, 38 l
parent, 185
parent diagram, 157
Pareto chart, 65
partitioning, 159, 359
password, 432
Index
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Index
481
pas~word cracking, 422
patchc&, 374, 405
payback analy~is, 212
perfective maintenance, 404, 406-407
performance. Sec also benchmark; syscem performance
management
syMem architt'l:ture, 327
Perl, 367
permissions, 305, 430
personal computer, impact on sysrems architecture,
322
personal digital assistant, 15
personal informarion manager (PIM), 134
person-day, 79
PERT/CPM chart, 77-78
maintaining schedule, 87
phased operation, 38 1-382
phishing, 422
physical design, 22 1-222
physical model, 145
physical security, 423
physical storage, 302-303
physical ropology, 335
pilot operation, 38 1
pilot site, 381
PIM. See personal informarion
manager (PIM)
PKE. See public key encryprion (PKE)
plain text, 426
platform, 317
plotter, 254
podca~t, 253, 385
point-of-~ale (POS), 333-334
po1111-of-sale terminal, 253
Polanon, 25
polymorphism, 183
pool, J 30
port, 427
portable computer, security, 425-426
portal, 320
port scan, 427-428
POS. See point-of-sale (POS)
post-implementation casks, 387-390
evaluation, 388-390
final report co man,1gement, 390
power-on password, 424
PowerPoinr (Microsoft), 170
predecessor tasks, 79
multiple, 83-84
preliminary investigation, 20, 60-69
planning, 61
steps, 61-68
summarinng, 68
pretexting, 433
pre,·entive maintenance, 404, 407
prin1ary ke), 276
printed output design, 247-251
printers, ~pecial-purpo~e, 254
priorities
dynamic,59
farors affecting, 59-60
setting, 59-60
private key encryption, 426
private network, 427
privilege escalation attack, 422, 432
probable-case esrimate, 79
Procedia Comp11ter Science I 00 (Bologva), 232
procedural security, 434
process, 7, 14 7
documenting, 167
improvement, 353
symbol in DFDs, 147
process 0, 154
process description, 169-175
decision tables, 170-174
decision tree., 17 5
modular design, 169-170
structured English, 170
processing systems requests, 54-55
product baselme, 414
production environment, 378-379
productivity sofrware, J 34
product lifccrcle management (PLM), 24
product--0riented, 34
program documentation, 374
Program Evaluation Review Technique {PERT),
77- 78. See also PERT/CPM chart
programmer/analyst, 408
Project (Microsoft). See Microsoft Project
project coordinaror, 76
project creep, 62, 95
project leader, 76
project management, 18, 74-97
managing for success, 94-96
overview, 75-76
project monitoring and control, 87
reporting, 87-89
risk management, 93-94
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ···---~~-.,.-"~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

482
project management (Co11ti1111ed)
software, 89-92
task patterns, 82-85
work breakdown structures, 76-82, 91
project manager, 76
project monitoring, 76
project planning, 76
project reporting, 76
project scheduling, 76
project scope, 62-65
project status meeting, 88
project status report, 88
project triangle, 75-76
properties, 21
prototype, 24, 258
user inrerface design, 233
prototyping, 258-259
proxy server, 337
pseudocode, J 70, 358
public key encryption (PKE), 426-427
Python, 181, 367, 387
Q
QA. See quality assurance (QA)
QBE. See query hy example (QBE)
qualirarive risk analysis, 93
quality assurance (QA), 28, 353-355
quality artribures, 105
quanritarive risk analysi~, 94
query by example (QBE), 273
query language, 273
quesnonnaire, 123-124
interviews compared, 124-125
quesnons
closed-ended, I 18
developing inrcrview, I 17
leading, J J 7
open-ended, I J 7-118
range-of-re~ponse, 118
R
RAD. See rapid application development (RAD)
radio button, 240
radio frequency idcnnficarion (RFID), 13
tags, 50, 53, 255
RAID (redundant array of independent disks), 435
random sample, 125
Index
range check, 244
range-of-response question~, I 18
rapid application development (RAD), 109, 111-112
advantages and di~ad,•amages, 112
objectives, l J 2
phases and activities, 111- 112
reasonableness check, 244
records, 164, 276
documenting, J 67-J 68
records rerenrion policy, 257
recovery, 435-437
recovery procedures, 305
Reddic, 217
redw1dant array of independent disks. See RAlD
(redundaJlt array of independent disks)
referential integrity, 244, 279
relational database, 271
relational model, 271
relationships, L85
structure charrs, 363
release plan, 369
remote control sofrw:i re, 40 I
repeating group, 285
report
data dictionary, 168
design, 248-25 I
footer, 249
header, 249
srsrem design prcsenranon, 342-343
representing requiremenrs, 128-133
diagrams, 129-131
models, 131-133
narural language, 128-129
requesr for proposa 1 ( R FP), 215
requiremenr(s). See also rcqui remenrs engineering
challenges, 106-J 08
definitions, l 05
eliciration, 114
fu11Ctional, 105
gathering, 114-115
non-functional, 105
representing, 128-133
specifications, 105
system, 105
rypes of, J 05-106
validating and verifying, I 33-l34
requirements engineering, 20, I 04-138
gathering requirements, I 14-128
representing requirements, 128-133
system requirements, I 05-108
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Index
483
ream-based technique~, 108-114
tools, 134-137
validating and verifying requirements,
133-134
requirements planning phase, 111
re~earch, 126-12 7
Resource ~1oniror (\Vindows), 41 5
response rime, 416
responsible user(s), 165
respo11S1\'e Web design, 258
retention period, 4 36
retirement, system, 437-438
return on investment (ROI), 2 12
RFID. See radio frequency identification (RFlD)
RFID tags, 52, 53, 255
systems projects, 52, 53
RFP. See request fo r proposal (RFP)
RFQ. See request for quorarion (RFQ)
ring network, 336
risk, 93, 42 1
risk assessment, 420, 42 1
risk control, 420, 421
risk idenrification, 93, 420-421
risk management, 93-94, 420-421
ri5k managcmcnr pliln, 93
risk response plan, 94
roaming, 339
router, 337
Rub), 367
s
SaaS. See Sofrware as a Scrvicc(SaaS)
salary, 32
sales force
corporate culnirc, 32-33
sampling, 125-126
SAP, 11
scalabiliry, 107, 271-272, 319
scalable, 2 1
scaling on demand, 328
scarcer diagram, 66
scenarios, 127
schedule
analysis, 67
feasibility, 58-59, 67-68
maintaining, 87
schedule issues, 96
schema, 273
SCM. See supply chain management (SCM)
script kiddie, 422
scroll bar, 240
Scrum, 23, 1 I 3
SDLC. See S)'~tems development life crcle (SDLC)
secondaq key, 278-279
second normal form (2NF), 287-289
security, 107, 165, 419-423
applications, 429-432
concepts, 419
file, 431-432
firewalls, 429
hole, 430
aerwork, 426-429
NIDS,429
operational, 434
operations center, 423-424
policy, 419
procedural, 434
risk management, 420-421
sysrcms architecture, 320
roken, 433
user, 432-434
user interface design, 255-257
SEI. See Sofrwilre Engineering Institute (SE!)
selection, 169
semantic web, 329
sequence, 169
sequence check, 244
sequence codes, 298
sequence diagram, 132-133, 192
server, 321
application, 325
clientlser\er architecture, 323-327
proxy, 337
security, 424
service, 427
desk,207-208,401-402
failure, 420
packs, 412
provider, 208-209
securiry, 430
service desk, 207-208, 401-402
service-oriented companies, 34
service provider, 208-209
Sherwin-Williams, 9
significant digit codes, 298-299
simulation, 387
sink, 15 I
sire visit, 127

484
Index
slack time, 87
sniffing, 423
social engineering, 423, 432-433
social networking ~ite, 329
so fr skills, 44 2
software, 5-6
acquis1rion procCSl>, 2 14-219
application, 5
anack,420
bug trackmg, 374
defect crackmg, 374
e11gineering, 353
failure, 420
license, 219
logs, 431
reengineeriug, 406
remote control, 40 J
requirements specification, 2 1, 219-220
system software, 5
third-party, 430
workgroup, 14
Software as a Service (S:.iaS), 211, 328
Software Engineering Institute (SEI), 353, 354
software package, 203
customizing, 206-207
purchasing, 205-206
software vendors, 203
identifying, 217
source, 151, 165
source data automation, 254-255
source document, 246
spam, 423
special-purpose printers, 254
spiral model, 23
sponraneous generation, 149
spoofing, 423
spy, 422
SQL (Structured Query Language), 273, 326
stakeholder, 7
stand-alone computing, 322
standard notation formar, 285-286
star network, 337
srart day/dare, 83
srare, J 83
srare transition diagram, 192- 193
srarus flag, 360
storyboards, 127, 233
strategic plan, 50
strategic planning, 45, 440-44 I
tools, 47
stratified sa m pie, 125
structure chart, 360-361, 362-364
structured analysis, l 7, 18-22
structured application development, 356-357,
359-364
structured brairutonning, 125
Structured English, 170
structured walk-through, 87, 370
stub testing, 371
subclasses, 184
subordinate module, 360
subschema, 273
subscription model, 209
successor task, 83, 85
summary report, 25 l
Sun Microsystems, 325
superclass, J 84
superuser account, 430
suppliers, 52
supply chain, 9
supply chain management (SCM), 9,
53,318
surveys, 123--124
interviews compared, 124-125
preliminary investigation, 65
swim lanes, 130
switch, 337
switchboard, 238
S\VOT analysis, 45-46
syntax errors, 370
SysML, 131
system, 4
system administrator, 408
system architecrure, 316-345
client/server architecture, 323-327
corporate organization and culrure, 317
corporate portals, 320
ecommerce, 329-332
ERP, 317-318
impact of Lnterner, 327-329
impact of personal computer, 322
initial cost and TCO, 3 J 8-3 19
legacy systems, 319-320
mainframe a rchitccrure, 321-322
network evolution, 322-323
network models, 334-338
processing methods, 332-334
processing options, 320
scalability, 319
security issues, 320
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

Index
485
systemJ. design complerion, 341-343
web inrt>grarion, 3 19
wireless networks, 338-340
systematic sample, 125
syscem boundary, 189
syscem changeover, 379
direct cucover, 379-381
parallel operauon, 381
phased operaaon, 381-382
piJoc operanon, 381
system design review, 356
srstem design specification, 21, 341-342
system documencation, 374
system performance managemenr, 414-419
capacity planning, 4 17-419
fault management, 414-415
performance and workload management, 416
system prototyping, 259
sys rem requiremenr, 105
documenc, 20, 219-220
syscems analysis, 103-223. See also data and process
modeling; object modeling; requircmenrs
engineering
and design, 4
phase, 20
systems analysrs, 4, 28-34
career oppornmiries, 32-33
certification, 3 1
knowledge, ~kills, and educarion, 29-31
maintenance team member, 408
role,28-29
role in systems developmenr process, 212
systems design, 227-343. See also data design;
system architecrure; systems analysis; user
interface design
goal, 227
logical and physical, 221-222
review, 356
transition to, 221-222
syscems design phase, 2 I
S)'Stems development, 17-26
systems development life cycle (SDLC),
19,36
systems implcmencarion phase, 2 l, 352-393
coding, 369-370
docurnenration, 373-378
installation, 3 78-391
quality assurance, 353-355
resting, 370-373
systems integration, 15
system software, 5
systems planning phase, 20
systems programmer, 408
systems projecrs
external faccors, 52-53
internal faccors, 50-51
syscems requests, 20
feasibiliry, 56-59
forms,54
processing, 54-55
toob,54
sysrems review committee, 54
systems support and security phase, 21, 27, 399~5
backup and recovet) 1 , 435-437
future challenges and opportunities, 438-442
maintenance management, 408-4 14
maintenance casks, 403-407
security. See security
system performance management, 414-419
system retircmenr, 437-438
user support, 401-403
system testing, 372-373
T
table, 269
table design, 284
tamper-evident cases, 424
cangible benefits, 58
cangible costs, 57
task, 78
box,82
concurrenc, 83
dependent, 83, 85
estimating duration, 79-80
group, 77
ID, 82
name, 82
predecessor, 79, 83-84, 85
successor, 83, 85
WBSs, 78-80
task pattern, 82-85
types, 83-84
working with complex, 84-85
TCO. See cota l cost of owncr~h ip (TCO)
TDD. See rest-driven dcvelopmcnr (TDD)
TcchCrunch, 126
cechnical fcasib1lity, 58, 67
......... ""_.. ...
.-.. ............... _
.. __ __.... ................... ~~·~---- ·· · ---~~-.,.- "~ ........... --......
("..,_..., llll!O( ...... ..--. .\) ....... ~ "->-"'Allf'W ~-............... ,.. o-.... ._ ...... _ ... ,..,...,...,~..,._.. .............. ~ ..

486
technical knowledge, systems analysts, 29-30
technical ob~ole~ccnce, 420
technical support, 26-27
technology, 52
rechnolog)' integration, impaCl, 439
terminab, 253
terminators, 15 I
test data, 3 71
test-driven development (mD), 368
test environment, 378
testing reviews, 87
testing the system, 370-373
integration testing, 372
system testing, 372-373
unit testing, 370-371
test plan, 371, 436
theft, 420
thick client, 324
thin client, 325
third normal form (3NF), 290-291
third-party software, 430
threat, 421
three-tier design, 325
throughput, 4 16
throwaway prororyping, 259
tightly coupled, 362
toggle button, 239
roolbar, 239
top-down approach, 359
top managers, 50
total cosr of owncr~hip (TCOJ, 57, 108, 213
systems arch1tccrure, 3 18-319
totals zone, 246
TP. See transaction processing (TP) sy~rems
TPC. See Transaction Processrng Performance
Council (TPC)
traceability, 136
trade-offs, 259-260
training
interactive, 387
online, 387
outside resources, 385
plan, 383-384
podcasts, 385
tips, 386-387
tutorials, 385
user, 401
vendor, 384
webminars, 385
train-the-trainer, 387
Train the Trainers, inc., 19 J
transaction model, 209
Transaction Processing Performance Council
(TPC), 218
transaction processing ("f P) systems, 11-12
transference, 4 21
transparent, 322
transparent interface, 230
TravelBiz., 181
trespass, 420
tunnel, 427
tuple, 276
turnaround documents, 248
turnaround time, 4 J 7
Turnkey Services, 211
tutorial, 385
onlinc, 387
Twitter, 202, 329
two-tier design, 325
type, L65
Index
u
UML. See Unified Modeling Language (UML)
unencrypted, 426-429
Unicode, 303-304
Unified Nlodeling Language (UM L), 131, 181, 187-
194, 283
activity diagram, 193-194
class diagrams, 190-191
sequence diagrams, 192
state rransirion diagrams, 192- 193
use case diagrams, 189-190
use case modeling, 187-189
uninterruprible power supply (UPS), 424
United Stares Compurer Emergency Readiness Team
(US-CERT), 428
unir testing, 370-371
Universal Security Slot (USS), 425
unnormalized table, 285-286
unsrrucrured brainstorming, 125
UPS. See uninrerrupciblc power suppl)' (UPS)
up.time, ldera, 419
US-CERT. See United Scares Computer Emergency
Readiness Team (US-CF.RT)
usability, 229
analysis, 67
metrics, 233
user interface design, 233
(....,..... J:gi( ..... I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

_
("..,_...,llll!O(........--. .\) ~ "->-"'Allf'W ~-............... ,.. o-.... ._......_ ... ,..,...,...,~..,._................ ~ .........""_......-................. ..__ __.... ................... ~~·~---- ···---~~-.,.-"~...........--......
Index
usage model, 209
use ca~c, 187
use case dcscripuon, 188
use ca~e diagram, 132, 189-190
use cai.e modeling, 187-189
user, 6
application, 207-208
approval of ~yMem design, 342
considering m user mterfoce design, 233
DB~1Ss, 273
design phase, J 11
groups, 431-432
ID,305
interface, 207
manual, 378
productiviry systems, 14
resistance to security, 433
rights, 305, 430
security, 432-434
story, 369
support, 28
training package, 40 I
user-centered ~ystem, 230
user design phase, I 11
user documcnracion, 375-376
user interface, 229-230. See also graphical user
interface (GUI)
user interface design
ba~ic principles, 232-234
emerging trends, 257-260
guidelines, 234-246
primed output, 248-25 I
securit) and control issues, 255-257
source document and form design, 246-247
technology IS~ues, 251-255
user requests, 5 I
user-selected help, 236
user stories, J 27
user survey, conducting, 65
v
validation, input, 430
validity check, 244
validity rules, 165
value-added rc~eller (VAR), 203
vandalism, 420
VAR. See value-added reseller (VA R)
vendor training, 384
version control, 4 12-4 13
vertical application, 203
vertical S)'i.tem, 6
virtual private network (VPN), 427
Visible Analyi.t (Visible S)'stems Corporation)
CASE tool, 283
documentation, data dictionary, 166
Visio ( ~ticrosoft), I 0
Visual Basic, 20 J, 370
VPN. See virtual private network (VPN)
VRB0,8
vulnerability, 421
w
Walmart, l l, 13, 52
WAN. See wide area network (WAN)
WAP. See wireless access point (WAP)
waterfall model, 19
WBS. See work breakdown strucmrc (WBS)
web
support, 28
S/~tcms ::irchitecturc, 3 19
web-based design, 274-275
Web 2.0, 202, 329
webcast, 252, 385
web-centric architecture, 3 19
web-connected device, portable, 253
webinar, 385
weight, 79
WEP. See \Xfired Equivalent Privacy (WEP)
Western Electric Company, 122
whar-if analysis, 417
wide area network (WAN), 322-323
\Vi-Fi AIJiance, 339
\Vi-Fi Protected Access (\XfPA), 427
wiki, 329
\Vired Equivalent Privacy (\VEP), 427
wireless access point (\VAP), 339
wireless devices, 253
wireless fidelity (Wi-Fi), 339
wireless local area network (WLAN), 338-340
standards, 338-339
topologies, 339
trends, 339-340
WolframAlpha, 13-14
Word (Microsoft). See Micro~oft Word
work breakdown scrucrure (WBS), 76-82. See also
Ganrt chart; PERT/CP1\.I chart
487

488
work breakdown structure (WBS) (Continued)
displaying, 81 - 82
factor~ affecting durarion, 80-81
identifying ta~k~, 78-80
Microsoft Project, 91
workgroup software, 14
workplace, impact, 439
worst-ca~e e~rimate, 79
WPA. See \V1-l-t Protected Access (WPA)
WPA2, 428
x
XP. See Extreme Programming (XP)
XY chart, 66
Microsoft Excel, 93
y
Y2K issue, 304
Yourdon, l 46
Index
(....,..... J:gi( ..... I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., ....,...,.......,..~.................,.t11ru..__.~~c.....,..~.........,..,... ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................

c.,,..-•~fftlllll'.._..., A11t1.-RNr-a ~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,., ~..,-. .......,..,• .._....,~ ,.W«t.., w~...t~.._., •._....._,~,.,
t.M..wl'"_._......,lhll..., ~....,...._,.. ....,.......,...... .,.,...,1.._.....,~ c~~".._.._...._.,,.. ..__..,.............._ ..., ..........""'°..................