figures part 2

ELECTRONIC TRANSPARENCIES

D I S K 2

ELECTRONIC TRANSPARENCIES

DISK 2

MODERN SYSTEMSANALYSIS

AND DESIGNJeffrey A. Hoffer • Joey F. George • Joseph S. Valacich

BTHE BENJAMIN/CUMMINGS PUBLISHING COMPANY, INC.

READING, MASSACHUSETTS • MENLO PARK, CALIFORNIANEW YORK • DON MILLS, ONTARIO • HARLOW, U.K. • AMSTERDAMBONN • PARIS • MILAN • MADRID • SYDNEY • SINGAPORE • TOKYO

SEOUL • TAIPEI • MEXICO CITY • SAN JUAN, PUERTO RICO

Executive Editor: Michael PayneSenior Acquisitions Editor: Maureen AllaireAssistant Editor: Susannah DavidsonMarketing Manager: Melissa BaumwaldProduction Editor: Teresa ThomasCover Design: Yvo RiezebosArt Supervisor: Karl MiyajimaArtist: Mark KonradSenior Manufacturing Coordinator: Merry Free OsbornCover art: La belle jardinière, 1939, by Paul Klee, oil and tempura on burlap, Kuntsmuseum Berne, Paul-Klee-Stiftung; ©1996 ARS, New York/VG Bild-Kunst, Bonn.

USA Group, Inc., Atkinson Construction, Allison Engine Company, McHenry County,IVI Publishing, Consensys Group, and Albertson’s Inc. are not affiliated with TheBenjamin/Cummings Publishing Company, Inc.

Copyright © 1996 by The Benjamin/Cummings Publishing Company, Inc.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system,or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording,or any other media or embodiments now known or hereafter to become known, without theprior written permission of the publisher. Manufactured in the United States of America.Published simultaneously in Canada.

ISBN 0–8053–2484–4

BThe Benjamin/Cummings Publishing Company, Inc.2725 Sand Hill RoadMenlo Park, CA 94025http://www.aw.com/bc/is/

CONTENTSDisk 2

Part V Logical Design

Chapter 13 Designing Forms and Reports

Figure 13-8a Contrasting customer information forms (Pine Valley Furniture): Poorlydesigned form

Figure 13-8b Contrasting customer information forms (Pine Valley Furniture):Improved design for form

Figure 13-9 Customer account status display using various highlighting techniques(Pine Valley Furniture)

Figure 13-10a Contrasting display of textual help information: Poorly designed form

Figure 13-10b Contrasting the display of textual help information: Improved design forform

Figure 13-11a Contrasting the display of tables and lists (Pine Valley Furniture): Poorlydesigned form

Figure 13-11b Contrasting the display of tables and lists (Pine Valley Furniture):Improved design for form

Figure 13-12 Tabular report illustrating numerous design guidelines (Pine ValleyFurniture)

Figure 13-14a How scaling can bias the meaning of information: No bias in scaling

Figure 13-14b How scaling can bias the meaning of information: Non-zero bottom ofscale

Figure 13-14c How scaling can bias the meaning of information: Too high top of scale

Chapter 14 Designing Interfaces and Dialogues

Figure 14-2 Specification outline for the design of interfaces and dialogues

Figure 14-5 Various types of menu configurations

Figure 14-7a Contrasting menu designs: Poor menu design

Figure 14-7b Contrasting menu designs: Improved menu design

Figure 14-9 Example of form interaction in the Netscape™ World Wide Webbrowser

Figure 14-11 Paper-based form for reporting customer sales activity (Pine ValleyFurniture)

Figure 14-12 Computer-based form reporting customer sales activity (Pine ValleyFurniture)

Figure 14-13a Contrasting the navigation flow within a data entry form: Proper flowbetween data entry fields

Figure 14-13b Contrasting the navigation flow within a data entry form: Poor flowbetween data entry fields

Figure 14-15a Contrasting help screens: Poorly designed help display

Figure 14-15b Contrasting help screens: Improved design for help display

Figure 14-16 Hypertext-based help system from Microsoft’s Visual Basic

Figure 14-19 Dialogue diagram illustrating sequence, selection, and iteration

Figure 14-21 Highlighting graphical user interface design standards

Figure 14-22 State-transition diagram for spell checker

Chapter 15 Designing Databases: Logical Data Modeling

Figure 15-3a Simple example of logical data modeling: Highest volume customerquery screen

Figure 15-3b Simple example of logical data modeling: Backlog summary report

Figure 15-3c Simple example of logical data modeling: Integrated set of relations

Figure 15-3d Simple example of logical data modeling: Conceptual data model andtransformed relations

Figure 15-3e Simple example of logical data modeling: Final set of normalizedrelations

Figure 15-6 Relation with redundancy

Figure 15-7 EMP COURSE relation

Figure 15-8 Steps in normalization

Figure 15-9 EXAMPLE relation

Figure 15-10 Table with repeating data

Figure 15-11a Removing transitive dependencies: Relation with transitive dependency

Figure 15-11b Removing transitive dependencies: Relations in 3NF

Figure 15-13a Representing a 1:N relationship: E-R diagram

Figure 15-13b Representing a 1:N relationship: Relations

Figure 15-14a Representing an M:N relationship: E-R diagram

Figure 15-14b Representing an M:N relationship: Relations

Figure 15-15a Two unary relationships: EMPLOYEE with Manages relationship (1:N)

Figure 15-15b Two unary relationships: Bill-of-materials structure (M:N)

Figure 15-18 Hoosier Burger inventory usage report

Figure 15-19 E-R diagram corresponding to normalized relations of Hoosier Burger’sinventory control system

Part VI Physical Design

Chapter 16 Designing Physical Files and Databases

Figure 16-4 Example code look-up table (Pine Valley Furniture)

Figure 16-5a Examples of referential integrity field controls: Referential integritybetween relations

Figure 16-5b Examples of referential integrity field controls: Referential integritywithin a relation

Figure 16-7a Possible denormalization situations: Two entities with one-to-onerelationship

Figure 16-7b Possible denormalization situations: A many-to-many relationship withnonkey attributes

Figure 16-7c Possible denormalization situations: Reference data

Figure 16-9a Comparison of file organizations: Sequential

Figure 16-9b Comparison of file organizations: Indexed

Figure 16-9c Comparison of file organizations: Hashed

Figure 16-10a File recovery approaches: Forward recovery

Figure 16-10b File recovery approaches: Backward recovery

