Answers

Part 2 Examination – Paper 2.1

Information Systems June 2003 Answers

The following three questions refer to the Berrington Insurance Group scenario.

1 (a) Benefits might include

– A long-term reduction in maintenance and enhancement costs as only one software solution has to be supported in the
Group. The costs of supporting and enhancing the current fragmented solutions must be significant and are unlikely to
decrease.
– Standardized procedures throughout the Group should lead to more staff mobility, allowing the Group to move employees
between companies to reflect demand and provide better career opportunities. Furthermore, training, documentation and
other aspects of the administrative process can be standardized.
– The production of standard documents and information should improve management information. One of the problems
of the current system is that the incompatibility of information systems means that little accurate Group-wide information
is available and it is probably inaccurate.
– Reduced costs from economies of scale should be achieved by purchasing multiple copies of one solution. This will apply
to the original licences, the support costs and the provision of services and products such as training and documentation.

(b) Categories of costs might include

Training costs
The users will have to receive training in the use of the package. It has already been noted that in some companies in the
Group employees currently only have access to character-based dumb terminals. The advocacy of a GUI based solution will
also mean that a significant number of employees will have to be given basic Windows training.
Data conversion costs
It is very likely that the data in the current systems will have to be transferred to the new software. This is a significant task
and is likely to be costly and time-consuming. Data mapping between the current systems and the proposed solution will
have to be undertaken for each individual application and data conversion and creation programs written and tested.
Hardware costs
It has been noted that different hardware platforms are used throughout the Group. It is unlikely that the selected software
solution will run on all of these platforms, particularly given the different proprietary and non-proprietary Operating Systems
in use. Hence, investment in new hardware and Operating Systems at some of the sites seems inevitable.

(c) The costs and benefits may be compared with a variety of techniques. One method is to value the financial costs and financial
benefits of the project over a specified number of years. Subtracting costs from benefits gives the overall cash flow for each
year. The value of this cash flow can be discounted using standard tables to take into account the time value of money. The
project passes the breakeven point when the cumulative cash flow over the life of the project becomes positive, although this
does not take into account negative flows after that point. Alternatively, the cash flow can be evaluated over a set period (say
five years). If it fails to break even within this constraint then the project is not worth considering from a financial perspective.
Many companies have standard investment techniques and return on investment expectations. The existence of these at
Berrington Insurance Group should be investigated, as they are not explicitly stated in the scenario.

(d) Some of the identified benefits are either intangible or very difficult to value. For example, it is difficult to put financial values
to the benefits of Group-wide information, improved security and the motivation provided by GUI based up-to-date software.
In contrast most of the costs are very tangible.
Some of the costs (for example, hardware costs) are infrastructure costs that will bring other benefits and costs to the
organization. These other costs and benefits cannot be reflected or allocated in a project-based cost-benefit analysis. It is likely
that costs will be over-stated from a project perspective and benefits outside the project scope will not be reflected. Hence it
will be difficult to evaluate the solution.

2 (a) 1. Decide what we want. We must be clear what we want the system to do.
The first stage must be to clearly determine the requirements of the system. This will be achieved by interviewing the
key stakeholders in the system and documenting their requirements. Facilitated workshops, questionnaires and
document analysis may also be used to help establish and refine these requirements. The sponsor of the project will be
required to prioritise the agreed requirements, to distinguish between necessary and desirable features, and these will
then be incorporated in an Invitation To Tender (ITT) that will be sent to prospective suppliers. It is likely that different
companies within the Group will have different requirements for their Claims Handling and Policy Administration systems
and so detailed fact-finding is necessary to prevent operational problems in the future. Furthermore, a strong project
sponsor will be required to prioritize and harmonize what are likely to be competing requirements from the different
companies in the Group.
2. Find out who supplies what we want.
There must be a defined procedure for finding potential suppliers. One approach is to place an advertisement in the
computer press giving brief details of the application and inviting potential suppliers to request the detailed Invitation to
Tender. In this way, potential suppliers identify themselves. Alternatively, it may be possible to locate potential suppliers

