Information Systems
Philip Bird
The Northern College Diploma Programme – Computer Studies
Introduction
The history of computing is littered with examples of costly mistakes. Mistakes
made in the design and implementation of information systems that are
intended to solve business problems. Since 1997 the cost of scrapped or
over-budget UK Government projects has topped £1 billion. There is a long
list of high profile, failed, late or over-budget projects that includes the
computerisation of the London Ambulance Service, the Passport Office, the
register of asylum seekers, the Criminal Records Bureau etc.
This is not a new problem – it has existed throughout the history of
computerisation of business functions. When designing data processing
systems there are many pitfalls that must be avoided. This unit examines
some of these issues and looks at methods of designing systems that attempt
to solve them.
Week
Week 1
Week 2
Week 3
Week 4
Topic
The Software Crisis and Life Cycle
An Order Processing System
Databases
Travelling Salesperson
SSADM – Data Flow Diagrams
SSADM – Entity Modelling
Drawing DFD’s and EM’s
SSADM – Entity Life Histories and
Normalisation
Week 9 SSADM – Entity/Function Matrix
Week 10 Review
Week 5
Week 6
Week 7
Week 8
Activity
A Payroll System
Assessed Task 1
Salesperson
Activity
Assessed Task 2
Assessed Task 3
Assessed Task 4
To qualify for accreditation for this module you must be able to demonstrate
that you meet the assessment criteria for this module.
Page
2
Information Systems
“After growing wildly for years, the field of computing appears to be reaching
its infancy.”
“Technology is led by two types of people: those who understand what they
do not manage, and those who manage what they do not understand.”
“The word user is the word used by the computer professional when they
mean idiot.”
Potential Problem Areas
The System
Where does the system start and finish – where are its boundaries, what
should be included?
What do the users want the system to do?
How does the system interact with others – systems or people. Will work
practices have to change?
Users often change their mind – especially as they see progress. False or
unrealistic expectations may be raised.
Completed systems may contain a number of errors (bugs) when delivered even though the specification was correct the finished product may not work.
Communications
The users don’t really understand IT systems – they cannot find a common
ground with IT experts and may often distrust them.
Computer specialists don’t understand a user's needs – they speak different
languages.
Users have different levels of experience and confidence in the use of IT.
It is difficult to express what is required - specifications are often imprecise or
incomplete.
The Environment
The business environment changes quickly – dynamic circumstances can
make systems out-of-date before they are delivered.
Technology changes quickly – it soon becomes obsolete.
The larger the problem the potential for mistakes rises considerably.
What is a System?
An information system accepts data as an input and processes it to generate
information. That information is interpreted by the user to generate
knowledge. Data can be any meaningless item, a number, a string of
characters. Processing by a computer gives this raw data meaning, collected,
sorted, compared, enumerated etc.
Page
3
A more formal definition is as "an assembly of resources including people,
data and procedures that work together to provide useful information"
Why do we need computerised systems?
 They can be quick to produce information.
 They can store large quantities of data.
 They can process large quantities of data.