Figure 16-12 Example hash file layout and size

Figure 16-14a Database architectures: Hierarchical

Figure 16-14b Database architectures: Network

Figure 16-14c Database architectures: Relational

Figure 16-14d Database architectures: Object-Oriented

Figure 16-15 Data volume chart

Chapter 17 Designing the Internals: Program and Process Design

Figure 17-3 Special symbols used in structure charts: (a) Data couples and controlflag; (b) Conditional call of subordinates; (c) Repetitive calls ofsubordinates

Figure 17-3 Special symbols used in structure charts: (d) Pre-defined module;(e) Embedded module

Figure 17-4a How to read a structure chart: Non-overlapping arrows

Figure 17-4b How to read a structure chart: Overlapping arrows

Figure 17-5 A transaction-centered system design

Figure 17-6 A central transform in a data flow diagram

Figure 17-7 A transaction center in a data flow diagram

Figure 17-9 The top-level structure chart derived from the data flow diagram inFigure 17-8

Figure 17-11 Complete first refinement of the structure chart from Figure 17-9

Figure 17-13 PVF Purchasing Fulfillment System data flow diagram with centraltransform circled

Figure 17-14 Top-level structure chart for the PVF Purchasing Fulfillment System

Figure 17-15 Refined afferent branches for the PVF Purchasing Fulfillment Systemstructure chart

Figure 17-16 Refined central transforms and efferent branch for the PVF PurchasingFulfillment System structure chart

Figure 17-19 Example of data coupling

Figure 17-20 Example of stamp coupling

Figure 17-21 Example of control coupling

Figure 17-22a Examples of communicational cohesion: Example of a communicationalcohesion module

Figure 17-22b Examples of communicational cohesion: Example of a communica-tionally cohesive module split into two functionally cohesive modules

Figure 17-24 Pseudocode description of Calculate New Balance module

Figure 17-25 Basic symbols in Nassi-Shneiderman charts

Figure 17-26 The contents of the module Calculate New Balance in the form of aNassi-Shneiderman chart

Chapter 18 Designing Distributed Systems

Figure 18-2 Outcomes and deliverables from designing distributed systems

Figure 18-3 File server model

Figure 18-4 File servers transfer entire files when data are requested from a client

Figure 18-5 Client/server architecture transfers only the required data after arequest from a client

Figure 18-7 Customer relation for a bank

Figure 18-8 Horizontal partitions: (a) Lakeview Branch; (b) Valley Branch

Figure 18-9 Part relation

Figure 18-10 Vertical partitioning of Part relation: (a) Engineering; (b) Manufacturing

Figure 18-13a Types of client/server architectures: Distributed presentation

Figure 18-13b Types of client/server architectures: Remote presentation

Figure 18-13c Types of client/server architectures: Remote data management

Figure 18-13d Types of client/server architectures: Distributed function

Figure 18-13e Types of client/server architectures: Distributed database

Figure 18-13f Types of client/server architectures: Distributed processing

Part VII Implementation and Maintenance

Chapter 19 System Implementation: Coding, Testing, and Installation

Figure 19-2 Steps in a typical code walkthrough

Figure 19-3 Comparing stub and integration testing

Figure 19-4 Test case description form

Figure 19-5 Test case results form

Figure 19-7a Comparison of installation strategies: Direct installation

Figure 19-7b Comparison of installation strategies: Parallel installation

Figure 19-7c Comparison of installation strategies: Single location installation (withdirect installation at each location)

Figure 19-7d Comparison of installation strategies: Phased installation

Figure 19-8 Schein’s three-stage model of the change process

Chapter 20 System Implementation: Documenting the System, Training,and Supporting Users

Figure 20-3a Outlines of user’s guides from various popular PC software packages:Microsoft Access™

Figure 20-3b Outlines of user’s guides from various popular PC software packages:WordPerfect™ for Windows 6.0

Figure 20-3c Outlines of user’s guides from various popular PC software packages:CA Simple Tax 1993

Figure 20-4 Traditional information system environment and its focus on systemdocumentation

Figure 20-5 End user information system environment and its focus on userdocumentation

Figure 20-6 Frequency of use of computer training methods

Figure 20-7 A Microsoft Cue Card™ for Microsoft Access™

Chapter 21 Maintaining Information Systems

Figure 21-5 Types of maintenance

Figure 21-7 Quality documentation eases maintenance

Figure 21-8 How the mean time between failures should change over time

Figure 21-9 Flow chart of how to control maintenance requests

Figure 21-11 How Total Quality Management differs from Business ProcessRe-engineering

Figure 13-8a Contrasting customer information forms (Pine Valley Furniture): Poorly designed form


Vague title

Hard to read: information is packed too tightly

No navigation information

No summary of account activity

Figure 13-8b Contrasting customer information forms (Pine Valley Furniture): Improved design for form


Clear title

Clear navigation information

Easy to read: clear, balanced layout

Summary of account information

Figure 13-9 Customer account status display using various highlighting techniques (Pine Valley Furniture)


Font size, intensity, underlining, and italics

All capital letters

Intensity differences

Boxing

Figure 13-10a Contrasting the display of textual help information: Poorly designed form


Vague title

Fixed, upper-case text

Hyphenated between lines and abbreviated

Single spacing

Figure 13-10b Contrasting the display of textual help information: Improved design for form


Clear title

Mixed case

Spacing between sections

Figure 13-11a Contrasting the display of tables and lists (Pine Valley Furniture): Poorly designed form


Single column for all types of data

Numeric data is left-justified

No column labels

Figure 13-11b Contrasting the display of tables and lists (Pine Valley Furniture): Improved design for form


Clear and separate column labels for each data type

Numeric data is right-justified

Figure 13-12 Tabular report illustrating numerous design guidelines (Pine Valley Furniture)


Northwest & Mountain Midwest & Mid-Atlantic New England

Baker Hawthorne Hodges Franklin Stephenson1 Swenson Brightman Kennedy

999-99-9999999-99-9999999-99-9999

999-99-9999999-99-9999999-99-9999

999-99-9999999-99-9999

Quarterly Actual SalesRegion Salesperson SSN First Second Third Fourth

195,000 220,000 110,000

110,000 75,000

110,000

250,000 310,000

146,000 175,000 95,000

120,000 66,000 98,000

280,000 190,000

133,000 213,000 170,000

170,000 80,000

100,000

260,000 270,000

120,000 198,000 120,000

90,000 80,000 90,000

330,000 280,000

