0% found this document useful (0 votes)
8 views15 pages

BM183 Handout

Chapter 8 discusses basic system concepts and tools essential for developing information systems, emphasizing a holistic systems view and the importance of interrelated components. It outlines the systems analysis and design process, business processes, and the role of IT in enabling business process redesign. Key techniques for developing information systems, including procedural and object-oriented approaches, are also detailed, highlighting the significance of structured methodologies in system development.

Uploaded by

kimberly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views15 pages

BM183 Handout

Chapter 8 discusses basic system concepts and tools essential for developing information systems, emphasizing a holistic systems view and the importance of interrelated components. It outlines the systems analysis and design process, business processes, and the role of IT in enabling business process redesign. Key techniques for developing information systems, including procedural and object-oriented approaches, are also detailed, highlighting the significance of structured methodologies in system development.

Uploaded by

kimberly
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Dela Cruz, Mary Abygail Louise BM 183 WWX

Lorenzo, Belle Angela Group 9


Tubaran, Ricardo Louis

CHAPTER 8: BASIC SYSTEM CONCEPTS AND TOOLS

Chapter Outline
● The System View
● Business Processes
● Processes and Techniques to Develop Information Systems
● Information Systems Controls to Minimize Business Risks

THE SYSTEMS VIEW


● more holistic systems thinking is needed to enable organizations to more quickly adapt
to today’s complex, fast-changing environments.
● Systems thinking:
○ a discipline for seeing wholes
○ a framework for seeing interrelationships rather than things
○ an antidote to the sense of helplessness one feels when confronted with
complexity

System — is a set of interrelated components that must work together to achieve some
common purpose
● Even when a given component is well-designed, simple, and efficient to operate, the
system will malfunction if the components do not work together.
● A change in one component could affect other components.

Information system (IS)


● collection of IT, procedures, and people responsible for the capture, movement,
management, and distribution of data and information.
● Components must be consistent, minimally redundant, complete, and well connected
with one another.

Seven Key System Elements — one or more of these elements that change or are created
when we redesign or design a new (information) system.
1. Boundary — The delineation of which elements (such as components and storage) are
within the system being analyzed and which are outside
2. Environment — Everything outside the system; provides assumptions, constraints, and
inputs to the system
3. Inputs — The resources (i.e., data, materials, supplies, energy) from the environment
that are consumed and manipulated within the system.
4. Outputs — The resources or products (i.e., information, reports, documents, screen
displays, materials) provided to the environment by the activities within the system.
5. Components — The activities or processes within the system that transform inputs into
intermediate forms or that generate system outputs
6. Interfaces — The place where two components or the system and its environment meet
or interact
7. Storage — Holding areas used for the temporary and permanent storage of information,
energy, materials, and so on

Formal vs. Informal Systems


● Formal system — way an organization was designed to work
● Informal system — is developed when there are flaws in the formal system, or when the
formal system has not been adapted to changes in business situations
○ Formal system ≠ real system

System Characteristics — important for analyzing and designing information systems


1. Determining the system boundary
● Boundary: delineates what is inside and what is outside a system.
● Arbitrary: we can often choose to include or exclude any component in the
system. The choice of where to draw the boundary depends on various factors:
a. What can be controlled
● Recognizing you can’t control everything
b. What scope is manageable within a given time period
● Complex systems often take so long to design and develop that
the envisioned systems solution could no longer be the best
choice by then time the project is complete.
c. The impact of a boundary change
● The business changes or new information about the organization
is uncovered, a different system boundary can appear to be
beneficial.
2. Breaking down a system into modules (decomposition)
● System: like an assembled product, is a set of interrelated components
● Subsystem (module): component of a system that is itself viewed as a system (or
a set of interrelated components)
● Hierarchical (or functional) decomposition: process of breaking down a system
into successive levels of subsystems, each of which shows more detail
○ Shows a high-level view of the system with two subsystems:

○ Shows details about one of these subsystems

● Five important goals of hierarchical decomposition of a system:


1. To cope with the complexity of a system
2. To analyze or change only part of the system
3. To design and build each subsystem at different times
4. To direct the attention of a target audience
5. To allow system components to operate more independently
3. Designing interfaces between old and new systems
● Interface: point of contact between a system and its environment or between two
subsystems.
● Functions of an Interface:
1. Filtering Disposing of useless data (or noise)
2. Coding/decoding — Translating data from one format into another
3. Error detection and correction — Checking for compliance to standards
and for consistency
4. Buffer — Allowing two subsystems to work together without being tightly
synchronized, as by having the interface collect data until the next
component is ready to accept the data
5. Security — Rejecting unauthorized requests for data and providing other
protection mechanisms
6. Summarizing — Condensing a large volume of input into aggregate
statistics or even mathematical parameters to reduce the amount of work
needed by subsequent subsystems
● Objectives of an interface:
○ Interfaces also can be built between preexisting independent systems
■ Called bridges because they connect two “island” systems.
■ Bridges are expedient ways to accomplish the goal of expanding
the capabilities of any one system.
■ Federated systems: multiple systems coupled by interfaces.
○ System decoupling
■ Two highly coupled system components require frequent and rapid
communication, thus creating a dependence and bottleneck in the
system.
■ Principal methods of system decoupling:
● Slack and flexible resources — Providing alternative paths
to follow when one component breaks down or slows down
● Buffers — Storing data in a temporary location as a buffer
or waiting line that can be depleted as the data are
handled by the next component
● Sharing resources — Creating shared data stores with only
one program (part of the interface component) maintaining
the data, thus avoiding the need to synchronize multiple
step updating or to operate with inconsistent multiple
copies of data
● Standards — Enforcing standards that reduce the need for
two components to communicate

Organizations as Systems
● Four fundamental components in an organization that must work in concert for the whole
organization to be effective
○ If a change in IT is made in an organization—such as the introduction of a new
software application—this change is likely to affect the other three components
○ Each time we change characteristics of one or more of these four
components, we must consider compensating changes in the others.

Systems Analysis and Design (SA&D) — major process used in developing a new information
system; based on a systems approach to problem solving
● Choose an appropriate scope
○ Selecting the boundary for the information system greatly influences the
complexity and potential success of an IS project
● Logical before physical
○ You must know what an information system is to do before you can specify how a
system is to operate.
○ Logical descriptions: concentrate on what the system does
○ Physical descriptions: concentrate on how the system operates.
○ “Function before form.”
● Problem-solving steps
○ Problem (or system): a set of problems; appropriate strategy is to keep breaking
a problem down into smaller and smaller problems, which are more manageable
than the whole problem.

BUSINESS PROCESSES - a chain of activities required to achieve an outcome, such as order


fulfillment or material acquisition.

Identifying Business Processes


● Core processes identification is crucial for analyzing a firm, as noted by Peter Keen
(1997).
● A manufacturing firm might have six core processes, including market sensing, product
development, material sourcing, manufacturing, selling, and order fulfillment. These
processes should be seen as assets and liabilities, not just workflows.
● Keen emphasizes that process importance varies between companies and even within
the same company in different circumstances.

Business Process Redesign


● Michael Hammer, a reengineering expert, advocated starting anew in business
processes, emphasizing radical change over automation.
● Business Process Reengineering (BPR) emerged in the early 1990s, aiming for
dramatic improvements by challenging long-standing assumptions in organizational
structures.
● Disruptive technologies, like telecommunications and tools such as WebEx, can trigger
radical redesigns.
● The goal of BPR is to achieve significant improvements, not just incremental gains.
Two BPR Success Stories by Hammer
● Accounts Payable at Ford Motor Company
Ford aimed to redesign its accounts payable process, initially planning a 20%
reduction in headcount. The initial solution involved a new system to address document
mismatches, assuming coordination problems were inevitable. Ford's pride diminished
when compared to Mazda, which achieved the same function with five people. Ford's
original solution was based on outdated assumptions, like the necessity of invoices for
payment. A truly reengineered solution emerged when Ford questioned assumptions,
involving scanning receipts at the loading dock and paying vendors based on validated
receipts. This "clean slate" approach resulted in a 75% improvement gain, surpassing
the original 20% projection.

● Mutual Benefit Life Insurance


