APPLICATIONS

TUTORS
These notes are designed to assist teachers of the course and are in a condensed format. Teachers should also consult
the syllabus for this module and adapt these notes accordingly by using extra examples and by filling out this material
with detail. Students will be expected to apply the material in a BUSINESS environment and with reference to the
particular situation specified in the examination question. Repeating these or any other notes in a generalised form is
unlikely to satisfy the required answers for any question.

In the syllabus, centres are warned that this modules is essentially concerned with the SYSTEMS of common large scale
applications. Aspects of general purpose software such as spreadsheet or word processing programs should not form
any part of the module and will not feature in the examination. Instead these are examined in the GENERAL PURPOSE
SOFTWARE module.

POINTS TO NOTE
1. Applications considered should be LARGE SCALE and include:
a. Mail order and customer accounts
b. Stock control
c. Supermarket sales
d. Library administration
e. Public utility companies administration – not the production of electricity/gas etc.
f. Hotel administration and bookings
g. Banking related to customer accounts.
h. Club membership
i. Estate agency (real estate) administration.
2. Large scale business would be concerned with large numbers of people/products/accounts etc and thus outputs on
screens are likely to relate to ONE person or product only.
3. The use of the words file and record should be used correctly. On computers, customers do not have files but their
details are recorded as records within files.
Candidates in past examinations have misused these words.
4. Candidates must have a realistic understanding of the structure of real data in the business world. For instance, stock
records would have details of past usage, perhaps on a weekly basis over 10 weeks. They would also have details of
particular ordering requirements of the supplier for each product – e.g. ordered in multiples of 10 with delivery lead
time of 21 days etc. Vague references in examination answers to “the data” are not enough. They must know the
details of each set of data, how it is captured, how it is processed and what then happens to it.
5. A wide range of the applications listed about should be covered. Covering only a limited number on the course
will limit the candidate’s choice in the examination. Teaching the first application may take many hours. After that,
subsequent applications should be shorter because the students should then know the extent of study required and
there will clearly be some overlap between applications. One or more of the applications could be set as a project
which could either be written up in detail and submitted for marking or alternatively, the students could be grouped
into small teams, each investigating a given application and presenting to the rest of the class. Teacher supervision
and comment would be essential here to ensure that the subject is treated FULLY and REALISTICALLY. Involve the
students in aspects of the application perhaps by encouraging some role-play where one student takes the role of
client and another plays the employee dealing with that aspect. One student could even represent the data carrier
and move between the parties involved carrying the appropriate data. Class discussion may bring out some of the real
practical problems that occur in the real world such as mislaid orders, late delivery, change of customer details etc.

www.icm.education | [email protected]
6. Each application should be treated separately. It would not be satisfactory to teach, one aspect of ALL applications
(e.g. input methods) because this will fail to gain a full overview of the whole application.
7. Online applications will NOT be tested on this paper but will be tested in the NETWORKS paper.

SPECIAL NOTE:
It is important to stress that the whole purpose of computers in business applications is to perform a task or tasks.
It is NOT to INPUT data. One way used by the author to emphasise this is to write the word OUTPUT prominent and
PERMANENTLY at the top of the teaching board. Every time a student strayed into suggesting input was an aim, I would
say nothing but point to the word OUTPUT. When this has occurred 5 times, the class begins to get the message. Input
is the necessary evil we have to endure to produce output.