11
 by searching trade directories and their Internet equivalents. This will identify potential suppliers who may be directly
approached to see if they are interested in submitting a proposal. In practice, a combination of both approaches might
be desirable, as it will allow suppliers to be considered who did not see the advertisement in the computer press, as
well as those whose entries are either missing or not up-to-date in the trade directories.
3. Ask these potential suppliers to bid for the contract.
The Invitation To Tender is a document that is sent to a potential supplier. This document not only defines the functional
requirements of the system, but also requests information about the supplier (for example; financial details, reference
sites, trading history) and the proposed product solution (number of copies sold, support arrangements, price etc). The
Invitation To Tender also suggests the contractual arrangements of the project as well as defining procedures about how
any response to the tender should be submitted. The company needs to receive competing bids in a fair and standard
format so that they are easy to compare and so that no supplier can complain about preferential treatment of a
competitor.
4. Select the most appropriate solution.
A procedure must be in place to compare competing proposals. This is usually a two-stage process based around
evaluation matrices. In this approach certain requirements (for example, functional match) are given a weighting and
each possible solution is rated against that requirement. The overall score for the suggested solution is calculated and
usually the best two or three are taken forward to a second stage. This second stage requires a much more thorough
review of the functional match of the software (usually by using it for a short period) as well as an investigation of the
supplier’s financial position and their attitude to customers. The appropriate matrices are updated with new information
and amended assessments and a winner is finally selected.
5. Purchase and implement the most appropriate solution.
This requires a contractual agreement to be set up with the supplier. Details must be worked out about payment terms,
licences and support agreements. The implementation of the package solution must also be carefully planned. Training
sessions must be scheduled for appropriate staff, supported by sufficient copies of the documentation. Implementation
will usually involve file conversion, taking data from the current systems and storing it correctly on the new one. In many
applications this will be a very time-consuming job and hence has to be meticulously planned. In the scenario example,
the movement of data from the various companies to a standardized package will in itself be a major project, requiring
data mapping in up to thirty companies with different file conversion software or procedures required in each company.

(b) (i) A risk in adopting this approach to systems development is that the software house providing the package goes out of
business. This will mean that the software package is no longer supported or developed by them.
(ii) (1) Ensure that an escrow agreement is in place so that a copy of the source code of the software is lodged either with
the customer or with a third party. In such an agreement a copy of the source code is lodged with a reliable third
party that will release it to the purchaser in certain circumstances, including the bankruptcy of the supplier.
(2) Ensure that a pool of in-house developers is maintained with expertise in the software development language used
by the package. Not only will this assist the company in the operational use of the package, but it will also provide
a pool of labour to provide initial support if the source code is received under the enacting of the escrow agreement.

3 (a) (i) Measures might include:

Setting up physical gatehouses at each site where preliminary security measures are enforced before allowing visitors
onto the site and hence into the reception area.
The use of card swipe entry systems and turnstiles in buildings, which only permit restricted entry into an extended
reception area.
The removal of all corporate markings on the buildings so that their use and purpose cannot easily be identified from
the outside. Removing address details of the company from all trade and telephone directories can support this strategy.
Such directory entries only give the telephone details of a centralised call centre.
For example, the major information processing centre of a news agency in London, has an external gatehouse manned
by specialist security staff as well as turnstiles within the reception area. It is so anonymous that even the security officers
of the building next door do not know the identity of their neighbour.
(ii) Measures might include:
Setting up secure areas within the building so that only a restricted number of carefully vetted and monitored personnel
are allowed access to secure areas. Access to these secure areas is again controlled through card swipe or biometric
controls.
Monitoring staff movements through CCTV, with a control centre linked to security staff who can react quickly to possible
or actual unauthorized behaviour.
Locate secure areas on separate floors that are controlled through restricted access and internal gatekeepers. For
example, a major insurance company has one floor that has no lift access and can only be entered via a staircase
manned by two security staff. All activity on this floor is constantly monitored by CCTV and cleaning staff for this floor
are carefully vetted and monitored.