Mutual Benefit Life's old insurance application process was complex, involving 30
steps and 19 people across 5 departments. Instead of automating the existing
workflows, the process underwent a radical redesign. The reengineered process
empowered an individual case manager to handle the entire loan application process.
Support included an advanced PC-based workstation, expert system software, and
access to automated systems. The result was a significant efficiency improvement,
reducing the time to issue a policy from three weeks to about three hours.

IT as an Enabler of BPR
IT played a crucial role in enabling radical business process redesign. Hammer and
Champy (1993) urge managers to use IT to challenge old assumptions. Hammer (1990)
advocated six key principles for business process redesign.

1. Organize business processes around outcomes, not tasks. This principle involves
having one person manage an entire process. It consolidates information for this
individual, and it often means organizing processes around customer needs instead of
the product.
2. Assign those who use the output to perform the process. This principle emphasizes
holding those with a vested interest in a result accountable. This streamlines processes,
leveraging information technologies to allow managers to handle tasks traditionally done
by specialists.
3. Integrate information processing into the work that produces the information. This
principle advocates processing information at its source. This minimizes errors and
reconciliation steps by capturing data closest to where errors can be detected. It
emphasizes capturing data once at the primary source, promoting a common and
consistent data source.
4. Create a virtual enterprise by treating geographically distributed resources as
though they were centralized. This principle suggests that IT eliminates the artificial
distinction between centralization and decentralization. Technologies like
teleconferencing and shared databases enable efficient information processing across
time and space.
5. Link parallel activities instead of integrating their results. This principle advocates
continuous coordination of related activities instead of waiting until the final step for
consistency.
6. Have the people who do the work make all the decisions, and let controls built into
the system monitor the process. This principle leads to a significant reduction in
management layers, empowers employees, and streamlines bureaucracy. It underscores
the importance of integrating controls into a system from the beginning rather than as an
afterthought.

PROCESS AND TECHNIQUES TO DEVELOP INFORMATION SYSTEMS

The Information Systems Development Life Cycle

● Three phases of a generic systems development life cycle (SDLC)


○ Definition — end users and systems analysts conduct a multistep analysis of the
current business operations and the information system or systems in the area of
concern.
■ Process-oriented Analysis — concentrates on the flow, use, and
transformation of data.
■ Data-oriented Analysis — focuses on the kinds of data needed in a
system and the business relationships between these data.
○ Construction — the designing, building, and testing of a system that satisfies
the requirements developed in the Definition phase.
○ Implementation — business managers and IS professionals work together to
install the new system, which often involves converting data and procedures from
an old system.
★ Maintenance — includes changes resulting from flaws in the original design.

Structured Techniques for Life-Cycle Development


● Structured Techniques — a body of tools used to document system needs and
requirements, functional features and dependencies, and design decisions.
● Two Major Approaches to Systems Building
(1) Procedural-Oriented Systems — include data-oriented as well as sequential,
process-oriented activities, such as tabulating time cards and printing paychecks,
inventory handling, and accounts payable.
(2) Object-Oriented Techniques — a newer approach which often is used with
prototyping-like methodologies; better suited to the development of graphical
user interfaces (GUIs) and multimedia applications.

Procedural-Oriented Techniques
● Fundamental Procedural Approach to Systems Development
(1) Describe what you have
(2) Define what you want.
(3) Describe how you will make it.
● Three-Step Modeling Approach

➔ The approach involves documenting the existing system (the As-Is model),
creating a model of the desired future system (the Logical To-Be model), and
then interpreting the logical future model as a physical system design (the
Physical To-Be model).

Techniques for the As-Is Model


● As-Is Model — provides a baseline for the system; includes both logical (what; functions
and processes) and physical (how; technology, including people and timing) models.
● Context Diagram — positions the system as a whole with regard to the other entities
and activities with which it interacts; provides a common frame of reference for project
participants and helps define the project scope.

● Work Process Flow Diagram — identifies the existing information sources (i.e.,
purchase order file, receipts file), information sources that are updated (changes to
invoices/payables), the order in which steps occur (approvals before checks are printed),
and some of the dependencies or decisions (need to know whether vendor is new or
not).