Place meaningful labels on all

columns and rows

Alphabetic text is left-justified

Use a meaningful

title

Box the table data to improve the appearance

of the table

Pine Valley Furniture Salesperson Annual Summary Report, 1995

January 10, 1996 Page 1 of 2

1. Sales reflect May 1, 1995 – December 31, 1995.

Superscript characters can be used to alert

reader of more detailed information

Sort columns in some meaningful order (names are sorted

alphabetically within region)

Long sequence of alphanumeric data

is grouped into smaller segments

Right-justify all numeric data

Try to fit table onto a single page to help in making

comparisons

Figure 13-14a How scaling can bias the meaning of information: No bias in scaling


Thou

sand

s

FourthThirdSecondFirst

30

25

20

15

10

5

0

Normal Scale – Bottom of Scale = 0 Top of Scale = near maximum value

Figure 13-14b How scaling can bias the meaning of information: Non-zero bottom of scale


Thou

sand

s


30

25

20

15

10

Biased Scale – Bottom of Scale = 10,000 Top of Scale = near maximum value

Figure 13-14c How scaling can bias the meaning of information: Too high top of scale

Copyright © 1996 by The Benjamin/Cummings Publishing Company, Inc-

Thou

sand

s


100

80

60

40

20

0

Biased Scale – Bottom of Scale = 0 Top of Scale = too much greater than maximum value

Figure 14-2 Specification outline for the design of interfaces and dialogues


Design Specification

Narrative overview a. b. c. d. e. Interface/Dialogue Designs a. b. Testing and Usability Assessment a. b. c.

1.

2.

3.

Interface/Dialogue Name User Characteristics Task Characteristics System Characteristics Environmental Characteristics Form/Report Designs Dialogue Sequence Diagram(s) and Narrative Description Testing Objectives Testing Procedures Testing Results i) ii) iii) iv) v)

Time to Learn Speed of Performance Rate of Errors Retention Over Time User Satisfaction and Other Perceptions

Figure 14-5 Various types of menu configurations


Single Menu

Linear Sequence Menu

Multi-Level Tree MenuMulti-Level Tree Menu with Multiple Parents

Multi-Level Tree Menu with Multiple Parents and Multi-Level Traversal

(Adapted from Sheiderman, 1992)

Figure 14-7a Contrasting menu designs: Poor menu design


SYSTEM OPTIONS 01 02 03 04 05 06 ENTER OPTION (01):__

ORDER INFO ORDER STATUS SALES PERSON INFO REPORTS HELP QUIT

Vague title

Vague command names

All upper-case letters

Vague exit statement

Two-key selection

Common options are not separated and

assigned a standard key

Figure 14-7b Contrasting menu designs: Improved menu design


Customer Information SystemMain Menu

1234

90

Type option number (1):__

Query Information on a Specific OrderCheck Status of a Specific OrderReview Sales Person InformationProduce Order and Sales Reports

HelpExit to DOS

Clear Title

Descriptive commandnames with

mixed-case letters

Clear exit statement

One-key selection

Common options are separated and

assigned a standard key

Figure 14-9 Example of form interaction in the Netscape™ World Wide Web browser


Figure 14-11 Paper-based form for reporting customer sales activity(Pine Valley Furniture)


Header

Body

Authorization

Totals

Sequence and Time Information

PINE VALLEY FURNITURE

Sales Invoice

INVOICE No. Date:

SOLD TO:

SOLD BY:

Customer Number: Name:

Address: City:

Phone:

Customer Signature: Date:

State: Zip:

Product Number Description

Quantity Ordered

Unit Price

Total Price

Total Order Amount Less Discount____%

Total Amount

Figure 14-12 Computer-based form for reporting customer sales activity(Pine Valley Furniture)


Figure 14-13a Contrasting the navigation flow within a data entry form: Proper flow between data entry fields


Figure 14-13b Contrasting the navigation flow within a data entry form: Poor flowbetween data entry fields


Figure 14-15a Contrasting help screens: Poorly designed help display


Figure 14-15b Contrasting help screens: Improved design for help display


Figure 14-16 Hypertext-based help system from Microsoft’s Visual Basic


Figure 14-19 Dialogue diagram illustrating sequence, selection, and iteration


Sequence

Iteration

Selection�

Display A

Display B

Display D

Display C

Display E

Figure 14-21 Highlighting graphical user interface design standards


File menu item is always the first item (if present)

Check mark shows that an item is selected or a mode is turned

No checkmarks indicate that a command will be executed if selected

Ellipsis (...) shows that a pop-up menu will appear if selected

Display text prompt for all menu items

Edit menu item is always the second item (if present)

Window menu item is always second from last item (if present) Help menu item is always

last item (if present)

Right arrow ( ) shows that an item leads to a submenu

(1) Load Spell Checker

(2) Display Spell Checker

(3) Initiate Spell Checking

(5) Close Spell Checker

(4) Completed or Suspend Checking

Open and Checking

Closed

Open, but Idle

Figure 14-22 State-transition diagram for spell checker


Figure 15-3a Simple example of logical data modeling: Highest volume customer query screen


HIGHEST VOLUME CUSTOMER ENTER PRODUCT NO.: START DATE: END DATE: – – – – – – – – – – – – – – – CUSTOMER NO.: NAME: VOLUME:

M128 11/01/93 12/31/93 1256 Commonwealth Builder 30

This inquiry screen shows the customer with the largest volume total sales of a specified product during an indicated time period.

Relations: CUSTOMER (CUSTOMER NO., NAME) ORDER (ORDER NO., CUSTOMER NO., ORDER DATE) - - - - - - - - - - - - - - PRODUCT (PRODUCT NO.) LINE ITEM (ORDER NO., PRODUCT NO., ORDER QUANTITY)

Figure 15-3b Simple example of logical data modeling: Backlog summary report


BACKLOG SUMMARY REPORT 11/30/93

PAGE 1

BACKLOG QUANTITY

PRODUCT NO.

B381 B975 B985 E125

M128

0 0 6 30 2

ÉÉ

This report shows the unit volume of each product that has been ordered less that amount shipped through the specified date. Relations: PRODUCT (PRODUCT NO.) LINE ITEM (PRODUCT NO., ORDER NO., ORDER QUANTITY) ORDER (ORDER NO., ORDER DATE) SHIPMENT (PRODUCT NO., INVOICE NO., SHIP QUANTITY) INVOICE (INVOICE NO., INVOICE DATE)

.

..