12
 (iii) The software should have passwords that are difficult to guess and that are regularly changed. Passwords must not be
displayed on the workstation and should not be ‘lent’ to other employees to allow them to enter areas of the software
for which they are not authorized.
The anti-hacking infrastructure should be reviewed with firewalls established and anti-virus software purchased and
updated via an on-line support contract.
Attempts to gain unauthorized software access should be monitored and reported by appropriate software monitors and
audit trails. This should allow the identification of possible miscreants and allow their future monitoring or perhaps justify
their removal.

(b) (i) The most obvious document associated with the software package is the User Manual. For this to be effective it should
concentrate on what business functions the user can perform, and where these may be accessed in the user interface,
rather than on how the software implements these functions. For example, there should be separate sections (or even
documents) that focus on business functions, such as ‘Raise a Payment against a Claim’, ‘Raise a Policy Renewal’ etc.
This is preferable to long textual explanations based around the menu structure of the software (which may not match
the functional structure of the business or the responsibilities of its employees). The documentation should also be
up-to-date (reflecting what the package actually does in this release), with a well-designed layout, clear print and hard
wearing paper. It should be written in a language that the business user understands.
In the type of software required by Celia Berrington, there will also be technical documentation concerned with installing
the software into a technical environment, together with a description of the procedures that are necessary to keep it
operational. This will also include installation or implementation processes and also how to recover from hardware loss.
These manuals are aimed at a more technical audience and hence it is their technical accuracy and completeness that
is more important than the use of business terms and language.
(ii) For training to be effective, Celia Berrington must first establish what she wants the training to achieve. Once these
training objectives have been set, she must identify the gap between what employees know now and what they must
know in the future to use this software effectively. This is the ‘skills gap’ between their current knowledge and what they
will need to know to be effective when the software has been installed.
Training attempts to address this gap but to do so it must be delivered at an appropriate time and use an appropriate
method. A number of approaches might be looked at, from conventional lecturer-based training courses to
computer-based tuition. The latter will allow the employees to move at their own pace, using the medium of the
application – the computer. But however learning takes place (and different people have different learning styles) it must
be assessed if the organization is to have some confidence that the training objectives have been achieved. Attendance
on courses is no guarantee that the necessary skills have been attained and so some formal assessment (perhaps again
on-line) is advisable. The key point is that standard proven training courses will be available for a software package
supported by tried and tested documentation and exercises. Furthermore, computer-based tuition may also be available,
developed at a cost that would be prohibitive to a bespoke solution.

4 (a) The process may include:

Unambiguous definition of the end product
The objectives of the project will help the manager define the end deliverables of the project. These objectives may need some
elaboration to ensure that they are unambiguous and they must be signed-off by the project sponsor.
Split the project into manageable chunks
The definition of the end products (deliverables) of the project will be used to split the project into smaller product or work
structures. These will define smaller stages of the project that will be needed to achieve the overall end product. Standard
product or work breakdown structures may be available to assist the project manager in defining these manageable chunks.
Estimate the effort required to produce each chunk
The duration of these smaller stages will be estimated using an appropriate estimating method. Standard estimates may be
available to the project manager from defined product or work breakdown structures.
Allocate precedence to the manageable chunks
Some chunks of work rely upon other work or products being completed. Such precedence within the work must now be
defined and allocated to each of the lower level chunks. Appropriate allocation of such precedence will allow certain elements
of the work to be done in parallel.
Develop an initial plan
The precedence allocation and work estimates will allow the construction of a network diagram using either the
activity-on-node or activity-on-arrow conventions. Both of these techniques allow backward and forward passes through the
network to produce a critical path and the estimated delivery date of the project.
Refine the plan to reflect constraints
Finally, the project plan may be amended to reflect resource and delivery constraints. Resources may be allocated to the
chunks of work and if such resources are unavailable at the point they are required (for example, staff could be on holiday)
the project plan must be amended. Other constraints (such as the delivery date of hardware) may also be reflected in the plan
and a new plan and project delivery date drawn up.