Techniques for the Logical To-Be Model


● Logical To-be Model — involves a critical appraisal of existing work processes in order
to:
○ identify major subprocesses, entities, and their interactions.
○ separate processing from the flow of data
○ capture relationships between data elements
○ determine those entities and processes within the project scope, and those that
are not
● Data Flow Diagram (DFD) — maps out the flow of information for any process or
system. This involves groups of people and is accomplished through multiple iterations.
○ Four types of symbols used in DFDs:
(1) External Entity — indicates some elements in the environment of a
system that sends or receives data.
(2) Data Flow — indicates data in motion.
(3) Process — processing of components of the system.
(4) Data Store — depicts data at rest.
○ Processes of creating DFDs:
(1) Identify the entities that supply or use system information.
(2) Distinguish processes from the data that they use or produce.
(3) Explicate business rules that affect the transformation of data to
information.
(4) Identify logical relationships.
(5) Pinpoint duplicate storage and movements of data.

● Data Dictionary/Directory (DD/D) — the goal is to maintain the metadata as completely


as possible; these entries should err on the side of too much information, rather than too
little.

● Data Model — created by logically defining the necessary and sufficient relationships
among system data. The most common notation for a data model is an
entity-relationship diagram or ERD.
Techniques for Documenting the Physical To-Be System
● Physical To-Be Model — a high-level model; communicates how the new system will
work and helps identify any dependencies that might lead to downstream impacts, such
as data integrity problems or inadequate process definitions.

Object-Oriented Techniques
● One of the key advantages of object-oriented development is that it allows for the reuse
of pre-programmed objects created by others. This means you can quickly build
prototype applications with use-friendly interfaces and simplify the process of
maintaining software.

Core Object-Oriented Concepts


● Object — created by instantiating a Class; it is anything that has an attribute and a
purpose.
● The attributes of an object and its methods are hidden inside the object. This means that
one object does not need to know the details about the attributes and methods of
another object. Instead, objects communicate with each other through messages that
specify what should be done, not how it should be done.

Two Principles
(1) Encapsulation — storing data and related operations together within an object.
(2) Inheritance — OOP technique used to inherit attributes and methods from one class to
another.
(a) Superclass — the class where inheritance of attributes and methods take place.
(b) Subclass — the class who will inherit the attributes and methods from a
superclass.

Information Systems Controls to Minimize Business Risks


Common system security risks include the following: (1) human error; (2) risks from
criminal acts; (3) risks due to staffing changes and project management deficiencies; and (4)
risks from natural disasters. All these risks have the potential to cause not only dissatisfied
customers but also considerable business expenses for error correction.

Types of Control Mechanisms


Control mechanisms include management policies, operating procedures, and auditing
functions.
● The purpose of information system control encompasses maintaining data integrity,
allowing authorized access, ensuring proper system operation, and protecting against
malfunctions, power outages, and disasters.
● Routine operation controls comprise backups, authorization security, and formal system
audits.
● Security controls related to technology infrastructure, including backup power supplies,
network access control, and firewall protection, are managed by the IS organization.
● It is the business manager's responsibility to specify checks and balances for accurate
data entry, identify valid data, assess potential errors, address nontechnical security
risks, and mitigate business losses.
● Distributed computing applications necessitate increased reliance on network
transmission, requiring additional technical and managerial controls.
Controls in the Definition and Construction Phases

Methodology Standards
The foundation of a system’s reliability lies in its design and construction. Automated
checks alone cannot compensate for errors in the software.

● Function Libraries
○ Create a library of frequently used functions for various information systems.
○ Develop and test functions meticulously, saving time and minimizing design and
programming flaws.
● User Interface Standards
○ Organizations’ established standards for designing user interfaces.
○ Guidelines for screen and report layouts contribute to consistent and user-friendly
designs.
● Importance of Documentation
○ Complete and accurate documentation during construction and maintenance is
crucial.
○ Future programmers rely on thorough documentation to be aware of prior
changes.
● Information Technology Infrastructure Library (ITIL)
○ A comprehensive set of international guidelines for IT management.
○ Encompasses best practices for incident management, problem resolution,
system changes, and more.
● Benefits of ITIL
○ Reducing IT costs, increasing utilization, and aligning IT with business
requirements.
○ Emphasizes the reuse of proven methods, customer satisfaction, and overall
operational efficiency.
● IT Service Management Forum (ITSMF)
○ Professional society promoting ITIL methods.
○ Offers education and certification and advocates the value of ITIL for IT
professionals.