.

..

Figure 15-3c Simple example of logical data modeling: Integrated set of relations


CUSTOMER (CUSTOMER NO., NAME)PRODUCT (PRODUCT NO.)INVOICE (INVOICE NO., INVOICE DATE)ORDER (ORDER NO., CUSTOMER NO., ORDER DATE)LINE ITEM (ORDER NO., PRODUCT NO., ORDER QUANTITY)SHIPMENT (PRODUCT NO., INVOICE NO., SHIP QUANTITY)

Figure 15-3d Simple example of logical data modeling: Conceptual data model and transformed relations


ADDRESS INVOICE NO.

SHIP QUANTITY

PRODUCT NO. DESCRIPTION

CUSTOMER NO. NAME

ORDER QUANTITY

LINE ITEM

SHIPMENT

Places Bills

ORDER

PRODUCT

CUSTOMER INVOICE

ORDER NO.

Relations: CUSTOMER (CUSTOMER NO., NAME, ADDRESS) PRODUCT (PRODUCT NO., DESCRIPTION) ORDER (ORDER NO., CUSTOMER NO.) LINE ITEM (ORDER NO., PRODUCT NO., ORDER QUANTITY) INVOICE (INVOICE NO., ORDER NO.) SHIPMENT (INVOICE NO., PRODUCT NO., SHIP QUANTITY)

Figure 15-3e Simple example of logical data modeling: Final set of normalized relations

CUSTOMER (CUSTOMER NO., NAME, ADDRESS)PRODUCT (PRODUCT NO., DESCRIPTION)ORDER (ORDER NO., CUSTOMER NO., ORDER DATE)LINE ITEM (ORDER NO., PRODUCT NO., ORDER QUANTITY)INVOICE (INVOICE NO., ORDER NO., INVOICE DATE)SHIPMENT (INVOICE NO., PRODUCT NO., SHIP QUANTITY)

Figure 15-6 Relation with redundancy


Figure 15-6

EMPLOYEE2

EMPID NAME DEPT SALARY COURSE DATE COMPLETED

100 Margaret Simpson Marketing 42,000 SPSS 6/19/9X100 Margaret Simpson Marketing 42,000 Surveys 10/7/9X140 Alan Beeton Accounting 39,000 Tax Acc 12/8/9X110 Chris Lucero Info Systems 41,500 SPSS 1/12/9X110 Chris Lucero Info Systems 41,500 C++ 4/22/9X190 Lorenzo Davis Finance 38,000 Investments 5/7/9X150 Susan Martin Marketing 38,500 SPSS 6/19/9X150 Susan Martin Marketing 38,500 TQM 8/12/9X

Figure 15-7 EMP COURSE relation


EMP COURSE

DATEEMPID COURSE COMPLETED

100 SPSS 6/19/9X100 Surveys 10/7/9X140 Tax Acc 12/8/9X110 SPSS 1/22/9X110 C++ 4/22/9X190 Investments 5/7/9X150 SPSS 6/19/9X150 TQM 8/12/9X

Figure 15-8 Steps in normalization


Remove Repeating

Groups

Remove Partial

Dependencies

Remove Transitive

Dependencies

Table With Repeating

Groups

First Normal Form

Second Normal Form

Third Normal Form

Figure 15-9 EXAMPLE relation


EXAMPLE

A B C D

X U X YY X Z XZ Y Y YY Z W Z

Figure 15-10 Table with repeating data


Figure 15-10

EMPLOYEE2

DATE EMPID NAME DEPT SALARY COURSE COMPLETED

100 Margaret Simpson Marketing 42,000 SPSS 6/19/9XSurveys 10/7/9X

140 Alan Beeton Accounting 39,000 Tax Acc 12/8/9X110 Chris Lucero Info Systems 41,500 SPSS 1/12/9X

C++ 4/22/9X190 Lorenzo Davis Finance 38,000 Investments 5/7/9X150 Susan Martin Marketing 38,500 SPSS 6/19/9X

TQM 8/12/9X

Figure 15-11a Removing transitive dependencies: Relation with transitive dependency


SALES

CUST NO. NAME SALESPERSON REGION

8023 Anderson Smith South9167 Bancroft Hicks West7924 Hobbs Smith South6837 Tucker Hernandez East8596 Eckersley Hicks West7018 Arnold Faulb North

Figure 15-11b Removing transitive dependencies: Relations in 3NF


(b) Relations in 3NF

SALES1

CUST NO. NAME SALESPERSON – – – – – – – – – – –8023 Anderson Smith9167 Bancroft Hicks7924 Hobbs Smith6837 Tucker Hernandez8596 Eckersley Hicks7018 Arnold Faulb

SPERSON

SALESPERSON REGION

Smith SouthHicks WestHernandez EastFaulb North

Figure 15-13a Representing a 1:N relationship: E-R diagram


NAME

ADDRESS

CITY STATE ZIP

DISCOUNTCUSTOMER NO.

ORDER DATE

PROMISED DATE

ORDER NO.

CUSTOMER

ORDER

Places

Figure 15-13b Representing a 1:N relationship: Relations


CUSTOMER

CUSTOMER NO. NAME ADDRESS CITY STATE ZIP DISCOUNT

1273 Contemporary Designs 123 Oak St. Austin, TX 38405 5%6390 Casual Corner 18 Hoosier Dr. Bloomington, IN 45821 3%

ORDER

ORDER NO. ORDER DATE PROMISED DATE CUSTOMER NO. – – – – – – – – – – –57194 3/15/9X 3/28/9X 639063725 3/17/9X 4/01/9X 127380149 3/14/9X 3/24/9X 6390

Figure 15-14a Representing an M:N relationship: E-R diagram


ORDER DATE

PROMISED DATE

ORDER NO.

ORDER

DESCRIPTION ROOM

PRODUCT NO.

(Other Attributes)

PRODUCT

QUANTITY ORDERED

Requests

Figure 15-14b Representing an M:N relationship: Relations


ORDER

ORDER NO. ORDER DATE PROMISED DATE

61384 2/17/9X 3/01/9X62009 2/13/9X 2/27/9X62807 2/15/9X 3/01/9X

ORDER LINE

QUANTITY ORDER NO. PRODUCT NO. ORDERED

61384 M128 261384 A261 1

PRODUCT

(OTHER PRODUCT NO. DESCRIPTION ATTRIBUTES)

M128 Bookcase —-A261 Wall unit —-R149 Cabinet —-

