Download as pdf or txt
Download as pdf or txt
You are on page 1of 514

·-

#"" ' - 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... ,..,........., "' . . . ..-..... ""' . . .................. .


C.....""_..,...._..,...,. ....,....._.,.,...._• """'."'"""<"' .,..
......
.._,. ......,~.n....-..-..ilk...,.~C~ ......_ __..
Dartn . . . . . . . . . ."'" •.-. . . . . ...., , . . . . ..., ... .,....,....,., ...... . , ,...~--. . ~~~
... ._..,,,.. .. __ ........ _.. ., _.. ... 4 . . . . . . ,__........._• .,._.1111:
,: _ CENGAGE

Systems Analysls and Design, Twelfth Edition O 2020. 2017 Cengage learning. Inc
Scott Tilley Unless otherwise noted, aH content ls Cl Cengage.
WCN: 02·300
SVP. Higher Educatton Prodlm Management:
Enn Joyner 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.
VP. Product MaNgement Mike Schenk except as permitted by U.S. copyright law. without the pnor written
Product Otre<tor.1.Auren Murphy pennissi<>n of the copyright owner
Product Team Manager Krosun McNary
Product Manager JaylT'Me Falconi For product informatlOfl and technology asslsta~. contact us a1
Product As5'Stant. Anna Goulart Cengage Customer & Sales Support, 1-IOC>-3S4-9706or
support.cengage.com.
Oire<1or, LHrnong Design Rebecu von Glllern
SenK>r Manager, learning Otsigr• Leigh Hefferon
Learning Designer· Emily Po~
Vice Preslden~ Marketing - Science, Technology,
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


& Math Jason Sakos
Senior Marketing D1re<1or: Michele McTlghe ISBN: 978-0-357· 11781-1
Execu1lve Marketing Monoger: Cossle Cloutier Cengage
Product Speclallst: Mackenzie Paine 20 Channel Center Sueet
Boston, MA02210
Director, Content Creation: Juliet Steiner
USA
Senior Manager, Content Creation: Pauy S1ephan
Cengage is a leading provider of customized learning soludons with
Cement Manager: Michele Stulgo
employees residing in nearly 40 dlfferem coumrles and sales In more
Technical Editor: John Freitas than 125 countries around the world. Fond your local repre~ntatlve at
Director, Digital Producllon Services: www.cengage.com.
Krista Kellman Cengage pro<lucts are represented in Canada by Nelson Educallon, l td.
Digital Delivery Lead· Justin Maniaci
To learn more about Cengage platforms and services. reglste< or access
Designer: Uzz Anderson your on lone leamlng solution. or purchase materials for your course, Visit
Proctucuon ~rvlce/Compos.llon. Lum1na www.cengage.com.
O..tamaiocs. Ltd.
Cover unage iStock.com/Nongkran_ch

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 ~,._._~
__ .....,.__.t__.•.._a..,..
r.....l _ _ .._......,..,_..,.,............_.,.....,..._...,.....,_..,.,,_.,.._..~~a-.e.._..,...,.,,._.
.,..., -<.....,._~~
.......... ,......_... ..........
iii

DEDll CATION

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
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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
vi

TABLE OF CONTENTS
PHASE I : SYSTEMS PLANNING I.9 The Systems Analyst 28
1.9.1 Role 28
1.9.1 Knowledge. SIUlb. and Ecb::auon 29
l.9J Certification 31
1.9.4 c..reer Opportunities 32
1.9.5 Trends"' lnformabon Technology 33
Introduction to Systems Analysis A Question of Ethics 35
and Design 1.10 Summary 35
Learning Objectives 2 Key Terms 37
I. I Information Technology 3 Exercises 42
I. I.I The Changing Nature of Information Technology 3
1. 1.2 Synems Analysis and Design 4
1.1 .3 What Does a Systems Analyst Doi
1.2 Information System s
"
4
1.2.1 Hardware
1.2.2 Software
5
5
Analyzing the Business Case
1.2.3 Data 6
1.2.4 Processes 7 Learning Objectives 44
1.2.S People 7 2. I Strategic Planning 45
Case In Point I. I. Data B~. che 8 2.1 . 1 Strategic Planning Overview 45

1.3 Internet Business Strategies 8 Case in Point 2.1; Pets for Rent 45
1.3. 1 The lnttrnet Model 8 2.1.2 SWOT Analysis 45
I .J 2 82C (BuS1ncsMo·Consumer) 8 2.1 J The Role of the IT Dep1rtmenc 46
I .J.3 828 (Business·tO· Buslness) 9 2.1 Strategic PlanningTools 47
1.4 Modeling Business Ope rations 9 2.l The Business Case 47
1.5 Busines$ Informa t ion Systems 11 2.4 Systems Requests 49
1.5 I Enterpriu Computing II
l.S.2 Trmuccion Processang II
2.5 Factors Affecting Syst e m s Projects so
2.5. 1 lntern>I Factors 50
I .SJ Business Support 12
2.5.1 Extern>! Factors 52
l.S.4 Knowled&e Mana&e"*" 13
I .S.5 User Producov1ty 14 2.6 Processing Systems Requests 54
I .S 6 D1giul Assistants 15 2.6.1 Sys<ems P.equen forms 54
1.5 .7 Systems lnteinuon 15 2.6.2 Systems Request Tools 54
2.63 Systems Review Committee 54
C..• ~ 1n P. t I 2: Au 1n• '"'° ~ h I • 5
1.6 Organiu.t ional Information Models 16 Case 1n P"'nt 2 1: At '"' y A1r1 " , P.art On~ SS
1.6 I Functions and Organlzadonal l.eve:s 16 2.7 Assessing Request Feasibility 56
1.6.2 Top Man~ers 16 2.7. 1 Feuibtlity Studies 56
1.6.3 Middle Maniiers •nd Know1ed&• Worker> 17 2.7.2 Operauon>l FeaS1bthty 57
1.6.4 Supervisor> and Team Leaders 17 2.7.3 Ecooom<e Feasib1l1ty 57
1.6.5 Operadonal Employees 17 2.7.4 Teclvlical F<!asibillty 58
2.7.5 Schedule Feasfblllty 58
1.7 Syst ems Deve lopment 17
2.8 Setting Priorities S9
1.7. 1 StructuredAnalysls 18
1.7.2 Object-Oriented Analysis 21 2.8.1 Dynamic Priorities 59
2.8.2 F•«ors That Affect Priority 59
1.7.3 Agile Methods 22
1.7.4 Prototyping 24
2.8.3 Discretionary and N ondlscretoonary Projects 60
1.7.5 Tools 24 Case in Point 2.3: Attaway Airline , Part Two 60
1.8 The Information Technology Department 26 2. 9 The Preliminary Investigation 60
1.8.1 Appllcatlon Development 27 2.9.1 Planning the Preliminary lnvesclgadon 61
C;ue in Point 1.3 : Global Hotel~ and Momma's Motels 27 2.9.2 Performing tho Preliminary lnvesdgatlon 61
1.8.2 Systems Support and Security 27 2.9.3 Sumtmn•mg the Preliminary lnvestlg-.tion 68
1.8.3 User Support 28 A Question of Ethics 69
1.8.4 D•toboseAdmlnt>trotJon 28
1.8.5 Network Adminlstrodon 28
2. 10 Summary 69
1.8.6 Web Support 28 Ke:yTerms 70
1.8.7 Qu>l1ty Assuranco (QA) 28 Exercises 72

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Ta ble o f Contents vii

4.2.2 Rapid Apphcadon Development 111


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
__.... ~~·~----···---~~-.,.-"~ ...........
viii Table of Conte nts

5.9.J Slt\ICtured En&hsh 170 7.3.4 Custom1%1ng •Software Pad<ogc 206


5.9.4 Dec1si0n T~es 170 7.3.S Cre.tlng User Appli<att0ns 207
Case in Point 5 .2 : Rock Solid Outfitters (Part I) 174 Case in Point 7 . 1: Doug's Sporting Goods 108
5.9 .S DeclSlO!'I Trees 175 7 .4 Outsourcing 208
use in Point 5.3 : Rock Solid Outfitters (Part 2) 175 7.4. I The Growth ol Ouuourc"'I 108
7.4.2 Outsouran& Fees 209
A Question of Ethics 176
7A3 Ouuourong Issues and Concerns 1 10
5. 10 Summary 176
7.5 Offshoring 210
Key Terms 177
Case in Point 7.2: Turnkey Services 211
Exercises 179
1.6 Software as a Service 211
7.7 Selecting a Devefopment Strategy 211
Chapter 6 7.7. I The Systems Analysts Role
7.7.2 Analyzing Cost and Bcnefiu
212
212
7.7.3 Cost-Benef1tAnalysls Checkllot 213
Object Modeling
Case in Point 7.3: Ster1ingAssoclates 214
Learning Objectives 180 7.8 The Software Acquisition Process 214
6.1 Object-Oriented Analysis 181 Step I: Evaluate che Information Synem Requirements 214
Step 2: Identify PotentialVendors or Outsouroing Options 2I 6
Case In Point 6. 1: Travel Biz 181 Step 3: Evaluate the Alternatives 217
6.2 Objects 181 Step 4: Perform Cost-Benefit Analysis 219
Step S: Prepare a Recommendation 219
6.3 Attributes 183
7.9 Completion ofSyscemsAnalysisTasks 219
6.4 Methods 183 7.9. 1 System Requirements Document 219
6. 5 Messages 183 7.9.2 Presentation to Management 220
7.9.3 Transition to Systems Des1&n 221
6.6 Classes 184
6.1 Relationships Among Objects a.n d Classes 186 A Question of Ethics 222

6. 8 The Unified Modellng language (UML) 187 7. 10 Summary 222


6.8. I Use Cue Mod~1n1 187 KeyTefms 224
6.8.2 Use Cue Ofagnms 189
Exercises 226
Case in Point 6.l : Hilltop Moton 189
6.8..3 Cius 01ograms l'JO
PHASE 3 : SYSTEMS DESIGN
use in Point 6 .3: Train the Trainers, Inc. 191
6.8.4 Sequence O.airams 192
6.8.S
6.8.6
State Transition Oiograms
Activity Diagrams
192
193
Chapter 8
6.8.7 Susineu Process Modeling 194
6.9 Tools 195
User Interface Design
A Question of Ethics 195 Leaming Objectives 228
6.1 0 Summary 195 8.1 User Interfaces 229
Key Terms 197 8.2 Human-Computer Interaction 230
Exercises 199 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
Chapter 7 8.3.2 Maxlml1e Graphical Effectiveness 232
8.3.3 Think like a User 233
Development Strategies 8.3.4 Use Models and Prototype>
8.3.5 Focus on Usability
233
233
8.3.6 Invite Feedback 233
Learning Objectives 200
8.3.7 Document Everythln& 234
7. 1 Traditional Versus Web-Based Systems
8.4 Guidelines for User Interface Design 234
Development 201
8.4. 1 Create an Interface That Is Easy to Learn and Use 234
7.1.I Traditional Oevelopmenc In a U'ldltlonal systems 8.4.2 Enhance User Producuvlty 235
development environment 201
8.4.3 Provide Flexibility 236
7. 1.2 Web-Based Oevalopmenc: In a web-based systems 8.4.4 Provide U1en wich Help and Feedback 236
development environment 201
8.4.5 Create an Atll'lctove Layout and Oesl&n 137
7.2 Evolving Trends 202 8.4.6 Enhance che Interface 238
8.4.7 Focus on Oaa Entry Screens 240
7.3 In-House Software Development Options 203
8.4.8 Use Validation Rules 143
73.1 Make or Buy Decision 203
204 8.4.9 Manoge Data Effectro'Oly 245
7.3 l Developing Softw1re In-House
8.4.10 Reduce lnputVolume 145
733 Purclwin1 • ~ Pac.kage 205

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Ta ble o f Contents ix

Case in Point 8.l : Boolean Toys 2'46 Case 1n Point 9.3= Madera Tools 300
8.5 Source Document and Form Design 146 9.8 Data Storage and Access 301
2'47 9 8.1 Tools and Techniques 301
8.6 Printed Output
9.8.2 Logial Venu• Phytical Storage 302
8.6.1 Report ~'II' 2'48
9 8.3 O.ta Cod•ng 303
8.6.2 Report ~lgn Pnndples 248
8.6.3 Tn- of R"'°ru 250 9.9 Data Control 305
Ca.e in Point 8 .3: Luy Eddie 251 A Question or Ethics 306
8.7 Technology Issues 251 9. 10 Summary 306
8.7.1 Output Technology 252 KeyTe,.ms 308
8.7.2 Input TechnolocY 25'4
Exercises 313
8.8 Security and Control Issues 255
8.8. I 0uq>Vt Secumy and Control 255
8.8 2 Input Securtl}' and Control 156
8.9 EmergingTrends 257 Chapter 10
8.9. 1 Modulor Deslsn 257
8.9.2 Re•pon•lve Web Design 158 System Architecture
8.9.3 Prototyp1n1 258
A Question or Ethics 260 Learning Objectives 316
8.10 Summary 260 I 0. 1 A,.chitecture Checklist 317
I0.1.1 Corporat0 Organludon and Culture 317
Key Terms 262 I0.1.2 Enterprise Resource Planning (ERP) 317
Exercises 266 I 0. 1.3 lnltQI Cost and TCO 318
I 0. 1.'4 Sal•b•lity 319
I0. 1.S Web Integration 319

Chapter 9 I 0.1.6
10. 1.7
Legacy Systems
Processing Options
319
320
I 0. 1.8 Security Issues 320
Data Design 10. 1 9 Corporote Portals 320
Case in Point 10.1 ABC Sy.terns 32 1
Learning Objectives 268 I O.l The Evolution of System Architecture 321
9. 1 Data Design Concepts 269 I0.2.1 Mainframe Arch1tec:wre 321
9.1.1 O.ta Scructures 269 IO.l.l Impact of the Ptrsonal Computer 322
9.1.2 Mano and o.,,.ca: Ao.a cnsiin Ex.omple 269 I0.2.3 Network Evoluuon 322
9.1.3 Database Manaaement Systems 271
I 0.3 Client/Server An:hitecture 323
9.1 DBMS Components 272 10.3 I The Client's Role 324
9.2. I lnU!rfaces lor Usen, Database Administrators. and I 0.3.2 OoentJSeM1er Tiers 325
Related Systems 273 I 0.3.3 M1ddleware 326
9.2.2 Schema 2n 10.3.'4 Cost-Benefit luues 326
9.2.3 Physical Data Repository 273 10.3.S Ptrformanco Issues 327
9.3 Web-Based Design 274 I 0.4 The Impact of the Internet 327
275 10.4 .I lntemet·BuedArchiteca.o,. 328
9.4 Data Design Terms
9.'4. 1 Definitions 175 I 0.'4 2 Cloud Computing 328
276 10.4 .3 Web 2.0 329
9.'4.2 Key Field•
9.'4.3 Refttential Integrity 279 I 0.5 E-Commerce Architecture 329
9.5 Entity-Relationship Diagrams 280 I 0.5. 1 In-House Solutions 330
9.5. 1 Drawing an ERO 180 I 0.5.2 Packaged Solu11ons 33 1
180 I0.5.3 Service Providers 33 1
9.5.2 Typos of Refadon•hlps
9.5.3 Cardinality 183 Case in Point I O.l . Small Potatoes 332
Case In Point 9. 1: TopText Publishing 284 I 0.6 Processing Methods 332
9.6 Data N ormalii.ation 284 I0.6. 1 Online Processing 332
9.6. I Saindard N otation Format 285 I0.6.2 Batch Processing 333
9.6.2 First Normal Form 286 I0.6.3 Example 333
9.6.3 Second Normal Form 287 10.7 N etwork Models 334
9.6.'4 Third Normal Form 290 I 0.7. 1 The OSI Model 331
Case In Point 9.2: CyberToys 291 10.7.2 NetworkTopology 335
291 10.7.3 Network Devices 337
9.6.S Two Re>l-World Examples
9.7 Codes 297 I 0.8 W ireless Networks 338
297 I 0.8.1 Stand•rds 338
9.7. 1 Ottrv.-ofCodes
9.7.l Types of Codes 298 I 0.8 2 Topolog1u 339
299 1083 Trends 339
9.1.3 Designing Cod.s

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~----···---~~-.,.-"~ --......
...........
x Table of Contents

Case In Point I 0 .3: Spider IT Services 340 '-- I

341 I l.93 Dati Conve.-..on 382


10.9 Systems D esign Completion
341 11.9.4 Training 383
10.9.1 System DHlgn Speclflcauon
11.9.S Post-lmplementadon Tasks 387
I0.9.2 Us..-ApprCMI 3'12
~
10 9.3 PreS4'lc11lons 342 tdwtrica
A Question of Ethics 3 43 A Q uestion of Ethics 391
I 0.1 0 Summary 343 I I. I0 Summary 391
Key Terms 346 Key Terms 394
Exercises 350 Exercises 398

PHASE S : SYSTEMS SUPPORT


PHASE 4 : SYSTEMS AND SECURITY
IMPLEMENTATION

Managing Systems Support


Managing Systems Implementation and Security
Le arning Objectives 352 Lear ning O bjectives 400
11 .1 Quality A ssurance 353 12. 1 U ser Support 401
I I. I. I Softw.lre Englneerlnc 353 12.1 .1 UserTralnlng 401
I 1.1.2 Systems Engineering 3S3 12.1.2 Help Desks 401
I 1.13 International Organization for St»ndardlution 355 12.1.3 Outsourcing Issues 403
I 1.2 Application D evelopment 356 12.2 Maintenance Tasks 403
11.2.1 Review the System Design 356 12.2.1 Types of Maintenance 404
I 1.2.2 Application De..lopment Tuks 356 12.2.2 Correctl\'e Maintenance 404
I l.2J Syncms Development Tools 357 12.2.3 Adaptm: Mimt~ncc 406
I I .3 Structured Deve lo pment 359 12.2.4 P..-fectrVe Maintenance 406
12.2.S ~ntive Maintenance 407
11.J. I Strvcture Chuts 360
I I 3.2 CohesK>n .nd Coupl 111 361 Case n Po 12 0 0 1n:lng, Inc, 7
11.3.3 Drawing a StrvCture Chart 362 12.3 Maintenance Management 408
11 .4 Object-Orie nted Developme nt 3 64 12.l. I The Mimtenance Te"'" 408
11.4.1 Charactenstlcs of Object-Onented De-ttlopment 365 12.3.2 Maintenance Requests 409
11.4.2 lmplementadon of Obtect-Onented Designs 366 12.33 Establishing Pnorrt1u 410
114.3 Object-Oriented Cohesion and Couplin& 366 12.l.4 Configuration Management 411
367 12.l.S M•intemnce Releases 412
I 1.5 Agile D e velopment
12.l.6 VersK>n Control 412
11 5.1 en.- Programml11g 368
369 12.3.7 Basehnes 414
11 S 2 UJ1r Scones
11.5.3 Iterations and Releases 369 12.4 System Pe rformance Manage ment 4 14
369 12.4. I fault Management 414
11 .6 Coding
12.4.2 Performance and Workload Measurement 416
I I.7 Testing 370 12.4.3 Cap•clty Planning 417
11.7.1 Unlt Teulng 370
372
12. 5 System Security 419
11.7.2 Integration Tesung 419
372
12.S. I System Security Concepts
11.7.3 System Tesdng
12.S.2 Risk Management 420
C:... I M...,., lnc. 3 l 12.S.3 Attacker Promos and Attacks 421
11.8 D ocum entation 373 12.6 Security Levels 423
11.8. 1 Program Documcntodon 374 12.6.1 Physical Security 423
11.8.2 System Documentation 374
Case in Point 12.2: Outer B;mks County 426
11.8.3 Operations Documentition 375
12.6.2 Network Security 426
11.8.4 User Documentitlon 375
12.6.3 Application Security 429
I 1.8.5 Online Documentation 376
12.6.4 Ric Security 431
I I •9 Installation 3 78 12.6.S User Security 432
11.9.1 Operational andTest Environments 378 12.6.6 Procedur.ll Security 434
11.9.2 System Changeover 379

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Ta b le o f Contents xi

c. l'uw 17 C on L 1 Consulting, Inc. 4)4 12.9.4 CnocalThonkln&Skills 442


12.9.S Cybcretllla 442
12.7 Backup and Recovery 435
12.7.1 Global Terrorism 435 A Question of Ethics 443
12.7.l Backup f>ojKoes 435 11.10 Summary 443
12.7.3 Business ContJnUtty Issues 436
Key Terms 446
12.8 System Re tirement 437
Exercises 452
12.9 Future Challenges and Opportunities 438
12.9.1 T..-.nds and Predoc:tJOns 438 Glossary 453
12.9 l Strateiic Ptann•f\g for IT Pro(euionals +40 Index 471
12.9.3 IT Credentials and Cerofoc:aaon +41

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~----···---~~-.,.-"~ ...........
~ 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
xii i

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 c hallenging 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 rh o e
ro les.

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 informa-
tion system is an amalgam of people, data, and technology to provide support for busi-
ness furn'tiom
.. •. As technology evolves, so docs systems analysis. The book cmphasi.i:es
the role of the systems ana lyst 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 st rong analytical and crincal
thinking skills. The y must also be business savvy, technically competent, and be cquall)'
comfortable working with managers and programmers. Throughout the book, real-
world examples emphasize critical thinking and l T 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 applica-
tions. 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 compan y's strategic objectives. Case srudies and assignments
teach analytical reasoning, critical thinking, and p roblem-solving skills. Numerous proj-
ects, assignments, and end-of-chapter exercises are provided, along with detailed instruc-
tor support material.

Objectives of This Text


Syst ems Analysis and Design, 12th edition is inrended for a three credit-hour introduc-
tory 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, object-


orientcd, and agile systems development merhods.
• explain how IT supporcs business requirements in todays intensely competitive envi-
ronment, and
• d~ribc major IT devclopmcntS and trends.

Ne w 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 dis-
traction.
• A renewed emphasis on aligning learning objectives with chapter content and assess-
ments. 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, discussio n 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.

Organizatio n 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, anal ysis,
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 a lso includes invaluable resources. Cross-functional toolkits provide
scudents with che basic skills soughc after by o rganizations 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......,........,
a:.a.ww~
A1..,....ai-.en...
~-..,.~·----·~••klk<9i11,..,_0w.~,,...
... ...,,..,.., ..,.......,,,... ........
.. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~•.
.. ., ...cn11.,.__..........,,..-:&-c~..,.--:c--•.,,. .. -~....._.....,.. .... ..,,, ......... ,... ........... ..,._.._
_.._...,~
Preface xv

Phase 2: Systems Analysis


• Chapter 4 - Requirements Engineering: Chapter 4 describes the requirements engi-
neering 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 strat-
egies for the new system and plans for the transition to the systems design phase.

Phase 3: Systems Design


• Chapter 8- User In terface 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 neces-
sary for a systems analyst to construct the physical model of the information system.
• Chapter l 0 - System Architecture: Chapter I0 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 change-
over.

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 mcasurc-
mcnr, and system renremenr.

Online Appendix:The Systems Analyst's Toolkit


• Toolkit Part A - Conuuwiication Tools: Part A of the toolkit discui.ses coinmunica-
tion tools that can help the analyst write clearly, speak effectively, and deliver power-
ful 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 esti-
mates, 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 thi nk 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 work-
force. 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 learn-
ers 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 dedica ted to providing you all the tools yo u 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......,........,
a:.a.ww~
A1..,....ai-.en...
~-..,.~·----·~••klk<9i11,..,_0w.~,,...
... ...,,..,.., ..,.......,,,... ........
.. - ... ,...,•_....,.._....,,..._.t._.,doA..,._~•.
.. ., ...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 fig-
ure 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 pub-
lications, including Software Testing in the Cloud: Migration 6r Execution (5pnnger,
2012), Testing iOS Apps with Hadoop Unit: Rapid Distributed GUI Testing ( ~1organ
& Claypool, 20 14), 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 com-
ments. 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 sys- The chapter includes three "Case in Point" dis-
tems planning phase. This chapter explains the role of cussion questions to help contextualize the concepts
information technology In today's dynamic business described in the text. The "Question of Ethics" invites
environment. This chapter describes the development examination of the ACM's code of ethics and those of a
of information systems. systems analysis and design con- developing systems analyst.
cepts. and various systems development methods. This
chapter also summarizes the role of the information
technology department and its people in the enterprise.

LEARNl"IG OB ECT VES CONTENTS


When yo11 fi11ish this d1apter, you should be able to: I . I Information Technolog)
I .2 Information Systems
1. Describe rhe impact of informario n rechnology
Case in Point J. J: Data Breaches
on soc1ery
1.3 Internet Business Strategies
2. Describe che five main components of an 1.4 Modeling Business Operations
informarion sysrem 1.5 Business lnformarion Systems
3. Explain lnrerner business srratcgies and Case in Point 1.2: Autonomous Vehicles
relationships, including B2C and B2B 1.6 Organiz.arional Information Models
4. Explain how rouse business profiles and models 1.7 Systems Development
S. Undersrand rhe seven rypcs of information 1.8 The Information Technology Department
systems used in business Case in Point 1.3: Global Horels m1d Momma 's
Morels
6. Describe the types of inform:i rion Lhe four 1.9 The Systems Analyse
classes of users need
A Question of Ethics
7. Distinguish among struccured ana lysis, objece- I. I 0 Summary
orienccd ana lysis, and agi le systems development Key Terms
methods Exercises
8. Lise rhe tools chat enable rhc syseems ana lyse
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

r..,,...JmDr-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 peop le use to
manage, communicate, and share information. Compa-
nies use information as a way to increase productivity,
deliver quality products and services, maintain customer Social Media
loyalty, and make sound decisions. In a global economy Explodes!
with in tense competit ion, information technology can
mean the difference berween success and failure.
l\1ore than ever, business success depends on infor- Another Home Run
Fh c More Sillies Ban
mation technology. IT is driving a new digital economy, for Apple'!
Driver Toting
where advances in hardware, software, and connectivity
can provide enormous benefits to businesses and indi- 1Math: 1Pod +
Digital Cure fo r i Phone + 1Pat! =
viduals. 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
Health Care Costs SS$

FIGURE 1- 1 These headlines Illustrate the enormous


---·
IT curve. Conver&ely, when the economy slows down, impact of information technology on our lives.
firms often use IT co reduce operating costs a nd improve
efficiency.
lnforn1Jtion technology a lso has profound infl uence 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 an d 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, w ho live a nd work in this exciting world, to
realize rh~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 th at identified characters by the location of punched holes,
founded IBM's predecessor company in 1896. A deck of hundreds or even thousands of
th ese cards cou ld 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
revolu tionized the business world and was in use into th e 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I Introduction to Systems Analysis and Design

4 1.2 Info r mation Systems

1. 1.2 Systems Analysis and Design


S)stcm s anal ysi~ and design is a s tep-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 da y-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 professiona ls like these a re always in demand, even in a slow economy.
For example, norice how many positions related to information technology and infor-
mation systems arc available in the Melbourne, Florida area, as shown on Monster.
com's job search website in Figure 1-2.

MONSTER [ Q. Information l ecltnology & ~ F Melboume. FL_ _ _ __.

.
Find Jobs •

., ...
Caree< Resource• • Post a Resume C<lmpany Profiles

Information technology & Information systems J obs In Melbourne, Florida (1081 Jobs Found)

FIGURE I · 2 Monscer.com is an example of an online job search w ebsite that IT professionals can use.
Sourc.r. nI 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 mus t be excellent communica-
tors wirh strong analytical and critical thinking skills. Because S)'Stems analysts trans-
form 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 mem-
ber 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 con-
ducts meetings, delivers presentations, and writes memos, reports, and documenta tion.
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 exam-
ple, specialized systems route lnternet traffic, manufacture microchips, and control
complex entities like the Hubble telescope, which took the amazing image shown in

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

1.2 Information Systems s

Figure 1-3. A mission-critical ~stem is one that is vital to a


company's operations. An order processing srsrem, for exam-
ple, 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 FIGURE 1-l Consider the amazing technology
equipment, fiber-optic cables, mobile devices, scanners, digital that enabled the Hubble telescope to capture this
capture devices, and other technology-based infrastructure. Image.
Sourcet Co..rt y of it,.. I "'-j,j
A l::irge concentration of networked computers working
together is called a data center. As new technologies emerge, / /
manufacturers race to market the innovations and reap the rewards. . I ~

Hardware purchasers today face a wide array of technology choices and I 1111111 •• • s
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
'
y
l 8ol••
over 50 )'Cars. Fortunately, as hardware became more powerful, it abo
became much less expensive. Large businesses with thousands or millions
[ '

s .,...
of sales rranc;actions require company-wide infor mation systems and pow- T
erful servers, which are often now in the cloud, such as those shown in . . 111111 <
E
I
Figure 1-5.

1.2.2 Software
I ..... ~ T
M
I.ii

Soh\\arc refers to the programs rhar control the hardware and produce the FIGURE 1-4 An Information
desired information or resulrs. Somvare consists of S)'Stem sofrware and system needs these components.
application software.
System software manages the hardware components, which can include
a single computer or a global network with many tho usands 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.

.........""_.. ....-................. _..__


("..,_..., llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ·· · ---~~-.,.- " ~ ...........
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 au to 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 informa-
tion. 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 databa~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

fMPl,OVff CUAAENTOfDUCTIONS O!OUCTION OPTIONS


9 Employet No fmplQYet No t Oedu<:llon Code
P>yl'tnod Otpt I Otduruon Codt Otsalpllon
Hoors Wotlrtd Ply Rott Amount frtqvtn()'
f1rs.tNlMt
Ml
ltrt N1mt
Strt:tt
CllY

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. Stake-
holders include che management group responsible for the system, the users (some-
times 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 devel-
opment process.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~ --......
...........
Chapter I Introduction to Systems Analysis and Design

8 1.3 Internet Busin ess 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 compan ies tha t
will require innovative IT solutions.
Business mday is being shaped by rhree major trends: rapidly increasing globalization,
technology integration for seamless informatio n 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 manage-
ment 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 pro-
fes!.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 prod-
uct) 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 incen-
tives for o n line cr::insactions because web-based processing cost~ are lower than tradi-
tional methods. By making Aight informa tion available online to lase-min ute 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 o ut that same transactio n 0 11 the Internet, che company must
develop an onl ine 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 advi-
sors, 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~iness-ro-busine~s) transactions is many rimes greater. Industry
observers predict that 828 sales will increase shar ply as more firms seek to improve
efficiency and reduce costs.
Initially, electronic commerce berween two companies used a darn sharing arrange-
ment 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)'·to-
company 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
Verily Customer
Veriy Customer
Credit
Cred~

Process
Enter Customer Enter Customer j
Order Data 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

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 ness process
modeling notation (BPMN). BPMN includes standard s hapes 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.

_____ ... _
-- ..
........__
=====================··
· - - g Q. ~- · - ·

_.... -·- 0

·- - •

0000
0 0 00 .,_
0000
oooa __ _
-·-
Cl
V0(9@ .._..
001
I
(
... ..
. -· 0

'
OciCJO
00011
11==
.... C=i
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.... .,..,_

(....,..... 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 II

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 exam-
ples of enterprise computing systems. The main objective of enterprise compuring is
ro integrarc a company's primary functions (such as production, sales, ervices, inven-
tory 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 e nterprise 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 poten-
tia~ many hardware and sofrware vendors target the enterprise computing marker
and offer a wide a rray 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

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, manufactur ing, 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.
F IGU RE 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.
T P syscems are efficient because they process a
Check Post to set of transacrion-relatt:d command~ as a group
Stock Accounts rat her than individually. To protect darn incegrity,
Status Aece1vabla however, TP systems ensure that if any single
elemenc of a crans~1 ctio11 fai ls, the system does not

~\
Check Adjust
Credit Inventory process the rest of the transaction.
Status Levels

E.5.3 Business Suppo rt


Verify
Customer
Data
• 1
,.,. Sates
nsactlon
6 Update
Sales Fie
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
F IGURE I · I I A single sales transaction consius of six separate
control business proces~es, and provide informa-
tasks. which the TP system processes as a group. tion that leads to better decision making.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 valu-
able information. The new systems we re called manageme nt info rma tion 'Y~ tem s
( ~US) 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 exam-
ple, 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 busi-
ness support system highlights slow-
or fast-moving items, customers
with past-due balances, and inven-
tory levels that need adjustment.
To compete effectively, firms
must collect production, sales,
and shipping data and update the
compan>r-wide business suppo rt
system immediately. Auto ma ted
data acquisition is possible using
technology such as radio frequency
identificatio n (RFJD), which uses
high-frequency radio waves to track
physical objects, such as the shirt
shown in Figure 1- 12. Major retail-
ers such as Walmart, which requires
its suppliers co add RFlD rags to
all item , have fueled RFlD's dra-
matic growth by tracking produces
throughout the retail process. FIGURE 1- 1l With an RFID tag. items can be tracked and monitored throughout
An imporrant feature of a the retail process.
b~mess supporr system is decision ~

support capability. Decision supporr


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 know ledge ma nagement 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 "compu-
tational knowledge engine." Ir has a sophisticated na tural language front end that
understands user queries in several domains. As shown in the figure, these domains
include mathematics, science and technology, society a nd 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, includ-
ing 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 ••

1...
Sdnn & '!echnclagy •

s -
Sodo!y & Culluze • ~Ult

1
--
--
.!:! - · -

• .,.,...,._ .a • -·-
-
t.:
1
. . """"
. •:. L._..'*'t m O.tnll.Tima v
>: 1 -
rt' ........ ._.. ~ .,_, \v; ..,...,~, IMPo"lllWWIW

J ... [). ~ ._.,,rtNl>Q



·-
t ............... C::...,,nt.oqo; Sclfl'ICll tto.fh<ll41 ~

~ ..,,,,, !C.""1CM

-· • FM 4' Nl.0'•1 •tfl. Ho!.lw1014IV1W\

.. \

11111
~1'9"1i.tll•.. •'Hll'll

,._,,~..
~

"':!JI( f•1o''*POtUt1Clrl
•• .....
Poll*'lfAOtrt""J'
:.:..i · -
• ....T.clfly 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 system s ioclude email, voice mail, video
and web conferencing, word processing, automated calendars, database managemenc,
spreadsheets, desktop publishing, presentation graphics, company inrranets, and inte-
grated mobile computing systems. User productivity systems also include group ware,
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~..

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ .. __.~~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 cor-
porate data co perform their jobs.

1.5.6 Digital Assistants


Rapid advanceb in na tura l language processing have made a
new rype of business information system possible: the personal
digital ab5i!.tant. T hese i.ysrems a re combinations of knowledge
management systems a nd user productivit y systems, enhanced
with artificial intelligence and machine learning capabilities.
They are typica lly cloud based and can be embed ded in
hardware devices of vario us sizes a nd types.
Digita l absisrants are exemplified by products such as
Amazon.com's Alexa, Apple's Siri, a nd 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 inte-
grate with other software applications and actual hardware,
such as controlling lights ar home or the rempera·r ure ar the FIGURE 1-15 Amazoncom·s Echo Dot.a digital
assistant embedded 1n a smart speaker powered
office. An image of the Amazon Echo Dor, which is a sman by Alexa.
speaker powered by Alexa, is shown in Figure 1-15. Sow«<

1.5.7 Systems Integration


Most large companies requi re systems that combine transaction proce sing, business sup-
port, 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 a nd a quali ty control system
with decision support capabiliries. A qualiry control engineer uses what-if analysis to
determine if the firm should make prod uct design c hanges to reduce warranty claims.
lo this example, a TP system is inregrated with a knowledge management sy!ttem and a
business support system with decisio n suppo rt features.

Imagine you work for a large automotive company. Your manager asks you to look into integrat-
ing 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 organizationa l 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 organi-
zation 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 knowl-
edge 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 recog-


nize 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 com-
pany'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, technol-
ogy trends, competitive threats, and governmental issues.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 manag-
ers 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 three-
stare 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. J ust 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, oper-
ational U)ers also need mformation ro handle tasks and make decisions t hat 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 lternative~ are !itructurcd analysis, which is a traditiona l 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 t he laresc trends in software devel-
opment. Figure 1-17 provide~ an overview of the th ree methods, which are discussed
in the following !.Cccions.
Although most projects utilize one approach, it i!> not unusual for systems devel-
opers 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 OBJECT-ORIENTED AGILE


ANALYSIS ANALYSIS METHODS

Description Represents !he system in terms Views the system in terms Scresses intense team-based
al daa and !he processes !hat of objects that combine effort. Breaks development
act upon that data.System data and processes. The into cycles. or iterations,
de< elcpment IS organized objects represent actual that add functionality. Each
into phases. with deMrables people, things, transactions. cycle 1s designed. built. and
and milestones to measure and events. Compared to tested in an ongoing process.
pi ogi ess.The watemll model structural analysis, 0-0 Attempts to reduce ma1or
typically consists al five phases tend to be more risks by incremental steps In
phases: requil el IM!l ltS. desipl. interactive. Can use the short time intervals.
ConstruCOOl'I. testing. and waterfall model or a model
mamtenanee & e\IOlution. Iteration that stresses greater
is possible among !he phases. iteration.

Mode ling Data flow diagrams (DFDs) and Various object-oriented Tools that enhance
Tools process descriptions, which are diagrams depict system communication, such as
described In Chapter S. Also, actors, methods, and collaborative software,
business process modeling. messages, which are brainstorming. and
described in Chapter 6. whiteborads. Business
Also, business process process modeling works well
modeling. with agile methods.

Pros Traditional method that has Integrates easily Very flexible and efficient in
been very popular over time. with object-oriented dealing with change. Stresses
Relies heavily on written programming languages. team lnteraroon and reflects
documentation. Frequent phase Code is modular and a set of community-based
iteration can provide flexibility reusable, which can reduce values. Frequent deliverables
comparable to other methods. cost and development consandy v.ahdate the
Well-suited to traditional time. Easy to maintain project and reduce risk.
project management tools and and expand because new
techniques. objects can be created using
inherited properties.

C o ns Changes can be cosdy, Somewhat newer method Team members need a


especially in later phases. might be less familiar high level of technical
Requirements are defined to development team and communications
early, and can change during members. Interaction of skills. Lack of structure
development. Users might not objectS and classes can be and documentation can
be able to describe their needs complex in larger systems. Introduce risk factors.
until they can see examples of Overall project might be
features and functions. subject t0 scope change as
user requirements change.

FIGU RE 1-17 Comparison of structured, object-oriented, and agile development methods.

Regardless of rhe devclopmenr stra tegy, 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 infor-
marion 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 develo pment 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.

x
41 V•,.blt 4n4'y11 · IRfGIST RATION PROCESS MODEU>FD)
li F~t
CJC!J:.l
[d< Vo<w °"''°"' Rq>OMt"')' 0..gftm Tools W.ndow - " Help
W .J1' ~ '1.a ia l • 4 ~ o""'a "' .. ,"\ ..,, , T
[J

-" .
1~ vj •4 14, I .J • ol I

SCHOOL REGISTRATIO~ SYSTEl\1

Sl\JDENTS OUTPUT

REGI STRATIOll Oo\TA


R£CIST£R 1 - - - - - - - - -M
COURS{OATA CL\.SS ROSTERS
.....--------1.t ~DC..''TS

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 per-
form, 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

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 wi th a formal request to the IT depart-
ment, called a systems request, which describes prob-
• System lems or desired chaDges in an information system or
teqUitements a business process. In many companies, IT systems
document
planning is an integral part of overall business plan-
Ding. When managers and users develop their business
plans, they usually include lT requirements thar gen-
erate systems requests. A systems request can come
• Systrim
design from a rop manager, a planning team, a department
spec1ftcat1on bead, or the IT department itself. The request can be
very siignificant or relatively minor. A major request
might involve a new info rmarion system or the
upgradi ng of an existing system. In contrast, a minor
• Functioning request might ask for a new feature or a c hange to the
system user interface.
The purpose of this phase is m perform a
prelimina ry investigatio n co evaluate an IT-related
business opportunity o r problem. The preliminary
Systems • Fully investigation is a critical step because the outcome will
Security and operahonaJ affect the entire development process. A key part of
S u pport system
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.
FIGURE 1-1 9 Development phases and deliverables are Suppose a systems analyst receives a request for
shown in the waterfall model.The circular symbols indie1te a system change or improvement. The first step is to
Interaction among the phases.
determine whether it makes sense co launch a prelim-
inary investigation at a ll. 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 func-
tions properly, bur users need more training. ln some situations, a business process
review may be recommended rather than an IT solution. ln o ther 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 a nalyst
invc~tigates business processes a nd dlocuments what the new system must do to sat-
isfy users. Requirements engineering continues the investigation that began during the
system~ planning phase. To understa nd rhe system, fact-finding using techniques such
as interviews, surveys, document rev iew, ob:.ervacion, and sampling is performed. The
fact-finding results a re used to build business models, data and process models, and
object models.
The deliverable for the systems analysis phase is the ~>~tern req uirements
document. The system requiremencs document describes management and user
requirements, costs, and benefits and outlines alternative development strategies.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 addi-
rion, 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 a rchirecrure 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 specifica tion, which is presented
to management and users for review and approval. Management and user involve-
ment 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 syste ms implementation phase, the new


system is constructed. Whether the developers use structured analysis or 0-0 meth-
ods, 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 a nd perform any necessary modifications. The objective of the
systems implementation phase is to deliver a completely functioning and documented
informa tion 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, a nd per-
forming the actual transirion to the new system.
The systems implementation phase a lso includes a n assessment, called a systems
evaluation, to determine whether the system operates properly and if co~ts and bene-
fits 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 du ri ng 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, maintarna ble, 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 a nalysis 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 mode l rea l-world business processes and opera-
tio ns. The result is a set of softwa re objects that represent actual people, things, rrans-
actions, and events. Usi ng an 0 -0 programming la nguage, 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 Introduction to Systems Analysis and Design

22 1.7 Systems Development

In 0-0 design, built-in processes called


PERSON
nzethods can change an object's properties. For
Name example, in an online catalog store, a n ORDER
Address
o bject might have a properry called STATUS that
Date of S.rih
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
INSTRUCTOR STUDENT
specific behavior or information from another
Name lnhefll&d Name
object. For example, an ORDER object might send
Address properties Address
a message to a CUSTOM ER ob1ect that requests
Dale ol Bir1h Dale of Birlh
a shipping address. When it receives the message,
Otlice Location GPA the CUSTOMER object supplies the information.
Olllce Phone
Other - { Adv<SOr The ORDER object has the capability to send the
properties
Email message, and the CUSTOMER object knows what
actions to perform when it receives the message.
FIGURE I · 20 The PERSON class includes INSTRUCTOR and 0-0 analysis uses object models to represent data
STUDENT objects. which have Inherited properties and their own and behavior and to show how objects affect other
properties. 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 follow 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


FIGURE 1-21 In a cyplc:al o.o development model. Development tcchnjques change over time. For example, struc-
planning. analysis. and design tasks Interact continuously tured analysis is a traditional approach, ~md agile methods are
to generate protocypes that can be tested. 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 feed-
back, :ind each incremental step is affected by what was learned in rhc prior steps.
Although relatively new to software development, the norion of iterative develop-
ment 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

1.7 Systems Development 23

...., ____ Q

lQ Scrum.org

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: eaha rs from tar lb.ing
IOC4~

International Conference on Data Science, £-learning


and ln(ormot/on Systems 2018
READ MORE
0 0t lob.< I Z018 9 Mi\dnd

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 grad-
ually 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 LC 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, ana lysts should recognize char
these approaches have advantages and disadvantages. By their nature, agile methods
can a llow 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 require-
ments, certa in features requested by some users might not be consistent with the com-
pany'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 Pro totyping


Srrucrured analysii., object-oriented analysis, and agile merhods can all employ
protoq·ping as a supporting sysrem s development method. ProtOt)·ping resrs sys-
tem concepts and provides an opportunity to examine input, ourput, and user
in terfaces before final decisions are made. A pro to t}pe is an early working version
of ::in information sysrem. Jusr as an ai rcrafr manufacturer resrs a new design in
a wind tunnel, sysrems analysts construct and study informarion system proto-
rypes. 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 valu-
able 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 a pplication lifecycle management (ALM), a lso called
prod uct li fccycle management (PLM ); integrated development environments (IDE);
::ind computer-a ided systems enginee ring (CASE), also called computer-a ided 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:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

1.7 Systems Development 25

Tools make ir easier ro build an informarion system, t hereby 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 d e -. bl.ltd lftl Ind "'IN99 ...,.,pla tcftwllt• S)"lle!M on I un.lltd
100 pert8'l -
of users
Dl..O 10M- lNl W"4S llNll leltnl « "'°""'"°'
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 Polarion REQUIREMENTS Polarlon QA


- .. fHt«r - mo<e , _ , M1ilt Ehoiwfy ~'-· ..,.,_• •W-ond "°"ides comclle•~ IOI...,_ qunty .....,_..
~nmg- - lr«Nblr.ty ond ,.,.._,_.,_II for complu SJ"I_,. ondtnt>ng~
~ty lr>•o your oppll(11.,., 1 let)dc K1otS ........ pqea lifK)'des

D D D

Variants Add-on Polanon Pro Polarlon Reviewer


ll<ipidly INI el!.ttiwfy o..ign. ~Ind unify Chl"llO .......met'I. llSli & is.... [Nble ln~nll •nd Ule<nel It.I~ IO
~· complu f1mlfies CJf ptodUtl _...,,,. trodJoog 11'<! _ ,_.."9 KrOU 111 P'O)KI ,....,...""and COftVT1iil"M on ""°'t. ,..,... M'ld
1NI va-11 wilh lndintty lffcf"'ll - l o g y contribt.itof5 Kf'Cl55 tre entefp\M piOlllcle lndunry-complio<U t l « -
1NI lr-tegrll"'"' lill""""" ond ll'PfOli'll\.
D D 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' ..---
..
···-
t - ,,,,,_.' - ,..
- - - -· ·
Fully-featurtd 1ntt.'9rak-d o.:vdoprrn:t l t:riwonment
(IOE) -
··-
··-
··-


-- .......... =----............................--..
t ' , 7111 I • .._

··-
.- --
fo< Android. 10S. rnacOS, web, and doud
··- ·--- I"------··
--
·-:==:... ·--
·-·
·-·
·-

I -·-
.-.... ~ ........
-~

··-===::....
··-
·-
r". -·oo=
-- -·-
~=~- ­
Download Vo~ual Studio for Mac .!.

. -- -••
••
- •

-
-~ J

- -
FIGURE I · 2 4 Microsoft Visual Studio is a fully-feawred integrated development environment (IDE).
Sour<e: """ •o • tt Co• p• .. 1

No Magic

Cameo Systems Modeler

c - ~.... MrDllllw.." . . ~" . . . . . cnw.--~ CClllabar•Nit Modllt B.wlofld ..,.,.... (• . . . . . .


~lllillltbiilll &
tt'AWIR thtMGAM

.• c.........,_ ... ~
'••CNdl --..--.....-·..........
I ......a..,-°""*'~,....Wld~"'feoolsto . . . . tne*.lftel~.al---bOI
a d cx....Srr'IMlmidelSD...,.,lllt••••w•••...................
... -<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 s uppon, 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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gi ( . . . . . -Woip-M ._..,..
..,...,...... .,..~ .. __.~~ 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 Departme nt
Otrector
lnlonnation Technology

I
Apphcauoo
Development
l
I_
Syslems Support
and Secunty
I
User
Support
I
Database
AdminlstrallOn
~'- _ I_
Network
Administration
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 o f 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 them-
selves. 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 fust acqu ired 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 addit ional
informat ion 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, tele-
communications 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 su pport 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 g raph ics packages. User support specialists answer questions, crou-
bleshooc 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. Regar d less of company size, mission-critical database
applications require continuous attention and technical support.

1.8.5 Ne twork Administration


Business operations depend on networks chat enable compa ny-wide informa tion sys-
tems. Network administration includes hardware and so~wa re mai ntena nce, support,
and security. In addition to controlling user access, netwo rk administrato rs insrall,
config ure, m::inage, monitor, and maintain ne twork a ppl ications. Nerwork a dministra-
tion is discussed in more d etail 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 web-
based ::ipplic::irions to the company's information systems. Reliable, high-quality web
support is especia ll y critical for companies engaged in e-commerce.

1.8.7 Quality Assurance (QA}


Many la rge IT deparrments also use a quality assurance (QA) team thac reviews
a nd 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 invest igates, analyzes, designs, develops, insralls, evalua tes, and
maintains a company's information s ystems. To perform chose tasks, a sysrcms ana-
lys t constan tl y interacts with users ai!ld managers within and o utside rhe compan y.
The fo llowing sections describe a systems analyst's ro le, knowledge, skills, ed ucation,
certifications, a nd career opportunities.

1.9. 1 Role
A systems analyst helps d evelop IT systems rha r s upport business requirements. To
succeed, ana lysts often mus t ace as translato rs. For exam ple, when chey descri be
business processes to programmers, t hey muse speak a language thar programmers
will undersrand clearly. Typically, the analyse build s a series of models, diagrams,
and decision rabies and uses other descriptive cools and technique . Similarly, w hen

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 ana-
lyst uses various presentation s kills, 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 manag-
ers. \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 con-
tinue , the analyse will seek feedback and comments from the users. This mput can pro-
vide 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 a nd the position.
In a rapidly changing fT marketplace, a syste1ns analyst must manage his or her own
career and have a pla n for professiona l development.

TECHNICAL KNOWLEDGE: Sracc-of-the-a rt knowledge is extremely import·


an t in a rapidly changing business and tech nical environment. T he 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 communi-
ties, and more. Analysrs also maintain cheir skills by actending training courses, borh

I E

~ -~-- ~ , -
. -- -
r

. '

WHAT ts S¥SltMS CNGIN((llllNG1 IMCOSl"S IMPACT GIOW IN SYSTCMS £NGINClllllHG


L.. ,, • .ai.u1 1hit .._,..nr..e ....... l•Mlf\& t~ rwtt.1.r• of 5"'i•m' V..pe lh• •~Id en4 .tw..w-e ,_., C•t..-t
) En1•1'\ff_rif'1g

rltOM me CUTIING lDGE nHO YOUA COMMliNIT't


lll'lpeictfwl ,'9d«.b end Mat.... the--.,,, 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~ s rrong oral and written


communication ~kills and che ability to interact with people at all levels, from oper-
ational 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.., qfIM W<ll«t IO ... ,..q ofUH~


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 C o n - 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 ..,.bating inl'o11118fiongalhatad Imm. otgane,.led by,~
--18-. 1eftadlol1, IMIOllfng, ot ~ H •~IO belef and •clan. ln 1111 .......ry fotm , l
le - on u n i - 01111 ;t• - lt>at Itel-id oubj9ct - dMelont doallly. 9CCUtaeY I" oclal<>ot
--..Y. ••••""'· - - - g o o d -, 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 critica l 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 professiona ls and the employers who hire thetin.

THINK Watson

- - ,..,.. I 'nloU- I - · I ... I - I c.ua

The Gold Standard Critical Thinking Test • menti

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.

----
------- -·
.- =-- -.._________ _
.--------
- ..==-----====---·--=:.--
------ ==----
~"'"'=='--
:::-::::::::..~
-..._~==--

--· _, --
':···~ii!!'
-----·--- --:::-----~--
- ...----::---..---
=---::.
- W .:-.:---a.:;::_:::
·-
- - r

1111 _ ic,_ _., !!O>rt


• •
ll>"ll\Jo'f Cn11<o!lv
-.>•uQl-
n>""'°""'

• _,......,. Ct1ttcll tfll"9 ... ltlfllty 1'1111 dldCD\ ll'IUi"I


• fllrecilcll JUOrttnt. ~ to1"""1. CNlllmtty, GPrMm io c;cpc •w» I
• ~ '-ttary of UM tft Mlf'IJ'll. F' I '""* It, WICI ~r:iort
• c.r.i..t" '#ftl'I
• °'4
. "*" 4
ot•'-d'i,.
IOCtty Md Pl"'O'll'''Y t-.i
.,.......,.,._flClfl It -ltfl~
"IM'I ""'-..,,,. C1'mla
"'°'9

CDtl • !?Br;~ t!!!ll p.tl\ utnWW;


mt -.tth """"'twpxt. . ciptfon&
·--·
1bp Scat .. on W G twlp "odlCt

.... itudr. lill " ... " . .



kDfftl 1111 h ...... ~ ..,. ~

........
efW.tliDr't-GIM« ............ ..
ret'WI\
l*'fca WWW l (at!W ,,...,, U'IC9 ~

F I GURE 1- 29 Employers lllce co hire people who can think logically and effectively.
Sourc.,. lu

("..,_...,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 a re found in positions rirled computer specialist, programmer,
programmer/analyse, sysrems designer, software engineer, and variou~ ochers. Be sure
rhc responsibi lities 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 com-
pany wirh scare-of-the-arr sysrems provides opportuniti~ for speciah.mrion. Alrhough
there mighr be more responsibiliry in a smaller company, rhe promorional opporruni-
nes and financial rewards could be grearer in larger companies. Working as an inde-
pendent 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 impor-
tantly, review shore- and long-term goals very carefull y before deciding which posi-
tion is most suirablc.

CORPORATE CULTURE: fn addition to having goals, methods, and information


systems requirements, every firm has an underlying corpo ra Lc culLure. A corpora re
culture is the set of beliefs, ru les, traditions, values, and attitudes char define a com-
pany a nd influence its way of doing business. To be successful, a systems ana l)1St 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 wor k.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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• IS ZW-
..... Ow ....... ..w-.-ONflllM,,_.li a M,~Md ......... to~'ftlf"*--._

Our Ohana blazes trails


¥111>W artM•1' . . . . ,....,_ ....-:1MWOft. 9 ,..., ................ ...._._..

~ · f~ LlMHMC*•

Our values connect and 1nsp1re us

Trust
_,..,,,,......_,.,.. ........
~ ..................."
.....,.,. . _°"'ONN
OJ<,t~r Sore@S.~

.....
0...---... ...-
~.,,,~.,.,
lnnOlr.ltlOll
,_.,. _..,,.. .,_DNA
0wr weiw....,, w p I ... __
... ......... .. .,..
Equo ty

~·,,.,.·-~·

--·-
Oii. :pl ,.. . . . . . .ra- ,,...,,.,.,., to_.... 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 technologi-
cal 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 band-
width, and increased storage capabilities. Once in a while, a truly transformative
cbange occurs, such as the injection of artificial intelligence applications across the
enterprise o r a revolution in the basic tenets of computation with the nascent intro-
duction 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 a lready been discussed in this chapter and are covered in
more derail later in the book. The agile movement is a significant trend in informa-
tion technology thot all systems analysts should follow. It scarred as a response to
the heavyweig ht 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 com-
puting and data storage resources accessed from remote clients, rather like the main-
frame 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<> addi tional
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 U RE 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. Smart-
phones 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 service-
oriented. Prod uct-o riented firms manufactured computers, routers, or microchips,
while service-oriented companies included consultants, vendors, software devel-
opers, 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. 1lowever, 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. I0 Summa ry 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 profes-
sional 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 program-
mers 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 ha rdware, 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 everythi ng in the physical layer of the
informanon system. Sofrware consists of system software, which manages the hard-
ware components, and application software, which supports day-to-day business
operations. Data is rhe raw material chat an information system transforms into use-
ful 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.
M ost s ucces~ful companies offer a mix of produces, technical and financia l
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-busi ness
(B2B) transactions that use Internet-based digital marketplaces or private electro nic
data inte rchange (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 busi ness models that rep resent busi-
ness processes, which describe specific tra nsactions, events, tasks, and results. Ana-
lysts 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 representatio n 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. I0 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 a nd information needs.
Three popular system development approaches are structured analysis, which is a
tradi tional 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 a nalysis uses a series of phases, called the systems development lLfe
cycle (SDLC) that usually is shown as a waterfall model. Structured a nal ysis uses a n
overall plan, similar to a blueprint for construc ting a building, so it is called a predic-
ti ve approach. This method uses a set of process models co describe a system graphi-
cally and also addresses data o rganization and structure, relational database design,
and user inrerfacc issues.
Objecr-orienred anal ysis 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, called 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 pro-
duce a series of prototypes, which evolve into the finished system.
Regardless of the development stra tegy, 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 develop-
ment, systems suppo rt, user support, database administra tion, network administra-
tio n, 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 busi-
ness, chink critically, and commUI\icace effectively. Valuable credentials such as certi-
fications arc available to systems analysts. A systems analyst's responsibilities depend
on a company's o rganization, size, and culture. Systems analysts need to consider sal-
ary, location, a nd 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

Ke y 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 ntraditiona l ~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 graphica l 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>, ser-
vic~. 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 mamrn in 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 overal l framework for systems development. T he 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 merh-
ods 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 lev-
els 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 opporrn-
mr) 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\, communica-
tion< 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 manage-
me111 ~)Mem, and a rest framework.

~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-.. - "*-·,..,_o.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 rrnd inona l documcn r., to dc<ii;n la rg:e·,calc <rtcm' and convey information
hctwccn cnginee rs.
modeling J\ process th,11 produces a graphical representacion of a concept or process tbtlt systems devel-
opers 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 da ra,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).
procl~\ 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 meaningfu l infom1anon. ln data Aow diagram5, a
pmce'~ receives input darn and produces nurput tha r has a d ifferent content, form, o r hoch.
produc1 lifccycle management (Pl .M) See application lifocycle management (A LM.).
product oriented Comp,mie~ that manu facture computers, routecs, or microchips.
projccc management The proccs5 of planning, scheduling, mo ni roring, conrrolling, a nd reporting upon
the development of nn informarion sys1cm .
propcrtic' In oh1t.'Ct·o riemcd (0·0) analysis, characteristics rha t 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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, sup-
pliers. srockholdcrs. and members of the comrnuruty.
\tratt111c plan' The loni;-rani;c plans thar define t he 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 rradm on,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 ma terials, infor·
ma11on. and finances as they move from suppliers to customers, both w1dun and between com-
parues. 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 softwa re Programs that control the comp uter, including chc opcranng sysrcm. de' ice drive~ that
commumca1e \~uh hardware, and lo"·level utilities.
anal)\I\ and dcsii;n The process of developing information sy\rems that eff1.-crively uo;e hard-
\)>IClll\
ware, 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"a l model of
rhc new sr,rcm.
systems anal) st A person who pla ns, analyzes, and implemcnrs mformanon systems. T hey 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 t ho•c acnvirics a nd foncrions fit mro a partku lar mcthodolofly. The SD I 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Phase I Systems Planning

Key Terms 41

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 .1dmtn-
is1ra11on, 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 too ls rhar enable che sysccms analyst to deve lop, 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 ro les and respons ibilities 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 deve lopment. Prepare a lisr of the sires you vis-
ited and a ~ummary of the results.
3. Model-based systems engineering (MBSE) is one of che leading methods used by systems ana lyses 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 th is tool's capabi lities. 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 The chapter includes three "Case in Point"
chapter also explains why it is Important to understand discussion questions to help contextualize the concepts
business operations and requirements, how IT projects described in the text. The "Question of Ethics" asks the
support a company's overall strategic plan, how systems systems analyst to consider the Implications of granting
projects get started, and how systems analysts conduct preferential treatment to a system enhancement
a feasibility study and perform preliminary investiga- request when the request originates with a friend of the
tions, which concludes with a report to management. project's manager.
Fact-finding techniques that begin at this point and carry
over into later development phases are also described.

LEARNING OB ECTIVES CONTENTS


Wl1e11 you fi11isb this d1apter, you s/Jould be able 2. 1 Strategic Planning
to: Case in Point 2. 1: Pets for Rent
2.2 Strategic Planning Tools
I . Describe the strategic planning process.
2 .3 The Business Case
2. Conduct a SWOT analysis. 2 .4 Systems Requests
3. Explam how cools can support strategic 2 .5 Factors Affecting Systems Projects
planning. 2 .6 Processing Systems Reque~cs
4. Explain the concept of a business case. Case in Point 2.2: Actaway Airlines, Part One
5. Summarize the ~ix main rea~ons for systems 2 .7 Assessing Request Feasibility
requests. 2 .8 Setting Priorities
Case in Point 2.3: Arra way Airlines, Parr Two
6. Describe the two factors affecting systems
2 .9 The Preliminary Investigation
projects.
A Question of Ethics
7. Explain how systems requests are processed. 2 . 10 Summary
8. Explain how systems request feasibility is Key Term~
assessed. Exercises
9. Explain how systems requests arc prioritized.
I 0. Conduct a preliminary invesrigarion.

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, strate-


gies, 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-rela ted proposal, project, and systems
request ro determine if it presents a strong business case, or justification.
T he following sections provide an overview o f strategic planning, a description of
SWOT analysis, and a look at the role of the IT d epartment.

2. 1. 1 Strate gic Planning Ove rview


Strategic plan ning starts with a missio n ~tatemen t that reflects rhe firm's vision, pur-
pose, and v:ilues. Mission statements usually focus o n lo ng-term cha llenges and goa ls,
the importance of the firm's stakeholders, :rn d a commitment to the fi rm's ro le 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-ter m goals and
objectives. For example, the company might establish one-year, three-year, and five-
year 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 facto r 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 objec-
tives 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 com-
radery. 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 st rengths, weaknesses, opportunities, and threats. A SWOT a na lysis 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

An enterprise SWOT analysis us ually 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 pos-
sible risks?
A SWOT analysis examines a
firm's technical, human, and finan-
cial resources. In Figure 2-1, the
butlered lists show samples of rypical
STRENGTHS WEAKNESSES strengths, wca kncsscs, opportu nities,
• Excellent web design staff • Still using 58\/eral legacy and threats for an organization con-
• low systems analyst systems sidering cxp:tnding their web-based
turnover • Budget Increase was turned online operations.
• Recently upgraded notwork down
• Documentation needs updaUng As the SWOT process conrin-
ues, management reviews specific
resources, business operations, and
valm1blc assets. For example, suppose
OPPORTUNmES THREATS rhat the company owns an imporranr
patent. A SWOT review for rhe parent
• Well-pos1Uoned for expansion • Aggressiv e new web might resemble Figure 2-2.
• Can be first with new competition
software • Impact ol new FCC rules There is no srandard approach to
• High potenbal tor B2B • Other firms oller bener strategic planning. Some managers
growth benefits
believe that a firm's mi sion srate-
ment !.hould contain an inspirational
message to its stakeholders. Others
feel that unless a firm starts with a
FIGURE 2 - 1 A SWOT analysis might produce l"e$Ults similar to those realistic SWOT assessment, ic might
shown here. 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 partme nt


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 ana lysts should focus on the larger, strategic role of the IT depart-
ment even as they carry out their day-to-da y technical tasks.
Experienced analysts know that planning is essentia l for IT project success, and it
must srarr as early as possible. Ca reful 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

2.3 The Business Case 47

During the planning process, manage- SWOT Analysis of a Corporate Patent


ment and IT should be closely linked. In
the past, a typical IT department handled Strengths Weaknesses
all aspects of systems development and
consulted uc;er~ only when, and if, the • Our patent covers valuable • Our patent has a hmrted Me
technology that we can use in Whetl 11 expires. the technology
depamnent wanted user input. Today, popular products will no longer be prot8C1ed
systems development 1c; much more
team-onenred. New approaches to systems
development, such as agile methods, Patent
typically involve groups of users, managers, Opportunities Threats
and IT staff working together right from
• We can use the technology on • A compehtor might develop
the start of the project. more products, license 11 to similar technology thal does
Although ream-oriented development others, or seek more patents. not legally lnfnnge our patent.
is the norm, some companies still sec the
role of the IT department as a gatekeeper,
responsible for screening and evaluating FIGURE 2-2 This SWOT analysis example focuses on a specific asset: a
systems requests. Should the IT department company patent.
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 per-
son 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 cvalua-
rion team or a srsrems review committee.

22 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 plan-
ning activities. Some analyses srick to tradicional text-based methods, using tvl icrosofc
\'(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 ele-
mencs, 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 cloud-
based 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 tech-
niques 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 stra-
tegic 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 2 Analyzing the Business Case

48 2.3 The Business Case

Ahal - - _, -
- -0
_,, .....

.. ...,............. .,,... ... .......... I"'


Strategy first
- - - -
-
.... ....-.;,~ -=---

· -~-- ·- - .-- ••• • •

- . ._..,_,
_.,.
,_ ............
.......... .,_, ..
~

-..
...,., -"«.,...
--
c.....
.,............,..........

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 proj-
ect'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 sam-
ples 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 Stronger


Controls
The starting point for most information
systems projects is called a systems request,
which is a formal way of asking for IT
More Reduced
support. A srsrems requesr might propose Suppo<1 Cos1
enhancements for an existing system, the
correction of problems, the replacemenr
of an older sy rem, or rhe developmenr of Systems
an enrirel)• new informarion sysrem char is Request
needed ro support a company's cur renr and
future busine s need .
As Figure 2-4 shows, rhe six main reasons
Improved
Service
t/
_J
More
lnlormatt~
I
for ~ystems request are stronger controls,
reduced cost, more information, bener per-
formance, improved service to customers, and
more support for new produces and services.
Better
Performance
J
STRONGER CONTROLS: A system must FIGURE 2-4 Six main reasons for systems requests.
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 con-
trols 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 mini-
mize data entry errors whenever possible.
For example, if a user enters an invalid
FIGURE 2-5 Apple Face ID uses advanced machine leamirig co recognize users.
customer number, the order processing
system should reject the entry immedi-
ately and prompt the user to enter a valid
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 insuf-


ficienc, incomple re, 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 require-
mencs. 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 cus-
tomers or users within the company. For instance, allowing mutual fund investors ro
check their acco unt balances on a website, storing data on rental car customer prefer-
ences, 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 a utomacic upgrade service for subscribers; or a package deliv-
ery 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 importa nt 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 usu-
ally 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
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Phase I Systems Planning

2.5 Factors Affecting Systems Projects 51

External Fact ors


l..__ _ _ _~J
Teclinology Lr------...
Government Suppliers

The Economy l. Custome~

------
FIGURE 2·6 Internal and CKternal factors that affect IT projecrs.
Competitors JL- - - - - -

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 correc-
tions and changes that cannot support the company's overa ll 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 financ ial 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

2.S.2 External Factors


Exrernal facrors include technology, suppliers, cusromers, comperiror<;, the economy,
and government.
Changing technology is a major force affecting business and soci-
TECHNOLOGY:
ety in general. For example, the rapid growth of telecommunications, coupled with
increased computing power and continuous miniaturization of electronic compo-
nents, 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 vi rtually all products. Some industry experts predict that
bar code technology, which is over 40 years o ld, will be overshadowed
in the furure by electronic product code (EPC) technology that uses
RF ID 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. T hey contain more information than
traditional ba r codes, but less than RF ID rags. T hey do ha vc the advan-
tage of being less expensive to use than RFID rags, and they can be
printed o n a lmost an ything-including online advertisements.
The Internet-of-Things (JOT) is a newer development that involves
FIGURE 2·7 QR Code. almost all electronic devices con1municating with one another over a com-
puter network. The communication can use radio signal~, as with RFID
cags, digical messages, or other means. loT devices can act as sensors, send-
ing important information to centralized data storage and procetising nodes. IoT 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
t hat suppliers code their parts in a certain manner to march rhc auto company's inven-
tor)' 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 effi-
cient, 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

......
,....~.....nc:rwe,..;

-..............
__...._,.,._...,..,.
----~----- _........
,.._..___,.
......._.___..........
...
..__ .......
._.. ...__
---
--
----..... ......
.....--------.
_,..._

---·-- ._ . ..............
....-......."..__
FIGURE 2·8 IBM 81ockcha1n.
Sourt• »1(
-
.-

(....,..... J:gi ( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

2.5 Factors Affecting Systems Projects 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 track-
ing. 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 dig-
ital 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 other-
wise 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 sam-
ple 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 instruc-
tions. It shou ld include enough space for all required information and )hould indicate
what supporting documents
Tech Support Request Sysleni 1/••r1,.:.. ·"~' ::..·, ~· ,,, "'·'"''· 1
are needed. Most companies
use onJine systems request
Submit Roqueet forms rh:H users submit elec-
tronically because the form can
be processed automatically.
When a systems request
form is received, a systems ana-
lyst or IT manager examines it
o-awio . . ~
_ _ ., olllllO Cl• 7 • ) 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 tiga-
tion. omerimes, a situation
o a - .... o ... requires an immediate response.
For example, if the problem
involves a mission-critical sys-
FIGURE 2- 10 Example of an onhne systems request form. tem, 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 throug h automated fo rms becomes significant,
or if the requests can origi nate from intern al sou rces as well as extern a I customers,
special-purpose systems request tools can be used to help manage t he work flow. For
example, Figure 2-'l 1 ill ustrates the service request capa bilities from l'nregrify that cap-
tures, manages, a nd routes requests to systems analysts based on definable business
rules. In th is way, req uests 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 pri-
orities more effectively t ban 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 C . ··• •' "' .... c • • • • '·' p ::::. GM11o.rno
the IT director and several manag-
ers or representarives from other Service Request Management
departmencs. The IT dirccror usu-
all)' serve:. as a technical consultant
co ensure that committee members
are aware of crucial issues, prob- -·----_...................
~ ...........
.... .............. ......
&"!ilil• ~ ---·-----~---- .... · - -

---
lems, and opportunities. ...,.._,___...,
.. ............. ........ -.........................
....

Although a committee offers


,... _...
- ........ - - -..... ,..._ ...................... ~o..
_..
._ ~

many advantages, some disadvan- --~


... . . . . . . . . . ;ill . . . . . . . . . _ . . . . . . . . . . . ..,.
_ __

tagei. exist. For example, action ......... s..1.....-r .. -


on requescs must wait unri l the
committee meets. Another poten-
tial disadva ntage of a committee is
that members might favor projects
-- -- -
req uested by their own departments,
and internal polit ical differences
could delay important decisio ns. --
M any sma ller companies re ly FIGURE 2- 11 A service request management system from lntegrify.
on one person to evaluate sysrem
requests instead of a committee. If
only one person has the necessary IT skills and ex perience, t hat person must consult
closely with users and managers throughout t he 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 account ing 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 p riorities be determined? To answer chose questions, the individual or the
commirtce m use assess rhc feasibiliry of each request.

__ , . . . - .. . ~ '
-- ---- -

.CASEJN;.P.OINfl:,.2.2: ,ATITAWAY 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 oper-
ational 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. tomor-
row. 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

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 sys-
tems requests that arc not feasible. For example, a request would not be feasible if it
required hardware or software that the company al ready 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 compurer-
based 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 sched-
ule 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
o rder, 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 ana-
lyst 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?
• Is rhe proposal economically desirable?
What are the projected saving~ and costs?
0pe1"8tlonal
Are ocher intangible factors involved, such
• WiH If be easy to
team and vse?
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
Schedule Economic within an acceptable rime frame?
• Can we do 11in
time?
Fualble? =:=a • Will b enefits
e'Kceed costs? To obtain mo re information about a
systems request, ini tial fact-finding migh t
be accomplished by stud ying o rganization
charts, performing interviews, reviewing
current d ocumentation, observing oper-
ations, and surveying users. Sometimes,
Technlcel
developing prototypes can provide addi-
• Do we have the
tech resources? tional insight into the feasibility of the
request. If the systems request is approved,
FIGURE l -1l A feasibility study examines operational, technical, economic, more intensive face-finding will continue
and schedule factors. during the systems analysis phase.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 feas ibility 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 cur-
rent !>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 out-
weigh the est11nated coses usually considered the total cost of o wnenhip ( fCO),
whic h 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 a reas:
• 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 tan-
gible 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 elimi-
nates 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 mrer-
face properl y with external systems operated by customer~ and suppliers?
• Will the combination of hardware and software supply adequate performance?
Do clear expecta tions 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 ha rdware, software, or expertise becomes available. Develop-
ment costs might decrease, or the val ue of benefits might increase enough that a sys-
tems request eventua lly 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:-..•~-".....-""'*"....,.._...,.. ..
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 sys-
tem 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 res ul t 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 measu re 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~crecion 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:i t waiting for com111irtee approval delays critical nondiscrecionary projects unneces-
sarily. Others believe t bat submitting all requests to the systems review keeps the com-
mittee aware of all projects that compete for IT resources. As a resul t, 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 premi-
ums. 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 prelimina ry investigation to study the systems request


and recommend specific action. After obtain ing 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 opportu-
nity, 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
Problem or
people know about chc invcstigarion and explain the role of the Opportunity
Benefits
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 Projec1 Scope
Costs
process. and Cons1ra1nts
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 encoun-
ter some user resistance during a preliminary investigation.
Employee attitudes and reactions arc important and must be Report to Management J
considered.
When interacting with users, use t he word problem care- FIGURE 2- 13 Model ofa preliminary
Investigation. Note the Importance of fact-finding
fully, because ir has a negative meaning. When users are asked In each of the four areas.
about problems, some will stress current system limita tions
rather than desirable new features or enha ncements. Instead
of focusing on difficulties, question users about additional capabi lity 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 Pe rforming 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.


Step I: Understand t he Problem or O pportunity
lf the systems request mvolves a new informacion system Undersland the problem or opponun11y
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
• Dehne fhe pro1ect sc;ope and consframts

Perform lact-fond1ng
_J
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
departmen ts, users, and business processes are involved
• • Analyze organlzauon charts
• Review documentauon
• Observe operaflons
• Conducf a user survey

must be determined.
Jn many cases, the systems request does not reveal
0 Study usablhty, cost, benefit. and schedule data

the underlying problem, bur only a symptom. For Evaluate feaslbllity


example, a request to invest igate centralized process- • Operational
ing delays might reveal improper scheduling practices 0 • Technical
• Economic
rather than hardware problems. Similarly, a request • Schedule
for analysis of customer complaints might disclose a
lack of sales representative training, rather than prob- FIGURE 2- 1 ~ Five main steps in a typical preliminary
lems with the product. 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


diag ram, 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 M orale, 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 anal yst 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 - 1S 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 sta tement, 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. T his 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 au thorization, 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 some-
times useful. The scope of the project also establishes the boundaries of the prelim-
inary 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 con~traint 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 t he 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 srm-
bol thac represents the consrrainr, as follows:

Sample Constrai nts Shown byTlming, Type, and Urgency

("'E;';'mple A: New IRS Example B: Sometime neX1


I ~must be used 1n
I !he payroll system as
as poSSlble
year our largest cus1omer wdl
require a seounty code for all
onhne transactlOlls

Present Future
I • Mandatory constraint

£ • Desirable constraint

Internal

Example C: Managemen1 Example 0 : Starting next Example E: To reduce raw material


prefers that the project be week, the marketing system costs. we should build supply chain
completed now rather must track all repeat visits management capabthty Into lhe next
than next quarter to the webslle. 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 con-
straints 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 object ive of face- finding is to gather data about project usability, costs, bene-
fits, ;ind schedules. Fact-finding involves various techniques, which arc described
below. Depending on what info rmation is need ed to investigate the systems
request, fact-finding mig ht cons ume several hours, days, or weeks. For example, a
change in a report forma t o r data entry screen might requ ire a single telephone call
or emai l message to a use r, whereas a new inventory system wou ld involve a series
of interviews. During fact- finding, the analyst might analyze organization charts,
conduct interviews, review current d ocumentation, 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 infor-
mation should be obtained from department personnel and construct the charts, as
shown in Figure 2-17.
Even when c harts are available, their accuracy should be ve rified. Keep in mind
t hat an organization chart shows formal reporting relationships but nor the informal
alignment of a group, which also is important.

CONDUCT INTERVIEWS: The


Customer Service Department primary merhod of obraining
informatio n during the preliminary
investigation is the interview. The
interviewing process involves a
series of steps:
1. Determine the people to
interview.
2. Establish objecri vcs for t he
interview.

-
3. Develop interview questions.
4. Prepare for the interview.
~ 5. Conduct the interview.
FIGURE 2- 17 Specialo:z.ed tools such as MlcrosoftVisoo an be used to draw 6. Document the interview.
organizational charu. but general purpose presentation tools such as Microsoft
PowerPoint shown here can also be used. 7. Evaluate rhe interview.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 mvestiga-
non 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 man-
agers 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 con-
firm that the informa tion is accurate a nd 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 infor-


mation from a larger group can be obtained by conducting a user survey. In this
case, design a form that users complete and reru rn 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
- -- -..... -
FIGURE l -18 A Pareto chart displays the causes ofa problem. in priority
problems, so that necessary improvements order. so an analyst can tackle the most lmpon:ant cases first. In this example.
can be made. 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, sup-
pose 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
I

-
p
'

·-
.A

- - •
- •
~

.. Network Response Time vs. Number of Users

.. .

••
..

..
•• • •
--- • • • --
• 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:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

2.9 The Preliminary Investigation 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 feasibilit y 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 informa tion must be obta ined, 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 wi th 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 mea ns that a system will be used effectively, this is a vital area
of concern.

ECONOMIC FEASIBILITY: Using che fact-findi ng data, financia l ana lysis tools can
be applied to :i~sess feas ihiliry. The cost-benefit da ra 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.

TECHN ICAL FEASIBILITY: The fact-finding data should identify the hardware, soft-
ware, 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 expec-
tations 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 ext ra 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 rec-
ommendations, which can be conveying to management in a report and/or in a pre-
sentation. 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
actio n, which is a summary of che pi:oject reques t and a specific recommenda tion.
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 res ults of che preliminar)' inves-
tigation, including a descriptjoa of the project's scope, constraints, and
feasibiliry.
• Recommendations-a summary of the project request and a specific recom-
mendation. 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 a lso shou ld be noted.
• Expected Benefits-this section incl udes anticipated tangible and intangible
benefits and a timetable that shows when they are to occur.
• Appendix- an ap pendix is included in the report if supporting information
must be attac hed. 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 t he 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 Summa ry 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 direc-
tor's request. and to persuade the other members to approve it. The IT manager wanted
to discuss the merits of the request, but the discuss ion 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)' stake-
holders. 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 proj-
ect 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 exter-
nal factors affect syscems projects, such as user requests, top management directives,
existing sy~tems, the IT depa rtment, software and hardware vendors, technology, cu~­
tomers, competitors, the economy, and government.
Duri ng the preliminary investigation, the analyst evaluates the systems request and
determine~ whether the project is feasible from an o perational, technical, economic,
and schedule standpoi nt. 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 oppor-
tunity; 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

Ke y 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;11ied d1scre-
rionJry. 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 vari-
abl~. 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 o utcomes 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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. H ow 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/o r 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 ll y organize information. ldencify a tool rhat supports the crc-
acion 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 The chapter includes three "Case in Point" discussion
phase of the SDLC. This chapter describes project q,uestions to help contextualize the concepts described
management and explains how to plan, schedule, in the teXt. The "Question or Ethics" considers the
monitor, and report on IT projects. implications of raising awareness of a project going astray
even when the project manager Is reluctant to do so.

LEARNING OBJECTIVES CONTENTS


When you fi11ish this chapter, you shottld be able 3.1 Overview of Project Nlanagemcnt
to: 3.2 Creating a Work Breakdown Structure
Case in Point 3.J: Sunr1~e Software
1. Wustrate pro1ect priorities in the form of a proj-
3.3 Task Patterns
ect triangle
Case in Point 3.2: Parallel Sernces
2. E..xplain project planning, scheduling, monitor- 3.4 The Critical Path
ing, and reporting 3 .5 Project Monitoring and Control
3. Create a work breakdown srrucrure 3.6 Reporting
4. Identify cask pattern~ 3 .7 Project ~1anagement Software
5. Calculate a project's crirical parh 3 .8 Risk Management
3 .9 Managing for Succes~
6. Describe project monitoring and concrol tech- Case in Point 3.3: Ju ~r-in-lime Software
niques Lo keep a project on sc hedule
A Question of Ethics
7. Explain how project starus is reported 3.10 Summary
8. Describe project management sofrware and how Key Terms
it can be of assisrance Exercises
9. Create a risk m:magcmcnt plan
10. Describe why projects sometimes fail

r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
Phase I Systems Planning

3.1 Overview of Project Management 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 tech-
niques arc needed. A project manager is also needed, someone who is responsible for
overseeing all relevant tasks. Project management for IT professionals includes plan-
ning, 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 sched-
ule 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 man-
agement 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.
PICK ANY TWO
3. 1.2 W hat Is a ProjectTriangle? FIGURE l· I You can't get
Figure 3-1 shows a very simple example of a project triangle. for each everything you want; you have to
make chokes.
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 rec-
ognize 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 fac-
tors. Most successful project managers rely on personal experi-
ence, 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. Time
It might be a budget cast in stone, a scope that is inflexible, FIGURE l·l A typical project triangle includes
or a schedule driven by factors beyond the firm's control. coSt. scope. and time.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 pro ject 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 requi rements or want changes that would require
additional time or expense.
Project managers typically perforn1 four activities or functions: planning, schedul-
ing, monitoring, and reporti11g:
• Project planning includes identifying all project rasks and esrimaring rhe com-
pletion 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 under-
stood: Gantt charts and PERT/CPM charts.

3.2.1 G antt 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 rep-
resents a sec of tasks. For example, the Gantt chart in Figure 3-3 displays five casks
in a vertical arra y, with time shown on the horizontal axis. The position of the bar
shows the planned starti ng a nd 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 sim-
plify a complex project by combining several acriviries into a wsk gro up 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
on ly about 80% done and is running behind schedule; Task 3 should have started,
bur no work has been done; Task 4 actuall y 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 pro-
vide enough detailed information, which is necessary when managing a complex proj-
ect. 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 Eval uation Re' iew T echniq u e (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 r itical Path M eth o d (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 b ou om-up ccchn iq ue because it analyzes a large, complex projecr as a
series of individual tasks, just as a pyramid is builr from the borcom up using indi-
vidual 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 o th er siruations, several tasks can be performed at th e
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 d iagran1, is shown in
che lower screen in Figure 3-4.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ --......
...........
Chapter 3 Managing Systems Projects

78 3.2 Creating a Work Breakdown Structure

- .. - . . .... -
w ~--- - --- Although a Gantt charr offers a
.. ... ·-· - ... - ~- ...·---- .
... - -- - --- =--.
- - L.:
valuable snapshor view of the proj-
ecr, PERT charts are more useful for

_ ,c.... .. _
Ii . ....__..._ _ _ ---- -scheduling, moniroring, and controlling
- a

the actual work. \'(.lith a PFRT chart,


a projec t manager can converr task
I ..,,..._.............,..
• ....c..... ........
-·-----~
.,. . (_...._...........
~

,.. .... -. ._. ,.._ ..._ ..._ ......


= . ----
·- .
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

• '-+ •
1 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
'""' S kNI out lntorvlow t<hedulo
Gaorr charts are not mutually exclusive
Stut Tuo 9/3/19 10 5
fon11h Tue t/S/19 Dut I d• v recltniques, and project managers often
Ars use both methods.
FigLtre 3 -4 shows both chart types.
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 T he top screen is a Gantt chart with six
project. When the user mouses over the summary box for Task 5, the derails t asks. T he PERT chart below it shows
become visible. rhe same project, using a separate box
for each rask instead of a horizon-
tal 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 bot-
tom of che figure. How co create PERT charts is explained in a later section.

3.2.l Ide ntifying Tasks in a Work Breakdown Structure


A WB musr clearly identify each task and include an estimated duration. A task,
or an acrivi t y, 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 con-
ducting interviews, designing a report, select ing software, waiting for the delivery
of eq uipment, or training users. Tasks are basic units of work that the project
manager plans, schedules, and mon itors-so they should be relatively small and
manageable.
In add ition ro rasks, every project has events, or mile~tones. An event, or a mile-
stone, 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% o f program test-
ing" would not be useful informat ion unless it could be determined exactly w hen that
even c wi II occur.
Figure 3-5 shows casks and events chat might be invo lved in che creation, dis-
tribution, and tabulation of a questionnaire. Note that the beginning ::tnd end of
e::1ch cas k 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 ( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f •,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase I Systems Planning

3.2 Creating a Work Breakdown Structure 79

All
Start work oo
ques110no8"•

Tabulate Prepare repon


Prepare Awart return of questionnaJre 00
quesbonnaire questioma&res responses 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 so unds 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, First, reserve the meeting room Then order
similar to the one shown in Figure 3-7, with columns for cask the marketing materials and brief the
managers After the bne~ngs. send out
number, description, duration, and p redecessor ca sks, which customer emails and upload program to the
muse be compleced before anocher rask can scan. 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
ESTIMATING TASK DURATION: Task duration can be hours, materiats have emved and the software is ready,
days, or wceks--dependmg on the project. Because che following do a dress rehearsal.
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 Firs1. rr; ve t mr
o.... Then orcJer
example, if it will cake one person 20 days to perform a particular t> ,.,. '"'9 ,..,
and b · I the
manat "' After lhe bnefings, nd out
cask, it might not be t rue that two people couJd complete chc same cus:onn r m s and ''' IOad progrNn to It>"
task in 10 days or that I0 people could perform tbe task in two app store. When the emails are soot and the
days. Some tasks can be divided evenly so it is possible to use dif- program is available on the a.pp store ready,
ioad tt>e ne,. ul!wa,,. When the marketing
ferent combinations of time and people--up to a point-bur not erials have amved and the software 1s ready.
all. in most sysrems analysis rasks, rime and people are not inter· a dr'"' rthearsal.
changeable. If one ana lyst needs two hours to interview a user, two -----
analysrs a lso will need two hours co do the same interview.
Project managers often use a weighted formula for estimating • First, reserve tho mooting room.
the durarion of each cask. T he project manager fixst ma kes three • Then order rhe mar~ellflg materi&/$ and brief
the manage1S.
time esrimatcl> for each cask: an optimisric, or bes t-case e~ timatc
• Aller the briefings, sand out customer omalls
(B), a prob ablc-ca\c e~ timate (P), and a pessimisric, or wo rse-case and upload program to the app store.
e~ timatc (W ). T he manager rhen assigns a weight, which is an • When the emails are sent and the program is
importance value, to each estimate. The weight can vary, bur a available on the opp store ready, load !he
common approach i'i to use a ratio of B = 1, P = 4, and W = J. now solrware.
Tbe expected task duration is calculated as follows: • When the mart<ehng materials have arrived
and the software Is ready, do a dre~s rohearsal.

(B+4P+W) FIGURE l-6 The three versions show how to


transform a wk scatement into a list of specific
6 casks for a work breakdown strucwre.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ --......
...........
Chapter 3 Managing Systems Projects

80 3.2 Creating a Work Breakdow n Structure


Description Duration Predecessor
(Days) Tasks
Reserve the meeting room
2 O rder the marketing materials
3 Brief the managers
4 Send out customer emails
5 Upload program to the app store ......._ _ ___.._ _ _ __.....
6 Load the new software
7 Do a dress rehearsal

FIG URE 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 form ula, the expected task dura rion 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 I00 person-days. does it matter whethe r two people in SO days,
five peo ple 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,
o ne 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"
equat ion?Taking the concept a step further. is there an optimum numbe r 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. 1luman resources
3. Experience with similar projects
4. Constraints

PROJECT SIZE: As described in Chapter 1, infom1acion systems have various charactcr-


iscics char affect their complex:iry and cost. ln addition to considering chose factors, a proj-
ect 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>_... ........ _ .. ~ ........................._ .... ._
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 vacan-
cies, 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 informa-
tion 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 prelim-
inary investigation. A constraint is a condition, restriction, or requirement chat the sys-
tem 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 require-
ments that can be achieved realistically within the required constraints. In the absence of
constraints, the project manager simply calculates the resources needed. 1lowever, if con-
straints 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

Description Duration Predecessor


(Days) Tasks
Reserve the meeting room
2 Order the marketing materials 9
3 Brief the managers 2
Send out customer emails 3
"s Upload program to the app store 3
6 Load the new software 2
7 Do a dress rehearsal
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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~ - .,.-"~ ...........
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, Tas k 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 resem-
ble Figure 3-9.

....
.. --·. -
·--- ·-·-
.
--
. ---·-- -
·- ·- . .. _____ . .. .
....
- - - :=,.::..--- ... ·-
......
....... .... .,_ ,_ _
-... .. "'\
::--- ::. B , ::

_
.. e.. •
..................... .... ........
ct:= "-:- #,_,.,'-

_.._____
I

...
.....
I

-
t ~ • · ~.I -

;
• o • ....,_
- :J .....
...,_
--:::~

I
I
.....
...................
...............
............... ·-
·-
·-
..... ...
.... ...

.
.
- ,,_...... .......,........,
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, la rge 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 Mode l


In a PERT/CPM chart, project tasks a re 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 NAME: The task name should be brief and descriptive, bur it
docs not ha ve to be uJlique in the project. For example, a cask named
Conducr Interviews might occur in several phases of the project.
TASK BOX FORMAT
TASK ID: The task ID can be a number or code that provides unique
Task Name id en ti ficati<>n.

TASK DURATION: The duration is the amount of time it will rake to


Start Day/Date Task ID
complete a task, which is not necessarily the same as rhe e lapsed rime.
Finish Day/Date Task DuratlOO For example, a cask that takes eight botirs of effort to complete would
be done in o ne day by a person dedicated lOOo/o, but if the person
FIGURE 3-10 Each section of the task assigned this task is only working 50% on this project, the task would
box concains important Information take rwo days elapsed time to complete. All tasks must use the same
about the cask. including the Task Name. time units, which can be hours, days, weeks, or months, depending on
Task ID. Task Duration. Start Day/Date.
and Fmish Day/Date. 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 com-
pletion. 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 FIGURE l - 11 In a relay race. each runner is
example, Figure 3-12 shows that Task 2 depends on Task 1, dependent on the preceding runner and cannot start
because Task 2 can nor start unril Task 1 is completed. In this until me earlier finishes.
Y- Fn
example, the finish time of Task 1, Day 5, con-
trols the start dare of Task 2, which is Day 6. E XA~I PLE OF A DEPEN DE NT TASK

MULTIPLE SUCCESSOR TASKS: \Xlhen Se\•eral Prepare Oull"'8 CtNlllOocumenl


tasks can start at the same time, each 1s cilled a
concurrent ta~!.. . Often, rwo or more concurrent
..
Start Day 1 ID 1 Start Day6 ID. 2
tasks depend on a single prior task, which is called An1sh Day 14 Dur 9
Finish. Day S Dur S
a predeces~or cask. In this situation, each concur-
rent task is called a ~ucc~sor task. In the example FIGURE l-12 This example of a dependent iask shows that the fontsh
shown in Figure 3 -13, ~ucces or Tasks 2 and 3 both cme ofTask I. Day s. controls me start date of Task 2. which tS Day 6.
can begin as soon as Task I is finished. ore that
the finish time for Task l determines the start time
EXAMPLE O F MULTIPL E SUCCE SSOR TASKS
for both Tasks 2 and 3. In other words, the earliest
that Task l can finish is Day 30, so Day 31 is the
Arrange Interviews
earliest that Tasks 2 and 3 can start.

MULTIPLE PREDECESSOR TASKS: Suppose Develop Plan ,J4 S1ar1: Day 31 ID: 2

t hat a task requires two o r more prior tasks to Finish· Day 60 Dur30
be completed before it can start. Figure 3- 14 Slart Day 1 ID: 1
shows that example because Task 3 cannot begin
Finish: Day 30 Dur 30
until Tasks 1 and 2 arc both completed. Since ~ Design Survey
the rwo tasks might not finish at the same time,
the longest (larcsr) predecessor rask becomes the Start Day 31 ID 3
controlling factor. Note char rhe srarr for Task 3 Finish Dey 40 Dur 10
is Day 16, nor Day 6. \'V'hy is chis so? Because
Task 3 depends on two predecessor tasks, Tasks 1 FIGURE 3- 1l This example of multiple successor wlc.s shows that me
and 2, Task 3 cannot begin until the later of those 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 tasks is complete. Therefore, the start time for a
successor rask must be the latest {largest} finish
aic.ri Authonullon time for any of its preceding rasks. In the example
shown, Task I ends on Da)' 15, while Task 2 ends
Start Day 1 10 1 on Day 5, so Task 1 control~ the srarr time for
[\
Fi111Sh; Day 15 °"' 15
Conduct 1i ......... Task 3.
Task pattern type~ are idenufied by looking care-
Cnlale Job Oeecripl!On
Start Day 16 ID 3 fully at the wording of the task sratemcnt. Words
~ Anlsh: Day 45 Our30 like then, when, or and are action words that
Slllrt Day 1 10 2
signal a sequence of events. Here are three simple
examples:
Aoish Oay5 0urs
• Do Task 1, then do Task 2 describes dependent
FIGURE 3· 14 This example of multiple predecessor tasks shows tasks char must be completed one after rhe
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
ocher.
ends on Day IS. while Task 2 ends on Day S, so Task I controls the • When Task 2 is finished, start rwo tasks: Task
start time for Task 3. 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 rounder-
stand 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 2

1 I ·I 2
4

FIGURE 3 - 1S 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 com-
plete, 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 avail-
ability 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 r isk overmanaglng the work
and spending more t ime on mon itoring than actually performing the tasks. As a mem-
ber of the team, wh ich 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 com-
pletion dare of the overall projecr. If any cask on rhe critical path faUs behind sched-
ule, the entire projecr will be delayed.
For example, suppose that Joan and Jim are invited to someone's home for din-
ner. 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- J8 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

~
ID: 3
)" Dur : 5
Obtain Authorization Hire Analysl 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 crir-
ical 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

)" Start: ~
Day 41 ID: 3
Finish: Day 45 Dur: 5
Obtain Authorization Hire Analyst Announce Training

Start: Day 1 ID. 1


_. Start. Day 11 ID:2 Start Day 66 ID: 5
Finish: Day 1O 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 com-
pletion 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 program-
mers, 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 dela ys. By monitoring and controlling the work, the project man-
ager tries to anticipate problems, avoid them or minimize their impact, ide ntify poten-
tial 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 com-
pleted 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 criti-
cal 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 3 Managing Systems Projects

88 3.6 Reporting

that can be undersrood easily, adds comments and explanations if needed, and s ub-
mits 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 infor-
mation, 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 s upervisor, 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 graphically.

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 man-
ager 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, a nd cost tracking. As shown in Figure 3-2 1,
M icrosoft Pro ject is a full -featured program that holds the domi nant 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 too l that is available on multiple platforms (Windows, Mac OS X, and
Linux). It can produce Ga ntt 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 win-
dow, 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 devel-
opment. Trello, shown in Figure 3-23, is aoorher project management tool that is tai-
lored 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) Allignfl St11u1 Epic E111m1110n 0

II 11> ... p""' ...., ~... "'9 1 c1o,.


""""'°Pon:..
" ii ' '!M
HOllWl>lge OJllayo

"-••Part. IOM brnp Fdrurt Ollllyt

,....,.
Spr1m 1 (IA11 _ , s..1... Epoc Ettlf'l'lll~ 0

I ,,,... .......
---Ito-.
lkJ9 02doft

I Hew I g 01-,.

-
u.,.

FIGURE 3-22 Monday is a project management tool that is tailored toward Mac users.
Sour«< ...,

............ _
• a
,_
Don'•--~

n
-
... U t ............ ~CNdft!A
,,.,,...n.n orH'*9 1 filil "°"1 • Ofll.
• tt• fD Ill
~
,_., o..g. a

-
_____
~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 91

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 signifi-
cant 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.

FIGU RE 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, depen-
dencies, 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 typ-
ical 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 da y-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 deter-
mine 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


. ..
.....
·~~..........
.........................,.......
.... ,o.e-,,,.,...............
....
~-

• .,.-.-_....,...
u ....

.,..,.....
•9\"

-
I ...........,.._.....
....,......
...·-... '''
i
----
-·-
~.-.........

_ • .,....... ....................... t_.


...................
... fl'lllWllll....... ·-
. ....

---
PERT Chart View

..............
-···· .
- .. --
--·
- ..._
......... u
••

h_..,, ...
-·--
-•ft• •• _
-
.. --
....... ...,_
........ ·~-
~
~

.. .-.......
......."" . ....
• •.
-
.... ~
.... fl'Wl1
.........
., •
-......·
'+
...
,._,., WV.• .... I...,.

C11lendarVlew

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 ( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 t hat 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 ·w ould depend on the specific proj-
Cl't, but most lists would include a mean~ of identification, and a brief descrip-
tion of the risk, what might cause it to occur, who would be responsible for
responding, and t he potential impact of the ris k.
• Analyze the risks. This typically is a rwo-step process: Qua litative 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 dis-
play 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 Risk Matrix High impact •


Low probability High probability

10..->o~---~-------~~~~~~~
Medium impact
9 Medium probabt~ty
8 •
7
t;
"' 8
~ 5 Low Impact
-" High probability
.!! 4
a:
3
2
1
0 *-~~~~~~~~~~~~~..;..-~~~~--!
.--~'"-----. 2 3 4 5 6 7 8 9 10
Low Impact
Low probabiltty Risk Probability

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, o r 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 appropri-
ate acnon.
• Monitor risks. This activity is ongoing throughout the risk management pro-
cess. Ir is important to conduct a continuous tracking process that can identify
new risks, note changes in existing risks, a nd update any other areas of rhe risk
management pla11.
Forrunarely, there is a wide variety of risk ma nagement ~ofrware available to help
a project manager with these casks. Most packages allow a project manager to assign
specific dares as constra ints, a lign task dependencies, note external factors rh a t might
affect a task, track progress, and displa)' casks that a re 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 suc-
ces-;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
t he crincal factor. When a project manager first recognizes that a project 1s 111 trouble,
what options arc available? Alternatives can include t rimming the project require-
ments, 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 o n time and within budget if sev-
eral less critical requirements are trimmed. The system can be delivered to satisfy the
mosr necessary requ iremen ts, and additional features can be added later as a part of a
ma intenance or enhancement project.
If a project is in trouble because of a lack of resources or o rga nizational support,
management 1night be willing to give rhe project more commitment and higher pri-
ority. For example, ma nagement might agree to add mo re people to a project that is
behind schedule. Adding staff, however, will reduce the project's completio n time o nly
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, tem-
porary he lp might be o bta ined from IT consultants or part-time staff. Adding sraff
can mean t rai ning a nd o rienting 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 add ing 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 empl oyee~ whose own productiviry was
reduced according!)'.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 man-
aged 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 unidenti-
fied 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 sys-
tem 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 o ptimisric 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 Sc hedule 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, mon-
vate, evaluate, direct, and control properly, then t he project is certain co foil. Even
when factors outside his or her control contribute to the fai lure, the project manager
is responsible for recogn izing the early warning signs a nd 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 t hat the project can catch up and says that a bad report on a major
project could resu lt 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 report-


ing on rhe development of an information system. Plan ning 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 t har show
casks, cask dependencies, and critical tasks char might delay rhe project. Projecr mon-
itoring requires guiding, supervising, and coordinating the project ream\ workload.
The project manager muse monito r the progress, eva luate the results, and cake correc-
tive action when necessa ry to contro l the project and stay o n carget. Project reporting
includes regu la r progress reports ro management, users, a nd the project rea m itself.
Effective reporting requi res st rong communication skills a nd a sense of what others
wa nt and need ro know a bo ut the project. A successful project must be com pleted on
time, be within b udget, and deliver a quality pro duct that satisfies users and meets
requiremen cs.
A project t riangle shows three legs: project cost, scope, and time. A project man-
ager musr find rhe besr balance amo ng 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>_... ........ _ .. ~ ........................._ .... ._
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 person-
da)'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 schedu ling, 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 pre-
decessor 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 c hart 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 assign ment 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 informa-
tion 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 o rder 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 man-
agement, which is rhe process of identifying, analyzing, a nticipating, and monitoring
risks 10 minimize their impact on the project.
In ihe end, project management involves the same skills as any o ther management.
The project manager must be perceptive, analytical, well organized, and a good com-
municator. 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 con-
trol 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 3 Managing Systems Projects

98 Key Terms

Ke y 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 critica l
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.11sequence.
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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~~
.......... _ _ _ , _ • .......,.. ....................
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, evaluati ng. cracking, and controll ing 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 differ-
ence 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 beginn ing 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 informa -
tion 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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
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 diffi-
culc 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 com-
pleted. 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 sys-
tems 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?

Projects
1. Think of all the tasks chat you perform when you p urchase a car. Include any research, decisions,
or financial issues that re lare 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 Ltasks. 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. Reca ll 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 I0I

• D escr ipt ion D ur ation Predecessor


( D ays) Tasks
I Develop Plan
2 Assign Tasks 4
3 Obtain Hardware 17
.. Programming 70 2
5 Install Hardware 10 3
6 Program Test 30 ..
7 Write User Manual 25 5
B Convert Files 20 5
9 System Test 25 6
10 User Training 20 7,8
II User Test 25 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 The chapter includes three "Case In Point"
systems analysis phase. This chapter describes the discussion questions to help contextualize the concepts
requirements engineering process: gathering facts described in the text. The "Question of Ethics" raises
about a systems project. creating models that will be the issue of considering a request by a supervisor to
used to design and develop the system, and verifying identify departments that reported the lowest ratings in
and validating that the models are correct before a survey that was supposed to be kept anonymous.
proceeding to the next phase of the SDLC.

LEARNING OBJECTIVES CONTENTS


Whe11 you finish tl1is chapter, you should be able to: 4. 1 System Requiremenrs
4 .2 Team-Based Techniques
1. Explain system rcquiremenrs and rhc challenges
Case in Poinr 4.1: 'orch Hills College
associated with the rcquircmcnrs engineering process
4.3 Gathering Requirements
2. Compare and contrast funcnonal and 4.4 Garnering Requirements Through lnrerviews
non-functional requirements 4.5 Gathering Requirements Using Other
3. Apply team-based rcquircmcnrs engineering Techniques
techniques, including joinr application development Case in Point 4.2: CyberStuff
UAD), rapid appltcaaon development (RAD), and 4 .6 Gathering Requirements in Agile Projects
agile method~ 4 .7 Represenring Rcquircmcnrs
4. De1'elop a face-finding plan for gathering Ca3e in Point 4.3: Digital Pen Transcription
requirements 4 .8 Validating and Verifying Requirements
4 .9 Tools
5. Conduct an interview to gather sy3tem
A Question of Ethics
requircmcntS
4. 10 Summary
6. Use other requirement~ garhering rcchniqucs, Key Terms
including document review, observation,
Exercises
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~
f"........., ,.,.r...., t . . . . . 4•111..-.•...__. .......
~ .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........,.., ........... ._... ..,.,...,.~"
~------.. ... ~ ........................ -..,.n..-.....-ik-sc~ c....,a..-.,.,...,. ..... ID>_... ........ _ .. ~ ........................_ .... ._
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 t he 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 func-
tional 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 4 Requirements Engineering

106 4.1 Syscem Requ irem encs

• 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 t he 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 usuall y repre-
scnccd 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.rakeholde rs to completely dlisagrec as to the mea ning of a simple req uire-
ment. It is for chis reason chat other techniques are used to represent requirements, as
described in Secrion 4. 7.
A req uirement may be a high-level abstract statement of a service or of a system
constra int, bur it can a lso be a derailed mathematical specifica tion. T his is because
requirement~ often berve rwo functions: as a basis for a bid for a contract, a nd as the
basis for rhe cotitract itself.
If rhe requirements are the basis for the contract bid, it muse be open to interpreta-
tion. 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 t he
systems analyse and rhe client can agree on whether or nor a specific requirement has
been met.
In theory, requirements shou ld 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 descri be the requirements for a complex system.
A requ irement 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 cha llenging.

CREEP: There are many social and organizational factors that influence sysrem
requirements. For example, business changes inevitably lead to ch:mging require-
ments-usually more of them ;ts the project progresses. T his is particularl y true for
long-lived projects where the personnel involved change over rime. This phenomenon
is known as "feature creep."
Rapidly c hangi ng requirements can cause numerous problems for systems analysts
and other ream members. T his is particularly true for project!. that follow a tradi-
tional waterfall model of the SDLC. It is partly for th is reason rhar agile methods are
popular: They explicitly address changing requirements as part of rhe project's man-
agemen t structure.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 sys-
tem 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 scal-
able 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 a nd types of data items required for each transac-
tion, 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 informa tion affeccs
fucure hardwa re decisions. In addirion, wich realistic volume projeccions, reliable cosc
estimates for rcl:ued expenses, s uch as postage and online charges, can be provided.
Similnrly, to ensure thac a web-based hotel reservation system is sufficientl y scal-
able, 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 sys-
tem 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 a ll systems development.
incorporating security as a first-class requiretnent is particularly important in lig ht
of the seemingly endless news reports of 1nassive data breaches. These hacks tele:isc
personal information from o nline 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 tha t 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 4 Requirements Engineering

108 4.2 Team-Based Techniques

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 alter-
native!.. 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. Eve n if accurate fig-
ures are unavailable, syscems
analysts should try to identify
TCO for Cloud Computing indirect costs and include them
in TCO estimates.
Because cost contro l is
so important, vendors ofren
29°10 claim that their products or
services will reduce T CO sig-
57°10 nificantly. For example, one

v of the most commo n reasons


to migrate n legacy system to
the clo ud is reduced TCO. As
shown in Figure 4- 1, cloud
computing offers rhe oppor-
tunity for lower operational
costs due to the our ourcing
of expenses such as ca pita I
investment in exchange for a
FIGURE 4-1 Total cost of ownership when migraung co the cloud can be significandy less
than current computing platforms. 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
st ructured analysis and consulted users o nlr when their inpur o r approval was
needed. Although the TT staff still has a central role, and structured analrsis remains
a popular merhod of systems development, mosr IT ma nagers 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

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 Applicatio n Deve lopme nt


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 µrofessiona ls who wo rk 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 ROLE


JAD protect leader Develops an agenda. acu as a facilitator. and leads the JAD session

Top manageme nt Provides enterprise-level authorization and support for the project

Managers Provide department-level support for the project and understanding of


how the project must support business functions and requirements

Users Provide operational-level input on current operations. desired changes,


input and output requirements. user interface issues, and how the proj-
ect will support day-to-day tasks
Systems analysts and Provide technical assistance and resources for JAD team members on
other IT staff members issues such as security, backup. hardware. software. and network
capability
Recorder 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 4 Requirements Engineering

I I0 4.2 Team- Based Tec hniques

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 s hown 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 pro-
duces the best possible definition of tbe new system.

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
Top management (sometimes • Explain the reason for the project and express top management
called the project owner or authorization and support
sponsor)
Project leader • Provide overview of the current system and proposed project
scope and constraints
• Present outline of specific topics and issues to be investigated
Open discussion session, • Review the main business processes, tasks, user roles. input. and
moderated by project leader output
• Identify specific areas of agreement or disagreement
• Break team into smaller groups to study specific issues and assign
group leaders
JAD team members working • Discuss and document all system requiremenu
in smaller group sessions, • Develop models and prototypes
supported by IT staff
--------
Group leaders • Report on results and assigned tasks and toptcs
• Present issues that should be addressed by the overall
JAD team
Open discussion session, • Review reporn from small group sessions
moderated by pro1ect leader • Reach consensus on main issues
• Document all topics
Project leader • 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 grou p is too large
relative co the size of rhe project. M any companies find, however, that JAD a llows
key users to pa rticipate effectively in the requ irements 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 acc urate statement of system requirement , a better
understanding of common goals, a nd a stronger commirment to the s uccess of the
new system.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 d evelo pment (RAD) is a team-lbased technique that speeds up
information systems development a nd produces a function ing information system.
Like J AD, RAD uses a group approach bur goes much further. \Xlhtle t he end product
of J AD is a requ irements model, the end product of RAD is the new informa tion 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 a nd 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, deter mine 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 cre-
ate a concinuou!i stream of documentation.

RAD PHASES AND ACTIVITIES: The RAD model consists of four phases: require-
1
ments planning, user design, construction, and cucover, as shown in Figure 4-4. ote
the continuous inreract ion between the user design and construction phases.
Require me nts planning. The requirements planning phase combines element~ of the
systems planning and l>ystems analysis phases of t he 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 p rocesses, outputs, and
inputs. T he RAD group or subgroups typically use a combinatio n of J AD techniques
and CASF, roo ls co transla te user need s into wor kin g models. User design is a con-
ti nuous, interactive p rocess that allows users to u ndersta nd, modify, a nd eventua ll y
approve a working model of the system tha t meecs cheic needs.
Constructio n. The constru ction phase focuses on program and application develop-
ment 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.
Cutove r. 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 Continuous interaclton
• Obtain approval to between the user design
and construction phases
continue

Construction Tasks
User Design Tasks
• Program and
• Interact with users User application
• Build models and Design development
prototypes
• Coding
• Conduct intensive • Unit, Integration,
JAD-type sessions
and system testing

CutoverTasks
• Data conversion
Cutover • 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 mod-
ificarions quickly, as the design evolves. In times of right corporare hudgers, iris espe-
cially 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.A D 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 migh t 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 incre-
mental step is affected by what was learned in the prior steps.
As agile methods become more popular, a large con1munity of agile-related soft-
ware 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 manag-
ers. 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 scru m.

.........""_.. ... .-................. _..__


("..,_...,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, meth-


ods 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, fre-
quenr 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 a nal yst will use various teclu1jques, including interviews, document review,
observation, surveys and questionnaires, sampling, a nd research.
Although software can help gather and analyze requirements, no program actuall y
gathers them a uto matically. First, the information needed must be identified. Typi-
cally, t his activity begins by asking a series of questions, such as the following:
• \'<i'hat bu'>iness functions are su pported by the current system?
• What strategic objectives and business requirements must be supported by the
new sysrem?

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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 a lso must ask another very important question: why.
Some examples of rhese questions a re 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 a ll.
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 l ow? 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 inter-
viewing process commences, which consists of seven steps for each interview:
I. Determine the people to interview.
2. E.srablish objecti ves 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 rig ht 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 stakehold-
ers 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 orga-
nization. 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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 convcr-
ation, 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 top-
ics. Interview objectives a lso 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 a nd 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 s tandard question list
permits a comparison of their answers. AJtbough there may be a list of specific ques-
tions, 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 advan tages in the proposed system?"

Open-ended questions. Open-ended ques tions 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?

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 4 Requirements Engineering
I 18 4.4 Gathering Requirements Th rough Interviews

Also, an open-ended question can be used ro probe further by asking: ls rhcre any-
thing else you can rell me abour rhis ropic?

Closed-ended questions. Clo~ed-ended q uestions limit or restrict the response.


C losed-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 repo rts 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. Ra nge-of-res ponse questio ns are closed-ended ques-


tions chat ask the person ro evaluate something by providing limited answers ro
specific responses or on a numeric scale. This metho d makes it easier co tabulate the
answers a nd interpret che results. Ra nge-of-response questions might include the
fol lowing:
• On a scale o f 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 develop-
ing 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 o r
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 de partment 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 avaiJ-
able at the meeting. The ad vance 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 a nalyst 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:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

4.4 Gathering Requirements Through Interviews 119

•••
d •• I) 0 B

°"""'-·
-

-
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 - . . - 1 1 .. , .-
. _ ..........- : 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 ....,.~•
..... ..,.

• Wt' tJ'W,.. ~ M"'f


l oa.-., oa.o. 1.L rm~.,. .. ,.... t....o ~
x ,._...., , ..,., .. _.,...,.~...,.~~.-e~w. .,..~u.'" wcu.,...,.tN __

•s...,•• "*'.....,at .. ~ 1octbotl&1


• 0. .,._...,. ~,..... .......... ~ ~ tit tN: . . . .,"""' ,,..,-?
• W"llC ..,,,,., ~ .... 0 . . . . . . , . ,...,.,.. .,. the,..... ~?
"°"""',....,...,..,

• Wt'9 . . ~· .ll'\ tht~411cltMAon~"


• HIDW....,. .. .,.... ·~~ !ft ~,.,... wipiCll

If"""
TM"b
h9W! "'" ~-..,.....,,..or-..... O\IC dOni '*" thl:
,_yew~
GM"IWft s...-em. P'MM No-.. UIOl9 ....._.._•I wn rnicw ""-"".._,.we nllefll

.......
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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ..... ...... ... ~..
__.... ~~·~---- ···---~~ - .,.-"~ --......
...........
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,
tactfull y 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 meet-
ing 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 com-
plete and candid a nswers. T he analyst's primary responsibility during a n interview is
co listen carefull y to the answers. Analyses sometimes hear only what they expect co
hear. Concentrate o n what is said and notice an)' non ve rbal 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 con-
versation 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 q uestions have been asked, summarize the main points covered in
the interview and explain t he 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 inter-
viewee'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 a nd
makes ir harder ro establish a good rapport.
After conducting the interview, record the informa tion 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 con-
versarion is forgotten within 30 min utes. Therefore, use the notes ro record the facrs
immediately so they will not be forgotten. Sun1marize the facts by preparing a nar-
rative 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'

P hase 2 Systems A nalysis

4.5 Gathering Requirements Using Oth er Techniqu es 121

interviewee. Assure the interviewee rhar rhe recording will be erased after its contents
are transcribed into note form and t hat 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 incer-
viewer 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 mecha-
nism 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 appreci-
ation 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 writ-
ten 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 misun-
derstanding or personal1ry conflict could affect the interview negatively, or the inter-
viewee might be afraid that the new sysrem will eliminare or change his or her job.
In other cases, the inter viewee 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. T he 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 super-
visor s hould 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 tech-


niques, including document review, observation, questionnaires and surveys, sam-
pling, 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 Requ irements Using Other Techniques

4.5. 1 Docume nt 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 peo-
ple 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 understand-
ing of system procedures. Personal observation also allows the analyst ro verify state-
ments 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 know ledge 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 sys-
tem 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 pro-
cedure 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 for-
malized; therefore, try ro document any procedures for handling exceptions.
• Observe all rhe steps in a transaccion a nd 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 informa tion does tbat person receive from other people? Wh:ir informa-
tion does this person generate? How is the information communicated? How
often do interruptions occur? How much downtime occur)? I low much sup-
port 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 s hown 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4 111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~• -fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~-- - t fta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

4.5 Gathering Requirements Using Oth er Techniqu es 123

employee productivity. The surprising result was that productivity improved during
observation whether the conditions were made better or worse. Researchers con-
cluded 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 docu-
ment containing a number of standard questions that can be sent to many individuals.
Questionnaires can he used ro obta in 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 Requ irements Using Other Techniques

,._ ......_...._ __...


........................
_....,._._.,,......
_.. ..........
..
__....... ---·-- .....
..............
..._,......
...-~ .. to answer rhe questions. Heading~ also arc used to
introduce each main section or portion of the survey
tt•W . . . . _ _ . . _ . ,.......... - . - - - - ·· . . .
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

--··-·--
,,_
I_ . . . . . . . . . . . .,.., . . . . _ . . . . . . . . _ _

·-
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 ques-
.....
a.0.,. ............ - -.........l
tions. First, does an analyst really need ro know who the
respondents arc in order to march or correlate informa-
--·
... ..
•••,.
tio n? For example, it might be important to know what
percentage of users need a certain software feature, but
··-
--- specific usernames might not be relevant. Second, docs

---
. . . . . . . . . . ,.. . . _ _ _ .....,..l

---
the questionnaire include any sensitive or controversial

---
..............................,......
.. ..,,.. lUOOltT'IOMI
topics? Many people do not want to be identified when
answering a question s uch as " H ow well has yo ur super-
visor explained the system to you?" In such cases, a nony-
mous res ponses might provide better information.
Wben designing a questionnaire, the most import-

--
a. ......................... .,...,............, _ _ _ _ _ ,..

--
_....,,, __ .._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:

-
FIGURE '4-12 Online version of a sample questionnaire.
• Keep the questioonaLre brief and uscr-fricndlr.
• Provide clear instructions chat will answer all antici-
Does it follow the suggested guidelines! pated questions.
• 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 grou p.
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 publish-
ing the form, protect ir so users can fill it in but cannot change the layou t 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
........ .,..,. .. ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. ..,...,.......,..~.................,.t11ru .. __.~~c.....,..~
I'

Phase 2 Systems A nalysis

4.5 Gathering Requirements Using Oth er Techniqu es 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 ani-
rudes 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 subsrnn-
tial. The personal interview usually is the most expensive fact-finding technique.
ln contrast, a question naire gives many people the opportunity to provide input
and suggestions. Questionnaire recipients can answer the questions at their conve-
nience and do not ha vc to set aside a block of time for an interview. If the question-
naire 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 unstruc-
tured. 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 col-
lected using a process called sampling. The samples might include records, reports,
operational logs, data entry documents, complaint summaries, wo rk 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 popu-
larion 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 sam-
ple 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 a n accurate picture.

4.S.7 Research
Research is another important fact-finding technique. Research can include the Inter-
net, 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 informa-
tion 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.

_
---
......_...._
..... ~...._ .........<-. -

---
......... __ - "'
.....,._...,._
,._

---
~-·
.,,..._.
--~

........
__.
_.,._ •-
1- - 1

__
r...J.....~c:.ar...

f\>llllcal Rtallly: Buy Ads


on Fatfbook or lllik
........
._
.........
~
_......._..,._
......
-.. _
_.............
~
\
----
·--·-
.. --· ~
,_...._,.

...,._ ... .......... .. _


Loi.Ins the ElecUoo

-- -
..
.......... ... --·· -·-· . ...
,....._.,_,...........
.
~ ..,............. ,_._
.......__........,_ .......................
------·~
!-··!

.......
_...,...
......
...,_~
__.....·-_--........ ....·---
_.................
..._._
---
.......___
-----·........
-.......

FIGURE 4 . 13 The WoH Sr:reetjoumo/'sTechnology website contains valuable infonnadon


for IT professionals.
~re-= .. ~ ~• n.l.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 con-
sidering 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 man-
ager 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 ven-
dor, 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 expe-
rienced 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 represen-
tatives did not follow established order entry procedures.You feel that with more Infor-
mation. you might find a pattern and identify a solution for the problem, but you are not
sure how to proceed.
Is a que stionnaire the best approach, or would interviews be better? And whether you
use interviews, a questionnaire, or both techniques. should you select the par ticipants 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 requi rements gathering, a variation on interviews
that focuses on features, user ~tories, scenarios, a nd 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 requi remenrs
or user stories, and a priority. Featu res 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.im-
ple sentence of the form "As a Iuser 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 require-
ment 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 Requ irements

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 suc-
cessively 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 s uccessful systems
development. As information is garhered, the importance of a sing le item can be
overlooked or complex system derails can be forgotten. The abili ty 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 shou ld 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 cho-
sen, 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 lan-
guage, 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 impreci-
sion and a lack of shared understanding.
Requirements represented as unstrucrured natura l language can he ~tored in a sim-
ple file, in a database that may facilitate sea rch ing its contents, or in an Excel spread-
sheet. The larrer choice is a popular one, because most systems analysts are familiar
with rhe root, a nd chey are likely to have access co it already.
An improvement upon unstructured natural language is structured natural lan-
guage. This representation rags part o f the requirement, rather like an XML docu-
ment. This facilitates automated processing of the requirement statements, but it's not
very user-friendly.
Requirements represented as structured natura l 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 Volere
official statement of what is requi red of rhe syscem by
the users. The Volere template is a good template for a FIGUR E 4- 14 TheVolere shell.
~ A tr• \... 1 r
comprehensive requirements document. It is populated by
atomic requi rements from the Volcre shells.

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 han-
dle 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!.en r system requirements. Diagrams help users, managers, and IT profession-
als understand the design of a system. Diagramming involves graphical methods and
nontechnical language that represent the system at various stages of development.
During requiremen ts engineering, the analyst can use various cools co describe busi-
ness processes, requirements, and user interaction with the system.
Systems analysts use diagram1ning and fact-finding interactively-first they build
fact-finding resu lts into diagra ms, then they study the diagrams to determine whether
additiona l face-finding is needed. To help chem understa nd system requirements,
ana lysts use fu nctional decomposition diagrams, business process diagrams, a nd dara
flow diagrams. Any of these diagrams can be created wi th CASE cools or sta nd-alone
drawi ng tools if desired.

FUNCTIONAL DECOMPOSITION DIAGRAMS: A fun ctional decomposition


diagram (I-OD) is a mp-down rep resentation 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 4.7 Representing Requi rem ents

systems development. During requi rements 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 Finan: e &


Resources AccOUlbng

Operalons Bock Personnel


Budge:ing Management AssigfT1'1ef11

Add& CheckolJ& Arctwe CheckolJ


Remove Books RetumBooks 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~


described in Chapter I, a bu\iness proce~s
i model (BPM) represents one o r more
! ~
~· ,.

-..
E ..
a Pfoce11 Order - t Prepare 81111no H Create Sh1.
Oata
pp1ng busi11ess processes, such as handling an
-..
ti;
c
~
~
airline reservation, filling a product order,
or updating a customer account. During

-..
;;;

Q.
w
!!
requirements engineering, analysts ofren
create diagrams that use a standard
syntax called business process modeling
~
a si ' Obtain Crtidil I-+ " Validate Credit H
Assign
Customer notation (BJ>MN). BPMN includes

I
3 '- 011• S tatus Number

-- various shapes and symbols to represent


events, processes, :1 nd workflows.
When creating a business process dia-
gram using a CASE tool such as Visible
FIGURE <4- 16 Using the Visible Analyst CASE tool, an analyst can create a
Analyst, the diagram automatically
busine.ss process diagram.The overall diagram Is called a pool. and the cwo becomes part of the overall model. In
separate customer areas are c:alled swim lanes. 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 o rher, related DFDs. Daca and process
modeling is deM:rihed in derail in Chapter 5 .
.. Add----
Boob

---2..!.. -
Bool<Tllo
~
Ir'"':' - -
.
.

AWlOl's
A61'S"'
~ Boob Updaled AIA!"Ol'S
,.
Doob
' .
'. Boolcs
••
"

FIGURE 4-1 7 This Visible Amlyst DFD shows how books are added and
removed 1n a library system.
'
4 .7 .3 M odels
Models provide a more formal representation of system requirements. They arc o ften
depicted as graphical in nature, so they share some of the cbaractcriscics of rhc tech-
niques described in Secrion 4.7.2. But models have an additional feature: The under-
lying 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 model-
ing 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\ll L provides various graphical cools, such as use case diagrams and sequence
diagrams. During requirements engineering, a systems analyse can utilize the
UJ\ll L co represcnc the informacion syscem from a user's viewpoinr. Use case dia-
!,'Tams, sequence diagrams, and other U~1L concepcs are discussed in mo re derail in
C haprer 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 Requireme nts

USE CASE DIAGRAMS: During requirements engi-


neering, S}'Stems analysts and users work together to
document requirements and model system functions.
A use case diagram visually represents the interaction
Submits between users and the information system. In a use case
card O..ta 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 t hat integrate the use cases into the
Customer
overall systems design.
Figure 4-18 shows a simple use case diagram for
a sales system where the actor is a customer and
FIGURE 4-18 This Visible Analyst use case diagram the use case involves a credit card validation that is
shows a sales system, where the actor Is a customer and perforn1ed by the system . Because use cases depict
the use case is a credit card validation.
I
' ¥<' I " '" f "1\/ •4 'Y'i
f I C ~ I •I Jll'I
the system through the eyes of a user, common
business language can be used to describe the
transactio ns. For example, Figure 4-1 9 shows a table that documents the credit
card validation use case, and Fig ure 4-20 shows a student records system, with
severa l use cases a nd actors.

SEQUENCE DIAGRAM: A sequence diagram shows t he timing of interactions


between objects as t hey occur. A systems a nalyst might u~e a sequence diagram to
show all possible outcomes o r focus on a single scenario. Figure 4-2 1 shows a ~im­
ple sequence diaE,'Tam of a successful credit card validation. T he 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: Credit card validation process


~~~~~~~~~-

Actor: Customer
Description: Describes the credit card validation process
Successful Completion: I. Custo mer clicks the input selector and
enters credit card number and e)(piration date
2. System verifies card
3. System sends autho rization message
Alternative: I. Customer clicks the input selector and
enters credit card number and e)(piration date
2. System rejects card
3. System sends rejection message
Precondition: Customer has selected at least one item and
has proceeded to checko ut area
Postcondition: Credit card information has been validated
Customer can continue with order
Assumptio ns: None

FIGURE 4- 19 This table documents the credit card validaaon use case shown in Figure 4-18.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi ( . . . . . -Woip-M ._..,..
..,...,...... .,..~ ..
__.~~ c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

4.8 Validating and Verifying Requirements 133

Registration
System

Student
Advisor

Record
Grades
Registrar
lnstruttor

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 V•lldate


Card.:Credll Card
Card Cutlomen
Cu1toma11

I
I
Enter Card Number 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:

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W
__.... ...................
~- ...............,..
~~·~----···---~~-.,.-"~ --......
o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
...........
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 custom-
er'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 iremcn 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 require-
ments are initially being formulated. Ideally, the systems analyse and the customer
(a nd perhaps other key scakeholders) should be involved in the reviews. The reviews
can be forma l (with complete documentation) or informal. The key is that good com-
municauons 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 softwa re programs a re available co help record and doc-
ument information elicited during the requirements gathering process. This type of
productivity software includes automation, word processing, spreadsheet, database
management, presentation grap hics, and collaboration software programs. Although
Microsoft Office is the best-known set of productivity software programs, ocher ven-
dors 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 capabi lity co check off com-
pleted 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:-..•~-".....-""'*"....,.._...,.. ..
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 o rga nize a presentation wirb templates, bookmarks, annota-
tions, revision control, and an index. Fill-in forms can also be creared ro conduct sur-
veys and quesrionnaires, as described earlier in this chaprer.
Spreadsheet software, s uch 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 graphica l
formar often is used in qua liry conrrol analysis because it highlights problems and
their po s ible causes, and iris effective when presenting results to management. A
common tool for showing rhe disrribution of questionnaire or sampl ing results is a
vertical bar cha re called a histogram. Most spreadsheet programs can create histo-
grams and other charts chac can display the daca collected. Figure 4-23 displays a typ-
ical 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 pro-
grarn such as Microsoft Access can be used to manage the details of a complex proj-
ect, create queries to retrieve specific informarion, and generate custom reports.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 4 Requirements Engineering

136 4.9 Tools

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
Question 2 results le
s < 20% 11
6 20-3t% 21 40 -
1 .o.tit% 36 35
8 60-7t% 2A 30 + - - - - - --1> Jl - - - - ---1
9 80% or mora !I 25 'l l---:::::----1
10 20 +-------a. . ~-'
11 15 .__ _-f.; :1--1 ,,1 --1 .1 - - ---1
12 10 -'--'....,._ _,, ..._ ... . . _ ...
13
14
5 .....
0 ~-.._.-
; --n-~
·
............- .....................- ..
1!> <20% 20- 40- 60- 80% or
16 39% 59% 79% more
11
18
19 4
,. • •1 SheetJ St (11.-u ID •~-======::=======================~·
____. _ __,'
FIGURE 4·ll This histogram displays the results fro m Question 2 In the questionnaire shown
In Figure '4-12.

Presenrarion graphics software, such as tvl icrosoft PowerPoint, is :i powerful tool


for organ i.ling and developing formal presentations. Presentation graph ics programs
enable the creation of org:inizarion charts that can be ui.ed in a preliminary inve~ciga­
tion and later during requirements engineering. T hese 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 will 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 pro-
duce a wide range of charts and diagrams .
Visio includes a library of templates, stencils,
and shapes. An analyst can use Visio co create
I "
many types of visual models, including business

....
Ii..
'..•
~
processes, flowcharts, network diagrams, orga-

- •I•1 •••
nization charts, and ma ny more. For example,
in Figure 4-24, the :inalyst used drag-and-d rop
shapes to represen r a business process .
For more forma l models of rcqui rcmcnrs,
'1l
e special-purpose tools such as IBM Rational
fJ
.. c: •.]l DOORS are used. These cools faci litate the use
:l·

0 - of UML (and SysM L) co model sysrcm require-


ments in a way that enables desirable character-
istics, such as traceability, where rhe origin of a
requirement i~ connected back co the require-
ment itself, which in turn is linked forward co
.. design artifacts, code fragment~, and even rest
FIGURE 4-24 Th1sV1sio drawinc uses drag-and·drop shapes cases in the SDLC. Figure 4-25 illustrates some
to re present a business process. of the capabilities of DOORS Next Generation.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4 111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~• -fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~-- - t fta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..
I'

Phase 2 Systems Analysis

4.10 Summary 13 7

FIGURE 4-25 IBM DOORS Is a to0I for capturing. analyzing, an d tr.icing system requirements.
ISM C. P r&

Your supervisor manages the corporate office where you work as a systems analyst. Sev-
eral 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 dis-
appointed 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 requi remcnrs engineering, che business-relared requircmenrs for rhe new
information sysrcm a re 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 esti mated to idenrify all coses, including
ind1 recr cos rs.
Popular team-based approaches include JAD, RAD, and agile methods. J AD 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 informar ion sysrems dcvelopmenc
and produces a functioning information sysrem. RAD is a complete methodology,
with a four-phase life cycle tha t parallels the cradirional SDLC phases.
Agile mechods a ttempc co develop a system incremenrnlly by building a series
of prototypes and constantly adjusting them to user requirements. Tools are o ften
:ivo ided and repbced with simpler ailds, such as whiteboards and sticky notes to faci l-
itate communication.
The requirements gathering process includes interviewing, document review, obser-
vation, questionnaires, sampling, and research. Successful interviewing requires good
planning a nd stro ng interpersonal and communication skills. The sysrems ana lyst
musr decide on rhc people to intervie w; ser interview objectives; and prepare for, con-
duct, and :inalyzc incerviews. The analyst a lso might find ic helpful ro use one or more
software rools during facr-finding.
Systems analysts use va rious tools and techniques ro represent system require-
ments. 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 ana-
lysrs who arc more visually oriented. They can a lso capture complementary aspects of
t he system reqmrements. Sample diagram rypes include FDDs, busine s process dia-
gram!>, and DfDs.
Nlodels provide a more formal represenration of system requirements. The UML
is a widely used method of visualizing a nd documenting i.ofrware de!>ign through the
eyes of the bu~iness user. UML cools include use case diagrams and sequence dia-
gmms ro represent actors, their roles, and the sequence of trans:iccion!. that occurs.
Systems :inalysts should carefully record and d ocumenr factua l information as it
is collected, and various software tools can help a n 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 correctl y.
All requirements engineering activities can be helped through rhc judicious use
of tools. They provide automated support for req uirements atrriburcs such as rrace-
abiliry. 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'

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) build-
mg 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 pro-
cess 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, w hich can develop from prcvi
ou~ work n~~ignmcnr~, physica l rruximiry, unofficial procedures, or per~ona l rclation~hip>.
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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~~
.......... _ _ _ , _ • .......,.. ....................
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 individ-
uals. 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 devel-
opmcn1 .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 down-
sized 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
pas~'·

~unc) 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
I'

Phase 2 Systems Analysis

Key Terms I41

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 ·1be 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 (UM I ) A widely used method of visualizing and documenunp. softw,1rc sys-
tems design. UML uses objccc-oricntcd design concepts. bur iris iudcpcndcnr of any specific program-
ming 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 informa-
ti<>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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 la wthorne 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 d ifference 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 ver-
sions of the system. How would these shorrer cycles affect the abiliry of the ana-
lyst ro manage sysrem requirements?
3. A group meeting sometimes is suggesred as a useful compromise bcrwccn mrer-
views 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 requi rements. 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 narura l language and the UML to represent the siru-
auon where people on different floors push the ''Up" button at the same time.
2. Prepare a presentation summarizing JAD and RAD. Explain how t hey differ
from traditional facr-finding merhods. What arc the m:iin advantages of team-
based methods?

r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 com-
plete. Examine several requirements engineering CASE tools and document how
(if ar all ) they support automated consistency analysis for validatmg :rnd verify-
ing 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 sys- The chapter includes three "Case in Point" dis-
tems analysis phase of the SDLC. This chapter discusses cussion questions to help contextualize the concepts
data and process modeling techniques that analysts use described in the text. The "Question of Ethics" raises
to show how the system transforms data into useful the issue of how to respond to subtle but insistent
information. Data and process modeling involves three requests by an IT manager In a systems analyst's new
main items: data flow diagrams, a data dictionary, and organization for proprietary information related to
process descriptions.The deliverable, or end produce, the business processes used by the analyst's previous
of data and process modeling Is a logical model that will employer. which is a competitor of the analyst's current
support business operations and meet user needs. company.

LEARNING OB ECTIVES CONTENTS


W/Jen you finish tbis chapter, you sl101tld be able 5. 1 Logical Versus Physical Models
to: 5.2 Data Flow Diagrams
5.3 Data Flow Diagram Symbols
l. Describe rhe relarionship bcrween logical and
5.4 Drawing Dara Flow Diagrams
physical models
5.5 Drawing a Context Diagram
2. Explain data flow diagrams 5 .6 Drawing a Diagram 0 01-D
3. Draw rhe four basic dara flow diagram symbols 5 .7 Drawing Lower-Level DFDs
4. Explain the si.~ guidelines used when drawing Case in Poinr 5.1: Big Ten Univcrsiry
data flow d1agr:ims 5 .8 Data Dictionary
5. Draw context diagrams 5 .9 Process Description Tools in Modular Design
Case in Point 5 .2: Rock olid Outfitrers (Parr 1)
6. Draw diagram 0 data flow diagrams Case in Point 5 .3: Rock Solid Outfitters (Part 2)
7. Draw lower-level darn flow diagrams A Question of Ethics
8. Explain how to level and balance data flow 5 . 10 Summary
diagrams Key Terms
9. Create a darn dictionary Exercises
IO. Apply process description tools in modular
design

r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 informa-
tion 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 a llows 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 ana lyst 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 use-
ful informatton. Other graphical tools include object models, which are explamed in

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter S Data and Process Modeling

146 5.3 Data Flo w Diagram Symbols

Chaprer 6 (Object Modeli ng), 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 O FDs. In his seminal book The
Visual Display of Quantitative 111(ormatio11, aurhor and renowned academic Edward
Tufte provides guidance on crearing effecrive diagrams to concisely convey com-
plex 111formation. A DFD is an example of this rype of visual e'<planation of system
behavior.
A DFD shows how data moves th rough 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. T hac discinction is important because focus-
ing on implementation issues at this point would restrict the search for the most effec-
tive system design.

5.3 DATA FLOW DIAGRAM SYMBOLS

DFDs use fou r basic symbols tha t represent processes, da ta flows, data stores, a nd
entities. Several different versions o f DFD symbols exist, but they a ll serve t he same
pu rpose. DFD examples in this rexr use the Gane and Sarson symbol set. Another
popu lar 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
Process
APPLY PAYMENT
PAYMENT

BANK DEPOSIT BANK DEPOSIT


Data Flow

II 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 veri-
fying 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, out-
puts, 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 workings-
which 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 sin-
gle 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 rNVO ICE process. A process symbol can have more than one
outgoing data flow, as shown 111 t be 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 t he r symbol, including another process
symbo l, 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 INVOICE


INVOCE

GRADED WORK
SUBMITIED WORK GRADE
STUDENT
WORK STUDENT GRADE
l-
o
w
a:
a:
0 HOURS WORKED
0 CALCULATE GROSS PAY
GROSS
PAY RATE PAY

ACCEPTED INVENTORY
ORDER VERIFY ORDER ASSEMBLE CHANGE
ORDER ORDER

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:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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 generatio n. 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 exam-
ple, a date of birth input is nor sufficient ro produce a final grade output in the
CALCULATE GRADE process.
Spontaneous generation, black holes, a nd gray holes are impossible logically in a
DFD because a process must act on input, shown by an incoming data flow, and pro-
duce output, represented by an outgoing data flow.

S.3.3 Data Store Symbols


A data ~tore is used in a DFD to represent
APPLY
dara that the system stores because one or POLICY NUMBER INSURANCE PAYMENT AMOUNT
more processes need to use the dara ar a PREMIUM
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 deduc- UJ
tion data during the year in order ro print HOURS WORKED CALCULATE PAY RATE a:
\Y/-2 forms with total earnings and deduc- GROSS PAY a:
0
tions ar the end of rhe year. A DFD does nor 0
show the derailed contents of a data store-- z
the specific structure and data elements are
defined in rhe dara dictionary, which is dis-
cus&ed later in this chapter. DATE OF BIRTH CALCULATE FINAL GRADE
The phy ical characteristics of a daca &tore GRADE
are unimportant because the logical model
is the only concern at this point. Also, the
length of time that the data i~ ~tored i& unim-
portant-it can be a matter of seconds while IFIGURE 5-'4 Examples of Incorrect combinations of data flow and
a transaction is processed or a period of process symbols. APPLY INSURANCE PREMIUM has no input and is
months while data is accumulated for year- called a spontaneous generation process. CALCULATE GROSS PAY has
no outputs and is called a black hole process. CALCULATE GRADE has
end processing. What is important is that a :an input that is obviously unable to produce the output. This process is
process needs access to the data at some later 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 r ig ht 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 illust rates
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 CREATE ADMIT


PAYMENT INVOICE PATIENT

CUSTOMER INVOICE ADMISSION


1- PAYMENT FORM
u
w DAILY ACCOUNTS
a: PAYMENTS RECEIVABLE
PATIENTS ·1
a:
0
u DAI LY INVOICE PAYMENT SYMPTOM TREATMENT
PAYMENT DETAIL DETAIL

PREPARE POST DIAGNOSE TREAT


DEPOSIT PAYMENT PATIENT PATIENT

FIGU RE 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 da ta stores lack either an outgoing or incoming data flow.

POST BOOK
1- PAYMENT FLIGHT
COURSES
u I
w
a:
a:
0 CLASS CUSTOMER FLIGHT
u LIST PAYMENT REOU EST
z
DAILY
STUDENTS PASSENGERS
I
PAYMENTS I I

FIGU RE 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'

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 com-
pany runs its payroll, the CALCULATE \XflTH HOLDI 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 CALCULAT E 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 CUSTOMER BANK CUSTOMER
three-dimensional. T he name
of the entity appears inside the
symbol.
PAYMENT BANK ORDER INVOICE
A DFD shows only cxrernal DEPOSIT
entities th:H provide data to rhe
sysrcm or receive output from l-
o
the system. A DrD shows the w
boundaries of the system and a:
a: APPLY PREPARE VERIFY
how the system interfaces with 0 PAYMENT DEPOSIT ORDER
the outside world. For example, 0
a cusromer enriry submits an
order to an order processing
system. Other examples of
entiti~ include a patient who VERIFY
TIME
CARO PAYCHECK CREATE
supplie~ data to a medical TIME EMPLOYEE PAYCHEC1<
record~ sy~tem, a homeowner CARD
who receives a bill from a ciry
property tax S)•Mem, or an
accouncs payable system that FIGURE 5-7 Examples of correct uses of e>nemal entitles on a cnu flow diagr.tm.
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 PAYROLL
CUSTOMER BANK
DEPARTMENT
that supplies data to rhe system
a source and an enriry that I-
receives data from the system 0
w PAYCHEC K PAYMENT BANK
a sink. An enriry na me is the a: DEPOSIT
singular form of a dcparm1ent, a:
0
an outside organiz;:irion, other 0
information system, or a person. z ACCOUNTS DAILY
An external entity can be a RECEIVABLE PAYMENTS I
source or a sink or both, bur EMPLOYEE
each entiry must be connected
ro a process by :i d:ita Aow.
Figure 5-7 and Figure 5-8 show FIGURE 5-8 Examples of incorrect uses of external ent1t1es on a cnu flow doagr.tm. An
correct and incorrect e-.::imples external entity must be connected by a cnca flow to a process and not directly to a data store
of this rule, re pecrively. or co another external entity.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter S Data and Process Modeling

152 5.4 Drawing Dae.a Flow Diagrams

S.3.S Using DFD Symbols


\'<'ith a n undersranding of the proper use of DFD symbols, the next step is co con-
struct 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 II Process to Data Store ./


- '·

D D External Entity to External Enllty


x
D II External Entity to Data Store
x
'-
II II
FIGURE S-9 Examples of correct and incorrect uses of data flows.
Data Store to Data Store
x
5.4 DRAWING DATA fLOW DIAGRAMS

During requiremen ts 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:-..•~-".....-""'*"....,.._...,.. ..
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 dia-
gram. For example, the process name in Figure 5-10 1s GRAD! G YSTEM.
, ore that rhe process name is the same as t he 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 on ly 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 appea rs, 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 rest rict t he 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 sym-
bols usually is a signa l that rhe diagram is too complex and that the ana lysis
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.

FINAL SUBMITTED
GRADE WORK
STUDENT
RECORDS STUDENT
SYSTEM

o...
CLASS ...... GRADED
ROSTER ~ WORK
GRADING
process o
represents lhe .
SYSTEM
' unique reference
number for
entire gred1ng sys1em
each process
GRADING '
PARAMETERS GRADE REPORT

INSTRUCTOR

FIGURE 5- 10 Context diagram DFD for a grading system.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 ins ide 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 identi-
fied 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 cen-
tral process. Data stores are not shown in the concext diagram because they arc con-
tained 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 a U 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 sup-
plies 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:
COtvl PLETED ORDER. Finally, the CUSTOMER entity has two outgoing data flows,
O RD ER and PAYMENT, and rwo incoming data flows, ORDER REJECT OTICE
and INVOICE.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

Phase 2 Systems A nalysis

S.6 Drawing a Diagram 0 DFD 155

ORDER

CUSTOMER WAREHOUSE
-
ORDER
PICKING
UST
REJECT
NOTICE

INVOICE 0
COMPLETED
PAYMENT ORDER
ORDER
SYSTEM

CASH
BANK RECEIPTS
COMMISSION DEPOSIT ENTRY

SALES ACCOUNTING
BANK
REP

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 tha t 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 dia-
gram 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 REPO RT) 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

FINAL SUBMITTED
STUDENT G RADE WORK
RECORDS STUDENT
SYSTEM

0
CLASS GRADED
ROSTER WORK
GRADING
SYSTEM

GRADING • GRADE
PARAMETERS REPORT

INSTRUCTOR

Diagram 0 for Grading Syslem

2 3
STUDENT
STUDENT
ASSIGN GRADE GRADE
RECORDS
FINAL STUDENT
SYSTEM
GRADE WORK

FINAL
CLASS GRADE GRADING
SUBMITTED GRAOED
ROSTER DETAIL
WORK WORK

1
CLASS
GRADEBOOK STUDENT
ESTABLISH 01 GRADEBOOK
GRADEBOOK I

CLASS
GRADING DETAIL
PARAMETERS
4
GRADE PRODUCE
REPORT GRADE
INSTRUCTOR
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'

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 await-
ing 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 identi-
cal 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, how-
ever, 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, t he 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 primi-
tive 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), a nd 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.

1
ORDER PICKING
UST
FILL
ORDER
ORDER
REJECT
NOTICE
CUSTOMER
WAREHOUSE

2
COMPLETED
ORDER
CREATE
INVOICE
INVOICE

DI ACCOUNTS
PAYMENT
RECEIVABLE
DETAIL
INVOICE
DETAIL 3

PAYMENT
APPLY
PAYMENT

COMM ,SSION CASH


RECEIPTS
BANK
ENTRY
DEPOSIT

SALES ACCOUNTING
BANK
DEPT

FI GUR E 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'

Phase 2 Systems A nalysis

S.7 Drawing Lower-Leve l 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 fol-
lowing sections.

EX AMPLE: LE VELING 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 con-
tmues 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 wor k through many levels to iden-
tify 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 O RDER process labeled as process 1. Now
consider Figure 5 - 14, which p rovides an exploded view of the RLL O RDER process.
Note rhat FILL ORDER (process l ) actually cons ists of t hree processes: VERIFY
O RD ER (process 1. 1), PREPA RE REJECT NOTICE (process L.2), and ASSEMBLE
ORDER (process 1.3).

CUSTOMER

ORDER
ORDER REJECT
NOTICE

1.1 I2
CREDIT
PREPARE HISTORY
VERIFY REJECT
ORDER REJECTED NOTICE
PRODUCT ORDER
DETAIL CREDIT
STATUS
I
ACCEPTED
ORDER D2 CUSTOMERS
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
on ly 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) interact-
ing 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 a nd 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
CREDIT
PREPARE
HISTORY
VERIFY REJECT
ORDER REJECTED NOTICE
ORDER
PRODUCT
DETAIL CREDIT
STATUS
I
ACCEPTED
ORDER D2 CUSTOMERS
I

1.3
PICKING PICKING
DETAIL UST
D3 PRODUCTS ASSEMBLE
ORDER

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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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 P<CKING
UST
flil
ORDER
ORDER
REJECT
CUSTOMER NOTICE I WAREHOUSE

2
COMPLETED
CREATE
ORDER I
INVOCE
INVOICE

II D1 ACCOUNTS

-
ll"YMENT

--
RECEIVABLE DETAIL
INVOICEf
3 ""
DETAIL
.
. I
PAYMENT
-- APF'\.Y
I
PAYMENT I

' - -i!!AN!!' '
COMMISSION CASH
RECEIPTS
DEPOSIT ENTRY

SAlES !IANJ(
DEPT
ACCOUl"1"NO

1NllOICE
Order System Diagram 3 DFD
ID' I

,--
I 31
t -' I
DEll'&.
I
PAYMENT
ACCOU'<TS
RECEIVAlll.E I

OET.tJL
I I
CVSTOMER POST
PAYMENT I PAYUENT I

- - - - - - - - ,, - - - - - .. - - - ...
I \
I CUSTOt.IER
PAYMENT

I "'I
I
1 tw1.Y OOMMISS ION I
I AAl'MENTS EARNED I
DAILY
I PAYMENT ACCOUNT1NG I
PAYMENT
I I
I 32 33 H
I
I PREPAA£ I
DEPOSIT ACCOUNTING PAY
I PAYMENT ENTRY COMMISSION I
I
.. - 1BANK - ---- -
DEPOSIT
~ <.'Xst-1'"
RECEIPTS ENTRY
-- - - - i ~:ss~ON -I

ACCOIJNf,NG SALES
BAM< 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 Low er-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. Fxam-
ine 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 par-
ent process.
Another example of balancing is shown in Figures 5-17 and 5-18. l11e DFDs in
the e figures we re 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
INPUT DATA I PROCESSO I OUTPUT DATA
FLOW2 I .I FLOW2

• •
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 -' • •

I ------- ---------, 1 3

EXTERNAL
I INPUT DATA
• FLOW I - UT OATA I
FLOW I I EXTERNAL
ENTITY A PROCESS 1 PROCESS3 ENTITYC
I
'
I I
I
I INTERNAL INTERNAL
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 FLOW 2 FLOW 2 I
EXTERNAL EXTERNAL
ENTITY 8 I PROCESS2 • ENTITY 0

I 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.

(....,..... J:gl( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

Phase 2 Systems Analysis

S.7 D raw ing Lo wer-Leve l 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
N UMBER SCHEDULE
ASSIGN WITH OPEN
AO\llSOR AOlllSOR CLASSES

FINAL
CLASS
SCHEDULE

05 CLASS ROSTER
CLASS
INSTRUCTOR ROSTER
STUDENTS
ATTENDING

SCH EDULE D6 SEATING C HART


OF OFFICE
HOURS
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 informa-
tion system. Examples of data elements are student grade, salary, Social ccurity num-
ber, account balance, and company name. Dara e lements are combined into records,
also called daLa structures. A record is a meaningful combination of related data ele-
ments t hat 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, a nd list price.
Significant relationships exist among the items in a data diction~iry. For example,
darn stores a nd data flows are based on data structures, which in rurn are composed
of data c lements. Data flows are connected to data s tores, entiLies, and processes.
Accurately documenting these relationships is essential so the data dictionary is con-
sistent with the DFDs. The more complex the system, the more d ifficult it is co main-
tain 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 reposi tory 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.tvl BER. Once the CUSTOMER NUMBER element has been defined in the repos-
itory, 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 o nline o r 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.tvl BER might be recorded in the Visible Analyst dara dic-
tionary. Regardless of the terminology or method, the follow ing attrib utes 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
CURR ENT BALANCE, various users might refer to it by alternate names such
as OUTSTANDING BALANCE, CUSTOMER BALANCE, RECEIVABLE
BALANCE, or AMOUNT OWED.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

S.8 Data Dictionary 165

• Type and length. Type refers ro


whether chc data element conrains
ISOCIAi. sicUltl'TY NUMlllJt
numeric, alphabetic, or character val-
ues. Length 1s the maximum number
i.w
Enbybpc
-
I of4

of character~ for an alphabetic or a


character data element or the maxi- ~ 1-s.a..cy-
mum number of digits and number
A!Us: SSH
of decimal posirions for a numeric
data element. In addition to text and \/oJues &
:::===:::___
n
TJ!I< lengsh: !IN

numeric data, sounds and images


also can be stored in digital form.
~
Acc.--
O.twlt.- None
Mf-"'9'1--

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 Notes; 5oufCC
Sttun1y
Appl1c1tton rorm
Pl)"Oll dq>tnmonl
value for the data clemenr if a value R"'f>O"sib~ \Ml". PoyniH d~l
otherwise is not entered for it. For
example, all new cu~tomers might long Nome:
have a default value of $500 for the
CREDIT LIMIT data element.
• Acceptable t•al11es. Spccificarion of
ArtOO!bi't objt<t llbfl an bt uP to 128 ctilrxt11s ID!lo. Jlld tllt Int c:IQ/xtt1 l'l\&St bt
the data element's domain, which is • mtter.
the set of values permitted for rhe
data element. These values either can FIGURE S-20 A VlsibleA!Qlyst screen describes the data element named
be specifically listed or referenced SOCIAL SECURITY NUMBER.
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 au thorized co
access dara in a read-only mode.
• Responsible 11ser(s). Identification of the user(s} responsible for entering and
cha nging values for the data c lement.
• Description and comments. This part of the documentation permits che entry
of addirional norcs.

S.8.2 Docume nting 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 sepa-
rately 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-2 1 shows
che definition of a data score named l N 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. l ....
2. For consistency. data
flow names are stan·
dardlzed throughout J
the data dictionary.
.... ,........
--
3. It Is important to
document these
enimates because
.......... ......
they will affect
design decisions In
subsequent SDLC
phases.

FIGURE 5-21 A Visible Analyst screen that documents a data store


named IN STOCK.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 sub- """'
...,..r,,.- L'""'""""
_ _ _ _ ___,
processes are num-
bered I. I, 1.2, 1.3, °'8qlpl!Oft [ ftc.(tf'l tit •¥rt~.....,_ NMd tifl l · - W.......IN<t h•IWiWltf

and so on.
2. These data flows 1 '1--1+- ·• ·
will be described "9cMc rr,,. .,._, .._. ~ .. Cltttlll UAl\l!o MfJO! "1 OflM
~ 0...-4.lf.t.._ UCllD<mll:~ M.CllflOOlllllll
spcclflcally else-
where in the data
diccionary.

-[
--
,___, -..
--Qp
....
t- ...

·-·
A ""8111tor'f~-- oP'I . . te ' - l.a C!Wlet". . . . . . . . W'9 h

FIGURE S-22 A Visible Analyst screen that descnbes a process named


~.,.. M

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 d ictionary.
• De(i11itio11 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 '"' J


""'Y lYPI'
Oac.vP'IOftl IC:witomtr (fedC d.tt•
l
Alflf\:

....... .
,,,,
......
Attrlbults: ....glh .....
ill CUSTOMllt MJMll!l Ch•
lftJ !JI CUSlOMlll STATUS Ch"

I. This data structure


is named CREDIT
y
STATUS.
2. The CREDIT
...... STATUS data
structure consists
ofcwo data
elements:
CUSTOMER
NUMBER and
CUSTOMER
STATUS CODE.

FIGURE S·ll A Visible Analyst screen that documents a record. or data


structure. named CREDIT STATUS.

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 d eveloped and is updated
constantly as rhc system is implemen ted, operated, and maintained. In addition co
describing eac h 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 s howing all characteristics of data elements, records, dara
flows , processes, or any ocher selected item stored in the d ara dictio nary

~- )U, - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ .. __.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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.
VERIFY VERIFY
VERIFY
PRODUCT STOCK
PRICE
5.9.2 Modula r Design CODE LEVEL

Modular design is based on combinations


of three logical structures, sometimes called FIGURE 5-2<4 Sequence structure.
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 YES
condition or decision, and the logic follows the
Imes in the direction indicated by the arrows.
CALCULATE
l. Sequence. The complerion of steps in OVERTIME
sequential order, one after another, as NO PAY
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 FIGURE S-25 Selection structure.
two or more process steps based on
the resu lts of a res t 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. PRINT
NO PAYCHECK
3. Ite ration. The completion of a process
step thar is repeated until a specific con-
dition changes, as shown in Figure 5-26.
An example of iteration is a process that
YES
conrinues to print paychecks until it
reaches the end of the pa)•roll file. Itera-
tion also is called looping. FIGURE 5-26 lte~tion structUre.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter S Data and Process Modeling

170 5 .9 Process Description Too ls in Modular Design

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 st rucrured English, be mindful of the following
gu1delt11es:
• Use only the three building
.... blocks of equence, selection, and
iteration.
&oorltP< --==-----~
~ f •••'f"C<•~.,.... NW!lf9fll1 -dl1 ~Y1.,..,_,~, ~ I • Use indentation for readability.
........ • Use a Ii mired vocabulary, includ-
"-'c- 111pt.1f Ml ..._. 01U1U. C'-'0!1 STAlUl, H<OJC1 OOAl ing standard terms used in the dara
On«sll_. ~ ...._. fllfwll llUCTlD°'°"MXlPTmOltCtl
dictionary a nd specific words that
,_. . M Ch OftOIJt
W CUSltWO!Sl~MCOOl •" """''~004'1. • OtC de cribe the processing rules.
[I,.
o....- AC<CPTlOO«DU +---1---1 Structured English
OV!pue '1•CttDOfl0.-l An example of srrucrured
statements
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 sys-
~-- °""' . . . tem. Srruccured English can help
process descriptions accurate and
understandable to users and system
developers.
FIGURE 5 . 27 The VERIFY ORDER process description includes logical rules and Structured English might look
a structured English verst0n of the policy. Note the alignment and indentation of
the logic statements. 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 a nd programmers wbo must design the information sy~rem from the
descriptio ns.

S.9.4 Decision Tables


A decision ta ble is a logical structure that shows every combination of conditions and
outcomes. Analysts often use dccisio11 tables to describe a process a nd 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.

~- )U, - ·~• -fllllie<'f• ,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~-- - t fta111&. ...-.~ ~ij


r..a...w...,..._...., ..I_,.. 4 111.,.. .................,.t11ru
(....,..... J:gi( . . . . . - Woip-M ._..,..
.., ...,...... .,..~ .. __. ~ ~c.....,..~ .........,..,. .. ._.,.,.,.......c:-.. • ~-" .....- ""'*"....,.._...,.. ..
I'

Phase 2 Systems Analysis

S.9 Process Description Tools in Modular Design I71

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 documcnr-
ing a process, it is importanr ro ensure char every possibility is listed. In chis example, rhc
process description contain~ 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 doub les each time another condition is added.
For example, one condition creates two rules, two ,conditions create four rules, three
conditions create eight ru les, 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
the top left.
2. Enter the
~ Credit status is OK
\!,/---. Product 1
s in stock
y
y
y
N
N
y
N
N _. }--W
__
conditions Accept order x
under the Reject order x x x --@
heading. with
one condi-
FIGURE 5-2 9 Example or a simple decision table showing the processing logic or the VERIFY ORDER
tion per line.
process. To create the table. follow the four steps shown.
to represent
the customer
status and availability
or products.
3. Enter all potential VERIFY ORDER Business Process with Three Conditions
combinations ofY/N
for the conditions. • An order will be accepted only if the product is in stock and the customer's credit status is OK.
Each column rep-
resents a numbered • The credit manager can waive the credit status requirement.
possibility called a • All other orders will be rejected.
rule.
4. Place an X on the FI GURE 5 -30 A third condition has been added to the VERIFY ORDER business process. For an order to be
actJon entries area for accepted, the product must be in stock and the customer must have an accepable credit status. However. the
each rule to indicate credit manager now has the authority to waive the credit saws requirements.
whether to accept or
reiect the order.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter S Data and Process Modeling

172 5.9 Process Description Too ls 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 a ll combinations appear is rouse parterns like these. The first con-
dition 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 ru le, represents a different set of conditions. The logic muse be
carefully analyzed and che outcome f or 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 t han 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 mo re, a nd 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.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ ..
__.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

S.9 Process D escription Tools in Mo d ular De sign 173

VERIFY ORDER Process with Credit Waiver (with rules marked for
combination)
I . Because the
I 2 3 .C 5 6 7 8 product is not in
y y stock. the other
Credit status 1s OK N N conditions do not
Produet 1s in stock y y N N y y N N matter.
Waiver from credit manager y N 2. Because the

Jt
other conditions
Accept order x are met.the
Re1ect order x x x x x waiver does not
matter.

VERIFY ORDER Process with C redit 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)

C redit 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-3 2 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 t o a 5% discount and an
additional 5% discount rf they use our charge card.
• Preferred customers who do not order S1,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 promot ion policy in figure S-33.This 1s the 1n1t1al
version of the table before simplification.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ --......
...........
Chapter S Data and Process Modeling

174 5 .9 Pr o c ess Descri ption Tools in Modul ar 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 per-
son is not a preferred customer, he or she can only receive a $5 hon us 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 das hes 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 unde rstand,
and programmers fi nd it easy to work from a decision table when developing code.

CASE IN POINT 5.2: llocKSouD 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 $ I00 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'

Phase 2 Systems Analysis

S.9 Process Descr iption Tools in Modular De sign 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. Deci-
sion 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 deci-
sion 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 result-
ing sets of actions, the example has four terminating branches at the righ t side of che
tree.

Used our
y
--- 5% discount and
an additional 5%
charge card? discount
Ordered
Y
,---------<
$1 ,000 o r
y more?
- - - 5% dlacount
N
Preferred
customer?
' - - - - - - - - - - - - $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 rela-
tively simple process.

CASE IN PO INT 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 prio r experience with a. smaller competitor gave you an edge in landing the
job, and you are excited about jo ining 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 abo ut o ne 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 abo ut 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 co nsidered 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 informa-
tion 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 pro-
cess symbol, which represents the entire information system. Lower-level DFDs show
additiona l detail of t he information s,ystem through t he leveling technique of number-
ing :1nd partitioning. Leveling continues until the functional primitive processes arc
reached, which are nor decomposed further and are documented with process descrip-
tions. 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 infor-
mation 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, sclec-
non, 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'

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 non-
oh-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 bui lding 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 cond itions, 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 genera l,
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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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.
logica l 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)l l)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 mforma-
non 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 cx tcrn,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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. .............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 rab le?

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 The chapter includes three "Case in Point"
systems analysis phase of the SDLC. This chapter discussion questions to help contextuali1e the concepts
discusses object modeling techniques that analysts use to described in the text. A "Question of Ethics" considers
create a logical model. In addition to structured analysis, the situation where an employee wants to skip a course
object-oriented analysis is another way to represent and and just sit the exam and requests a copy of the training
design an information system. materials from someone else who took the course.

LEARNING OBJECTIVES CONTENTS


When you fi11is/J this chapter, yo11 should be 6. 1 Objecr·Orienrcd Analysis
able to: Case in Point 6.1: TravelBiz
6 .2 Objects
1. Demonstrate how objccr-orientcd analysis can
6.3 Attributes
be used to describe an informarion system
6.4 ~lethods
2. Explain whar an objecr represenrs in an informa· 6.5 ~lessages
tion sysrcm 6.6 Classes
3. Explain obiect artribures 6.7 Relationships Among Objecr~ and Classes
4. Explain objecc mcrho<ls 6 .8 The Unified Modeling Language (UML)
5. Explain objccr messages Case in Poinr 6.2: Hilltop Motors
Case in Poinr 6.3: Train rhe Trninerb, Inc.
6. Explain classes
6 .9 Tools
7. Explain relarion~hips among objccrs and classes A Question of Ethics
8. Draw an objecr relarionship diagram 6. 10 Summary
9. Demonscrace use of the UML ro describe Key Terms
objecr-oriented l.ystems, including use cases, Exercises
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

r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 m aintain.
Object-oriented (0 -0 ) analy~is 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 s tep is ro unde rstand basic 0 -0
terms, incl uding objects, attributes, methods, mes.sages, and classe~ . Th is chapter
shows how systems ana lysts use those te rms 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 pro-
cesses separately. An object, however, includes data and the processes that affect that
data. For example, a c ustomer 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 par-
ents and children. UM L represenrs an o bject as a rectangle with the object name at
tbe cop, fo llowed by rhc object's attri butes and m ethods.
Figure 6- 1 shows a PARENT 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 PARF.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

Instances of
PARENT Object the PARENT Object

Mary Smith
Age25
Cllaracter.stlCS Attributes Female
that describe tile Name Red
PARENT object Age
Sex
Hair color Ahmec:IAll
Age34
Male

•a Brown
Task.s tllat the
PARENT objoct
can perform
...........
a1111112m ui.-.
"ill
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 num-
ber 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.

Instances of
CHILD Object the CHILD Object

CfSD James Smltll


Age3
Characteristics Attributes Male
that describe the Name Red
CHILD Object Age
Sex
Amelia All
Hair color
Age 1
Number of slbllngs
Female
Brown
Tasks that the
CHILD objecl can
perform •...
-··
,..,
tl?h•lfr
MlatyGreene
Age t2

.........
,
Female
D Ji I Blonde

FIGURE 6 -2 The CHILD object has rive attributes and five methods. James Smith. Amelia A li. and
Mosty Greene are Instances or the CHILD object.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ ..
__.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 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 char-
acteristics 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
Method: Steps:
BRAKES when it is sent a message by pressing the
MORE FRIES t Heat oll
brake pedal. A method defines specific tasks that
:in object can perform. Ju~r ::is objects are similar co 2. All fry basket with frozen
potato strips
nouns ::ind ::irrribuces are similar to adjecrives, meThods
resemble verbs rhar describe what and how an object 3. Lowe< basket Into hot oil
does something. 4. Check for readiness
Consider a server who prepares fries in a fasc- 5. When ready, raise basket
food re!.taurant. A systems analyst might describe the and let drain
operation as a method called r.10RE FRIES, as shown 6. Pour fries Into warming
in Figure 6-3. The t.10 RE FRIES method includes the lfllY
steps required to heat the oil, fill the fry basket with 7. Add salt
frozen potato strips, lower it into the hot oil, check for
readines!>, remove che basket when ready and drain the FIGURE 6-l The MORE FRIES method requires the
oil, pour the fries into a warming tray, and add salt. server to perform scvcn specific steps.

6.5 MESSAGES

A message is ~1 command that tells an


object co perform a certain method. For Message: GOOD NIGHT
example, the message PfCK UP TOYS
directs rhe CHILD class to perform
all 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 PARENT DOG CHILD
objects can produce different results.
The concept that a message gives Causes Ille Causes the DOG Causes lhe CHILD
different meanings to different objects PARENT oo,ect lo obJOCI to go ro sleep object ID gel ready
read a bedlime SlQ(y for bed
is called pol>morphism. For example, in
Figure 6-4, the message GOOD NIGHT FIGURE 6-4 In an example or polymorphism. the message GOOD NIGHT
signals the PARENT object to read a produces different results. depending on wtuch ob1en receives 1L

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 6 Object Modeling

184 6.6 Classes

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 righ t 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, work-
ing with reusable program modules t ha t have been tested and verified. For example,
in Figure 6-5, an INSTRUCTOR object sends an ENTER GRADE message roan
instance of the STUDENT RECORD
Message: class. Note that the INSTRUCTOR
ENTER GRADE object and STUDENT RECORD class
STUDENT
INSTRUCTOR could be reused, with minor modifi-
RECORD
cations, in ocher school information
systems where many of the attributes
FIGURE 6-5 In a school Information system. an INSTRUCTOR object sends an
ENTER GRADE message to an instance ol the STUDENT RECORD class. 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 a ll 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 s uperclass 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, inst ructors, 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

6.6 Classes 185

Class Subclass

Vlllat E
Attributes Attributes
Make
Common Model
allnbulH Yur
Weight
Color lmlYAN

Common
methOds
....-. Attributes

FIGURE 6-7 A typical flmess center might


have students. Instructors. class schedules, and a
Attributes registration process.
Uncommon
Load limit SI<> I 1!1,.,'Shttlr1 1 '""
ottnbutes

SCHOOL BUS
Attributes
Uncommon Emergeoncy e•il location
allttbutes

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
PERIOH
name Class
Attributes
Name
Common --:r Date of birth
Class

........
attnbu1os
name
Attributes Subclass
Social Security number

r:Com:::::mo=n'---,:A.111
•11 .. Uncommon
attributes
Telephone number
Subelass
WllRUCIOR
Hire date
methods ... name
Title
Attributes
Pay rate
lnatructor type
Uncommon Avatlabillty
attrlbutos
llJltiodl
Uncommon ...
Giit....
7 0

methods 0
• Uncommon
methods

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 Re lationships Among Objects and Classes

6. 7 RELATIONSHIPS AMONG OBJECTS AND CLASSES

Relationships enable objects to communicate and interact as they perform business


functions and t ransactions 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 relations hip 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 t he example in Figure 6,9,
the INSTRUCTOR object (child) inherits many t raits 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 STRUCTO R. 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 Child Inherits

•llWCIOR
Attributes Attributes
So<:lal Security number Type ol lnslNCtor
Telephone number So<:lal Security number
Hire date ~:.,.._--h Telephone number
Title
Hlredate _ J
Pay rate Tiiie
Pay rate

....•••llOlllt
1lt LS
CIAO 7 'ct 111'

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 s hows 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

6.8 The Unified Modeling language (U ML) 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 C ase 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 MAKE APPOINTMENT
use case being used. Figure 6- 12 shows an example where a PATIENT (Use Case)
student adds a fitness class and PRODUCE FITNESS-CLASS (Actor)
ROSTER uses the results of ADD FITNESS-CLASS to
FIG URE 6 - 11 In a medical office s11tem. a
generate a new fitnes.'>·clas.'> roster. Similarly, if an instructor PATIENT (actor) can MAKE APPOINTMENT (use
changes hts or her availability, UPDATE TNSTRUCTOR case). The UHL symbol for a use case is an oval.The
h FORMATIO 11ses the CHA GE AVAILABILITY actor is shown as a stick figure.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 6 Object Modeling

188 6.8 The Unified Modeling Language (UML)

use case to update the


instructor's in formation.
To creare use cases, start
b)' reviewing rhe informa-
tion that gathered during
<<U5eS>> the requirements modeling
Add Rtness-Class Produce Frtnes~lass phase. The obrective is to
Student Roster 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 descrip-
tion documents the name
<<USeS>>
of the use case, the actor, a
Change Avallablllty Update lnslructor description of the use case,
Instructor ln1ormatlon
a step-by-step list of the
FIGURE 6- 12 When a student adds a class, PRODUCE FITNESS-CLASS ROSTER uses the ra~ks and actions requi red
results of ADD FITNESS-CLASS to generate a new roster. When an instructor changes his or for successfu l completion,
her availability, UPDATE INSTRUCTOR INFORMATION uses the CHANGE AVAILABILITY use
a description of alternative
case co update the Instructor's Information.
courses of action, precondi-
tions, 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: Add New Student


Actor: Student/Manager
Description: Describes the process used to add a student to a fitness-class
Successful 1. Manager checks FITNESS-CLASS SCHEDULE ob1ect for availabihty
completion: 2. Manager notifies student
3. Fitness-class is open and student pays fee
4. Manager registers student
Alternative: 1. Manager checks FITNESS-CLASS SCHEDULE object for availability
2. Fitness-class Is full
3. Manager notifies student
Precondition: Student requests litn ess-class
Postcondition: Student is enrolled in fitness-class and fees have been paid
Assumptions: 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 man-
agement 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 Writes
service

Update
Customer Service
Writer

Update
Work
Schedule

Performs
work
Mechanic

Prepare
Invoice

FIGURE 6- 1S A use case diagram t o 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 cardinal ity, 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 migh t have no spouse o r 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

Phase 2 Systems Analysis

6.8 The U nified Modeling Language (UML) I91

UML Nature of the Example Description


Notation Rellltlonshlp
o. • Zero or many Employee Payroll Deduction
An employee can have no payroll
deductions or many deductiOns
1 0. •
An employee can have no spouse or
0 .• 1 Zero or one
Employee H 0 .. 1
Spouse
one spouse

1 One end only one I Office Manager


H Sales Office
An olfoce manager manages one and
only one olfice.
1 1
t: One order can include one or many
One or many Order
H t..•
Item Ordered
items ordered

FIGURE 6· 16 Examples of UML notations that Indicate the narnre o f che relationship betwee n instances of one class
and instances of another class.

Manages
1
S11h!s Manager

Attributes
Methods Methods
1 1

Manages Assigned

o..•

Attributes
Methods Methods

Includes
Items Ordered
1..-
Attributes 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 Tralner 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
I ~ Lifeline

Message 1
I
I
Focus Focus I
I
Message 2 I

I
I *
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.
FOCUSES: A focus is identified by a narrow vertical shape that covers the lifeline.
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 ~it ion diagra m 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 ( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

6.8 The Unified Modeling language (U ML) 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 Makes l1rst
account deposit Customer closes account
Act
Existing

Assets Frozen
attached

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 a re 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 6 Object Modeling

194 6.8 The Unified Modeling Language (U ML)

Card is PIN ts
Customer accepted Custom41r accepted Customer
Inserts enters PIN requests
ATM card ~sh

Sufficlenl funds available

ATM ATM
ltd Justs provides
balance 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~• -fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---t fta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..
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 pro-
vide 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: T hey 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 tha t 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 fami ly, are typically used. These rool
underlttand t he meaning of the diagrams they hel!P create, wh ich suggests it's diffi-
cult to create a UM L diagrnm that is syntactically incorrect. These tools al!.o provide
traceability, an importa nt feature in the SDLC tha t links design a rtifacts backward ro
requirements a nd fo rward to development a nd 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

T his 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 a nal ysis, which treats da ta and processes
separately, objects include data and processes t hat can affec t 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 com-
mands, 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 ubclas~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 dia-
gram 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 informa-
tion 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 sub-
system. 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 sta te transition
diagra m 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 rep-
resenc 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'

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· rcl 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 ana lybb.
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 1he
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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Chapter 6 Object Modeling

198 Key Terms

how ob1ec1s r~pond to changes in orher objecrs, and 1he effccrs of mcmbcnh1p m classes, super-
dasscs. 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;, independen t 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 relationshi p 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 a nd 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

Cha pt e r 7 is the final chapter in the systems and pre.s entation of the system requirementS
analysis phase of the SDLC. The main objective of document to management. The chapter also explains
the systems analysis phase is to build a logical model the transition to systems design.
of the new information system. Chapters 4, S, and 6 The chapter includes three "Case in Point"
explained requirements modeling. data and process discussion questions to help contextualize the concepts
modeling. and object modeling. Chapter 7 describes described in the text. The "Question of Ethics" concerns
the remaining activities In the systems analysis phase, how truthful an answer should be when submitting a
which include evaluation of alternative solutions, response to an RFP. Is a slight exaggeration acceptable if
preparation of the system requlremenu document, it means the company will win the contract!

LEARNING OBJECTIVES CONTENTS


W/Jen you finish tbis chapter, you sl101tld be able 7. 1 Traditional Versus Web-Based Systems
to: Development
7.2 Evolving Trends
l. Explain the differences between traditional and
7.3 In-House Software Oevelopmenc Options
web-based S)Stems development
Case in Point 7 .1: Doug·s Sporting Goods
2. Explain how Web 2.0, cloud computing, and 7 .4 Oursourcing
mobile devices may affect systems development 7 .5 Offshoring
3. Explain how to selecr one of the four in-house Case in Point 7.2: Turnkey Services
:.oftware development options 7 .6 Software as a Service
4. Explain outsourcing 7 .7 Selecting a Development Strategy
5. Explain the main advanrages and the unique Case in Point 7.3: Sterling A~sociares
concerns of off:.hori ng 7.8 The Software Acquisition Process
7.9 Completion of Systems Ana lysis Tasks
6. Describe rhe concept of Sofrware a~ a Service
A Question of Ethics
7. Explain how a systems :rnalysr helps in selecting 7.10 Summary
a development strategy Key Terms
8. Execute the five steps in the software acquisition Exercises
process
9. Describe a requesr for proposal (RFP) and a
request for quotation (RFQ)
I 0. Summarize the rasks involved in completing the
sr stems analysis phase of rhe SDLC

r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~....... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., ................. .._... .., .,. ..,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
Phase 2 Systems Analysis

7.1 Trad itional 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 pro-
liferarion 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 dif-
ferences 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 chan-
nel, and systems analysts need new applicarion development tools and &olutions tO
handle the new systems.
Two represenrarive web-based development environmenrs are M icrosoft's .NET
and rhe open source MERN stack. Microsoft describes .NET as a developer plat-
form 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 differ-
ences between them. Building the application in a web-based environment can offer
greater benefits (and sometimes greater risks) when compared to a traditional envi-
ronment. The following sections list some characteristics of traditional versus web-
based 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
consulta nts.
• 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 7 Development Strategies

202 7.2 Evolving Trends

7.1 .2 W eb-Based Development: In a web-based system s development


e nvironme 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 solu-
tions for applications such as customer relationship management, order pro-
cessing, 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 softwa re us ually requires additional layers, called midd leware, to
commun icate 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 rech-
nology. 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.
Many IT professionals use the term \''cb 2.0 ro describe
NIST Cloud Computing Program - NCCP a second generation of the web rhat enables people ro
collaborate, interact, and share information much more
DESCRIPTION effectively. This new environment is based on conrinuously
.. available user applications rather than Static HTJ\-1 L wcb-

---.-_
a.....,...i......
.......................
........___,..,........ ...
,
""""""....,..n..,...,••. pages, wirhour limitations regarding rhe number of users o r
how they access, modify, and exchange data. The Web 2.0

.. ......
~,.......,.

NIST Cloud environmenr enhances interactive experiences, including


, ~
Computing wikis and biogs, a nd social networking applications such as
....
~ ..... !'@I. . . . .
Facebook, Linkedln, and Twiner.

---
~,...~

fltolt• Wwt.f~
llltl'Klloa. TNldeuf
Program As shown in Figure 7- 1, the Nationa l Institute of Stan-
. . . ~.,"" ....... ~ . . . . . . . Will l#IW• ...... l(Q1l."""*' dards and Technology (NIST) defines cloud computing as
18M(f ........... "'*"" ....... .......Cf. . . . .
~ CS...S~ C..."*'"
~,_
••• """9(P'HSi,a-. ...~
~~ .. .
•• ...... tM-S ......
"a model f or enabling ubiquitous, convenient, o n-demand
................... ~ .... hlkm.tlJl!rtiN .... ~ ........ network access ro a shared pool of configurable computing
....,.,.. -....111• ...... .........,ta ........... ........,. ....... ........_ ... ca
._,...,.nm..,.......... ......_.~ resources (e.g., networks, servers, storage, applications, and
llirClilwf~ . . . . ~"'~- ................................ ... services) chat can be rapidly provisioned and relea ed with
....._ •• __............. _......,.,._......,. ... w,,....,..,.
...............-.c...--................................ Ml'W" minimal management effort or service provider interacrion."
............................................ _,a... Cloud computing is often represented by a cloud symbol
.........
..,.._. ..............
~.._. .......... WI*" • • kll .... ,.,...... . . . . . . .
that indicates a network or the Internet. Cloud computing
FIGURE 7- 1 NIST definition of cloud computing. can be viewed as an onlioe SaaS and data environment sup-
5-«< "' ported by powerful computers that makes Web 2.0 possible.

r..a...w...,..._...., .. .................
..,...,.......,..~
• ._..,..
(....,..... J:gl( . . . . . , _ , . . 41 11.,.. ~-""'_..,.Olp" 0w.,,,.._._,..." ....... ,_,.,..,....,. -~,__.., ,,.......... ~~ij
-·~·-"*<'f•,...
t11ru . . __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

7.3 In-House Software Development Options 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 cus-
tomize) 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 commer-
cial 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 pack-
age 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 add ing
custom features a nd 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 com-
panies, 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, disad-
vantage~, 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 REASONS FOR PURCHASING A


DEVELOPMENT SOFTWARE PACKAGE
Saosfy unique business requireme nts Lower costs

Minimize changes in business procedures Requires less time to implement


and policies
Meet constraints of existing systems Proven reliability and performance
benchmarks

Mee t constraints of existing technology Requires less technical development staff


Develop Internal resources and capabilities Future upgrades provided by the vendor

Satisfy uniqu e security requirements 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 va riery of software packages available to handle horizontal
and vertical business operations, why would a firm choose to develop its own soft-
ware? Typically, companies choose in-house development to satisfy unique business

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 de velop


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 o n 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 deliver y
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 a lmost 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 requi re 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
develo pment 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.r e Package


If a companr decides no t to o utsource, a commercially available software package
might be an attractive alternative co developing irs own software. Advantages of pur-
chasing 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 a nd integrated into the systems environment,
which can rake a significant amou nt of time. Also, even though implementation
is quicker, TCO ca n be higher due to added training expenses and softwa re
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
certainl y 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 ve rsion 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.
Tryi ng 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 require-
ments, 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'

Phase 2 Systems A nalysis

7.3 In-House Software Development Options 207

standard applicarion will nor sarisfy all customers. A human resources infor-
marion 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 permis-
sible 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 pro-
ductiv1ry. 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 calcu-
lates 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 less-
expericnced 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, a nd
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-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapte r 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 requ ire spreadsheets, dacabase management programs, and other
software packages to meet t heir information needs. If user applications access corpo-
rate 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 read-
only 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 main-


tenance 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


T raditionally, firms out~ourced IT tasks as a way of controlling coses and dealing \vith
r:ipid technologica l 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. T he outsourcing trend abo has ::1ffecred
software vendors, who have adjusted their ma rketing accordingly.
A fi rm drnr offers outsourcing solutions is called a service provider. Some service
providers concentra te on specific software a pplications; others offer business services
such as order processing a nd customer billing. Still o thers offer enrerprise-w idc soft-
wa re solutions that integrate and manage functio ns such as accounting, manufactur-
ing, and inventory contro l.
Two popular outsourcing options involve application service providers and firms
tha t offer Internet business services. These terms are explained in the fo llo wing
sections.

APPLICATION SERVICE PROVIDERS: An application sen ice provider (ASP) is a


firm t ha t delivers a software applica tion, 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'

P hase 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 ~er\ 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 sup-
port, mainframe computing power for mission-critical functions, and universal access
via the Internet. Many firms, such as Rackspace, compete in the managed cloud ser-
vices 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 solu-
tion 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 t he history and financial condition of an
outsourcing firm before making a commionent.
Mergers and acq uisitions a lso caa affect ou tsourcing clients. Even with large,
financ ially healthy fi rms, a merger o r acq uisition can have some impact on clients and
customers. If stability is importa nt, an outsourcing client shou ld consider these issues.
Outsourcing can be especially a ttractive 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 consu lring 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 sta ff 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 o utsourcing 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 tha n it is to ship bulky
raw materia ls, bui ld factor ies, and deal with tariffs and transportation issues. Sev-
eral years ago, rhe IT consul ting firm Gartner, Inc., accurately forccasted the steady
growth of offsho re outsourcing and predicted that outsourcing would evolve from
labor-intensive main tenance 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, wo rkers, customers, and shareholders in some companies
have protested this tre nd and have raised public awarenes5 of possible economic
impact. Even more important, offshore outsourcing involves unique concerns regard-
ing project control, security iss ues, 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'

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 t hem the righr to use the
software under the terms o f the license agreement. Although this model still acco unts
for a large percentage of software acq uisition, a new model, called Software as a
Ser vice (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 funcrion-
aliry 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 offer-
ing!> 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 com-
panies 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 a nd a formal presentation, which is described later
in this chapter.
Even a single system can use a mjx of sofrware alternati ves. For example, a com-
pany 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 a nd 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 c ritical fac-
cors arc not overlooked and that a sound choice is made. The evalua tion 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 a lternatives rhar arc feasible,
and present the viable alternatives to management for a final decision. The process
begins wi th 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 ana lysis determines how long it takes an information
system co pay for itself through reduced costs and increased benefits. Rclurn o n
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 srrare-
gies 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 migra-
tion 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 follow-
ing sreps:
• List each development srrarcgy being cons~dcred.
• Identify all cosrs and benefits for each alterna tive. Be sure to indicate when
co~ts 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 finan cial analysis rools to each alremarive.
• Srudy the resu lt~ and prepare a report ro management.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ --......
...........
Chapte r 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 devel-


opment. 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 acq uisition.

Ste p I: Evaluate the Information System Re quireme nts


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 esti-
mated; 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 level~ , 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 s hows chat the website will genera re more new
customers, process almost 80o/o more orders, and substantially 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'

Phase 2 Systems A nalysis

7.8 The Software Acquisition Process 215

Online Order Processing System Estimated Activity During Next 12-Month Period
FUTURE GROW TH FUTURE GROWTH
(based on ex1sung (assuming new website IS
CURRENT LEVEL procedures) 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
O rder 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 informa-


cion 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 s hows 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

Unweighte d Evaluation Model for a Network Project


Inst ructions: Rate each vendor on a scale from I (low) to I 0 (high). then add vendor scores
to calculate total points.
V ENDO 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

Weighte d Evaluation Model for a Network Project


Instruc tio n s: 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.
~~~~~~~- -~~~~~~~

WEIGHT
FACTOR VENDOR A VENDOR B VENDOR C

Price 25 6 * 25=150 5 * 25 = 125 9 . 25 = 225


Compledon Date 25 2 * 25 = so 5 " 25 = 125 8 . 25 = 200
Layout/Deslp 35 8 * 35 =280 8 . 35 = 280 s .. 35 = 175
References IS 10 * IS= ISO 6 * 1S = 90 3 * IS = 4S
TOTAL POINTS 100 630 620 645

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.

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 dif-
ferent 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 a rc 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.

~- )U, - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . - Woip-M ._..,..
..,...,.......,..~ ..
__.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
I'

P hase 2 Systems A nalysis

7.8 The Software Acquisition Process 217

If vercical applications for specific industries need ro be locared, industry rrade jour-
nals 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 profcs-
ional 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
forum s 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 - n i t y. w.·,. here to help!

-=
--
0
-
,~
- - DJ 0
- CJ.
-
-- ~
--- e ---
-- e
co -- ..
L>
-·-
FIGURE 7- 10 Microsoft Community is a valuable resource for IT professionals.
Sovt<tet ~ .. ,. ""

Step 3: Evaluate the Alternatives


After identifying the a lternatives, the analyst must select the one that best firs the
company's needs. Information abou t the options should be obtained from as many
sources as possible, including vendor presentations and literature, product documcn-
tarion, trade publications, a nd companies that perform software testing and evalu-
ation. To learn more abour particular software packages, search rhe Internet using
keywords that describe the application. Websites maintained by consu ltants and ~ofr­
ware 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 Acqu isition 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 mostl y 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 transac-


tion 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 con-
trolled 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 sofc-
warc. 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

--
·-·-·-·
--- ·--··-
·--
- ----· ~

Gctxwl (1
- AHO::i , 1(1,1f1,
'" CISCO e
.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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 a llow 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 pro-
vide 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 soft-
ware vendors contact registered owners whenever a new release is available and usu-
ally offer the new release at a reduced price.

Step S: Prepare a Recommendation


T he 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 followi ng section.

7. 9 COMPLETION OF SYSTEMS ANALYSIS TASKS

To complete the systems analysis phase, the a nal)'St muse finalize the system require-
ments document, present their findings co management, a nd 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 recommenda-
tion 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 sys-
tem developer mu t deliver co users. Recall chat system requirements are identified
during the fact-finding process, and a system requirements checklist is c reated at char
nme. Various examples of system requiremenrs are listed in C hapter 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 format-
ted 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 sys-
tem requirements document will depend on the company and the complexiry of the
system.

7.9.2 Presentation to Managem e 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 require-
ments 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 objec-
tives of the system project, the objectives of thjs presentation, and what deci-
sions need to be made.
• ummarize rhe primary viable alternatives. For each a lternati ve, 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 finan-
cial 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:
• lm plemenr an oursourcing alternative. If oursourcing is selected, the analyse
will work with representatives of the service provider to achieve a smooth tran-
sition to the new environment.

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 imple-
mentation 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)1Stems 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 a ll further work. The decision mighr be based on the analyst's recommen-
dation, a shift in priorities or costs, or for o ther reasons. Wha tever rhe reason,
if that is managemcm's decision, then there are no additional tas ks for the proj-
ect o ther than ro file a ll 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 developmen t 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 develop-
ment 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, a ll these tasks-
and more-are inregrated and managed together.
Regardle~s o f the developmenr method, systems design requires accurate documen-
tation. Traditio nall y, a sy!>tem requirements document provided detai led specificatio ns
for output, input, dara, processes, and whatever else was needed. Although agile
merhocli. do not require :.t particular form of documenta tion, a s uccei.~ful develo pment
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 constructio n 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,

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 7 Development Strategies

222 7.10 Summary

the analyst migh t 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 c hanged.

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 wan t that job, we' ll have to come up with a
better answer." Thinking about it, the analyst isn't comfortable with anyth ing but a straight
answer. Is th is an ethical question? What are her options!

7. I 0 SUMMARY

This chapter described system development strategies and the preparation and presen-
tation of the system requirements document.
Traditional systems must function in various hardware and software environ-
ments, be compatible with legacy systems, and operate within the constraints of com-
pany 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 soft-
ware application.
Systems analysts must consider •veb-based development environments such as
.NET, M ERN, and various outsourcing options, including ASPs and IBSs. ASPs charge
subscriprion fees for providing application sofrware packages. IBSs offer powerful
web-based servers, software hosti ng,, a nd IT support services ro customers.
The web generation called Web 2.0 is fueling the expansion of information shar-
ing, user collaborarion, and social networking applications such a~ Twiner, Linkedfn,
and Faccbook. Another development, called cloud computing because of the com-
monly 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 soft-
ware packages from a software vendor or VAR.

r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
I'

P hase 2 Systems A nalysis

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 devel-
opmenr 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 sys-
tem co pay for itself through reduced costs and increased benefits; ROI, which com-
pares 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 analy-
sis, prepare a recommendation, and implement the solution. During software acquisi-
tion, 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 sys-
tems analysis phase. The document derails all system requirements and constraints,
recommends the best ~olution, and provides cost and time estimate~ for future devel-
opment 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, mod-
ify the current system, purchase or customize a software package, perform additional
systems analysis work, or stop all further work.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 7 Development Strategies

224 Key Terms

Ke y Te rms

applicauon \Ct\ ice pro' idtl (ASP) A finn chm delivers a wfrware applicauon, or aC(c.,s IO an appltca-
rion, 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.irdwa rc 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 provid-
mg 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~icaldc,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 bm ld 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 t bar Jre nor permanenrly terhered ro a
desk. T hey connect to 1he ncrwork wirelessly.
nc1 present l'alue (Nl'V} The rocal va lue of rhe beneffrs minus the tota l v.1lue of the coqs, w ith both the
cost~ and benefits being adjusted to reAecr the poinr in tome .it which t hey 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 out~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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 ben-
efirs (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 centra lized 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 ,o ftwa rc applica tion that ;, duwnlondcd
and in,ta llcd 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 t ha t enhances a commercial package by adding custom feature~ and
conf1gunng 11 for a parucular md usrry.
vertical application A ,oftwan: package that has been develo ped ro handle informnrion requirement\ for
a •pcc1fic rype of bu,i ne,~.
\\'ch 2.0 A ' ccond 11cncr:irio n of 1hc web ihnt enables people to collaborate, interact, Jnd ,h,irc on for-
mation much more dynamically, ba~ed on con cinuo usly avai lable user applications rather than Sto rie
HTML. web page~. lnrcracrivc experience is n ha llmark ofWeh 2.0.

~ JD» (".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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
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~ ana-
lysts? 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?

Projects
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 sys- The chapter includes three "Case in Point" dis-
tems design phase of the SDLC. User Interface design cussion questions to help con textualize the concepts
is the first task in this phase. Designing the interface is described in the text. The "Question of Ethics" consid-
extremely important because everyone wants a system ers the ethical (and possibly legal) constraints on how
that is easy to learn and use. This chapter explains how far the creative work of others can be used without
to design an effective user Interface and how to handle crediting the source. for example, In the design of a
data security and control issues. The chapter stresses company's website.
the importance of user feedback and involvement in all
design decisions.

LEARNING OBJECTIVES CONTENTS


When you fi11is/1 this chapter, you s/Jould be able 8 . 1 User Interfaces
to: 8.2 Human-Computer lntcracuon
Case in Point 8.1: Casual Observer Software
1. Explain user interfaces
8 .3 Seven Habir5 of Successful lncerfoce Designers
2. Explain che concept of hum:m-computer imerac- 8 .4 Guidelines for User lncerfoce Design
rion, including user-friendly interface design Case in Poinr 8.2: Boolean Toys
3. Summarize th e seven habits of successful inter- 8.5 Source Documenc and Form Design
face designers 8.6 Printed Output
4. Summarize rhe 10 guidelines for user interface Case in Point 8.3: Laty Eddie
design 8 . 7 Technology Issues
5. Design effective source documents a nd forms 8 .8 Securiry and Co ntrol Issues
8. 9 Emerging Trends
6. Explain printed output report design guidelines
A Question of Ethics
and principles
8.10 Summar y
7. Describe three types of printed output reports Key Terms
8. Discus~ output and input technology issues Exercises
9. Describe output and input security and conrrol
issues
10. Explain emerging user interface trends, includ-
ing modular design, responsive web design, and
prototyp e~

r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 con-
sisrs 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 lo nger 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-gen-
erated 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 sys-
tem responded w1rh an error message, which frustrated u ers and stifled pro-
duct1v1ry. ~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 corpo-
rate 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 exceptiona l user
incerfoce is essentia l 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 sug-
gests 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 eleme nt in the S)'S-
tems 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 (H Cij describes tbe relationship between computers
and the people who use rhcm ro perform rheir jobs, like the worker shown
in Figure 8-2. HCTconcepts apply to everything from smarrphones to globa l
networks. In its broadest sense, HCI includes all the commun ications and
instructions necessary ro enter inpul to the system and to obtain output in the form
of screen displays or printed reports.
Earl y 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 appli-
carions. 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 -

:--..·- -
-=--I.:..:.- ..-
... = ..............,,............. o.. ....... . . .... : ·•di.·•• . ~J.~ --~
,....OWl.tll~aMtir---....-
......... .,.., .. ~
..c coWiiJrw e -. j&SOCl'"'I
- .c "
:[::(~-11=---· :-~~,t
.,.,.....,.,......,a"'49 ... ~till- ....... .... otlon ·''

Olllr~ .. to ftilt

111•~·~- ...
prodllC'bMI ..,_... .,..,............. .,..._
l•chillilo:OC*:oew ..... HuMM~ - - ' • ' -·,-..Iii 1 • .. Cl)

_ ______ ' !
' I !/j
ill'Wtlt'............... ,.,,., . . ~...._,. .. ,. . . . . . . ...... .

.. _
...
............l'ld ..........."" ........... . ltd ................. '" ....
..... Ny
_,
. ...
..,...,.....,..,..........., .,..
. 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 U ser Interface Design

232 8 .3 Seven Habits o f Successful Interface Designers

Because I ICI has a major impact on user productivity, it get!. lots of anention-
espccially where multimillion-dollar issues are concerned. For example, in the article
"Human-Computer lnceraccion in EJeccronic Medical Records: From the Perspect ives
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, a nd noc everyone is happy about it-par ticularly
phy)icians who often struggle with electron ic health records ( !:'. HR\ ) systems that
are poorly designed. In her article, 1'1s. Ga rdner 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 \\',\R E

Casual Observer Software's main product is a program that monitors and analyzes user key-
strokes 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 u nderlyi ng business funcrions and how
the sysrem supports individual, departmental, and enrerprise goals. The overall objec-
tive is ro design an inrerface t har helps users to perform t heir jobs. A good srarting
point mighr be ro analyze a functional decom position diagra m (FDD). As descri bed in
Chapter 4, an FDD is a graph ical 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. T he immense popularity of Apple's
iOS and ~1icrosoft 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 inter-
face 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 accommo-
date 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 real-
world 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 out-
put should be attractive a nd 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 STUDENT SERVICES

The user interface should include all tasks, commands, - Pnnt Grade
-

I
and communications berween users and the information
system. The opening screen should show the main options
Register
SludenlS I Repof1S

(Figure 8-4 is an illustration). Each screen option leads to


another screen, with more options. The objective is ro offer Help
a reasonable number of choices that a user easily can com-
prehend. Too many options on one screen can confuse a
user-but coo few options increase the number of su bmenu Enter Grades Exll System
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.
FIGURE 8-4 The opening screen displays the main
options for a student registration system.A user can click
8.3.6 Invite Feedback 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, 1lclp 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 Ever ything


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 s imilar co a menu rree. U er-approved skerches and sroryboards
also can be used to document the user interface.
B)• applyi ng 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 powe rful 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 s uccessfu 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 C reat e an Inte rface That Is Easy t o Learn and Use


1. Focus on system design objectives, rather than calling arren-
tion ro the interface.

I Dau -•• IOildl Pluse s1an --..


2. Create a design rbat is easy ro undersrand and remember.
Mainrain a common design in all modules of the interface,

I Dat a ts nol sultablP.


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
a-It ti... 1ru.1rucuoru for t his consistent and predictable.
taslt and t i..."'""''°"' tast l
4. Allow users ro correct errors easily.
I Not enough a l• t o prOCHd. 5. Clearly label all controls, butrons, and icons.

IT'"' data Is lncorrec:I.


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
Ple•stt use l he proper format: buttons, but none of them has an obvious meaning. Jn the
Three lette.,. f ollowed by three
numMrs. w ith no~
bottom screen, the first five messages provide little or no
EJtomple: CTSU$ 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
FIGURE 8· 5 In the example at the top. the commands that are not available ro rhe user.
icons do not have a clear menage. In the
Help text examples at the bottom. only one
8. Make it easy to navigate or return ro any level in rhe menu
message is understandable.The others would srructure.
frustrate and annoy most users.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 han-
dle more complex tasks, the user becomes more productive. Conversely, if the inter-
face 1~ difficult to work with, productivity declines.
I. Organize tasks, commands, a nd functions in groups that resemble actual busi-
ness operations. Group functions and submenu items in a multilevel menu hier-
archy, 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 place-
ment exists. The best strategy is co design a prototype and obtain feedback
from users. Some applicacioas even allow menus to show recently used com-
mands 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 dup licate 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 applica-
t1ons 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 featu re 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 alternati ves, 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 sim-
ple and concise. lnserr blank lines between paragraphs to make Help easier ro
read, and provide examples where appropriate.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 prog-
ress 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 mes-
sages 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 communi-
cate 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 User Interface Design

238 8.4 Guidelines for User Interface Design

3. Use hyperlinks that allow users to navigate to related topics.


4. Group related objects and information. Visualize the screen the way a user will
see it, and simulate the tasks that the user will perform.
5. Screen density is important. Keep screen displays uncluttered, with enough
white space co create an artracrive, readable design.
6. Display titles, messages, and instructions in a consistent manner and in the
same general locations on all screens.
7. 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 shou ld 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 au tomati-
cally 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 cau- = =
tion, and green =go. Stick to that partern and use it when appropriate to rein-
force 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 pro-
cesses and the vocabulary of a typical user.

___...._............
... __.... .
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 aesrhct-
ics 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
FIGURE 8 -8 An e~mple of a switchboard introducing primary options. The starting point can be a ~witchboard
TurboTax. The main options are tlearly displayed on an with well-placed command buttons that allow users to
uncluttered screen-something particularly Important for navigate the system. Figure 8-8 shows the switchboard
users who are hkcly to be confused and/or ner<0us when of TurboTax introducing a tax preparation program.
beginning the iax preparation process.
Souttg • •,
The main options are clearly displayed on an uncluttered

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 begin-
ning the cax prepararion process.
2. Use a conunand buHon co initiace an action such as printing a form or request-
ing help. For example, when a user clicks the Find Student command button in
Figure 8-9, a dialog box opens wich instructions.

• - 0 x

- ..
STUDENT REGISTRATION SYSTEM Cont.ct IT Help at Ext. 2236
for user support
-..1cv...
r 2019-2020

SSH 111.. 11.. 11 11 City New Hope E2I AdYhof Aj•ls~


Liil N•nwt H.amftton ST PA !atr•n.al~t Olt
rlot N..,.e R..., Zlp l2J45
• rvll TlrM
MI M , HornePo"°""(S55)9"--
Street 607 w..15princ Strfft Worll Pl>oM (555) SU-- O PMITune

-- ,_-
Courses
Pref · • Nutnbel • SKtJon • Find Student -r-ltudtnU
MAT lU 2
"'~""'
-by•h«llrit U., ol
OS l Print Record

-· IUS
HELP

Fond~ a x
• P!Nse ent~ a SocYl Security Numbe<.
use the format w u ·UU.

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 ava ilable choices. If rhe lisr docs n ot 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 b utton, 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 d ifferent message (Choose all that
apply). Use a black dot to show selected options.
9. If check b oxes 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 rh e 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 sou rce document is completed on the
screen.
2. Restrict user access ro screen locarions where data is entered. For example, in
the Eventbrirc event manage ment data entry when rh e screen in Figu re 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 auroma rically 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 loca-
tions 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 rde r 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) o r 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 col-
umn, the input screen shou ld use the same design.
8. Display a sample format if a user must enter values in a field in a specific for-
mat. 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 sepa-
rators, 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 c reated, 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 auromar-
ically 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 ru le might
occur when entering a date, where a leading zero is needed to identify single-
digit 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 sug-
gested value. If the default value is not appropriate, the operator can change ir.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 8 User Interface Design

242 8.4 Guidelines for User Interface Design

. .
Hllp

-
..l_..... ............ p

__---.------
...........
... ............. -
......,..__ ...........
--
---
-- --
-·--
.,__ ,............__ .......... .,..,,..
.........................................

---
-
Q:li. \lt- tti.l
- . .__

__
..,.- - - - - - . .. . . .c -.. - • • •
....c- ... _.,.....__ ... ......,....._ ....
._, ..-

__... .......... ..............


................ _.,...
~"---~
~

--~---__,.
________-.---
- -... ...................... ......,....,.. ................

. .
Htlp
... p

• 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
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Phase l Systems Design

8.4 Guidelines for User Interface 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, mechan-
ical, 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 antic-
ipate 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 pro-
grams 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 . __._ ,....,_
s... ........................ _............
-~ ..... .._,
____ ,,,,. _ _ _ _

.......,......
~

- - - - ...- •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 a llow the user to save the record until he o r she enters a suitable value in
the Social Security number field.
3. A da ra I ) pc check can rest to ensure that a data item fits the required data
type. For example, a numeric field must have on ly numbers or numeric sym-
bols, and an alphabetic field can contain only the characters A through Z (or a
through z).
4. A ra nge 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 t hat a payment amount is greater than zero, but not specifying
a maximum value, is an example of a limit check.
5. A reasonableness check identi fies values that are questionable bur not neces-
sarily 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 validi ty 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, tha t 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 combina tion 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 unreason-
able. For example, if an order input for 30 units of a particula r item has an
input discount rate applicable on ly for purchases of I 00 or mo re 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 q uantities. 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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

8.4 Guidelines for User Interface 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, pro-
ducriviry, 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 alpha-
betic, 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 docu-
ments. The easiest, mosr accur:ire, and least expensive dara input strategy is auto-
mated 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 automati-
cally 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 8 U ser 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 assis-
tance from the IT staff by using a menu-driven utility program? What wou ld 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 a n 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. How-
ever, 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>_... ........ _ .. ~ ........................._ .... ._
Phase l Systems Design

8.6 Print ed Output 24 7

Heading Control
Zone Zone

lnstructioo Zone

Body
Zone

Totals
Zone

Authorization Zone

FIGU RE 8- 13 Source document zones.

lnformanon shou ld 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 pre-
printed. 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 a lso 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 o nline 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 infor-
mation, 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?

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 answe red.
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 Re port 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 porra-
ble, 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 acc urately.
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. Rightl y 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 Re port 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 spac-
ing. Pruning character-based reports on high-speed impact pnncer~ 1s a fasr, inexpen-
sive method for producing large-scale reports, such as payroll or mventory reports, or
registra tion 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 pre-
pare 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 Re port Design Principles


Printed reporrs must be att ractive, 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, s uch as Store
Number, changes, a control break occurs. A control break usually causes specific
actions, such as printing subtotals for a gro up 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 well-
designed 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

8.6 Print ed Output 249

REPORT HEADER.S AND FOOTERS: Every report should have a report header and
a report footer. The report header, which appears at the beginning of the report, iden-
tifies 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 hours fields


Employee Hours
Week end ing date: 6128/2019 } report header

Store
Number
Emp loyee
Name Position
Regular
Hours
Overtime
Hours
Total
Hours } page header

8 Andres, Marguerite Clerk 20.0 0.0 20.0


8 Bogema, Michelle Clerk 12.5 0.0 12.5
8 Davenport, Kim Asst Mgr 40.0 5.0 45.0
8 Lemka, Susan Clerk 32.7 o.o 32.7
8 Ramirez, Rudy Manager 40.0 8.5 48.5
8 Ullery, Ruth Clerk 20.0 0.0 20.0
control break
on Store Store 8 totals: 165.2 13.5 178.7 } group footer

Number field

17 De Mar!Jnl, Jenniler Clerk 40.0 8.4 48.4


17 Haff Lisa Manager 40.0 00 40.0
17 R1ttenbery, Sandra Cterk 40.0 11 0 51.0
17 Wyer. Elizabeth Clerk 20.0 00 20.0
17 Zeogler Cealle Clerk 32.0 00 32.0

Store 17 totals: 172.0 19 4 191.4

Grand totals: 337.2 32.9 370.1 } report footer

Page 1 } page footer

FI GU RE 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 s hould be shorr but descriptive. Avoid abbreviations unless the
users will unde rstand 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.

Not•: Tl* -
pUllll9l1 Ol'lllne
_ , , llllPll' "'----tho kind"' d i ! _ you deolgn- - .,.,

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 Re ports


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 informa-
tion, 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 tha t were not delivered wi-rhin a specified time period.

SUMMARY REPORTS: Upper-level managers often wa nt ro sec toral figu res a nd 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. Simila rl 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 p rinted 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 tech nology
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 wo uld 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 smarc-
phone, a tablcr, or a 23-inch desktop monitor.
The following sections discuss outpur and input technology separately, bur inter-
face designers should always be al ere to the possible opportunities, or potential prob-
lems, 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 com-
municate 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, doc-
uments, and orher rypes of output that might be accessed from workstarions, note-
books, tablets, smarrphones, and other devices. How the information will be used,
stored, and retrieved must also be considered. The following subsections explain va ri-
ous 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 inte rfaces that display
ourpur and nccept input from cusromers. For example, a business can link irs inven-
mry system to its website so the o urput from the inven tory system is displayed as an
o n 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 pro-
vides 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 prere-
corded \.. 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
a udiences.

EMAIL: Email is an essential means of internal and external business communica-


tion. Employees send and receive email on local or wide area networks, including the
Internet. Companies send new product information to customers via email, and finan-
cial services companies use email messages ro confirm on line srock trades. Employees
use ema il to exchange documents, data, a nd schedules and to share business-related
information they need to perform th eir jobs. In ma ny firms, email has virtually
replaced traditio nal 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 communi-
cation, 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:-..•~-".....-""'*"....,.._...,.. ..
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 prod-
uces rhar combine porrable computing power, multimedia capabilit)', and lnterncr
access.

DIGITAL AUDIO, IMAGES, AND V I DEO: Sounds, images, and video clips can be cap-
tured, 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 bal-
ance, or derermine rhe current price of a mutual fund.
If a picture i!> worrh a rhousand words, then digital images and video clips cer-
tainly 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 down-
loaded 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 exam-
ple, 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 transac-
tions, print receipts, and updare inventory records

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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. Busi-
nesses 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
RAD Two-way satellite interface
recogn1lion)
MICA (magnetic mk character
Advanced opt'Cal recogn&tiOl'I V1nual environments
recognnion)
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 ana-
lyst 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 busi-
ness activity requires o nline data en t ry. The online method offers major advantages,
including the immediate validation and availability of data. A popular online input
method is ~o u rce da ta a uto mation, which combines online dara entry and automated

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

8.8 Security and Control Issues 255

data capture using input devices such as radio frequency idenrificario n(RFID) tags,
magnetic data srrips, or even smarrphones. Source data automation is fast and accu-
rate and minimizes human invokement in the translation process.
~1any large companies use a combination of source daca automation and a pow-
erful 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 scan-
ners 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 a nd
update inventory dara
• Libraries that use hand held scanners co read optical strips on books

TRADE-OFFS: Although on line input offers man y advantages, it does have some dis-
advanrages. 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 ty protects privacy rights and shields the organization's proprietary
data from theft or unauthori.ted access. To ensure o utput 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 infor-
m3non, 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 sig-
narure 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 sen-
sitive data, and controlling user access. Physical security a lways 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 ~ klcss wo rkstation 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 audi r 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 recov-
ery 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 a nd 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 conri nues 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 main-
scream 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 evo-
lurion, 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 dc~ign , individual compo nenrs, 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. Modula r design is explained in more detail in C ha 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 espe-
cially imporranr in designing large-scale systems because separare reams of analysrs
and programmer can work on different a reas 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 smart-
phones. 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 mcnus-
w1thour 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 a llows 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 a nything from a ne w 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 t esting 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 o urpurs, inpurs, inrerfaces, and processes. Users can " tesr-drivc" rhc model in
a risk-free environmenr a nd 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 o nly ro validate user requirements and is disca rded
afterward.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 pro-
totypes and constanrly adjusting them to user requirements. As the agile process con-
tinues, 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 tha t 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 out-
puts, 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 out-
weigh any disadvantages, the following porenrial problems should be considered:
• The rapid pace of development can creare quality problems, which are nor dis-
covered 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,
mistakenl y 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 design-
ing 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 compet-
itor, 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 tha r 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>_... ........ _ .. ~ ........................._ .... ._
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 dis-
cussion 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 head-
ers 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 pro-
cedures, 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 enter-
ing 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 proto-
typing were discussed.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 8 User Interface Design

262 Key Terms

Ke y 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 record-
ing 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 .:.1ku-
latc 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 ca lculates 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~uall 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
cont rol 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 li dation 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 on ly 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 p h ase 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 va lidmion check involl'~ a minimum or a maximum value, hut nor both.
Checking 1hat a payment amount is greater than zero, bur nor specifying a maxim um 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 va lues 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 spec-
ified 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 va lues 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 va lue' 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 end-
of-rcporr information.
report header Appears oc the beginning of a report and identifies 1hc report a\ well a• the report title,
d.1rt, and o ther 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 docu-
ments 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!(!\lchutton 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, aura l, 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 val-
ues. 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, .ivail-
ablc on demand or for a specific period co online participants.

~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Chapter 8 User Interface Design

266 Exercises

Exercises

Question s
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 infor-
manon 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 restric-
tions? 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 necessary for a systems analyst to construct the physical
systems design phase of the SOLC. During the systems model of the information system.
analysis phase, a logical model of the system was The chapter includes three "Case in Point"
created. Now, it must be decided how data will be discussion questions to help contextualize the concepts
organized, stored, and managed. These are important described in the text. The "Question of Ethics" raises
issues that affect data quality and consistency. This the important and timely issue of sharing customer data
chapter focuses on the data design skills that are w ithout their explicit consent.

LEARNING OBJECTIVES CONTENTS


Wl1e11 you finis/J t/Jis c/Japter, you should be 9. 1 Dara Design Conceprs
able to: 9.2 DBMS Components
9 .3 \'<'eh-Based Design
l. E..xplain basic data design conceprs, including
9.4 Data Design Terms
data srrucrures, DBMSs, and rhe evolution of the
9 .5 E.ntiry-Relarionship Dtagrams
relariot1al databa~e model
Case in Point 9.1: TopText Publishing
2. Explain the mam components of a DB~1S 9.6 Dara 'ormalization
3. Define the major characrcrisrics of web-based Case in Point 9 .2: CyberTo)'S
design 9 .7 Codes
4. Define dara design rerminology Case in Point 9.3: Madera Tools
5. Draw enriry-rel::irionship diagram~ 9.8 Dara Storage and Access
9.9 Dara Control
6. Apply data normalization
A Question of Ethics
7. Utilize codes to sim plify ourpur, input, ;:ind dara 9 . 1O Summary
formats Key Terms
8. Explain dara storage roots and techniques, Exercises
including logical versus physical srorage
9. Explain data coding
I 0. Explain darn control mea~urcs

r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 struc-
tures 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.

CUSTOMERS

r;w______.. ~lliiM
~ 53914 U ·ll-2019 86.S2

Transaction ' Cuatomff O.te ICode lunovnt


flumber , Number
109823497 53914 11-03 2019 °'4<g!! no.so
2100485/6 53914 11-04 2019 Re1 .. n 23.98
994184424 X9810 11 04 -2019 Owlrgr 62.67

FIGURE 9- 1 A credit card company that posts thousands of daily transactions might consider a file processing
option.

Over time, the modern relational darabase became a standard model for systems
developers. The following example of an auto service shop will 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 9 Data Design

270 9.1 Data Design Concepts

MARIO'S AUTO SHOP: Ivlario relics on rwo


file-<>riented systems, sometimes called file pro-
cessing 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
FIGURE 9 -2 In the example shown here. data about the means that some dara is stored in rwo different
mechanic, the customer, and the brake job might be stored in a places, and the data might o r might not be con-
file-oriented system or In a dacabase system. sistent. For example, rliree data items (Mechanic
No, Name, :111d Pay Rate) are srorcd in both
files. This redundancy is a major disadvan-
tage of file-oriented systems because it threatens data quality and inregriry. In face,
Figure 9-3 includes a typical discrepancy: Jim J ones' pay rate is s hown as $18.90 in
the Ivl ECHANIC SYSTEM. file a nd$ L9.80 in the JOB SYSTEM file.

MECHANIC SYSTEM
-No
-
MECHANIC

,.,,_
""°"'
5UIUS
......,....,.
!:i! MIOW« a
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
JOB SYSTEM
JobNo
Worl: Coclf
Houn
Dolt
r..wchan.cNo
~
Poy Rlt•

,!: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'"'
1110 l\IW<CS ... 0 U/)/201q 11 J.,.,...,fm SllSO
1.14 ALIGN .J.O 12/6/lOJS 2J $20.00
"""'"' \\ .. y
... '

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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 relatio nal 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 envi-
ronment. Figure 9-5 shows a company-wide data base SALES
that supports four separate information systems. DATABASE
A database management system (DBMS) is a collec-
tion 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. FIGURE 9-5 In chis enmple, a sales dacabase an
support four separate business systems.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~----···---~~-.,.-"~ --......
...........
Chapter 9 Data Design

272 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 appli-
cations 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
maintain. The compromise, in many cases, is a
Database clienr/server design, where processing is shared
Adm n1s1rators
1
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

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
Relatedt J interface and support for their business require-
Users Information ments, a systems analyst must understand all of the
Systems
components of a DBMS. ln addition ro interfaces
for users, DBAs, and related systems, a DBMS also
FIGURE 9-6 In addition to interfac.es for useN. database has a data manipulation language, a schema and
administratoN, and related information systems. a DBMS also has
a data manipulation language. a sc.hema and subschemas, and a
subschemas, and a physical data repository, as
physkal data repository. 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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.2 DBM S Components 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 quer y by example (QBE) language, che user provides an example of the data
requested. Many database programs also use Strucrured Query Lang uage (SQL),
·which is a language that a llows 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 a t 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
.._

-- __
-= ~--

• --
-... --• ..-
II ll
QBE
) request

data Mructures, collecting and reporting parrems of


database usage, and detecting and reporting database
irregularities. ~ ---__ -.. .
~-===-=·~··
"
.... ~.....
_,..,......,._,.......,.._ ,..
_..,.
- . c - ..............
SOL
) commands

FIGURE 9-7 Using QBE.a user can display all 2019 Ford
RELATED INFORMATION SYSTEMS: A DBMS
Fusions that have a power moonroof and are either Ume
can support several related information systems that Squeeze or Blue Candy color.
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
The complete definition of a database, including descriptions of all fields, tables,
and relationships, is called a schema. One or more subschemas can a lso 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 indjvidua l 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 communica-
tion 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 under-
stands and can execute, similar ro the ones shown in Figure 9-7. Another common
standard is called java database connecti,;ty (JDBC). J DBC 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 I0, 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
requi res 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 EXPLANATION
Global access The Internet enables worldwide access, using existing infrastructure
and standard telecommunications protocols.
Ease of use Web browsers provide a familiar interface that 1s user-friendly and
easily learned.
Multiple platforms 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.
Cost effectiveness Initial investment is relatively low because the Internet serves as the
communication network. Users require only a browser. and web-
based systems do not require powerful workstations. Flexibility is
high because numerous outsourcing options exist for development,
hosting. maintenance. and system support.
Security issues 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.
Adaptability Issues 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.4 Data Design Terms 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 enri-
cies named CUSTOMER, ORDER, PRODUCT, and SUPPLIER. \'<lhen DFDs were
prepared during the systems analysis phase, various entities and data stores were
identified. Now the rela tionships 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, a lso 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, s uch 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 a lso 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 cou rse,
the primary key must be a combination of student number a nd course ID. In that
case, the primary key is called a combination key. A combination key a lso can be
called a composite key, concatena ted key, or multivalued key.
Figure 9-10 shows four different tables: STUDENT, ADVISOR, COURSE, and
GRADE. Three of these tables have single-field primary ke ys. Note thar in the

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 1' TOTAl ' GPA I ADVISOR


NUMBER NAME CREDITS NUMBER
1035 Linda Mllrk 14 3.40 49

3397 SamCerr 9 3. 75 49

407D Kelly Goldman 8 2.50 23

i -- - - 1 common fields ,_ _ _.,

23 Alice Jones 8 230


49 Carlton Smith 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 Computer Science I 3
ENG101 EnsfLSh Composition 3
MKT2U Macfoeting Management 3

FIGURE 9- 10 Examples of common fields, primary keys. candidate keys. foreign keys, and seconcbry keys.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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: Con trary 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 candi-
date 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 NUMBE R fie ld appea rs in both the STUDENT table and
the ADVISOR table a nd joins t he tables together. Note that ADVISOR NUMBER is
a primaqr key in the ADVJSO R table, where it uniq uely identifies each advisor, and
is a foreign key in the STUDENT table. A foreig n 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 exam-
ple, 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 o r retrieve records. Secondary key values a re not unique. For example,
to access records for only those customers in a specific postal code, the postal code
field wou ld be used as a secondary key. Seconda ry keys a lso can be used to sort or
display records in a certain order. For example, the G PA field in a STUDENT fi le
could be used ro displny records for a ll students in grade point order.
The need for a secondary key arises because a table can have on ly 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 par-
ticular 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 un less 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 h as 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 t able 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 int o rhe
design. Figure 9-11 shows a Microsoft Access screen thar identifies a common field
and allows rhc user ro enforce referential integrity rules.

JOB
lOONo
Woft.Codir
Houn

-
MlCHAN:C
°"''

Patble
Httt O•tt
status
IM<NIN<No

P ly RM>

lmutanc:t Edll Re~11onsh1ps 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 o rders. An information system muse recognize the relationships a mo ng
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 rclarion-
ships and interaction among syscem entities. An ERD provides an overall view of rhe
syscem and a blueprint for creating rhe physical data st ructures.

9.5. 1 Drawing an ERO


DOCTOR The first step is co list the entities chat were idenrified during rhe sys-
tems analysis phase and ro consider the nacure of the re larion~hips rhar
link chem. Ar rhis stage, a simplified method can be used ro show rhe
relations hi ps between entities.
Although there a re different ways co draw ERDs, a popular merhod
A doctor is ro represen t entities as recta ngles and re lationships as diamond
treats TREATS shapes. T he enti ry rectangles are labeled with s ingular nouns, and
a patient
the relarionshi p diamo nds a re labeled with verbs, usually in a cop-to-
bottom and left-to-right fashion. Fo r 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
9.5.2 Types of Relationships
T hree rypes of relationships can exist between entities: one-co-one,
FIGURE 9 - 12 In an enuty-relaaonship one-to-many, and many-to-many.
diagram, entities are labeled with singular
nouns and relationships are labeled with
A one-to-one relationship, abbreviated 1: l , exists when exactly
verbs. The rebuonship is interpreted as one of the second entity occurs for each instance of rhe first entity.
a Slmple Enghsh sentence Figure 9-13 shows examples of several l: l relationships. A number
I is placed alongside e ach of the two connecting lines ro indicate the
I: I relationship.
A one-to-man)' relationship,
abbreviated l :M, exists when one occur-
OFFICE 1 1 rence of the first entity can relate to many
HEADS OFFICE
MANAGER insrances of the second enriry, bur each
instance of rhe second entity can associate
wirh only one insrance of rhe first enri1y.
VEHICLE ID 1 1 For example, rhc re lationship herween
ASSIGNED VEHICLE
NUMBER TO DEPARTMENT a nd EM PLOYEE is
one-to-ma ny: One depa rrmen t can have
many employees, but each employee
SOCIAL 1 1 works in only one deparcmenr at a time.
SECURITY ASSIGNED PERSON Figure 9-14 shows several l:M rela-
TO
tionships. T he line connccring the many
entity is labeled with the Jeerer M, and
1 1 the number l labels the other connect-
DEPARTMENT CHAIRS DEPARTMENT ing line. How many is many? The first
HEAD
I :NI relationship shown in Figure 9-14
shows the entities IN DIVIDUAL and
FIGURE 9- 13 Examples of one-to-one ( 1:1) relationships.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.5 Entity-Re lationship Diagrams 281

AUTOMOBILE. One individual mighr


own five auromobile , or one, or none.
DEPARTMENT EMPLOYS EMPLOYEE
Thus, many can mean any number,
including 1ero.
A man y-to-man} relation\hip, abbrevi-
ared M :N , exisrs when one instance of the M
first entity can relate ro man y instances INDIVIDUAL OINNS - - - ' AUTOMOBILE
of rhe second enriry, and one instance
of the second entit)' can relate to many
instances of the first entity. The relation· 1 M
CUSTOMER PLACES ORDER
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 FACULTY M
shows several M:N entity relationships. ADVISES STUDENT
ADVISOR
One of the connecting lines is labeled
with the letter M, and the lctrer N labels
FIGURE 9-14 Examples of one-to-many (l :M) relationships.
the other connection.

M N
STUDENT ENROLLS CLASS
IN

REGISTRATION

M N
PASSENGER RESERVES FLIGHT
SEATON

RESERVATION --- - - - - - - - - - - --l assocoahve entity

M N
ORDER LISTS 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 9 Data Design

282 9.5 Entity-Relationship Diagrams

Note that an M:N relationship is different from 1:1 o r 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 rela-
tionships 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

SERVES

M
CUSTOMER PLACES ORDER WAREHOUSE

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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.5 Entity-Re lationship Diagrams 283

9.5.3 Cardina lity UML


SYMBOL MEANING REPRESENTATION
Afcer an analyst draws an initial ERD,
he or she must define the relationships
One •nd only one 1
in more detail hy u~mg a technique
called cardinality. Cardinality describes
the numeric relationship between two
I 111

p1
entities and shows how instances of one

I
entity relate to instances of another entity. Oneorm•ny 1.:
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 cus-
tomer. An analyst can model this inter-
action by adding cardinality notation, I po Zero, or one,
or m•ny
o.:

which uses special symbols to represent

I
the relationship.
A common method of cardina lity
notation is called crow'~ foot notation
because of the shapes, which include
I I 0 Zero, or one 0 ..1

circles, bars, and symbols that indicate FIGURE 9- 17 Crow's foot notation Is a common method of indicating
various possibilities. A single bar indicates cardinality. The four examples show how various symbols can be used to
describe che relationships between entitles.
one, a double bar indicates one and only
one, a circle indicates zero, and a crow's
foot indicates many. Figure 9- 17 shows EXAMPLES OF CARDINALITY NOTATION
various cardinality symbols, their mean-
ings, and the UML representations of rhe
relationships. As described 111 Chapter 4, CUSTOMER PLACES ORDER
the Unified Modeling Language (UML) is
a widely used method of visualizing and One and only one CUSTOMER can place anywhere from zero 10 many of !he
documenting software ~ystems design. ORDER entity.
In Figure 9-18, four examples of car-
dinality notation are shown. In the first INCLUDES
ITEM
ORDER ORDERED
example, one and only one CUSTOMER
can place anywhere from zero to many
of the ORDER entity. In the second One and only one ORDER can Include one ITEM ORDERED or many.
example, one and only one ORDER can
include one ITEM ORDERED or many. EMPLOYEE HAS SPOUSE
In the third example, one and only one
EMPLOYEE can have one SPOUSE
or none. Jn rhe fourth example, one One and only one EMPLOYEE can have one SPOUSE or NONE.
EMPLOYEE, or many employees, or
none, can be assigned to one PROJECT, ASSIGNED
EMPLOYEE PROJECT
or many projects, or none. TO
Most CASE products support the
drawing of ERDs from entities in the One EMPLOYEE, or many employees, or none, can be asS<gned lo one
data repository. Figure 9- 19 shows part PROJECT, or many projec1s. or none.

of a library system ERD drawn using FI GURE 9- 18 In the first example of cardinality notation.one and only one
the Visible Analyst CASE cool. Nore that 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
crow's foot notation i~ used to show the many. In the third example, one ~d only one EMPLOYEE an tl3Ye one SPOUSE
nature of the relarionship~. which are or none. In the fourth eicample. one EMPLOYEE.or many employees.or none.
described in both directions. 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

FI GURE 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: T orTE..' \I Pusus11L'\ G

TopText Publishing is a textbook publishing company with a headquarters location. a ware-


house, and three sales offices that each has a sales manager and sales reps. TopText sells to
schools, colleges, and individual customers. Many authors write more than one book for
TopText, and more than one author writes some books. TopText maintains an active list of
more than 100 books, each identified by a unive rsal code called an ISBN. How would you
draw an ERO for the TopText information system, including cardinality notation!

9.6 DATA NORMALIZATION

Normalizatio n is the process of c reating table designs by assign ing specific fields
or attributes to each table in t he da tabase. A ta ble design specifics the fields a nd
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 tha t 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 for mulated 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 nor-
mal 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'!> struc-
ture, 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 grou p is s hown in Figu re 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 (s ubsidiary) records
contained within the parent (main ) record.

pnmary key primary key tor


for ORDER repeating group

OllDER (Unnor11 1H1 1ii)

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


these two
orders have 633 ~v 1 J 9'1S J~ No
repeating 684 Sui-sizmo 4 C-876 Cebot YM
croups
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 N UMBER 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 No rmal 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.tvl BER, 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-2 1 has a combination primary
key. The primary key of the lNF design cannot be the ORDER field a lone, 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
NUtvl BER, 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
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Phase l Systems Design

9.6 Data Normalization 287

in 1NF. 1he primary key Is a unique


combmabon of a specific ORDER
and a speofic PRODUCT NUMBER

ORDER lnlNF

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
1n 1NF
t
• 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 INF.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 num-
ber. 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 prob-
lem 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 prod-
uct 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 1NF 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 combi-
nation 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 1AME, 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. Sup-
pose 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 march-
ing 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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.6 Data N ormalizat ion 289

ORDER ln2NF PRODUCT In 2NF

ORDER ORDER PRODUCT DESCRI PTION I SUPPLIER SUPPLIER 1


' ISO
DATE NUMBER NUMBER NAME
86223 9-13·2019 128 ' Steel widget A-602 Acme 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

ICJWll 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

c ustomer has ordered che product? A dummy order numbe r could be used and
later replaced with a real order number when the product is ordered ro solve
the pro blem, 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 prod-
uct 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, inconsis-
tent 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 elimi-
nated, and the three 2NF designs are superior ro both the original unnormalized rable
and the INF design.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Cha p ter 9 Data Design

290 9.6 Data Nor malizat ion

9.6.4 Third Normal Fo rm


A popular ru le of t humb is that a design is in 3NF if every non key field depends o n
the key, the whole key, and nothing but the key. A 3 NF d esign avoids redunda ncy
and dara inccgriC) probl ems cha t Still can exisr in 2NF designs.
Conti nui ng th e ORDER example, now review che PRODUCT rable design in
Figu re 9-23:
PRODUCT (PRODUCT NUMBER, DESCRIPTION, SUPPLIER NUMBER,
SUPPLfER NAtvlE, ISO)

•••
PRODUCT In 2NF ••
~~~~~~~~

..•

.
'
PRODUCT
NUMBER
IDESCRIPTION SUPPLIER : SUPPLIER
NUMBER ; NAME

I ISO

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 '


SUPPLIER In 3NF

'
PRODUCT
NUMBER
DESCRIPTION
'''
ISUPPLIER
NUMBER
'
SUPPLIER
NUMBER
ISUPPLIER 11so
NAME
128 Steel widget A-602 A-602 Acme 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 J NF because ic has no repeacing group~. T he c:i ble a lso
is in 2NF bcc:iusc the primary key is a single fi eld. But the table still has four po tcn-
cial problems:
I. To cha nge a supplier na me, every record in which tha t na me a ppears must be
cha nged. With hundreds, o r even thousands o f record s, the process would be
slow, expensive, and subject to input erro rs.
2. T he 2NF d esign a llows a supplier co ha ve a different name or ISO sta rus in
different recor ds.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.6 Data N ormalization 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 thi rd nom1al fonn (3NF) if it is in 2NF and if no nonkey field is depen-
dent 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 NU MBER, DESCRIPTION, SUPPLIER NUMBER)
SUPPLI ER (SUPPLIER NUMBER, SUPPLIER NAME, ISO)

CASE IN POINT 9.2: CYBERTOYS

You handle administrative support for CyberToys, 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 norma lization is to apply the
r ules to a representative situa tion. This section presents
two diffe rent scenarios: first a school a nd tben a rechnical
service company. If a step-by-step process is followed, data
designs can be created tha t a re efficient, maincainable, and
er ror-resistant.

EXAMPLE I : Crossroads Co llege: Consider the fami liar


situation in Figure 9-24, which depicts several entities
in the Crossroads College advising system: ADVlSOR,
COURSE, and STUDENT. The relationships among the FIG URE 9·24 A faculty advisor, who represents an
three entities are shown in the ERO in Figure 9-25. The em1ty, can advise many students, each of whom can
following secnons discuss normali1.arion rules for these reginer for one or many courses.
three entities. "' r

r..,,...JID)r-..1-.. 4•11_.. •...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
Chapter 9 Data Design

292 9 .6 Data Normalization

Before the normaliz~nion process is


M scarred, it is noted that the TUDENT
ADVISOR ADVISES STUDENT
cable contains field5 rhar rclarc ro rhe
ADVISOR and COURSE cnrirics, so a
d ecision is made co begin with the initial
design for the STUDEl\'T cable, which
is shown m Figure 9-26. Nore rhac the
TAKES rable design includes the student number,
student name, coral credits taken, grade
point average (GPA), advisor number,
N advisor name, and, for every course the
student has taken, the course number,
course description, number of credits, and
COURSE
grade received.
The STUDENT table in Figure 9-26 is
FIGURE 9°25 An Initial entity-relationship diagram for ADVISOR, STUDENT. m1nor111aljzed because it has a repeating
and COURSE. group. Tbe STUDENT table design can be
written as:
STUDENT (STUDENT NUMBER, STUDENT NAME, TOTAL CREDITS,
Gl'A, ADVISOR NUMBER, ADVfSOR NAME, OFFICE, (COURSf.. ~l..!.i.~B~R,
CREDIT HOURS, GRADE))
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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

9.6 Data Normalization 293

Figure 9-27 shows the 1NF 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.

111 1NF. 1he pnmary key is a unique combmatlO!l ol a


STUDENT NUMBER and a speofic COURSE NUMBER

STUDENT In lNF

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 Sm1th B2U ENGlOl l B

1035 l..nd1 47 3.60 49 Smrth B2U CHMll2 4 A

1015 Un.U 47 3.60 49 Smith Blll 8US105 2 A

3397 Sam 29 l.00 49 Smith 82U ENG101 l A

3397 5.tm 29 l.00 49 Smith 82U MICT2U 3 c


3397 s.tm 3.00 Sm1th 82U CSCUl 4 B

4(J7Q kelty
29

14 2.90
"'
23 Jones 033 CSClSl 4 8
<IOJO Kelly 14 2.90 23 Jones C333 CHM Ill 4 c
<IO'IO Kelly 14 2.90 23 JO<> es Clll ENGIOl 3 c
Kelly 14 2.90 Jones 013 c
"°'° 23 lkJSUIS 2

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 o f 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 CRED ITS, GPA,
ADVISOR NUMBER, ADVISOR NAME, OFFICE)
COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUMBER, GRADE)
The original I F STUD ENT 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 COURSE In ZNF

STUDENT I STUDENT
NUMBEll , NAME
lOlS '' llr>da
ITOTAL I GPA
CREDITS
47 3.60
ADVISOR
NUMBER
49
ADVISOR
NAME
Smith
OFFICE

B2U
'
COUllSE
NUMBER
BUSlOS
I'
CREDIT
HOURS
2

3397 Sam l.00 49 Smith B2U CHM112 4

4070 Kelly 2.90 23 Jones C333 CSClSl 4

ENG101 3

MKTlU 3

GRADElnZNF

STUDENT
' ' ' +! COURSE
' ' ' I GRADE
NUMBER NUMBER
I
I

1035 CSCJ.51 B

1035 MKT212 A

103S ENGlOl a
1n2NF
• All fields now depend lOlS CHMU2 A
on the whole pnmary
key, but some fields lOlS BUSlOS A
aleo might depend on
other fields lhat are nol 3397 ENG101 A
pan of the pnrnary key c.........
• The pnrnary key of 3397 MICT2U c
GRADE ls a unique
combination of two 3397 CSCUl a
foreign key values.
STUDENT NUMBER 4070 CSCUl a
and COURSE NUMBER
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:
ST UDENT (STUDENT NUMBER, STUDE1''T NAME, TOTAL CREDITS, GPA,
ADVISOR NUNIBER)

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~• -fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Sys tems Design

9.6 Data N ormalizat ion 295

ADVISOR (ADVISOR NUMBER, ADVISOR A?vlE, OFFICE)


COURSE (COURSE NUMBER, CREDIT HOURS)
GRADE (STUDENT NUMBER, COURSE NUfy1BER, GRADE)

STUDENT In ZNF

STUDENT
NUMBER
I STUDENT
NAME
I TOTAL
CREDITS
IGPA I ADVISOR
NUMBER
. ADVISOR
: NAME
I OFFICE

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
NUMBER
101)
INAME ICREDITS I
STUDENT TOTAL

47
GPA

3.60
'''
INUMBER
ADVISOR
'
ADVISOR
NUMBER
49
I ADVISOR I OFFICE
NAME
Smith B2U

3397 Sam 3.00 23 Jones C333

4070 14 2.90 23

FIG URE 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 1
ADVISES
M
ADVISOR STUDENT
normalizarion. Now rhere
are four entities: STUDENT,
ADVISOR, COURSE, 1
and GRADE (which is
an associative entiry).
Note how Figure 9-25, RECEIVES
which was drawn before
GRADE was identified as
an entity, shows that che
M:N relationship between M
STUDENT and COURSE
has been converted inco
two l:M relationships:
one relationship between
STUDENT and GRADE
COURSE
1
SHOWS
M
GRADE

FIGURE 9 °30 The entity-relationship diagram for STUDENT. ADVISOR. and COURSE after
l assoc1atm
enllty

and rhe other rclacionship


normaliution. The GRADE entry was idemified during the normaliution process. GRADE is an
bcrween COURSE and associative enoty that links the STUDENT and COURSE tables
GRADE.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 9 Data Design

296 9.6 Data Normalization

-,..._
- . To creare 3NF designs, the nanire of first, second, and

-- \• -- -----
,. ....... rhird normal forms must be understood. A S)' rems ana-

- . .--- ....I -
lyst will encounter designs that are much more complex
·- T- • than the examples in this chapter.

--
-
·- \.. -- • EXAMPLE 2: Magic J\i\ aintenance: .Nlagic Maintenance

·------ I
• ~
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
FIGURE 9-31 A relational database design for a
computer service company uses common fields co link scructure.
the cables and form an overall daca structure. Notice the Figure 9-32 shows even more derail, including sample
one-to-many notation symbols and the primary keys. dara, primary keys, and common fields. Nore rhat rhe
which are indicated with gold-colored key symbols. eariries include customers, technicians, service calls,

lW IAIOll ('OOf \ ".J <Um>MIR


C~T-NUM
s · CUSHAST · ' CVSHlllST • ' CUST·A~S • CUH-Cll'f • CUU·STAT( ·
- x

lAllOR COD£ HOURLY-RATl •


• A Sl5.00
• 1456 JonH Albo'1 •J0.11.DrM Dtnv..- co

•c
• $<U.OO
~soo


1913
2S16
vatdt:J
Gonutez
1nn1
Jul"I
1011 H1lllop Rood Chotlott•
67UthSttHt Stott It
~c
WA

---
s." CA
. 0 SMOO


6121
ll7<iO
· 1848
a.111
SAruono
thly

,....
JIC~le
101 MJlti Slfoet

'""•bt"V c.....
3;JlSm!1hUM
.....Jat1nto
..,
H\.ldlOn
"'A
Fl

~ SOMCf <ALl\ x
:::J SUMCl 1.-'- OOAll'
.
x
. CAU·N~JM . CUST·NUM .
T
OATf . T[(H·NUM .
CAU· NUM • lABOR-CODE lABOR·HOURS
• 10796 14)6 U/U/2019 04

-
'10796
107'6
" cA LS
2.0
• 10797 2136 U/13/2019 17
• 10791 11/13/201' 04
10791 B s.o • 10799 1456 12/l.S/2019 21
10799 c LS - 10800 6J21 U/16/201' 21
10799 D 1.S I • 10801 14)6 1211"'2019 09
10801 A 2.5

::;J SEIMCC Pi ITTOfTAll \ x ;:J TI'OI x


CAU·lllUM .
PART·NUM . QTY . TECH NUM
'
. T£CH·lAST . TECH FIRST . HlRE·OATI .
107'6 00-9192 4 • 04 Robison GefTY 6/1/'1008
10796 SS·llll 2 • 0'9 Wh1tf1eld oa..d 8/1/2001
~
~··
10797 AB-6784 6 17 Kaplan 1/1/l'J93
10799 AB-6784 1 • 20 Chood L11land U/1/2003
10799 XC-3133 15 • . 21 Johnson Mane 10/1/2014
10800 SS-1024 8

I i1] PARTS \ 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
JUMPER
S38.00 S50.00 41 •' Common fields

I • 5$-lUI
• XC·llll CABLE
SU.SO
<:6 75
SlS.00 3
<=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.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gl( . . . . . -Woip-M ._..,..
..,...,.......,..~ .. __.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 Code s


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 j ohn 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 posta l 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 3290 1-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 entr y is correct.

Broad geographical FL Florida Tech


locallon In Ot1ando Melbourne
150 W. Unlvers11y Blvd.
soUlheastem US East

3 29 01 6975

F IG URE 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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
orde r 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. Col-
lege 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. Alpha betic 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

ATL
--- ORO__ u-IR ....HNO
------ LAX sold: GN for gardening supplies,
HW for hardware, and EL for
electronics.
oFW FRA aDG -·--- AMS ···-
OEN b. AbbreYiation codes are alphabetic
abbreviations. For example, standard
state codes include NY for New York,
PHX
--- LAS--- MAD IAH
-.-... . ._ . HKG
- .................
~....... ...
ME for ~l aine, and MN for Minne-
sota. Some abbreviation codes arc
MSP o1W-·-- aKK SFO MIA .....
.. _.__ .... _,........ ..
called mnemonic codes because they
use a specific combination of lcncrs
that arc easy to remember. Many
JFK
-·- -- LGW
--- EWR SIN - NRT
_, _____. ..... ..... .......
three-character airport codes such
as those pictured in Figure 9-34 arc
mnemonic codes, such as ATL for
PEK
------ seA - sTL
-·---- MCO VY! _._ ----·~
......... ..-... ....
............. Atlanta and MIA for Miami. I Iowcver,
some airport codes arc not mnemonic,
FIG UR E 9-3 4 Abbreviations for some of the world's busiest airports. 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
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~
Phase l Systems Design

9.7 Codes 299

Section code
Warehouse location code Bin number

'
11 2
'
05 3
'
27

A
Floor number - - - - - - - number
~------ Aisle

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 mag-
azine subscription codes arc derivation codes.
For example, one popular magazine uses a
subscriber's five-digit postal code, followedl by
31749 ADE 34 EBE
the first, third, and fourth letters of the sub-
scriber's last name, the last two digits of the
subscriber's house number, and the first, third,
FIGURE 9-36 A magazine subscriber code is derived from
and fourth letters of the subscriber's street various parts of the name and addreu.
name. A sample is shown in Figure 9-36.
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 (0 1, 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 ot hers 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, o r the num ber o ne (1 ) with the lowercase lette r L (I) or uppercase
lcrrer I. For example, rhe five-character code 5Z08 l easi ly can be misread as
5Z08I, o r 52081.
• Make codes meaningful. Codes should be easy to remember, user-friend ly,
convenient, and easy to interpret. Using S\Xl as a code for the southwest sa les
region, for example, has far more mea ning than t he code 14. Using ENG as t he
code for t he 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 attri-
butes. For example, if a single code is used to identify the combination of an
employee's depa rtment and t he 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 depa rtment, or both. A separare code for each separate charac-
teristic makes much more sense.
• Keep codes consistent. Foe example, if the payroll system al ready is using two-
digir codes for departments, do not create a new, different coding scheme for
rhe personnel sysrcm. lf the two systems already arc using differen t 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 a nd 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 informa-
tion 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
Sales
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 ~ystcm and the human
r
DATA WAREHOUSE
resources informarion ~ystem, as
!.hown in Figure 9-37. Without a 1
data warehouse, it would be diffi- Human
Resources
cult for a user to extract darn char Information Information
spans several information systems System Results
System
and time frames. Rather than Sates ref)<esenta1ive 121
sold $375.784 10 Jo·Mar
accessing separate system~, a data Input data lndustnea during Juno 2019 Input data
warehouse stores transaction data
in a format that allows users to FIG URE 9-3 7 A data warehouse stores dat3 frolTl several systems. By selecting data
retrieve and analyze the data easily. dimensions. a user can retrieve specific Information without having to know how or
While a data warehouse typ- 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 spe-
cific 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 s pecific
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 archi-
recrure rhar includes derailed planning and specifications.

DATA MINING: Da ta mining software looks for meaningful data patterns and rela-
tionships. For example, dara mining sofrware could help a consumer products firm
identify porenrial customers based on their prior purchases. lnformalion about cus-
tomer 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 visito rs, bur most of it is
of lirrle value. His article mentions tbar smart marketers and business analysts are
using data mining techniq ues, which he describes as "machine learning algorirhms
thar find buried parrerns in databases, and report or act on those findings." He con-
cludes by saying tha r "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, meas urab le 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 pur-
chase 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:i-
rion would be very valua ble 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:ir-
kers 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 tech-
nique relies on associariou r u.le learning and is often called mar ket basker a nalysis.

9.8.2 Logical Versus Physical Storage


It is important to uuderstand the difference between logical stornge and physical
storage. Logical sto rage refers to data that a user can view, undersrand, and access,
regardless of how or where that information actually is organized or stored. Tn con-
trast, phy~ical 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 migh t 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:-..•~-".....-""'*"....,.._...,.. ..
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 t he data is stored physically.
The term record usually refers ro a logical record. Whenever an application pro-
gran1 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 t he 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 standa rds and support, as shown in Figure 9-38.

~ The Unicode Consortium c.-. .,, , .,. _ , s-

---- .
,.Q
n.c •••

• n.--
OuktlUr>b
C:-0-

UTC_,.._
a.Oii

- ...
n.u............ ..

... _
.............. (C\.OllQ ..

--
QJTC

.
"1t• I w.-O. •

_
......... o... 7 ..
CW-11-

-.
UTC~ ........

.

- .. ........
• -- ~~.Jd!Llf!JA&Ht0soctrQl.llll t''
wr--110 . . pp1t• l'll.._~
't W l:lV'IVGil
-·~
l!lll.Lll!lllllll.Jj--.il!C- ,_., ...,

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 ""' ,,,... "'

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 t he yea r 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 rha r 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 exam-
ple, 20150504 (May 4, 20 15) is later than 2013092 7 (September 27, 20 L3 ).
But wbat if dates must be used in calculations? For
example, if a manufacturing order placed on June 23 takes

- ..
DI


• 1 M

• c
• .!. •

0 t
three weeks co complete, when will the order be ready? If a
payment due o n August 13 is nor paid until April 27 of the
, following year, exactl y how late is the payment a nd how
2'
much inteTesr is owed? In these s ituatio ns, it is easier rouse
1 absolu te daces.
•s An absolute date is the total number of da ys from some
'I, specific base date. To calculate the number of days berween
rwo absolute daces, one dare is suhtracccd from rhc other.


t(21fU
10 For example, if the base date is January I, 1900, then May
,,11 UIS 4, 2015, bas an absolute date of 42 128. Similar!)', Seprember
27, 20 13, has an absolute date value of 41 544. If rhe earlier
FIGURE 9.39 Microsoft Excel uses absolute dates In
calculations. In this example. May 4, 2019, ls displayed as dace value is subtracted from the later one, che re ult is 584
43589.and September 27. 2015.ls displayed as 42274. days. A spreadsheet can be used ro determine and displa)
The difference between the dates Is 13 I5 days. a bsolute daces easily, as shown in hgure 9-39.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
..,...,...... .,..~
~- )U,
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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, includ-
ing 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~si 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 divisio ns, which include insurance, health-care products. and financial planning
services, to name a few.
The cor porate marketing director for Worldwide has requested Tip Top's customer
shopping data to target people who might be likely to purchase items o r ser vices 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 World-
wide 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 companies-
noc 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 sys-
tems, manage data stored in separate.
A database consisrs of linked tables that form an overall data St ructure. A DB~1S
is a collection of tools, features, and inrerfaces that enable users to add, update, man-
age, access, and analrze dara in a dat abase.
DBMS designs are more powerful and flexible than crad1tional file-oriented srs-
tems. 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 data-
bases are complex and require extensive security and backup/recovery features.
DBMS components include interfaces for users, DBAs, and related systems; a
DM L; 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 da ta mini ng, 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 relacion-
ships :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 identi-
fies 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 sort-
ing or retrieving records.
An ERD is a graphic representation of all system entities and the relationships
among them. The ERD is based o n 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 relation-
ship, 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 sym-
bols 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 forma t.
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 abso-
lute 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, ca lled a mnemonic code.
A~Cll ScanJ, for American Standa rd C.<Jde for Information lntcrchani:c, a lLita 'mrasc coding method
u'ed on mo~t pcrmna I computers and workstation<.
a~~ociath·ecnriry 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 ,~;rhin 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~~
.......... _ _ _ , _ • .......,.. ....................
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 ind iHdual 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;fu l combination of related daca clements that is indudcd in a data flow or
retained in a d<1ra >tore. A framcwork for organizi ng 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 (OBMS i 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 mam-
frame .: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...,, pro-
cc<>\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 rela-
nonslups 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 with in an infnnnation ')'stem. For example, a Social Sccurit)' numhcr or company name
cou ld 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 w ith the informa-
tion '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 esrab-
ll\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 >tandar d 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 logica l record as a set of field<, rcgard lcs'> of how or where the data is
'torcd phy<1cally.
logical \tOraAc Refer& to informa tion 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~~
.......... _ _ _ , _ • .......,.. ....................
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 mforma-
uon 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 qua licy 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Chapter 9 Data Design

312 Key Terms

~c~ond normal form u


(2'\1- A record design is in 2NF if ic is Ill l;\J and 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'osra l
Service ii p 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 communica te with 'crver.,
and mainframe computcn..
'ubi.d1cma t\ view nf rhc datab:isc used by one or mo re: syMem; or u;cr;. t\ .,ub.,lhcma defi ne., only
rho' c p<>rtiom of the database char a parncular ' YStcm o r 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 uuor-
mauon 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
progra nurnng language and can be used to descrihe busmess processes .ind requaremcms genera II).
unnonnali1cd ;\ record rhar contains a repeating group. wh ich 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 yea r (YYYYM MDD ).

~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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
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?

Projects
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 Kan-
sas and also contr:icts irs manufacturing projects ro small firms in Canada and Mexico.
An unusual problem has occurred for this small multinationa l company: People are gemng con-
fused 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 argu-
menrs 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 The chapter includes three "Case in Point"
phase of the SDLC. This chapter describes system discussion questions to help contextualize the concepts
architecture. which translates the logical design of an described in the text. The "Question of Ethics" explores
information system into a physical blueprint. Designing the trade-offs between the potential benefits of Installing
the system architecture requires consideration of servers. tracking software on users' computers to Improve the
clients, processing methods, networks, and related issues. 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 CONTENTS


W/Jen you finis/, this chapter, yo11 should be able I 0. 1 Architecn1re Checklist
to: Case in Point I 0. J: ABC Systems
I 0.2 The Evolution of Sysrcm Archirccrurc
I . Provide a checklist of issues ro consider when
I 0.3 Client/Server Arcbirecturc
selecting a system architecture
I 0.4 The Impact of the lnrcrnct
2. Trace the evolution of !>ysrem architecrure from I O.S E-Commerce Architecture
mainframes ro current designs Case in Poinr 10.2: Small Poraroc~
3. Explain client/server architecture I 0.6 Processing l\1cthods
4. Describe Lhe impacl of the lnterner on syi.rem I 0. 7 crwork Models
archirecrure I 0.8 Wireless Networks
5. Compare in-house e-commerce dcvclopmenr Case in Point 10.3: Spider IT Services
with packaged solutions and service providers I 0. 9 Sysrems Design Completion
A Question of Ethics
6. Explain online and barch processing I 0. 10 Su mmary
7. Describe network models, including hierarchical, Key Terms
bus, ring, star, and mesh topologies Exercises
8. Explain network devices, including routers, gate-
ways, and proxy servers
9. Describe wireless networking, including wireless
standards, topologies, and trends
IO. Explain rhe final activities in rhe systems design
phase

r..,,...JID)r-..1-.. 4•11_.. • ...__. ~....... .,...~ • ........._ ......_.,.,.. o-... ..,._.,,.,.._..,.~ ,........., ................. .._... ..,.,...,.~"
................... ..., .......................... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ........................._ .... ._
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 sys-
tem 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 a n 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 a nswer ro
that question. The best approach probably would be to srudy day-to-day business
functions, talk ro users at a ll 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 nterpri~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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

318 I 0.1 Architecture Checklist

Many companies are extending internal ERP systems to their suppliers and cus-
tomers, 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 o rder, which in n1m rriggers a call for more parts from one
or more suppliers. In a dynamic, highl)' competitive economy, CM can help compa-
nies achieve faster res ponse, 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 capabili-
ties 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 plan-
ning and analysis was discussed earl ier. TCO includes tangible purchases, fees, a nd
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
o riginal 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 pric-
ing 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

I 0.1 Architecture Checklist 319

• Have any significanr rechnical developments occurred char could affect rhe pro-
posed 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 tech-
nologies 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 compatibil-
ity 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~----···---~~-.,.-"~ ...........
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 c hapter, 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 sys-
tem, such as an order entry system, requires more network, processing, and darn stor-
age 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 c haracteristics 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.rea rs and defenses are a major concern co a systems ana-
lyst. As the physical design is translated into specific hardware and software, the ana-
lyst 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 sys-
tem architectu re and design.
Web-based systems introduce addmonal security
concerns, as critical data muse be protected in che
lnrerner environment. Also, firms that use e-com-
merce applications must assure custo mers rhar
their pen.onal dara is safe and secure. The lamen-
table number of high-profile securiry breaches in
large corporations in recent years suggest~ that
security issues should play an even larger role in
FIGURE I 0 -2 User IDs and passwords are tr:tditional elements of system architecture considerations. System secu-
syscem security. rity concepts a nd strategies are discussed in detail
in Chapter 12.

I 0. 1.9 Corporate Portals


Depending o n 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

I 0.2 The Evo lut ion of System Archite ctu r 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 ou r three mai n functions:


• Ma nage applications tha r perform che processing logic
• Handle dara sroragc a nd access
• Provide ~1n interface rhar allows users ro i1ueract with the system
Depending on the archi recrurc, rhc three functions are performed on a server, on a
clienr, or arc divided berwecn rhc server and che clienr. During system design, rhc ana-
lyst must dererminc where rhe functions will be carried our and ascertain the advan-
rages and disadvanrages of each design approach.

I 0.2. 1 Mainframe Archite cture


A sen er 1s a computer thac supplies dara, p rocessing services, or other support to
one or more compurers, called client>. The earliesr servers were mainframe comput-
ers, and a sy~rem design where che server performs all rhe p rocessing someume~ is
described as mainframe architecture. Alt hough che actual server does nor have robe a
mainframe, the term mainframe architecture typicalJy describes a multiuser environ-
ment where the ~erver is significanrly more powerful than the client). A sy~tem) :ina-
lysr should know the history of mainfrrune architecrure ro understand the :.erver's role
in modern system design.
In the I 960:., mai nfra me architecture was che 011/y choice. In addition to central-
ized data processing, the earl iest systems performed all data input and outpur at a
centra l locat ion, often called a data processing center. Physical dara was delivered or
tra nsmitted in some manner ro the data processirng center, where it was enrered into
rhe sysrem. Users in the o rga nization had no input or o utput capa biliry, except for
pri nted reporrs rhat were d istri b uted by a corpora te IT depa rtment.
As nerwork technology adva nced, compa nies inst alled terminals a t remote loca-
tions, so t ha t use rs could c nrer a nd access da ta from a nyw he re in the organization,
regardless of where rhe ccnr ralized computer was locared. A terminal included a
keyboard and display screen co handle in put a nd o utput but lacked independenr pro-
cessing capabi liry. In a cenrralized design, as shown in Figure 10-3, rhe remote user's
keystrokes arc cransmirred from his or her renninal to the mai nframe, 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 I0.2 The Evolution of System Architecture

Today, mainframe architecntre still is used in indusrrie~


that require large amounts of processing that can be done
at a centra l location. For example, a bank might use main-
frame servers to update customer balances each night. In a
blend of old and new technology, man y organi1arions arc
Mainframe moving s ome of thei r dara processmg off their mainframes
and into the cloud. Indeed, a mainframe can be used ro
implement part of a cloud co mpunng infrastruccure.

I0.2.2 Impact of the Personal Computer


FIGURE I O·l In a centralized design. the remote user's
keystrokes are transmitted to the mainframe, which When PC tecl1nology exploded in the 1990s, powerful
responds by sending screen output back to the user's microcomputers quickly appeared on corporate desktops.
screen. 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 a llowed 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 ra ised major CODCerns about data security, inregrity,
and consistency. Without a central srorage location, it was impossible to protect and
back up valuable business data, a nd companies were exposed ro enormous risks. In
some cases, users who were frustrated by a lack
Pnnter Scanner 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

····-
LAN
resolved the problems of stand-alone computing
by joining clients into a local area ncl\\Ork
Client (LAN) that allows haring of data and hardware

I 'Q
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
AllUllil Client
Client the Internet to share data.
A wide area network (WAN) spans long
FIGURE I 0-4 A LAN allows sharing of data and hardware, such as
printers and scanners.
distances and can connect LANs rhat are con-
tinents 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 t heir 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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
Q Client

Server 1tan&mits onto/ the


'9$uftS Of lhe client query 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 main-
frame systems. M any 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 AUdata 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. Servicc-
oriented architecture (SOA) is an example of a networked system where a service can be a
client and a server simulta neously, 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 u ltimate form of client/server architecture, where Internet-based computing
becomes the server part of client/server and hand les processing rasks, while che T1ner-
net itself becomes the platform that r eplaces 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 a nd the server. A fat client, also called a chick client, design locates all or

(....,..... J:gi ( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,...... .,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~ c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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 a re 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 da ta 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 ~inc~~ logic, required
by che system. Three-tier design~ also are called 1r-rier design~ . 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 I0.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 a re 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
x x
x --
Central server with Server
remote terminals Client

Sland·alone Sel'ller 1
client x x x
l\.vo·tier
Client
Sel'ller x x ---,
cllenVserver Client x x I

Three-tier
Data server x I
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 C ost-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 rapidl y changing environment.
As the size of t he business changes, it is easier to adjust the number of clients and
the processing functions they perform than it is to a lter 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 heavy-
weight 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 informa-
tion about total sales figures. In a client/server system, che server locates the data, per-
forms 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.

I0.3.S Performance Issues


\Xlhile it provides many ad\'ancages, client/server architecture does involve perfor-
mance 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 cur-
rent and furure business needs.
To enhance performance, client/server systems musr be designed so the client con-
tacts 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 process-
ing 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 scal-
able, 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 vari-
ous locations. In addition, the architecture of a DDBMS is more complex a nd 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 funda-
mentally different environment for system development.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

328 I 0.4 The Impact of the Internet

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 respon-
sib1liry 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


C loud com puring refers to tbe cloud sy1ubol that often is used ro represent the Inter-
net. The cloud computing concept envisions a cloud of remote computers rhar pro-
vide 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 work ing 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.
Cloud computing effectively
eliminates comparibilit)' issues,
because the Internet itself is the
platform. This architecture also

c
,/\ Web server
provides scaling on demand,
which marches resources to
needs at any given time. For
example, during peak loads,

D I additional cloud servers mighr


come online auromarically ro
support rhe workload.

8 8 Cloud com puring is an ideal


platform for powerful Software
as a Service (SaaS) applications.
As described in Chapter 7,
FIGURE I 0-10 Cloud computing. SaaS is a popular deployment

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 a rchitecn1re, 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, desir-
able, 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 cor-
nerstone of enterprise system a rchitecture and will continue to be for the foreseeab le
future.

I 0.4.l W eb 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 dynam-
ical!)'· 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 explo-
sive 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 busi-
ness solutions must be efficient, reliable, and cost-effective. When planning an e-com-
merce architecture, analysts can examine in-house development, packaged solutions,
and service providers. The following sections discuss these options.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

330 I 0 .5 E-Com me r c e A rch itectu re

I O.S. I In-H ouse Solutions


Chaprer 7 descri bed how to analyze adva ntages and disadvantages of in-house de\'cl-
opmenr 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 st rategies. An in-house solution usually requi res a
greater mirial invest ment but provides more fl exibility for a company tha t must ada pr
quickl)• in a dyna mic e-commerce en\'iron ment. By working m-house, a company
has more freedom to inregrarc wit h c usromers a nd suppliers and is less dependent o n
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 s ma ller companies, the decision about in-house web development is even mo re
critical, because this approach will require fina ncial resources a nd management atten-
tio n tha t many small companies might be unable or unwilling to commi t. An in-house
strategy, ho weve r, can pro vide valua ble benefits, including the fo llowing:
• A unique website, with a look and feel consistenr with the compa ny's orher
ma rketing effo rts
• Complete control over the orga nization o f the site, the num ber of pages, a nd
the size of the fil es
• A scala ble structure to handle increases in sales a nd producr offerings in rhe
fu ru re
• More flex ibi lity to modify a nd manage the site as the company changes
• T he opp<irrun iry to integrate rbe fi rm's web-based business systems with its
o ther informa rion systems, c reating rhe po tential for more savings a nd berrer
customer service

(....,..... J:gi ( . . . . . I_,.. 41 11.,.. ~- )U, Woip-M ._..,.. - ·~•-fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. - ~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,...... .,..~ __.~~ 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 host-
ing 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 a lternative 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 s ubscription fee. Today, many ASPs offer full-scale lntcrnet business services
for companies char decide to outsource rhose functions.
A sysrcms analys r 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 I0.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 supply-
ing home gardeners with the finest seeds and gardening supplies. Until now, the finn has done all
i ts 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 wou ld be better to outsource the site and
focus on the business itself. Suppose t he family asked for your opinion. What would you
say? What addit ional 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 ai rline'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 reserva-
tion, enter a name, address, credit card informa tion, 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
s hows what happens when a customer uses an ATM to inqu ire 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 ATM QUERY PROCESS


characteristics:
Step 1: Customer enters his or
1. The system processes transacrions com- her account number and
requests an account
pletely when and where they occur. balance
2. Users interact direct!) with the informa-
aon !>ystem. J_§~j
E J :::::::::::31
E
3. Users can access data randomly.
4. The information system must be available
whenever neces~ary to support business
St ep 2: Retrieves current
functions. ONLINE account balance
PROCESSING
St ep 3: Verifies bank account
SYSTEM
number and displays
I 0.6.2 Batch Processing balance on ATM screen

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 infor- CUSTOMER
mation to operate, and batch processing is not FILE

always desirable. However, batch methods can


be efficient and convenient in some siruations.
FIGURE I 0 - 13 When a customer requests a balance. the ATM
For example, batch processing can be used system verifies the account number. submits the query. retrieves the
for large amounts of daca rhat must be pro- current balance, and displays the balance on the ATM screen.
cessed on a routine schedule, such as weekly
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 t raffic, 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, migh t 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 a nd accou nring entries are performed in a batch. A company
would choose a mix of onlinc and batch processi111g when it makes good business
sense. Consider t he 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 I0.7 Netwo rk 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) PROCESS ING

Daily Sales Daily


POS
Terminal -4 - ...
POS
Program
Sales
Transaction Program _ .,. Sales
(Online) File (Batch) Report

t t
Accounllng
Inventory 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 vulnera-
ble 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 wire-
less networks, which arc covered in rhis secrion. Other imporranc issues, such as ncc-
work 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, mid-
dlcwarc, 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 Ne tworkTopology
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 busi-
ness enterprise compared wi th a sma ll LAN in a single department. These four com-
mon 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 con-
trol lower levels of processing and network devices. An example of a hierarchical net-
work 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 opera-
tions. 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 I0.7 N etwork Models

One disad,·antage of a hierarchical network is that if


PC
a business adds additional processing levels, the net-

g work becomes more complex and expensive ro oper-


ate and maintain. Hierarchical networks were often
- used in traditional mainframe-ba<;ed S)'Stems but are

g
less common today.

BUS NETWORK: In a bu~ net\\ Ork, as shown m


PC Figure 10-16 , a single communication path connects
cbe central server, departmental servers, workstations,

~B>--~~-- ~
and peripheral devices. [nformation is transmirted
in either direction between networked devices, and
all messages travel over the same central bus. Bus
Termnals U PC networks require less cabling than ocher topologies,
s because only a single cable is used. Devices can also be

Q --- attached or detached from the network at any point


without disturbing the rest of the network. Jn addirion,
PC Ci} Ci} Te1mina1s a fa ilure in one workstation on the network does nor
necessaril y affect other workstations on the network.
O ne major disadvan tage 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
FIGURE I 0-1 6 A bus network with all the devices treelike srruccure of a hierarchical nerwork or the hub-
connected to a single communication path. and-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.

PC
g PC
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
Oepartmon1a11etver in only one direction from one device to the nexr. In
function, a ring network can be thought of as a bus
FIGURE I 0 - 17 A ring network with a set of computers that network with rhe ends connected. One di~advanrnge
sends and receives data flowing In one d1rect1on.
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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 3 Systems Design

I 0.7 Network Models 337

STAR NETWORK: Because of its speed and versa-


tility, the star network i a popular LAN topology.
A ~tar network has a central networking device
called a switch, which manages the network and
Oepartmenllll
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 perfor-
mance. 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 broad-
casts network traffic, called data frames, to all ~nner

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 FIGURE I 0-18 A star network with a switch, departmental server,
and connected computers and devices.
all traffic flows into and our of the switch. An inher-
ent disadvanragc of the srar design is rhar rhe entire
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 Switch


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
Ci:
~.m~ I I ~M•
communication problems arise or some nodes
become inoperable. .,... ~
• 4-------~
Pnnter •
I 0. 7 .3 Network D evices PC

Nerworks such as LANs or W'ANs can be intercon- FIGURE I 0- 19 A mesh network is used In situations where a
nected using devices called rourers. A router is a high degree of redundancy is needed. such as military applications.
device thar connects network segmen rs, determines The redundant design provides alternate data paths but is
expensive to Install and maintain.
the most efficienr data path, and guides the flow of
data.
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 connec-
tivit}' for internal LAN users. The vast majoriry of business nerworks use routers to
integrate che overall network archirecmre.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

338 I0.8 Wireless Ne tworks

Departmental
server

1i1,~ I ~ Router

1i1 ~ ,,_ ~
~ "'~'
Internet
Proxy server

1i1 /
0 PC
Q PC
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 substan-
tial, a~ well as the inevirnble wiring changes char occur in a dynamic o rganization.
~!any companies find wi reless technology co be an arrracrive alternative. A " irele~~
local area ncrn ork (\VLAN) is relatively inexpen~ive co install and is well suited co
wo rkgroups 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 ropol-
ogie~, which are discussed in the following seccions.

I0.8. 1 Standards
Wireless networks a re 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 origina l 802. 11 standard.
Severa l versions, or amendments, were intended to improve bandwidth, range, a nd
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 wire-
less nerworks. Wireless network speed is measured in megabi ts per second (M bps) or
gigabits per second (Gbps).
For example, when the 80 2.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 band-
width 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:-..•~-".....-""'*"....,.._...,.. ..
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 inp ut/multiple
o utpu t (MIMO ) technology to boost performance. MIMO relies on mulciple data
paths, also called mul tipath 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 dis-
cussed 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 commu-
nications medium, the a ir, 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 net-
work, 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 ser vice.

I 0.8.3 Trends
\Vireless cechnolog y has broughr explosive change co the IT industry and will con-
cinue 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 wire-
less 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 inter-
ference 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- .............. . ,.. o-....._ ...... _ ... ,..,...,...,~..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

340 I0.8 W ireless Networks

..
i:J ..._

-
·---

-~ .............
··~- ~ --· - :. - -

....
n

...

• -

...
n -
~·> - (Cc~

FIGURE I 0-2 1 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 IDER IT SER\'ICLS 1

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>_... ........ _ .. ~ ........................._ .... ._
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 doc-
umented 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 pro-
vide 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 speci-
fication, obtaining ui.er approval, a nd delivering a presentation to mnnagement.

I0.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 sys-
tem will be measured. Unlike the system requirements document, which is wrirten for
users to unde rstand, the system design specification is oriented toward the program-
mers 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 pro-
cess descriprions, data dicrionar)• enrries, and data flow diagrams.
The system design specificarion varies in lengrh, so it should be organized care-
fully. 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 fol-
lowing 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 all 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, hard-
ware, systems sofrware, or security. Examples of operational consrramts include

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter I 0 System Architecture

342 I0.9 Systems Design Completion

transaction volumes thar muse be supported, data storage requirements, pro-


cessing 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 sho uld meet with users to
review the protorype, adjus t 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 o r software issues
for which they need to prepare. As a lways, a systems analyst must be a good com-
municator 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 enoug h
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 opera-
tional support for the system. Because of the audience, the presenration is rechnicall>•
oriented.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 inreracrio n 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 presenra-
non , 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 termina te 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 both-
ered 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 rdwa re, 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 web-
centric 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
suppl y 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 sys-
tems 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 inter-
face, 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:-..•~-".....-""'*"....,.._...,.. ..
Phase l Systems Design

I 0.10 Summary 345

The Internet has had an enormous impact on system architecture. In implement-


ing 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 Inter-
net 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::im-
ically. 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 sys-
tems process transactions in groups and execute them on a predetermined schedule.
Many online systems also use batch processing co perform routine tasks, such as han-
dling 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 typ-
ically 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 worksta-
tions 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 popu-
lar, they do have some limitations and disad\•antages, includ111g interference and secu-
nry concern~.
The system design specification presenrs the complete systems design for an infor-
mation ~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 devel-
opment phase, requires additional systems design work, or is terminated.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~ - .,.-"~ ...........
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 l ac 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 hand les 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 architectu re 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 t he clients.
corporate ponal A website rhat provides V•triou; tools and fe.itures for .Lil orgnnitauon's customers,
employees, ~upplicrs, .tnd the public.
d.ita frame~ rrJff1c 011 a compurer network.
dara procC\\ing center A ccnrra l 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Phase l Systems Design

Key Terms 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 commu-
nicatton 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 sran-
dard, 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; print-
ers .111d ;•anner;,. Advan,es 1n dJt:t commumcanon 1eclmology ba\e made ar po;;1ble to create power-
ful 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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. 11n and 802.1 lac \tandard' that u>e' multiple data \trcam\ and multiple antenna' ro achieve
higher tran,mi"ion 'peed~ and substantially increase wirelc~> range over earlier <iandard,.
nct ·ccnnic computing A di~rributcd environment where appl ication' and data arc down load~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 al lo\\., 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 e nvironment.
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) cha nging 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·
ca lly 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Phase l Systems Design

Key Terms 349

stand-~lonc When personal computers first appeared large numbers ID the 1990, users found that rhey
ID
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'>, mfor-
mation, 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,c1H~ 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.
thr~e-tier d•~igo 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.
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 Ia, 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 rol e do sra ndards 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 full-
fledged 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 presenta-
tion, 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?

P rojects
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 solu-
tions, 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. Wh y are some pl::ices bypass-
ing LANs and physical cabling altogether and moving ro a wireless S)'Stem archirecrure? What are the
advantages and di sadvantages 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 and existing data must be converted. After the new
of the SDLC. Managing systems Implementation involves system is operational. a formal evaluation of the results
paying constant attention to quality assurance throughout takes place as part of a final report to management.
the activities of application development. coding, testing, The chapter includes three "Case In Point"
documentation, and installation. The system design discussion questions to help contextualize the concepts
specification serves as a blueprint for constructing the described in the text. The "Question of Ethics"
new system. The initial task Is application development. concerns with an issue that all testers have to deal:
which requires systems analysts and programmers to when to stop testing. In the example, there is an ethical
work together to construct the necessary programs and question raised about whether or not a 90% pass rate
code modules. Before a changeover, the system must be is sufficient to ship the product, assuming the remaining
tested and documented carefully. users must be trained, bugs will be fixed once the system Is operational.

c T
Whe11 you fi11ish this d1apter, you sho11 /d be able I I. I Qualiry Assurance
to: I 1.2 Application Developmcnr
I 1.3 Structured Development
1. Explain quality assurnnce and three techniques
I 1.4 Objecr-Orienred Development
co help improve Lhe finished product
I 1.5 Agile Development
2. Ourline application developmenc I 1.6 Coding
3. Appl)' structured development I 1.7 Testing
4. Apply object-oriented development Case in Point 11.1: Your Move, Inc.
5. Apply agile development 11.8 Documentation
11.9 lnsralla ti on
6. Explain coding
Case in Poinr I 1.2: Globa 1 Cooling
7. Explain unir, integration, and system resting Case in Po inr 11 .3: Yorktown lndusrries
8. Diffcrenti:ue between program, system, opera- A Question of Ethics
tions, and u&er documentation 11.10 Summary
9. Explain the role of online documentation Key Terms
Exercises
I 0. Describe rhe five tasks involved in sysrem
installation

r..,,...JID)r-..1-.. 4• 11_.. • ...__. ~... . ... .,...~ • ........._ . ....._.,.,.. o-... ..,._.,,.,.. _ ..,.~ ,........., .... ............. .._... .., .,...,. ~"
................... ..., .................... . . .... -..,.n..-.....-ik-sc~ c....,a..-.,.,....,. ..... 111>_... ........ _ .. ~ ... . ....................._ .... ._
if' uuo 4 y.st:o1ns; rnp1o:n

I 1.1 Qualicy Assurance 353

f f 1 ll I ITV -.
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 possi-
ble. 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 engineeri ng 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 esti-
mation, 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 lcss-
expensive methods of software development. To achieve thar goal, SEI designed an
influential ser of software development standards called tbe Capabilit) M aturit y
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 SETcsrablished a new model, called Capability Ma turiry
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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 Level 5


strategies defined and used Op11m1z1ng
Quality management
Level4
strategies defined and used
Managed

Level 3 Process management


Defined procedures defined and used

Level2 Product management


Repeatable procedures dellned and used

Level 1
Essentially uncontrolled
Initial

FIGURE 11· 2 The C MM 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:-..•~-".....-""'*"....,.._...,.. ..
if' uuo 4 y.st:o1ns; rnp1o:n

I 1. 1 Qualicy Assurance 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

F IGURE 11-3 INCOSE's view of systems engineering.


So1.lrceJINC°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 services-
including software.
p
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 qua lity
standards. In 2014, ISO updated a set of guideljnes, called
ISO 9000· 3:2014, that provided a QA framework for
developing and mainraining software. ''
r
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
+
F IGURE 11-4 ISO symbols include lntemationally
recogni:ted symbols.
documented and tncluded in the test records.

.........""_.. ... .-................. _..__


("..,_...,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 developm ent 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 man-
age. 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 import-
ant to set realistic schedules, meet project deadlines, control costs, and maintain qual-
ity. 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 functiona l
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 dia-
grams (DFDs). The development of process descriptions for functional primi-
tive 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 sys-
tem 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 develop-
ment 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, design-
ing, 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 struc-
ture 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 sys-
tem logic into properly functioning program modules. These generic tools include
ERDs, flowchnrrs, pseudocode, decision table , and decision trees.

Test
.scenarios

New user S1ory

New Customer
r:::=-1 Preparation Release version Acceptance approval r:==1
·~
~ planning .. 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 plai n 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 informa tion
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 ru les 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
if' uuo 4 y.st:o1ns; rnp1o:n
I 1.3 St ructure d 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
Award a $25 bonus coupon
ELSE
Award a $5 bonus coupon

FIGURE 11 ·7 Sample of a sales promotion policy with logical rules (top) and a pse udocode version o f the
same policy (bottom). Note the alignment and indentation of the logic statements in the pseudocode.

Used our
y
--- 5% discount and
an addltlonal 5%
charge card? discount
Ordered
more than
y $1,000?
5% discount
N
Preferred
customer?
"'-~~~~~~~~~~~- S25bonuscoupon
N

SS bonus coupon
N
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 usua ll y invol ves a top-down approach, which


proceeds from a genera l design ro a dera iled structure. After a systems analyst docu·
men ts the system's require ments, he or she breaks the system down into subsystems
and modu les in a process called partitioning. T his approach a lso is called modular
design and is s imilar co constructing a leveled set of DFDs. By assign ing modu les 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 modu le, 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 capa-
bilit} 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 r hac represenc rhe program modules, wich ar rows
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 tha t 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 Mainta in Customer Daca module.

Module I M aintain Customer Data

Library
IIModde 1.311} 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.r t 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 s ignal a specific condition or action ro another module.

Maintain Customer Data

Control
Couple

Check Update
Customer Status Customer File

FIGURE 11 - 11 An example of a Strucrure chan control couple

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 mod-
ules 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 IProduce 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 mod-
ule 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 C ustomer Credit Limit,
cohesion is greatly improved.

More
Cohesive

Check Customer Less


Cohesive Check Customer Check Customer
Number and
Number Credit limit
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 rightl y 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 Upda te 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 t he 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 ana lysis method was used du ring system design, the structure charts
will be based on t he DFDs created du ring 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 struct ure chart is analyzed to ensure chat it is con-;isrenr wirh the sys-
tem documentation.

(....,..... 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 363

Update Customer Update Customer


Balance Balance

~
..
t? ~~1
f5
-
.8
E 8
-..
I ] ::>
!
()
ff
~
z
j.,,
zl
a §- ~
-
.8
R ::>
()
0
Loonly
Coupled

i1
l .- ' z
E
::>

~ I
'l
.s
~
~
j
i
z
z ~ .$
'lJ"'
~
;:;
Tl ghUy
()
8
..
.,
Coupled

rJ !;
~ ili
Ji!
0 I
,j
z

Calculate Current Apply Calculate Current


Charges Discount 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 incer-
action among the objeccs is fully undersrood.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ --......
...........
364 I 1.4 Object-Orie nted Development

Order System
ModuleO

Relalea to context
diagram

Fill Order Create Invoice Apply Payment


Module 1 Module2 Module 3

Relates to diagram
ODFD

Relalea to diagram
1 DFD

Prepare Reject
VenfyOrder Assemble Order
Nolice
Module 1.1 Modu:e 1.3
Module 1.2

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 pre-
vious 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 we re 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 diffe rences.

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, Woip-M ._..,.. - ·~• -fllllie<'f •,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~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 herwee n 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 Allnbutes
Number Number
Customer Description
Date o.. • Includes 1 ~.•
Price
.. ...
Methods Methods
Verify credil stalus Change stock level
Verify Item status Change min-max
Apply discount 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 busi-
ness functions and transactions.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
366 I 1.4 Object-Orie nted Development

EMPLOYEE

ts a

MANAGER OFFICE STAFF INSTRUCTOR

Determines

A TNESS·CLASS
SCHEDULE Takos
rostor

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. H owever, 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 care-
fullr analyze, design, implement, cesc, and documen t rheir 0-0 projccrs.

I 1.4.2 Imple m e ntation of Obje ct-Orie nte d 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 mod-
ule. To accomplish the task, rhe programmer ana lyzes 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 Obje ct-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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 disti nctly 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 custo mer, 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 r4 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 a lso use various 0-0 languages such as Java, C++, C#, and others.
As with traditional methodologies, agile developmen t 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. C ritics 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
368 I I .S Agile Development

Before implementing agile development, the proposed system and development


methods s ho uld be examined carefully. As experienced IT professionals know, a
one-si1c-firs-all solutio n does nor exist. For more information on agile method , refer
to the discussion of systems development methods in C hapter I and agile methods
such as Scrum in C hapter 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. Courage: We will tell the tJUth about
progress and estimates. We don't document
Communication: Everyone is part of the excuses for failure because we plan to
team and we communicate face lo face daily. succeed. We don't fear anything because no
We will work together on everything from one ever works alone. We will adapt to
requirements to code. We will create the best changes when ever they happen.
solution 10 our problem that we can together.
FIGURE I 1-20 The five core values of XP.

XP uses a concept called pair programming. In pair programming, rw o


programmers work on the same task on the same computer; one drives (programs)
while the ocher navigates (watches). The onlooker examines the code stra tegically 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 develo pment (T DD) focuses on end results from the begin-
ning and prevenrs programmers from straying from their goals. Because of rhc magni-
t ude and intensity of the multicycle process, agile testing relies heavilr on automared
resting methods.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 0111 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 sto-
ries, 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 pro-
totype releases as they become available. This process usuall y 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 individ-
ual 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 srandard~ 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 contin-
ues, HTM UX M 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 addi tion ro these commercial packages, programmers can use open-
source ID Es such as Ecl ipse.
Earlie r chapters explained rhar systems analysts use application generators, report
writers, screen generarors, fourth-generation languages, and other CASE tools that
produce code directl y from program design specifications. Some commercial applica-
tions can generate edirable program code directly from macros, keysrrokes, o r mo use
actions. For example, IBM's RationaJ toolser can generate code fragmenrs based o n
UML design documents. T his can help with QA.

After coding, a programmer must rest each program co make sure it functions cor-
rectly. 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 pro-
grammers nnd analysts who did not wo rk on the project. The objective is ro have a
peer group identify errors, a pply 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
sectio n of people who will work wi th the new system and ensure that all necessary
features have been included. T his is a continuation of the modeling a nd prototyping
effort that began early in the systems development process.
The next step Ln application devel opment is co initiate a sequence of unit testing,
integration resting, a nd system testing, as shown in Figure 11-2 1.

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 integrabon test

Unit Test
Program 2
-
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 a nd 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 will 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 sho uld 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 a rc adequate (the derails of creating this sort of documentation are dis-
cussed later in this chapter)
• Demonstrate that users can interact with the system succe!>sfully
• Verify tha t all system components are integrated properly and rhar actual pro-
cessing 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 o t her 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 cor-
rected 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 o r no t to install! t he system after a fu ll discussio n
of the options.

You work at You r 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 a n info rmation system and helps t he users, managers, and
IT staff who must interact with it. Accurate documenta tion can reduce system down-
time, cut costs, and speed up maintena nce tasks. Figure 11-22 shows an example of
the Rigi research environment tha t can auto mate the documenta tion process and help
software devel oper~ generate accurate, comprehensive reference ma terial through
derailed source code analysis.
Documentation is essential for successful syste m operation and maintenance. In
addition co supporting a system's users, accurate .documentation is essential fo r IT
staff members who must modify t he system, add a new feature, or perform main-
tenance. Documentation includes program documenta tion, 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 ABSTRACT
_.......,, Th• Rlp envtronlTlC'llt IJ 1 lllitWt rewth tool di.It P<O'idet lllnaJon•l•tl' to .....,.
liet'ffltd JO IWlwtllbtt lOOt l'fllinttr toltw.,. sy><<nu. Wlth Rill Lorae JYSl..,,t <1n bt1n1lyud. lntm<1t..iy ..plattd,
ltctCcNed lt1 tf\llifd form 15 oet*t 2009 tummorlztd. ind da<umm...S. TblJ IJ 1uppon<d with P•ll•fS to tJClt.a lnfonNdon from
Acttplfd JO Orrullit'r DB 10Urce code• .n f'XCNote fonNt to 5CO~ tJttrac:ltd ln!orm•tion. ~Ml)"Ht ro m.nsform
Av•lllble Df'lw 10 NOYf'mbrf 2009
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
ll)'wiorG:
fonn or cyp<d. dltoct<d. hl<mthlc.l 1roplu. In thl• P<P<f we dr>cnbt Rlal't m.iln
lllrwr4e ~flllntttm&
,....,. _ _•Ion compoaents ..nd funruomlltlo!. ond ,...., Its lmpoct on ..,..,.., .,,p,.,..riO& ,.,.,rdi.
,.... .....1<11. . 1\11tbennot.. wt ditcuu Rlp't Mdllt<a"" ind dttiCn dtdJlont thlt led to • dtcouplln&
Tool requltttlWfttl 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

FI GURE 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 Docume ntation


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 docu-
mentation, 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 externa l comments and descriptions that can be understood and
maintained easily. A systems analyst usually ve rifies that program documentation is
complete and accurate.
System developers a lso use defect tracking softwa re, 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 Docume ntation


System documentation descri hes the system's functions a nd how they arc imple-
mented. System documentation includes dara dictionary entries, DFDs, o bject 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 mainta in 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.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gl( . . . . . -Woip-M ._..,..
..,...,.......,..~ .. __.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
if' uuo 4 y.st:o1ns; rnp1o:n

I 1.8 Documentation 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 pos-
sible. 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 opera-
tions 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 inter-
act 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 parttcularl y rrue in the world of online documentation, which needs
to coordinate with prinr documentation and inrranet and lnternet information. Tech-
nical 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 can-
not be added at rhe end of the project. While this has always been rrue of traditional
user documentation, thi~ i ~ an even more c ritical issue now that online help and con-
text-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 documentatio n, which provides immediate help when
they have questions or encounter problems. Many users are accustomed to con-
text-sensitive help screens, hints and tips, hypertext, on-screen demos, and other user-
friendly 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 devel-
oping 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 devel-
oping the required documentation and support material. In addition, system devel-
opers 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 Inter net-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
........ .,..,. .. ._.,.,.,.......c:-.. • ~-".....-""'*"....,.._...,.. ..
-
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~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) t he 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 a lso be provided. If system resting produced no technical, economical, or
operational problems, ma nagement determines a schedule for system insralhnio n.
T he following syste1n installa tion tasks a re performed for every information sys-
tems project, whether the applicarioll is developed in-house or purchased as a com-
mercial package:
• Prepare a separate operationa l 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 Environme nts


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 opcrnrio nal
en\ iro nmenr or pro duction enviro nment. The environment char analysts and
programmers use ro develop and maintain programs is called rhe tc~t enviro nment.
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 con-
tro lled. Systems analysts and programmers should not have access ro the operational
environ ment except co correct a system problem or to make authorized modific:1rions
or enhancements. Orherwise, IT de partment membe rs have no reason ro access rhe
day-LO-day operorional system.
T he rest environment for an infor mation sysrem contain~ copies of a ll 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 t he 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:-..•~-".....-""'*"....,.._...,.. ..
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 Users
Authorized
Changes

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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 a rise 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 abnormally, and with the
direct cutover method, reverting to the old system as a backup option is not
possible.
Compa nies often choose rbe direct cutover method for implementing commer-
cial software packages because they feel tbat commercial packages involve less risk
of total system failure. Commercial software is certainly not risk-free, but the soft-
ware ve ndo r usually ma intains an extensive knowledge base a nd can supply reliable,
prompt fixes for most problems.
For systems developed in-house, most o rga nizations use direct curover only for
no ncritical situations. Direct cutover might be the only choice, however, if the operat-
ing environmenr cannot support both the o ld and new systems o r if the old and new
sys rem~ arc incomparible.
Timing is ve ry impo rtant when using a direct cutover strategy. Most systems operate
on weekly, monthly, quarterly, a nd 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 semimonth ly. !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
termina ted.
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 a re 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 t he 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 paralle l operation for the entire company. ln addi tion, if
a para llel approach ro complete the implementa tEon is used lacer on, the changeover
period can be much shorter if the system proves s uccessful a r 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 implement-
ing a new manufacturing system all a t once, the materials management subsy~tem
is installed first, then rhe production control subsystem, then the job cost subsys-
tem, 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 opera-
rion 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 pos-
sible, however, if the system cannot be separated easily into logical modules or seg-
ments. 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.
High I

Direct
cutover
,__
-
R
I
Medium
s
K PiIOI Phased
operation operabon
. - -
Parahel
operabon
Low •
low Med1Um High

,______ ____ COST __, >


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 data-
base 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 understand-
ing 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
Gotect origin
Cost-benefi t analyslS
Start·up and shut down Support for business goals
Main menu and submenus Key IT contact people
Icons and shortcut keys Handt ng system charges
Ma)Or system functions Major reports and displays
Onkne and external Help Requesting enhancements
Frequent y asked questions User training
Troubleshooting guide
Hand ing emergencies

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 t he company will provide rraining must be
determined. T he main choices are to obtain training from vendors, outside t raining
firms, or use IT sraff a nd other in-house resources.

VENDOR TRAINING: If t he system includes the purchase of sofrware or ha rdware,


then ve ndo r-su pplied t rai ning is o ne of the fea tu res tha t should be included in the
requests for pro posal (RFP) a nd req uests for quota tion (RFQ) chat are sent to poten-
tia l vendo rs.
Ma ny hard wa re and software vendo rs offer trai ning programs free or at a nom-
ina l cosr fo r the products they sell. [n other cases, t he company mighc negotiate the
price for trai ning, depending o n their rela tio nship with the vendo r and the prospect of
fu ture purchases. T he training usua ll y is conducted at the vendor's sire by experienced
trai ners who provide valua ble hands-on experience. If a large number of people need
training, classes mar be held at the co111pany's location.
Vendo r training often gives t he best return on t raining dolla rs because it is focused
o n products rhar the vendor develop ed. T he scope of vendor training, however,
usually is limited to a standard version of the vendor's software or ha rdware. T he
vendor's training may have robe s upplemented with in-house t raining, especially if
the IT staff customized t he vendor's package.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
- Woip-M ._..,..
..
- ·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,.. ..,. - ~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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 pre recorded 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 multime-
dia 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\'an-
tage 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, out-
side 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 exam-
ple, 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,..,.,.,..,..... ........ .,
..... ....
c.... ...... llCIO.l9_,......,.
...._,...........,
<OWf'Mt.

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.

• . . . . . . . . . . c-.t
Panopto
'°'....... f'O'ldl«.e!O\ lllncuas ~ -
• LM . . . . . . W.."""°' ..,.._ ~ ..

Flexible video recording software for any


presentation.

.......... ~
,.._.~•--••"'1.,.:1
............ ......,_...~ ................
.................. ,...... . . . . . . . . . . . . llll'llla,,.., ! ~.,

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 d ifferent information. Problemi. often a ri~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 o f
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 mate-


rial. 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 bud-
gets 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 forma l 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 pos-
sible 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 simu lation. 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 per-
formed: (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

- - -(5)
o.....i.w Trenscrlpt View Oflllne El<Ofdse Fllft

·-~--ft K-~GI""""' ..,_.., ••1


.._
D\Atto .. _
owv• .._.-.-.. """"'°V Gooll'O •.,_ _ ... J."'•-""Ill'..._.....,""""'

-
au•astiowlOUM~llOC.- •rq;.s.,_.,.._......,.~
TM CW (Orrililfl N ~al N lllnQl.-oe Jyl'W Md 1M09. 11 . . . . . IO I aid,._,_
'ih''
__·-·· -...
wct\•.,...oa•:&::4.,.,•.......... LWf'....,JtoMatlld~n.....,•-...:
"""''° ... ~ ,...... ~ Udant..end ,.,.., "'°"' ...............
-"', -""" ..""""'- 'l&''P.'
..... "·-
.. - '11111--0!L ~-----
..Ol...

FIGURE 11 -31 A sample lesson on learning Python in an onhne tutorial from lynda.corn.
Sout"CS " "f1 • •• ~
-
POST-IMPLEMENTATION EVALUATION: A post-implemencauon evaluarion
assesses rhe overall qua li ty 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 e nd 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 a nd platform performance
• Effectiveness of database implementation
• Performance of the IT team

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_, .,_.,....,. -~---tfta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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.

. ................. oc

--
iili ~._,,_ Cl x
,.._a-'"- ........

" ••
................. ,., • (!)

t!:I
Q POI DOCUMI NI lJBRARY.
~
U..,tv.......... ,...M
,.,,_ ..
"""tit.,....._
, ,~

_
,... _,.,. ._,. .... __ jo.t·
..._..._ ..........
-
ttlf ~,,._ r
,..,......,yow .~

llM•I IDOi II c..-


°"""'
"""'................
mmo
•••
s
I 1 J
''
t

.
~...... o1111.tm111Kiof!

• . -.......-
l l.e«olv.e
I
l
2
2
l
J

s
s
s •
.._
l J
'
___ ,
USll INfUtfACI

..
> 0.l'ffyol._Ntt..... l • s •
~lty ...... _
2 l • > I


I ( ;ne ~-- -
,
2 l •• >
s •
°' mttallf'l
•10 " twnlO\ol
(\lrlJy tttOf
I
I z J
J
• s '
6
lrlPIA tnOr• l • s •
INK>ltMAllON lfCHHOlOG't' STAFF
U toop.,r.11on
·- - - -' , ,
J • 5 •6
" _...ky
t l ~· -
2
I J
•• '
$ 6
I• ~Jnt of Pl()flN ••
•'
2 J $

_
S'i ~IQl\·,.t.Jlt J s
,.._lllG

,".. """"""-
11 ""iOlltWffti!'9
__ , I 2
I
l
J
J



s
5
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

\'(lhc ncvcr possible, people who \·v ere not directly involved in developing the sys-
tem should conduct the post-implementation evaluation. IT sraff and users usually
perform the evalua tion, a lthough some firms use an internal audit group or indepen-
dent 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 documenta-
tion, or by experimenting with the system on their own.
Users a lso 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 o ther hand, if the evaluation is done too soon, the users may not be a ble to
provide sufficient feedback d ue to la.ck of experience with tbe new system. Post-im-
plementatio n 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 ne w system and appreciate its streng ths a nd weak-
nesses. Although many IT professio nals recommend conducting the evaluatio n after
at le3st six mo nths of system o peratio n, pressure to fin ish the project sooner usually
results in a n ea rl ier evaluatio n in o rder to a llo w the IT department to move on co
other tasks.
Idea lly, 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 a no ther system.

FINAL REPORT TO MANAGEMENT: At the e nd 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 a ll systems development costs a nd schedules
• Comparison of actual costs and schedules to the origin3 1estimates
• 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, secu-
rity, 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 implementa-
tion 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 a pp licatio n development, resting,
installatio n, and evalua tion of the new system. During a pplicatio n development,
ana lysts dete rmine the overa ll design stra tegy a nd wo rk with programmers ro
complete design, coding, resting, and docu mentation. QA is essenti:.il dur ing 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 sys-
tem 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 pro-
gram 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 doc umentation.
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 pro-
vide<> 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 operationa l 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 gro up 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 compute ri zed 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:-..•~-".....-""'*"....,.._...,.. ..
if' uuo 4 y.st:o1ns; rnp1o:n

I 1.10 Summary 393

in a forma t 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 respo nsible 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, webi-
nars, 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 shou ld 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 enhance ments that already have been identified, and details the
project coses. The report represents the end of the development effort and the begin-
ning of the new system's operational life.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 pro-
grammers 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 doc-
umemauon, system documencarion, operations documenranon. and user documenta11on.
Oowchar1 A diagram used to describe program logic that represems logic-JJ rules and iutcracuon graph-
ically 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 esta blished 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 under-
stand 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 r he 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 mu ltimedia 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 overa ll qualiry o f the information •}Stem. The
cva lunrion vcrific~ that t he new system meet;; 'pccificd rcc1uircmcnr,, compl ic• 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 t o 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 docu-
mcnra11on, and ineffecrive ce~ring. A QA ceam reviews and res~ a ll .1pphcat10n~ and ')'rem' chanse'>
co vcrof) >pccifi~ation' and ;,oftware qua lity 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 proce-
dures, 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, occu-
rnrc docu mcnr.trion, and careful testing.
\l.ttu1 Oa11 In >trucrured opplicnrion development, an indicator thac nllows one modu le 10 send a mes·
>.lgc IO .rnothcr modu le.
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. Gen-
erally, \ysrcms ona lyi.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 through-
out 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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 process-
ing sirnat1ons. During a system rest, u~crs cnrcr dara, inch1ding samples of acrnal or live darn, perform
queries, and produce reports to simu late 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 :1 nd 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 manual ~, 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\J1l-
able 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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, yo u 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 main concerns: user expectations, system performance,
wks that continue throughout the useful life of the and security requirements.
system. The systems support and security phase begins The chapter includes three "Case In Point"
when a system becomes operational and continues until discussion questions to help contextualize the concepts
the system reaches the end of its useful life. Throughout described in the text. There are cwo "Question of
the development process, the objective has been to Ethics" scenarios in this chapter. The first scenario
create an Information system that is efficient, easy to concerns known security vulnerabilities In a system and
use, and affordable. After delivering the system, the what should be done about them. The second scenario
IT team focuses on support and maintenance tasks. is about divulging personal information, social media, and
Managing systems support and security involves three free speech.

LEARNING OB ECT VES CONTENTS


W/Je11 you fi11is/J this d1apter, you s/Jould be able I 2. 1 User Support
to: I 2.2 ~1aintenance Tasks
Case in Poinc 12. I: Oucback Outsourcing, Inc.
I . Describe u!ter supporc acr1viries
12.3 ~1aintcnance Managemenr
2. Define the four rypcs of maincenance 12.4 System Performance Managcmenr
3. Explain seven strategies and cechniques for 12.5 System Security
maintenance managemenr I 2.6 Security Levels
4. Describe techniques for system performance Case in Point 12.2: Outer Banks Counry
management Case in Point 12.3: Chain Link Consulcing, Inc.
5. Explain l>yscem security concepts and common 12.7 Backup and Recovery
attacks against rhc system 12.8 System Retirement
12.9 Future Challenges and Opporrunitics
6. Explain three tasks related ro risk management A Question of Ethics
conceprs
I 2. 10 Su111mary
7. Assess syscern security at six levels: physical Key Terms
securit>', nerwork security, application security, Exercises
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

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 informa-
tion systems. If significant changes rake place in the existing system or if a new ver-
sion 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
specia l website, n revision to the user guide, a trai ning 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 depart-
ments. 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 ~oftware , which
allows IT staff ro ta ke over a user's workstation and provide support and trouble-
shooting. 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 scan-
ners, printers, netwo rk 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 GoToM y PC Remot e Desktop Software


No matter where you are or what you nttd to do. remote access benefits both you and your business.

~~\\\\\\llllUIQ~~ ~~\\\\IUU/11.1,,
:s

or
~
IS ~
~ ~
"-
~ 0 0 fl:!
~ ~
N '
'11111 11\\\ •

Reduce Your Commute Connect While Traveling Be Home More


Avood ttwdodv u&lhc~ m •nd.,,... ,_..,., No rnore wpor>tlon """ielV - .......,comp..ter it "'"''" tho. Pf"-"' Mn ond Mt-b VoU , _
~by wort<~ from homeduroncnJV\.,.,... ....,"VI• coupleU1>uwov. Just IQ&., from IOdovau< job. ond be'- In Ii""' !..-d...,,.,
MM>thet computer or mcboledeYi<At.

FIGU RE 12- 1 Remote access software, such as GoToMyPC 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 LLnk 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 knowl-
edge 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:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.2 Maintenance Tasks 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 eco-
nomic life of a system. Figure 12-2 shows a typical pattern of operational and main-
tenance 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 rep-
resents 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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

404 12.2 Maintenance Tasks

12.2. 1 Types of Maintenance


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
Examples of Maintenance Tasks enhancements, perfective maintenance improves efficiency,
and preventive maintenance reduces the possibility
of future system failure. Some analysts use the term
Corrective Maintenance mai11tena11ce to describe only correcti'e maintenance
Diagnose end foe logoe errora
~ de19d1119 ..iwont calllong that fixes problems. It is helpful, however, to view the
Restore p<oper conllgure1ion aeaingt mainteoancc concept more broadly and identify the
Debug P<OQfllfO ooOt
Update clnvers
different types of tasks.
Uti ize remote control aoftwate tor problem cflagnosls and resotuuon Maintenance expenses usually a rc high when a
system is implemented because problems must be
Adaptive Maintenance
Add Online capabiltty detected, investigated, and resolved by corrective
Add support tor mobda devlCM maintenance. Once the system becomes stable, costs
Add new data ontry Held 10 109u1 screen
Install links 10 wobslta
usuall y r emain low and involve minor adaptive
Create employee portsl maintenance. Eventually, both adaptive a nd perfective
maintenance activities increase in a dynamic business
Perfective Maintenance
Upgrade or replace ouldalo<I hardware environment.
Wnle macros to hllndle rope111o11e tasks Near rhe end of a system's useful life, adaptive and
Compress syslem filea corrective maintenance exp enses increase rapidly, bur
Opumize user desklOp Mllllngs
Upgrade w1raless network capablllty perfective maintena nce typically decreases when ir
Install m0ta povterlul network tetVer becomes clear that the company plans ro replace the
Preventive Maintenance system. Figure 12-4 shows rhc typical pancrns for each
Install new anWltUS toftwaro of the four classifications of maintenance acriviries over a
OevelOp standard bed<up ecl>edllfe. oncludong o"·a.te system's ]ife span.
and do<ld-basecl stral9glea
lmplemeol reg.-.ir Clefragmenia1 en pioceu
Analyze J)<Olllom t9pot1 lot i-..r,,.
TVilen •• ~ connecltOnS 12.2.2 C orrective Maintenance
Oe\191op . - g.- ccwnng conliden1.alcy rulM and
unaul>orm1d use of company IT r - . .
Corrective maintenance diagnoses and corrccr errors in
an operational system. To avoid introducing new prob-
FIGURE 12-3 Co~rove maintenance fixes errors and
problems. Adaptive maintenance provides enhancemcnu
lems, all maintenance work requires careful analysis
to a system. Perfective maintenance improves a system's before making changes. The best maintenance approach
efficiency. reliabihty. or maintainability. Prevcnuve is a scaled-down version of the SDLC itself, where investi-
maintenance avoids future problems. gation, 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 main-
tenance work that could affect the system must be performed first in the rest environ-
ment and then migrated to the operational system.
IT support staff respond to errors. in various ways, depending on the nam re 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 app roved, the rnaintenance tean1 designs, tests, documents, and implements
a solution.
As stared in Chap ter 2, many organizations use a standard online form for systems
requests. Jn s maller 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.

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi ( . . . . . -Woip-M ._..,..
..,...,...... .,..~ ..
__.~~ c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....- ""'*" ....,.._...,.. ..
Phase 5 Systems Support and Security

12.2 Maintenance Tasks 405

Immediately Earty Middle Later


After Operallonal OperatlOl'lal Operational
lmplementatlon Lrle Life Life

Correcnve
Maintenance High Low Low Htgh

AdaplMI
Maintenance
None Medium Mecium
(Minor
Enhancements)
Adaphve
Maintenance
None None Medium to High Medium to High
(Ma1or
Enhancements)

Perfective Low Low to Medium Medium Low


Maintenance

Preventive
Low Medium Medium Low
Maintenance

FIGURE 12-4 Information systems maintenance costs depend on the type o f maintenance and the age
of the system.

The wor~r-case siruarion is a sysrem failu re. If an emergencr occurs, rhe main re·
nance ream bypa ses the initial steps a nd cries to correct rhe problem immediately.
This often requires a parch, which is a specially 'vrin en sofrware module chat pro-
vides temporary repm rs 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 deter-
mines 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 ran king
method can be helpful. For example, Figure 12-5 shows a three-level framework for
IT supporc potential impact.

PRIORITY IMPACT

Level I Significant im paa on IT operations, Implement patch as soon


secur ity. or business activity that r equires as possible.
Immediate attention.

Level 2 Some impact on IT operations, security, Patch as necessary and


or business activity. Requires prompt begin Implementation
attention, but operations can continue. prior to next release.

Levell Little or no impact on current IT Implement in the next


operations, security, or business activity release.

FIGURE 12-5 This three-level ranking framework for IT support considers potential impact and response
urgency.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"-> - "'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,..., ~ ..,._.. ........... ... ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 te-
nance arc ali ke, adaprivc maintenance requires more IT department resources than
mino r correcti ve maintenance.
A major adaptive maintenance project is like a s mall-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 perfor-
mance. \'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 highligh red, 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 resou rces often consider new systems development, adaptive
maintenance, ::t nd correcti vc maintenance more important than perfective maintenance.
Managers and users constantl y request new projects, so few resources arc available for
perfective maintenance work. As a practical matter, perfective maintenance can be per-
formed ::ts part o f 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 maintena nce usually is cost-effective during rbe middle of the system's
operationa l life. Early in systems operation, perfective maintena nce usuall y is nor
needed. Later, perfective maintenance might be necessary b ur ha ve a high cosr. Perfec-
tive 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 requi res analysis of areas where trouble is
likely ro occur. Like perfective maintenance, tbe IT department normally miria res pre-
ventive main tenance. Preventive maintenance often resu lts in increased user satisfac-
tion, decreased downttme, and reduced TCO. Preventive maintenance competes for IT
resources a long with other projects and sometimes does nor receive the high priority
that it deserves.
Regardless of the cype of maintenance, trained professionals must support com-
puter 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 di rectl y affect
the organi zation'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 o f system. tr;ioned
professionals must perform high-quality mainte nance.
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 commun ication skills, and a n overall understanding of business operations.

SYSTEM ADMINISTRATOR: A system administ rntor manages computer and net-


work systems. A system administrator must work well under pressure, have good
o rganizational and communication skills, and be able to understand and resolve com-
plex 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 rounder-
srand the overall sysrem. In addirion to strong technical skills, an annlrst must have a
solid grnsp of business opernrions and functions. Analysts a lso need effecrive mrerper-
sonnl 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 va riety of tasks, but in larger firms, programming work rends robe
more specialized. For exnmple, typical job titles include nn npplicntion~ 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 a nd supporting lnrge-scnle dntabnse S)1Stems.
Many IT departments also use a job title of programmer/analyst to designntc
positions t hnr 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 o r expense is unnecessary, and members are likely to have a sense
of ownership from the onser.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.3 Maintenance Management 409

Unfortunately, many analysts feel that maintenance is less interesting and less cre-
ative 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 docu-
mented 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 compro-
mises 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 none-
mergencr 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 wa ne new features. IT staff members usu-
ally 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 c hange, the system review committee either
approves it and assigns a priority or rejects ir.

TASK COMPLETION: The system administrator usually is responsible for assign-


ing 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

No
System administrator
assigns maintenance Yes
tasks and monuOfS
Che wO<I<

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 adminis-
trator 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......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.

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

• Wort<1111 Group
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 docu-
mentation. 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, a nd the release
that includes the first set of maintenance changes is version l. l. A c hange, for
example, from ve rsion 1.4 to 1.5 indicates relatively minor enhancements, while
whole number changes, such as from version 1.0 to 2.0 o r from version 3.4 to 4.0,
indicate a significant upgrade.
The release methodology offers several ad vantages, 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, a nd less interruption for users. Using a release
methodology also reduces the documentation burden because all changes arc coordi-
nated 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 opera tional costs.
Commercia l 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, o r 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 opera-
tions. 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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:1MtWCt peck 10 h$ t..,, W"~ ... CO._ Slt'w<e PICb W tt:lowl lO "'"""-"to .,,,g1.

)'OU Mid f t reedy to~ tn ~


,..,,~

- 1. . . .__
fhe it<Oll Wl•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_& ....
10. t.ipdten M
• """"""connec:llOn. lttm 1NWW llbo.C. ~ W"""'°"" tO \IP to
ly ,..,. _ _ _ _...
'"'°"""l<Aftt d0w1 °m lldld """*"' ,.,.,. \ltlf'lt

FIGU RE 12-9 A Microsoft service pack provides access to updated drivers. tools. security patches, and customer-
requested 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 con~ment ft •

aaglng atta!', and mulupl wort1lows.

.....
·----
About Documeni.tlon
...... ,,.
,._,. a "°"~

°"----
--
~

. ...-
t>ownload• Community
CUlcL.-1'et111r.. W..,, rdrM..
"' "'""" ......................
o..-..i· ..............
•nd--
.

-FIGURE 12-1 0 G it 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 type~ 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 featu res.
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 rel-
atively simple to manage a system and measure its efficiency. Today, companies use
complex networks, client/server systems, and cloud computing environments to sup-
port business needs. A user ar a client workstation often interacts with an informacio n
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 compo-
nents 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 assis-
tance during the o peration 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 attrac ti ve charts and graphs ro
display the results. Information technology planning is an essential part of the busi-
ness planning process and often part of the presentations made co management.

12.4. 1 Fault Ma nageme nt


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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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~ import-
ant 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, mem-
ory, energy, disk, and network accivicy of all running applicarions in real time. Similar
programs, such as the Resource Monitor, are available on \Vindows. Faulr man-
agemenr 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 _ .,..., _.,.... -- -- PIO IJMr
....,.,..lff- IUtOll 70tCI 27,207.480 7,•'7...• 0-

.. 11;, Ml 11.1 Ml '°·"" 74,.... , ,•• WIMy I


_
0 - .,..~- 8 t Ml 64 $ M8 45_,115 itt,t2t 112 ..,1tO!Mdnn•tnl"'-"''"'"'

_...,.a
UMft'411\Aigtnt ')Ml
no u
.,, "'
..2 " '
12,21•
s,11<1
12,228
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 ....,
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-

----
- ow
IQ '7D
"'' ,. 21 no• ....,____
......... IQ U 21 DI...,,., _

·--
.. -
"'"' 4Q
•u
IOICB
,, ic:a
10
12
•2 tMO....,
, . l0201 ,...,.

.. --
0 llCtliio ...... .... ,... .. 11 .... -
SQ Maby\ell 11 11 1817 .....,
10 ID I 12 171~

..... ...
~-··­
'() ~.
10
1U
7U
>OU
SS1
It
1a tOOt
11
1Ulley
111 toec

........
...... JCftd

_,.
--
,,..,,..
0.....
20-
o-
0-

2
0
7
a
0
'°-
20•• -

11 -
-- 0- 0
"---~~~~~~......;.~~~-'-~~~~~~~~
0 o.,,.. ... - ~~~~

- 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.

.........""_.. ... .-.................. - ..................................


("..,_...,llll!O( ...... . . - - . .\) ....... ~ "->-"'Allf'W ~- ..............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~ --.......
...........
Chapter 12 Managing Systems Support and Security

416 12.4 System Performance Management

12.4.2 Performance and Workload Measurement


In e-busine s, slo w performance can be as devastating as no performance at all. er-
work delays and applicarion borrlenecks affect customer sarisfocrion, user produc-
t1viry, 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 diffi-
cult 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 softwa re.
To measure system performance, many finns use b enchmark testing, which uses
a set of standard rests to evaluate system performance and capacit)'· In addition co
benchmark testing, performance measurements, called metric~, can monitor the num-
ber 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 delive ry of the response. In the typical online environment, response
time is measu red 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 a ffected by the system design, capabilities, and processing methods. If the
request involves network or Internet access, response rime is affected by data commu·
n ica ri on factor~.
Online users expect an immediate response, and they are fru~rrared by any appar·
cnr lag or delay. Of all performance m eas urements, response time is the one that users
notice and com plain about most.

BANDWIDTH AND THROUGHPUT: Bandwidth and throughput are closely related


terms, and man y 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 bit s per second. Depending on the system, bandwidth can be
measured in kilobits per second (Kbps), megabi ts per second (Mbps), o r gigabi cs per
seco nd (Gbps). Analyzing bandwidth is similar to forecasting the hourly number of
vehicles th ar 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, through-
put is expressed as a data transfer rare, such as Kbps, Mbps, or Gbps. Jusr as traffic
jams delay highway traffic, throughput limitations can slow system performance and
response rime. Thar is especially true with graphics-intensive systems a nd web-based
systems rhar a rc 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 stan-
dard set of metrics exists, several typical examples arc as fo llows:
• Arrivals: The number of items that appear on a device during a given observa-
tion rime.
• Busy: The rime that a given resource is unavailable.
• Completions: The nwnber of arrivals that are processed during a given obser·
vatio n period.
• Queue length: The number of requests pending for a service.

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 s ubmitting 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 a lso is used for
cost-benefit analyses of proposed 111ainte11a11ce a111d to evaluate systems that are near-
i11g 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
syste m's prcscnr workload and performance specifications. Then future demand and
user requircmcnrs arc projccced O\'er a one- co th ree-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 cal-
culates 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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
11
_
fclul

-.~
MU

... .....
gs-
?
"
t

't
ll

,.
u

IS

_,
It
11

"••
1 CAPAcnv PLANNING ANALYSIS

DATA:

,• PrO<:~\in& 11me (S«onds) per Web site order·


MilXlmum Web·b.l~ orders per day
96
9.000

'
Goo<S.-S.- )(
1


--
"4ill i • .._.. .n Cd IS

'
10
tOWlillaMM--..
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, t ype, and size of all generated reports. If rhe system
invo lves a LAN, network traffic levels must be estimated to determine whether or
not the existing hardware and software can hand le the load. If the system uses a
client/server design, performance and connectivity specifications must be exam-
ined 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.5 System Security 419

I D ........
:::: • Ra.ii.
A - ,_t_ - - ··..•__.:.. ..,._ •
--- --

Unify IT Performance Monitoring end Oplim1Z11tion


Upt m I f str ct Mo tor

- <'>
-Iii
-- Start for FREE

A,t I . . llCe ~ . . . . . . . . ,.. c.,.aty~

c-c...--l'OU' -~llul·----·:t-
•-N"8QT._
~ f9'DO"llnO • *C*'ein
Mr:.iwor QIW1 JO,.! dOeP. ~.,_,COL C' 1;

.,.......--y- -
*es ft
_..,,....,_,.....,...
.
Cll*!llt_,.,.....__._ -
al._.,,
--
...,,~

.--pjlnnlng
,. . . . -...,io--.
... )IOU~ ..........

.. ~--...- ._,..,11--· · --
_ond_)IOU_llel1g!W-

... _
~"""
-y,,,.,.._,. ..,_-
...,_ ... . . . . . . .
-H"U..NovvOQ. Yi111111W.....
"'"... collOdlW""" """"'"'........ --
~ _.
\J!JllPlelnloonu<V•---
-~--·"""'-
~ Uk!XINX.

-111<141b1 . _ -
C.,.Cft)t ~and PtotetM ........."",.

__ _,,<O"""'Y____ -.--·--..
• ~/ lod$ JM ptebl1m• tMlar9 i1'~ twcJpert trw f'IOe dltlceraf

boet ~ I
_ _ ...,"""'O~ CP\A
------~-
Qf'..,,.
.... ·..
't4Wt.;ei 9"AOiilNrG ~ larlQdng.....,, hltlf'l
ond llQ . _ ................ -

~---- ...................
- - 1 a y 0 u - . . g o < - ... _ . . . , . , . , _ _ . _ . .. -
an 01iCAI

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 Integrity


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.
lntoml8tlon
12.5.1 System Security Concepts
The CIA triangle in Figure 12- 14 shows the three main e lements
of system secu rity: confidentiality, integrity, and availability.
Confidentiality protects information from unauthorized Confidentiality Availability
disclosure and safeguards privacy. Integrity prevents FIGURE 12-1 4 System security must provide
unauthorized users from creating, modifying, or deleting Information confidentiality. integrir:y, and
information. Availability ensures rbat authorized users have avallabilir:y (CIA).
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.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

420 12 .5 Syste m Se cu rity

Risk Management 12.5.2 Ris k Managem e nt


In the real world, absolute security is not a realistic goal. Instead,
managers must baJance the value of the assets being protected,
ldenllly potential risks co the organi1arion, and security costs. For example,
it might not be worth installing an expensive video camera moni-
coring 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 assess ment measures risk likelihood and
impact. Risk control develops safeguards that reduce risks and their
impact.
FIGUR E 12-15 Risk management requires
continuous risk identification, assessment, and RISK IDENTIFICATION: The first step in risk identification is to
control. list and classify business asse ts. An asset might include company

Threat Ca t e go rie s and Examples


THREAT CATEGORY EXAMPLE

Extortion Hacker steals trade secrets and threatens to release


them if not paid.

Hardware and software failures Router stops functioning. or software causes the
application server to crash.

Human erTOr or failure Employee accidentally deletes a file.

Natural d isasters Rood destroys company bu1ld1ng and necworked


systems.

Service railure Electricity is disrupted and brings the entire system


down for hours.

Software attack A group planes destructive software, a vi rus, or a worm


into a company network.

Technical obsolescence Outdated software is slow, difficult to use. and


vulnerable to attacks.

Theft of physical or intellectual Physical server is stolen, lncellectual property is


property stolen or used without permission: may be physical or
electronic.

Trespau and espionage Employee enters unlocked server room and views the
payroll data on a forbidden system.

Vandalism 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 carego-
nes 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 t har takes advantage of a vulne rability. 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 vulnerabil-
ity 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 ra ring 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 a re calcu lated and prioritized, critical risk~ will head the
list. Although rntings can he subjective, rhc overall process provides a consistent
approach and framework.

RISK CO NTROL: Afte r risks are identified and :issessed, they mus t 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 o ne 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 disas ter recover y plan
in case a natural disaster occurs. Transference shifts the risk to another asse t 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 no r 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 knowl-
edge, 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 compa ny itself. Thus,
a disgruntled e mployee, or a hacker who is 6,000 miles awa y, might launch an
arrack. Attackers break into a sysrem to cause dia mage, s teal informarion, o r gain
recognition, among o rher reasons. Attackers ca n be gro uped into categories, :is
s hown in Figure 12- 17, while Figure 12- 18 describes some commo n types of
attacks. Companies combat security threats and challenges by using a multilevel
srrategy.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

4 22 12.5 System Security

Attac ke r Charact e ristics


ATTACKER DESCRIPTION SKILL SET
C yberterrorist Attacks to advance political. social. or ideological goals. High

Employee Uses unauthorized information or privileges to break Vanes


into computer systems, steal information. or cause
damage.

Hacker Uses advanced skills to attack computer systems with


malicious intent (black hat) or to expose Haws and
improve security (white hat).

Hacktivlst Attacks to further a social or political cause; often Vanes


involves shutting down or defacing websites.

Script kiddie Inexperienced or juvenile hacker who uses readily Low


available malicious software to disrupt or damage
computer systems, and gain recognition.

Spy Non-employee who breaks into computer systems to High


steal information and sell it.

FIGURE 12-17 IT security professionals have names for various types of attackers.

Types of Attacks and Examples


ATTACK EXAMPLES
Back door Attacker finds vulnerability in software package and exploits it.

Denial of service or One or more computers send a stream of connection requests to


distributed denial of disable a Web server.
service

Dumpster diving Attacker scours the trash for valuable 1nformatt0n that can be
used to compromise the system.

Mail bombing Enormous volumes of email are sent to a target address.

Malicious code Attacker sends infected email to the target system. Attackers may
use viruses, worms, Tro1an horses. keystroke loggers. spyware, or
scripts to destroy data. bog down systems. spy on users, or assume
control of infected systems.

Man in the middle 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.

Password cracking 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.

Phish ing 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.

Privilege escalation Employee tricks a computer into raising his or her account to the
administrator leYel.
(continues)

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f •,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.6 Security Levels 423

ATTACK EXAMPLES

Sniffing Network traffic is intercepted and scanned for valuable


information.
Social engineering An attacker calls the service desk posing as a legitimate user and
requesu that his or her .password be changed.

Spam Unwanted, useless email is sent continuously to busine ss e mail


accounts, wasting ome and decreasing productivity.

Spoofing 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.

Security Levels
12.6 SECURITY LEVELS
Physical
To provide i.ystem security, six separate but intenrelated levels must
be considered: physicn l security, network security, application secu· Network
rity, fi le security, user security, and procedural security. Like the
chain shown in Figure 12- 19, system security is only as strong as Application
the weakest link. The following sections describe these secltrity lev·
els, and the issues that must be addressed. Top management often File
makes the final strategic and budget decisions regarding security,
but systems analysts should understand the overall picture in order Procedural
to make informed recommendations.
User

12.6. 1 Physical Security


The first level of system security concerns the physical environment,
FIGURE 12-19 Each security link has a
including IT resources and people throughout rhe company. Special specific focus. and the overall chain Is only as
anention must he paid ro critical equipment located in operations cen- strong as the weakest ltnk.
ters, where servers, network hardware. and related equipment operate.
Large companies usually have a dedicated room built specifically for
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 tigh tl y, and each entrance must be equipped with a suitable security device.
AU access doors should have internal hinges and electron1agnetic locks that a rc
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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

424 12.6 Security Levels

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
FIGURE 12-20 Companies use biometric scanning to analyze
co enable or disable the alarms.
the features of the eye's iris. which has more than 200 points that
can be measured and used for comparison. If pos-
SERVERS AND DESKTOP COMPUTERS:
sible, 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
keystro ke 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 everyth ing 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 mali-
cious 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 com-
puter 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 a nd 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( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.6 Security Levels 425

PORTABLE COM PUTERS: When assessing physical securiry issues, be sure ro


consider additional securit y provisions for notebook, laptop, and tablet comput-
ers. 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 a llows secure logons, BIOS-level passwords,
and srrong firewall prorccrion. Log on and work wirh a user account cha r has
limited privileges rather rhan an adminisrraror accoun r and mask rhc admin-
istrator account by giving ir a different na me chat would be hard for a casual
intruder ro guess.
• Mark or engrave the computer's case with the company name a nd address, or
a teach a tamper-proof asset ID tag. Ma ny hardware vendors a llow 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 wo uld be more difficult to use or resell. Security experts a lso
recommend using a generic carrying case, such as an artache case, rather than a
custom carrying case chat calls a ttention ro itse lf and its contents.
• Consider devices that ha ve 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 pro-
fessional rhieves, they might discourage and deter casual
thieves.
• Back up a ll 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 periodi-
cally contact a ecuriry cracking center. if the notebook is
Find My iPhone
stolen, the call-in identifies the compurer and its ph)•sical - ApplelO a~
location. Armed with this information, the security track-
ing center can alert law enforcement agencies and commu-
nications providers.
• Apple, Google, a nd Microsoft offer services to locate lost
customer sma rtphones. The services also permit remo te
data wi pe a nd factory reset of the devices. For example,
Apple's Find My iPhone a pp is shown in Figure 12-21.
Apple a lso provides a similar cloud-based service.
• While traveling, try co be alert to pocential high-risk situ-
ations, 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 check points. Also, FIGURE 12-2 1 Apple's Find My 1Phone app
when travelmg by car, score rhe computer in a trunk or helps customers locate lost devices and perform
remote data wipes and factory resets if needed.
lockable compartment where 1t will nor be visible. ~.. ....

.........""_.. ... .-................. _..__


("..,_...,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 estab-
lishing 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 th e best way to approach this issue/ Also, does a
potential security Issue exist/ If an unauthorized person gained possession of the key-
stroke 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 con-
nect to a network, a computer must have a network interface, which is a combination
of ha rdware and software thar allows rhe computer to inccract wich rhc nerwork. To
provide security for nerwork t raffic, 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 pos-


sibly a ltered, redirected, or recorded. For example, if a n unencr) pted, or plain text,
password or credit card number is transmitted over a network connection, it can be
stolen. When t he 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 a nd fast, it poses a fun ·
damenral problem. To use symn1et ric encryption, both the sender and receiver mus t
possess chc sa me key beforehand, or it must be sent a long with t he 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 mes-
sages. 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 Pro tected Access (WPA), which offered major secu-
rity 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. Eac h computer o n the private nerwork must have a dedicated
inrerface to the network, a nd no interface on rhe network should connect to any point
outside the network. In this configuration, unencrypted traffic safely can be transmit-
ted because it is not visible and cannot be intercepted from o utside 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 add ress, but a different box number. Port security is critically importa nt
because a n ;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. Po rt 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 com-
puter 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 Readi-
ness 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 0
>•t'I..•,,••• ••

FIGURE 12-23 The US-CERT is a key player in the battle against cybersecurlty threats.
Sol.ire« JL ~

(....,..... J:gi( . . . . .
r..a...w...,..._...., ..
I_,.. 41 11.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
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 matc hing rule is found, the firewall automatically accept~.
re1ecrs, or drops the traffic. When a firewall rejects traffic, it sends a repl y md1cac-
ing 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 onl y 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

FIGU RE 12-24 Exampll!S of rull!S !hat detenn1ne whether U,., firewall will allow traffic to pass.

NETWORK INTRUSION DETECTI O N : Suppose an intruder attemprs to gain access


co the system. Obviously, an intrusion ala rm should be sounded when certain acriviry
or known attack patterns are detected. A network intrusion detection system (N IDS)
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 pat-
terns. An NIDS requires fine-tuning to detect the difference between legitimate ner-
work 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 neces-
sary 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~ions , input validation techniques, software parches and
updates, and software logs.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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. T his 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) ser-
vice i~ available co a hacker, he o r 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 o rganization.
Hardening a lso includes additional pro tection such as antivirus and a ncispyware
sofrware. These programs can detect and re1nove malware, which is hostile soft-
ware designed to infilcrace, damage, o r deny service co a computer syscem. Ma lwa rc
includes worms, Trojan horses, keystroke loggers, and spyware, a mong ochers.

APPLICATION PERMISSIONS: Typically, a n app lication 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 applica-
tion 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 o pera tional system, security holes or vulnerabilities


mig ht 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 carefull y. 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. Pa tches
released by third-party sofrwa re 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 a n application to contact the vendo r's server and c heck 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......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


t hat 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 administ rator
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, a nd a systems a nal yse needs to consider the impo rta nce
of encryption o r encodi ng fi les ro make t hem unreadable by una uthorized users, and
permissions, which can be assigned co individual users or to user gro ups.

ENCRYPTION: As explained in che section on necwork secu rity, encryption scram-


bles 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 fea-
tures 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 ser ver. 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~er 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 onl y 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, a n appropriate level of management approval is requi red
for a ny pe rmissio ns 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 o r rank. If a person is transferred, he or she leaves certain groups and joins
others that reflect c urrent job duties.

12.6.S User Security


User ecunry involves t he identification of system users and consideranon of user-re-
lated security issues. Regardless of o ther security precautions and fearures, security
ullimarely depends on S)'Stem users and their habits, practices, and willingness to sup-
port 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 ma nage-
ment strategy must balance technology, security, privacy, cost, and user productivity.
ldenrity management is an evolving technology tha t is being pursued intensively by
corporations, IT associa tions, and governments.
Carmer has described identity ma nagement as a "set of e lectronic records that
re present ... 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 uniq ue 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, o ne of rhe most common computer passwords has been" 123456," an unfortu·
narc choice rhar is trivially easy to crack.
As long as passwords a re 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 a nd stores it in a n easily accessible location s uch as a desk, a bul-
letin board, o r under t he keyboard.
Several yea rs ago, a hacker made headlines by gaining acccs~ to the email account
of a political candida te. 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 i llegal and constituted a serious felony under fed-
eral law.

SOCIAL ENGINEERING: Even if users are protecting and securing their pass-
words, an intruder might anempt to gain unauthorized access to a system using a
tactic called ~ocial engineering. In a social engineering attack, an int ruder 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 pre-
tend 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 compro-
mise 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 th is telephone
call. The user should be required to provide further informatio n 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 com-
monly used as part of identit y theft, wherein personal information or online creden-
tials are stolen and used for illegal purposes. The Federal Trade Com1nission's division
of Privacy, Identity & Online Security has a section dedicated to helping consum-
ers 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 senio r managers, dislike tight secu-
rity 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 securi ty token shown in Figure 12-25 is a
physical device that aurhenticares a legitimate
user. Some firms provide employees with secu-
rity cokens that generate a numeric validation
code, which the employee enters in addition to
his or her norm::d password.
Unfortu nately, new technology sometimes
creates new risks. For example, a powerful
search application can scan a ll the files, docu-
ments, emails, chars, and stored webpages nn
a user's computer. Although this might pro-
vide 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 FIGURE 12-25 Security tol<ens, which come in various forms. can
anything stored on the computer. Also, if an provide an addmonal level of secunty.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

43 4 12.6 Security Levels

inrrudcr uses rhc rer m password in a search, the program mighr be able ro find pass-
word 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 er-
namcs and passwords.
Business and personal users also should use caurion when they consider cloud-
based 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 Se curity


Procedural security, also called operationa l securit y, 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 tech nology. M anage-
men t must work to establish a corpor a te culture tha t stresses the imporra11cc of secu-
rity ro the firm an d its people. Proced ural security defines how particular tasks arc to
be per formed, from large-scale data backups to ever yd ay tasks such as storing emails
or forms. O th er procedures might spell o ut h ow co upda te firewa ll 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 secu-
rity. For exam p le, an employee ha ndbook mig ht require tha t users log o ut of the ir sys-
tem accou nts, clear th eir desks, and secure a ll documents before leaving for the day.
T hese policies reduce the r is k of dumpster diving attacks, in w hich an inrruder raids
des ks or trash bins for valuable inform ation. In a dd ition, 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,
w here access i~ limited to employees who need the in formation to perform sccu-
riry-related tasks. ~1any firms also a p ply a set of classificat ion levels for access to
company documents. For example, highly sensitive technical documents mighr be
available only to rhe IT su pport ream, while user-related materials would be available
to mo~t compa ny employees. If classification levels a re used, they hould be identified
clear ly and enforced consistently.
Procedural security muse be supported by upper ma nagement and fully exp lained
to all employees. The organization must provide training co explain rhe procedures
an d issue reminders from time to ti m e that will make securiry issues a prioriry.

Chain Link Consulting is an IT consulting firm that specializes in system security issues. The com-
pany'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 recom-
mendations, 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>_... ........ _ .. ~ ........................._ .... ._
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 , 200 1, and increased concern about global terror-
ism, 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 con-
tinue 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 ret rieval 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 a mount 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, soft-
ware, 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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 d rives appears co rhe computer as a single logical drive.
Figure 12-26 shows a comparison of various backup methods.

Comparison of Backup Methods


TYPICAL
BACKUP TYPE CHARACTERISTICS PROS AND CONS FREQUENCY
Full Backs up all files. Slowest backup time and Monthly or
requires the most storage weekly.
space. Rapid recovery
because all files are restored
in a single step.

Differential Only backs up files that Faster than a full backup and Weekly or daily.
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 Daily or more
are new o r changed the least storage space often.
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. Usually only


method that records software, and network used by large
all system activity. capacity. Recovery is very firms and
fast because system can be. network-based
re.stored to just be.fore an systems.
interruption.

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 o r years, depending on legal requirements nnd com-
pany policy. Stored media must be secured, protected, a nd 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.8 System Retirement 437

After personnel arc safe, damage to compan y 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 objecti ve of a disaster recovery plan is ro restore busmess
operations to pre-disaster levels.
Disaster recovery plans are often part of a larger business contin uity pla n (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 c rash, or physical catastrophe. A hoc
site requires data replication, which means that any transaction on the primary sys-
tem 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 ho t sites are a ttractive backup solutions, they are very expensive. I low-
ever, 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 insura nce can offset the financial impact of system fail-
ure and business interruptio n.

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 va rious 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 tech-
nology 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 follow-
ing signs:
• The system's maintenance history indicates that adaptive and corrective main-
tenance are increasing steadily.
• Operational cosrs o r execution times are increasing rapidly, and rou tine perfec-
tive maintenance docs not reverse or slow ·che trend.
• A sofnvnre package is availa ble that provides che same o r additio nal services
faster, better, and less ex pensively than the current system.
• ew technology offers :.t way to perform the same or :.idditional functions more
efficiently.
• ~lainrenance changes or additio ns 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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

438 12. 9 Future C hallenges 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

T here is an o ld 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 nume rous 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 bou nd 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 spe-
cific 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 Tre nds 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 ma y 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. 1vl any 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:-..•~-".....-""'*"....,.._...,.. ..
Phase 5 Systems Support and Security

12.9 Future Challenges and Opportunities 439

IMPACT ON IT IMPACT ON FUTURE


TREND DESCRIPTION GENERALLY SYSTEMS ANALYSTS
Globalization New lands of corporaoons will language skills will be exi:remely Syst ems analysa will be directly
be globally integrated. driven important. Technology will open affected by global uends. They will
by the Internet. and free of new opportunities for developmg probably wort< for more finns '"
traditional trade barriers. countries to compete more their careers. be exposed to more
effectjyely. Knowledge worl<ers mfonnati0n, need more teehnical
will communicate and collaborate skills. and see greater change than
across borders and boundaries. at any time in history.
Work will be done 24'7 across
multiple time zones.

Technology Powered by an enormous New tec.hnology will drive ma1or The systems analyst will need
Int egratio n mcrease in computing changes in how persona.I and a. mix of business s~ and
power. new IT models will business services are provided. technical skills. He or she will have
include networks with smart. Firms will compete in a global a unique opporwnity to work
interconnected deVJces such marketplace that will reward at the Intersection of business
as communication systems. Innovation. creativity, and positive operations and IT. Synergy
automobiles, entertainment, soc.ietal outcomes. between technology growth and
transportation lnfrastrucwre, globalization will create jobs and
and "smart" power grids. opportunities for people with the
right skills.

Service A business model of computing Service orientation is a paradigm Systems analysts will need to
Orie ntation where processing capabilities shift. It represents a matunng Increase their business acumen to
and data storage are leased of the field. where end users no wort< effectively in a service-oriented
(rented) instead of bought longer care about technical details IT enwonment. Technical slolls wtl
(owned). Computing capabilities as much as business functionality. still be needed. but services are
are seen as servtees used IT systems will be built using SOA about fulfilling business requirements.
on-demand. hke electricity or (service-oriented architecture)
water, rather than as managed to enable current and new
programs. functionality to be delivered as
services to customers.

Cloud Cloud computing is a new The full potential of cloud Like any new technology. systems
C o mputing model for delivering business computing will be realized by development for cloud-based
and IT services. It will have a firms that can integrate cloud· applications will be a challenge
profound impact on business based infrastructure. services. for some and an opportunity
strategies, including product servers. data access, and a secure for others. Regardless of the
innovation, markeong. customer environment. Creativity and development method or platform.
relationships. and social media. innovation will be rewarded. and an analyst will need business savvy
Cloud computing provides the competition will be intense. Cloud and technical know-how to help an
IT infrastructure that enables computing will lower TCO by organization take full advantage of
service orientation. reducing capital expenditures. the cloud.

The Wortcplace In the face of worldwide Successful IT workers must be able Students prepanng for the
competition and enormous to innovate. analyze. communicate workplace of tom0rrow will
technology change, finns will effectively, and "think outside the need a strong skill set. Systems
stress innovaoon. vision, and box." The winners will be those analysts will be expected to bnng
the ability to adapt rapidly. The who can adapt to change and convnunlcations, modeling. problem·
abihty to think critically will be embrace new technology and new solvtng. decision malung. and critical
Vita). ways of doing business. 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 o n future systems analysts.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
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) devel-
o ped overseas, and political pressure co pre erve johs.
It is entirely possible that large enterprises would require suppliers to certify their
security c redentials and sourcing policies. Another issue might re late 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 c usromers around the
world will become progressively mo re 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 a lso 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 C hapter 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 sta y 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 forma l 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 Informa-
tion Systems and possess an JSTQB foundation level certification s hown 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
• --hoall.\J
testin& certifications build your path to jobs and promotions.

ISTQ8 C.." ........,, 11 the most "°"""''


sol- '· .... 1..unacertif\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> • l
tic.d tor ISTQ8. That's wily American COllllM!HS d1edt With us to se•ul you are~ !'led.

Foundation level Certlftcatlon (CTFL) • -Tm!na CASTQe)

lSTOB Found.11lon Lovd M>ttwaie tntlna certiflatoon <CTFU os a cuecr e:;$C!llial


l nit soltwa.. Whether you IOS1 IOftware all clay or jUSt part llme !llrou£h A&ll o..ot>s
'°' those •
Of Conl l'IUOll1 De!IW<y you need ISTQB Found411on level te: "I cortfhcat en (C'Tfl.) •

c .....- • T • Anolpt(ISTQIJ

FIGURE 1l-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, whic h 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 commu-
nications, 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 lead-
erlthip 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 e nviromnen ts 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 taxono my of learning objec-
ti ves in education for many years. What has changed-particularly within informa-
tion 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 a lgorithms, and technical innovation are important, but the most valu-
able 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 informatio n that he o r she needs on the job. Many employers now seek criti-
cal 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 hardwa re 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 profes-
sionals can have serious implications. Situations may arise involving ethical consider-
ations 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
you rself what would you do? Where would you draw the line? I low much would
you be willing co risk doing what yo u thought was the right thing? The decisions you
ma ke 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( . . . . .
r..a...w...,..._...., ..
I_,.. 4111.,.. .................,.t11ru
~- )U,
..,...,.......,..~
-Woip-M ._..,..
..
-·~•-fllllie<'f•,...
__.~~c.....,..~
0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Phase S Systems Support and Security

12. 10 Summary 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 permis-
sions 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 repo rt 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 com-
ply 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 ana lyst's pri-
mary involvement with an operational system is to manage and solve user support
reque&ts.
Corrective maintenance includes changes to correct errors. Adaptive mainte-
nance satisfies new systems requ irements, and per fective maintenance makes t he
system more efficient. Adaptive and perfective maintenance changes often are called
enhancements. Preventive main tenance is performed to avoid fut ure 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 a nd scheduled for the IT group.
T he 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 main-
tenance 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 ini-
tiates perfeccive maintenance projects to improve performance or maintainability.
Aurom:ncd program restructuring and reengineering are forms of perfeccive mainte-
nance. In order to avoid future problems, IT staff perform prevenrive maintenance,
which involves ana lysis 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
simulta neo usly. A release methodology usually is cost effeccivc and adva ntageous 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 s pecific 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 du rmg 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 lev-
els should be analyzed: physical securiry, network securicy, application security, file
security, user security, and procedural securit y. Physical security concerns the phys-
ical 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 secu-
rity requires an understanding of services, hardening, appl ication permissions, input
validatio n techniques, software patches and updates, and softwa re logs. File security
involves chc use of encryption and pcnnissions, which can be assigned co individual
users o r 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 a nd policies that ensure secure operations.

(....,..... 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. 10 Summary 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 eco-
nomic life usuall y 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 informa-
tion 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 1should 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 knowl-
edge and skills. Many IT industry leaders offer cerrification. Ln addition to technical
ability, other skills, such as critical thinking skills, also are extremely valuable.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
Chapter 12 Managing Systems Support and Security

446 Key Terms

Ke y Te rms
acccpt.a ncc 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 require-
ments 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 hen-
di1 co an organi7.ariun.
attack A hos1ile ac1 1ha1 cargecs an information system, or an organii.ation itself.
automa iic 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 .tvailahil-
icy (ClA ). t\vai lah1licy 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 rcquire-
mem< 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 BI 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 level~ 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\Cl-
npmcm; 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_ ._.... ~~ ..
. ..............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
.... . _
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Phase 5 Systems Support and Security

Key Terms 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 va lued 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 wh o 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 o r 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~~
.......... _ _ _ , _ • .......,.. ....................
Chapter 12 Managing Systems Support and Security

448 Key Terms

hot \ttc A sepa rate 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 secu rity: confidenrialiry, intci;riry, and avai lability
(CIA). lmcwiry prevent\ unaud1urized asers from creating, mod ifying, or deleting information.
Khp; (kilobit; per •econd) A bandwidth o r 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 peratin g systems and a pplic.mons rh ar documems .111 evenrs, incl udmg
dJres, 11mes, and 01her s pecific information. Logs can be im portant 111 lutdersra nding pJst a ttacks and
prevcnring furure inrrus1ons.
m·:untt·nancc acri,~iric\ Chungi ng pr<>gra n1o;;, prc>ccdurcs, <lr d<x:un1entati<>n t<> c.:n,urc C<>rrcc."t system
performance. Adapting rhe '>ysrem ro c hanging 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.1n-
n11111 and preparanon. For example, a company can prepare a di~a~ter rc<ovcry plan to miri11ate rhc
effecrs of~ narural disaster should one occu r.
network Two or more devices rhat a rc connected for the p urpme of o;endtng, rc:cciving, nnd sharing dara.
net\\ Ork intcrfoce A combination of hardware and software rhnt allows th<' compu ter to inrc r.1ct with
the network.
ncc\\orl. intrusion dc1cction ;ystem (NlDS) Software that monitors nerwork traffic to detect •trre mp ted
111trus1011> o r su.picmus nerwork traffic p:a treros and sends a lerr~ to network .1d nllm>rr.11ors. Can be
helpful m docu menting rhe efforrs o f arrackers a nd analyzing network performance.
offsit1n14 The practice of srormg backup media away from the mai n bu~mc<> lo..:atmn, in c>rder ro mm -
gare 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.1nage ria1 policia and coatrol; th.11 en~urc .e..urc op<ranon;.
Al~o called procedural sccuriry.

~JD»(".............. .-\l ........... .,.... _.,."'flllll.~-....-..-"*-·,..,_o.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...
-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Phase 5 Systems Support and Security

Key Terms 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 t hey arc either destroyed
or the bJckup media 1; reu;,ed.
rhk An evcnl that cou ld 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
Chapter 12 Managing Systems Support and Security

450 Key Terms

\ccurit~ hole Created bl a comblllarion of one or more improper!)· configured services.


\\.-.:urir~
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 commercia l ~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.
I r profe&sionals must have soft skills as well as technical skills.
~ofm.1re rcenginccring Uses anal ytical techniques to idenufy potential qualiry .ind performance impcove-
mcncs 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 cest-
ini: 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, ~lhps, 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 subm nunp. 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 cnahl 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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. ;upcr-
seded 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.:


.........,. _ _ .._ ......... ..,
..,,.........,..~_.......,_,_,_._....~~ ..
...............
C'ftlpll"&.-..,~fw
_ .... ~---11rt~
....._
...-,..~---~ ~
.......... _ _ _ , _ • .......,.. ....................
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
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 secu-
rity threats and problems in the futu re?
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?

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

453

.........""_.. ....-................. _..__


("..,_..., llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~ --......
...........
454 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gi ( . . . . . -Woip-M ._..,..
..,...,...... .,..~ ..
__.~~ c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 455

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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~----··----~~-.,.-"~ --......
...........
456 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,....._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~• ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi ( . . . . . -Woip-M ._..,..
..,...,...... .,..~ ..
__.~~ c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 457

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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~---- ···---~~-.,.-"~ --......
...........
458 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 41 11.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ ..
__.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 459

fill··in form A 1cmpla1c u...J 10 coll= Jau 011 the ln1emc1 or a corn- pteWlly (I) In bu;mcs. procernng modcl1n11 nooauon, a fork m the
p3n)' rnoranrt. process. allowmg the now to go one WJ} or another. (2) A rourcr or
finish day/date The dai• or d•1t when J ta<k "scheduled robe fin· ocher network dtvi« u!.cd 10 conn"'' tO a lar11cr. d1ssurular type of
bhed. OCC\\o'ork, such a~ rht Jntcmct.
firewall Theo nmn line ol ddcfbC ~ccn • Joal net" ork. or oncnnct. gipbits per second (Gbps) A t>andMdoh or 1hrn11ghput mcasurc-
3ncJ th• l111crnr1. mm1.
first nonnal fonn (I NF) A ttcord ''Yid to l>c m I !\F of n doc< noc globlll outsourcin& The prJClk:C ol \htfttng IT dntlopment. support.
conr.un • rtpt'.•nng group (• .ct of data items th.it can ex-cur any nwn- and OJIC'rauon> 10 ocher countn~.
b.:r ol nm"' m • >tn~lco rr.;orJI. glueware Su m1ddlcware.
fishbone diaaram An .1nal)m 1<>ol 1h.11r•P"""""1hc pos;1hle c•usn gnphical user interface (GUI) The use of 1tuph1ol ob1«LS and
of. prohlem .1<. vaph1c•I ou1hnc. Alm Cdlled an l•h1kaw• diagram. l("<.:hn1quc!.- allu"'"K Uo,c'r\ 10 ~cHl1n1un1tt.JtC' wuh J ~)'tcrt1. \ v..cll-

fU<ed fee model A <en1'< model tha1 charges a set ftt b'1scd on a
desq;ned GUI can help u<e" lram • new system r.1r1dly and work with
me sysrtm ·ff~tild).
specified lt\el ol s<rv1ce one.I user suppon.
gray hole A proceu Mth Jn mru1 ob'1ou'I) 11bulf1ctent to gencraoe
nowchart \ diagram u«d to dc<cnhc program logic rhor represencs 1hc <hown ourpur.
IOjti<.al rule> one.I mt<rJct1011 gr.1plm.Jlly u;ing a series of symbols con-
necoed by .1rro"''· l lowd1.r1< c•n he u.efol 111 vi~u•hLmg modular iroupware Program; th.11 run on ll network thJI enable""'" to .hare
progrnm designs. darn. collaborate on pro1«.1', and work 111 t<.1111>. Al>o <.tllec.l worl·
group <ofowJrc.
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 hardenlni: Making a ;y,tcm more \Ccurc by removing unn<'Ccss:try
accounts, s.erv1ce:i.. and fe~l1urc".
covers 1hc lifel1nc.
hardware The ph) <1c.1l bycr of 1hr 1nfom1Jnon >y"cm, to mdudt
foreign key A field 111 one table th.11 must match a primary key val ue computers, network<. co111mu11tca1ioM equipment. nnd other rcchnol·
m anoohcr 1:1blc 111 order to csrnbli>h the relntiomh1p between the two ogy-baseJ infrasrruuur<.
tJblrs.
hash totals Nm 111can111gful number> 1bem>clvc; bu1 are u>cful for
form filllna A Hf) cffe.;t"e m<1hod of nnhnc da1> cn1ry where a companson purpo<c<. Also known a< hatch conrrol tota ls.
Mank form rhar dupl1ca1r, or rc-.mble< rhe •ource dncumcnr is com-
pleted on the ~rccn. The u>cr enters the data and then moves ro the Hawthorne Effect A phenomenon whl•rc cmplO)l'<'> who know they
are being ub)lerve<l .irt 1nort produ,ta\.c,
llC\I hdJ.
help desk A ce111rall7ed ttmu,.-e ,.,ffed hi Ir profe~1onals that rro·
fonn layout Inc phy'lc.11appearance and placemenr of dat.1 on a vides user>" 1th 1he suppon the) need to do their 1ob>. A help desk has
form. Form layout make• the form easy to complett and promlcs thrtt ina1n oh1f\.11\e-.: to 'how ~orl~ how Ct) u~r ')'tc1n rt."M>Ur~e~
enoujlh >pJ~. both 1cru{~lly and boruont:tll)'. for us.en to enter che mott dfrai,ely, tn pro'1dr >n\\\er< 10 te<hn1c.1I or opera1tonal qucs-
c.1 ....
uo~ and w make U>er> more produ,u'c b) tea,hmi: lhrm ho" 10
fonrm An onlmc J1«.u\\1011 on• ramcubr rnpic, whett ~pie men, mttr 1hc1t own 1nfnrmat1on need-. Al..o ulled .cn ice de,J,, nr infomu·
offer suppon. •nd t'l<changc idea•. uon center~
fouMnodel .,,proach A phy;i.-al model of the curren1 S) strni. a l<>gi- hierlll'Chklll networlc A ncrn ork de.1gn "'here one computer t) pt·
al model of the •urrrnr S) Siem. a IOjllcJI model of me De\\ srsrem, and calli a mainframe) <onrrol' the enurr n<IM>rl. \atclluc <ompu1ers or
a ph) sial model of 1he Ile\\ "'"m •re all de1clopcd. servers control lo" er Ind< of pro..e;smg and nriwork de'1ces.
full backup \ 'omrlc1e badrnp of nery hie on the sy"cm. histogram A common mot for sho" mg thr d1stnbo11on of question·
functional baseline ~ ronf1gurauon of die S)Sltm documented 31 D3trc Of >Jmphnjl rc:,uJI,. h tJJ..c, tht form o( ~ \CMlcaJ b.tr<han .
rhc bq;inmng of the pro1<..:t. lo cons1s1> of all rhe neccs..ar)· sysrem horizontal application A snff\v•re p.id,.;1gc that c•n he used by m.an)'
rrqu1rcme-nr" and ~1gn ..:on\tr.;ur1~. differenr orpes of orgami.aoon,.
functional decomposition dlaaram (FOO) A top-down rcprc.c:nta- horizontal system A b3'ic >);l<m. •U<h "'on lO\CntOf) or PJ>roU
ttOn or hu'1nc>• functtOn' and prol<.-C»CS. Al;o called a structure chart. p3cii.ag.e, 1hat ., -.:<>mn1r•nl¥ u'\.ed h> a ,.1ru:1y <>f l.C>nlpan1c-..
functional primitive A •mglc function rhat l< nor exploded funher. hot site A separate rr locauon, whl<:h might l>c tll another SIJIC or
The logic for fu11<.11on•I prim1uves " documented m a da1a diaionary t:\cn 3nother i..:ounrf), that \:JO .'J,Upport t.:riu~.11 bu>nlc>.; ~)~term in th~
prn«ss dc"'rtpnon. C\COt o( ~ pnwer outage, ~y,tcm cra,h, or ph)'\K.al t.lta\ttt>phe.

functional requir.,ment A \ tattmcn1 of the sen1«>s a system pro· HTTP/2 The second ma1or vcrnon ol 1hc network protocol used b)
v1dcs. the web. Rel.,,t<t'<l •> n >1andard 111 20 IS.
functionally dependent Func"trona l dependence 1s an imponant con- hub The ce111cr uf a >tar 11<1wurk. ~w11~h•> in 111odtrn network> ha'e
ap1 fur umlcr>1andmf; oltc 2NI'. Thc f1dJ X 1s said to bt fun<.-tionally largely replaced huh>.
dependent on 1he field Y 1f the Y.lluc of X depend~ on the value of Y. human-computer interaction (HCI) A dc<cription of the relarion-
For example, an order dare i~ dependent on nn ordrr number; for a sh1p berw«n computer. and the people who u>• them to perform
por11cular order numbcr. 1hcre i> only one value for the order dare. In bu,111ess·rclatcd ta<k<. 1ICI concept< apply I<) c,·crythmg from a PC
conu·as1, tht• produc.:1 de,r1p1tnn 111. nn1 dcpenden1on Lhe order nuni· desktop 10 1hc ma in menu for a globJl ncm·ork.
bcr. For n pamcular order numh<r, there might he several prndua identity manai:ement Conrrol; •nc.l prox:cJurc> nece.snry 10 idenciJ)
de.criptte>n'· one for each 1tcm ordered. leguinlatc u\Cri. and ~y~tr1n 1o;;<n11ponenc,,
Gane •nd Sllrson A populJr •imbol ;t1 u>ed rn DFDs. Processes, da1a identity theft The <teahng of pcr<nn•ll) tdenufymg 111for111acion
now,, cJa13 >IOfC\, ,llld e>tr1nal C11UllC> Jll hdVC ,t unique symhnl. c>nhne.
Gantt chart A homo111.1l l>ar <hart th.111llusrrar<'> a <ehedulc. Dcnl- IEEE 802. 111 A >«um) ''anJ.ucJ for Wi· F1 w1rrl<>> ne1works that
opcd many ) tar> Jgo hy I lenri L Gantt as a prnducnon control uses 1he WPA2 protocol, rnrrcntl> 1hc m<»t <ccurc cncriptton method
techmque. Sull arc 111 common use IWa). for Wi-F1 n<rworh.
garbap in, garbaa• out (GIGO) lbc wn<.cp1 tha1 the qualuy of the incremental backup ~.. mg a cop) ol only thc filo th.1 ha'e changed
ourpu1 "only,., i;nod a< the quahry of 1he mpur. sm« the la51 full backup.

c.,,......_..<.....,1..,.. "'~~-- ~-•"'fl"ll ~ •..,._. •......,•• ,...


c.s........
lM«lllln'_ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .._.. • .,.._..
0-..- . - ............. ....,,,....... _,..,....,......._.,..,,.....,.~u,
~- ..... - -.......... ,- .. .,,, .................""""._ ..... ...
460 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- t fta111&....-.~~ ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,...... .,..~ ..
__.~~ c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 461

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

.........""_.. ....-................. _..__


("..,_..., llll!O( .....,..___ .\JI..,...~ \b) -
...................•_...••fl" 0-•*._ ...... _
WAlif'W ~- ........
__.... ~~·~---- ···---~~-.,.-"~ --......
... ,..,..,... _, ~ ..,._.,,. .,_._, te...- .._""""""._
...........
462 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gi( . . . . . -Woip-M ._..,..
..,...,.......,..~ .. __.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 463

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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,..
~~·~---- ···---~~-.,.-"~ --......
o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
...........
464 Glossary

product.o0riented C...ompan1cs thdt n1.1nu(acturr l"01nputc:~. rourrrs, quantita.tive risk analysis LvJlu>llng mk Ill ttrnh of the acruJI
or m1croch•p~. 1mpaet '" tern1s of dollar.. umc, pro1cct ><.ope. or qu.11111.
Pl'Olram documentation Prep;ir.inon of program documt ntatton query by example (QBE) A language allow> the u1<r to provtde Jn
\laru 111 t~ \);tt1rL-. J.n3l);I~ ph.a.;c .1nJ -.;onunuc:~ Jur1ng "")~rems example of the data rrque>l<'<I.
1mplcmcnt•non. S)Sl<nl\ •nal)\I< rrrp>re O•erall documenta11on, such query language Allows a u~r 10 specify • task "tthout spectf) mi;
as process d~nption• :and rep<>n la1·out>, earl) m the SDLC. ho" trn: ta<k \\Ill be accomrh<hed. !>ornc qutr) bnl(UJj:~ U'iC natur31
Programmer'\. pro\ 1dt" dc>Cunttn1.i11on b) ~ans;rru"t•n~ moduk4" th:tt are
language commands that resemble ordinary f.ngh•h •rntcncC".
well supponed b) 1111tmal and c.icmJI commcnh and descnpttons
dut c•n be undcn.tood •nd mJ1nmned ta,il). qu~onnaire A document conmmng • numhc:r of >1ambrd qu<"·
nons that can be -.ettt to """Y 111d1nduJl\. Al"1 <.1lleJ J '""C).
Program Evaluation Review Technique (PERT) Su rERT/CP~I.
radio button Button> th.at rrpk'Cnt grour• of or1Klll' The U\Cr un
Pl"Olrammerlanalyst A dC'\1W1•11on fc>r ros1nnn< that require a com· select only one opoon at a nmc' a selected oruon con1>1ns a black dor.
bmarioo of ~·stems anJl)SIS and prnt;rammmi: skills. See also option button.
project coordinator The pen.on" ho handl,., admitu>tramc r"'pon- radio frequency identification (RFID) T<'<.hnolOjl) thot U>e> h1i:h-
"bdmcs for tbr dt\do1>1nrnt tram and negottale< wi1h u<er< who
might ba"c co11fhc11ng rcqu1rcmcnr> or "ant changes thar would frcquc11cy radK1 wa\c- tu tnt k phr1<JI ohJC<I\.
require •ddumn.d wnc or e~pen.e. radio frequency identification (RFID) ta1 An mput device u<cd 1n
source data autonut•on.
project creep Inc procc.s by whtth pr<>1«is wtth \cry i;encral scope
dcfin1nons e~pand grndually. wirhom <pcc1fic amhori1ation . .-andom sample A sele.non taken ma rando1n, un planned manner.
project leader The per-.<111 charRcd w1rh leading• project from • For example, a random .. mple 1111gh1 he• sample tha 1 <elc.1s any 20
t('('hn1co l p<rspernvc. cusromcrs.

project management rhc pr<>«" of pln1ming, scheduling, mon11or- range check A type of daca validation check that tC•lS dn1n items tc)
ing, controlling, and rcpor1111g upon the development of M 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
infor1naaon ~y~ttn1.
the range of 0 to 24.
project manager ·1he pcrwn charged wuh managing• projoc1 frum
an admini<;:tratlvc pcrc;!'>C"Crivc. range-of·responso questions Clo1ed ended que>iion• that a~k the
perwn ro evalu.11c something by providing ltn111ed """'tr> to sped fie
project monitoring Guiding. supervl\mg, ond coordinanng che proi- respon<es or on a numeric SCJle.
t<:t team\ workloJd.
rapid ;a.pplication development (RAD) A tcJm·hao;cd rcchniquc that
project pl<innina ldcnttlymll pro1«t t."~' onJ c<timating compleuon speeds up mforn1't1on systent> dc•elopmcnt Jnd produce. a funrnon-
time ond ~<>'>ts. ing information S}'Stcm. RAD is sm11lar i11 concept to JAD but goc>
proiect reportin1 Pro\ 1J1ng ri..-g:ular progri..i.'J reporcs ro managt."menr~ funhcr by including all rh.1\C'\ of the ~Ol C..
users. •nd the pro1cct tc•m u<cll. reasonllbleness check A rypc ol data vahcL1tton cht'Ck that 1dcn11fics
project schedulins rhc crc.mon of,, 'peciftc nmct.1blc m fnciltr4rc values that arc quesuooable but not n«.tssanly wron~. For example,
complerion of• project. Also invol··~ ~leering ond sta ffing rhe project mput payment •·alue> of SO.OS .md SS.000,000.00 bo1h pas; a simple
team and ass1w11n11 spcc1li. t•sk; to 1ram member\. lim.1tchtck for a p•)mcnt 'aluc greater than uro. and )<t "nth 'aluK
project scope A si-1hc dcttrrmnauon of a pro1e..,\ houndariC" or could be errors.
extent. record A M't of ttlJted field. tha1 dc ... nhc:; one m>tan,c. or tn4'tnbtt
project trianal• The three ma1or cumponm1> ot • pro1ecr: co.,, of a n cntrt), ~tK:h a" one cu~romcr. one t>rJcr. ()t cMlC' rrcxlu'-1 A Chord
scope. and umc. A pro1cct manai;tr rncs ro fmd the opumal balance might ha,.• one or dozens of fields. depcndmit on what mfornunon ts
among the<e facto~. needed. Also called J tuple.
properties In obicct-oncnted <0 0 1analysi>. characteristics cbat records retention policy Rul"' de>1g11ed to meet Jll lci1-1I require··
ob1crts mhcm from tht1r da" or I'"'''"'
on 1hcir own. mcn1< •nd hu<m"1i< ~' for l~ring m:ord<.
prototype An early, rar1dlt con .. 111x:ted "orking \Cr\1on of rhe pro- recovery The procc<<< of restonng dJta and rc<ramng a syorcm after
p-OS<'<! 1nformauon >y>1cm. an interruption.
prototyping The meihod hy which• prmot}p<• "Je>eloped. It recovery pro«'Clure Pr0<t1>> for re;tonng data and reHamntt a sis-
involve< a rcpcltll\ e srqucncc of an.11~"'• de"!!"• nl(ldeling, and res1111g. tcm :after an 1ntcrrup11on. RttO\'Cf)' ('rtk.cdurc~ c:;an he usrd ro r~torr a
Ir is a common technique rh•r c11n he u1ed to dc11g11 anything from• file or dorahase ro it~ currcm state at the ttme of the 1.-1 l><1<kur.
ne''' ho1nc co a compu1er nctwor~. ,..,dundant """'Y of Independent disks (RAID) A RAID sy<rem may
proxy server A nerwork1 1111 de' tee 1h:11 provide' ln1ernc1 <onnccnvity h<! pon of a11 organtLation'> backup and recovery plan•. A RAID')'"
for internal LAN use.-. rem mirrors the dar. while prcxc'""ll ""'""uc>. RAJD <ys1cms are
pseudocode A tcd1111quc for rcprC>t'llltng progr:im logic in scmi- called fault· rolcranr. because a failure of a11)' on< disk d~< not disable
~Lructurtd pro~. rhe system.
public key encryption (PKE) A common c11cryrtion technique. bch referential Integrity ,\type o f valtd11y check. Refcm11tal mtt)\I iry i; a
user on the network ho <a patr of key" a ruhlic key and a pl'ivare key. set of rules that avoids dat11 """""' tcncy .111d qualtry prohlcm<.
Tbe public key encrypt> data thJt t11n be J <:<rypted wi1h the priv•te relational database A da1•base m which t;ihlc< a re rcl•tcd hy com
key. mon fields, crearjng a unified datJ mucrure that provi<lt• improved
qualitative risk analysis hJ luanni: ri~k by emmnri11g the probability data quallly and•«"''·
that it will occur :ind 1he d<!!l'l.'C ol unpact. rel<itional model A moocl U'>Cd'" rcl.mt:ltlal JniabJ<«. The rrb11onal
quality :anurM1ce (QA) A rr.x:cs' or prn<eJurc for m1mmi2ing errors model was inrroduced during the 1970< and 0«:.1mc porular because 11
•10d ensur<ng quah1y 1n produ•t>- Poor qualuy can re.ult from 1nnccu· w:n flexible and powerful .
rate reqwrrmtnb, de:)1gn problem\, coJ1ng error'-, tnulry relat;onships Enoblc ob1cc1> to co111111um<.t1c •n<l tnlerall .h they
documcn1a11on ••md mcfft:>.hvc tc<11ng. A Qi\ team re"•" s and tests all per-form the business fun<11ons .md ir.m<a<tu">n• rcquir<J by a sy\lem.
npplicrnons and sy>1cms ,hangts to verify <p.'C1ftca110"' and software Relauonsb1ps describe" h3t ob1rtt; oecJ to know about each other.
qu;ilt1) >tandard>. how ob1ccts tt>pond to <h.lDjtt1> 111 other ub)C<b, •nd the clta;ts of
quality attributes Su noo·fonc11on•I rrq111rcmcnis. 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 roamin1 .\ rrt,..... ,. th,11 -i11t)\\) \\-1rtln> i..lacnt'\ co 1110\C' lrt>nl tlnc
\tnnn "111 i.., 1mrkmrn1eJ .anJ thr 111111ni; ot tht rd.:.•""· Rd~ art J~\ J'<'lnl tn Jnothtr, JUIOtnJl'IC.lfl)' ~<-"lJllllf: >\llh !ht <rrnni;cr
rd.au\ th trc:qumt, •nd t.k:h rde•,... 1> 1r<'!1td •• • "'rrm protO<YJ'C .11..A.:O-' pnnt .JnJ all''""'"~ h>r un1ntc:rrupt~d "1'\h•.c .
th•I .an ht '"''rJ .anJ mod1hcd ' ntt<lcd. route,. .\ dfo,,..~ ch.it "'"'nc:"l'° nc'"''""l ~cnt,, Ja.:nn1nn chc rJ'kb.I
-l• control JOftw&n Arrlt-•1tOll\ th.lt .u.... n " .. tt to ulc dtk.imt 1bu r•rh. apJ l(UKk> rht tln\\ ol J.11.1.
mrr • u<n\ wod-t•non and rm• i<k "'M"'fl "nJ trnuM«hoonn~ sampl1111 .\ rm..n> \\hc:rr .111 nn.al)sr ~olk.;1' .,.. mrln nl .><:<II.ii d•><>
~I l"O"P \ ~t of~ or mott htkl• lh.11 '"" ocrur •ny number umnth, "'h... h .i1<1ld ""lutk rC\otJ.. rq><>rt'>. or .-.onou• fotn».
ol ton,.. 111 .a ..ngk m:••rd.. "'uh ...,h '""urrm..c h.1•m11 dtt!n-om ,-.u~ scal.lblficy \ 1hJr...irmu1 ot J '~"cm.1mpl)11ia thJ1 thr "'ccm 1Jn
....,Ort rooter .\prc•r. JI •ht md "'the fCJ'<lrt. '"" 1n..luck gr.and i.., C"J'•ndrJ. mud1hcJ, m dnwn.ucd c...1ly in mrcc rhc r.1rc.JI, ,h;ing-
mul\ tor nurncn.: field> Jnd ·~htr cnJ nl rcrnn onformmon. mg,,..., .... (If J bu>lll<..., mrerrrue.
,..port h4!•der Ari'<'•" .11 tht h<it1nntng of• rrr<>rt •nd 1dmniics rhc sat.ab!. The Jfl1lil) of J •)>rem co '"f"'"J 10 1111-.,t nrw bu>lll<"»
f<J'<lrt •• \\ tll J\ lh<: rcJ'<)rt llflc, .lilt', JnJ UCher n«:CS>'lty infomntioo. rrqurrt1nrn1' ;anJ \ttlurut'\.
requet ror pro~ (kFP) A "nncn l1>t uf tcaturcs ;i.od specifiQ- 10Jln1 on d•mand !he .1"1!11~ 10 mJ t<h flcl\\orl ""'"""co nttd<
lltlll\ fi!l\l"n tu r••9'J'n-l1\l" \t"OJtar, ht-torr. '\rn.1fh. rtt.x:ILk.t ()f' pl..:kagr: .ot ;any ~" .,, nmc: a f.,turt ol doud 1omrunnR. for cx.ompl<, dunug
h.- ~ ~l<'Ct<d . r<JI. luJd•, i1Jdll111n.ll .luud ••.'f'<r> lntghl U•llK' On fut<' •UluntJlh.;af!\
to <urron 1n. rt.a....J •rnrlln.aJ.._
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 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.
requ•,..,.,..,tl d4!fi111llon• A Jn..11rnon uf rhc '} -t<'ID rc.iulJTIDetlb
tr1lm 1hr u_\('r\ fl't-JUlt ol \IC". u.....uicK In an •Jill< rn>tn.1 • .a rcat.,.orfd c'Amrlc of ho,. u.cr. "111
requ1rTm4!nt1 4!heitatt0n Th< ,...,,.._, ol 11Jth.:·nflll: rtquircmcnts. Su
mrtra..., the 'Y"tcm.
\\.1th

r•.:di11dtn1t Kh4!dule r.... b11lcy \ rro1«;t .:~n h.c 1mrlc1n<·nrrJ on .111 ""'' pcablc
ttmt' frJmt.
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· Kh•ma The rnonrlr•c Jcl11111111n of. J.11JhJ,<. 111dud11•K Jr-..ripuom
VJrw•. 'urvry,, oh.crv.mon, .rnd <.1mrl1ni;, 111 dc'llnhc the currt"nr of .111 f1clJ<, rr..onl>. Jnd rrl.u1nn•h11"
'Y'lcm all(] 1Jcnnfy 1hc rcquir1'111cn" for 1ht new •)'tern. scroll bar In u<er 1111rrf.11.c tlt<ign, n Stroll liJr •llnw< 1he "'er to move
requlremenct planning ph;uo A 1ih.l'e 1hJ1 "m1hlnc' dtmems of rhe rhr<>u)lh 1hc ,l\ alf~bfe <hOM'\ fo1 ,Ill 111flut f1cfd.
'~Mtlll\ j)l,1111111114 and ~y,lrtll\ .111.it,,, ;, rh•'e' nf thr \Of (.. Scru"' A popul.1r tr.h11h1ur fur .1gll< pro1<•1 1m n11jlernr111. l>criveJ
requlrt'mentt •p4!ciflcatlon1 A Jc.crir11011of1hc •y>1cm require- frnm a ru111>1 11·nn In "'-rum, te.>m mcm!>rr. 11l.1y ''""'""role• .111J
ment\ Imm 1hc ,~n•ly\I "' cnginetnng 1,Jm\ ro1nr of \It\\. Lnter;u.'t 1n lnu:n\.C ~\>Ion~.

~h An imronJnc facr. findm~ 1c.;hn1quc rh.i mdude. die r.-.'icw second nonnal rorm (1NF) \ ra:<>nl JNi:n h 111l~F11ti1> in IM .mJ
ut 111urn•h. rcnoJ ...•I-. •nd r-....i., m uhu1n l-•.l11munJ utlurnunon, d •ll hdch !hJI .orr II<~ r.in of 1ht rom;ary kc) .Ire dcrcnJmt llCI rhc cnbrc
lr<bn1<.Jl nuicrul. Jnd nn-s Jb.JUI mJu\11') rrrnd, md dndopmcnn. 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
retponM I.Im• Tht o><rJll tunt l>ct"•= ~ tt<1unc for •r""•tm ann·t~
\\tth a rt11n.1ry ln rlut,., • • · • hdd "aucom.11.. •lly 111 .!:-.I.
: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 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
le) or d,..l,' "'"""' hunnn until the n-.iuc,1cJ "-<«n disrt..i 3ppe&n
or rnnreJ ourrut ,, rcaJ>. (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 .
recentlon p<tnod S..clUJ)' .ire •rurcJ tor J '!'<"-''"
r•'ttllbon period
RC\lnty HJrd,.•rt. «>ttw.orc, Jnd rroaJur•I cnnm•h th.ti ufcpurd
~h<1 "h1<.h 1hc1 art c11htr &.rro)-nl nr the l>••kup mcdu is reused.
JnJ rr<><t.I J >)'1nll •nd lh dJU from mrcrnal nt r.icrnJl thtc-JI\.
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 M!Wricy hole ( rr.11...J hv .a <umh1n.a11on of 01\C' or more 1n1rm1"'rh
rrvtl'\.I IO 1hc wul (<hC. 1the 111\t\tm<lll Jof the rru,....1. ROI. 110121 .:onhgurcJ "'" k.'l'>.
l>cttchb - toul •m••lfmul """ RC1lrity policy \ rbn rh.ar adJtt>-..t\ rhc rhrtt "'''" tlcm~nr. o( \\»
rem .._utll) 1 u1C1hJcn11Jl11-,. mtq:my.:and .11.11bl-1l11v.
""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 wcurity token \ rhl"""' Jc.... < 1lu1 au1ht111 ... .a1t>. kgt11m•1< "~..
rn...o..n11 "' puturmcJ at lo.:al '"'"" rathtr dun at a crn1nl loc:ttion. <U<=h '"' • ,man <Md e>r hyduon dt>-...c.
rKk An C\tnt th•t u>uld .1tlc.1 the rrottt-i llCJ;.>11\d) . selection A conttt>I 1tru"turc 1n m•,dul.1r dN-1~n. tt t\ tht c<tmplt·
.._...,.,II
riJtc \1ca-urn the hl.d1ho1>.J and •mJ'M.t of mJ.s.
cond1t1on.
mtJf(' rr,Jt.t,.~ 'UCplo b.a\C:J t>ft thC' rnuh, ul .1 (t'\l t}r
1100 Clt t\\tt t•r

rt>lc confrDI lk•clor> ufqtuJrJ, rh.i rcdo..r the hld1hood mJ


IMJ'.lt.I of n'l.'\.
.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
risk ldenaficadon I l\Mf: c::ich nd, anJ a1<""'"'!1 tht hkd1hood rh:n m~rkurt. 'M•nt<lllllc• <•lleJ \\th 3.0.
11 •ould •fleet • prof'""
sequence I ht «lmpklmn or '''1''
1n -cqucn11.1I nrJrr, nnc al1rr
rl•k man.1g.. m•nt The prn•.c" 111 i<lr1111ri '"II• .-,1fuJt1n11. 1ra,ku1g. another.
•1rul lnnll nll111g n'k' to rn1nh1117.\'. chr1r 11n1l.U;:c.
•cqul!nce check A 1ypc of Jarn •ahJorion dte\.k rlw "mrJ whcn thr
risk manaacmcnc plan Include• n rt• 1<w nf tht rro1c.::t'< <cope, stake- d.ua 111u\l hr ju 1to1nc prcJ1.•trtn1111(:d 'lt·c1urni.:t. II du,• 11,1.•r 1nu'1 tnttr
holder>, hudi:e1, ••hcdulc, anJ any mhtr 1mrrornl or C\lcmoJ factors. work nrdor. Ill m11ntr1cil -.c4ucncc. for example. then dn our or
th.11 111111111 .ifl«r 1hc rrot« •. Tiir 1>1.in •houl1l Jrfine 1iro1c.:1 roles and sequence onlcr number 111d1\.JI., an error. I( 1he uk'r 11111'1 cnrer
rnr<•11\1h1l11ir-. rl\k 1m11JJ1tmtnt n1eth11<h Jnd pmccdurt\, catcgoro« tr01n\;u.. tuH1\ thronol,~.Jlly, fhcn .11nn~.t«-"l1un ~tth .1n ouc·<,f-
of mk\, Jnd <OOllnflCllCV rlan\. scqumcr dare 1nd1Cdl<" Jn crmr.
risk ruponM plan A rroarn••, dfon tn :ann.ira1e J ful. .and d..-.cri.be sequ4!nce code •..;umbt:" ur kncn a"tllJlt-d 111 a '""'"''" orJc,
~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 ~lkf'k.C' «.1td('~ .. c.mt.at.n no aJJ1uun.iJ 1J1tornut1on 1>thc-r th.Jin .Jn i.nJ1-
th<: o>rr.1ll 1mr~a I') m~cn"I! • nfll<'I• and .1rrn'l'n•1< .acnon. 00<W1 ot or<kr "' tnlf) 1n10 • •>~ ·

............ _........ ..........,.a.w ............... ....-..c.......... ----...... - . .................. --,, ....... ,,.,,...............
• .,,,..,_ l!i:D"......,'--- ,• ._...__. ""' ........,... __.. .•........_ ...... .-.,.....nw...-... ..,..._._.,.., ...... .., .............
_..,~_
._..,...__.."'.....,.~
466 Glossary

sequence diagram A U.\11 d1JgrJm thJt show' t he 11miog of tr<m>ac- rtal<eholder An)Ollt who,. affecrcd hy 1hc <omp•n) \ p<"rfonnJncc,
oons lx-n.ce11 ob1r<:h •<the)' occur during <rtcm exccu11on. such as cusromcrs, employee<, suppl1e<', <tockhnldero, and members of
server Com purer on a chent/<cr»er d~1gn thot <upphe< data, process· the com.munit).
in~, .ind~" icn to i.:l1cnt \\ Ork~t.i1wn41, rtand~ne \'rhen P<'r>Onal <Omputcr. first apl'<'•rtd m l.t'll< num-
senke An •rphu11on th.it monuur•, or h>tms on.• p•mcular pon. hcrs in tM 1990, user.. found 1hat lhl') rnuld run their own ''°rd
processing. spreadsheet, and daiaro;,: •pph<.tllnn>, "'1bou1 assi.untt
service <!Mk A ~cntral11ed rt'><>Ur.c \Uficd hy Ir profes<iorutl• that from the IT group, in >mode CJlled '1Jnd-alonc <Ompuung.
provi<ks u~r< "uh the •uppon the) need to do their 1obs. Also called
help desl.. 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~.
service piack A mamttnan<< rcka"" •upph<J by wmmcrual wftware
<upplK'.rs. star network A network design with a central device •nd one or more
worksmions connected to 11 1n a "''> that forms a ;tar pJttern.
servke provider A firm that offer< nut)Our<mg solu11ons. Two popu·
lar out50urctng opnons mvol•·e \5Ps and firn" that offer IBSs. start day/date Thr d3) or Jate when J t>'~ 1s 'lhcdultd to hq:m.

servic.,.orien~ed A <ompan) that prtmarily offer. information or sta.te An ad1ccnve that d"'lenhc; an oh1c<t\ curn-nr >IJtU• (r.g.• a
<er'1ces or .ell< g<l<ids prodm:ed by othct\. srodenr could he• CURR F.:-.T. FUTURf, or rA~T m1den11,
significant digit code (.1phcr that do<ttngrnshc< items hy using a scnes state transition dlaeram Show< how an ob1e'1 <hangcs from one
of subgroups of d1g1t~. U.S. r ostal Servkc tip code>, for cJG1mplc, a rc srncc to another. depending on t he events 1h:rr •ffc..t the ob1eu.
sigmfic;int di11it cod es. status flag In ~tru"rured ..•prlu.:ati<>n de,·tlopnu.!rlt, Jn iu<lu:,ltor that
slmuladon A tire<> rehcar,al for mer. and Ir • uppurt su ff. Organiza· nllows one mod11lc to .;end• mes<.1ge II> '11101hcr module.
11011< typically include all procedure«, 'llch J• thmc tha t they execute storyboard In an agile pro1cct, a simple graph ic ori:ani1cr rhat helps
only ar rhe end of a month, quarier, o r year, 1n their simulations. sysrcnl:s annlysrs vi~ut\liz~ chc 1it:t 1u~ of.\ projcc.:t.
sink An cxrern:il cnnry chnt rcccavcs thua from un 1nfor111Jtion ~yste1n. strategic planning ·1 ht procc~s of 1clrn1ifymg l111111 1cm1 org.rniza·
site visit A trip to .1 phy>i<.1l loc,11io11 w observe (I system 111 use at tional goaJs. .srrarcgic'i~ nnd resource.
another loca tion. rtrateglc plans The long rnngc plans rhat define 1hc corporate mis-
slack time rhc amoum of nine hy which an e1•c111 can f>c lotc without sion and goal<. Typically defined hy 1op 111nnn11en1en1, w11h inpu1 from
all levels.
delaying the pro1ecr. The d ifference bc1wccn lnte>r completion tune
(LCTI anJ earlic\t wmrlcuon 11111e (ECI ). 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
soc-ial engineering An 1111ruder u\C\ ~<•llll 1ntrt.li.;11un Ct> N.un access
to • com11urcT 'Y'tcm. 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
soft skills Commun1canoM. 11ncrpcr<0na l skills. pcrccpnvc ab1hties.
and crmcal thinkmi: nrc wit •kill._ IT prolc;,1onJls mu>t haw so&
prOO!Sses. Also CJ lied an FDD.
"'111' •• wdl a. 1n.hn1<al ,kill> 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 infor-
software A program run hi rnmpu1r" for a 'p«1f1c fun<uon or 1ask.
mation sysrem. Proccs<es and dJt3 arc rreatcd "' <cpar•t• components.
Softwa,.., as a Service (SaaS) A model of •oftwJrc dcl1~ery m which
structured bralnstormin& A group d1...:u"1on "hen- ca<h p;amcipant
funcrionahl) is dcli1·cred on demand ~> .J nttwork·acccssiblc sen ice,
speaks when n rs hrs or her rum or p3'5es
r:nhcr than as a tradmonal sot"' are apphu11on th.it"' dmrnloadcd
and msralled on rhc cu'tomcr's computer. structured English A sub.ct of \landuJ I nghsh 1hat de"nbc. logical
J'Toce<SC' clCilrly and acrnr.ucly.
software encineerin1 \ )Off\1are Jc• clopmcnt process that srres~
solid design. tffr.:-ri1c 'rruaurt, ae,ut2tc Jocummt~tion, and careful Structured Query Laocuase (SQL) A qutl') langua1<c ch•t allow>
trsnng. PC users to communicate \\·1th stn·trs and n1a1n(ramt' computrrs.
software license J\ lei;al agrtrmcnl that gives use" the rrglu to use structured wal k-throush A "'""'' of a pro1c..1 tcJm memher\ worL.
the software under ccrr.11n rerm~ and condmons. by other memhc..., of the 1eam. C'.en<ralli. 'Y'tcms an.1l)'h rc•icw the
work oi o rher S)"Stems analy.rs, and programmer> rev1<\\ the 11ork of
software pacla1e Software that is pur,h.Jst-d or leased from another
ochre programmtrs, as a (mm ol pttr rrvoew, Stru.111rcd walk·1hroughs
firm. J\ comm<r~ially produ<cd w fl\\ art prod~t. or fanuly of products.
should rake pla"' 1hrolll\hour the SDI C and art CJllcd requirement<
software reengineerin1 U\e< .rnalylllJI te<hm11uei. 10 idennfy poten· revle'' ~,design review~. lode rcv1C\\'.). or tC)Ung review), df:-pt:ndmg on
tial qu•liry .ind (l<'rforninncc 11nprmcmc1m 1n on information sysrcm. 1he pha<e in which 1hey occur.
software vendor Company thnr develop>;,ofrwarc for >ale. stub testing J\ form of rcsnng '''here the pr~r.im1ncr s1n1ul.1rc' c<1ch
source An e•ccrna l ennry 1ha1supplies 1IJt.1 to ;111 informarion syscem . program outcome or result nnd displays n mcss:111c ro 1ndkatc whcrhcr
or nor rhe progr:un executed \Uc:cc,~full}. [ach )lllh rt.!prfi4!n~ Jn entry
source data automation 1\ popu1nr onli11.: input n1c-tho<l that <.:On1-
or exir point t h:u will be linked l.ucr m :inor her progrnm o r d"r.1 file.
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:inncrs. su bclass A further d1vi, ion of oh1ccu in n cl.l«. \uhcln,~c~ .ire more
specific caregorlcs \\r1thin n cln'li.
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 subordinate module A lo\i.rer-level n1otlule u1 a ~trul.ture <.:ha rt.
transaction. l)ur1ng th<" input dc.;ign ~tAKC, rou dcvclor ~ourcr docu- subschema A view cif the dnrnha<r U\cd hy one or more >)Sl<nh or
mc·nts th:lt Jre easy to corn piece nnd lncxpcn~i' c. users. A sullschema defines only thn<c pnrrinn' nl 1hc dntaha<e 1hn1 J
spiral model A development model w i1h a scrie• of iterations. or rcvi· particular >f>ltlll or uocr need, or 1> allowcJ to"""'~ ..
sions, based on u'er fccdbJ<k. subscription model A servict model th.u ,h.,11es J 'Jnablc le<: for an
spontaneous generation An unc,pln1ncd gcncr.111on of dJtn or mfor- apphanon basro o n 1hc numhcr of u<cn or worl.'t>llOn< that have
mauon. Wi1 h respect 10 OfO,, prncts>e' c.111101 ;pontancousl) acce;, to tbc appucauon.
gcneratt dJtn llo\\s-th<) mu\! h•vc an input ro ha.e an output. successor t.ask E:ich of rhc concurrent tJ.<ks of;> rrcdtces>-Or t,1sk.

~ .........._.. ... .., ..,.....e.... ...


~ :B)Jf....,..~ Al._.,._...,.._.._.,. "t..) •
~
ka.,-...i.'IUIJWll w""Jl'l.aflal.••'-*<lf .,...
......ih.,~•*...,.~~c....,,_~,
0.-••,..,.._.....,..:,._",...Alrllflilfl,,...,........,
......,...,. __ ........,~
-~,.._..,,.__.,....,.,.. ~,.~
.. -- .... ...,...,.......,.._....,.. ..
Glossary 467

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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~ --......
...........
468 Glossary

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

~- )U, -·~•-fllllie<'f•,... 0w.,,,.,,._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij


r..a...w...,..._...., ..I_,.. 4111.,.. .................,.t11ru
(....,..... J:gl( . . . . . -Woip-M ._..,..
..,...,.......,..~ ..
__.~~c.....,..~ .........,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Glossary 469

charact<r. Un1wdc rcquirl"S 16 b11, per charactc~ which allows 1t to user-centered A t<rm th.JI md1catc<, the pnmary ftx:u• is upon the
rcpr=nt more than 6~.000 unique ch•ucters. u~r. In a u5Cr·ccntercd sy<tem, the dmincuon blurs between mpur.
ourput. and tbt interfo«' it!>Clf
Unified M~linc Lancuace (UML) A widely used mcrhod of ..-1sual·
LLUl8 and do..umennn1t ;ofmarr '>''<rm design. U\{L u.e" user'> Stll.eholJ..r. ""'de and out>1de the i;ompani "hu "1ll 1nteracr
ob1c.:1-onemcd Jcs11tn wn..ept<. hm u is mdcpcndmt of any spcofic mth the S) <tern
programming language and can h..· u..nl to d~hc busan~ processes validity check A ryp<" of dJt.l validation check that 1s used for data
and rcqwtcnu:nr> gcncralh. 1rems that mU!.t tu\e ..:~man '.t.luc>. l·or eumple.1t an tn\enrory !ty~·
unlnterru.p tlbl• power supply (UPS) &ntery•po\\cred b:idup power rem ha< 10 v•hd 1t•m d""''• then an) input llt:m tlut doc< no< match
wun.:t th;ic en.J.hl("\ <>ptr.1uon~ cu (Onunue dur1n1t shorr ..rcnn p<>\vcr one o f rhe ,-ahd dJssc• will foil rhe check.
outage<, •nd iurgC>. validity rules Check\ that are •pphed ro daD elemenrs when d.1ra 1s
unit tutinc ~ l<'iflng of an ind1ndual program or module.~ <mered to cmure tlut the \'3lue entered 1> valid. for rumple,• »!tdJt)
ob1~thc 1> to 1den11fy and dmunatc e"ccucion error> thar could cause rule might require that Jn emploicc\ ;.1l.ir1 nmnbcr he "uhm the
the pmgram tn tcmunatt •hnornully •nd lo11ic errors that could have emploier< predefined ran~c for that po<inon.
l:><cn mmcd dunng dcik ch«k1ng. value-added "'seller (VAR) A fmn that cnhan<e> a <Ommetttal pack-
U niYersal Security Slot (USS) C.m he fastened t0 a c•blc lock or age hy addm1t cu;rom le•wrrs •nd wnfigur111i:; 11 for a panicular
laptop at.rm. mduscry.
unnormalized A re~.cud th:it t:.onr31n' ;t repeaung group, which means. v..nion control The proc•>S of trnckmi: si·stcm releases.
th.1t a >1ngle record h,,, multiple oc.urrcncc~ of a parncular fidd, w-1th vertial applic.atlon A •<>ftware pJckai;c that hu> been developed to
each o..-.:urrencc ha\•mg difforem v•lue.. bandle mformauon rcqu1rcmc1m for a ;pcc1lic t)pc of bu<ine<S.
unstructured b r ainstorming A group discussion where any partici· vertlal system A sy<tcm dc<igncd to ntret the unique requirements
pant l.lll ~1>e:tk ru Jll) 111nt. o f 3 specific bu;ines> or industry, such ll~ a wcb·based retailer or auro-
usability In mer 11urrfocc dc;ign, include< """r
•ati•facuon, •upport suppl) store.
for businc_, fu1mion~. nnd ~y>tcm cffect1vcncss. vir tual private networl( (VPN) U>e' a pu bl1c network 10 conncc1
usability m<!trlcs Darn thar mrcrfoce dC'lignen cun obrnin by using remote users securely. Allows n rtmme chenr m u<e n spccin l key
M>ft\\<Jtc that CJ.I\ rt."r..ord .ind 1nc3i.urc u..cr 1nreracr1on.s \\'Uh the- .sy!rlotC.-m4 exchange thJ1 mu-;t 1"' authenllcJt«I by the VP!".
usaee model Set• tran>ac1 ion model. vulnerability A ~e<.:urity \\il'JL1u.>~~ or ,oft ~1'>(>1.

use case description A dc-.nption in UMI ch•r documents the name waterfall model !'he tradmon.ll modcl of •oftwarc dc,dopment.11
graph tl1at depicts t he rc;ult of each SO I C pha<c flowing down 1oto
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 the next pha"".
docr1puon; •nd a;;urnp11011,. W eb 2.0 A sc.;ond 11enera11on ol the \\cb thJt enJbb people 10 col-
laborate, mtcracr, and •harc mfornuuon much more dynamically,
use ca.se dla1r~m A \l)UJ.I rcpr('\.entarton thdr 1llu')ltd.tCS th~ tnrcrac-
based on conrinuouslv ••~LIJblc u;cr •pphcauoni ucher 1han sraric
tion between uier. and the mformauon •y•rem m UML
HTML web pJJ.ih. lnterJUl>r expcneri.;e "a h.tllmarL of Web 2.0.
use a.se Reprei<nts the nc~ in a •pccific busin~ funcnon or proass
webast A onc-"'*'Y rr.1n,m1ss1on of 1n£orm.;auon or rr.11n1ng marcr1~
ID U)',1L.
such as a Web1nar ~''°"· a,·J1'3hk on dtmlnd or for a spcctftc pcnod
uffr appllatlon l'ro1:um, th•t uuhic StJnd.1rd busin~s software. to onlinc panic1pants
•u...h •; M1Cro..oft Olh~e, "h1ch ha< been configuttd 1n a specific man·
web-centric A ..tr•t<g) or aprroa~h tlut cmrlume< a high dqtrtt of
ocr to enhance u;cr produ.tt\lty.
mtcgranon with other wrl>-h.ivcd ~on1roncnt,. A wrl>-cmrnc arch1t«·
user deslcn phaM In th" pha\C, u...,n interact with si >temS :malis" mre follow• Internet M'11\ll protocol, and enables a compani' ro
md de' dop moJd, and pro1orypes th21 repr~m aU <ysrem procases. 1nlqtralc 1hc nC"w applu;auon uuo It\ t<nntmcn.t' ~fr.Jtqt).
output>, •nd input<
we.binar An lntrmt't·h~\td 1ra1n1ng "tt'.S\1on 1hat rrov1des ;in 1n1tr-.ac·
user documentation ln~rruct10n\ and 1nfonnanon ro users "'ho WJll nvc c~iienmcc. The word u't'bm.ir comlun~ rhe words u1'b and
mteracr '"th the si;tem. Includes u<er manuals. help screens, and sn,uniJr.
cutoriah.
weight An llllporta.nt multtpUe:r that n1.lnajtt" f:h. .tor inro csr1n1;,ire-11; 'o
us<!r interlace (U I) fhe mcch•msm 1hrough "h1ch the u5C'r intcratts thei can be analyzed.
with the 'Y"Cm. The mtcrfocc can 1-e graphical, te•ru31, aun1l, or 3
w hat-if analysis A kJturc of hu<me'< iupporr <yitem' thnr allows
combmntion of different modC'I of 1ntcr:icrion. analy>i> to define anJ J"ount for a wide vancty of 1'SU<> lindudmg
user Interface Jn,Judt" ...:rcen,, C<)n11nands. controls. and features issue' not rnmplctdy drfmcd).
thlt enoble u!>Crs to 1111erJct more cffow .. dy w11h an apphca11on. wide area network (WAN) A network <panning long d1<rancc< rhat
u1<!r productivity syotems Applirn11ons thar l'rovide employees of all can link users who are <ontinenrs aparr.
lo"d< a wide arr.1y of cools m m1provc 1nb performance. fxamples W i·fi A lliance A 11onpro f11 imcrnatlnn:tl .1>so.:1orion formed in J 999
include ctnail, word proi:es'iing, grnph1c~. and ccunpan) intraotb. 10 eenily m1ewpernh1lity of wirclc" 11rrwor~ p roduct< ha<cd on IEEE
user rights U><r·•peufk privilei:es t hot determine che type of acce>s a 802.11 specifirntions.
u<cr hn, to a d ata ha«, file, or dirc<1ory. Al<o Cll lled permission<. W I-Fi P rotected A ccess (WPA) A common method used to secure a
user stories In nn agile pro1oct, a «'I of more rtfincd rcquiremcms wireless network. Tht' .1ppro.1ch re4u1rc~ e.\l..h wircle'" client be con·
dcmcd from fc.iturc;. figured manual!) to use a special, prc·~hnrcd ~ey, rather than kei pairs.
user story In agile development, J ;hon, >imple requiremcnrs ddini· The most recent nnd more secure \tri1on 1s WPA2.
t1on pro\ 1Jcd h) the 4-U\tUrne-r. Pro~r:tmn1et\ U\e u-.er !.tnrlh to wild A web-b.tsetl r<)X»itor) ol 111formn11<>n 1hnt •nyone c.tn n.:c..,,,,,
dctcrm1nc a prOfC'~l·~ rcqu1rcmcnr~. prtor1n~ nnd ~ope. con1r1bute 10, or mod1f1.
user trainfnc packace The m31n oh1cmvc of a u~r training package W i-Max IH~ H02. lfl <r<:<1f1<aflon<, which ore c><p<"Ctro to enable
1s to ;how u~rs ho\\ the s~-stem can help them perfonn their jobs. wireless multtmedia •pphca11on> wuh n r.rni:e of up to 30 miles.

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
...................
"->-"'Allf'W
__....
~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
~~·~----···---~~-.,.-"~ --......
...........
470 Glossary

W ired Equivalent PrlVllcy (WEP) Onr of rhe r.orltcst methods used work breakdown structure (WBS) A proJclt hrol en down onto•
to ""'urea wire)..,., nrtwork, >Upcr...,J•d b) WPA and WPA2. sen es of smaller tasks. Su alsn Gantt chart: PERT/CPM chan.
wireless access point (WAP) A central wirelt-> de' re.- that worst-case estimate: The most pess1m1stk outcomr.
pro' 1Ms nctworl.. ;er> ICC> 10 wircie>S chenh. 1\1,0 c•llcd an access WPA2 A "irckss se<:Urit) srand.ud bdscd on 802.1 l 1 th•t pro• ,.le, a
point. 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·
wireless lldellty (Wl·Fl) I Jmil) ul popular I[f.E I.AN w1rcb> net·
rclaoon ~twc<n rwu v>.nablcs. Alw callrd a "-•tl•r diaf,Um.
worlmq,\ standards. aho kno" n J> 802.11, mdudmg 802.1 la, b. g, and
Yl K issue A problem f._.d b1 many form, in the )·cu 2000 heuu"'
n. 802.11 n is the most recent .iandard. 802.1 bc and 802. I bd are
rbeir computer sysr.-ms used only rwo d1gm to rcrrcsenr rhc year: most
proposed new standards. d3res no\\ use a four-d11v1 form,lt for tilt" 1·CJr (YYYY.\1\IDD t.
wireless foul area network (WLAN) A " 1rclr•s network ttiar,. Yovrdon A t}fX' of >ymbol SCI that" used m l)l·l)s. l'roe<<sc<, d•t•
rclan,dy mcxpcr1>1\'e to install and " well suued to workgroops and Row s, da1a store<., and external rnntir< each ha Ye a unique ~ymbol m
u!.er~ who .ire not :.n~hott:d tt• ;i \ipt."<.:tfi(. d~l: or loc:111on. 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 server, 325
l:~l, 280 software, 5
lNF. See first normal form (I NF) systems architecture, 319
2NF. See second normal form (2NF) application development, 356-359
3NF. See chird normal fonn (3NF) agile, 357, 367-369
4GL. See fourth-generation language (4GL) object-oriented, 364-367
802.J J, 338 structured,356-357,359-364
802.11 ac, 339 system design review, 356
802.1lb,338 tasks, 356-357
802.1 li,427 tools, 357-359
802. J Jn, 338 application lifecyclc management (ALM), 24
application service provider (ASP), 208-209,
331
A applications programmer, 408
abbreviation codes, 298 Apprivo, 89
absolurc date, 304 archived, 4 12
acceptance, 421 Ars Techn ica, 126
acceptance rc~t~, 372 artificial inrelligencc, 15
access poinr, 339 ASCII, 303
action codes, 299 ASP. See application service provider (ASP)
activity, 78. See also task asset, 420
activity diagram, 193- 194 associative entity, 282
actor, 187 ASTQB foundation level certification, 441
adaptive maintenance, 404, 406 ATNl. See automatic teller machine (ATM)
adnurustrator account, 430 attack, 421
agile methods, 17, 18,22-24, 113-114.Seealso attributes, 183, 276, 365
agile mechods audit fields, 305
advantages and disadvantages, 114 audit log files, 305
application developmenr, 357, 367-369 audit trails, 245, 257
auchorization zone, 246
Airbnb, 8
Alexa (Amazon.com), 15 automated fax, 253
automatic teller machine (ATM ), 254, 332
alias, 164
automatic update service, 430
allocated baseline, 4 14
ALM. See application life C)•cle management (Au\.i) availability, 4 J 9
a,roidance, 421
alphabetic codes, 298
Ama1on.com, l 5, 53
Amazon Echo Dot, I 5
app,8 B
Apple, 15, 207, 229-230, 425 B2C (busine~s-ro-consumcr), 8
Apple Keynote, 386 back door a track, 422
Apple's rind My iPhone app, 425 backup,305,435-437
Apple's iOS, 232 backup media, 435
Apple's Mac OS X, 415 backup policy, 435-436
Apple Xco<le, 370 balancing, 159, 160-163
application, 319 bandwidth, 329, 4 16-417
logic, 147,325 baseline,414
~ecuriry, 429-432 Basic Service Ser (SSS), 339

471

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ··----~~-.,.-"~ ...........
472 Index

barch, 254 skills, systems analysts, 30


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

(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Index 473

class, 21, 184-185 construction phase, I I I


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
474 Index

curover phase, 11 I documenting data stores, J66


CybcrEthics, 442 documenting enritie~, 167
cybcrterrorist, 422 documenting processes, 167
documenting record~, 167- 168
reporrs, 168
structure chart~, 363
D dara element, 164, 303
data, 3, 5 data entry ~reen, Ui.er interface!.,
anal)'sis, preliminary invesrigarion, 65- 67 240-243
control, 305 d ata flow. 147-149
conversion, 382-383 di verging, 157
couple, 360 d ata flow diagrams (DFDs), 19, 13 I ,
frames, 337 146-152
item, 303 drawing, 152-154
legacy, 6, 324 drawing structure charts, 362-363
mart, 30 I examples in creating, l 54- 158
mining, 302 symbols, 146-152
normaliza rion, 284- 297 using symbols, 152
processing cencer, 32 1 data item, l 64
securiry, 257 data manipulation language (OM L), 2 73
strucrure, 269 data replication, 43 7
tesr, 371 d ata repository, 164. See also dara dictiona ry
type check, 244 d ata score, 149. See also data dictionary
validation rule, 243-245 d ata store symbol, DFDs, 149- 151
warehouse, 30 I data strucrures, 164
web-based, design, 274-275 d ares, storing, 304
data and process modeling, 144- 176 OBA. See database administrator (OBA)
data dicuonaries, 164- 168 D B,:\15. See database management sysrem
D FDs. See data flow diagram (DFD) (DBMS)
process descripc1on cools, 169- 175 DDB~1S. See distributed dJrabasc managemenr
darabase admi nisrranon, 28 system (DDBt-lS)
dacabase administrator (OBA), 272 DDOS. See distributed denial of service
darabase managemenr S)'Stem ( DB ~I S), (DDOS)
271-274 d ecision table, 170-174, 358-359
componenrs, 272-274 mulriple outcomes, 172-174
darabase programmer, 408 one condition, 170
daca center, 5 three conditions, 171-172
dara design, 268-307 two condi rions, J 71
codes, 297-300 decision tree, 175, 358-359
concepts, 269-272 decomposing, 159
da ta control, 305 d efault value, 165, 236
dara storage and access, 30 1-304 d efect tracking softwa re, 374
DBMSs, 27 l-274 delivera ble, 19
entity-relationship diagrams, 280-284 d enia l of service (DoS), 422, 4 28
example, 269-27 1 d ependent tas k, 83
normalization. See normali1ation d erivat ion codes, 299
term inology, 275- 279 d esign prowryping, 259
web-based, 274- 275 d esign reviews, 87
data dictionary, 164- 168 d esk checking, 370
documenting data flows, 165- 166 d esktop computer, securiry, 4 24
Index 475

dee ai I report, 251 duration, 82


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

espionage, 420 file, 269, 276


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

(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Index 477

GoToMyPC (Cicrix), 401 lDE. See integrated development


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
478 Index

integration testing, 372 ]IT. See just-in-time (jlT )


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

J
JAD. See joint application development (jAO)
M
Java, 22, 181, 367
JDBC (Java database conncctivit)'), 274 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:-..•~-".....-""'*"....,.._...,.. ..
Index 479

mail bombing, 422 Microsoft Excel, 47, 93, 170, 207, 41 7


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
480 Index

network, 426 offsiting, 435


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

(....,..... 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 preliminary investigation, 20, 60-69


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

.........""_.. ....-................. _..__


("..,_..., llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
482 Index

project management (Co11ti1111ed) range check, 244


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

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~---tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Index 483

ream-based technique~, 108-114 SCM. See supply chain management (SCM)


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
484 Index

slack time, 87 stratified sa m pie, 125


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


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

.........""_.. ....-................. _..__


("..,_..., llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ·· · ---~~-.,.- " ~ ...........
486 Index

technical knowledge, systems analysts, 29-30 Train the Trainers, inc., 19 J


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

(....,..... J:gi( . . . . . I_,.. 4111.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
Index 487

usage model, 209 version control, 4 12-4 13


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

.........""_.. ... .-................. _..__


("..,_...,llll!O( ...... . . - - . .\) ....... ~
................... --......
"->-"'Allf'W ~- ...............,.. o-....._ ...... _ ... ,..,...,...,~..,._.. .............. ~..
__.... ~~·~---- ···---~~-.,.-"~ ...........
488 Index

work breakdown structure (WBS) (Continued) x


displaying, 81 - 82 XP. See Extreme Programming (XP)
factor~ affecting durarion, 80-81 XY chart, 66
identifying ta~k~, 78-80 Microsoft Excel, 93
Microsoft Project, 91
workgroup software, 14
workplace, impact, 439 y
worst-ca~e e~rimate, 79
WPA. See \V1-l-t Protected Access (WPA ) Y2K issue, 304
WPA2, 428 Yourdon, l 46

(....,..... J:gi( . . . . . I_,.. 41 11.,.. ~- )U, -Woip-M ._..,.. -·~•-fllllie<'f•,... 0w.,,,.._.._,..."-,.._..,.,_,.,_.,....,. -~--- tfta111&....-.~~ij
r..a...w...,..._...., .. .................,.t11ru ..
..,...,.......,..~ __.~~c.....,..~ ........ .,..,. .. ._.,.,.,.......c:-..•~-".....-""'*"....,.._...,.. ..
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........
c.,,..-•~fftlllll'.._...,
t.M..wl'"_._......,lhll..., A11t1.-RNr-a
~....,...._,..
~ ••'-Nf'911...._.....-..,....WIL""'t..ikor•,.,
. .,......., ...... ~..,-. ....... ,.., •
.,.,...,1.._.....,~ c~~".._.._...._.,,..
.._....,~ ,.W«t.., •
""'°..................
w~...t~.._., ._....._,~,.,
.. __ ..,............ .._ ..., ..........

You might also like