Validation Rules and Calculations


Robust validation processes and checks are crucial for maintaining data integrity,
preventing errors, and supporting business growth. Business managers play a key role in
defining and enforcing these measures.

● Data Element Updates


○ Check new values against legitimate sets or ranges.
○ Perform checks in application programs and the database to maintain data
integrity.
● Edit Rules
○ Stored ideally with the database to ensure data completeness, validity, and
consistency.
○ Validate against missing data, appropriate size and type, and alignment with
other stored values.
● Screen Display for Verification
○ Display associated data (e.g., vendor name and address) for visual verification
during data entry.
○ Edit rules to ensure only valid numbers, codes, and calculations are entered.
● Dropdown Lists for Data Entry
○ Minimize keystroke mistakes by selecting values from dropdown lists.
○ Integrity rules control data validity in the user interface.
● User Interface Design
○ Well-designed interfaces prevent data entry mistakes.
○ Clear labels, edit masks, examples, and buttons for quick error correction
enhance user control.
● Immediate Error Messages
○ Prompt error messages indicating the nature of the error and corrective action.
○ Allow overriding data entry rules only when necessary, with logged traces for
auditing.
● Validation through Calculations
○ Batch totals are calculated manually and by the computer to identify
discrepancies.
○ Check digits for critical identifying numbers for quick verification and error
detection.
● Business Managers' Role
○ Define legitimate values and control calculations in the data dictionary.
○ Set policies for overrides and authorization, ensuring validation rules support
business growth.
● Validation Rule Flexibility
○ Permit business growth while reducing the likelihood of erroneous data.
○ Validation rules should adapt to evolving business needs.

Systems Testing
● Essential IS control involves conducting complete system testing.
● Controls in the Implementation PhaseIndividual and combined testing of each
program within the application is necessary.
● Managers play a crucial role in creating test data with known results, covering typical,
atypical, correct, and erroneous scenarios.
● Testing is applicable during both the initial system development and subsequent
modifications.
Security
● Logical access controls focus on user permissions, managed through authentication and
authorization mechanisms.
● Authentication verifies user identity with unique identifiers and private passwords, while
authorization grants resource access based on permissions.
● Encryption safeguards data transmission and storage, rendering files unreadable without
the decryption algorithm.
● Physical security involves measures like badge readers, voice/fingerprint/retina
recognition, and combination locks.
● Detection methods for security breaches include hiding instructions in sensitive
programs, analyzing computer time usage, and reviewing system activity logs.

Backup and Recovery


● Ultimate protection against system failures means storing backup copies separately, like
in a bank vault.
● Transaction logs track changes chronologically, allowing automatic backup copies of the
current status.
● A common flaw in backup plans is storing backups in the same location as the master
file, risking a loss in disasters.
● Secure off-site locations with foolproof tracking systems are crucial for effective backup
plans.
● Redundant systems and mirrored operations at distant facilities, known as "hot sites,"
enhance recovery from power/network outages or natural disasters.
● Ongoing backup and recovery costs must align with potential organizational benefits and
risks.

Auditing Roles
● Audits may align with annual accounting audits, compliance with regulations like
Sarbanes-Oxley, Basel II, or health-care regulations such as HIPAA.
● EDP (Electronic Data Processing) auditors use methods like compliance tests, statistical
sampling, and embedded auditing to ensure correct data processing.
● Compliance tests check for high-quality system development procedures, while
statistical sampling identifies abnormalities.
● Embedded auditing includes reporting triggers activated by specific processing events
and analyzing flagged records for errors or security breaches.
● Audit trails, tracing transactions from input through processes and reports, help identify
errors and security breaches.

Reference:
Brown, Carol V., et al, (2012) Managing Information Technology, 7th ed., Pearson

You might also like