Part 2 Examination – Paper 2.1
Information Systems December 2003 Answers
1 (a) The assessment of technical feasibility is concerned with the technical performance criteria the system will have to meet to be accepted. For example:
– The ability of the system to produce defined outputs in a given time scale. For example, to produce 120,000 examination certificates in two weeks.
– The ability of the system to provide minimum response times under certain conditions. For example, no more than a two-second response time when accessing student information.
– The facility to input a large number of documents in a given time scale. For example, to enter the results for 200,000 students in four weeks.
– The facility to communicate data to distant locations. For example, to transfer examination results to London.
– The facility to interface with other software already used by the organisation. For example, to allow data mining tools to be used on student information.
(b) Technical issues might include (two required):
(1) The technical issues concerning the scanned input of hand-written scripts into the computer system. Will it be possible to scan with sufficient quality to allow the marker to read the script on the screen?
(2) If sufficient quality can be achieved in the scanning process, will it be possible to scan with sufficient speed at that quality to meet the marking process deadline?
(3) The technical issues concerning the security of transfer of scripts through the Internet and how the marker accesses the allocated scripts from his or her computer. What equipment will the marker need for this on-line access? For example, what size and quality of display unit will be required?
(c) Operational and social feasibility is concerned with the organisational, social, human and political impact of the system. Amongst the issues considered are:
– Likely job changes caused by the system and how these might affect the motivation of employees.
– The disturbance of established organisational structures within the company and trading relationships with suppliers. – The expected skill requirements of users of the system and the implication of bridging any gaps in those skills. – Any conflicts with how the organisation usually does business, the image it projects and the business ethics it wishes
to adhere to.
(d) Operational or social feasibility issues might include (two required):
(1) Health and safety issues arising from on-line marking. The markers could potentially spend a long time looking at the screen and guidance will have to be given on equipment and work practice.
(2) The software skill levels of markers. Appropriate training will have to be given in the software application and supporting technology.
(3) The employment implications for staff at head office will also have to be considered. They have less involvement in the proposed system and so redundancies may be possible.
(e) Costs (three required) – Costs of scanning – Hardware costs – Software costs
– Training costs (for examiners and markers) – Increased data communication costs Benefits (three required)
– Reduced courier costs
– Speedier processing of scripts (no checking and less time spent with the courier) – Reduced checking costs
– Improved moderation
2 (a) A bespoke solution is one developed specifically for an organisation. In this instance the Institute of Information System Administrators would comprehensively specify their requirements for the On-Line Marking Project (OLMAP). This requirements specification would be used by the internal Information Systems (IS) department or by an external software house to produce a system that exactly matched the requirements. The software would be owned by the Institute, who could make changes to it in the future to reflect changes to the original requirements.
A software package is a generalised solution to an application area offered for sale by a software vendor. In this instance a software company has recognised that a number of educational and training organisations would benefit from on-line marking software. They have constructed their own specification of requirements and developed a software package called Emark which they now market and license throughout the world.
(b) Advantages of the software package approach to systems development might include (two required): Quality
The software package is a proven product that has undergone systems testing (in development) and user acceptance testing (by the users who have already bought and used the package). Hence the product should be bug-free, as well as fulfilling most of the functional requirements of the application. The implementation should not be affected by the programming errors and misconceptions that are normally associated with bespoke systems development.
Time
The bespoke systems development needs to be tightly specified, designed, programmed and tested. These parts of the lifecycle are very time-consuming and during this period requirements may change, so complicating the process even further. The software package is a product that already exists. It can be purchased and implemented almost immediately. There is no requirement for design, programming, unit and systems testing.
Other perceived advantages include:
High quality documentation and training available for inspection
Maintenance and enhancement provided at a fixed price under an agreement Try before you buy, because the software is already available
(c) Disadvantages of the software package approach to systems development might include (two required): Failure to completely fit requirements
One of the most commonly claimed disadvantages of the software package approach is the inability of the product to fit all of the users’ requirements. This means that either:
(1) Users have to make compromises and accept that they will not get all the functionality they require, or (2) Tailored amendments will have to be made to the software product to deliver the required functionality.
Whichever way is chosen, it is clear that most software packages do not fulfil all the user requirements defined for a particular application. Furthermore, they often include facilities and functions not required by a particular user, which only serve to confuse when the product is implemented into the organisation. In contrast, the bespoke solution should completely fulfil all the user’s requirements and, if it doesn’t, will be amended until it does.
Financial stability of the supplier
Internal Information Systems (IS) departments do not go out of business. However, external software suppliers are subject to the vagaries of management and the markets. There is a risk that they may go out of business, or experience financial problems that affect the quality of their support and development services. It is possible to reduce these risks (through Escrow agreements) but the disruption likely to accompany the enactment of such an agreement should not be underestimated. Other disadvantages include:
Inability to generate a competitive edge because the package is also available to competitors Ownership is retained by the supplier
Legal redress is virtually impossible because of the licence agreement
(d) In the context of the OLMAP project, performance testing will mean – Testing the scanning time of a batch of scripts.
– Testing the response time of the system when a specified number of examiners and markers simultaneously access scripts for marking and moderation.
(e) – Testing the scanning time of a batch of scripts.
A test can be set up where a certain number of scripts are taken from the IISA Head Office and scanned into the system. The time taken for scanning can be recorded and further tests may be undertaken to confirm this time. This time can then be scaled up to estimate the time for scanning the scripts of 200,000 students. Scanning time should scale linearly with the number of scripts scanned into the system.
– Testing the response time of the system when a specified number of examiners and markers simultaneously access scripts for marking and moderation.
This test is difficult to simulate. It is likely that a limited test can be arranged with markers and examiners asked to access the system and record the results. However, the use of load testing software would be more effective. This software allows the testers to simulate a large number of ‘virtual’ users and to diagnose any bottlenecks. Any problems can be addressed before the software is released. The point here is that the response time of the system is unlikely to scan linearly with the number of users accessing it.
3 (a) (i) In Direct Changeover/Conversion, the new system is implemented completely and the old system is withdrawn. Thus processing of the current system may end on a Friday night and all transactions pass through the new computer system from Monday morning onwards. Where possible, direct changeovers should occur in slack periods and take advantage of natural breaks in the operations of the organisation, such as industrial holidays.
(ii) Direct Changeover/Conversion is particularly appropriate to the OLMAP application because there is a natural break in processing within the application. It is not a continual process (like order processing, invoicing and payroll) but an application that runs for a limited amount of time every six months. Direct Changeover/Conversion demands very thorough testing, but it is the quickest and cheapest implementation strategy.
(iii) In parallel running the old and new systems are run simultaneously for an agreed period of time and results from the two systems are compared. Once the user has complete confidence in the system the old system is abandoned and transactions are only passed through the new one. Parallel running places a large administrative overhead on the user department because every transaction has to be done twice – once through the established procedures and then again through the new computer system.
(iv) Parallel running makes very little sense in the OLMAP application because the proposed and current systems are so different. The proposed application area (marking) is currently not computerised and any attempt at a parallel run would be costly (involving courier and marking costs) and time consuming. It is unlikely that the results would be very valuable (for example, what lessons could be gained from marking a paper script and its screen-based equivalent?) and they could not be achieved in the tight time constraints of the marking process. The OLMAP application will need thorough testing, but there is little to gain from parallel running. If direct changeover/conversion fails, it would be relatively easy to switch back to the current process as all the paper examination scripts will still be available in a warehouse in Singapore. (b) (i) Project manager
The project manager is responsible for running the project. He or she will agree the Terms of Reference with the project sponsor or client and use this as a basis for developing the project plan. The project manager gives out work to the people working on the project and is responsible for motivating and monitoring the work of these people. He or she will monitor and report on the progress of the project, identifying and dealing with slippage as it occurs. The project manager’s job ends when the project is accepted by the project sponsor or client, signifying that the objectives of the project have been met.
(ii) Project sponsor or client
The project sponsor or client is the person who commissions and owns the project. It is the sponsor’s responsibility to set and agree the Terms of Reference of the project, which will include project objectives and scope. He or she will also agree certain critical deliverables as the project progresses as well as receiving reports on the progress of the project and any problems that have been encountered. It is the job of the sponsor to promote the project within the organisation (hence motivating the project manager) and to finally sign-off the project and agree that the objectives have been met and the project has ended.
4 (a) In this context outsourcing is the contracting out of IT/IS services to an external supplier. Many organisations, like Caetshire County Council, have traditionally employed their own information systems employees. In the outsourcing arrangement these employees may be transferred to an external IT/IS company and hence become employees of that specialist contractor. This contractor then provides an agreed service to the host organisation for a specified contract period. At the end of this period the host organisation is able to evaluate competing suppliers before placing the next contract. The specialist supplier assumes profit and loss responsibility for the delivery of the service as well as undertaking the employment and employment rights of employees.
(b) The perceived advantages of outsourcing might include: Emphasis on core business
The principle of outsourcing is that specialists are brought in to provide the supporting functions, allowing the management of the host organisation to concentrate on its core business. The quote from the Chief Executive of Caetshire County Council suggests that this is one of the primary reasons for outsourcing. Thus outsourcing means that the management of the organisation can focus on its reason for existence, rather than being diverted into time consuming tactical issues concerning its support services which it neither understands nor values. Indeed IT/IS is the core business of the outsource supplier and so should benefit from that organisation’s concentration on its core business.
Cost reduction
It is reported that the overwhelming reason an organisation explores outsourcing options is to identify opportunities for cost reduction. The perception is that outsourcing vendors can provide IT/IS services more cheaply due to economies of scale and due to the fact that resources are only paid for when they are needed. One writer likened it to electricity ‘you use less, you pay less’. Many organisations have been prepared to publicly claim outsourcing savings of between 10% and 50% of the IT/IS budget. Most IT/IS departments are accounted for as an overhead function and senior managers tend to evaluate such departments on cost efficiency. Consequently they are always seeking opportunities for cost savings in the IT/IS department. Other likely advantages include:
– Access to new resources and technical expertise
– Variable staffing requirements to fulfil project requirements
(c) The perceived disadvantages of outsourcing include: Contract length
Most of the outsourced IT/IS contracts are for a relatively long time-period. This is because of the high cost (where relevant) of transferring assets and employees as well as making and maintaining the required technological investment. The long time-period of the contract causes three particular problems.
(a) Difficulties in terminating a contract if the supplier turns out to be unsuitable.
(b) Problems in foreseeing what the business will need over the next five or ten years (typical contract lengths) hence creating difficulties in establishing an appropriate contract.
(c) The problems of re-forming an internal IT/IS department after the contract period is finished. Scope definition
Most IT/IS projects suffer from problems associated with successfully defining the scope of the system. The same problem afflicts outsourcing arrangements. Many difficulties are due to contractual misunderstandings between the outsourcer and the outsourcing supplier. In such circumstances the customer believes that the service they require is within the contract scope whilst the supplier is sure it is outside and so is subject to extra charges. Contractual disagreements often lead to tension and mistrust.
In some instances the scope of the original contract has been purposely restricted to justify the outsourcing agreement and award the contract. Unfortunately this leads to significant extra charges to cover variations and this again contributes to customer/supplier tensions as well as under-use of technology as the customer strains to keep the contract within the bounds of the budget.
Other likely disadvantages include:
– Where it occurs, staff problems concerning the transfer and resultant motivation problems
– Difficulty of developing an ‘intelligent customer’ capable of managing the outsourcing and IT/IS replacement decisions. 5 (a) Advantages of interviewing include (three required);
Rapport
The interview provides the analyst with the opportunity to build rapport with the user. The analyst will often require the co-operation, support and enthusiasm of the user throughout the whole project. The face-to-face interview is an excellent opportunity to develop the rapport that will be the necessary foundation of a good working relationship.
Clarification
In an interview it is possible for the analyst to clarify a question that has been misunderstood by the user and to ask supplementary questions that take into account the interviewee’s initial response. In contrast, this responsiveness to the original question is not possible in the pre-determined question sequence of a questionnaire.
Document access
It is often necessary for the answers to questions to be illustrated by documents, leading to subsequent questions that allow an analysis of those documents. In interviews at the user’s workplace, documents are readily available and may be photocopied and subjected to detailed scrutiny.
Observation
Interviewing at the workplace allows the analyst to observe the physical workplace. This may give important clues about bottlenecks and workflow as well as providing an insight into the physical environment, where dirt, noise or an absence of physical space affects the deployment of hardware.
(b) Questionnaires may be appropriate as follows: (three required) Geographically distributed users
It is time-consuming and expensive to interview users who are widely geographically distributed. The cost of collecting their views and requirements probably outweighs the insights they will give. In such circumstances it may be appropriate to interview a small number of users and then send a carefully constructed questionnaire to the rest.
Large number of users
There may be insufficient time to interview all the possible users of the system. Consequently, it may be decided to interview a sample of users and to get the requirements of the rest through questionnaires.
Factual information
The analyst will need answers to factual questions about locations, volumes and processes. For example, how many invoices are raised every day? Factual information requires the user to investigate rather than respond with instant answers and such questions are particularly appropriate to questionnaires.
Anonymity
In some circumstances the analyst may wish to collect information whose accuracy would be enhanced if the provider of the information remains anonymous. For example, information on the effectiveness of management, or the efficiency and service of an internal IS department. Questionnaires provide a confidential way of gathering such information.
(c) Prototypes may help users define their requirements in a number of ways. For example, in some projects it is very difficult for users to articulate their requirements because they have very little experience of the application under development. It may be equally impossible for technical experts to adequately explain the possibilities. In such instances a prototype may be developed to show what is technically possible and this is used to fire the imagination of users as they attempt to place the technical possibilities within the context of their own business or application.
In other circumstances a prototype may be constructed to agree a detailed operational requirement. For example, the entry of on-line order details may be a key business process. The screen and dialogue for the entry of these details may be agreed in a workshop between the users and a programmer using a Fourth Generation Language to develop a prototype of the interface. This will allow the immediate agreement of content, the sequence of data entry and the layout and presentation.
(d) Requirements should be formally documentedusually in a Requirements List or Requirements Catalogue. The requirements can then be formally inspected and agreed by the user. The entry in the Requirements Catalogue will provide all the information necessary to trace a requirement from the initial request to the final sign-off after testing.
It is unusual for a project to have the time, resources and money to implement all the requirements defined in the Requirements Catalogue. Consequently users are asked toprioritise these requirements. A simple approach to this is to use the MoSCoW classification of each requirement as
Must have, Should have, Could have, Won’t have (at least, not this time)
Agreeing such priority will mean that all the users are clear what will be implemented now and what will be deferred. Hence the development work is prioritised and user expectations are managed.
6 (a) Functional correctness of the software
This describes the ‘fit’ of the software to the specified functional user requirements. A bespoke solution should exactly fit such requirements and this fit should have been verified in user acceptance testing. However, experience suggests that many bespoke systems do not completely fulfil user requirements and this lack of fit is not identified in the limited time often given to user acceptance testing. A common reason for this lack of fit is the inability of users to unambiguously specify their requirements and consequently the ambiguity of this specification leads to systems that do not work as they are supposed to. Devising some measure to express the percentage of business functions successfully available to the user may assess the ‘fit’ of the software to the user requirements. For example, n% of the functions defined in the user specification have been successfully implemented in the bespoke system.
Alternatively, the organisation may track the number of requests for system changes in the months following system implementation. The reasons for these requests may be codified by the person requesting the change so the allocation of an appropriate code will allow analysis of the changes required to implement functionality correctly. However, in reality it is likely that most immediate change requests are raised to implement functionality that should have been there in the first place. The cost or time taken to make such changes may be expressed as a percentage of the total cost or time taken to produce the system.
Reliability of the software
The reliability of the software refers to the amount or percentage of time the system is available to users for them to use. The time when the system is not available is colloquially known as ‘downtime’. The software may be functionally correct, but this is of little consolation to users if the system is ‘down’, so they cannot use it.
The reliability of the system may be measured through ‘downtime’, with the number of hours that the system is available to the user expressed as a percentage. The expectation of reliability may have been defined in an initial Service Level Agreement. For example, the system will be available 99% of the time in the period 7.00 am Monday to 7.00 pm Friday. The actual availability of the software may be monitored against this target.
The number of faults reported may also measure the reliability of the system. This may be a complementary measure to ‘downtime’. For example, one error may cause significant downtime because it is difficult to find and fix. Alternatively, fifty smaller errors may have less effect on overall availability.
Usability
Usability is concerned with the ability of the users to actually use the software. So, the system may be functionally correct and reliably available to the users, but functions may be under-used or not used at all because they are beyond the user’s competence. The software may be genuinely difficult to use with confusing feature names and/or a confusing interface, or it may be that users have not understood their training or failed to be trained at all.
Usability might be measured by logging the number of calls to the HELP desk caused by the user being unable to use or misusing the system. The HELP desk operator may classify the reason for the call and any common errors reported, leading to changes in the interface and in the supporting documentation.
Trained observers watching the user using the software may also assess usability. Observers can record errors and hesitation and feed their findings back to the support team. These observations might be supported by questionnaires where users have been asked to assess the usability of different functions in the software using a five-point scale.
(b) Corrective maintenance
Corrective maintenance is concerned with immediately fixing faults. These faults may prevent the software from running at all (and so concern reliability) or may lead to business functions working incorrectly (functional correctness). So, failure of the software or incorrect implementation of holiday entitlement codes in the HR software would lead to corrective maintenance. Perfective maintenance
Perfective maintenance is carried out to improve the performance, usability, efficiency and effectiveness of the software. No changes are made to functionality but the human-computer interface may be simplified to improve usabilityand eliminate common user errors and difficulties. Technical changes to programs and databases may be made to improve efficiency and maintainability. For example, re-writing the staff appraisal system to speed up its operation would be classified as perfective maintenance.
Adaptive maintenance
Adaptive maintenance is concerned with modifying the software to fulfil new requirements that have emerged since the software was implemented. These requirements could not have been fully anticipated at the time of the original specification. For example, changes in employment law made by a government may affect the functionality of the HR software and hence demand adaptive maintenance.
Part 2 Examination – Paper 2.1
Information Systems December 2003 Marking Scheme
1 (a) 1 mark for each relevant point up to a maximum of 3 marks
(b) 1 mark for each relevant point up to 2 marks for each issue. Two issues required giving a total of 4 marks (c) 1 mark for each relevant point up to a maximum of 3 marks
(d) 1 mark for each relevant point up to 2 marks for each issue. Two issues required giving a total of 4 marks (e) 1 mark for each relevant cost/benefit. Three costs and three benefits required giving a total of 6 marks.
2 (a) 1 mark for each relevant point up to a maximum of 4 marks
(b) 1 mark for each relevant point up to a maximum of 2 marks for each advantage. Two advantages required giving a total of 4 marks
(c) 1 mark for each relevant point up to a maximum of 2 marks for each disadvantage. Two disadvantages required giving a total of 4 marks.
(d) 1 mark for each relevant point up to a maximum of 4 marks (e) 1 mark for each relevant point up to a maximum of 4 marks
3 (a) (i) 1 mark for each relevant point up to a maximum of 3 marks (ii) 1 mark for each relevant point up to a maximum of 4 marks (iii) 1 mark for each relevant point up to a maximum of 3 marks (iv) 1 mark for each relevant point up to a maximum of 4 marks (b) (i) 1 mark for each relevant point up to a maximum of 3 marks (ii) 1 mark for each relevant point up to a maximum of 3 marks
4 (a) 1 mark for each relevant point up to a maximum of 4 marks
(b) 1 mark for each relevant point up to a maximum of 4 marks for each advantage. Two advantages required giving a total of 8 marks.
(c) 1 mark for each relevant point up to a maximum of 4 marks for each disadvantage. Two disadvantages required giving a total of 8 marks.
5 (a) 1 mark for each relevant point up to 2 marks for each advantage. Three advantages required giving a total of 6 marks. (b) 1 mark for each relevant point up to 2 marks for each circumstance. Three circumstances required giving a total of 6 marks. (c) 1 mark for each relevant point up to a maximum of 4 marks
(d) 1 mark for each relevant point up to a maximum of 4 marks
6 (a) (i) 1 mark for each relevant point up to a maximum of 3 marks (ii) 1 mark for each relevant point up to a maximum of 4 marks (iii) 1 mark for each relevant point up to a maximum of 4 marks (b) (i) 1 mark for each relevant point up to a maximum of 3 marks (ii) 1 mark for each relevant point up to a maximum of 3 marks (iii) 1 mark for each relevant point up to a maximum of 3 marks
