Designing Inputs, Outputs, and Controls

About This Presentation

Title:

Designing Inputs, Outputs, and Controls

Description:

Designing Inputs, Outputs, and Controls – PowerPoint PPT presentation

Number of Views:183

Avg rating:3.0/5.0

Slides: 45

Provided by: Petr97

Category:

more less

Transcript and Presenter's Notes

Title: Designing Inputs, Outputs, and Controls

1
LECTURE 10.
Designing Inputs, Outputs, and Controls
2

Major issue in the design of systems how to
provide access to required information and at the
same time protecting the information from damage
(both accidental or intentional). Designing
system controls is crucial, especially today when
computer systems are built in an open environment
I. Integrity controls
Integrity controls are mechanisms and
procedures that are built into the system to
safeguard both the system and the information
contained in the system
Most violations occur from inappropriate
access. So, design of interface must consider the
mechanisms to protect the system. However,
integrity controls involve also many situations
of regular systems use
E.g. how could we ensure that only a manager
looks at sensitive pay information?
E.g. how does a company know that only authorized
person can make corrections to a customer
balance?
Objectives of Integrity Controls
Ensure that only appropriate and correct
business transactions occur (this objective
focuses on identification and capture of input
transactions to ensure that all important
transactions are included and fraudulent ones are
not entered)
Ensure that the transactions are recorded and
processed correctly (controls are used to alert
users to data-entry errors and system bugs that
cause problems in processing and recording data)

Protect and safeguard the assets (including
information) of the organization (protection
against loss of information due to crashes,
catastrophes, hackers etc.)
System Access Controls
Modern operating systems, networking software
and Internet access all require implementation
control mechanisms. These mechanisms control
access to any resources including hardware,
application programs and data files
System access controls are mechanisms that
restrict or control what portions of the computer
system a person can use
Includes controls to limit access to certain
applications or functions, the computer itself or
pieces of data
Most systems are built with the embedded in
system software access control functions (it
allows to apply the single control access scheme
to every resource of IS). Extra controls can be
added by the project team over and above those
already provided by system software (it is
expensive and requires technical expertise
usually only standard, built-in controls are
used)
Categories of users
In order to develop the access controls, we
must identify categories of users. There are
three categories of users (1) unauthorized
users (2) registered users (3) privileges users

4
Unauthorized user is a person who are not
allowed access to any parts or functions of the
system (e.g. former employees and oustiders like
hackers) Registered user is a user who is
registered or known to the system and is
authorized to access some part of it. Different
levels of access are defined for different users
during design (e.g. permission only to view data
but not update them or update only certain data
fields) Privileged user is a user who has
special security access privileges to a system
(to the source code, executable programs and
database structure) usually system programmers,
application programmers, operators and system
administrators. They may have different levels of
security access system programmers have full
access to all components of the system and data
application programmers have access to the
applications themselves but often not to the
secure libraries and data files system
administrators have access to all functions of
the system and can control the register users
(special software helps to control access and
monitor access attempts) Figure 10-1
illustrates the various types of users and kinds
of access controls Various access controls are as
follows. Physically securing locations protect
physical equipment such as computers, hard disk
storage devices and backup data tapes. It cannot
protect software or the on-line data files
5
FIGURE 10-1 Users and access roles to computer
system.
6