The Software Crisis
Computer systems are expensive beasts – the cost is not in the hardware but
in the programming and maintenance of them.
Writing good quality software takes time, the process is usually rushed and
finished systems contain many errors (bugs).
The following chart shows the values ($m) for a sample number of software
projects delivered for the American DARPA programme in the 1970’s.
Even when a system is used there are many fixes and enhancements that
need to be made – this is maintenance. The following chart shows figures for
the percentage amount of maintenance a system needs.
Page
4
Page
5
Systems Analysis – The Systems Life Cycle
The purpose of System Analysis is to analyse current data processing
problems and design and implement solutions. (Those solutions may not
involve the use of computers).
It is possible to define a number of stages that occur as a system is analysed.
These stages make up the systems life cycle.
Desire for Change
Maintenance
Initial Investigation
Implementation
Analysis
Design
Desire For Change
The desire for change is usually expressed by the users of the current
system. It may be that there are problems that need to be solved if the
organisation is to run effectively. E.g. Cash flow problems because of delays
in the sending out invoices.
Initial Investigation and Feasibility
This is undertaken by the system analyst or often by the accountants who
look at the current situation, based on an initial specification from the users.
S/he will examine the situation and prepare a feasibility report. (Perhaps
analysing the cost and benefits). The user will then take a decision to
proceed. The analyst may conclude that the problems can be solved without
re-designing the old system and may instead suggest ways of improving the
existing system, whether is it manual or already computerised.
Systems Analysis
This is an in-depth analysis of the current situation. This is conducted through
interviews, questionnaires and discussions with the users. The analyst
models the system in terms of data files, processes and flows of information
between them. The idea is to produce a logical model of the information
processing and the necessary functions needed to perform it.
Systems Design
Once the analyst has a good understanding of the current situation and the
problems associated with it he is in a position to design a physical solution.
Once the design is finalised, often done using systems flowcharts or other
Page
6
diagrammatic tools, program specifications are prepared. Test specifications
will also be prepared at this time. It may be that different designs are
produced and offered as alternatives to the users.
Implementation
This stage is often indistinct from the design stage. Programs are written
using the previously prepared specifications. Hardware is bought and
installed. Testing is then carried out, at program, system and acceptance
levels. Documentation is also prepared. Program documentation - explaining
how the programs work for use by programmers working on maintaining the
system. User documentation - explaining how to use the system in a clear and
non-technical way. Operator documentation - explaining how the programs
are to be run, what media is needed, what to do if things go wrong.
There are a number of ways in which the new system can be implemented.
Simply scrapping the old method in favour of the new could be disastrous,
what if the new system doesn’t work? Parallel running may be tried where the
new system is run by the staff but after they have processed the same data
through the old system first. This gives a benchmark to compare the new
system against and time to iron out any bugs. Pilot running may also be
used, operating the new system alongside the old with the new system
gradually taking over more of the functions of the old. Both these methods
make heavy demands on staffing. Staff training will also be necessary during
this stage so that staff know how to use the new system.
Maintenance
Maintenance involves both the repairing of hardware but more importantly the
correction and updating of software. As mentioned systems are constantly
changing and the software must be able to change along with new
requirements. Parts of the system may need re-specifying and re-coding.
Users may want more facilities than was originally specified while there may
still be bugs in the system. Any changes means that the system will need retesting and documenting. Maintenance occupies a large part of most Data
Processing departments.
A system can only be maintained for so long before the demands on it grow
and problems emerge this results in a desire for change from the users.
Problems
The dynamic nature of system and the fact that people are involved are the
largest problems associated with Systems Analysis. People tend to be
resistant to change and rarely welcome the extra work that is involved in
altering their work practices to make use of the computer. Their needs often
change, leading to the problems of maintenance mentioned above. (Up to
90% of coding time can be spent on maintenance leaving only 10% to write
new applications.)
Page
7
Some solutions are through the use of Fourth Generation languages, which
allow users of databases access to the data without the need for a trained
programmer, and through the use of Fifth Generation languages to ‘prototype’
a system while the users are in attendance. Users thus feel more involved in
the design process and have more of a say in the look of the finished product.
The process of analysing a system and designing a new one, together with
the documentation and testing is part of the discipline of software engineering.
Tools exist to help this process, they are known as CASE - computer aided
software engineering tools. They include packages to draw data flow
diagrams, create databases of specifications and validation procedures, some
even include automatic program generators which can create much of the
final application. These tools can help too ensure that the final application
meets the original specification. There are different methodologies to
analysing a system, the tools are often tied to a particular methodology – one
such is Structured Systems Analysis and Design Methodology (SSADM).
Summary
Many problems in the delivery of working systems are down to getting the
customers requirements into an accurate specification. The failure to do this is
because of:




The poor notation used in producing specifications and fuzziness of
customers requirements – they often rely on English.
The size of systems.
The technology culture gap between customers and developers.
Changing and dynamic business situations.
Page
8
An Order Processing System
One of the earliest methods of describing a system was via a Systems
Flowchart. This technique is very good for showing the processing of data by
computer but is less good at describing the manual handling of forms in a
system and weak at describing the data that needs to be collected and
processed.
The System
An initial customer order is entered into the system and checked. If no errors
are detected then 4 copies of the order are produced as advice notes. One is
posted to the customer to confirm the order. One is sent to the Warehouse
where the order is made up. A third is used as a delivery note that is sent with
the goods. The final one is sent with the goods and is signed by the customer
as proof of delivery. It is returned to the company where it is used to initiate
the invoice.
The invoice program produces the invoices that are sent to the customer and
also produces a ledger record that is later used to update the customers
account.
The following flowchart does not show details of the updating of the products
file as this is done by the Warehouse. It also shows no details of how the
accounts department use the ledger records to update a customers account
or how the system might cope with stock re-ordering.
Page
9
Page 10
Files and Fields In The System
Customer.
Customer_Number, Name, Address, Credit_Limit
Product.
Product_Number, Name, Description, Sell_Price, Buy_Price,
Re-order_Level, Quantity_on_Hand, Supplier_Number
Orders.
Order_Number, Customer_Number, Product_Number, Order Date, Quantity
Delivery.
Order_Number, Date Delivered
Ledger.
Customer_Number, Order_Number, Order_Value, Date Paid
Supplier.
Supplier_Number, Name, Address, Tel
Errors That Could Be Generated By The System
Verification checks the integrity of the data entry, usually a visual check on the
screen. E.g. ‘Are you sure Y/N’. The check is to see that the order has been
transcribed properly.
Validation checks on the reasonableness of the data entered. Checks such
as size, limit, range and check digits. E.g. If the Quantity < 0 then Error
The most likely errors produced by the Order Program would be ‘Goods out of
stock’ or ‘No such customer’. The only error likely to be produced by the
Invoice Program would be ‘Order not found’.
Problems With This Approach
This method of taking each function of an organisation and computerising it
has an advantage in that the data processing of the organisation can evolve
to meet specific needs one step at a time. But over time many systems may
be used by the organisation with duplication of data between them.
Rather than handle the computerisation of each function of an organisation
(sales, invoicing, personnel, stock control etc) a database can be used to
provide one source of linked data.
Page 11
Task – A Payroll System
Use the systems flowchart notation to draw a payroll system.
Clocking on cards are collected each week and used to create a weekly
transaction file of data that is used to update the payroll master file and
produce weekly payslips.
What are the fields of data stored in each of the two files?
What errors could be produced by the Payroll update process?
Page 12
Databases
A database is more than just a collection of files, it is a collection of all the
stored operational data used by all the application programs of an
organisation. The files are integrated under the control of a Database
Management System. (DBMS).
Applications
Database
When dealing with database it is often easier to stop talking about files,
records and fields and to use the terms entity and attribute instead.
An example might be a customer entity with attributes customer_number,
cutomer_name, address etc. This allows us to think about the data in a more
logical way without having to worry about the physical storage of it. The
modelling of data in this way helps bring about data independence.
Data independence is useful in that it separates the physical storage from the
different views, or data models, that a user may want to take of the data. Data
independence is made possible though the use of a schema, or data
dictionary. This gives the logical structure of the database, the names of
entities, the number and type of attributes and any validation rules associated
with them. The applications can access the data via schema’s. They limit the
access to only those pieces of data that are needed for that application thus
providing a level of security and can include validation rules to limit the
entering of incorrect data.
The problems of having to maintain large application programs to access the
data, with consequent delays in the writing of new programs for users, and a
shortage of skilled programmers has caused a move towards more user
friendly ‘query’ languages. These Fourth Generation languages allow
databases to be easily accessed to find information or produce reports without
the need for a programmer. (SQL is one such language e.g. SELECT name,
address FROM customer WHERE credit_limit>5000.)
Page 13
Increasingly the most common of structuring the data in the database is via
the relational model. This method uses tables, usually separate files, of
entities. These tables may be joined to generate the appropriate report.
Customer
(Customer_number
0123
0234
name
A. Wally
S. Jones
0345
G. Brown
address)
24 High Street
12 Huddersfield
Road
11 Downing Street
Stock
(Stock_number Description Quantity_on_hand Price)
0987
Beans
673
19
0876
Diet coke
285
69
Orders
(Customer_number
0234
0345
0234
Stock_number
0987
0987
086
Quantity)
6
1
2
These entities could now be joined using the two keys in the Orders entity to
generate an invoice.
As well as the account department using the data to produce invoices the
warehouse may use it to produce active stock reports or use it for re-ordering
stock. In this case there is no need to know the customers name and
address.
Page 14
To make use of relational files the entities must be linked by common key
fields and the data must not be in repeating groups. The process of getting
the data into usable tables is known as normalisation.
A common way of describing the entities in a database is through a Bachman
Diagram.
In other words a Customer may have many Orders, an Order could be for
many Stock Items. Each Stock Item has a Supplier.
Advantages Of A Database
There is less duplication of data. Only one copy is stored in the database.
Thus data is more ‘consistent’. When data is updated only one copy has to
be changed therefore there is less chance of there being inconsistent data.
New applications are easy to install. All the necessary data should already
exist within the database.
Because all access to data is centralised it should be easier to monitor
security.
It is possible to distribute a database over a wide area - the many sites of a
company for example.
Disadvantages Of A Databases
A DBMS is a large and complex piece of software requiring powerful
hardware to run on.
If the system should crash then the organisation has all it’s eggs in one
basket. File security of dumping and logging is vitally important. Some
systems may have backup hardware ready to take over in the event of a
major system crash.
Page 15
Other Issues
The problems associated with databases can be classified under the following
headings.
Security
The use of passwords and restricted data models to ensure that no
unauthorised person can access the data. In some situations specially secure
terminals may be used. This is especially important in light of the Data
Protection Act and other legislation.
Integrity
Ensuring that the data is as accurate as possible. One piece of incorrect data
may be used by many applications. Validation checks can be built into the
schema.
Consistency and Concurrency
Although only one copy of the data is kept it may be that a number of users
want to look at or alter the data at the same time. (Concurrently). This could
lead to problems, the value of a piece of data may change while someone
else is using it. To solve this problem record ‘locking’ is used. When an
application accesses a record a lock is placed on it preventing other
applications accessing it. The lock is removed when the first application has
finished processing the record.
Recovery
It the database does crash then recovering it to the state it was in before the
failure is vital. Dumping and logging techniques are used. But what of the
transaction currently being processed? Application programs may have to
explicitly ‘commit’ changes to the database and may ‘rollback’ changes if an
error is encountered. This helps to ensure that the state of the database is
always defined. No log is made until a transaction is committed.
Administration
A senior manger is usually responsible for ensuring the smooth running of the
database. Often called the Database Administrator or Management
Information System (MIS) Manager.
Page 16
Assessed Task 1
Developing a successful Information System is as "difficult as plaiting fog".
Describe, using examples where appropriate, what is meant by an Information
System.
Explain some of the problems faced by a systems analyst in trying to design
and implement a computerised system over a systems life cycle.
Write a report of 1200-1800 words.
Page 17
An Information Problem
The Travelling Salesperson
This exercise looks at some of the issues when attempting to solve an
information processing task. The idea is to organise into small groups and
solve the problem.
Issues to reflect on include:
 Do you know what is required? There is a danger of misinterpreting the