THIS MODULE
The content of this module essentially breaks down into two main aspects which will be tested TOGETHER in the
examination. These aspects are:
1. The application areas – listed under 1 above
2. How the application functions.
a) Overall purposes of the business, range and limitations.
b) Data capture methods – there may be several within each application dependent upon the type of data. e.g.
For a bank, customer initial registration, change of address are clearly less frequent and may be initiated with a
paper form submitted and entered by a clerk at a keyboard. Cheque processing is another matter and needs to
be automated. Candidates will NOT need to know the practicalities of how devices read the data (this is in the
HARWARE and OPERATING SYSTEM module) but should know how the data must be presented for input and how
the user operates each device.
c) Consideration of different POSSIBLE methods of data entry and reasons for the choice selected.
d) The processing that occurs for each type of transaction. This would involve identifying files used AND their methods
of file organisation and access. A file might be used in more than one way. e.g. For a bank, registering a new
account is a random event as is the changing of address and required direct access and involves only individual
records on a file. Printing monthly statements is batch processing not triggered by any customer event and involves
the use of the whole file in one run but not necessarily all customers will receive statements on the same day – the
printing will probably be staggered over the month – how is this achieved?
e) Outputs that the application will produce. Some will be on screen and others on paper. Realistic layouts should be
covered. E.g. Invoices should show company standard headings, date, customer identification, columns for entries
of the variable transactions, totals, VAT and discounts, details of when, how and where to pay. How each output will
be used and possible follow-ups.
f) Overviews of the whole process by way of system flowchart and data flow diagrams. See Notes for Systems Analysis.
g) Special programs would be written for these applications – using a spreadsheet is NOT the answer as so many
candidates seem to think.
h) Personnel involved in the whole process should be identified.
i) Security aspects. The difference between data security and aspects of privacy of personal data is NOT part of
this module but students would be well advised to know the difference. Providing passwords will not replace a file
failure. If a back-up file is made, how often and in what form will it be? Back-up files need to be tested from time to
time to see whether they are actually readable – if not why not. Somebody should be responsible for checking this.
Somebody should also be checking that the one responsible is doing the check. Security needs to be REALISTIC.
“Do not bring in diskettes” is constantly quoted in answers but do people take much notice of rules if there is no
enforcement? Rarely is a suggestion made how this is particular event can be prevented. It could be quite easy –
computers without disc drives. Security guards are expensive and not practical in almost all businesses yet they are

www.icm.education | [email protected]
 quoted in almost all answers. Alternatives methods should be discussed such as location of the computing facilities
where the majority of company’s staff and outsiders would not have easy access – top floor. Simpler physical barriers
such as a password-activated keypad on doors may be more practical. Burglars alarms connected directly to police
stations can also be effective. The class should be encouraged to discuss security features in the real world. A list of
textbook answers is not sensible in all application and business areas.
j) Notes for aspects of this module can be found in Notes for Information Processing. The difference between the
modules is that in this one, candidates are expected to APPLY the knowledge to particular applications and
situations. Different business applications will use the features listed above in different ways.
k) Only a minor part of the module covers all the applications in a general way. This relates to:
• definitions (package, program, application, program and data)
• the difference between on-line and batch runs – which transactions typically use each.
• error correction.

EXAMPLE
To provide an understanding of the requirements of this module, an example is given for a public utility. It must not be
forgotten that the number of customers is likely to be VERY LARGE and hence the processes reflect this. The notes are
supplied in note form and would need to be covered and discussed in greater detail. They are covered by topic but the
best approach probably is to treat the application chronologically:
• The customer registers, perhaps changing some of the data or fills in missing parts at a later date
• Company generates meter reading data – for those due this month
• Meter reader captures readings – what if access to the meter is not possible?
• Meter readings transferred to main system
• Invoices generated and sent
• Payments received (or if not reminders)

EXAMPLE (IN OUTLINE) – Public Utility – ELECTRICITY SUPPLIER (ADMINISTRATION)

Purpose: To accept new customers, correct/amend customer details, update customer records. Read customer meters,
bill them and accept payment. Generate reports for management. Maintain past records for enquiry purposes.
People: Office staff will register new customers and deal with queries. Meter-readers will read meters in
houses. Computer staff will update files from these readings and subsequently produce bills that will be
despatched to customers. Customers will pay (or not). Office staff will deal with payments and request
non-payment runs that will generate reminder letters.
Source data: • New customers – The main data will be Name/Address/Telephone/Start date/Existing meter Number
and reading if one already present in the house. Some of this data may not be available at the time of
registration.
• Change of customer details, Enquiry OR Customer cancelling – letter or telephone call with details of the
account to verify authenticity.
• Meter reading – meter reading of usage on meter in household and meter number.
• Payment details – Account number, amount, date.
Data capture: • New customers/Changes – Keyboard using on-screen form.
• Meter reading – possible methods:
a) Palm top – new reading keyed in. Checked against expected reading/past usage.
b) Mark Sense form – mark sense reader with batches of readings per meter-reader.
c) Manual forms – keyboard entry at the office.
d) Customer reading – some companies accept meter readings by telephone/internet made by the
customer but require an official reading perhaps once per year.

www.icm.education | [email protected]
 e) OCR – to read the turn-around bill when money is paid IN FULL. Keyboard needed if there is any