13
 (b) (i) The project plan allows the deliverables of the project to be linked in such a way that reflects the precedence of these
deliverables. Each of these deliverables has an estimated duration. Forward and backward passes enable the Earliest
and Latest Start Times of each deliverable to be calculated, together with the overall duration of the project. The critical
path consists of the series of deliverables whose total duration defines the minimum duration of the project. For each of
these deliverables the Earliest and Latest Start Times are the same. Any delay in starting or finishing any of these
deliverables will lead to a delay in project delivery. In contrast other deliverables will have float, where some delay in
delivering that particular deliverable will not be reflected in delay to the project as a whole.
(ii) The project manager must be aware of the critical path for the following reasons:
(1) The estimates on the critical path must be validated with particular care as they define the overall duration of the
project. It may be possible to re-visit some of the deliverables to see if they can be broken down any further, hence
changing the critical path and the likely duration of the project.
(2) Delay in the delivery of such deliverables will affect the final delivery of the project. Hence progress on such
deliverables should be closely monitored. In contrast, deliverables with float can be given less attention.
(3) The successful achievement of the estimated duration is critical for these deliverables. Hence deliverables on the
critical path might be best allocated to the most experienced team members.

(c) Allocation of resources

Project management software allows the definition of resources (for example, people) and the allocation of those resources to
work on the project plan. If the resource is unavailable at this time then the software automatically adjusts the project plan
to take this into account. Resources may also be allocated standard costs and the software uses this to work out the overall
project cost. The project manager can compare this to the budgeted cost.
Facility to record progress
Most project management software allows the user to record the completion and part-completion of deliverables. This allows
the production of standard reports showing progress in the project. These would be very time-consuming to produce manually.
Re-planning of projects
Changing requirements, changes in estimates and project slippage always affect projects. The use of project management
software allows such changes to be quickly reflected in the project plan. The effect of such changes (particularly on the final
delivery date) may be recorded and submitted to the sponsor. Again, manual maintenance of such changes would be
extremely time-consuming.

5 (a) External design is concerned with parts of the design that the user can see and evaluate. For example, input screens, output
reports, menu design and dialogue structures are all parts of external design. Problems with external design emerge very
quickly and need to be addressed, otherwise they become a source of irritation and discontentment.
Internal design is concerned with aspects of the system that are transparent to the end user. For example, data file and
program design are important parts of internal design, but the consequences of poor design in these areas are seldom very
obvious (except in poor performance) to the end-user. Poor internal design may lead to inflexible systems and high
maintenance costs but these may not emerge for some time. Furthermore, it may not be clear to the end user that these high
costs have their roots in poor design.

(b) (i) It is important that similar features are displayed or used consistently within the software. For example, function keys
always perform the same function throughout the application, error messages always appear in the same format and
position and mandatory field entry is always shown in the same way. Such consistency assists the user, because parts
of the software they are unfamiliar with, work very similarly to parts that they are more experienced in. This gives them
confidence in using the software. In comparison, lack of consistency leads to bewilderment and hesitancy in using the
software. Users are confused when part of a system does not act like they expect it to.
(ii) When most users approach a software application for the first time they bring with them experience of other software
and evidence suggests that they try and use commands and techniques they have used in other software applications.
Consequently, the adoption of industry wide standards means that different applications have the same underlying
characteristics, providing familiar territory for inexperienced users. Committees and working groups have promoted such
industry wide standards in the past. However, in the GUI environment de facto standards have been defined by
Microsoft and promoted in their design guidelines. It would be perverse for a Windows application developer not to
adhere to these standards, hence failing to provide familiar signposts for the inexperienced user of their software.
(iii) Context sensitive HELP refers to HELP text that is relevant and appropriate to that part of the interface and the problem
currently experienced by the user. So, for example, if the user has mis-specified an arithmetic command in a spreadsheet
package, then HELP text is displayed just concerning this problem. This HELP text is usually accompanied by an
example application of the command and it may also suggest a correct alternative to the command that the user has
specified. Appropriate HELP text allows the user to gain immediate, relevant help and gives them the opportunity to
solve their own problem and avoid time-consuming telephone calls to Help Desks.

