Explain the differences between logical and physical design
Discuss the objectives of systems design and provide guidelines
for good design
List and describe the major activities of the systems design phase
Design and use appropriate codes in systems design and development
Discuss types of output
Objectives (2nd part)
Describe the classifications of output reports and explain the
differences among them
Design effective printed reports that will meet user requirements
Design screen reports that are easy to understand and use
Explain output control concepts and methods
Systems Design Overview
Logical vs. Physical Design
Logical design defines necessary system requirements
Logical design specifies what must take place, not how
it will be accomplished
Physical design concerns how the system will be
implemented
Physical design describes specific components and system
specifications
The relationship between analysis and design
Logical and physical design are related closely
Analysis should be completed before design
Developers do not return from design to analysis work except in
limited circumstances
An important fact is overlooked
Users have significant new needs
Legal/governmental requirements change
Unforeseen design issues or problems arise
Systems design activities
Design the system
Output
Input
Files and databases
System architecture
Present the system design
System design specification document
General Guidelines for Systems Design
Characteristics of a well-designed system
Effective
Satisfies defined requirements
Accepted by users
Reliable
Adequately handles errors (input, processing, hardware, or
human mistakes)
Maintainable
Well-designed and flexible
Future modifications considered
Design suggestions
Three categories of considerations
User considerations
Data considerations
Processing considerations
User considerations
Make the system user-friendly
Consider where users receive output, or provide input to the
system
Anticipate future needs
Users
Information system
Organization
Data considerations
Enter data where and when it occurs
Verify data where it is input
Use automated data-entry methods
Control access for data entry
Report all entries or changes to critical values
Enter data into a system only once
Avoid data duplication
Processing considerations
Use a modular (structured) design
Design modules that perform a single function
Design tradeoffs
Design goals often conflict with each other
Easier use might create more complex programming requirements
More flexibility might increase maintenance needed
Meeting one user’s requirements might make it harder to
satisfy another’s needs
A major issue is quality versus cost
TRADEOFF
Good design: the flexibility issue
Hardcoded (fixed) values are inflexible
Users’ needs constantly change
Variable parameters can provide flexibility
Default values can be combined with user-defined parameters
Designing and Using Codes
A code is a set of letters or numbers that represents an item of
data
Codes serve many useful purposes
Save storage space and costs
Reduce data transmission time
Decrease data entry time
Can reveal or conceal information
Can reduce input errors
Types of coding
Sequence codes
Block sequence codes
Classification codes
Alphabetic codes
Mnemonic codes
Significant digit codes
Derivation codes
Cipher codes
Action codes
Self-checking codes
Developing a code
Keep codes concise
Allow for expansion
Keep codes stable
Makes codes unique
Use sortable codes
Avoid confusing codes
Make codes meaningful
Use a code for a single purpose
Keep codes consistent
Introduction to Output Design
Users judge a system based on how well the output helps them
perform their jobs
Output must be
Useful
Accurate
Understandable
Timely
Checklist for output design
Design process depends on
What is the purpose of the output?
Who or what wants this information, why is it needed, and how
will it be used?
What information will be included?
What format should be used?
When will information be provided, and how often must it be
updated?
Will simultaneous user access be required?
Are security or confidentiality issues involved that need to
be considered?
Types of Output and Information Delivery
Technology affects how people communicate and obtain information
Printers
Screens
Plotters
Audio output
E-mail
Links to Web pages
Automated facsimile system
Computer output microfilm (COM)
Other specialized devices
Printed output
Impact printers
Laser printers
Turnaround documents
Advantages/disadvantages of printed output
Many people prefer to work with paper
Paper is portable
Printed output is expensive to purchase, print, store, and
dispose of
Printed output is outdated quickly
Screen output
The screen is the most familiar output device
Monitor
CRT (cathode ray tube)
LCD (liquid crystal display)
VDT (video display terminal)
Graphical output allows various special effects and
user-friendly features
Screen output reflects immediate data changes
Other types of information delivery
Audio output
Automated facsimile and faxback systems
E-mail
Links to Web pages
Specialized forms of output
Designing Printed Reports
Reports can be classified by content
Detail reports
Exception reports
Summary reports
Reports also can be classified by distribution
Internal reports
External reports
Detail reports
Provide the most information
At least one line of output is produced for each record
processed
Detail reports can be quite lengthy
Control-break reports
Use a control field
Must be sorted on the control field before printing
A control break occurs when the control field value changes
Exception reports
Show only records that meet a specific condition
Useful when particular information is required
Special parameter queries can be used to select only the records
that meet specified conditions
Summary reports
Show only subtotals and totals
Useful for upper-level managers who do not require extensive
detail
Internal reports
Distributed within the organization
Usually printed on stock paper
Blank, single ply, standard size
Less expensive
Can be used for many types of reports
External reports
Distributed outside the organization
Might include statements, invoices, or paychecks
Usually printed on special forms
More expensive than stock paper
Paper must be changed for each report printing job
Multi-part forms must be separated or decollated
Special forms can use preprinted graphics and logos
Special applications, such as checks, require special forms
Designing the report
Most reports use graphical design
Choice of typefaces and scalable fonts
More design flexibility
Some reports are character-based
Printed on high-speed impact printers
Require printer spacing charts for layout and design
Stock paper reports
Page heading lines
Column heading lines
Column heading alignment
Spacing between columns
Order of data items on detail lines
Grouping detail lines
Report footing
Improving a report design
Documenting a report design
Design Consistency
Special form reports
Can use printer spacing charts to design
Placement of preprinted graphics can be indicated
Functional and aesthetic design principles are important
Field labels should be short but descriptive
Avoid nonstandard abbreviations
Order and placement of printed fields should be logical
Totals should be identified clearly
Report volume and time calculations
Accurate estimates are necessary to
Determine whether printing capacity is adequate
Achieve efficient printing operations
Ensure timely delivery of finished reports
Provide reliable forecasts of paper and storage needs
Factors to consider
Types of printers
Print volume calculations
Print-time calculations
A KEY QUESTION
The problem: users receive many reports, but do not seem to read
them
The solution?
Designing Screen Output
Major advantage is timeliness
Screen output can be produced when and where needed
Disadvantage - no tangible record
When would you use screen output?
Screen design considerations
Many print design principles apply to screens
Screens also need instructions and messages
Users require immediate Help and feedback
Character-based screens
Screen locations are plotted using columns and lines
Use screen display layout forms
Messages typically on top or bottom line
Graphical screens
Screen locations are plotted in inches or other units
More flexible designs are possible
Character output
High-resolution monitors allow more flexibility
Display must be clear and easy to read
Fonts and typefaces must be chosen carefully
High-resolution monitors allow more flexibility
Display must be clear and easy to read
Fonts and typefaces must be chosen carefully
Screens vs. printed output
Information might need redesign for smaller screen
Multiple screens might be necessary
Columnar or tabular designs are possible
Graphical output
Graphical displays can be very effective
Many formats are possible
Pie charts
Maps
Bar charts
Area charts
Scatter diagrams
Use descriptive titles, label each axis, and include a legend
Special effects
Character-based systems can use special effects
High brightness
Blinking
Reverse video
Use of different colors for emphasis
Graphical environment provides options
Command buttons
Boxes and borders
Unlimited use of color
Custom menus, icons, and multiple windows
Designing Other Outputs
Output to tapes and disks
In an integrated environment, data transfer is handled by
interactive network design
In other cases, data transfer uses tapes or disks
Output from one program can be input to another
An output file format is a data structure that can be
understood by another program or system
Tape or disk output design must calculate file volume
Other output media
Format and contents depend on the output device and its
requirements
Various output options exist
Plotter output
Series of commands is formatted for the specific plotter
being used
Computer output microfilm (COM)
Output is recorded as images on roll or sheet film
Data scanned/stored in digital form
Output Control
Output integrity
Ensure output is correct, complete, & secure
Include appropriate titles and dates on reports
Number pages consecutively
Identify the end of each report
Print/reconcile control totals/record counts
Review error reports for possible causes
Create error file to flag uncorrected/reentered records
Output security
Protects privacy rights and proprietary data
Important tasks to carry out
Control the number of report copies
Distribute reports only to authorized users
Store sensitive reports in secure areas
Label all pages of confidential reports
Burn/shred sensitive reports & other output
Inventory blank checks regularly
Store signature forms securely
Automated Design Tools
Report generators
Included in CASE tools & database programs
Powerful, easy-to-use features
Enter constant information (titles/headings)
Specify a print position for each item
Use field sizes from data dictionary to create a design
Produce a report definition
Creates program code that can be modified
Screen generators
Similar to report generators
Create displays using onscreen layout tools
Completing the report and screen designs
Ensure consistency with data dictionary
Automate routine design tasks
Produces rapid results
Does not guarantee good design
Still must know and apply effective design to produce reports
and screens that satisfy user requirements
Objectives
Discuss the objectives of systems input design
Explain the differences among data capture, data entry, and data
input
Explain the differences between batch and online input
List and describe the different types of data validation checks
Discuss effective source document design
Design input records
Discuss guidelines for effective screen design
Describe and design data entry screens, process control screens,
graphical user interfaces, and Help screens
Explain input control techniques
Introduction
Input technology has changed greatly
Output quality depends on input quality
Overall goals of input design
User-friendly interface
Input processes that ensure data quality, accuracy and
timeliness
Definitions
Data capture
Identification and recording of source data
Data entry
Conversion of source data into a computer-readable form
Data input
Process by which the computer-readable source data enters the
information system
Input Design Objectives
Four main input design objectives
1. Select input media and methods
2. Develop efficient input procedures
3. Reduce input volume
4. Reduce input errors
Input media and data entry methods
Batch input method
Data entry is done over period of time
Collection (batch) of data is input at one time
Online data entry method
Also called direct data entry
Data is validated and available immediately
Source data automation
Combines online data entry with online data capture
Uses magnetic data strips and swipe scanners
Common examples: ATMS, point-of-sale terminals, bar code
readers, patient ID bracelets, libraries
Develop efficient input procedures
Procedures
Must be efficient, timely, and logical
Must identify potential bottlenecks
Reduce input volume
Less volume means less time, effort, and cost
Four guidelines
1. Input necessary data only
2. Do not input data that can be retrieved
from system files or calculated from other data
3. Do not input constant data
4. Use codes
Reduce input errors
Fewer errors mean better data quality
Eight types of data validation checks
1. Sequence checks
2. Existence checks
3. Data type checks
4. Range checks
5. Reasonableness checks
6. Validity checks
7. Combination checks
8. Batch controls
TRADEOFF
Should users ever enter retrievable data for verification
purposes?
Online data entry allows immediate verification, but batch input
methods do not
Batch input data can be verified by entering a second data item,
such as a customer name in addition to a customer number, which must
match a specific record when the data is input
Pros and cons: this method can detect invalid entries, but
involves more time and expense
A KEY QUESTION
Should Prowler Products change to an online data entry system?
Pros: improved data accuracy, customer satisfaction, and company
image
Cons: more expensive
Alternatives?
Key Tasks in Input Design
Six key tasks
1. Design data entry and input procedures
2. Design source documents for data capture,
or devise other data capture methods
3. Design input data records
4. Design data entry screens
5. Design user interface screens
6. Design audit trails and system security
measures
Source Document Design
Source documents
Request and collect input data
Can trigger or authorize input actions
Provide a record of the original transaction
Form layout guidelines
Allow sufficient space
Offer clear instructions
Provide logical organization
Use captions effectively
Form zones
Heading zone
Control zone
Instruction zone
Totals zone
Authorization zone
Source documents can be external or internal
Input Record Design
Input record layout chart
To design and document batch input records
Multiple record designs are used for transactions that involve
constant and repeating data
Constant fields (non-repeating data)
Repeating fields
Information flow on a form
Should be logical and easy to follow
Poor design results in forms that are difficult to use,
time-consuming, and prone to error
Screen Design
Effective screen design guidelines
1. Screens should be attractive and
uncluttered
2. Information on a single screen should be
displayed in a meaningful, logical order
3. Screen designs should be consistent
4. Messages should be specific,
understandable, and professional
5. Messages should remain on the screen for
an appropriate period of time
6. Special effects should be used sparingly
7. Users should receive feedback
8. Screen designs should be documented and
approved as soon as possible
Data entry screen design
Guidelines
1. Restrict user access to screen locations where data is entered 2.
Provide a descriptive caption for each field and show the user where to
enter the data 3. Show a sample format if one is required 4. Require
ending keystroke for every field 5. Do not require users to enter
special characters 6. Do not require users to type leading zeroes or
trailing spaces for alphanumeric fields 7. Do not require users to type
trailing zeroes that follow a decimal point 8. Display default values
that users can accept 9. Use default values for constant data 10.
Display a list of acceptable values for fields with a limited number of
valid choices 11. Provide a way to leave the data entry screen without
inputting the current record 12. Provide an opportunity to confirm the
accuracy of input data before entering it 13. Provide a means to move
among form fields in a standard, or in another, order 14. Design the
screen form to match the layout of the source document 15. Allow the
operator to add, change, delete, and view records 16. Design a method
to allow operators to search for a specific record
TRADEOFF
When should input data be validated? Is it better to check the
values as soon as each value is entered, or wait until all fields are
input? What issues should be considered?
What type of field is involved, and does it affect other fields?
Can data be validated at time of entry?
Can missing data be obtained later?
Which method do users prefer?
A KEY QUESTION
At Boolean Toys, should individual users be allowed to select data
entry and validation methods, or should a standard method be required?
What are the pros and cons of allowing different validation
methods in the same system?
Process control screen design
Users can control system actions with interactive menus and
prompts
Menu screens
Menus display a list of user-selectable options
Menu-driven system uses a hierarchy of main menus and submenus
Shortcut key combinations can be used in a menu design
Prompt screens
User types a response to a prompt
Responses can include commands
Structured Query Language (SQL) can be used
Question/answer screens can be used
Natural language techniques can be used, similar to Internet
search engines
Graphical user interfaces
A GUI environment includes process control and data control, and
are easy to use
Common features
Menu bar
Toolbar
Drop-down menus
Dialog, text, and drop-down list boxes
Option (radio) buttons, toggle switches, and spin bars
Help screen design
Several methods to obtain Help
Click a command button or toolbar
Press a special key
Context-sensitive Help
Provides Help on the task in progress
User-selected Help
Hypertext
Uses links to display additional information on related topics
Help Screen Design guidelines
Provide a direct route for users to return to the program after
Help is obtained
Title every Help screen
Use easy, simple, understandable Help text
Present attractive, uncluttered screens
Provide appropriate examples
Use hyperlinks
Include contact data for persons or departments responsible for
assisting users
Input Control
Measures to ensure that data is correct, complete, and secure
Effective source document design
Data validity checks
Batch input controls
Log files for rejected records
Audit trails
Data security measures, including encryption
Password and sign-on procedures
Records retention policies
Automated Design Tools
Screen and form generators
Useful tools during input design as well as output design
Screen and form generators interact with the data dictionary
Screens and forms can include built-in field validation checks
Mock-ups can be produced quickly for user approval, together
with design specifications
Systems Analysis and Design
8 As always, these notes are a supplement to, not a substitute
for, class attendance.
File and Database Design
Objectives
Define the terms entity, file,
record, and attribute and discuss the various types of keys
Draw an entity-relationship diagram,
and explain the types of entity relationships
Define cardinality, cardinality
notation, and crow’s foot notation
Explain normalization, including
examples of first, second, and third normal form
Compare and contrast database
management and file processing environments
Explain various types of database
organization, including hierarchical, network, and relational design
Describe various types of files,
including master, transaction, table, work, history, and security
Discuss file and database control measures
Data Terminology and Concepts
Definitions
Entity: a person, place, thing, or
event for which data is collected and maintained
Field (attribute): a single
characteristic or fact about an entity
Record: a collection of fields
that describes one instance of an entity
File: a set of records that
contains data about a specific entity
Key field: a field used to locate,
retrieve, or identify a specific record
Primary key
Candidate key
Foreign key
Secondary key
Key fields
Primary keys
A field or combination of fields
that uniquely and minimally identifies each member
of an entity
A primary key composed of more
than one field is called a multivalued key
Candidate keys
Any field that could
serve as primary key
Any field that is not a primary
key or candidate key is called a nonkey field
Foreign keys
A field in one file that matches
a primary key value in another file
Example: the advisor number is a
foreign key in the STUDENT file that matches a primary key value
in the ADVISOR file
A foreign key need not be unique
A combination of two or more
foreign keys can form a unique primary key value
Referential integrity ensures
that a foreign key value cannot be entered unless it matches a
primary key value in another file
Secondary keys
A field or combination of fields
that can be used to access or retrieve records
Secondary keys do not need to be unique
Data Relationships and
Entity-Relationship Diagrams
Entity-relationship diagrams (ERDs)
An ERD is a graphical model that
shows relationships among system entities
Each entity is a rectangle,
labeled with a noun
Each relationship is a diamond,
labeled with a verb
Types of relationships
One-to-one (1:1)
One-to-many (1:M)
Many-to-many (M:N)
A full ERD shows all system relationships
One-to-one (1:1) relationship
Exists when exactly one of the
second entity occurs for each instance of the first entity
Examples
One office manager heads one
office
One vehicle ID number is
assigned to one vehicle
One driver drives one delivery
truck
One faculty member is chairperson of one department
One-to-many (1:M) relationship
Exists when one occurrence of the
first entity can be related to many occurrences of the second
entity, but each occurrence of the second entity can be associated
with only one occurrence of the first entity
Examples
One individual owns many
automobiles
One customer places many orders
One department employs many
employees
One faculty advisor advises many students
Many-to-many (M:N) relationship
Exists when one instance of the
first entity can be related to many instances of the second entity,
and one instance of the second entity can be related to many
instances of the first
Examples
A student enrolls in one or more
classes, and each class has one or more students registered
A passenger buys tickets for one
or more flights, and each flight has one or more passengers
An order lists one or more products, and each product is
listed on one or more orders
A full ERD shows all system
relationships
Examples
A sales rep serves one or more
customers, but each customer has only one sales rep
A customer places one or more
orders, but each order has only one customer
An order lists one or more
products, and each product can be listed in one or more orders
A warehouse stores one or more products, and each product can
be stored in one or more warehouses
Cardinality
Describes how instances of one
entity relate to another
Mandatory vs. optional
relationships
Crow’s foot notation is one method
of showing cardinality
Most CASE products support the
drawing of ERDs
Creating an ERD
1. Identify
the entities
2. Determine
all significant events or activities for two or more entities
3. Analyze
the nature of the interaction
4. Draw the
ERD
Normalization
Record design process that
identifies and avoids data problems and redundancy
Specifies the fields and the primary
key
Normalization analyzes record
structure through four stages
Unnormalized records
First normal form (1NF) records
Second normal form (2NF) records
Third normal form (3NF) records
First normal form
Unnormalized records contain a
repeating group
A repeating group refers to a
single record that has multiple values in a particular field
Example: multiple product
numbers in a single order record
A 1NF record cannot have a
repeating group
To convert an unnormalized record
to 1NF, the repeating group must be removed
Expand the primary key to
include the primary key of the repeating group
The new primary key is a
combination of the original primary key and the key of the
repeating group
Instead of a single record with a repeating group, the result
is many records, one for each instance of the repeating group
Second normal form (2NF)
To be in second normal form, a
record must be in 1 NF, and all nonkey fields must be functionally
dependent on the entire primary key - not just part of it
Functional dependency means that a
value in one field determines a value in another field
If the primary key is a single
field, then any record in 1 NF is automatically in 2 NF
In 2NF, all nonkey fields are
functionally dependent on the entire primary key
To convert a 1NF record to 2NF
Create a new record design for
each field (or combination of fields) in the primary key
Place remaining fields with the
appropriate record
The result will be several records, each with a primary key
field (or combination of fields) that determines the values of the
other fields in that record
Third normal form (3NF)
To be in 3NF, a record must be in
2NF and no nonkey field is functionally dependent on another nonkey
field
In 3NF, all nonkey fields are
functionally dependent on the primary key, the entire key, and
nothing but the key
To convert a 2NF record to 3NF
Remove all nonkey fields that
depend on another nonkey field and place them in a new record that
has the determining field as a primary key
A normalization example (see page
8.15)
Identify the entities
ADVISOR
STUDENT
COURSE
Identify the relationships
One advisor advises many
students (1:M)
Students take one or more
courses, and courses have one or more students (M:N)
Document the unnormalized record
Note the repeating group of
courses
Convert the unnormalized record to
1 NF
Remove the repeating group
Create a primary key composed of
the original primary key (student number) and the primary key of
the repeating group (course number)
The result is one record for
each instance of the combination primary key
Convert the 1 NF record to 2NF
Create a separate record design
for each field and combination of fields in the primary key
Place functionally dependent
fields with an appropriate primary key
The result is three records
instead of one, each with a unique primary key
Now all nonkey fields are
dependent on the entire primary key, not just a portion of it
Convert the 2NF record to 3NF
The STUDENT record contains a
nonkey field (advisor name) that is dependent on another nonkey
field (advisor number)
Create a new record with advisor
number as the primary key
Remove the dependent nonkey
field (advisor name) and include it in the new record
Now all nonkey fields are dependent on the entire primary key,
and nothing but the key
Steps in Database Design
Four steps in database design
1. Create the
initial ERD
2. Assign all
data elements to entities
3. Create 3NF
designs for all records, taking care to identify all primary, secondary,
and foreign keys
4. Verify all
data dictionary entries
Database Management
Potential problems in a file
processing environment
Data redundancy
Inconsistent data
Inefficiency
Database management design
A database is a structure that can store data about many
entities and the relationships among them
Elements of database management
systems
A database management system
(DBMS) is used to create, access, and control a database
Data definition language (DDL)
Data manipulation language (DML)
Query language
Data dictionary
Utility programs
Characteristics of database
management systems
1. Scalability
2. Better
support for client/server systems
3. Economy of
scale
4. Sharing of
data
5. Balancing
conflicting requirements
6. Enforcement
of standards
7. Controlled
redundancy
8. Security
9. Increased
programmer productivity
10. Data
independence
A DBMS is more powerful, complex,
and expensive than a file processing system
Effective security, backup, and
recovery procedures are essential
Data is a company-wide resource
Data mining enables users to extract information from anywhere in
the organization
Database Models
Hierarchical databases
Data is organized like a family
tree or organization chart
The parent record at the top of
the hierarchy is the root record
Pointers are used to navigate and access records
Network databases
The network database model is
shown as a set of records arranged in one-to-many relationships
A relationship between two records
is called a set, which includes owner and member records
A record can be a member of
multiple sets
Relational databases
Data is organized into
two-dimensional tables, or relations
Each row is a tuple (record) and
each column is an attribute (field)
A common field appears in more
than one table and is used to establish relationships
Because of its power and flexibility, the relational database
model is the predominant design approach
Object-oriented databases
The object-oriented approach
focuses on data rather than processes
An object-oriented definition
includes objects, methods, messages, and inheritance
An object is a unit of data, along
with the actions that can affect that data
Methods are actions defined for an
object
A message is a request to execute
a method
Inheritance allows a subclass to
take on the characteristics of an object
A file is a set of logical records
that contains data about an entity
Types of Files
Table files
Transaction files
Work files
Security files
History files
Data storage formats
EBCDIC
ASCII
Packed decimal
TRADEOFF
What is the best way to store date
fields?
Issues to consider
Year 2000 problem
ISO format options
Julian date format
Extended Julian date format
Absolute date format
A KEY QUESTION
The problem: different date formats
exist in various countries where SoccerMom operates
The question: should SoccerMom adapt to the standard of each
country, or should it use a single international format? What are the
arguments both ways?
File Access
The file access method determines
how programs read and write records
Two main methods are used
Sequential access method
Program reads all records in
order until the end of the file is reached
Random access method
Program can read any logical
record without having to access all preceding records
File Organization
The file organization approach determines the way logical records
are physically stored in a file
Alternatives
Sequential organization
Direct
organization
Indexed organization
Sequential organization
Two methods of sequential organization
Records are stored in physical
sequence as they occur
Records are stored in primary key order
Direct organization
With direct organization, a record is
stored based on a formula that uses the record’s primary key, which must
be numeric
Two methods of direct organization
Key-addressing techniques
Hashing (randomizing) techniques
Indexed organization
With indexed organization, a separate
index file contains the key value and data file location for each
logical record
Several types of indexed organization
exist
Indexed random organization
Indexed sequential organization
ISAM
VSAM
File organization advantages and
disadvantages
Direct file organization
Indexed organization
File and Database Control
Control must include measures to ensure that data is correct, complete,
and secure
Passwords
Encryption
Backup and
recovery procedures
Audit trail files
Audit fields
Systems Analysis and Design 9
As always, these notes are a supplement to, not a substitute for, class
attandance.
Systems Architecture
Phase Three, Step Two, Part Four
Systems Planning
Systems Analysis
Systems Design
Review Requirements
Design the System
output design
input design
file and database design
system architecture
Document/Present the System
Objectives
Define the term system architecture and
describe how it relates to the organization and functions of a business
system
Discuss major processing methods,
including batch, online, centralized, and distributed processing
Describe local and wide area networks
Explain the characteristics of distributed
systems and client/server architecture
Discuss the major processing functions of
data input, validating, updating, sorting, and reporting
Describe standard backup and recovery
methods for batch and online processing systems
Discuss the differences between
traditional systems development and object-oriented development
Define the contents of the system design
specification document
Systems Architecture
System architecture refers to the logical
and physical design of a system, including hardware, software, data,
procedures, and people
System architecture is the last task in
the systems design phase of the SDLC
The end product of the systems design
phase is the system design specification
Processing Methods
An information system operates in an
environment that contains one or more specific platforms
An environment, or platform, consists of a particular combination
of hardware, systems software, and processing methods
Most companies have progressed from multiuser or stand-alone
environments to a powerful, interconnected operating environment
Online processing
Interactive
Allows a dialog between the user and the system
Increases productivity
Batch processing
Data is collected and processed in groups (batches)
Typical method for large amounts of data that are processed
periodically, such as paychecks
Batch processing can take place at off-peak times
Combined online and batch processing
Typically captures transactions in an online mode
May or may not update files online
Usually uses the data captured online as input for batch
processing
Examples are banks, retail sales, and grocery stores
Centralized and distributed processing
Trend has been toward distributed data entry and access, rather
than centralized operations
Terminology
Centralized processing
Distributed system
Data communication network
Distributed processing
Distributed database management system (DDBMS)
Data processing center
File server design
Client/server architecture
Local Area Networks and Wide
Area Networks
Networks are classified as local area
networks (LANs) or wide area networks (WANs) depending on geographical
scope and equipment required
A network allows hardware, software, and
data resources to be shared
Topology is the way a network is
configured
A protocol is a set of data transmission
standards
A popular protocol is TCP/IP
Nodes are individual locations on a
network
Client/Server Systems
Divide processing between a central server
and one or more clients
A client handles the entire user interface
Data entry
Editing
Data query
Typical transaction
The client submits a request for information from the server
The server responds with the results
Client/server advantages
Client/server systems are scalable, powerful, and flexible
Businesses can size their systems easily to a changing environment
Communication is possible across multiple platforms
Network load is reduced
Response time is improved
A KEY QUESTION
R/Way has several options
Continue with a file-based system running on the current file
server and three workstations
Implement a relational database running on the existing file
server platform
Design a new client/server environment
R/Way should consider cost, data file
characteristics, ability to handle legacy data, projected growth, and
network load
Processing Functions
All processing functions must be
documented
Data input and validating
Updating
Sorting
Reporting
Data input and validating
In online processing the system handles data entry, data input,
and validation as a transaction is entered
With batch processing, data entry and validation are separate
functions, and a specific way to handle transaction errors is
necessary
Require all transactions to be correct before any processing
Use a program to correct the transaction file
Create a suspense file for transaction errors
Updating
Updating (file maintenance) is the process of adding, changing, or
deleting records in a master or table file
An audit file is required
Deletion methods
Logical deletion uses flags, and restoration is possible
Physical deletion occurs when data is no longer required
Sorting
A major task in file-based systems
Transaction files must be sorted before a batch update takes place
In a database environment, physical sorting is not necessary
because the DBMS uses indexes when processing, accessing, and
displaying records
Reporting
A major function of online and batch processing systems
Reports can be designed with report generators and 4GL tools
Most commercial database programs have report generation
capability built into the package
Processing Support
Every system will encounter problems
"Bugs"
Hardware failures
Systems software errors
User mistakes
Power fluctuations
The objective is to anticipate problems
and develop methods to recover from them
Five major support functions
Backup
Recovery
File retention
Restart
Start-up processing
Backup and recovery
Different strategies are required for batch and online processing
Batch processing involves restoring the backup master and running
the transaction file again
Online recovery strategies include
Log (journal) files that recreate transactions
Multiple high-capacity disks
Streaming tape devices
File retention
The length of time that a file needs to be stored
Determined by combination of legal and processing requirements
Updating cycles are called generations
Grandparent, parent, and child strategy
Legal requirements must be considered
Restart
After a program is interrupted by an error, the first step is to
correct the problem and restart the system
A specific restart procedure is required
Common techniques include the use of checkpoints and program
status indicators
Start-up processing
Needed when making the transition from the current system to a new
system
Create new master files from existing data
Might require special data conversion programs
Start-up processing and file conversion tasks are discussed in
Chapter 11, which covers systems implementation
Software Design
Program considerations
Identify specific processing functions for each program, and
review all process descriptions
Guidelines
Use a separate update program to maintain each master file
Provide a validation program for each update program that does
not perform its own validation
Reduce the number of report programs if possible
Identify any programs required to perform special processing
Program documentation
In a file-based system, specific program documentation must be
assembled
Program identification
Purpose of the program
Processing requirements
Systems Design Completion
System design specification
Presents the complete design for the new system, along with
detailed costs, staffing, and scheduling requirements for the next
SDLC phase, systems implementation
Programmers rely on the system design specifications as they
develop the necessary programs and system functions
The contents of the system design specification depend on the
company standards and the complexity of the system
Management Summary
System Components Details
Program Design
Output Design
Input Design
File and Database Design
Support Processing Design
Environmental Requirements
Implementation Requirements
Time and Cost Estimates
Appendices
Approvals
Review and approval process continues throughout the SDLC
Obtaining design approval from users is especially important
Other approvals are needed from IS department members and
management
The system design specifications should be distributed well in
advance of the presentation
Technical and management presentations
Several presentations usually are made to
Other information systems department staff
Top IS management
Company management
Various decisions are possible including
Proceed with systems development
Perform additional work on system design
Terminate the project
Name
Title
Company
Address
E-mail
Phone
Notice: These notes are intended to be a supplement, not a substitute, to
attending class.