Figure 15-15a Two unary relationships: EMPLOYEE with Manages relationship (1:N )


NAME BIRTHDATEEMP ID

EMPLOYEE

Manages

Figure 15-15b Two unary relationships: Bill-of-materials structure (M:N )


NAME

QUANTITY

COSTITEM NO.

ITEM

Contains

Figure 15-18 Hoosier Burger inventory usage report


INVENTORY USAGE REPORT Page x of nfor Sales Date 1–Date 2 Date Printed

REGULAR DATECONSUMPTION

PRODUCT NO. DESCRIPTION USED REGULAR HOOSIER TOTAL

xxx aaa — — —bbb — — —ccc — — —¶ ¶ ¶ ¶

yyy — — — —— — — —— — — —¶ ¶ ¶ ¶

¶

Figure 15-19 E-R diagram corresponding to normalized relations of Hoosier Burger’s inventory control system


Sale Date Invoice DateReceipt No. Invoice No.

Vendor No. Paid?

Product Description

Product No.

Sells

Is Sold on

Orders

Is Ordered onIs Received for

Received on

Includes

Is Included on

Quantity Added

Quantity Sold

Quantity Used

Quantity in StockType

of Item

Minimum Order Quantity

Item Description

Item No.

Regular Product No.

Hoosier Product No.

HOOSIER PRODUCT

REGULAR PRODUCT

RECIPE

ITEM SALE

PRODUCT

INVOICE ITEM

INVENTORY ITEM

INVOICESALE

MEAL

IS-A IS-AMeal

Quantity

Figure 16-4 Example code look-up table (Pine Valley Furniture)


PRODUCT FILE

PRODUCT NO. DESCRIPTION FINISH …

B100 Chair CB120 Desk AM128 Table CT100 Bookcase B� � �

FINISH LOOK-UP TABLE

CODE VALUE

A BirchB MapleC Oak� �

Figure 16-5a Examples of referential integrity field controls: Referential integrity between relations


CUSTOMER (CUSTOMER_ID, CUST_NAME, CUST_ADDRESS,...)↖CUST_ORDER (ORDER_ID, CUSTOMER_ID, ORDER_DATE,...)

and CUSTOMER_ID may not be null since every order must be for some

existing customer

Figure 16-5b Examples of referential integrity field controls: Referential integrity within a relation


EMPLOYEE (EMPLOYEE_ID, SUPERVISOR_ID, EMPL_NAME,...)

and SUPERVISOR_ID may be null since not all

employees have supervisors

Figure 16-7a Possible denormalization situations: Two entities with one-to-one relationship


CAMPUS ADDRESS

STUDENT-ID APPLICATION- ID

APPLICATION DATE

SubmitsQUALIFICATIONSTUDENT

SCHOLARSHIP APPLICATION

FORM

Normalized relations: STUDENT (STUDENT-ID, CAMPUS-ADDRESS, APPLICATION-ID) APPLICATION (APPLICATION-ID, APPLICATION DATE, QUALIFICATIONS, STUDENT-ID) Denormalized relation: STUDENT (STUDENT-ID, CAMPUS-ADDRESS, APPLICATION DATE, QUALIFICATIONS) and APPLICATION DATE and QUALIFICATIONS may be null (Note: We assume APPLICATION-ID is not necessary when all fields are stored in one record, but this field can be included if it is required application data.)

Figure 16-7b Possible denormalization situations: A many-to-many relationship with nonkey attributes


ADDRESS CONTRACT NAME

ITEM

VENDOR-ID ITEM-ID

PRICE QUOTE

PRICE

DESCRIPTION

VENDOR

Normalized relations: VENDOR (VENDOR-ID, ADDRESS, CONTACT NAME) ITEM (ITEM-ID, DESCRIPTION) PRICE QUOTE (VENDOR-ID, ITEM-ID, PRICE) Denormalized relations: VENDOR (VENDOR-ID, ADDRESS, CONTACT NAME) ITEM-QUOTE (VENDOR-ID, ITEM-ID, DESCRIPTION, PRICE)

Figure 16-7c Possible denormalization situations: Reference data


INSTR-ID WHERE STORE

ITEM-ID

DescirptionDESCRIPTIONCONTAINER TYPE

ITEMSTORAGE INSTRUCTIONS

Control for

Normalized relations: STORAGE (INSTR-ID, WHERE STORE, CONTAINER TYPE) ITEM (ITEM-ID, DESCRIPTION, INSTR-ID) Denormalized relation: ITEM (ITEM-ID, DESCRIPTION, WHERE STORE, CONTAINER TYPE)

Figure 16-9a Comparison of file organizations: Sequential


Start of file

Scan

. . .

. . .

. . .

Aces

Boilermakers

Devils

Flyers

Hawkeyes

Hoosiers

Miners

Panthers

Seminoles

Figure 16-9b Comparison of file organizations: Indexed


Key(Hoosiers)

B D F H L P

F P Z

R S Z

Miners

Panthers

Seminoles

Devils

Aces

Boilermakers

Flyers

Hawkeyes

Hoosiers

Figure 16-9c Comparison of file organizations: Hashed


Relative Record Number

. . .

. . .

Miners

Hawkeyes

Aces

Hoosiers

Seminoles

Devils

Flyers

Panthers

Boilermakers

Key(Hoosiers)

Hashing Algorithm

Figure 16-10a File recovery approaches: Forward recovery


TransactionsTransactions Transactions

BackupBackup BackupError

introducedDiscover

error

Time

Restore this backup

Rerun all these transactions after correcting problem that caused error

Figure 16-10b File recovery approaches: Backward recovery


Transactions

Error introduced

Discover error

Time• Reverse effects of transactions • Correct problem that caused error • Rerun all these transactions

Figure 16-12 Example hash file layout and size


Track = 4000 bytes�

Blo

ck n

umbe

r

Was

ted

spa

ce16

0 by

tes

Tra

ck n

umbe

r

048

1216202428323640

123456789

1011

Record = 240 bytes Record block960 bytes

Wasted block

File characteristics Record length = 240 bytes Number of records = 172 Blocking factor = 4 Track length = 4000 bytes

Figure 16-14a Database architectures: Hierarchical


Figure 16-14b Database architectures: Network


Figure 16-14c Database architectures: Relational


RELATION 1 (PRIMARY KEY, ATTRIBUTES...) RELATION 2 (PRIMARY KEY, FOREIGN KEY, ATTRIBUTES...)

Figure 16-14d Database architectures: Object-Oriented