problem and following the correct instructions.
 There is a lot of information given. What information is relevant?
 It includes jargon and unfamiliar terms.
 There is no obvious methodology to adopt to solve the problem.
 How did the group work? Was information effectively shared and how
were group communications organised?
All these factors must be taken into account when analysing and designing
new information systems. In this example all information is complete and noncontradictory – in the real world this is not always the case.
Page 18
Structured Systems Analysis and Design
SSADM is a methodology to help in the investigation, analysis and design
stages of the systems cycle. It includes a number of techniques that help in
the planning and control of the development of a system. It is linear, one
stage follows on from the next with the output at one stage acting as the input
to the next.
Adopting rules and standard documents allows for better communication and
should ease the implementation and maintenance stages. Reviews can be
built in at the end of each stage, whilst diagrammatic tools can be used to
draw pictures that can be better understood by both specialists and other
users. It also has other software tools which can ease the (often time
consuming) use of the methodology. Other methodologies for designing
systems do exist - these are either based on graphical techniques such as
flowcharting, object orientated techniques or mathematical specification.
The two key features of SSDAM are getting the processes (functions) correct
and getting the data right. Cross-referencing between the two serves as a way
of ensuring consistency.
Data flow diagrams (DFD’s) are used to describe the current physical system
and develop the required physical system. Functions are shown together with
the data flows between them. This includes gaining an understanding of the
context, problems and requirements of a new system.
Data (or entity) modelling is used to define the entities in the system and what
attributes and relationships they have. These are used to help to answer the
question, what does the organisation need to keep data about?
Data Flow Modelling
DFD’s are made up of
Function or Source or recipient
process
of data
Data store
Data flow
The idea with DFD’s is to keep things as simple as possible, each process
can be broken down into further stages so try not to have more than 12
processes at each level.
The first step is to identify the data flows and system boundary.
Page 19
Example
A patient visits the GP with a suspected broken finger. The doctor gives the
patient an x-ray request form and tells the patient to visit the local hospital.
The patient telephones or calls to request an appointment and receives an
appointment card. On arrival at the hospital the x-ray department take a new
x-ray and retrieve any existing x-rays and reports and pass these on to a
consultant for a new report to be produced.
One copy of the report goes to the GP and one is filed with the x-rays and old
reports. The patient re-visits the GP to get the results of the x-ray.
The next step is to produce the level 1 data flow diagram of the area inside
the system boundary.
Page 20
DFD’s go through a number of stages. The first is to produce the current
physical system. This is taken and used to model the current logical model
(where time dependencies and physical references are removed). The DFD’s
together with a list of problems associated with the current system and
requirements for the new system are then used to generate the required
logical DFD then the required physical DFD model.
Assessed Task 2
Interview transcript from X-Ray department manager
“When patients arrive we direct them to reception. If they have an
appointment we check their appointment and get their patient number, using it
to retrieve their x-ray request from the file and pass the x-ray request to the
radiographers. The patient is sent to the waiting room. We also send a copy of
the x-ray request slip to the filing room so the patients’ history (old reports and
x-rays) can be extracted.
If a patient does not have an appointment card we make a suitable
appointment by finding a slot in the diary and giving them an appointment
card. We find their patient number and add the patient number to the x-ray
request and file it away for when they come on their appointment.
The radiographer takes the first x-ray request from the pending file, takes the
appropriate pictures and passes the film to a clerk who appends them to the
patients' history for the consultant. When the consultant sends the history and
the new report back they are filed.”
Complete a Level 2 DFD for the x-ray process.
Page 21
Data/Entity Modelling
This is concerned with the “things” that the system needs to store data about.
They may be:
 Physical – cars, products etc.
 People – customers, employees etc.
 Abstractions – order, invoice, booking etc. These link the other two