difference.
Candidates could be asked to consider several of these and consider the advantages and
disadvantages of each.
Processes:
• New customer entry/enquiry/changes to existing customer – update the customer file. This includes
customer readings and reported errors. Generate new bill for a leaving customer.
• Create meter-round details from file for the meter-reader – file down-load onto palm-top, mark
documents or printed forms – each in round order (how to resolve this practical problem needs
discussing in detail).
• Input of meter readings to update accounts for billing.
• Bill production by batch processing - exceptions on request (customer leaving the area or correction
agreed with the customer)
• Payment recording – either direct to account from OCR form/keyed payment or batch of payment
records from remote office. The company may have a facility to take regular payments each month from
a bank account – this process would therefore need to be set up and recorded on file, in advance. How
will the adjustments be made when the actually electricity usage is more or less than predicted?
• Batch non-payment check.
Filing systems:
• Customer file
identity details: name/address lines/telephone/start date/payment method/round number/number within
the round/account number
meter details: meter number/previous reading/particular tariffs
history: past usage details.
Access: sequential for batch billing run direct access for individual enquiries, payments, meter reading
update.
Organisation: Index sequential to achieve both access methods.
• Meter readings file: (to update customer file)
Customer address/account number/round number/meter reader ID/expected reading (prediction –
to reduce errors when reading) /actual reading (filled in on the round)
Organisation: Indexed sequential – sequential access for round listing, indexed for amendments access.
Keys: Round number, then number within the round.
• History file (customer past usage) – why is it needed? Contents? How long is it retained?
Outputs & Devices:
• Billing invoices with payment slip – printed – which type of printer?
• Customer records for updating/enquiry – screen
• Reminder letters for customers & lists for accounts department – printed
Use of Outputs:
• Screen records for clerks to deal with problems and answer customer queries.
• Bills for customer to identify reasons for charging and make payments. Data clerks to accept payment.
• Reminder letters for customer to take remedial action and use for late payments.

This is only an outline. The candidates should be taken through the whole process, preferably in a logical sequence from
first registration of a customer to payment of bills. The scale of the problem should be discussed to show one customer
is only one of a large number.

www.icm.education | [email protected]
Questions:
The following and many more questions should be discussed and answered. There are no precise answers but those
that are put forward should be realistic within the confines of this application and situation.
• How can the company cope with say, 1 million customers?
• How often are bills printed? If this is three monthly (50 working days allowing for other processes and building in safety
margins), all of the following considerations need to take this into account.
• How many meter readers might be needed assuming that the reading is staggered over the three months? It therefore
follows each would need their own data capture device and appropriate file down-load for each round, prepared in
advance.
• How long does it take, realistically, for a meter-reader to move from one house to the next and read a meter? Simulate
this process to find out.
• How do you deal with house which the meter-reader cannot gain access on his round? It is not economical to return to
a single house another day. What happens to subsequent billing. Candidates may have experience of this or be able to
talk to parents about it.
• How are businesses treated differently from homeowners? Business may have the equivalent of 10, 100 or 1000 times
the electricity usage of householders and have multiple meters. Are there special rates for business?
• How many operators (and therefore computer terminals) are needed to deal with queries and changes?
• What hardware (type?) would be needed to print 1 million bills over three months, again staggering them over three
months?
• How do you post 1 million bills over the three months? The letters would need to be addressed. If the customers are
all local (large city) it may pay to employ delivery staff otherwise general mailing systems would be used. How do you
address these mailings quickly?
• What security is needed to ensure continuity? Even temporary failure of a fast main printer could have major delaying
effects. How can this be overcome? Failure midway through a run means some of the bills are printed and the file
updated while the remaining customers are effectively unprocessed. How can the system cope with this problem?
• Past data is filed in a history file. How far back in time should this go? How frequently should the history files be
updated?
• How are reminder letters generated? If just 1% fail to pay on time, this is 10,000. This would be 200 per day over 50
days. How does the system identify this group? Should the reminder run be performed once per week/once per month
- this would delay income? Clearly they would have to be batched and related to when the meter was read/bill sent.

The questions are almost endless. When any of these systems are initially created, such questions will face the system
designers. This is therefore a good way to teach this module encouraging enquiring minds to look for solutions (and
problems). Students will have a better understanding and will almost certainly be more confident in answering any
question in the examination.

www.icm.education | [email protected]