Object Class 1

Attributes

Methods

Object Class 2

Attributes

Methods

Object Class 3

Attributes

Methods

Figure 16-15 Data volume chart


(3)

(2)

(6)(3)

(80%)(20%)

RECIPEMEAL

SALE

ITEM SALE

PRODUCT

781,200

260,400

HOOSIER PRODUCT

INVOICE

INVOICE ITEM

INVENTORY ITEM

REGULAR PRODUCT

IS-A IS-A

4,340

8,680

6 18

30

24 144 21

Figure 17-3 Special symbols used in structure charts


(c) Repetitive calls of subordinates

(b) Conditional call of subordinates

(a) Data couples and control flag

Make C

AError

making C

B C

Get C

Figure 17-3 Special symbols used in structure charts (continued)


(e) Embedded module

(d) Pre-defined module

Figure 17-4a How to read a structure chart: Non-overlapping arrows


VA

VA

VA

C CVB

VB

VB

A A BB

Read A

Get Valid B

Validate A

Make C

Read B

Put C

Validate B

Boss

Get Valid A

Legend:

VA – valid A

VB – valid B

VA

VA

VA

C CVB VB

A A B B

Legend:

VA – valid A

VB – valid B

VB

Read A

Validate Data

Make C

Read B

Put C

Boss

Get Valid A

Get Valid B

Figure 17-4b How to read a structure chart: Overlapping arrows


Process Savings Deposit

Process Savings

Withdrawal

Process Checking Deposit

Process Checking

Withdrawal

Process Car Loan Payment

Process Transaction

Figure 17-5 A transaction-centered system design


Get Valid

A

Make C

Print C

Report

Source 1

Get Valid

B

Source 2

Sink

A

B

CC

Report

Valid B

Valid A

Figure 17-6 A central transform in a data flow diagram


Validate T1

Process Payment

Source 1

Validate T2

Source 2

Sink 2

T1

T2

Payment Out 2

Process Deposit

Sink 1Deposit Out 1

Process Withdrawal

Sink 3Withdrawal Out 3

Valid T2

Valid T1

Process Transaction

Figure 17-7 A transaction center in a data flow diagram


Figure 17-9 The top-level structure chart derived from the data flow diagram in Figure 17-8


VA

VA

C CVB VB

Legend:

VA – valid A

VB – valid B

Make C

Put C

Boss

Get Valid A

Get Valid B

Figure 17-11 Complete first refinement of the structure chart from Figure 17-9


VA

VA

VA

C CVB

VB

VB

A A BB

Legend: VA – valid A VB – valid B FCR – formatted report

Read A

Validate A

Make C

Read B

Validate B

FCR

FCR

C

Format C Report

Print C Report

Boss

Get Valid A

Get Valid B

Put C

1.0

Forecast Material Needs

6.0

Order Materials

4.0

Select Preferred Supplier

Supplier Material

Evaluations

Criteria

Preferred Supplier

Bill of Materials

Production Schedules

Production Capacities

Order

Suppliers

Suppliers

5.0

Produce Bill of

Materials

3.0

Develop Purchased

Goods Specs

Production Schedulers

2.0

Plan Purchase

Agreements

Engineering

Price & Term Quotes

Material Forecasts

Material Specifications

Product Design

Supplier Description

Figure 17-13 PVF Purchasing Fulfillment System data flow diagram with central transform circled


Figure 17-14 Top-level structure chart for the PVF Purchasing Fulfillment System


A

B

C

D

E

CF G

H

F

H

G

D

E

B

A

Develop Purchased

Goods Specs

Put Materials Orders

Purchasing Fulfillment

System

Get Supplier

Data

Plan Purchase

Agreements

Get Material

Data

– price & term quotes – supplier material evals. – material specs – production schedule

– material forecasts – supplier description – criteria – product design

Legend:E F G H

A B C D

Figure 17-15 Refined afferent branches for the PVF Purchasing Fulfillment System structure chart


Supplier quotes

Supplier material

evals

Supplier quotes

Supplier material

evals

Material forecasts

Material specs

Production schedule

Material forecasts

Material specs

Production schedule

Production capacities

Material forecasts

Get Material Specs

Get Production Schedule

Get Material

Data

Get Supplier

Data

Get Supplier Quotes

Get Material

Forecasts

Calculate Material

Forecasts

Get Production Capacities

Get Supplier Material

Evaluations

Figure 17-16 Refined central transforms and efferent branch for the PVF Purchasing Fulfillment System structure chart


Product design BOM

Supplier description

Material specs

Order

Supplier description

Product design

Criteria

Production schedule

Production schedule

BOM

Preferred supplier

Supplier

description

Criteria

Supplier Material

evals

Price & term quotes

Material forecasts

Generate Order

Put Order

Plan Purchase

Agreements

Criteria

Product design

Develop Purchased

Goods Specs

Select Preferred Supplier

Produce Bill of

Materials

Put Materials Orders

Figure 17-19 Example of data coupling


Amount paid

Current balance

New Balance StatusEOF New

charges

Prepare Customer

Bill

Calculate New

Balance

New balance

Amount paid

New charges

Format Customer Bill

Prepare Customer Bill

Calculate New Balance

CUSTOMER RECORD

New balance

Formatted billCUSTOMER

RECORD

Figure 17-20 Example of stamp coupling


Figure 17-21 Example of control coupling


Prepare Customer Bill

Calculate Amount Due

Write “amount is 30 days past due”

Figure 17-22a Examples of communicational cohesion: Example of a communicational cohesive module


Part name

Part cost

Part supplier

Find Part Details

Part #Using part-# find part-name find part-cost find part-supplier

Figure 17-22b Examples of communicational cohesion: Example of a communicationally cohesive module split into two functionally cohesive modules


Part name

Part cost

Find Part Cost

Part # Part name

Part supplier

Find Part Supplier

Part #

Figure 17-24 Pseudocode description of Calculate New Balance module


(Note: The data couple Status has three values, 1, 2, and 3. The value 1 corresponds to“credit,” 2 to “nothing due,” 3 to “amount due.”)

Module name: Calculate New BalanceReceives: Current-balance, New-charges, Amount-paid, EOFReturns: New-balance, Status

Set New-balance, Status to 0Read Current-balance, New-charges, Amount-paid, EOFRepeat

New-balance = Current-balance + New-charges – Amount-paidBeginif

If New-balance < 0Then Status = 1Else