together.
Each entity should be uniquely identifiable by a key value. There should be
many of them in the system, with associated data and be important enough to
store. Entities are linked using a relationship.
1:1
1:N (Many )
M:N (Many to Many)
Many to many relationships need to be resolved by the introduction of a new
entity.
Each entity has attributes (items of data) e.g. an Employee entity would have
the following attributes. [Employee number, Name, Address, Tax code, NI
numbers, Pay to date, Tax to date]
An Example
A car hire company offers a number of different cars for loan. Each car is
serviced on a regular basis by a mechanic.
The entity relationship diagram for a car hire company may look something
like:
Page 22
Assessed Task 3
Draw an entity relationship diagram for the x-ray example. (Note there are
likely to be 7 entities with multiple connections between some entities).
List the attributes you would expect to store for each entity.
Page 23
Drawing Data Flow Diagrams and Entity Models Using GEDIT
There are a number of expensive CASE (Computer Assisted Software
Engineering) tools that will automate all aspects of the SSADM design cycle.
Our needs are considerably simpler and will use a free package to produce
DFD’s and EM’s.
The GEDIT software enables diagrams to be drawn but the symbols are
slightly different to the standards we have adopted.
Data Flow Diagrams
GEDIT uses Boxes, Ovals and Stores to represent Processes, Sources and
Data Stores.
Standard Symbols
GEDIT Symbols
Entity Models
Classes should be used instead of simple boxes and they are linked via
Aggregations.
Page 24
Entity Life Histories
Another useful tool associated with SSADM is that of describing what
happens to the entity over time. This acts as a useful check, before
programming is started, to ensure that there are no missing processes, it
shows how the entity exists over time, what processes interact with it, how it is
created, updated and deleted.
The idea is to look at all possible events that could happen to an entity and
describe these in a diagram. (The diagram produced links very closely to a
programming technique called Jackson’s Structured Programming and serves
as an initial design for the production of the programs that will implement the
system.)
ELH for Appointment
The * represents an event that could be repeated while the  represents an
alternative event. When we now look at our list of processes it becomes clear
that we will need a process to change appointments and this has to be
designed into our system.
Normalisation
When it comes to model the entities as data stored on a computer we may
need to do further work so that the data can be efficiently stored in data
tables. This is called normalisation and links to a set of mathematical rules for
the storage of “relational” data.
Page 25
Imagine we had the following data attributes for the Report entity. (Note that
this entity is based on the x-ray example, it is a possible way of storing the
data but would not have come about had we been following the other SSADM
stages.)
Patient# Name
P1056
Address XRay#
F.Jones 12 The
X3002
Way
M.Smith 5 Main
X3105
St
F.Jones 12 The
X3003
Way
P.Brown 7 Hill St X3309
Report
NXR Consultant Address Dept
P1001
Broken
finger
NFF
3
DW
1
OB
NFF
3
DW
P1001
F.Jones
P1003
P1001
12 The
Way
Cracked 1
rib
X3806 Another 3
broken
finger
1 High
St
Arm
Farm
1 High
St
8 Low
Rd
8 Low
Rd
JS
JS
What if a patient changes address? What if we add another x-ray? How can
we uniquely identify each report? What if we want to sort the data?
The first step to normalise the data is to remove any repeating groups, then
break any table that involves two fields to uniquely identify it. The resulting
structure gives 3 tables but is more flexible than a single table solution.
Patient# Name
P1001
P1003
P1056
Address
F.Jones
12 The
Way
M.Smith 5 Main
St
P.Brown 7 Hill St
Patient# XReport
Ray#
P1001
X3002 Broken
finger
P1003
X3105 NFF
Consultant
P1001
P1056
DW
JS
P1001
X3003 NFF
X3309 Cracked
rib
X3806 Another
broken
finger
DW
OB
JS
Consultant Address Dept
DW
1 High
FC
St
OB
Arm
ONC
Farm
JS
8 Low
FC
Rd
Page 26
FC
ONC
FC
FC
FC
Entity / Function Matrix
Once entities have been identified they are cross-referenced with the data
stores from the DFD. This serves as a check to see that all data is being held,
used and not duplicated.
The entity/function matrix is used to cross-reference the entities with the
functions we identified in the data flow modelling. As part of this check an
entity/function matrix is drawn. Each entity is listed along with all the functions.
All entities should have a process that creates, deletes and uses it.
The following example would be for a typical sales processing system.
Entity
Process
Place
order
Process
order
cancellation
Get stock
delivery
Add new
customer
For each
process…
Customer
Order Product For each
entity…
D=Delete
R
C
M
R=Read
R
D
M
M=Modify
M
C
C=Create
Assessed Task 4
Create an entity/function matrix for the X-Ray example. There should be in the
region of 7 entities and 12 processes. Remember that, as we are not doing
the complete X-Ray system, there will be some entities that are incomplete –
not all will have D and C effects.
Page 27
Review Of Information Systems
Both the public and private sectors have produced many studies of major IT
projects over the years with a view to learning from the factors affecting their
success or failure. (In 2000 only 28% of IT projects in the USA hit their targets
for budget, functionality and timeliness, 23% were cancelled outright.) Studies
have found similar problems with large information system projects as
described below.
The Design Of Projects
Organisations should ensure that they analyse and understand fully the
implications of the introduction of new IT systems to their business.
Project specification must take into account the business needs of the
organisation and the requirements of users – users must be involved in the
specification of the project and convinced of the benefits it will deliver.
Organisations should consider carefully the scale and complexity of projects
to assess whether they are achievable. Wherever possible they should be
broken down into manageable subprojects to be implemented with regular
milestones to measure progress.
IT architectures must be flexible to technological advances.
Managing Projects
Having high quality project management skills is essential.
Organisations must have contingency plans in case projects are not
implemented as planned.
Relationships With Suppliers
Organisations and suppliers must have a shared business vision and a mutual
understanding of requirements.
Organisations must maintain a close relationship with suppliers.
All parties must have a clear understanding of their respective roles and
responsibilities.
Post-implementation Issues
Sufficient time and resources must be allocated to training staff in the use of
the system and the required organisational and process changes that may be
required.
The success of projects should be reviewed after implementation to feedback
lessons for later projects.
Page 28
Achievement of benefits should be monitored throughout the life of the
contract.
Summary
The following factors need to be considered for the successful implementation
of an information system.




