Transcript Quick history of IS - University College Cork

Quick history of IS
• Very rapid growth as a profession and an academic
discipline
• early days of “computer is beautiful” lead to mistakes
– loads of requests to computerise
– crude methods of development and analysis
– business applications not well understood
• discouragement and scepticism as a result
• maturation was required on both theoretical and practical
sides (ie: technology and management)
• IS is established as a discipline (?) and functional area
Has Lead to...
• ability to use information systems technology is
essential for success
• some companies apply IT with great benefit; others
make no progress at all
• “reactive approach” to IT no longer works
– too much novelty too fast
– technology more and more powerful and less and less
predictable
• role of business managers in introducing IT has
become paramount
Growth of IS
• Number of people involved:
– In companies
– In society at large
• Importance:
– very visible information systems
– size of investments
• Notoriety:
– Internet…
– public perception
Change of Focus in IS:
• Very Technical
–
–
–
–
–
specialists’ domain
centralised concentrated expertise
expensive
well guarded
computer based
• Very Managerial
–
–
–
–
–
every manager’s business
decentralised awareness
very cheap
service department more open to the outside
information based
Early definition of IS
(An) information system is an organised method of
providing past, present and projection information
relating to internal operations and external intelligence.
It supports planning, control, and operational functions
of the organisation by furnishing uniform information in
the proper time-frame to assist the decision maker.
(Kenneron, 1970)
Another definition centred on
Human Activities?
(An information systems is a) system which assembles,
stores, processes and delivers information relevant to
an organisation (or to society), in such a way that the
information is accessible and useful to those who wish
to use it, including managers, staff, clients and citizens.
An information system is a human activity (social)
system which may or may not involve the use of
computer systems.
(Avison & Fitzgerald, 1988)
Another definition centred on the
social integration of IS
One of the components (or sub-systems) of an
organisation is the information system. The
components of this system are people, hardware,
software, data and procedures.
(Ahituv & Neumann, 1990)
Another definition centred on
Computer Systems
An information system is a formalised computer information
system that can collect, store, process, and report data from
various sources to provide the information necessary for
managerial decision making.
(Hicks, 1993)
What is Information?
• General definition (Oxford):
“News, intelligence or knowledge communicated; the act of
informing”.
• In management terms:
“Data which have been processed by a human mind”
What is Information?
• The result of a process whereby:
DATA
Human Mind
INFORMATION
Information System
DATA
Computer
INFORMATION
INFORMATION
Starting Point:
1 - Information is a key corporate resource
2 - Information must be regarded as an investment
3 - Information systems are a strategic resource that can
generate competitive advantage and Competitive advantage
is what makes companies win
Information as a key resource:
• General examples:
– Travel agent
– Stock traders
• Within a company:
–
–
–
–
–
–
Profit
Status of customer orders
Productivity
Stock levels
Market share
Opinions of customers
Information as Investment:
• Information is not freely available
• Information has a cost
– eg?
• Information has benefits:
– eg?
• Decisions to invest in Information
Information for competitive
advantage:
Mickael Porter and Victor Millar (1982)
• information technology is changing the way companies
operate internally and externally
– it alters industry structures
– it supports differentiation strategies
– it opens new businesses
• New technologies can be used to exploit information to
gain competitive advantage
Analysis of existing SIS:
• SIS were never intended to be strategic
• They rarely involve radically new technology
• They rarely originate in the IT function
• They are generally based on a “first mover”
advantage, but there have been some striking counterexamples
• Ability to handle huge amounts of information is often
main factor - ie: use of DBs
Evidence of the Importance of IS
• Change in the nature of applications
• Change in the perception of top managers
– 3 eras (Read Rockart
• Development of Strategic Systems
– change the nature of the relationship with customers / competitors /
suppliers
– provide better integration of information usage
– enable organisations to deliver new services or products based on
information
– provide information to managers for strategic purposes
Link with suppliers:
• American Hospital Supply Corporation (AHSC): system
whereby customers can directly re-order their supplies
from terminals located in their hospitals
• Successful because it enabled AHSC’s customers to cut
their costs of administration
• originally meant as an INTERNAL systems by AHSC and
extended to one main customer
Improved Integration of
Internal processes
• SABRE (American Airlines): first effective electronic
reservation systems in the US
• simple one-line database application
• took a long time to justify the investment
• competitive value of system still felt today
• in 1988 AA were making more money out of SABRE
than out of flying air planes
Information Based products
• Merrill Lynch’s integrated banking service
• cash management account
• combined up to then separated services into a single
statement
• automatically moved funds to higher interest accounts
• Merrill Lynch captured assets worth $1 billion in the first
year alone
Provision of Executive
Information
• EIS
• Greater visibility on the work of lower levels enables
greater levels of delegation
• Acceleration of communication
• Support for collective decision making
• Access to external information
• etc...
Formal Techniques to exploit
IT
• Business System Planning (BSP): IBM in the 1970s
– 13 different steps
– very cumbersome, expensive and long
• Strategic Planning for IT
– to provide a solid technical foundation
– alignment with the corporate strategy
• Application Generator: C. Wisemann
– aimed at outside opportunities
– up to 100 potential applications per company
More Formal Strategic Models BSP
• Business Systems Planning (BSP)
• Proprietary IBM technique mid 70s
• Data flow mapping technique - output of one process
becomes input into another
• Geared towards the creation of a central data repository
• top-down planning followed by bottom-up implementation
• Huge costs huge volumes of documentation
• Little possibility to build-in the competitive position of the
firm
Porter’s Competitive Analysis
(1980)
• based on the “five forces” matrix
• scope includes the entire business
• According to the framework, organisations' ability to
compete is determined by:
The threat of new competitors
The threat of substitute products or services
The bargaining power of customers
The bargaining power of suppliers
The rivalry amongst existing competitors
Rockart’s CSF method:
• Identification of a hierarchy of performance measures
that lead to identification of Critical Factors and Issues
that will determine a business’ success
The business mission statement
The business vision statement
multiple business goals
multiple business objectives for each goal
multiple CSFs for each objective
See Figure 2
McFarlan and McKenney’s
framework:
High
Turnaround
Strategic
Support
Factory
Strategic
Potential
of IS/IT
Low
Low
Strategic Importance
of Current IS/IT
High
McFarlan and McKenney’s
framework:
High
Strategic
Potential
of IS/IT
Education
Farming
Newspaper
Banks
Travel agents
Cement Factory
Funeral Homes
Retail business
Restaurants
Low
Low
Strategic Importance
of Current IS/IT
High
Quick Introduction to Tutorials
• MS Access: Development of Database Applications
• Cheap well-known Relational Database engine
• Includes a complete user-friendly environment for the
development of applications:
–
–
–
–
Interface,
report generator,
menus and forms
multiple wizards
• Also a bit of Oracle: to learn how to use structured query
language (SQL).
Basics of data Organisation:
DATA HIERARCHY (four categories)
• Fields = represent a single data item
• Records = made up of a related set of fields
describing one instance of an entity
• File = a set of related records - as many as instances
in the set
• Database = a collection of related files
Example of data structure
Fields
Records
File
Name
First name Telephone
Borg
Healy
McEnroe
Cantona
Bjorn
Margaret
John
Eric
45 25 65 65
25 58 96 63
12 25 28 89
25 78 85 85
+ Other files
ie: more information
Database: Definition.
"A collection of interrelated data stored together with
controlled redundancy, to serve one or more applications in
an optimal fashion; the data is stored so that it is
independent of the application programs which use it; a
common and controlled approach is used in adding new
data and in modifying existing data within the database."
Definition - closer look
•
•
•
•
A collection of interrelated data stored together
with controlled redundancy
to serve one or more applications in an optimal fashion
the data is stored so that it is independent of the
application programs which use it
• a common and controlled approach is used in adding new
data and in modifying existing data within the database.
Advantages of Databases:
• data are independent from applications - stored
centrally
• data are accessible to any new program
• data are not duplicated in different locations
• programmers do not have to write extensive
descriptions of the files
• These save enough money and time to offset the extra
costs of setting and maintaining DBs
Disadvantages of DBs:
• Data are more accessible so more easily abused
• DBs require expensive hardware and software
• specialised personnel is often required to start with large
DBs (but not Access!!)
• people may object to “their” data being widely available in
a DB (information is power??)
DataBase Management
System (DBMS):
• program that makes it possible to:
– create
– use
– maintain
a database
• provides a logical access to the data stored in the DB
• users/programmers do not have to worry about the
physical aspects of the DB
Using a database:
Two main functions of the DBMS :
• Query language - for people who are not programmer
(greatest advantage of DB)
• Data manipulation language - for programmers who
want to modify the links between data elements within
the DB
• Also, Host Language - the language used by
programmers to develop the rest of the application - eg:
Cobol, Fortran, Visual Basic......
Different types of DBs:
• creating the DB = specifying the links between data items
• different types of relationships can be specified - ie
different logical views
• they correspond to three main types of DBMSs:
– Hierarchical DBs
– Network DBs
– Relational DBs (most frequent)
Relational DBs:
• Data items stored in tables (records + fields)
• Specific fields from each table related to other fields in
other tables (joint)
• infinite number of possible viewpoints on the data
(queries)
• most flexible of all DBs but slower for complex
searches (many connections to follow)
• Oracle, SyBase on Unix, Access, Paradox for
Windows...
Describing relationships
• Attempt at modelling the business elements (entities)
and their relationships (links)
• Can be based on users’ descriptions of the business
processes
• Specifies dependencies between the data items
• Coded in an Entity-Relationship Diagram (ERD)
Types of Relationships
• one-to-one: one instance of one data item corresponds
to one instance of another
• one-to-many: one instance to many instances
• many-to-many: many instance correspond to many
instances
• Also some relationships may be:
– compulsory
– optional
Example
• Simple Sales Ordering
• What are the entities?
• What type of relationship do they have?
• Draw the diagram
Entity Relationship Diagram
Next step - creating the data
structure
• Few rules - a lot of experience
• Can get quite complex (paramount for the speed of the
DB)
• Tables must be normalised - ie redundancy is limited to
the strict minimum by an algorithm
• In practice, normalisation is not always the best
Data Structure Diagrams
• Describe the underlying structure of the DB: the complete
logical structure
• Data items are stored in tables linked by pointers
– attribute pointers: data fields in one table that will link it to another
(common information)
– logical pointers: specific links that exist between tables
• Tables have a key just like files
ORDER
Customer
order number
Item description
Item Price
Quantity ordered
Customer number
Item number
Customer number
Customer name
Customer address
Customer balance
Customer special rate
1
2
3
4
Item
Item number
Item description
Item cost
Quantity on hand
* compulsory attributes
0 optional attributes
Normalisation
• Process of simplifying the relationships amongst data items
as much as possible (see example provided - handout)
• Through an iterative process, structure of data is refined to
1NF, 2NF, 3NF etc.
• Reasons for normalisation:
– to simplify retrieval (speed of response)
– to simplify maintenance (updates, deletion, insertions)
– to reduce the need to restructure the data for each new application
First Normal Form
• design record structure so that each record looks the same
(same length, no repeating groups)
• repetition within a record means one relation was missed =
create new relation
• elements of repeating groups are stored as a separate entity,
in a separate table
• normalised records have a fixed length and expanded
primary key
Second Normal Form
• Record must be in first normal form first
• each item in the record must be fully dependent on the
key for identification
• Functional dependency means a data item’s value is
uniquely associated with another’s
• only on-to-one relationship between elements in the
same file
• otherwise split into more tables
Third normal form
• to remove transitive dependencies
• when one item is dependent on an item which is
dependent from the key in the file
• relationship is split to avoid data being lost inadvertently
• this will give greater flexibility for the design of the
application + eliminate deletion problems
• in practice, 3 NF not used all the time - speed of
retrieval can be affected
Creating links between the tables
• use common fields to join tables / queries
• very easy when data is properly normalised
• Gives total flexibility in terms of data retrieval
• Main strength of RDBs (SQL)
Structured Query Language
• used for defining and manipulating data in Relational
DBs
• aimed at:
–
–
–
–
–
–
reducing training costs
increasing productivity
improve application portability
increase application longevity
reduce dependency on single vendors
enable cross systems communication
• In practice, SQLs can be a bit different
Querying RDBs with SQL
• use a form of pseudo english to retrieve data in a view
(which looks like a table)
• syntax is based on a number of “clauses”
• Select: specifies what data elements will be included
in the view
• From: lists the tables involved
• Where: specifies conditions to filter the data
– specific values sought
– links between tables
Example with one table
• find the name and address of customer number 1217
Select name, address
from [customer table]
where cust. # = 1217
Example with a range
• find the items which are priced between £50 and £15000
Select item#, description, price
from [item table]
where price > 12000 and price < 20000
Example with two tables
• find the rep name of all customers
select [customer table].name, [rep table].[rep name]
from [customer table], [rep table]
where [customer table].[rep#] = [rep table].[rep #]
Example with two tables
• same for customer Murphy only
select [customer table].name, [rep table].[rep name]
from [customer table], [rep table]
where [customer table].[rep#] = [rep table].[rep #]
and [customer table].name = “murphy”
Use of a Search Condition nested queries
• find the name and address of the customer who ordered
order # 110
select name, address
from customer table
where cust. # =
(select cust. #
from order table
where order# = 110)
Additional syntax
• Add computation in the “select” statement:
– select SUM(price)
– select AVG(price), MAX, MIN, COUNT
• Simplify comparisons with a BETWEEN clause and LIKE
clause (with *, ?)
• Add sorting instruction after the where clause
– ORDER BY name (alphabetical)
– ORDER BY price (ascending)
• Provide aggregate information by grouping data:
– GROUP BY customer
• find contents (item# and description) of order 110:
Select [item table].item#, [item table].description
From [item table], [order line table]
Where [item table].item# = [order line table].item#
and [order line table].order# = 110
• find the average price of the cars for sale
Select avg(price)
From [item table]
• find the average price of all orders taken so far by
customer “Adam”
Select [item table].avg(price)
From [item table], [order line table], [customer table],
[order table]
Where [item table].item# = [order line table].item#
and [order line table].order# = [order table].order#
and [order table].cust# = [customer table].cust#
and [customer table].name = “Adam”
• find how much cash customer “Bowe” has generated in
total
Select SUM([order table].total)
From [order table], [customer table]
Where [order table].cust# = [customer table].cust#
and [customer table].name = “Bowe”
find the average price of all orders taken so
far
Select AVG(total)
From [order table]
First Sessions:
• Check out what the Access environment looks like
• Understand how the building blocks available fit together:
–
–
–
–
–
–
tables
queries
forms
reports
macros
modules
• Learn how to use some of the wizards
Oracle Demo Set Sales Order
Processing
CUSTOMER TABLE
SALES_ORDER TABLE
PRODUCT TABLE
ITEM TABLE
PRICE TABLE
DEPARTMENT TABLE
EMPLOYEE TABLE
LOCATION TABLE
JOB TABLE
Oracle Demo Set Employee Data
Functions of Database
Management Systems
•
•
•
•
•
•
•
•
•
Data storage retrieval and update facilities
A user-accessible catalogue or data dictionary
Support for shared update
Backup and recovery services
Security services
Integrity services
Services to promote data independence
Telecommunications
Utilities
Support for Logical
Transactions
• logical transaction = many separate physical transactions
(reading, updating, writing records)
• if transaction are interrupted before entire completion "up
to date" data is sacrificed for consistent data.
• If not, transaction is committed - ie written to disk
• DBMS provides mechanisms that either Commit or
Rollback transactions
SHARED UPDATE
• i.e. Two or more users making updates to database at
the same time
– Single vs. Multiuser Environment (eg: Networked DBMS)
• Problem: double update
– CUSTOMER BALANCE: 418
– Pat (recording sale: +100) and Jo (recording payment -100):
– CORRECT: Pat reads, updates and writes (commits: 518). Jo
reads (518), updates and writes (commits: 418).
– VALUE: 418.
– INCORRECT: Pat reads and updates. Jo reads and updates.
Pat writes (commit: 518). Jo writes (commit: 318).
– VALUE: 318.
SHARED UPDATE SOLUTIONS
• 1. AVOIDANCE:
– Prohibit shared update,
– Allow access for retrieval only,
– Record updates in transaction file and update database periodically
using a batch program.
• Problem: Data is temporarily out of date
• customer may not be allowed credit because his balance
had not been credited with last payment.
SHARED UPDATE SOLUTIONS
• 2. LOCKING
– Lock table/record/field from access by other users.
• TYPES OF LOCK
– Exclusive Lock
– Read Only Lock
– Lock Time-Out
• Other variables
– Lock Granularity
– Deadlock
• TYPES OF LOCK
– Exclusive Lock: Other users can neither read nor update locked
table/record/row. Extreme and inflexible.
– Read Only Lock: Other users can read but not update the locked
table/record.
– Lock Time-Out: If a record is locked, a user could have a long
wait for its release. Some DBMS's detect lengthy locks and unlock
them, undoing any updates made to any records during the
transaction.
– Lock Granularity: Refers to the level of the lock: field, record,
page/block, table.
– Deadlock: Users can have a lock on more than one record at a time.
This poses problems when two users require each others locked
records.
RECOVERY
1.
Backups or Saves (normal backup of DB files)
2.
Journaling / Audit trail / Audit file
– Keep a log or journal of the activity which updates the database
– recovery involves: Copying the backup over database and running
a special program to update the backup version of the database
with the transaction in the log.
SECURITY
• Restriction of access to authorised users only.
1.
2.
3.
4.
Passwords
Encryption
Views
Authorisation Levels
•
•
•
•
read only
edit
delete
create
Data Integrity
• DBMS provides a mechanism to enforce specific rules.
– Examples:
*Customer numbers must be numeric,
• But programmers must also develop their own
* Credit Limits must be £300, £500 or £1000 only,
* The sales rep for a given customer must exist,
* No customer may be deleted if he/she currently has an
order on file.
Data Independence
• DBMS must support the isolation of data structure from
the programs
• Users or application programs not be affected by changes
to the database structure. (no reprogramming or
recompilation)
• Logical and Physical Data Independence Usually achieved
through Subschema or View type mechanisms.
Database Schema
• description of the overall logical structure of a database,
expressed / programmed in Data Definition Language
(DDL)
• broken down into sub-schemas: logical description of a
user’s view or program’s view of the data used
• DDL can be very sophisticated on a mainframe or trivial
on a PC (queries / views)
Telecommunication
• organisations are rarely single site / single entity
• flows of data transcend the boundaries of organisations - so
do information systems
• data communication must be implemented
• databases can be used to support the distribution of
information resources
Integration of applications
• organisational data sources are varied
• all applications must be integrated to save time (ie:
exchange data)
• databases can be used to enable this integration (eg:
MFG/PRO)
• portability / compatibility is paramount (eg: ODBC
drivers)
Database Utilities
•
•
•
•
•
•
•
Compact datafiles
Index / re-index data files
Repair database (crash)
Import/export data from and to other sources
Enforce standards (eg: integrity of relationships, NF...)
Associated data dictionary
Access to remote computers (login, emulation)
Distributed Databases
• Logical next step in geographically dispersed
organisations
• goal is to provide location transparency
• starting point = a set of decentralised DBs located in
different places, developed for the specific
information needs of each site
• Aim: to integrate these decentralised DBs into a
coherent DDB
Advantages of Distributed
DBs:
• Increased reliability of systems and availability of data
• Local control preserved
• Modular growth possible at each site and at new sites
• Optimised communication costs
• Faster response times
Control in normal DBs
• transaction control: ability of the DBMS to ensure the
successful completion of transactions
– commit transactions
– roll-back to previous state
• concurrency control: ability of the DBMS to arbitrate
between concurrent uses of data:
– simultaneous access
– simultaneous update
– deletion
Control in Distributed DBs
• Different portions of the overall database reside at
different locations
• these portions are controlled by different processors
running sometimes different DBMSs
• common schema means queries can involve any portion
of the DB residing at any location
Options for Distributed DBs
• Issue of physical design (data structure)
• performance of the DB (response time...) depends upon
good design
• There are a number of options:
–
–
–
–
data replication
horizontal partitioning
vertical partitioning
combinations of the above
Data replication
• store a separate copy of the full tables in each location
• if a copy is stored at every site: Full Replication
• Advantages:
– reliability
– fast response
• Disadvantages
– storage requirements
– complexity and cost of updating
Horizontal partitioning
• some of the rows of the tables are stored in one location;
others are stored at other locations
• eg: customers banking out of a particular branch
• Advantages:
– efficiency
– local optimisation
– security
• Disadvantages:
– inconsistent speed access
– backup vulnerability
Vertical partitioning
• some columns are projected into base relationship at
different sites
• all relations share a common domain so the full table
can be reconstructed
• Advantages:
– tailor-made support for functional areas
– same as horizontal partitioning
• Disadvantages:
– some queries might be very slow
– users must understand some design issues
Combinations of the three
methods
• most of the time, companies will use different
methods
• each method is efficient in certain situations + some
other security requirements
• eg: local customers, information originating at a
certain site, shared processes that require the same
data at all sites
• it is a design issue to try to identify the optimal
distribution - data at the sites where it is used most
Distributed DBMS
• additional roles to play in the case of a distributed DB
• determine the location where data to be retrieved is
located
• translate the request into the language used by the local
DBMS
• deal with normal data management functions, security
matters, locking, query optimisation...
Heterogeneous Distributed
DBMS
• a different DBMS running at each site
• a master DBMS controlling the interactions amongst the
parts
• not practical today (compatibility)
• more often, each DBMS follows the same data architecture
Problems with global
transactions
• DBMSs can be radically different - relational versus
network
• only some state-of-the-art commercial products have
translating capabilities
• one alternative solution is to put some essential data
and the directory of the data locations on a central
server
• Real distributed DBMS solve these problems for the
users with the help of the NOS
Commit Protocol
• to ensure the integrity of the data in update operations
• well defined procedure based on the exchange of
messages (“ok” or “not ok”)
• each global transaction can either be complete (and
completed) or aborted
• Two-phase commit:
– site originating the transaction sends requests to all sites involved in
the update
– all sites attempt to process their part of the transaction without
committing the data (temp files)
– they notify the first site whether OK or not
– the first site collects all OKs and sends order to commit the data
Timestamping
• Alternative to locking (possibility of deadlocks)
• ensures that transactions are processed in serial order
so locking in not needed
• All updated records carry the timestamp of the
transactions that modified them
• if new transaction attempts to update a record with an
earlier timestamp = OK
• If new transaction ...with a later stamp, update access is
denied, the transaction is re-stamped and is re-started
Example:
Record in a DB
Record update: 170
168
OK
Updated record
170
Record Update: 165
Denied
Record Update: 170
Transaction re-started (ie: do it again)
Updated record
170
+++: costly deadlock situations are avoided
----: transactions may sometimes be restarted even though
they did not conflict with previous ones.
Effect of design on speed
• how to design fast queries
• simple example with two sites in relational DB:
–
–
–
–
–
supplier (Supplier#, ...,City): 10,000 records stored in Detroit
part (part#, .., colour): 100,000 records stored in Chicago
Shipment (supplier#,..., Part#): 1,000,000 records stored in Detroit
each record is 100 characters long + there are 10 red parts
data transmission is 10,000 character/second, 1 second delay in any
communication
– data processing negligible
• Write the SQL statement
• Imagine how the query can be carried out between the two
sites
SQL statement
select supplier.supplier#
from supplier, part, shipment
where supplier.city = ‘Cleveland’
and supplier.supplier# = shipment.supplier#
and shipment.part# = part.part#
and part.color = ‘Red’
Conclusions
• Reasonably easy to optimise query with two tables
• Very complex with more than two (try with 30!)
• Rules:
• Queries must be broken down into components isolated at
different sites (minimise communication time and traffic)
• Determine which site has the potential to yield FEWER
selected records
• Move preliminary results to site where rest of the work can
be performed (ie: try to move as few records as possible)
Problems with Information
Systems:
The following is a quote by the Finance Director of a
major UK firm:
“Computer people are painful people, they really are bad.
The gap is between my problems and getting them
solved, but our people don’t understand that, they are
just programmers, they know nothing about
management, nothing about financial information and
nothing about financial information structures”.
Scope of IS Development
• Software development is labour intensive
• Large software projects are amongst the most
expensive undertakings:
–
–
–
more than a domed football stadium
more than 50 floor building
more than a 70,000 tons cruise ship
• Managers have unrealistic expectations
• Large software projects have very high failure
rates
Complexity inherent in IS
development
•
•
•
•
•
Complexity of IS is not accidental (Brooks)
Problems tackled are complex
Project Management is difficult
Increasing flexibility allowed by tools adds complexity
Computers need “discretisation” of often continuous
situations
• External complexity is added by economic / political
constraints on the system
Failure rates
Fate of IS Projects
Faith of IS projects - Standish Group (1995)
+ effect of size
Abandoned projects
• Economical and technical factors are not major
• Organisational factors:
– loss of management commitment
– political and inter-personal conflicts
• Many well-known examples of failure of large systems in
last few years
• Notion of failure is uncertain in IS
– eg: Socrate
– different types of systems (as per the Application Portfolio
Analysis Matrix)
Systems Development Life
Cycle:
• SDLC is a Disciplined approach to systems development
• it cannot guaranty the success of the developments, but
provides a number of useful rules and guidelines
• There are many version of SDLC (nearly as many as
authors) but they nearly all say the same thing
What is an SDLC?
• SDLC stands for Systems Development Life Cycle
• it is a methodology (ie - a number of related methods and
techniques) aimed at facilitating and making more reliable
the development of new information systems
• it consists in breaking down the process in a number of
well-defined stages (five) and sub-stages
• those sub-stages can, in turn, be broken down in small tasks
which take one person a few days to carry out.
Principles underlying SDLC:
Principle #1: Get the user Involved
• there is a need to attempt to bridge the gap between
technical people and users
• the ultimate “owners” of the systems are the users - they
must like it
• their opinion and agreement must be sought by the
analysts
• Failure to do so will mean the system is useless
Principles underlying SDLC:
Principle #2: Use a problem solving approach
• ‘Problem’ means opportunity for improvement
1 - Identify the opportunity for change
2 - understand the context surrounding it
3 - define the requirements of a solution
4 - identify a number of such solutions
5 - select the “best” one
6 - design and implement it
7 - monitor acceptance and usage to refine solution
Principles underlying SDLC:
Principle #3: Establish phases and activities
• SDLCs consist of a number of phases
• the most recent SDLCs have additional phases based on
experience of what is needed
• when projects become too large, phases must be broken
down into tasks and sub-tasks
• This makes project management easier (you can check if
the project is on track more often)
Principles underlying SDLC:
Principle #4: Establish standards for development and
documentation
• projects involve many people each working on a number
of sub-tasks
• ultimately all the parts that people developed must be
integrated into a coherent system
• This requires consistency in the procedures used and the
documentation written
Principles underlying SDLC:
Principle #5: Justify systems as capital investment
• information systems must be regarded as investments
to be maintained
• development choices should be guided by
considerations of Cost Effectiveness
• Budgets and schedules are not a rough guidelines, they
must be followed and deviations from them must be
accounted for
Principles underlying SDLC:
Principle #6: Cancel and revise the scope of the projects
• after the completion of every sub-task, there is an
opportunity to revise the project
• if the project is going nowhere, the decision to
abandon it should be contemplated
• the fact that money has been spent on a bad project
does not mean it should be finished (even more money
will be spent)
Principles underlying SDLC:
Principle #7: “Divide and Conquer”
• All systems are part of larger systems or networks (eg:
WAN) called SuperSystems
• Most systems are made up of smaller systems called
SubSystems
• All these need to be taken into account so they neatly fit
within one another
• if a system requires changes in the supersystem, the
time/cost to do that must be build into the time/cost of
development of the new system
Principles underlying SDLC:
Principle# 8: Design systems for growth and change:
• real shortage of IS staff in organisations means backlog
of applications to be developed
• IS analysts should try to develop systems that meet more
than just Today’s user needs
• because more time is spent “fixing” old systems than
developing new ones
• IS staff need to be more pro active
A Systems Development Life
Cycle:
Systems
Planning
(Planning
Analysts)
Systems
Support
(Systems
Analysts
Designers
and
Builders
Systems
Analysis
(Systems
Analysts)
Systems
Implementation
(Systems
Builders)
Systems
Design
(Designers)
Business Mission
Initiation Stage
of a new system:
Systems
Planning
(Planning
Analysts)
B.I.S Plan
Planned
Applications
Systems
Support
(Systems
Analysts
Designers
and
Builders
Systems
Analysis
(Systems
Analysts)
Owners
Unplanned
Applications
Unplanned
Applications
Systems
Implementation
(Systems
Builders)
Systems
Design
(Designers)
Users
Analysis Stage of a new system:
Systems
Planning
(Planning
Analysts)
Systems
Support
(Systems
Analysts
Designers
and
Builders
Existing system’s details and limitations
Systems
Analysis
(Systems
Analysts)
Analysis
Report
Systems
Implementation
(Systems
Builders)
Systems
Design
(Designers)
Facts and
Requirements
Users
Design Phase of a new system:
Systems
Planning
(Planning
Analysts)
Systems
Support
(Systems
Analysts
Designers
and
Builders
Systems
Analysis
(Systems
Analysts)
Technical Design
Report
Systems
Implementation
(Systems
Builders)
Systems
Design
(Designers)
Opinions and
Recommendations
Users
Implementation Stage of a new system:
Systems
Planning
(Planning
Analysts)
Systems
Support
(Systems
Analysts
Designers
and
Builders
Systems
Analysis
(Systems
Analysts)
Actual Information
System Delivery
Systems
Implementation
(Systems
Builders)
End-user training
and documentation
Systems
Design
(Designers)
Users
Support Stage of a new system:
Existing system’s
Limitations
Systems
Support
(Systems
Analysts
Designers
and
Builders
Systems
Planning
(Planning
Analysts)
Problems using
the new systems
Systems
Analysis
(Systems
Analysts)
Systems
Implementation
(Systems
Builders)
Additional
Training and Support
Users
Breakdown of SDLC
• the five stages of SDLC are PLANNING,
ANALYSIS, DESIGN, IMPLEMENTATION and
SUPPORT - commonly broken down into a number
of sub-stages as follows:
– system planning:
• 1 - study the business mission
• 2 - define an information architecture
• 3 - evaluate business areas
– system analysis:
• 1 - survey project feasibility
• 2 - study and analyse current system
• 3 - define and prioritise user’s requirements
– system design:
• 1 - select the design target
• 2 - acquire necessary hardware and software
• 3 - design and integrate the new system
– system implementation:
•
•
•
•
1 - build and test networks and databases (if any)
2 - build and test the programs
3 - install and test the new system
4 - deliver the new system into operation
– system support:
•
•
•
•
correct errors
recover the system (after a crash)
assist the users of the system
adapt the system to new / evolving requirements
Systems planning:
• most organisations do not have planning phases in
their SDLC
• priority given to most influential / wealthy
departments regardless of potential importance of
project for the business
• on-going process to ensure that:
– information systems are developed according to the plan
– management decisions and external factors have not changed
the plan
• made up of three phases
Systems planning - definition:
• “The systems planning function of the life cycle seeks
to identify and prioritise those technologies and
applications that will return the most value to the
business.”
Systems planning - Phase 1:
Study the Business Mission
• All businesses have a mission (formulated or not)
• only way to ensure that ISs return value to the business is
to make them address that mission
• scope of the phase covers the entire business
• Key actor in this phase is the Planning Analyst
• Deliverable is the Business Plan
Systems planning - Phase 2:
Define an information system architecture:
• design of an IS plan that mirrors and supports the Business
plan
• plans must take into account existing systems, opinions and
recommendations of users and technology forecasts
• actors involved are the same as in previous phase
• deliverable is the IS plan
Systems planning - Phase 3:
Evaluate business areas:
• They are groups of logically related functions and activities
(concerned with the same processes)
• the overall plan needs to be refined to detail what is needed
in the different business areas
• Business Area Analysis (BAA) is very time consuming
(several months per area)
• managers and users in specific BAs must be involved as
potential developments must be prioritised
• deliverables are individual planned application development
projects
Systems Analysis:
• It is the study of a current business and information
system and the definition of the requirements of the
users for a new IS
• it is triggered either by a planned project (previous
phase) or by a spontaneous request by a user or owner
• It is made up of three phases
Systems Analysis - Phase 1:
Survey project Feasibility:
• Feasibility and investment evaluation are crucial (is
system worth looking at?)
• short 2 to 3 days preliminary study:
– plans
– problems
– opportunities...
• definition of the scope of the project
• systems analysts are main actors but users provide all the
information
Systems Analysis - Phase 1:
• the deliverable is a report recommending:
– a quick fix
– or an enhancement of an existing systems
– or a completely new application
• this report is reviewed by the system owners who:
–
–
–
–
approve the project and push it to next phase
or change the scope and push it to next phase
or reject the project
or postpone the project in favour of another one
Systems Analysis - Phase 2:
Study and analyse the current systems:
• Analyst must acquire a thorough understanding of:
– problems
– opportunities
– constraints and preferences of actors
• He/she delivers a Business Problem Statement submitted to
the system owners
• after approval, analysts will produce a system’s objectives
report to be passed to the next phase
Systems Analysis - Phase 3:
Define and Prioritise User’s Requirements:
• Find out exactly “what” the system will offer to the users
• main source of complaints about systems is “system does not do
what we want” - ie too much emphasis on the “how”
• Also try to assign priorities to requirements in case some of
them are sacrificed by Systems Owners
Systems Analysis - Phase 3:
• In addition to the common paper-based Analysis Report, two
methods can be used for this phase
• “Modelling” or using graphical representations to help user
understand what the system might be like
• “Prototyping” or creating a partial version of the system
which offers only some of the functions
• faster to develop
• cheaper to develop
• user can give immediate + reliable opinion on design
System Design:
• Given the detailed description of the users’ requirements
(Analyst’s Report), technical translation of what the system
does into how it works
• it consists in the specification of a detailed computer-based
solution
• Also called Physical Design
System Design - Phase 1:
Select a design Target:
• selection of a number of feasible design solutions
• How much of the system should be computerised?
• should we purchase software or develop it ourselves?
• what technology and type of computer would be
useful for this system?
Selection of the “best” design
solution:
• Technical feasibility - Do we have expertise?
• Operational feasibility - How will this affect the users’
work (will they resist)?
• Economic feasibility - Is it cost effective?
• Schedule feasibility - Can it be done within acceptable
timeframe?
Result of the first phase:
• a solution is selected - often a combination of the best
options
• finally, a Systems Proposal is put forward to the Systems
Owners
• Systems Owners might:
– Approve and fund the solution
– Select and fund one of the design solutions
– Reject the solutions and cancel the whole project or send it back for
more
– Approve a reduced-scope version of the solution
Systems Design - Phase 2:
Acquire necessary Hardware and Software:
• more and more software are purchased off-the-shelf
by organisations
• Selection process is crucial and not well understood
yet
• shop around for the lowest price
• shop around for the best service - potential danger area
+ / - of buying “turn-key”
solutions:
+
+
+
+
+
+
+
• system very reliable
• system can be seen in operation before buying (users
may even be interviewed)
• project much easier to schedule
• no need to have all expertise involved in-house
• Less risk that project is going to cost more than
expected
• some degree of customisation is often possible
• maintenance / support is part of the contract
+ / - of buying “turn-key”
solutions:
-
-
• no guaranty that required system exists
• selection of a supplier is difficult and time consuming
• difficult to say when one has contemplated enough
solutions
• potential expertise gap when buying
• difficult to get any competitive advantage out of a
system that everyone can buy
• situation becomes unmanageable in multi-supplier
situations
Design - phase 3:
Design and integrate the new system
• given the approved, feasible solution, system can finally be
designed - ie planning how it will work
• in addition, designers ensure that it will work in harmony with
existing systems
• the general design involves the structure of files and DBs, the
processing methods, the structure of networks...
• the detailed design involves the internal design (program logic)
and external design (user interface)
Systems Implementation phase:
• this is the construction of the new system (or its
development)
• it is totally based on the results - ie the reports of the
design phase (often called Technical Design
Statement)
• it is made up of four phases:
–
–
–
–
build and test networks and DBs (optional)
build and test the programs (documentation, testing)
install and test the new system
deliver the system (user documentation, training)
System Support phase:
• it involves the on-going maintenance of the system
after its delivery
• it also includes improvements to the system
• it is made up of a number of on-going activities rather
than sequential phases:
–
–
–
–
correct errors (bugs, lack of robustness...)
recover the system (crash, processing error...)
assist the users of the system
adapt the system to new requirements
Adapt the system to new
requirements
• new business problems identified by the users
• ideas for enhancement as identified by users or analysts
• new technical problems brought by evolving
circumstances (year 2000, increase in volume...)
• new technology available on the market which can
simplify or improve existing application
Cross Life Cycle Activities:
• activities that cover more than one phase
• activities that recur in a number of phases
–
–
–
–
–
–
–
fact finding (also data collection or information gathering)
documentation - recording facts and specification of the system
presentation - formally packaging the documentation
estimation - approximating time, effort, costs and benefits
measurement - measuring and analysing productivity and quality
feasibility analysis
project management - overall co-ordination and supervision activity for
the whole project
Techniques and Methods in use
during SDLC phases:
• tools and techniques for the initial steps
– fact finding techniques used to collect information
– tools and techniques to organise the data collected and identify the
gaps
• techniques for systems analysis - structured analysis
– graphic symbols - data flow analysis
– data dictionary
– techniques to document procedures and decisions
Fact finding techniques:
Interviews: structured or unstructured and with individuals
or with groups
• often favourite methods of analysts but not necessarily
best method
–
–
–
–
–
–
time consuming
can turn into questioning
not suitable for quantitative information
personal bias can occur (how to verify information???)
personality clashes can occur
requires a lot of skill from analyst
Interviews (2)
• however, it can be very useful:
–
–
–
–
for people who are not good at communicating in writing
for people who do not have time to reply to questionnaires
to discover areas of mis-understanding
to identify potential resistance to change
Fact finding techniques:
Questionnaires:
•
•
•
•
•
ideal to collect data from very large number of users
standardised questions mean more reliable information
anonymous answers are possible
can use open-ended or close-ended questions
However, problems can arise as:
– people can misunderstand questions
– it is difficult to evaluate how competent people really are
– it is difficult and time consuming to design good questionnaires
Fact finding techniques:
Record review:
• records include written policy manuals, standardised
operating procedures, guides...
• unfortunately, they rarely show what actually happens
• but they can help the analyst understand basic processes
• they are good for the initiation of the analyst
Fact finding techniques:
Observation:
• enables the analyst to gain information that could not be
obtained with other techniques
• first-hand information about what actually happens
• difficult to create conditions where the analyst is allowed to
observe without inferring with events
• potential “spy” effect
Techniques to organise the
details collected:
• Documenting how people work means analysing decisions
and procedures
• This requires a number of steps:
–
–
–
–
–
determine what the conditions are
identify the relevant decision variables
eg: the payment of an invoice can be Authorised or Unauthorised
identify the actions that should follow when conditions are met
graphically represent the procedures resulting using decision trees,
decision tables or Structured English
What are they used for?
• they are Process Description Tools
• used for the determination of systems requirements
• especially in the case of complex / multi-criteria decision
situations
• They are used by systems analyst to document such
situations and communicate with users
What is specific about them?
• they are aimed at enabling analysts to lift any ambiguity
regarding important decisions to be made by the system
• they enable them to show the users for confirmation in a
way that users can understand
• they can be processes directly by special code-generating
tools called CASE tools - thereby facilitating / speeding
up programming
Decision Trees:
• a decision tree is a graphical way to represent a sequence of
decisions and actions
• it shows which conditions to consider first, second etc...; ie it
helps to visualise the process to be followed to reach a good
decision
• it also shows the relationships between each condition and
the resulting actions
• It is very program-like in its format
Decision Trees:
• Example of a decision tree with two layers of conditions and four
different possible outcomes
Condition
Root
Condition
Condition
Action
Condition
Action
Condition
Action
Condition
Action
Example of decision tree:
• Discount authorisation in a company:
if payment was not made within 10 days, the customer pays the
full amount
if payment was made within 10 days, some discount may be
granted
if the amount in dollars is below £ 5000 the customer pays the full
amount
if the amount in dollars is between £ 5000 and £ 10000, 2%
discount is granted
if the amount is over £ 10000, 3% discount is given
Solution:
Within 10
days
Over £10000
3% discount
Between £5000
and £10000
2% discount
Below £5000
Full amount
How much
discount??
Longer than
10 days
Full amount
Usefulness of Decision trees:
• good at highlighting the sequence of business
decisions
• effective to describe business problems with many
conditions
• enable the analysts to verify the accuracy of their
understanding of processes by showing their DT to
users
• However, Decision Trees can become overly complex
when many interlinked processes
Decision tables:
• it is matrix of rows and columns that shows conditions and
actions
• it is made up of four categories:
–
–
–
–
condition statements
condition entries
action statements
actions entries
• it is like a decision tree, but there is no sequence - It applies
covers all situations
Decision tables:
Condition
Decision Rules
1
2
3
C1: Patient has basic health insurance
C2: Patient has social health insurance
Y
N
N
Y
Y
Y
A1: Pay amount of office call
A2: Pay nothing
A3: Pay full amount for services
X
X
X
4
N
N
X
Different forms of Decision
Tables:
• table entries can take a different form
• limited-entry form use entries like Yes, No and X
• extended-entry form use actual descriptions of actions and
conditions
• mixed-entry form (combination of previous forms)
• the ELSE form aims at omitting repetition (ie: ELSE = any
other conditions that leads to an action)
Example:
• Sales reps can get extra bonus when they sell our higher
margin goods
• Extra bonus is paid up to a maximum of £2000 per year
• It is paid 1 % up to £5000 ordered and 2% above £5000
• In any case, reps receive a letter of congratulation when
they take orders larger than £ 5000
• When they sell high margin goods, reps also enter a
monthly draw for a dinner in town
Structured English:
• additional method to overcome problems of
ambiguous language in stating requirements
• it uses narrative statements to describe procedures,
conditions and actions
• analyst lists the steps in the order in which they must
be taken until entire procedure is stated
• procedures consist of:
– sequence structures
– decision structures
– iteration structures
Components of Structured
English:
• sequence structures:
– are single steps or actions included in a process
– individually, they do not depend upon any condition
– a procedure typically consist of several sequences
example: buying a book
1 - pick the desired book
2 - take the book to the cash desk
3 - pay for the book
4 - leave the store
Components of Structured
English:
• Decision structures are used to describe the conditions which
regulate the execution of the sequences
example - buying a book
– the condition for the execution of the sequence is that a desirable book is
found
IF a desirable book is found, THEN
take the book to the cash desk
pay for it
leave the store
OTHERWISE
(or ELSE)
do not take the book to cash desk
check the next book
Components of Structured
English:
• Iteration structures are structures that are repeated 1- while
a condition is true or 2 - until a condition becomes true
example - buying a book:
DO WHILE more books to examine
read the title of the book
select or reject it
END DO
DO UNTIL desired book found
pick a book
read the title
select or reject
END DO
}
1
}
2
Real example - Accounts
Payable Processing:
Do until all invoices are processed
If invoice is signed then
log invoice - pay amount
Else
If merchandise was not accepted
Reject invoice
End if
If invoice is not priced properly
Correct invoice amount
log invoice - Pay new amount
End if
End if
End Do
Structured analysis of systems
requirements:
• Additional techniques to document requirements of new
systems
attempt to tackle two problems below:
• Would two analysts identify the same set of requirements
when they independently study the same system???
• How well defined are the applications that analysts get to
investigate by talking to users, studying current systems
etc.??
Tentative answers:
1 - If one can say that a systems analysis report is either
right or wrong then, the 2 analysts should come up with
the same requirements. But is this true?
2 - The settings in which ISs must be developed are illdefined and systems themselves are not stable.
Two different analysts are very unlikely to get to observe
the same situations
Structured Analysis as part of
the solution:
• manageable and logical way to learn and report about
a system
• the method attempts to “structure the requirement
determination process”
• It is based on the use of:
–
–
–
–
–
Structured English
Graphic symbols:
Data dictionary
Procedure and process description
Rules and standards for documenting systems
Data Flow Analysis:
• Major part of structured analysis involves Data Flow
Analysis:
•
•
•
•
What processes make up the system?
What data are used in each process?
What data are stored?
What data enter and leave the system?
The emphasis is clearly on identifying Data Flows.
Tools for Data Flow Analysis:
1 - Data flow Diagram: central tool for DFA on the basis
of which the components of the system are later
developed
2 - Data Dictionary: consists of the name, description,
aliases, contents and organisation of every data item in
the system and the processes in which they are used
3 - Data Structure Diagram: relations between the
different entities in the system
4 - Structure Chart: relations between processing
modules in a computer system
Notation used for DFDs
(according to Yourdon):
Data Flows look like:
Processes look like:
Sources or destinations of data look like:
Data stores look like:
Example of DFD:
Source
Data Flow 2
Process 2
Data Flow 1
Data Flow 4
Process 1
Data Flow 3
Destinat.
Data Flow 5
Data Store
Additional symbols used in
Data Flow Diagrams:
Three categories of symbols
• Media symbols = actual devices or objects that are
used to display, store or print data
• Processing symbols = processes that are used in the
system; they can be either automatic or manual
• Descriptive symbols: used to show the direction of the
flows and to make DFDs more readable
Rules in creating Data Flow
Diagrams:
Employee
membership
application
1
Create new
member
Account
bank statement
employee
status
Employee
3
generate
employee
bank
statements
employee
id and address
existing
account
Member accounts
modified
account
status
2
freeze
account
number
frozen account
notification
Accounts
Receivable
Dpt.
Process #1: Black hole !!
Process #2: Miracle!!
Employee
membership
application
1
Create new
member
Account
bank statement
employee
status
Employee
Process #3: Gray hole!!
3
generate
employee
bank
statements
employee
id and address
existing
account
Member accounts
modified
account
status
2
freeze
account
number
frozen account
notification
Accounts
Receivable
Dpt.
Rules in creating Data Flow
Diagrams:
Customer
Process
order
customer
transaction
order
Route
transaction
payment
Process
Payment
complaint
Process
complaint
Rules in creating Data Flow
Diagrams:
Process
order
order
Customer
payment
Process
Payment
complaint
Processes that do not make decisions
or change incoming data should be eliminated
Process
complaint
Rules in creating Data Flow
Diagrams:
Phone
Company
Invoice and itemised
calls statement
Invoice
Itemised calls statement
Pay phone
bill
If two flows always travel together, they should be shown as a simple
data flow
Rules in creating Data Flow
Diagrams:
Bill and credit
voucher
Process
order
Credit
receipt
Customer
Credit Vouchers
Due
Payments
Customer
receipt
Customer
Bill and credit
voucher
Process
order
Approved
credit voucher
Sale
Credit Vouchers
Due
Payments
Illegal Data flows:
You need a Process
Between all these elements:
“ All data flows must either
end or finish at a process “
Additional rules:
• Only processes can be connected to a data store
• A data flow from a data store to a process means that the
process USES the data
• A data flow from a process to a data store means that the
process UPDATES the data stored - ie:
– it adds new records
– it deletes existing records
– it changes existing records
• try avoid crossing lines on a DFD, eg by placing your data
stores in the middle of the page
Example of DFD:
• Analysis of Accounts payable
• Elements (data sources or destinations) in the diagram are:
– vendors
– vendor data
– accounts payable data
• Flows are:
–
–
–
–
invoice
check
mailing address
balance
• First level = only one process, here Accounts Payable
Solution of the DFD for
Accounts payable
Accounts payable
Balance
Vendor invoice
Vendor
Accounts
payable
processing
Mailing address
Vendor data
Cheque
This the level 1 DFD also called Context Diagram
Steps in solving the Decision
Table are:
1 - Identify the conditions and values
2 - determine the maximum number of rules
3 - identify the possible actions
4 - Enter all possible rules
5 - Define the actions for each rule
6 - Verify the accuracy of the table with users
7 - Simplify the table by eliminating impossible and
indifferent conditions
Steps in solving the decision
table:
1 - Identify the conditions relevant to the case and the
values that can be assumed:
Data Attributes and conditions:
1 - Account type:
R = Regular rate
S = Split Rate
2 - Insurance
Y = Yes
N = No
3 - Balance dropped below £25 during month?
4 - Average daily balance
Y = Yes
N = No
1 = £ 0 to £ 24.99
2 = £ 25 to £ 500
3 = £ 500.01 to £ 2,000
4 = more than £2,000
Steps in solving the decision
table:
2 - Determine the maximum number of rules:
that gives you the number of “solutions” of the problem
- like throwing dice
Condition # 1: 2 values
Condition # 2: 2 values
Condition # 3: 2 values
Condition # 4: 4 values
Number of rules in DT = 2 * 2 * 2 * 4 = 32
Steps in solving the decision
table:
3 - Identify the possible actions:
• Pay no dividend
• Pay 5.75% / 4 on the full balance of the account as a
quarterly dividend
• Pay 6 % / 4 on the full balance of the account as a
quarterly dividend
• Pay 6% / 12 on the balance up to £ 500 as a monthly
dividend
• Pay 6.5% / 12 on the balance between
£ 500.01
and £ 2,000 as a monthly dividend
• Pay 7% / 12 on the balance over £ 2,000 as a monthly
dividend
Create the framework of the
Decision Table:
• you know how many conditions there are
• you know how many actions there are
• you know how many rules there are
• format your table accordingly with:
– the condition statements
– the action statements
– leave the rest blank
Steps in solving the decision
table:
4 - enter all possible rules:
a - alternate the possible values for the first variable
b - cover each repeated pattern of the first condition with
each of the values of the second condition in turn
c - repeat previous step with each further condition
Steps in solving the decision
table:
5 - Define the action for each rule:
use X to mark the appropriate actions in the table for each of
the combination of rules
Add another action in the table to mark the situation that are
impossible (ie that cannot happen)
Use ??? to signal situations where you do not know what
should happen. These will require that you go back to the
users and ask them - c.f.: step 6
Steps in solving the decision
table:
7 - Simplify the Decision Table:
The table is now complete and correct
However, the table is not ready for programmers yet
a - eliminate impossible situations
b - look for indifferent conditions (ie conditions that do not
affect the decision)
– find a set of rules for which the actions are identical and one and
only one condition changes and takes all possible values
– consolidate that set of rules by replacing the value of the indifferent
condition by a minus sign - the indifferent symbol
Narrative for Sales Order system
• Customer submits an order. The ‘get order’ process either sends a reject
notice to the client or a picking list to the warehouse
• A completed order notice is sent from the warehouse and is input to the
‘create invoice’ process which outputs an invoice (one copy to the
client and one to accounts receivable data store)
• Clients make payments which are processed by the ‘process payment ’
process. This process requires invoice details from accounts receivable
and the payment. It also outputs payment details to the accounts
receivable datastore, commissions to the sales reps file, bank deposits
to the bank and cash receipts entries to the Accounting department
Data Dictionary:
• catalogue of all elements in a system
• list of all the elements composing the data flowing through
the system:
– data flows
– data stores
– data processes
• data dictionary provides both descriptions of these elements
and details of where they are used in the system
Importance of the Data
Dictionary:
• It is developed as a complement to the Data Flow Analysis of the
system:
– legend of the diagrams
– more information on the data elements
– names and titles of key informants
• assists the analyst in determining the system’s requirements
• also used in the design phase for reference to such details as
‘data length’, ‘transaction volume’, etc...
Use of the Data Dictionary in
development and maintenance
Analysts use the Data Dictionary in five main ways:
• to manage the details of large systems
• to communication a common meaning for all system
elements
• to document the features of the system
• to facilitate the identification of the areas where
changes are required
• to locate errors and omissions
Manage details:
• large systems have huge volumes of documentation: reports,
input / output documents..
• Such volume of data far exceeds the capacity of human
memory
• Conventional means of storage would not allow the
organised retrieval of these data
• Newer development environments include automated data
dictionaries
Communicate meaning:
• Data dictionaries ensure common meaning for all
people involved
• many different way to define even simple things like
‘invoice’ or ‘total amount’
• no meaning should be assumed and when clarified, it
should be documented for everyone to see
• Every member of a team has access to the DD
Document system features:
• the Data dictionary has a long term use too as it will be
used for the maintenance of the system
• it will also be used in the evaluation of the existing system
when the system gets older
• it will provide a better basis for the development of a
replacement system (it will be reusable)
• it can become a company-wide data dictionary to be used
across systems
Facilitate analysis:
• to help determine whether new features or changes are
needed in a system
• to enable analysts to answer a number of questions
regarding:
– the nature of transactions (what business activities are carried
out)
– example of potential inquiries (how will the data be retrieved
and processed)
– output and report generation (how will the data be presented)
– files and databases required
– system capacity (what volume of transactions will be treated)
Locate errors and omissions:
• to trace conflicting data flow descriptions
• to discover processes that neither receive input nor generate
output
• to identify data stores that are never updated
• some automated dictionaries will actually scan for
inconsistencies and produce an error report
What does a DD look like?
• data dictionaries contain two types of descriptions
• data items:
–
–
–
–
also called fields or elementary item
smallest unit of analysis
building blocks for all other data in the system
eg: invoice number, date, amount due...
• data structures:
– set of related data items describing a component of the system
– eg: Invoice is a data structure made up of a number, date, amount
due....
Describing data elements:
• data names - (ie a meaningful name)
• Data description (states what the item represents)
• Aliases - other possible names
• Length - the space required to store one item
• Possible data values - the range of values the item can
take
Strategic use of Database
Technology:
• The case for Strategic Information Systems (SIS)
• Some examples of successful applications
• A close look at database applications
• Strategic uses of Databases
Information systems can be
strategic??
• After the industrial revolution, the information revolution
(Porter and Millar, HBR 1985)
• Computers have become so flexible that there is no limit
to the range of tasks they can support
• This was called “the third era” of computer use (J F
Rockart, 1983)
Observations about the 3rd era:
• ability to use information systems technology
is essential for success
• some companies apply IT with great benefit;
others make no progress at all
• “reactive approach” to IT no longer works
– too much novelty too fast
– technology more and more powerful
• role of business managers in introducing IT
has become paramount
Managing Information
systems for competitive
advantage
• The way companies use IT actually makes a difference
• Application of IT must be managed properly like other
assets of the company
• Information technology is changing the way companies
operate internally and externally
– it alters industry structures
– it supports differentiation strategies
– it opens new businesses
Strategic Information Systems:
• Described in IT journals in the early 80s
• Difficult to define an SIS
• Even more difficult to plan for one
• Most of the research has concentrated on analysing
existing instances of SIS
• Some unconvincing attempts to come up with a
method to generate SIS
Formal Techniques to exploit
IT
• Business System Planning (BSP): IBM in the 1970s
– 13 different steps
– very cumbersome, expensive and long
• Strategic Planning for IT
– to provide a solid technical foundation
– alignment with the corporate strategy
• Application Generator: C. Wisemann
– aimed at outside opportunities
– up to 100 potential applications per company
Rockart’s CSF method:
• Identification of a hierarchy of performance measures
that lead to identification of Critical Factors and
Issues that will determine a business’ success
The business mission statement
The business vision statement
multiple business goals
multiple business objectives for each goal
multiple CSFs for each objective
Porter’s Competitive Analysis
(1980)
• based on the “five forces” matrix
• scope includes the entire business
• According to the framework, organisations' ability to
compete is determined by:
The threat of new competitors
The threat of substitute products or services
The bargaining power of customers
The bargaining power of suppliers
The rivalry amongst existing competitors
McFarlan and McKenney’s
framework:
High
Turnaround
Strategic
Support
Factory
Strategic
Potential
of IS/IT
Low
Low
Strategic Importance
of Current IS/IT
High
McFarlan and McKenney’s
framework:
High
Strategic
Potential
of IS/IT
Education
Farming
Newspaper
Banks
Travel agents
Cement Factory
Funeral Homes
Retail business
Restaurants
Low
Low
Strategic Importance
of Current IS/IT
High
Well-known examples:
• SABRE (American Airlines): first effective electronic
reservation systems in the US
• simple one-line database application
• took a long time to justify the investment
• competitive value of system still felt today
• in 1988 AA were making more money out of SABRE
than out of flying air planes
Well-known examples:
• American Hospital Supply Corporation (AHSC): system
whereby customers can directly re-order their supplies
from terminals located in their hospitals
• Successful because it enabled AHSC’s customers to cut
their costs of administration
• originally meant as an INTERNAL systems by AHSC and
extended to one main customer
Well-known examples:
• Digital Equipment Corporation (DEC): an expert
system that supports the process of designing and
specifying large computer systems
• Xcom is based on the experience of the best
specialists in DEC
• it eliminated a bottle-neck in DEC’s processes
• additional gains in customers satisfaction were
obtained as a result
Analysis of existing SIS:
• SIS were never intended to be strategic
• They rarely involve radically new technology
• They rarely originate in the IT function
• They are generally based on a “first mover”
advantage, but there have been some striking counterexamples
• Ability to handle huge amounts of information is
often main factor - ie: use of DBs
A close look at Database
applications:
• More and more applications involve databases
• on-line systems as opposed to batch processing
• new concepts (relational databases) make DBs much
faster
• available on more and more platforms (UNIX, PCs...)
• Databases are becoming cheaper to manage and easier to
maintain
A close look at Database
applications:
• Databases are perfect to handle the large amounts of data
which companies require (+DW)
• Databases make distributed computing and data sharing
easier
• Software vendors developed new development
environments which include a DB engine
–
–
–
–
Oracle + 4th GL
INGRES + 4th GL
All PC products for Windows (Access, Paradox, Foxpro...)
Visual Basic 4 + Jet engine
Strategic Uses of DBs:
• at a technical level, DBs are just a set of functionalities ie data storage and retrieval
• databases have far greater potential than just mere record
stores
• strategic applications arise when people try to creatively
imagine how these functionalities could be used by a
business
• DBs are not looked at as support applications anymore,
they can add value for the organisation or its customers
Potential areas of DB use:
1 - to cut administrative costs
2 - to serve customers better
3 - to enter new product areas
4 - to increase sales volume
5 - to improve decision making
To cut down administrative
costs:
• Reduction in staff costs not a very strategic application
of DBs
• But, significant competitive advantage if company’s cost
structure is greatly improved
• eg: UK Department of Social Security computerised their
paper files:
–
–
–
–
system must handle 60 million records
can deliver benefit cheques within 24 hours
it cut down the required work force by 20,000 staff
so costly (£ 2,000 millions) that it is unlikely to pay for itself
To serve customers better:
• this has become a popular (and necessary) strategy
• It can involve developing new services that the customer may
require (lodging cheques in an ATM)
• or making an existing service more practical (speeding up the
payment of social benefits)
• eg: British Rail’s Computerised Assisted Timetable Enquiry
system (CATE)
To enter a new product area:
• Specific DBs are required to assist in reaching potential
customers
• sometimes by-product of implementing another DB
• eg: Marks and Spencer built their first customer database to
support their credit card system
– later expanded to the financial area
– use their database to select and to contact potential customers
• once DBs have been developed, they can be sold to other
organisations (eg: Time, Newsweek...)
To increase sales volume:
• most companies have the opportunity to collect loads of data
about their customers - few do it
• experience with DBs has shown that they have a great
potential in improving a company’s knowledge of its customer
base
• eg: Aer Lingus have compiled typical profiles of their
customers per period and per route
To increase sales volume another example
• eg: Hewlett Packard's customer Database:
– each salesrep was equipped with a portable with MODEM
– applications available include address book, time and expense
recording systems, a word processor and access to corporate DB
– time saved by salesreps is spent with customers
– sales increased immediately
– they now have the perfect customer DB and started telemarketing
Customer databases to
improve marketing decision
making:
• DBs enable organisations to store very specific information
re thousands of customers
• information can be classified according to socio-economic
criteria (eg: age, geographical location
• mailings can then be more targeted and efficient
• new products launch can even result from such information
How to obtain customer
information:
• customer DBs can be compiled from four main
sources:
sales invoices
sales reps
published documents / advertising
external databases - information services
Sales Invoices:
• Always been a source of information on customers
• Now, computerised invoicing applications
• They usually record
–
–
–
–
–
names of companies / contacts
address
dates and amount / quantity / references of sales
discounts and other terms and conditions
name of the salesrep
• Analyses arising from invoices are
– sales territory and analysis of salesforce
– customer profiles
– seasonality
Information collected by the
sales force:
• Commonly under-utilised by organisations
• Salesreps very seldom on the premises
– information delivered in bulk
– too late after the event
• Communication problem between HQ and the “field”
people
• Creative use of portables + networks + EDI can yield
huge benefits (Northern Telecom)
Published documents /
advertising:
• A unit within the organisation scans the press
systematically for opportunities
• Not an option for small companies
• Very important for state markets and community
equipment
• Competitor scanning is also becoming a common activity
External Databases including
the WWW
• More and more of sources of information are
available
• From simple reference databases (Lexis [Law]
information system) to on-line up-to-the-minute
services regarding the stock markets
• Companies have to subscribe to the service and pay a
fee per inquiry
• Connection has become trivial with Internet
• eg: Banks, Marketing organisations, advertising
agencies etc...
Computers and the Law:
• according to the “IS Analyser” :
As companies make more use of information systems to
run their businesses, sell services and add value to their
goods, there is greater likelihood that poor information
practices will lead to harm to themselves or their
customers
• Legislation dealing with the role of computers in
business has become a necessity
Legal requirements for
databases:
• Since 1987, Data Protection Act
• “to protect the privacy of individuals relative to
personal data which is processed automatically”
• Personal data means information related to a living
individual who can be identified from the data itself
or other information held
• Bill gives right to the people to access “their”
information and duties to the people who hold
personal information
Obligations of information
holders:
•
•
•
•
•
•
•
•
implement and maintain computer security procedures
obtain and process data fairly
keep data accurate
keep data for specified and lawful purposes
keep data confidential
keep only relevant data
delete redundant data promptly
remove data from lists upon request
Obligations of information
holders:
• they may have to register under certain conditions:
1 - if they hold certain kinds of information:
–
–
–
–
about racial origin
about political opinions
about physical and mental health
about criminal convictions
2 - if they are:
– public authorities, financial institutions, credit reference
agencies, direct marketing agencies or data processors
Rights of people upon whom
information is held:
• have the right to find out about any record concerning
them
• have free access to records of information concerning
themselves
• have right to trigger legal intervention to obtain that
inaccurate data is corrected or removed
• have to the right to refuse to be included in marketing
lists which might arise from the database
Managing IT investments
• Allocation of resources to selected projects
• Application portfolio contains list of potential systems
• Limited resources mean that systems must be evaluated in
terms of their business potential
– justifying investment
– allocating priorities
– determine how the expected benefits will impact the business
overall (+review of these)
Evaluating IS investment
• Little consensus on how to do it
• Total consensus that it is not done properly
– 70% of organisations have no formal process
– only 30% of projects’ outcome are reviewed
• Variety of types of benefits suggests that multiplicity of
methods id required
• Old fashion financial oriented methods less and less
appropriate
80% of IT directors admit that cost/benefits analyses are
“a fiction” in relation to IT projects
Characteristics of IT investments
• Technology investment does not really have a return on
investment (unless it strictly replaces another older system)
• Many investments in infrastructure cannot be linked to a
specific application and their potential is not exhausted by
one project
• But technology is not always scaleable (purchase in
increments)
• Additional development costs incurred within functional
areas are rarely taken into account
Characteristics of IT investments
• Identifying and quantifying benefits is also difficult
• Consider the following three types of applications:
– Substitutive to improve efficiency
– Complementary to improve effectiveness
– Innovative to obtain and preserve competitive advantage
• These different types of applications require different methods
Generic Methods
• Traditional cost/benefit analysis - good at measuring
improvements in efficiency
• Value Linking - good to estimate improvements in business
performance
• Value acceleration - to model the positive (non £)
consequences of saving time in business processes
• Value restructuring - to plan for the productivity resulting from
a combination of better systems and other fundamental change
• Innovation evaluation - to take into account the additional
revenues that can be obtained from extension of business to
new activities
See figure 10.1
Examples of targets for these
Methods
• Traditional cost/benefit analysis
• Value Linking
• Value acceleration
• Value restructuring
• Innovation evaluation
Savings resulting from
automation
More accurate billing means less
time spent in correcting mistakes
Acceleration of order processing internally
means more time for negotiating with
suppliers for the buyers
Support given by systems
in implementing change
IT based plan to develop
totally new activities
Summary
• Costs and benefits should be appraised in both IT and
business domains
• 5 different categories of benefits have been put forward
• Overall value of project is combination of all these
• Long term and short terms benefits must be included
• Not possible to convert all intangibles to financial figures
(spurious)
• However crucial to establish how intangibles will be
measured and monitored
• Portfolio Analysis can be used as guide
Portfolio Analysis
High
Potential
contribution
of IS/IT application
to achieving future
business goals
Strategic Attack
Key Operational
- Explore
High Potential Beware
Support - Safe
Low
High
Low
Degree of dependence
of the business on IS/IT application
in achieving overall business objectives
Lessons from the Portfolio
approach
• Quantitative justification easier in key operational and
support quadrant
• Reliance on single method will result in only one type of
application to be developed
• The way IS is regarded and managed in the organisation
will be reflected in the way IT investments are justified
(see figure 10.2)
Support
• Given the aim to improve efficiency, financial evaluation
should be used
• benefits should be quantified and a financial argument
made
• Additional arguments might be relevant (eg: staff morale) other methods to be used for those
• Potential benefits must be evaluated before any resource is
committed
• To compete against other projects, a support application
must show a good return on investment especially when
scarce resources are involved
Key operational
• Some important arguments cannot be converted into
financial arguments
• Not suitable to estimate all benefits prior to any resource
allocation or cost determination
• most economic solution may not be the most effective
• Critical failure effect if systems do not do enough
• Some freedom must be given to each business unit to initiate
such projects even when the economic rationale is not
obvious to an outsider
• But design and implementation must be undertaken by
central IS/IT
Strategic Applications
• Very important applications - critical in achieving future
business objectives
• Cost / benefits should be evaluated in terms of their order
of magnitude
• Reasons to go ahead will remain intangible (linked to
CSFs)
• Attention of top management is required to ensure that
objectives are met and resources are available
• Centralised processes is best with a task force approach
High potential Applications
• Benefits are unknown! Only potential benefits can be
anticipated
• Projects should be treated as R&D projects (on a separate
budget)
• Project champion arbitrates between spending too little and
spending too much (Hayes’ model)
• Iterative process of developing a bit and evaluating the
results then re allocating some resources etc...
Assessment of Priorities
•
•
•
•
Priority score should be a compound measure of:
what is the most important - Benefit
What can be done - Resources
What is likely to succeed - Risks
• This final factor must be added so that not all projects
undertaken are high risk = nothing achieved
Application to the different types
of systems
• Support: greatest “doable” economic benefit
• strategic: use scoring framework as in fig 10.3
– business objectives can be ranked
– division of score per person-year of scare resource means
contribution can be maximised
– must however not be used mechanistically
• High potential: more difficult to prioritise
– link to CSFs often tenuous
– strength of champion’s position and support will count
• Key operational systems: different framework
– economic rationale
– CSF
– risk to current business
Managing the IS department:
• Dilemmas in managing IT:
– limited to the administration of systems
– searching for new opportunities to develop the use of IT
• Success of the IT function is often measured based on
the operation of existing systems
• Adaptability and creativity are not assessed
• Neither is the efficiency of resource usage
Tasks of IS
• IS delivers a service to the rest of the organisation - it
is a support department
• IS is in charge of managing the computer resources
and the technology
• IS must plan for future needs on behalf of the whole
organisation
• IS must develop the new systems that will be help the
organisation in the future
IS as a service department
•
•
•
•
supporting end-users - answering their requests
training users
provide a secure environment
providing advice on how to tackle problems in the future
There are a number of strategies to fulfil this role
Different philosophies of
Network Management:
1
•
•
2
•
3
•
•
•
- Centralised DP:
one company = one computer
one department does all the processing
- Decentralised DP:
each individual function has own computer with home made rules
and procedures
- Distributed DP (DDP):
somewhere in between
various computers available throughout the company
all linked together
+/- of the different
philosophies:
1
•
•
2
•
- Centralised DP:
easy to maximise use of computer and to control usage
flexibility for user is restricted
- Decentralised DP:
difficult to maintain and share corporate data (compatibility of
software, hardware...?)
3 - Distributed DP (DDP):
• more difficult to manage
• does address the difficulties of both philosophies
Traditional IS
• computing is a centralised activity managed by the IS
department
• functional areas have no freedom in relation to the
selection or the usage of IT
• functional areas have no budget for computing
• the IT architecture developed in the organisation is
centralised as well
End-user computing
• Users / managers are active in determining the
systems they require
• They are active in specifying the requirements for
these applications
• They may even develop the applications themselves
(if skilled enough)
• They have a specific budget within their functional
area to accomplish this
• They may be supported by the IS department through
an Information Centre
Problems with EUC:
• less transparency in the IS spending (up to 50% in
“hidden” costs)
• more difficulty in integrating inter-departmental
systems
• possibility that individual buyers make wrong choices
• Loss of economies of scale
Problems with EUD
•
•
•
•
•
No overall view of business systems
no standards for development and documentation
likely duplication of efforts and data
likelihood of loss of critical knowledge
risk of local users “re-inventing the wheel”
Advantages of EUC
•
•
•
•
•
faster application development / implementation
increased chance of getting requirements right
users become more expert at using computing resources
productivity increases at individual user level
reduction of the “application backlog”
Outsourcing
• Transfer the responsibility for IS to an outside organisation
(various degrees)
• Use a computer service provider for one or more
applications
• outsource some development work
• Do without an IT department and depend entirely upon
outside specialists
• Saves money but with major consequences for control and
strategic developments
Historical evolution of IS
•
•
•
•
Stage of growth model (Nolan)
All organisations go through similar stages
EUC emerges in stage 2
EUC must be carefully managed through the other
stages
• Failure to manage EUC means organisation does not
go into later stages
• Evolution is basically a cycle of phases of control,
EUC and outsourcing
Dealing with IT costs
• Allocating or charging out costs
• Seen as an administrative or accounting procedural matter
• can influence the selection of and management of IT
investments and budget
• Who pays for IS projects and who is responsible
determines how applications are cost justified
• Also accountability for failure and over spending
The Chargeback system
• Unpopular at the best of times
• users see it as a pricing mechanism: how expensive should
IT be?
• Transfer pricing for buying and selling IT products and
services
• All boils down to status of IS department and whether
functional areas have access to a free IS market
Free Market?
•
•
•
•
Have functional areas their own budget?
Is IS an independent profit centre?
Is IS in competition with other suppliers?
Can IS refuse unprofitable work?
• Who prepares the IS budgets?
• What cost drivers to use?
Calculating IS usage
• Traditionally, CPU time and other very technical
parameters
• More fair to the user to use more visible and business-like
measures:
– number of transactions
– number of screens viewed per session
– …
• Matter of business policy!!
Vision of the status of IS
• Earl argues that charge-out system must reflect the role of
IS as component of the business:
• service centre: IS service not chargeable
• cost centre: users are charged with costs representing the
resources consumed (IT costs are recovered)
• Profit centre: users pay a market price (IS department can
have its own revenues + bid for outside work)
Implications for charge-out
system
• Cost centre: charging method based on average/standard
costs (e.g. network)
• Profit centre = open market - players can accept / refuse
work based on availability of better offer
• First step to outsourcing??
• Hybrid method may offer best solution,
– charges determined by the nature of each application
•
but is difficult to implement
Socrate - Buying systems instead
of developing them
• Reservation System for the French National Railroads
(SNCF)
• To be implemented at a set deadline at the same time as
the launch of the Atlantic TGV
• Ambitious attempt to develop a Global Distribution
System (GDS) for rail transportation
• Very large development project
– current system obsolete
– lack of confidence in internal development (previous failure)
• Why not buy SABRE?
Story of a Disaster
•
•
•
•
•
•
•
Launch January 18th 1993
Million of customers stranded
Queues longer than ever before
ghost trains
missing towns (eg Rouen / 400,000 inhabitants)
Clerks went on strike
traffic decrease by 7% in 1997!
The real story
• Difficult managerial decision
• difficult project technically (never done before)
• Other factors (increased competition) explain the bad
results of 1993
• Reason of the failure were largely external to the project
• No support from top management
• SNCF is important and irreplaceable service
Why buy SABRE?
• Current system has reached the end of the road
• bad experiences with semi-state bodies developing large
systems
• GDSs are enormous packages - Socrate was expected to
– take 500 man years to create
– add up to a million lines of code
– cost around £150 million
• Train industry is very specific => outsourcing not an
option
• Lack of political support for European collaboration
• SABRE provided a good basis for what was needed service + yield management
Development
•
•
•
•
•
Joint venture between AMR and SNCF
gradual transfer of responsibility and knowledge
overshot budget by 20%
was ready just about on time
systems has now been sold to SNCB, SNCS and other
European operators
• Users and customers not involved in development
• Training was minimum
Greatest Problems
• Bad analysis of requirements
• Underestimation of the complexity of the problems raised
(eg: exceptions)
• Not consideration given to training needs
• Lack of understanding of the implications of the culture
and structure of the company (eg: databases)
• Appalling communication with the public
So Socrate…..success or failure????
AIMS OF PROJECT
MANAGEMENT:
•
Ensure the respect of dead-lines
• Ensure the respect of users’ requirements
• Ensure the quality of the systems
• Meet the target costs
Module 4: Problems with Information Systems Development
FEASIBILITY STUDY:
• Make sure that vendor and client organisations will be
able to carry out the project in the best conditions
• Is the project worth pursuing - what benefits will it
deliver to the organisation
Crucial FROM THE CUSTOMER’S POINT OF VIEW
as well as from the vendor’s point of view
Module 4: Problems with Information Systems Development
MANAGEMENT TOOLS (1):
• The development effort is broken down into tasks and
sub-tasks
• Each task is documented and assessed for duration and
difficulty
• All tasks are then built into a Worksheet
• The resources are allocated
• Dead-lines and critical dates are checked
Module 4: Problems with Information Systems Development
MANAGEMENT TOOLS (2)
• Developers submit detailed time sheets on a weekly basis
• All time sheets are compiled into a spreadsheet
• Reviewed in a weekly progress meeting
• Any task off target is re-allocated and rescheduled
Module 4: Problems with Information Systems Development
MANAGEMENT TOOLS (3)
most important from the customer point of view:
• Regular meetings are held between the project managers
on both sides:
– Ensure the respect of the specifications
– Co-ordinate the phases
– Plan for the availability of personnel
• Senior Management From Both Companies should try to
Meet / Talk at Least Once a Month
Module 4: Problems with Information Systems Development
Protection of Information
Resources
• Modern network-based environments require the
application of basic security principles to distributed
environments.
• “An open, secure system is a contradiction in terms”
(datapro, 1994).
• any data flowing through a network or cached
temporarily is vulnerable
• as security is implemented, freedom is reduced
Basic principles of security
•
•
•
•
Confidentiality
integrity
authenticity
utility - fitness for a purpose
Steps in protecting Distributed
Resources
• Identify what you want to protect
• evaluate and determine all possible weaknesses /
sources of risk
• constantly review access to IT resources and IT audit
procedures
• routinely conduct / update risk analysis of the
operation
Priorities for the Protection of
Computer Resources
• Prevention of computer crimes - ie ensuring that
information resources are only used as prescribed and by
authorised personnel
• disaster planning - pro-actively envisaging what might
happen in order to minimise risks
• disaster recovery or “business continuation” - ie ensuring
that consequences of crime and accidents will also be
minimum so business can resume immediately
Computer crime:
• using computer resources to engage in unauthorised or illegal
acts
– stealing money from a bank
– copying and using programs without required licence
• as technology spreads, opportunities for crime increase
• still very loose legal framework means few people are
prosecuted
• 80% of crimes are insiders’ jobs (employees)
• most instances are not reported (banks!!!)
Types of computer crime:
• a very large number of different ways:
–
–
–
–
data diddling: unauthorised modification of data
the Trojan Horse technique: a block of code hidden in a program
the salami technique: shaving minute amounts to each transaction
Trapdoor routines: special programs used in the development
phase sometimes not removed
– Eavesdropping: spying of data communication between LANs
and mainframes for important info
Recent survey
• security problems resulting in financial loss:
–
–
–
–
–
–
–
•
•
•
•
•
24% software failure
12% network failure
12% virus
11% computer failure
7% stolen data
5% sabotage
4% network break-in
Nearly 50% have lost valuable info in last 2 years
20 respondents have lost info worth more than £1 million
70% say security risks have worsen
80% have hired a full time info security director
67% have faced viruses in the last year
Computer related crime
•
•
•
•
•
•
•
credit card fraud 96%
telecommunication fraud 96%
staff use of corporate computer for personal use 96%
unauthorised access to company files 95%
cellular phone fraud 95%
unlawful copying of copyright software 90%
theft of information regarding:
–
–
–
–
–
clients 81%
trade secrets 80%
new products 75%
confidential employee information 75%
money 72%
Hackers and Bandits:
• most prolific types of unauthorised activities on computer
systems
• a hacker is someone who breaches communication and
network security to gain unauthorised access to a central
computer
• Hackers are supposed to do it for the fun
• very often not classified as computer crime and not
prosecuted
• They can however be tricked by Bandits who give them
“bad ideas”
Requirements for identification of
computer crime:
A number of conditions have to be demonstrated to enable
prosecution of the crime:
– knowledge: criminals must have competent knowledge about the
act and be aware of the consequences
– purpose: the must have an underlying purpose, specific intent
otherwise, browsing may be merely “electronic trespassing”
– malice: they must be motivated by malice and wish to do harm in
some way.
How to make it easier to trap
Hackers:
• have investigation procedures ready to be implemented
• they will aim at freezing the situation and preserving the
scene of the crime
–
–
–
–
–
prevent further damage to data and programs
limit the losses incurred
find out what went wrong
identify the perpetrator (if any)
preserve evidence in view of legal action
• in the case of internal threats, publish an internal code of
conduct for employees (included in work contract??)
Why are computers so
vulnerable?? - DATA
• data can be stored in pocket size forms (floppy disks, disks,
tapes, DAT...)
• electronic data is invisible
• data can leak (electromagnetic waves = tempest)
• data is accessible (can be copied without trace or authority)
• data can get left behind
• centralised data stores can reach high value
Why are computers so
vulnerable?? - COMPUTERS
• computers are mythical: users do not behave rationally
• technology is changing faster than companies / people can
adapt
• communication and networking are compounding factors
• systems and networks are more and more integrated (open
systems)
• processing is more and more distributed
• security standards are still very low
Consequences of security
breaches
• damage is sometimes unexpected and subtle:
– loss of business
– damaged reputation
– compromised organisational secrets
• Primary costs - replacement of destroyed / stolen
property
• secondary costs - lost business / revenues
• incidental costs - legal and detrimental costs resulting
from damage or settlement
First step is risk analysis:
• Some general threats to all companies, but each setting is
unique => specific analysis
• identify specific worth of organisational assets
• From list of sensitive assets a specific security plan can
be designed
• this is best done by an outsider (taking some distance is
required) by way of an inquiry:
– talking to people
– learning about the company
– writing a report that will convince top management
steps in security: assessing
risks:
• a number of “models” are available for assessing risks
• one example is:
where:
Risk – = threatsThreats
Vulnerabilities
+
are events which
cause
harm
+
Assets values
– vulnerability is the degree of openness of the org.
– asset value is the worth of the assets in danger
• If one component decreases, risks decreases and vice
versa
Risk analysis techniques:
• Subjective analysis = group method where all competent staff
review:
–
–
–
–
the role of the computer systems
the nature of the business and the org.
the history of the company (for previous problems)
no longer sufficient because not systematic enough
• Quantitative analysis: come up with a figure that should be
spent every year by:
– computing the likelihood of each threat
– computing the costs of damage resulting from each threat
– multiplying frequency and impact to obtain the maximum amount that should
be spent on protecting the company against each threat
– there are obvious limits to that method too
Security policy matrix:
Impact
Plan
(What-if?)
10
Avoid/Escape
(What!!!)
Expectancy
0
10
Accept Risk
(So What...)
0
Control
(What to do...)
Components of the the
security Plan
•
•
•
•
•
physical security
document security
personnel security
hardware security
software security and logical access control
Example - physical security
• Plan is aimed at deterring intruders from trying
• efficiency of the barrier is measured by:
–
–
–
–
the time and cost needed to breach it
the speed with which intrusions are identified
the accuracy with which the intruder is identified
its non-interference with the life of the organisation
• it involves the protection of:
– the computers (location, layout of computer centre)
– the services of the computer installation (air conditioning, power, water...)
– fire protection
Example - document security
• there are a number of documents specific to computer
use that are important:
– blank pro-formas
– “handle as if..” documents (ie: drafts, mistakes...)
• magnetic documents (ie: disks and tapes) must be
registered in an inventory
• tapes must be purged before being re-used
• the life of every computer document should end by its
destruction (shredded)
Who is in charge:
•
•
•
•
security is still viewed as an MIS issue
Co-ordination of security strategy is an MIS issue
but co-operation is required from all departments / users
if procedures are not followed, the best strategy is worth
nothing
Security of Networks:
• Security is much easier to implement in M/F environments ie centralised
• risks increase in LANs and even more in interconnected
LANs (WANs)
• Remote access is a great source of risk - eg workstations are
left unattended
• Remote access market = $2 billion in 1997
• how to make a network of notebooks safe
Security with EDI:
• organisations share their IT infrastructure
• paperless nature of transactions requires double care - legal
aspects
• prevention, monitoring and recovery must be shared and coordinated between the partners
• liability and responsibility could be difficult to establish
• all parties involved must agree on common code of security to
ensure “end-to-end” security
Security with CAD:
• attempt to shorten the value chain of an org.
• design office is linked to outside organisations to contract out
work
• design office is on-line to the manufacturing systems
• Integrated system also involves inventory control, finished
goods stocks, shop floor control...
Security with Document
Image Processing
• Paperless organisation means documents are scanned as
soon as they come in
• copies of all documents always available from anywhere
• over-reliance on such systems (inability to handle paper
documents) can lead to disaster
• editing facilities make it too easy to “fabricate”
documents for fraudulent purposes
Added difficulties in multivendor environments
• most organisations no longer rely on one single
platform
• integration means emphasis is on linking these rather
than separating them
• password protection can mean that users must
remember many different passwords
• encouragement for users to weaken security by using
same password or obvious passwords
Recovery Planning:
• perfect security cannot be achieved and no single
countermeasure is completely effective
• security is about reducing the risk to an acceptable level and
coping with the consequences
– provision must be made for accidents despite countermeasures
– recovery mechanisms are as important as protection
• so security measures should:
–
–
–
–
operate in conjunction with the corporate life
be simple and easy to implement
be cost effective as £££ are scarce for security
be introduced over a period of time, progressively
Potential gain from a suitable
security strategy:
• improved image:
– competitive advantage can be obtained
• enhanced customer confidence:
– ensure service continuity
– accuracy and privacy of service
– safeguard of customer assets
• new products and services:
– novel security devices and strategies can be marketed and sold to other
companies
– security projects may generate new ideas
• new security features for existing products and services:
– can give new life to an old line of products
– market opportunities may be lost if security is not up to the standard
A Strategic Role for IS
•
•
•
•
IS as a contributor to organisational value added
Helping functional areas to develop their contribution
contributing to developing new specific activities
e.g. Electronic Commerce
IS Strategy
IS strategy must be consistent with:
• The organisation’s corporate plan
• its management’s view of the role of IS in the organisation
• its stage of maturity of use and management of IS
Example of questions that must
be addressed
• Where does the IS strategy fit in the wider set of corporate
strategies
• what has been the history of IS strategy planning
• what circumstances demand major re-assessment of IS
plans
• who might be employed to do the actual planning
• what might an IS strategy contain
Different organisational
circumstances
•
•
•
•
Maturity (Nolan)
Information intensity
Strategic Importance
Special circumstances demand extra planning:
– major corporate changes (BGE)
– external competitive opportunity or threats
– evolutionary change in IS maturity
From Planning to Implementing
• Improving IS strategic Planning is primary target of IS and
non-IS managers (1994)
• Contents of plans improved over 80s and 90s
• But many IS plans have been left aside nevertheless
• Lack in commitment to implement them - especially top
management
Barriers to implementation
•
•
•
•
•
Lack of top management’s awareness (DP era)
Credibility gap between between hype and real benefits
Lack of vision (information not an asset)
Difficulty in judging / evaluating IS proposals
Short term focus militates against planning
Threats resulting from lack of
planning
• Loss of control of investment in IT
• Incompatible / inconsistent development of IT usage - eg:
UCC
• Conflicts between functional areas
• Systems’ life shorter + greater need for upgrade /
maintenance
• Decreasing return on investment
Good IS planning?
• Impact not instantaneous (2 / 3 years delay in getting
benefits)
• Benefits depend on:
– starting point (current system’s portfolio)
– opportunities sought
– top management support (champion)
• Proper organisational culture and good relationship
between IS and other areas must be developed (eg: BGE)
Mintzberg’s Grass Root Model
• Planning for IS is everyone’s business
• Balance between formalised strategies and emergent
strategies
• Planning process should not only pre-conceive strategies,
but also recognise their emergence and intervene when
appropriate
• Knowing when to promote change for the sake of
adaptation and when to resist it for the sake of internal
efficiency
Adaptive approach to IS planning
• Best opportunities for IS development are often linked to
unique assets or resources
• Firms must learn to identify and exploit these
• Hayes (1985):
“Firms should acquire technologies and techniques so that workers
and managers gain experience with them and come to
understand their capabilities and constraints”
• Organisational structure should be modify in order to
foster this process
Roles in Hayes’ Model
• Wizards - corporate experts and librarians for new technologies
• Marriage Brokers - designed to act as intermediaries between
users and wizards
• Rich Uncle - manager who pays for seeds so users can develop
prototypes
• Weed Puller - top executive who re-evaluate investments and
projects and stops or encourage them
• Teacher - educates users about the possibilities offered by
technologies and other about the organisation and its products
Advantages of the Adaptive
Approach
• Bottom up process - ideas come from users in close contact
with organisational processes
• Top-down approaches are less satisfactory as senior
strategists may be unaware of technical possibilities
• Adaptive approach enables focus on specificities of the firm
=> yield long term edge
• Development of an informal structure of actors involved in
strategic idea generation may prove a competitive advantage
in its own right
Topics covered:
• Quick history of IS in organisations
– Importance of IS in organisations
• Databases - definition - DBMS functions
– Basics of data organisation
– relational databases
– distributed databases
• Data Modelling: describing relationships - the ERD
– Normalisation
– SQL
• Strategic uses of databases / Strategic systems
• Information Systems development
–
–
–
–
–
–
Problems with IS
SDLC
Tools and techniques used during SDLC phases
Data flow analysis
Data dictionary
Socrate case study
• Dealing with IT cost
• Managing IS investments
• Protection of IS resources
Sample exam question
•
You are working for the admissions office of a university. The role of your
department is to enroll students into the various courses available in the
college. Because the process of registration is getting more and more tedious,
your boss has asked you to develop a small database in which first
registrations will be keyed in (ie your system is limited to students who
register for the first time). The system must hold information about (1) the
students, (2) the courses offered by the college (including fees information),
(3) the subjects that make up each course, (4) the courses that each student is
registering for, (5) the payment(s) made by students and (6) the marks that
each student obtains in each subject.
•
You are requested to put particular emphasis on the transactional aspect of the
system, whereby a student is being registered into a particular course (not
forgetting the implications in terms of interface) and to present clear examples
of what the data stored in your database should look like.