Jump to content

AQA Information and Communication Technology/ICT4/IS Within Organisations

From Wikibooks, open books for an open world

Information Systems

[edit | edit source]

Data processing systems are systems which capture data and store it in a more useful form for later use, such as an EPOS system storing a list of items sold in a transaction file.

Information systems (IS) take data (generally taken from the data capture system) and turn them into information which can be used to make decisions. For example, a supermarket information system may take the transaction files of the EPOS and turn them into a “best selling” list for decision making.

Information systems are important in decision making as they help managers collate the large amount of data that is at their disposal into the more usable form of information. Good quality and efficient processing of information results in better decision making.

Management Information Systems

[edit | edit source]

Management Information Systems (or MIS) exist to take information from internal (such as EPOS data) and external (such as market research) sources and turn them into useful information. Appropriate information is then relayed to managers at different levels, for the task they are responsible for.

An effective MIS becomes an integral part of the organisation to work together to meet the business objectives.

Taking the systems approach to the MIS, we have the Inputs (external and internal data), Processing, and Outputs (reports, query results and expert systems)

The development and lifecycle of an IS

[edit | edit source]

The systems lifecycle is a convenient lifecycle most systems follow (not just IS). The stage of the system in the lifecycle depends on which type of development is currently taking place on the system.

The systems life cycle has 6 stages.

Feasibility Study

[edit | edit source]

Why have a new system? The feasibility study aims to identify the reasons for having one (or not having one, if the existing system works well).

  • The current system may not meet the requirements of the organisation
    This could occur if the needs of the business change, or the previous system was not implemented correctly.
  • The current system may be outdated
    Technological advances may mean that the current system is inefficient, and potentially incompatible and becomes hard to maintain. For example, an old EPOS system may not be able to take advantage of the new "Chip & Pin" systems being deployed.
  • The system may be become difficult to maintain
    Old systems running on dated hardware may become difficult to locate replacements for, and developers who can develop in COBOL (for example) may be difficult to find.

The feasibility study primarily checks 5 areas of feasibility, called TELOS.

  • Technical feasibility - Does the technology exist to be able to create the system?
  • Economic feasibility - Is the capital available to develop the system? Are there cheaper ways of developing the same system?
  • Legal feasibility - Has the law been taken into account? (For example, the Data Protection Act)
  • Operational feasibility - Can current work practices support the new system?
  • Schedule feasibility - Can the system be developed in the required timeframe?

Analysis

[edit | edit source]

An analysis of the current system and user requirements must be performed at an early stage when developing the system.

Staff at all levels of the organisation must be involved in the analysis stage for an accurate analysis to be performed. This can be done with

  • Interviews
  • Document inspection
  • Questionnaires
  • Observation (such as a Time and Motion study)

The finished analysis report will:

  • show what (not how) the new system will work
  • document the data flows of the organisation (including the inputs and outputs)
  • analyse the costs and benefits of the system
  • explain how the system will be implemented
  • explain how the system will fit in with the organisational structure, and any changes to working practices required
  • consider alternatives (hardware configuration, software design, etc.)

Design

[edit | edit source]

This is where it is explained how the system will work. An explanation of hardware and software requirements should be included in the design document.

It should contain how the inputs and outputs of the system will be captured/output - including any validation checks for the input data, and an explanation of the processes of the system should be included.

The user interface should be described (usually with the aid of diagrams) here also.
Most modern systems are developed modually, so a breakdown of the modules and tasks of each will also be part of your design document.

Your design should also include your test plan. Your test plan should cover extreme, erroneous and normal data for each input, and the expected output of such.

The final section of the design document is the changeover plan. Here, we should be considering how we'll be implementing the finished system and changing over from the new one.

Implementation and Testing

[edit | edit source]

This stage is where the creation of the system from the design plan is performed. Ideally, the system should be tested continually with the test plan to identify problems as soon as possible for correction. There should also be milestone targets, where the system should be tested again.

Installation

[edit | edit source]

Once the system has been created, it should be implemented into the organisation (as per the changeover plan).

Maintenance

[edit | edit source]

Sometimes referred to as evaluation.

Once the system has been successfully installed, it needs to be reviewed to ensure that it is meeting the needs of the organisation as laid out in the analysis. If it is not, then there are types of maintenance that can be performed:

  • Perfective - Improvements to the system not originally identified in the analysis
  • Adaptive - Alterations to the system, say if the needs of the organisation change
  • Corrective - Solving problems in the system that were not identified during testing

Success or failure of an MIS

[edit | edit source]

Developers might only have one indicator of the success of a MIS. Whether or not it works. However, just because it works doesn't mean the MIS is successful. No-one may use the completed MIS, for example.

There are better indicators of MIS success.

  • Does the system get used?
  • Are the end-users happy with the system?
  • Does the system meet the original objectives laid out in the analysis?

Factors leading to success

[edit | edit source]
  • User involvement
    • Involving users in the analysis and testing phases tends to lead to a better system that will increase end-user satisfaction
  • System complexity
    • Highly complex systems tend to fail if they're undertaken by inexperienced teams
  • Development management
    • A poorly managed project is more likely to suffer from
      • Cost over-runs
      • Delays
      • Performance problems
  • Support from the management
    • New systems must be backed by the management of the organisation the system is being developed for
      • Correct funding must be made available
      • Manpower must be made available
      • Changes to the existing system must be supported

Factors leading to failure

[edit | edit source]

MIS can fail at any point in the lifecycle, but failures often become more apparent later on the lifecycle, when it becomes very expensive and difficult to correct them.

The most likely point of failure is at the analysis stage.

  • A poor analyst was appointed with poor analysis skills
  • The wrong type of research was done, especially with regard to the current system
  • Poor staffing levels for the analysis to take place
  • Users were not sufficiently involved

Failure at the design stage can be because of

  • Inability of the system to meet future needs
  • Major changes to working practices are required
  • Users were not sufficiently involved

At the implementation stage, the failure could be due to

  • An underestimate of coding time
  • Lack of necessary software development skills
  • A poor design
  • Poor internal communication
  • Low level of allocated resources
  • No proper test plan is designed, and therefore no proper testing occurs
  • The end-users are not involved in testing, and there are no acceptance tests

At the installation stage,

  • No conversion plan was developed
  • Insufficient funds allocated to conversion
  • Poor documentation of the new system
  • There are no performance evaluations