Managing User Access. The most common method
for managing user access to IS is a user
identifier (ID) and password
User IDs are defined by a standard algorithm
which takes a combination of the user name or
initials to develop the ID
Two techniques are used to define passwords
Computer can randomly generate and assign
passwords (usually longer and more random, but
hard to remember)
Each user can define his or her own password
(easier to remember, not as complex and therefore
not quite as secure
Some restrictions can be placed on the syntax of
the password must be at least 8-10 characters
long, contain both numbers and letters, both
lower- and uppercase letters, easily guessed
passwords such as names or birthdays should be
avoided
Security system should be organized so that all
resources can be accessed using the same unique
identifier and password (so dont have to know
many of these within one organization otherwise
users will write down and post their IDs and
passwords near the computers)
Some companies require password changes every
30 or 90 days
A final security step is keep record of
attempted (unsuccessful) logons. It may simply
indicate that the user mistyped or forgot a
password, but may also indicate an attempted
breach of security and should be investigated

Controlling Access with Visibility is an
important type of control which determines what
each user actually sees and must be integrated
into the application system itself
Designers define and develop the various levels
of visibility and access
Visibility controls are defined by
The various classes of registered users, and
Which functions, screens, forms, fields, reports
etc. will be available to those classes of users
(e.g. a salespeople may be able to see their own
orders, sales and commissions a supervisor may
be able to view the performance of salespeople in
his /her jurisdiction
Level of visibility increases with the level of
authority and responsibility in an organization
Input Integrity Controls
Input integrity controls are used with all
inputs mechanisms (from specific electronic
devices to standard keyboard inputs)
Input controls are an additional level of
verification that helps reduce errors on input
data (e.g. an input device cannot ensure that all
the necessary fields have been entered so need
this additional level of verification or control)

Error Detection and Elimination
Historically the most common method to ensure
correct input was to enter data twice (called
keypunch verify). One person would enter the data
and a second person would reenter it on equipment
that would then verify that two inputs were the
same (not used today)
Common techniques that are used today to verify
input
Field combination controls, i.e. review various
combinations of fields to ensure that the correct
data is entered (e.g. on an insurance policy the
application data must be prior to the policy
issue date)
Value limit controls, i.e. check numeric fields
to make sure that the amount entered is
reasonable. (e.g. the quantity of an ordered item
is not greater than its quantity in stock)
Completeness controls is an integrity control
to ensure that all necessary fields on an input
form have been entered (e.g. if children are
entered on a form, then that their birthdays must
also be entered)
Data validation controls, i.e. ensure that
numeric fields that contain codes are correct
E.g. bank account numbers might be created with a
7 digit field and a trailing check digit to make
an 8 digit account number
The check digit is based on the previous seven
digits, and the system recalculates it (using
data entered) as the data-entry person enters the
account number with check digit
If the results dont match an input error has
occurred

Transaction logging is a technique whereby all
updates to a database are recorded with the
information of who, when and how the update was
performed
Any update to a database is logged with this
audit information such as user ID, date, time,
input data and type of update
The main idea is to create an audit trail of all
updates to the database that can trace any errors
or problems that occur
Objectives
To discourage fraudulent transactions (since it
is known who accesses)
Provides a possible recovery mechanism for
erroneous transactions if all transactions are
recorded system can recover from errors by
unapplying the erroneous transactions
Output Integrity Controls
Purpose of output controls is to ensure that
output arrives at the proper destination and is
correct, complete and accurate
Destination controls is integrity controls to
ensure that output information is channeled to
the correct persons
In the past, when most output was in printed
form, a distribution control desk collected all
the printed reports from the nightly processing
and distributed them to the correct department or
people

Reports may contain confidential information,
so good idea is to use cover sheets to identify
person to get output
Today businesses can place printers in each
location that needs reports (however, it is still
a good idea to print a cover sheet with
destination and report heading information)
Electronic output to other systems is usually
provided in two forms
On-line transaction-by-transaction output
Must ensure that each transaction has routing
codes identifying the correct destination
The output transaction will have verification
codes to permit the receiving system to verify
the accuracy and respond with an acknowledgement
Many of those controls are now built into the
network transmission protocols
A single data file with a batch of output
transactions
Controls should identify the contents, version,
date, and time of file
Normally, a system produces a data file on
magnetic tape or disk, and another system must
find that file
Special beginning and ending records may contain
date, time, version, record counts, dollar
control totals etc to avoid situations when e.g.
Fridays transactions get run twice

Controls for computer screen output are not as
widely used as for printed reports
Normally, this situation is controlled by the
user controls
In some instances destination controls limit what
information can be displayed on which terminal
(used for military or other systems that host
computer terminals in secure areas and provide
access to the systems information to anyone who
has access to the area
Completeness, accuracy and correctness controls
We can ensure completeness and accuracy by
printing control fields on the output report.
They may contain the following items
Date and time of report printing
Date and time of data on the report
Time period covered by the report
Beginning header with report identification and
description
Destination or routing information
Pagination in the form of page of
Control totals and cross footings
End of Report trailer
Report version number and version date

II. Design of System Inputs
In designing inputs for the system, the
developer must must perform four tasks
Identify the devices and mechanisms that will be
used to enter input
High-level review of the most-up-to-date input
methods (usually is done through electronic forms
by end user, but todays technology include
scanning, reading, transmitting devices that are
faster, more efficient and less error-prone)
Identify all system inputs and develop a list
with data content of each
Provides the link between the design of the
application software, and the design of the
system and user interfaces
Determine what kinds of controls are necessary
for each system input
Identify control points and level of security
A statement of policy and control requirements
should be done before beginning the detailed
design of the electronic forms
Design and prototype the electronic forms (the
windows the user works with) and other inputs
Begins by creating user dialog scenarios and
sketches of screens
Sometimes working prototypes of electronic forms
can be made (helps ensure that the forms
acceptable to the users)
Graphical programming languages (e.g. Visual
Basic, PowerBuilder) are useful

Identifying Devices and Mechanisms
Objective of any form of data input is to enter
new, error-free data into the system or to update
information with error-free data
Several rules help reduce input errors
(1) Capture the data as close to the originating
source as possible
(2) Use electronic devices and automatic entry
whenever possible
(3) Avoid human involvement as much as possible
(4) If the information is available in electronic
form anywhere, use it instead of reentering it
(5) Validate and correct information at the time
and location it is entered
Many firms design systems that enable the
capture of data at the same point the data are
originally generated
E.g. instead of having person fill out insurance
application form that then has to be mailed by
the insurance agent and then entered into the
computer, can simplify by having agent entering
directly into laptop
One of the biggest sources of errors is from
users making mistakes in typing fields and
numbers. Many methods allow data to be captured
without human keystroking
Magnetic card strip readers, bar code readers,
optical-character recognition readers and
scanners, touch screens and devices, electronic
pens, digitizers (e.g. digital cameras and
digital audio devices)
E.g. at grocery stores scanners identify prices
from UPC codes, automatic weighting machines
weight and price the produce

Reuse the information already in the computer
instead of reentry multiple times what not only
creates general errors but also creates multiple
copies of the same information. It requires
extra level of controls to synchronize various
copies, changes must be made to all copies of the
data and when an error occurs, it is very
difficult to know which copy is correct
Electronic data interchange (EDI) is an
approach to reduce the need for user input
(either with a scanning device or with the
keyboard). An idea to have an interface directly
from another system
Input information, such as purchase orders,
invoices etc. passes between systems in separate
organizations, but may be applied within the same
organization enterprise resource planning
systems (ERP) make company-wide integration
possible
System-to-system transaction interface may be
based on languages like XML (extensible markup
language) an extension to HTML
Like HTML consists of embedded formatting
information to transmit texts
Extends HTML by adding self-defining data
structures to send data fields
Figure 10-2 illustrates a simple XML
transaction that transfers customer information
between systems

15
FIGURE 10-2 A system-to-system interface based on
XML.
16

Developing the list of inputs and data
requirements of each
The objective of this task is to ensure that
the designer has identified all the required
inputs to the system and specified them correctly
Fundamental approach includes
Identifying all information flows that cross the
system boundary
Idea is the same for traditional and
object-oriented approaches but the detailed
techniques vary
Developing the list of inputs using structured
models
During design using structured techniques, one
of the first tasks is to define the automation
boundary. Figure 10-3 is an example of an
automation boundary on a DFD (several of the
inputs are time-card information updates to tax
rate tables updates to employee files)
It is possible to draw the automation boundary
on a high-level DFD, but sometimes better to work
from DFD fragments or even more detailed DFDs.
For complex models you define system inputs by
looking at each DFD fragment and creating the
system boundary on each fragment
Designer analyzes each DFD fragment to determine
inputs required
Data flows that cross the boundary on the DFDs as
inputs correspond to triggers for external events
in the event table
Objective is to create a preliminary list of
the inputs from examining the diagrams

17
FIGURE 10-3 Automation boundary on a system-level
DFD.
18

Figure 10-4 shows the Create new order detailed
DFD with the automation boundary superimposed.
All of the processes are automated along with the
data files ( Figure 10-3 has examples of manual
processes). The new order information data flow
and real-time link to the credit bureau are two
inputs. The input for the user interface will be
the new order information, while the real-time
link to the credit bureau will be an electronic
system interface, so not all inputs originate
with users.
As a result, a list of high-level inputs are
determined (Figure 10-5 is a list of inputs for
RMO CSS
It does not provide enough detailed information
to design the inputs themselves.
To complete the list of inputs, the additional
information may be needed from data flow
definitions and structure charts
In structure charts the designer defines
individual program modules and data couples
Each input data flow diagram may translate into
one or more physical inputs on the structure
chart (in Figure 10-6 the New order data flow on
the DFD might be expanded into four separate data
couples on the structure chart, which in tern
identifies three modules that get data from
outside the system Get customer information,
Get order information and Get credit card
information.
Next step is to analyze each module and data
couple and list the individual data fields for
each data couple (this analysis consists of
reviewing the elements in the data stores to
ensure that all elements on the data stores can
be built based on the input data couples

19
FIGURE 10-4 The Create new order DFD with an
automation boundary.
20
FIGURE 10-5 List of inputs for the CSS.
21
FIGURE 10-6 Structure chart for Create new order.
22

Figure 10-7 shows the data couples associated
with each data flow as well as the data fields to
be associated with each data couple listed the
data couples and the associated data elements
that will be needed. Each item in the data couple
column becomes part of an electronic input data
form or an input/output form
Developing the list of inputs using the
Object-Oriented methods
Sequence and design diagrams are used
Sequence diagrams identify each incoming
messages
The design class diagrams contain the
pseudocode to verify the characteristics of the
inputs
In the sequence diagram, every message that
goes from an actor (e.g. Customer, Clerk etc.) to
an object represents an input to the system
In OO models, the boundary between actors and
objects is more explicit than in structured
models
Figure 10-8 is the sequence diagram for the
telephone order scenario of the Create new order
use case. Five separate messages go from the
Clerk (actor) are
CreateCustomer (Customer information)
CheckStatus (CustomerName, PhoneNo)
CreateOrder (Order information)
AddToOrder (ProductID, Description, Qty)
FinishOrder()

23
FIGURE 10-7 A data flow and the data couples and
data elements making up an input.
24
FIGURE 10-8 Sequence diagram for Create new order.
25
The series of messages indicates that
potentially five electronic input forms will be
required. Additional analysis of the messages
themselves supplies information about the data
fields on the message To create a more thorough
analysis of the messages, the developer should
consult the design class diagram for the
receiving object class. Each input message has a
destination a particular object class (within
the object class, a method is defined in the
design class diagram to process the message For
each input message you can list the data
parameters that will be needed (passed with the
message) see Figure 10-9 as an example of a
table that lists each input message and the data
field that must be passed with the message The
class diagram focuses primarily on the
application classes a complete design requires
user interface classes to be added to the class
diagram User-interface classes can be added
directly to the class diagram Todays
programming languages contain component libraries
to develop the user interface (Visual Basic, Java
etc. have components to build windows and input
screens) UML provides an additional notation to
identify user-interface classes (a small circle
to denote an interface for a class) Figure
10-10 is a partial class diagram from RMO that
shows five interface classes (the name for each
interface class begins with the letter I - to
indicate it is an interface class)
26
FIGURE 10-9 Input messages and data parameters
from the sequence diagram.
27
FIGURE 10-10 Customer and order classes with
interfaces for the input forms from the Create
new order sequence diagram.
28

Designing and Prototyping Input Forms
Good design principles dictate that the paper
form and its electronic counterpart should have
the same general layout and sequence of data
fields
Since the paper form will be used to enter the
information into the system, the electronic and
paper version should mirror each other and both
should be designed together
Figure 10-11 is an example of customer order
form for RMO. It is used by customers who make
purchases by mail through the catalog, but even
those who order by telephone use the form as a
working document to assist them in collecting
information before they call
III. Design of System Outputs
Primary objective of system outputs is to
present relevant information in the right place
and the right time to the right people
Historically, the most common method of
presenting output information has been in the
form of printed textual reports. New techniques,
such as charts and diagrams, provide many more
options for presentation, emphasis and
summarization of information

29
FIGURE 10-11 RMO catalog order form.
30

The tasks in this activity accomplish four
objectives
Determine the type of each output (historically
all outputs were produced in standard paper
reports, now many options to provide
information). The purpose is to evaluate the
various alternatives and design the most
appropriate approach
2. Make a list of specific outputs required based
on application design (normally, this list is
specified during the analysis phase as part of
system requirements). During design, the task is
to coordinate the production of those outputs
with the modules (structured techniques) and
methods (object-oriented techniques)
3. Specify any necessary controls to protect the
information provided in the output (often
organizations implement controls on the inputs
but forget to protect output reports, which also
contain sensitive information)
4. Design and prototype the report layout (today
users can develop their own reports using tools
and preformatted outputs ad hoc reports,
i.e.reports that are not predefined by a
programmer/analyst but designed as needed by a
user. Many systems provide a simplified graphical
tool to permit the users to formulate queries in
SQL and produce ad hoc reports
Determining the Type of Output
In the beginning of the computerized are, one
has been thought that paper reports would no
longer be needed. In fact, just opposite has
happened. Business systems generate more paper
than ever! One of the most difficult aspects of
output design is to decide what information to
provide and how to present it.

Types of reports
There are four types of output reports
detailed reports, summary reports, exception
reports and executive reports
(1) Detailed reports are used to carry out the
day-to-day processing of the business, they
provide working documents for people in the
company
Contain detailed information on business
transactions
A report may be for a single transaction or
contain information about e.g. a particular
account
A clerk might use the report to research overdue
accounts
(2) Summary reports are reports that summarizes
detailed information over a period of time or
some category (e.g. daily or weekly summary of
all sales transactions)
Often used by middle management to track
departmental or division performance
(3) Exception reports are reports that contains
only information about nonstandard or exception
conditions they is only produced when a normal
range of values is exceeded
(e.g. a report that shows the accounts that are
past due)
(4) Executive reports are summary report from
various information sources that is normally used
for strategic decisions by top management (e.g. a
summary of activities within the company or
industry-wide averages to access the competitive
strengths or weaknesses of the company)

Internal versus External Outputs
Printed outputs are classified as internal and
external outputs.
Internal output is a printed report or document
produced for use inside of the organization
(includes types of reports discussed above)
External outputs are printed documents, like
statements, notices, form letters, and legal
documents, produced for use outside of the
organization (e.g. bank monthly statements you
get in the mail)
Some external outputs are called turn-around
documents (they include a portion that is
returned to the system as input, e.g. a bill with
a payment stub you fill out and send back)
Figure 10-12 shows example of an internal
output, an inventory report for RMO. The record
includes
A detailed and summary section (called a control
break report)
The detailed section lists the transactions of
records from the database
The summary section provides totals and recaps of
the information
The report is sorted and presented by product

33
FIGURE 10-12 RMO inventory report.
34
External outputs can consist of complex,
multiple-page documents (e.g. a set of reports
and statements you receive with your car
insurance statement Parts of the report are
customized to individual recipients of the report
(sometimes documents are printed in color with
special highlighting or logos, printed on
high-quality laser printers Figure 10-13 is
example of report for survivor protection from an
employee benefit booklet (the text is standard
and the numbers are customized to the individual
employee Screen Output There is various types
of screen output, each serving a different
purpose In most instances, screen output is
formatted like a printed report, only displayed
electronically (can include detailed and summary
sections, multiple pages, columns of data with
headings, just as printed report) However, an
electronic report can be dynamic, the user can
have a real-time interchange (e.g. contain links
to further information) One technique used
called drill down is the ability to link a
summary field to its supporting detail and enable
users to view the detail dynamically Figure
10-14 is a summary report on products, however if
the user clicks on a hot link for any product, a
detailed report pops up with the list of
inventory items, the quantities on hand etc.
35
FIGURE 10-13 A sample employee benefit report.
36
FIGURE 10-14 A summary report with drill down to
the detailed report.
37

Another output technique called linking, i.e.
connecting two or more reports electronically so
that information from one links to information in
another (concept is similar to browsing pages on
the Internet, and can also be used in business
reports)
Another dynamic aspect of electronic reports is
the capability to view data from different
perspectives (e.g. option to view data by region,
by sales manager, by product line, by time period
or compared to last seasons data). Instead of
printing all these reports, electronic format
permits the different views to be generated only
as needed
Graphical and Multimedia Presentation
The graphical presentation is based on tools
that permit data to be presented in charts and
graphs making reporting more user-friendly than
just text. It allows to businesspeople using
information for strategic decision making by
looking for trends and changes.
Todays systems maintain massive amounts of
data, much more than people can review. The only
way to use this data is by presenting it in
graphical form (bar charts, pie charts etc).
Figure 10-15 illustrates a bar chart and a pie
chart
Multimedia outputs have become available only
in the last several years
Users can see graphical, animated presentation of
information on the screen
Users can have audio description of salient
points
Combining visual and audio output is powerful way
to present information
(video games are pushing progress in this area)

38
FIGURE 10-15 Sample bar chart and pie chart
reports.
39

Making a list of specific reports based on the
application design
The objective of determining the list of
reports is to ensure that each of the required
outputs is specified correctly
The basic approach is similar to design of
system inputs. Outputs are responses in the event
table data that flow from the system to some
destination
For structured techniques, outputs are data flows
that cross the system boundary
For object-oriented techniques, outputs are
messages that originate on internal classes and
whose destination is an actor
However, the uses of input and output are
different. Whereas the data content of the input
forms must support the needs of the database, the
data content of the outputs must support the
information requirements of the report users
Using Structured Models
Identifying the outputs is essentially the same
as that of building the list of inputs from the
data flows that cross the system boundary
In Figure 10-4 the Create new order DFD there
are three outputs
A confirmation to the customer
A notice to shipping
A payment transaction report that goes to the
bank
The tasks are similar task to what we did for
inputs, i.e. building a table of the DFD outputs,
defining exactly what reports are needed and
determining the data fields

We look at the data couples and the report
requirements to verify that the structure chart
modules are consistent with the structure of the
output report identify data couples to include
An analysis of the data couple being sent to
the module and the data fields on the output
report will verify that the application has been
designed correctly to generate the report
Figure 10-6 shows a single-record-output (such
as confirmation slip to a customer) the module
and data are correct to produce that information
Figure 10-16 is an example of the table of
system outputs. Two more columns are added
A column for files or tables that will be
required to produce the report
An indication of whether the report is for a
single instance of the file or includes a large
set of records such as the entire file
Using Object-Oriented Models
Outputs are indicated by output messages in
sequence diagrams (the message originates from an
object internal to the system and has as
destination an external actor)
In Figure 10-8 the output message Confirmation
( ) is an example of an output message
A review of all the output messages generated
across all sequence diagrams provides the
consistency check against all required outputs
identified from analysis phase

41
FIGURE 10-16 A table of system outputs with data
requirements.
42

Output messages that are based on individual
object (or record) are usually part of the
methods of that object class
To report on all objects within a class, a
class method is used (a class method is a method
that works on the entire class of objects, not a
single object)
E.g. a customer confirmation of an order is an
output message that contains information about a
single order object
However, to produce a summary report of all
orders for the week, we need a class method that
looks at all the orders in the order class and
sends output information for each one with an
order date within the weeks time period
In Figure 10-10 the class method
ListLargeAccounts () sends output messages for a
report that lists all accounts whose purchase
have been gt 10,000
An interface class (the circles) can be added to
represent this output interface
Designing and Prototyping Reports
Two principles to keep in mind during design of
output reports
What is the objective of the report
Who is the intended audience?
Designers must decide on the level of detail
and format of the report ,so must know objective

Without careful consideration, a report can
easily get information overload (the problem of
providing too much information to users without
providing techniques to organize and search the
information)
Same kind of problem when search Internet and get
too many results
The format of the report is also important.
Every report should have a meaningful title to
indicate the data content
The report should contain a heading that lists
information such as the date
The report should be paginated
Labels and headings should be used to ensure
the correct interpretation of the data. Charts
should be clearly labeled with identification of
units of measure and a legend (Figure 10-12 shows
labels and headings on the report)
Control breaks should be used to divide the
data into meaningful units
Use of lines, boldface and different size fonts
makes reports easier to read