(c) (i) In most instances it is difficult for the user to envisage and contribute to the external design without being given the
opportunity to experience using the software in some way. Paper based alternatives (such as a series of screen-shots)
lack the dynamic nature of the actual system and are not presented in the medium of the final system. Simple prototypes

14
 clearly show how the system will look and feel and allow the user to gain some experience of using the software. This
allows them to make relevant comments back to the developer and to participate effectively in the design process.
(ii) Interviewing users is a traditional method of identifying user requirements. However, it is usually restricted to one or two
users per interview and is largely led by the systems analyst. These restrictions, together with the perception that
interviews are largely IT-directed, led to the suggestion of facilitated user workshops. A user workshop is an open forum
where participants can explore requirements, issues and problems in a more reflective environment. The workshop is
centred around users with aspects developed and encouraged by an experienced facilitator. This person is skilled in
facilitation but need not have significant IT skills or be completely familiar with the business domain under discussion.
IT staff are at the workshop to provide technical input and perhaps to explore design solutions using Rapid Application
Development (RAD) tools, such as CASE Tools and Fourth Generation Languages. The proceedings of the workshop are
documented, perhaps by a dedicated scribe who attends the workshop in that capacity.

6 (a) Examples of quality characteristics are:

Correct functionality
The software provides the functionality specified by the users in their Requirements Specification. A failure to provide such
functionality may mean that key business processes cannot be carried out until appropriate system design and programming
changes have been made.
User-friendliness
Although the software may provide the required business functionality it must do so in such a way that the user finds it easy
to use. If the software is difficult or cumbersome to use then it may be difficult or impossible for the user to utilize the business
functionality.
Robustness
The software may be functionally correct and user friendly, but its quality is undermined if it regularly crashes and so is
unavailable to the user for significant periods of time. Such failures will mean that key business functions cannot be carried
out and this may crucially affect the viability of the business.

(b) (i) A simplified V model is shown below:

Analysis User Acceptance

Testing

Design System Testing

Coding Unit Testing

The left-hand side of the V model shows the main stages of systems development. Within each stage there will be
defined quality assurance procedures to review and accept the products developed within that stage. For example, Data
Flow Diagrams might be produced in the Analysis stage. These will be subjected to formal static walkthroughs, ensuring
that the diagram appears to be functionally correct, follows defined construction standards and makes reasonable sense
in the context of that business domain. Similar walkthroughs will take place on design deliverables. Static walkthroughs
of program designs and code will also be required as evidence suggests that these are an effective method of finding
programming faults.
On the right-hand side of the V model are stages of dynamic testing that relate to each of the left-hand stages. Unit
testing (Component and Assembly testing) defines the dynamic tests a programmer executes on a program. For example,
a programmer will execute path tests to test that each path through the program executes correctly. System testing is
performed against the design. It is a series of dynamic tests run by the person responsible for the design
(analyst/designer) or by a dedicated systems tester working from the specified design. System testing is concerned with
proving the business functionality, usability and robustness of the software before it is released to the user. Finally,
end-users (or their representatives) perform user acceptance testing, against the product of analysis and the
Requirements Specification signed off by the user. Failure to conform to requirements or problems of usability must be
identified and addressed.
(ii) The V model promotes the definition of products at the end of each stage, which form the basis of subsequent testing.
For example, the Requirements Specification produced at the end of analysis is the document against which user
acceptance testing is planned and executed. This emphasises that testing is against something specific, not against
requirements or criteria arbitrarily invented by the tester.