BeginifIf New-balance = 0Then Status = 2Else Status = 3Endif

EndifReturn New-balance, Status

Until EOF = YES

Figure 17-25 Basic symbols in Nassi-Shneiderman charts


Sequence

Conditional statement

Do-while loop

Do-until loop

Case statement

condition

1 2 3 4

Figure 17-26 The contents of the module Calculate New Balance in the form of a Nassi-Shneiderman chart


Set New-balance to 0

Set Status to 0

Read Current-balance, New-charges, Amount-paid, EOF

New-balance = Current-balance + New-charges – Amount-paid

New-balance < 0

Yes No

Yes No

New-balance = 0

Status = 2

Status = 1

Status = 3

Return New-balance, Status

Until EOF = YES

Figure 18-2 Outcomes and deliverables from designing distributed systems


1.

2.

3.

4.

Description of Site (for each site) a. b. c. d. e. Description of Data Usage (for each site) a. b. c. d. Description of Business Process (for each site) a. b. Contrasts of Alternative IS Architectures for Site, Data, and Process Needs (for each site) a. b. c. d.

geographical information physical location infrastructure information personnel characteristics (education, technical skills, etc.) … data elements used data elements created data elements updated data elements deleted list of processes description of processes pros and cons of no technological support pros and cons of non-networked, local system pros and cons of various distributed configurations …

Figure 18-3 File server model


Data

File server

Client Client

Client

• Requests for data • Requests to lock data

• Entire file of data • Lock status

Client • Process/scan tables • Application program – user interface – database processing – generate queries • Handle integrity and security • Full DBMS

File Server • File storage • Record locking • Acts like extra hard disk to client • Not very busy • Significant LAN traffic

Local Area Network

Figure 18-4 File servers transfer entire files when data are requested from a client


ServerClient

File Server Architecture

Entire file sent to client

Client request for data

Figure 18-5 Client/server architecture transfers only the required data after a request from a client


ServerClient

Client /Server Architecture

ONLY result of request

Client request for data

Figure 18-7 Customer relation for a bank


ACCT NO. CUSTOMER NAME BRANCH NAME BALANCE

200 Jones Lakeview 1000324 Smith Valley 250153 Gray Valley 38426 Dorman Lakeview 796500 Green Valley 168683 McIntyre Lakeview 1500252 Elmore Lakeview 330

Figure 18-8 Horizontal partitions



200 Jones Lakeview 1000426 Dorman Lakeview 796683 McIntyre Lakeview 1500252 Elmore Lakeview 330

(a) Lakeview Branch


324 Smith Valley 250153 Gray Valley 38500 Green Valley 168

(b) Valley Branch

(a) Lakeview Branch

(b) Valley Branch

Figure 18-9 Part relation


PART NO. NAME COST DRAWING NO. QTY ON HAND

P2 Cap 100 123-7 20P7 Lead 550 621-0 100P3 Spring 48 174-3 0P1 Clip 220 416-2 16P8 Body 16 321-0 50P9 Gripper 75 400-1 0P6 Eraser 125 129-4 200

Figure 18-10 Vertical partitioning of Part relation


PART DRAWING NO. NO.

P2 123-7P7 621-0P3 174-3P1 416-2P8 321-0P9 400-1P6 129-4

PART NO. NAME COST QTY ON HAND

P2 Cap 100 20P7 Lead 550 100P3 Spring 48 0P1 Clip 220 16P8 Body 16 50P9 Gripper 75 0P6 Eraser 125 200

(a) Engineering

(b) Manufacturing

Figure 18-13a Types of client/server architectures: Distributed presentation


FUNCTION CLIENT SERVER

Data management All data management

Data analysis All data analysis

Data presentation Data for presentation on Data delivered to client server are reformatted using server presentation for presentation to user technologies

Figure 18-13b Types of client/server architectures: Remote presentation




Data analysis All data analysis

Data presentation Data from analysis on server are formatted for presentation to user

Figure 18-13c Types of client/server architectures: Remote data management




Data analysis Raw data from server are retrieved and analyzed

Data presentation All data presentation

Figure 18-13d Types of client/server architectures: Distributed function




Data analysis Selective data from server Selective data from server retrieved and analyzed retrieved and analyzed,

then transmitted to client

Data presentation All data presentation, from analyses on both server and client

Figure 18-13e Types of client/server architectures: Distributed database



Data management Local data management Shared management of data on server

Data analysis Data retrieved from both client and server for analysis


Figure 18-13f Types of client/server architectures: Distributed processing



Data management Local data management Shared management of data on server

Data analysis Data retrieved from both Data retrieved from client and server for server for analysis, thenanalysis sent to client for further

analysis and presentation


Figure 19-2 Steps in a typical code walkthrough


(Adapted from Yourdon, 1989)

GUIDELINES FOR CONDUCTING A CODE WALKTHROUGH1. Have the review meeting chaired by the project manager or chief

programmer, who is also responsible for scheduling the meeting,reserving a room, setting the agenda, inviting participants, and so on.

2. The programmer presents his or her work to the reviewers. Discussionshould be general during the presentation.

3. Following the general discussion, the programmer walks through thecode in detail, focusing on the logic of the code rather than on specifictest cases.

4. Reviewers ask to walk through specific test cases.5. The chair resolves disagreements if the review team cannot reach

agreement among themselves and assigns duties, usually to theprogrammer, for making specific changes.

6. A second walkthrough is then scheduled if needed.

Figure 19-3 Comparing stub and integration testing


System

MakeGet Put

Final integration

testing

Initial integration

testing

Stub testing

Figure 19-4 Test case description form


Pine Valley Furniture CompanyTest Case Description

Test Case Number:Date:Test Case Description:

Program Name:Testing State:Test Case Prepared By:

Test Administrator:

Description of Test Data:

Expected Results:

Actual Results:

(Adapted from Mosley, 1993)

Figure 19-5 Test case results form


Pine Valley Furniture CompanyTest Case Results

Test Case Number:Date:

Program Name:Module Under Test:

Explanation of difference between actual and expected output:

Suggestions for next steps:

(Adapted from Mosley, 1993)

Figure 19-7a Comparison of installation strategies: Direct installation


Current System

New System

Install New System

Time

Figure 19-7b Comparison of installation strategies: Parallel installation


Current System

New System

Install New System

Time

Figure 19-7c Comparison of installation strategies: Single location installation


Current System

New System

Install New System

Location 1

Current System

New System

Install New System

Location 2