Have a clear vision about what your trying to achieve.
Look ahead and predict change.
Have good project management.
Establish good communication both with suppliers and internally with
different departments. (If it is a project working across an organisation
who will get the blame or credit?)
 The cheapest supplier isn’t always the best.
 Remember there is a culture gap between IT and business
management.
 Don’t throw good money after bad. Cancelling projects may be cheaper
than trying to make it work.)
Page 29
Assessment Criteria
The Learner
The Learner has
should be able achieved this
to:
outcome
because s/he
can:
Level 2
Describe the
Describe the
nature of an
nature of an
information
information
processing
system.
system.
Level 3
Explain the
problems
associated with
defining an
information
system.
HE
Examine a range
of alternative
approaches to
modelling a
system.
Understand the
systems life
cycle.
Describe a typical
systems cycle.
Evaluate the
stages in the
analysis, design
and
implementation of
a computerised
system.
Evaluate the use
of a systems
methodology in
the systems life
cycle.
Apply system
analysis
techniques.
Apply, in outline,
the techniques
associated with a
systems
methodology.
Use a range of
systems
methodology
tools.
Examine the
effectiveness of
a range of
design
techniques.
Identify the
problems in
modelling
information
systems.
Describe the
problems in
implementing a
typical computer
system.
Review the
reasons for the
failure of
information
systems.
Critically assess
the reasons for
the failure of
information
systems.
To understand
the impact of
ICT on society
in respect of
the prevailing
regulatory and
advisory
frameworks
and
examination of
good practice.
Describe relevant
frameworks or
good practice.
Evaluate the
impact of ICT with
regard to
frameworks or
good practice
Critically assess
the impact of ICT
with regard to
frameworks or
good practice.
Page 30