15
 The model promotes the partition of testing and the allocation of testing to appropriate people. For example, exit criteria
will be defined for unit testing indicating what tests must be executed in that stage. This means that the programmer is
clear about what tests they should do and the system tester (who receives the unit tested programs) is also aware of
what tests have been performed and so is unlikely to duplicate tests and hence use their time ineffectively.

(c) (i) Performance testing is concerned with putting the system under extreme conditions, exploring the limits of the
performance of the application. These tests will explore the effect of large data files, the result of concurrent use by a
large number of users and the effect of high activity by other concurrent applications. In some instances, such as web
testing, it is difficult to predict the performance requirements of the system, as the number of concurrent users is
unpredictable and uncontrollable. However, performance testing will give some indication of the technical limits of the
application.
(ii) It is time-consuming to manually create large stored data volumes, and it is difficult to manually simulate the concurrent
use of these by a large number of actual users. However, the performance of the system can be simulated using
automated tools such as LOADRUNNER, which allow the tester to predict the performance of the system when it is used
by a large number of users. Furthermore, this simulation may also reflect the concurrent use of other software as well
as the characteristics of the hardware and the communication links used in the system. Not only does the automated
tool simulate performance but it also diagnoses where the bottlenecks are, so allowing the tester to feed back suggestions
to the systems designer.

16
Part 2 Examination – Paper 2.1
Information Systems June 2003 Marking Scheme

1 (a) Up to 1 mark for each valid point up to a maximum of 2 marks for each valid benefit. Three benefits required, giving a total
of 6 marks

(b) Up to 1 mark for each valid point up to a maximum of 2 marks for each valid category of cost. Three cost categories required,
giving a total of 6 marks

(c) Up to 1 mark for each valid point up to a maximum of 4 marks

(d) Up to 1 mark for each valid point up to a maximum of 4 marks

2 (a) Up to 1 mark for each valid point up to a maximum of 3 marks for each valid part of the process. Five parts required, giving
a total of 15 marks

(b) (i) Up to 1 mark for each valid point up to a maximum of 2 marks

(ii) Up to 1 mark for each valid point up to a maximum of 3 marks. Up to a maximum of 2 marks for each way.

3 (a) (i) Up to 1 mark for each valid point up to a maximum of 4 marks

(ii) Up to 1 mark for each valid point up to a maximum of 4 marks
(iii) Up to 1 mark for each valid point up to a maximum of 4 marks

(b) (i) Up to 1 mark for each valid point up to a maximum of 4 marks

(ii) Up to 1 mark for each valid point up to a maximum of 4 marks

4 (a) Up to 1 mark for each valid point up to a maximum of 8 marks

(b) (i) Up to 1 mark for each valid point up to a maximum of 3 marks

(ii) Up to 1 mark for each valid point up to a maximum of 3 marks

(c) Up to 1 mark for each valid point up to a maximum of 2 marks for each feature. Three features required, giving a total of
6 marks.

5 (a) Up to 1 mark for each valid point up to a maximum of 4 marks

(b) (i) Up to 1 mark for each valid point up to a maximum of 3 marks

(ii) Up to 1 mark for each valid point up to a maximum of 3 marks
(iii) Up to 1 mark for each valid point up to a maximum of 3 marks

(c) (i) Up to 1 mark for each valid point up to a maximum of 4 marks

(ii) Up to 1 mark for each valid point up to a maximum of 3 marks

6 (a) Up to 1 mark for each valid point up to a maximum of 2 marks for each valid characteristic. Three characteristics required,
giving a total of 6 marks.

(b) (i) Up to 1 mark for each valid point up to a maximum of 5 marks

(ii) Up to 1 mark for each valid point up to a maximum of 3 marks

(c) (i) Up to 1 mark for each valid point up to a maximum of 4 marks

(ii) Up to 1 mark for each valid point up to a maximum of 2 marks

17