Figure 19-7d Comparison of installation strategies: Phased installation


Current System

New Module 1

New Module 2

Install Module 1

Install Module 2

Current System Without Modules 1 & 2

. . .

. . .

. . .Current System

Without Module 1

Figure 19-8 Schein’s three-stage model of the change process


Stage 1: Creating motivation and readiness to change through Unfreezing disconfirmation; creation of guilt or anxiety; provision

of psychological safety

Stage 2: Helping employees to see things, judge things, feel Changing Through things, and react to things differently based on a new Cognitive Restructuring point of view

Stage 3: Helping employees to integrate the new point of Refreezing view into their personal view and into their local

organizational relationships(Adapted from Schein, 1987)

Figure 20-3a Outlines of user’s guides from various popular PC software packages: Microsoft Access™


MICROSOFT ACCESS HELP CONTENTS

Help Features What’s New

Using Microsoft AccessStep-by-step instructions to helpyou complete your tasks.

Cue CardsThe online coach that helps youlearn Microsoft Access as you doyour work.

General ReferenceGuides to menu commands,keyboard shortcuts, toolbars, andwindows and answers to commonquestions.

Language and Technical ReferenceComplete reference informationabout properties, actions, events,objects, and the Access Basiclanguage.

Technical SupportAvailable support options so thatyou can get the most fromMicrosoft Access.

Figure 20-3b Outlines of user’s guides from various popular PC software packages: WordPerfect™ for Windows 6.0


CONTENTS

Welcome to WordPerfect 6.0 for Windows Help

To find information, choose from the following items. To search forinformation and to move through Help, use the buttons along the top ofthe Help window.

Choose For information about

Search (Index) topics listed alphabeticallyHow Do I performing tasksGlossary meanings of termsMenu Commands features by menusWordPerfect Bars topics by Feature Bar, Power Bar, Ruler Bar, Button

Bar, and Status BarKeystrokes keystrokes and templatesWhat’s New features new to WPWinOther Products other WPCorp products

Using Help how to use Help

Figure 20-3c Outlines of user’s guides from various popular PC software packages: CA Simple Tax 1993


CONTENTSGetting Started

Using the InterviewStep by Step Overview

Tax Return FilesOpening a Taxpayer FileCreating a New Taxpayer FileRetrieving a Tax Return From Last YearSaving Your Tax ReturnRenaming Your Tax Return FileErasing a Tax Return File

Completing Your Tax ReturnSelecting Forms, Schedules and WorksheetsEntering DataDeleting Data from a FormMini-WorksheetsItemized ListLinking Between FormsTax SummaryRecalculating Your ReturnVerifying Your Return

Importing Data from Other ProgramsImporting Data from ASCII FilesImporting Data from Lotus FilesImporting Data from Quicken FilesImporting Data from CA-Simply MoneyImporting Tax Exchange Format (TXF) Files

Tax PlanningTax ForecastingWhat IfUsing CA-Simply Tax for Keeping Records

Printing Your Tax ReturnSelecting a PrinterPrinting a Complete ReturnPrinting Selected FormsPrinting Selected Itemized ListsPrinting Current Form, Schedules and Itemized ListsPrinting Multiple CopiesPrinting Multiple Tax ReturnsPrinting 1040PC FormatPrinting to Disk

Special FunctionsUsing Automatic Timed BackupTax Deadline AlarmTax Form and Tax Category LocatorShoeBox

Filing Your ReturnFiling By MailFiling Electronically

Getting Ready to Complete State TaxesCreating State Resource FileGoing to the State Tax Program

TroubleshootingEfile Troubleshooting

Figure 20-4 Traditional information system environment and its focus on system documentation


Training

User Analyst/ Programmer

Computer System

Operations

System Documentation

Program Documentation

Data File

Programs

Routine Report

Requests

(Adapted from Torkzadeh and Doll, 1993)

Figure 20-5 End user information system environment and its focus on user documentation


User Interactive Software

Computer System

Consultation

Application- Oriented User

Documentation

End-User Tool Manual

Database

Programs

Training

(Adapted from Torkzadeh and Doll, 1993)

Figure 20-6 Frequency of use of computer training methods


Interactive Training Manuals

5%CAI 12%

Course 10%

Tutorial 7%

Help Components

10%

Resident Expert 51%

External 5%

(Nelson & Cheney, 1987)

Figure 20-7 A Microsoft Cue Card™ for Microsoft Access™


CUE CARDS

Do your own work as you learn. Cue Cards can walk you through common Microsoft Access tasks step by step.

What do you want to do?Build a Database with TablesBuild a database; create, import or attach tables.Work with DataAdd, view, edit, sort, or filter data in forms and datasheets.Design a QueryCreate or troubleshoot queries.Design a FormCreate or customize forms.Design a Report or Mailing LabelsCreate, customize, or print reports or mailing labels.Write a MacroDesign, run, or attach macros.I’m Not SureShow me what a database is and what I can do with it.

To read about Cue Cards and how to use them, see About Cue Cards.

>

>

>

>

>

>

>

▲

Figure 21-5 Types of maintenance


Corrective

Adaptive

Perfective

Preventive

Percentage of the Maintenance Effort

Mai

nten

ance

Type

0 20 40 60 80

Non-Value Adding

Value Adding

(Adapted from Andrews and Leventhal, 1993)

Figure 21-7 Quality documentation eases maintenance


400

300

200

100

Norm 0

–100

Perc

ent C

hang

e in

Mai

nten

ance

Effo

rt fro

m N

orm

Normal maintenance effort required for average documentation quality

Poor AverageDocumentation Quality

High

400

200

125

75

300 –15

–35 –48 –50–80

(Adapted from Hanna, 1992)

Figure 21-8 How the mean time between failures should change over time


Aver

age

Days

Bet

wee

n a

Failu

re

1 2 3 4 5 6

Months Since System Was Installed

25

20

15

10

5

0

Figure 21-9 Flow chart of how to control maintenance requests

Adaptation Enhancement

Other Error

Very Not very

Kill Do

Evaluate, Categorize, Prioritize

Evaluate, Categorize

Inform Requester Prioritize

TOP Priority

Evaluate, Categorize, Prioritize

Select next task from

Top of Queue

Type?

Type?

Severity

Action

Change Request

(Adapted from Pressman, 1992)


Figure 21-11 How Total Quality Management differs from Business Process Re-engineering


Time

Continuous Improvement

BPR

Proc

ess

Impr

ovem

ent

figures part 2

Documents