chapter vi mis design and development process

63/MITSDE

Chapter VIMIS Design and Development Process

Learning Objectives

Reading this chapter would enable you to understand

• The processes used for designing, developing and implementing MIS

• Techniques used for determining management information needs

• The techniques of systems analysis and design

• Methods of managing MIS development projects

Contents

6.1 Introduction

6.2 Challenges of the MIS Development Process

6.3 Determining Management Information Needs

6.3.1 Business Systems Planning

6.3.2 Critical Success Factor (CSF) Method

6.3.3 End/Means (E/M) Analysis

6.4 Systems Development Methodology

6.4.1 Systems Development Life Cycle (SDLC) Approach

6.4.2 Problem Definition

6.4.3 Feasibility Study

6.4.4 Systems Analysis

6.4.5 System Design

6.4.6 Detailed System Design

6.4.7 Implementation

6.4.8 Maintenance

6.5 Systems Analysis and Design

6.6 Requirements Determination and Structuring

6.6.1 Requirements Determination

6.6.2 Choosing the Right Method

6.7 Requirements Structuring

6.7.1 Data Flow Diagram (DFD)

6.7.2 Logic Modelling

6.7.3 Data Modelling

6.8 Advanced System Analysis

6.8.1 Rapid Application Development (RAD)

6.8.2 Object Oriented Analysis (OOA)

6.9 Managing the MIS Development Project

6.9.1 Who Develops the MIS ?

6.9.2 People Side of MIS Development

6.9.3 Managing User Expectations

6.9.4 Critical Issues for MIS Development and Operation

Summing Up

Self-assessment

References

6.1 Introduction

Although many organisations greatly benefit from their MIS, developing and

implementing such systems successfully is far from certain. The literature on

this subject contains many and sometimes very expensive examples of failures.

Box 6.1 gives one such case relating the London Stock Exchange. Such cases

64/MITSDE

Management Information System

have led to much study of the reasons for failure and the factors that contribute

to success. By adopting systematic approaches for designing and developing

MIS, a great deal of delays and excess costs can be avoided in addition to

getting MIS that is much more effective and efficient. In this chapter we will

discuss ways of designing, developing and implementing MIS.

Box 6.1

Example of failure of a major information system

development project

In the early 1990s, an information system titled Taurus was sold as

a multi-million pound project that would revolutionise the London

Stock Exchange. The London Stock Exchange decided to modernise

its operations by introducing new technologies both, within the

exchange itself and among the organisations associated with it. The

project started with all the optimism of any new venture sold as

revolutionising an industry.

However, in 1993, after years spent in development, the head of the

London Stock Exchange announced that the Taurus system had

failed. It never reached the operational stage; at its demise parts of

it had not been implemented.

In the initial days after the announcement, people searched for

answers: why had Taurus failed? A highly regarded firm of computer

consultants, Ovum Consultancy, suggested that the failure of Taurus

was a direct result of poor configuration management practices.

Configuration management involves identifying the components of

a software system and tracking the changes made to them. It also

involves maintaining information about how to assemble the

components into systems. In practice developers and organisations

find configuration management activities very difficult, because the

software components have technical relationships—called

dependencies—that must be coordinated by the people working on

that code.

Taurus was a highly distributed system; teams of developers worked

together on individual parts of the projects. At the same time Taurus

required that all the organisations linked to the London Stock

Exchange build Taurus-compliant systems. In this highly distributed

environment, the different developers and organisations struggled

to coordinate their ef forts with each other. Technically, it was

difficult to align the distributed development efforts so that all the

systems worked together. Socially, it was hard to maintain

communication among the different developers and organisations

working on the project so that everyone understood what changes

were taking place and why.

Software engineering researchers know that dependencies exist

between pieces of code. However, little is known about how technical

dependencies among modules of code create and reflect social

dependencies among the developers, teams, and organisations

working on them. The story of Taurus clearly illustrates that the

problem of trying to coordinate these technical dependencies is a

managerial problem.Source: Grinter (1996)

65/MITSDE

6.2 Challenges of the MIS Development Process

Frequently managers are faced with a situation where they find that they are

receiving such a lot of information that they just don’t have enough time to

go through all the information received. Yet, at times they find that the MIS

does not generate adequate information on some important issue that they

need to tackle. The information may be incomplete, incorrect, or confusing.

Still worse, they may face a situation that an important report has been sent

to them, but they are unable to locate it when required because it has been

lost somewhere been the piles of reports on their desk or in filing cabinets.

At times it becomes difficult to locate the required information stored on

one’s desktop computer. This problem can be solved by careful study of

management information system requirement of each manager in the

organisation and providing him or her with just that information. The

approach of providing managers with all possible information required by

them is unworkable for several reasons. First is the problem of information

overload. Individuals have limited capacity to absorb and understand the

information reaching them. Too much information can tire the mind of the

recipient, which in turn leads to carelessness, poor understanding, and

mistakes. Then as we have seen in the paragraph above, the presence of

irrelevant, extra, or unimportant information can make it difficult to use the

relevant and information. Finally, extra information means extra costs.

Quantity of information and its content - that is what the information describes

– is just one of the parameters used for identifying management information

requirements. Other parameters include the following factors:

• Nature of Analysis and Presentation: This determines the extent to which

the information is easy or difficult to understand by the manager and

the time needed to spend in doing so (pre-defined versus as requested

or required).

• Time of availability: There are several dimensions to this parameter

including frequency, recency, acquisition lead time, on-demand v/s

routine, periodic versus occasional, repetitive versus one time.

• Accuracy.

• Reliability.

• Security and Authentication.

Thus any good MIS design and development process must address the following

issues effectively -

• Problems of effective communication between users and developers of

MIS. MIS development calls for good understanding of management,

industry, and IT, all of which are usually not available with either the

MIS users or developers.

• Problems in understanding and combining information needs of

managers from dif ferent functions and levels in a common MIS.

Considerations of economy, speed, and data integrity favours a unified

MIS covering the whole organisation. However, because of complexity

of designing and developing a truly unified MIS, it has remained an

ideal rather than reality in practice.

• Usually a management system, of which MIS is a sub-system, is a very

complex system, comprising of a vast array of dif ferent types of

subsystems, interacting with the environment which is even more

66/MITSDE


complex. In a situation like this it is a laborious, costly and time-

consuming task to understand this management system and define its

requirements.

• Need for the organisation to keep pace with changes in environment,

increasingly demanding customer and intensifying competition.

• Using effectively the opportunities fast developing in IT capabilities.

• Keeping in control the capital cost and time of installing advanced IT based

systems. These can be substantial and have a tendency to escalate easily.

• Eliminating the need for frequent and major modifications in the MIS.

This is relative difficulty and costly for advanced IT based MIS.

• Need to manage the human aspect of the MIS user, and other

stakeholders such as employees, customers, suppliers, and other

environmental agencies.

Managers need to decide on the types of information systems that should be

installed in the organisation to support and facilitate their management duties

and responsibilities.

Emergence of sophisticated IT including computers, telecommunication and

automation has created new opportunities for the improvement of operational

and managerial performance. To use these opportunities, managers and MIS

developers need to adopt appropriate methods for designinig, developing and

implementing MIS.

Managers need to take an active role in identifying and clarifying their

information requirements. It is not enough to just limit themselves to the

information they are using currently. Information technology offers many

opportunities for improving business per formance through improving

managerial effectiveness and business process transformation. The total MIS

development project can be broadly divided in two major parts – determining

information needs for managers, and designing and developing information

systems that fulfil these requirements effectively and efficiently. We will first

take up the issue of determining the management information needs, and then

discuss the methodologies for designing and developing information systems.

6.3 Determining Management Information Needs

Three methodologies can be adopted to determine management information

needs:

• Business Systems Planning – To specify problems and decisions.

Developed by IBM

• Critical Success Factor (CSF) – Developed by John Rockart of MIT

• End/Means (E/M) analysis – Developed by Wetherbe and Davis at the

University of Minnesota

6.3.1 Business Systems Planning (BSP)

The business system planning (BSP) method approach was developed by

IBM. It helps to build MIS for both long and short-term information needs of

an organisation. It provides an objective way of identifying information system

priorities for the organisation, and focuses on developing a good overall design

of the way data is maintained in the system so that it can support information

67/MITSDE

system development activities over a period. For example, supplier related

data may be used in 20 different reports and stored in 6 different databases.

Any change in some major information about a supplier may thus need to be

changed in each of the 6 databases separately. The BSP approach tries to

overcome or reduce this problem by using data architecture that supports

multiple applications.

Major activities involved in a BSP study are:

• Top management making a commitment to the MIS development

project.

• Organise a BSP study team consisting of managers from different

functional areas.

• Hold a kick-off meeting of the BSP study team.

• Identify major business processes in the organisation that are needed

to manage the resources of the business.

• Define data classes using different matrices to establish relationships

among the organisation, its processes and data requirements. The

process/ organisation matrix relates the organisational process activities

to people responsible for these activities. Also the classes or types of

data that are used for different processes are identified and charted on

another matrix of data class versus processes showing indicating

processes that use or create the data.

• Determine executive perspective on how effectively the current MIS is

supporting various business processes.

• Identify business problems as perceived by managers, processes

impacted, processes causing the problems, and the impact of the

problem.

• Identify systems development projects based on data classes and business

processes, and based on this define an information architecture.

• Determine priorities for the system development projects based on their

benefit, impact, probabilities of success and demand based on value to

users.

• Review information system management capability to develop proposed

integrated database to environment supporting multiple applications.

• Develop recommendations and action plan to move towards the planned

integrated database environment and develop required applications.

Although the BSP approach is a comprehensive technique for planning

information systems, its application can be time consuming and expensive.

Also it focuses more on more information processing aspects rather than on

managerial effectiveness. It has been criticised also for not paying attention

to identifying opportunities for effective use of new IT. This technique is more

suitable for use by IT professionals trained in the design of database systems

rather than line managers using the MIS.

6.3.2 Critical Success Factor (CSF) Method

CSF was developed by John Rockart of MIT. Critical success factors are

management aspects believed to be crucial to the success of an operation.

They are sometimes described as necessary although not sufficient conditions

for success. The “escape clause” indicates that we do not yet have a complete

understanding of the reasons of success in each situation, but we may draw

68/MITSDE


some general conclusions. The CSF method identifies key business goals and

strategies that must be addressed with business strategy. An effective way of

spotting business problems is to develop key indicators of the health of the

business and to focus on significant deviations from planned performance.

In the first step in the CSF method, the manager identifies his or her goals.

In the next step he looks for the critical success factors underlying these

goals – that “ what has to go right” to achieve a business goal. For example,

for the goal of increasing the market share of a company there could be

different critical success factors. A management consulting firm organising

management development programmes may need to identify seminar topics

that are of interest to the prospective clients, and create a pool of effective

trainers on these topics. An FMCG (fast moving consumer goods) company,

to achieve the same goal may have to focus on advertising effectiveness and

an extensive distribution network. The critical success factors applicable to a

company depend on the nature of the industry and the business strategy

adopted by the company.

Information need of managers is derived from the critical success factors by

finding ways of measuring how well these are being achieved. For example,

advertising effectiveness may be measured by change in market share, and

distribution network may be measured by the number of retail outlets stocking

the goods.

Each of the measure of CSF effectiveness becomes an input for defining

information system requirements. After compiling all the different information

needs, decisions can be taken on the best ways of making these available to

the managers

The CSF method enables managers to identify their own information needs

clearly and correctly. The MIS can then be limited to only such information,

eliminating all other reports, which are often created in traditional MIS more

because of easy availability of input data rather than based on value of

information contained. The main limitation of the CSF method is that it focuses

on information needs of individual managers, rather than the organisation as

a whole. This is not very helpful in building integrated MIS that need to look

at the totality of information required by all the managers in the organisation.

6.3.3 End/Means (E/M) Analysis

E/M analysis technique was developed by Wetherbe and Davis at the University

of Minnesota. Its purpose is to determine effectiveness criteria for outputs

and efficiency criteria for the process generating the outputs.

The first part of the E/M analysis process, related to the “end” aspect, starts

with identifying outputs or services provided by the business process, and

moving on to clarifying what makes these outputs effective for the recipient or

the user. Finally information needed to evaluate the effectiveness of outputs is

selected. For example, the output of a demand forecasting system are forecasts

and market demand. The effectiveness of this will depend on factors like accuracy

of the forecast, and the prompt availability of forecasts. Information required

for measuring the effectiveness may include analysis of variation between forecast

and actual sales, and analysis of delays in providing the forecasts.

69/MITSDE

The other part of E/M analysis, concerned with specifying efficiency criteria

for the processes generating the outputs is based on answers to three

questions:

• What are the key means or processes used to generate or provide the

outputs?

• What constitutes efficiency in providing the outputs?

• What information is needed to evaluate that efficiency?

Continuing the example of demand forecasting process, the key means or

processes used for generating the outputs might include obtaining and

analysing data on past demand and other factors impacting the demand. The

efficiency in this case may be the cost of processing per month, and this cost

may be calculated based on a standard costing system that may be related to

parameters such as computer processing time.

6.4 Systems Development Methodology

A system development methodology establishes a set of procedures that conform

with a life cycle. It helps to keep MIS development project cost and time within

limits, ensures that the results meet business requirements, and that MIS is

properly documented. It gives the users an opportunity to review and confirm

their requirement of the MIS at each phase of MIS development. These constitute

checkpoints for detecting and correcting errors at various points in the

development process. Also it becomes possible to review and modify time and

cost estimates for the project. If required, decisions can be taken on major

modifications in the MIS project approach including cancelling it.

6.4.1 Systems Development Life Cycle (SDLC) Approach

One widely used system development methodology is “Systems Development

Life Cycle (SDLC)” approach. It is a structured technique for developing

systems that cover procedures for controlling information system development

projects. It is a useful tool for producing reliable and maintainable systems.

In SDLC, each stage (subsystem) is defined in terms of activities,

responsibilities, milestones and deliverables (the output from one subsystem

to another subsystem). The SDLC approach helps to control the large and

complex systems that consume large amounts of time and resources.

SDLC may divide the total project from four to 12 phases. One phase is

completed before beginning the next phase. This approach emphasises

documentation and checkpoints, and requires detailed planning and budgeting

at each phase.

SDLC has the following advantages and disadvantages:

Advantages

• Lends itself to good control

• Phase deliverables well defined

• Clear checkpoints makes reviews easy

• Creates detailed documentation which is valuable for maintenance

70/MITSDE


Disadvantages

• Time and cost estimation is difficult

• Can be very slow

• Requires that requirements are defined abstractly, without interaction

with the “system”

• Overall ownership of the process is usually on “systems” people

The key steps of systems development life cycle (SDLC) are listed below:

• Problem Definition

• Feasibility Study

• Systems Analysis

• Systems Design

• Detailed Systems Design

• Implementation

• Maintenance

6.4.2 Problem Definition

Problem definition, the first step of SDLC is intended to clarify the problem

to be solved, improvements to be made, or new opportunities seized by the

proposed MIS. This is really clarifying the objectives for undertaking the MIS

project in the first place. These objectives may be one or more of three general

types. The first of these types of objectives is improving efficiency of the

information system. The focus here is on reducing costs related to the

information system rather than improving the overall performance of the

organisation. When the objective is to reduce the information costs, the MIS

development is focused on automating the process of providing information

to managers, without much stress on improving the nature or quality of

information over the existing levels. The second type of objectives relate to

improving the effectiveness of managers to improve the business performance

by improving the quality of information provided to them. Here the MIS

attempts to provide managers with information not available to them in the

present system or improves the quality of information in terms of features

like timeliness, analysis, presentation and accuracy. The final type of objectives

aim at bringing about major improvements in efficiency and efficiency of the

total business by transforming the way in which the business processes are

undertaken. For example, Wal-mart achieved major improvement in its sales

and at the same time reduced costs of inventories, by introducing a totally

new concept in its procurement practices, where instead of placing purchase

orders on its suppliers for replenishment of stocks in its stores, it introduced

a system of its major suppliers initiating replenishment on their own based

on information on movement of stocks in Wal-Mart stores available to them

with an advanced IT based system using the POS (point-of-sales) information

generated electronically at Wal-Mart checkout counters.

The main methods used for problem definition are - collecting information

from user managers and others through interviews, and questionnaires. This

study may be initiated by sponsoring user managers or an MIS professional.

In any case, the objectives finally developed must be accepted by the sponsor.

The output of this step is a formal document to guide the analyst and the

users with a broad view of the system development project. It specifies the

objectives, scope, any special constraints, material to be used, and resources

71/MITSDE

available (cash limits, time deadlines, persons committed). When an outside

consultant is used, this document provides the inputs for the terms of reference

of a contract. The terms of reference may be provisional pending the findings

of the feasibility study.

6.4.3 Feasibility Study

As the name implies, the feasibility study examines the practical feasibility of

solving the identified problems and achieving the desired objectives within

reasonable time and cost limits. An analyst makes a rapid study of current

practices and systems and of any problems and gaps. Alternative solutions are

examined and may include merely solving specific problems, broad improvements

across the existing system, or moving to a new system. A cross-section of users

is consulted. It results in a feasibility report that advises whether a project for a

new system is worthwhile or whether work should be stopped at this stage.

Whatever the advice, it must be substantiated with facts and explanations. These

should include an indication of resources needed and the costs and benefits,

even though it will be difficult to determine these with accuracy.

This done by doing performing a simple system analysis type exercise without

going into too much depth or details. In this phase, the current system is

studied to identify specific problem areas and possible areas for improvement.

The scope and depth of such study is determined by the objectives set in the

problem identification stage. Based on this study, outlines of alternative MIS

design options are developed and their cost, benefit and time are made. If one

or more of these alternatives are found to be attractive enough, the project

moves to the next stage of systems analysis. When more than one feasible

alternatives are identified, the one most promising may be chosen. When

none of the alternatives is considered by the top management responsible for

sponsoring the project, it may be terminated at this stage itself.

Output of the feasibility study includes the development of a logical model for

the proposed system, specific performance objectives to be achieved by the

proposed system, and time and cost estimates for developing and implementing

the system.

If the advice is to proceed with the project and develop a system, then it

should specify the outline of a solution. It may offer a choice between two or

more options, and it may specify ways in which the original terms of reference

need to be adjusted.

Information on existing methods and organisation for this step is collected

using interviews, questionnaires. If required, some additional analysis based

on organisational records may also be carried out. Logical models of the

existing and proposed systems are constructed using systems diagrams that

graphically depict the main process steps and information flows.

6.4.4 Systems Analysis

Systems analysis involves an in-depth and documented study of current

practices in information management. Based on this study, a proposal for a

revised or new system is developed. The process has three parts: gathering

data, analysing it, and developing from this analysis the system proposal,

which will be the starting point of the next major stage: system design.

72/MITSDE


In consultations with all levels of users, the analysts will seek to identify all

impor tant data entities and information flows, i.e., their origins and

destinations, and record and analyse the information obtained. In a business,

the users include managers from all functional areas at various levels. This

stage uses several sources of information, including the existing reports and

documents in the organisation, questionnaires, interviews and observations.

Questionnaires need to be designed carefully to avoid misinterpretation. An

accompanying letter can explain the purpose and give a return date. Note that

there are limits to the accuracy that respondents can provide, particularly

with numeric data such as hours per week spent on a particular task.

Interviews are often the most productive source of facts and the best way to

tap people’s views and experiences of the current systems and practices.

Observation comprises visits to key offices and operations to view their

processes, check previously recorded facts, and look for new (unrecorded)

facts and for bottlenecks. Good powers of observation are a valuable trait of

the good analyst.

The order in which the methods are listed may also be useful in applying

them. Initial study of appropriate documents can provide the analyst with a

good initial view of the current systems and assist in developing an effective

questionnaire. A well thought out questionnaire is likely to prompt users to

think about their information uses and needs, which can enhance a subsequent

interview.

Data collection is followed by data analysis. At this point, the systems analyst

is not looking for a solution so much as a clear understanding of the current

systems and any problems with them, and for opportunities for greater

effectiveness and efficiency in information management. There are well-

established tools to assist in a methodical systems analysis, such as data

flow charting, data entity modelling, and the function-organisation matrix.

They become important particularly in large and complex systems. This phase

may also encounter resistance from users, who may have legitimate fears

that are best addressed by open and frank discussions between managers,

analysts, and users on plans and prospects.

The system analysis finally leads to a systems proposal specifying a high

level of output (e.g., printed reports, on-screen charts), inputs (e.g., data

collection forms), and the main database tables and their relationships. It

also lists the major tasks of the project to implement the proposed system,

with their duration, and the resources needed. Outputs reflect the perceived

information needs of users. An MIS output only has merit if a management

decision might be made on the basis of an output. Difficulty in identifying any

such decision casts doubt on the value of the output.

A formal report with the analyst’s recommendations is presented to the

management. This report should be accompanied by an oral presentation

attended by all involved parties. Based on a review of the report and the

presentation, management makes a decision whether to continue to the system

design phase (i.e., the proposed system is feasible), revisit the systems analysis

phase to meet areas of concern, or terminate the project.

Management may look at operational, technical, and economic aspects of a

system proposal and at its development schedule:

73/MITSDE

Operational capability ensures that the system can perform its intended

functions within the existing organisational environment with its current (or

planned) personnel and procedures, i.e., that the system will be used once it

has been developed and implemented. If the end users resist a new system,

the system might not be exploited to its full potential. The operational aspect

is largely a human relations problem.

The technical area comprises hardware, software, and personnel to develop

(or purchase), install, and operate the system.

From the economic standpoint, the analyst has to determine and demonstrate

that the benefits to be derived from the system are worth the time, money,

and other resources required to implement it.

Finally, management has to be convinced that the proposed implementation

schedule is realistic and acceptable. The analyst may find Gantt charts and

the Program Evaluation and Review Technique (PERT) helpful to demonstrate

the tasks of a project and their sequence and relationships. If management is

convinced that the project is feasible and should continue, then the project is

taken to the next phase.

6.4.5 System Design

The system design step is intended to decide on detailed features and processes

of the proposed MIS within the framework of overall system identified during

the feasibility phase. In a way systems analysis involves the same tasks as in

feasibility stage, but the range of options considered is narrowed down to the

alternatives selected at the previous stage. Also the level of details and

thoroughness in studying the existing system and for designing and specifying

the proposed systems is much more. The estimates of cost and benefits

produced at this stage are more detailed and reliable. For example, the

feasibility study may talk of developing a system of developing sales persons

evaluation system base on their performance against targets in terms of sales

as well as contribution to profits and overheads. At the systems analysis stage

it will be necessary to give details like what constitutes sales, and how

contribution to profits against these sales are defined, how targets for these

are to be fixed and how the actual performance is to be measured.

The systems analysis stage will also include finalisation of greater details of

IT options to be used for different MIS tasks. For example, the feasibility

study for computerisation of a bank may say that all withdrawal and deposit

transactions by the customers will be computerised, their accounts statements

or passbooks will be printed on computer, and the related accounts of the

banks will also be computerised. The System design stage may then identify

and choose from several alternatives for printing of customer passbooks like,

a running passbook which can be updated after every transaction, a running

passbook updated periodically, and loose statements printed periodically.

Systems analysis will also specify the overall architecture of the computer

hardware, software, and the data structure. This will interest primarily the IT

specialist, but some aspects will also affect the user managers and other

employees. For example, availability of computer terminals for data entry,

transaction processing, and on-line information impacts them substantially.

Similarly they will be very much affected by the ease of and delays in accessing

information available in computer databases.

74/MITSDE


Systems analysis also needs to provide specifications of computer and

communication hardware required for the proposed MIS along with cost

estimates. Similarly time and cost estimates for software development and

other project activities are reviewed and revised as required. Also a time

schedule is prepared giving the break-up, sequence, and schedules for various

detailed design and implementation activities to follow. At times, the system

design may divide the whole MIS project into smaller subprojects to be

implemented in a phased manner.

The developers of MIS need to consult managers widely and need to agree on

their broad information needs for managing the business. This provides an

outline of what the system needs to include. Ideally the cost of management of

an organisation should be kept within acceptable limits. Management of the

MIS has its own cost, which adds to the above cost of management. This is a

further reason to constrain the system within reasonable limits. Having said

that, it is crucial to the value of the information system that sufficient skilled

resources be allocated to its development, implementation, and operation.

6.4.6 Detailed System Design

Detailed system design carries the process of MIS design further and firms

up detailed systems specifications for the proposed MIS, which becomes the

basis for detailed software development and other development activities to

be undertaken by IT professionals. The specifications cover details like report

layouts, computer terminal screen designs, input documents, and the logic

for processes to be used in the system for analysis of information, which need

to be approved by the users and affect their working. There are other details

that affect the efficiency and reliability of the computer processes. This includes

details like data dictionary specifications giving names, definition, format and

size of all data elements in the system. Systems flow charts describing the

subsystems and processes within the MIS are developed to facilitate easy

understanding of the total system and its internal relationships as well as

interface with the environment.

During the process of detailed system design, some of the minor features of

MIS finalised in the earlier stages may be changed in view of the fact that a

clearer picture of the issues involved is available. If the previous steps have

been handled well, a need for major changes should not arise at this stage.

Detailed system design will also provide more reliable data for time and cost

estimates. Therefore, the cost estimates should also be reviewed, revised if

required.

6.4.7 Implementation

Implementation covers the process of coding, testing, and documenting

programmes to capture, store, process and present information to managers

at all levels as envisaged in detailed system design. Also, computer and

communication hardware as required for the planned MIS are procured and

installed at this stage. The process of implementation takes up about two

thirds of the total development effort. Therefore it is necessary to plan,

monitor, and control the implementation activities in much greater detail than

the earlier stages.

75/MITSDE

A poorly tested system is a frequent cause of problems during and after

systems implementation. The system should not become fully operational

until it has been tested for errors. Although testing is tedious, it is essential

that it is carried out thoroughly. It is useful to develop a formal test plan,

which should include for each test: its purpose, definition of test inputs,

detailed specification of test procedure, and definition of outputs expected.

A system’s components are first tested individually, using previously

established test procedures and test data. Then the system is tested in its

entirety to ensure the components are compatible and function as intended.

Testing must include users: this will not only identify further errors but also

provide indispensable feedback on the users’ reaction to the system and the

degree to which they find it meets their requirements. Testers should include

users who are not expert in the system or its software—experts will avoid

user’s errors that more normal users will be prone to make. Testers will need

clear guidance on what they are expected to do. They also need a good medium

in which to record test results, an unhurried environment, and motivation to

test thoroughly.

Another important area of implementation is training of user managers and

other employees to operate and use the system effectively. There are different

training needs for different categories of users. It may be necessary to enlist

external expertise for some of this training. If the company has procured a

readymade system or used an external organisation to develop a local system,

then the source of the system or expertise is likely to be a useful provider of

initial training. It is very important that all those undergoing such training

are in a position to apply it immediately. It is quite different from learning to

ride a bicycle—skills learned in computer training are lost rapidly if not

employed. So the training has to be fitted into the whole MIS implementation

plan in such a way that hardware and software are already in place. If new

equipment is being procured, then it should be used for the training workshops;

trainees can take the new equipment with them back to their station, with

the MIS installed and operational, for immediate use.

Usually a new or revised MIS entails capturing a large volume of master data

into the system before the MIS can become fully operational. When the new

MIS needs to replace the existing ones, there are additional activities involved

for change over from the old to the new system. This task at times can be

quite tricky because a large number of employees in the company have to get

involved in the process, and usually, during the process of changeover they

need to put in extra efforts. Therefore the process of changeover needs to be

planned and executed carefully. We can choose from one of the following four

ways of changing over from an existing system to a new one:

• Parallel conversion

• Direct conversion

• Pilot conversion

• Phased conversion

76/MITSDE


Parallel Conversion

The old and new systems are run side by side for a fixed period of time.

Outputs from each system can be compared to check for errors in the new

system. The causes of errors can be investigated and revisions made in the

final design of the new system. The duration of parallel processing may have

to be extended if an excessive number of errors need to be corrected.

• Advantage: The old system is available to fall back on in case there are

serious difficulties with the new one.

• Disadvantage: The high cost, mainly in staff time, of operating two

systems simultaneously, and in the time and skills needed in running

the cross-system checking.

Direct Conversion

The old system is dismantled immediately after the new system has been put

into place. It might be the preferred choice if the old system has so many

weaknesses that a parallel conversion would serve no useful purpose or if the

new system is very small or simple and does not involve major risks.

• Advantage: It avoids the cost of running two systems simultaneously.

• Disadvantage: Should the new system fail, there is no system currently

operational.

Pilot Conversion

In pilot conversion method, the new system is installed initially in only part

of the organisation, such as one or a branch of a bank, where it can be

thoroughly tested in all its aspects before it is extended to other stations.


serious difficulties with the new one. It is less disruptive and there is

more time for training and for detecting and correcting errors, and it

imposes lower peak demands on users and the system operators.

• Disadvantage: The organisation is left working with different systems

in different parts of the organisation.

Phased Conversion

Throughout the organisation, only part of the new system is implemented

initially. When that part is proven to work efficiently and users are comfortable

with it, another part may be introduced, again for organisation-wide adoption.


serious difficulties with the new one. It is less disruptive and there is

more time for training and for detecting and correcting errors, and it

imposes lower peak demands on users and system operators.

• Disadvantage: The modules have to be able to be implemented and

operated independently and, later, collectively.

77/MITSDE

File Conversion

One important conversion activity is file conversion – that is, changing any

existing paper or electronic files into a form in which they can be used by the

new system. Both paper and electronic forms will often be structured very

differently from the new system. Paper files will need to be keyboarded into

electronic files. It may be worth using an intermediate electronic file that

matches the existing paper format to ease the chore of this keyboarding effort,

and which the systems staff can later process into the new system. Electronic

files from a prior system may be processed into the new system although the

batch process files that are needed for this are difficult and time consuming

to develop. Considerable manual intervention is usually required, especially if

the data is inconsistent and incomplete. Users may have to be asked to update

and correct their data, but as it is a time consuming task, they may need to be

persuaded of its necessity.

Testing

A poorly tested system is a frequent cause of problems during and after

systems implementation. The system should not become fully operational

until it has been tested for errors. Although testing is tedious, it is essential

that it is carried out thoroughly. It is useful to develop a formal test plan,

which should include for each test: its purpose, definition of test inputs,

detailed specification of test procedure, and definition of outputs expected.

A system’s components are first tested individually, using previously

established test procedures and test data. Then the system is tested in its

entirety to ensure the components are compatible and function as intended.

Testing must include users: this will not only identify further errors but also

provide indispensable feedback on the users’ reaction to the system and the

degree to which they find it meets their requirements. Testers should include

users who are not expert in the system or its software—experts will avoid

user’s errors that more normal users will be prone to make. Testers will need

clear guidance on what they are expected to do. They also need a good medium

in which to record test results, an unhurried environment, and motivation to

test thoroughly.

Quality Assurance

Among other things implementation involves, developing procedures designed

to ensure quality of the MIS as a whole in terms of issues like:

• Data security, backup and recovery

• Systems control

• Testing of programme to ensure their ability to be bug free under all

expected business situations

• Ability of hardware and software to deliver the expected processing

capacity and maintain reasonable response times

Attention must be given to usability, stability, documentation and

maintainability of the software system’s quality. Usability should derive from

early and continued user testing and comments from users. Stability,

maintainability will be encouraged if a relational database software is used by

addressing relational principles.

78/MITSDE


Documentation

The MIS project cannot be considered to be complete until all the important

details of the system including hardware, software, computer operational

procedures, and user inter face procedures have been documented.

Documentation is the material that explains what the information system

does and how people interact with it. All documentation must be clearly

identified and dated. Documents must be readily understandable and should

not refer to other documents as far as possible. While a number of documents

were prepared as part of the systems analysis and design processes described

earlier, here we look at those to be released as soon as the system is developed.

The documentation should comprise the following:

• A user guide, which enables an inexperienced user to learn how to use

the system for the major functions for which it is designed

• A user reference or operations manual, which provides more detailed

information for advanced users, including the routine management of

the system

• A systems reference manual, which provides a record of the system

structure and design in sufficient detail in order to enable new staff to

continue the maintenance of the system and make future enhancements

in case the original system developer(s) depart

The first two may be combined in a single document. Increasingly such

assistance is provided by built-in, on-line help facilities within the system

software. The systems reference manual includes a data dictionary, which

lists and defines all tables and their fields.

6.4.8 Maintenance

The MIS system developed, needs to be maintained throughout its working

life to solve any problems faced in operation and to make minor modifications

to the system in response to additional requirements developing after initial

development and implementation is over. Effective design, development, and

implementation of MIS systems can substantially reduce the need for

maintenance efforts. But no amount of planning and design efforts can totally

eliminate the need for maintenance. Good documentation is the only other

way to reduce the maintenance effort required.

It is better to actively seek the area of improvement possible in the MIS and

wherever possible make necessary modifications to improve its utility.

However, not all desired modifications may be that easy or economical to

implement. Even when it is not possible to modify the system to address a

problem or opportunity identified, a record of these should be kept. Sooner

or later a stage may arise when it may become advisable to undertake a major

upgrade of the system. At these stages such records of unattended problems

and opportunities will be a great help in analysis and design of a revised MIS.

6.5 Systems Analysis and Design

We have seen different stages of SDLC use, the Systems Analysis and Design

techniques. These techniques are used even when methods other than SDLC

are used for the MIS project. While information system developers need to be

79/MITSDE

skilled in use systems analysis and design, an overview of these techniques

enables the user managers also to participate more effectively in the MIS

development process.

James A. Senn, in his book “Analysis and Design of Information Systems”

describes systems analysis and design as the process of examining a business

situation with the intent of improving it through better procedures and methods.

It comprises of processes through which the existing practice of information

management is studied. The results are used to redefine the needs for information,

which form the basis for the design of a new system to meet these needs.

Systems development can be generally thought of as having two major

components: systems analysis and systems design. System design is the

process of planning a new business system or one to replace or complement

an existing system. System analysis is the process of gathering and interpreting

facts, diagnosing problems, and using the information to recommend

improvements to the system. This is the job of the systems analyst.

Systems analysts do more than solve current problems. They assess what the

future needs of business will be and what changes should be considered to meet

these needs. Analysts may recommend alternatives for improving a situation.

Working with managers and employees in the organisation, a systems analyst

recommends which alternative to adopt, based on such considerations as the

suitability of the solution to the particular organisation and setting, as well as

employee support the solution is likely to have. Sometimes the time required

to develop an alternative is the most critical issue. Costs and benefits are also

important determinants. In the end management, which will pay for and use

the system, will decide which alternative to accept.

Once this decision is made, a plan is developed to implement the

recommendations. The plan includes all system design features such as new

data capture needs, file specifications, operating procedures, and equipment

and personnel needs. The system design is like the blueprint for a building: it

specifies all the features that are to be in a finished product.

System design will specify ways to capture and store data. It will also designate

work to be performed by people and computers.

Each design describes output to be produced by the system. The systems

analyst decides which output to use, and how to produce.

Analysis specifies what the system should do. Design states how to accomplish

the objective.

Information system consists of subsystems, including hardware, software and

data storage for files and databases. The particular set of subsystems used –

the specific equipment, programmes, files and procedures – constitute an

information system application. Thus the information system can have

purchasing, accounting, or sales application.

Since information systems support other organisation systems, analysts must

first study the organisation system as a whole and then its information systems

details.

80/MITSDE


6.6 Requirements Determination and Structuring

Requirements determination and requirements structuring are two core

components of system analysis. Traditionally, interviewing, questionnaires,

directly observing and analysing documents are four main methods adopted

by system analysts to collect information. JAD and prototyping are two modern

requirements of determination methodologies, which are developed and based

on the previous traditional methods. A well-structured representation of

system requirements can dramatically improve the communication among

analysts, designers, users, and programmers. DFD, structured English,

decision tables, decision trees, and E-R diagrams are traditional primary

requirements structuring tools. Now a days, RAD and OOA are emerging to

help streamline and shorten the total SDLC. While RAD packs traditional

analysis phase and part of design phase into one step, OOA tries to make the

outcomes of analysis phase reusable by the following developing phases, which

can dramatically shorten the total SDLC.

Detailed system analysis involves a substantial amount of effort and cost and

is therefore undertaken only after the management has decided that the

systems development project under consideration has merit and should be

pursued through this phase. Most observers would agree that many of the

errors in a developed system are directly traceable to inadequate efforts in

the analysis and design phases of the life cycle. However, for many reasons, it

is difficult to obtain a correct and complete set of requirements.

As analysis can be divided into three main activities: Requirement

determination, Requirement Structuring, and Alternative generation and

selection. The third one is usually regarded as the automatic result from the

first two processes.

Requirements determination is the beginning sub phase of analysis. In this

sub phase, analysts should gather information on what the system should do

from as many sources as possible. There are some traditional methods to

help collecting system requirements, such as interviewing, survey, directly

observing users, etc. Now a days, some modern requirement collecting

methods, such as JAD and prototyping, have emerged.

Requirements structuring is the process to use some kind of systematic and

standard, well-structured method to model the real world. Traditionally, we

use the data flow diagram for process modelling, decision table or decision

tree for logic modelling, and Entity-relationship diagram for data modelling.

These modelling tools usually separately model only one face of the real world.

So, when we try to show the integral picture of a system, we usually choose

more than one of the above requirements structuring methods.

Rapid Application Development (RAD) is an approach that promises better

and cheaper systems and more rapid deployment by having system developers

and end users work tighter jointly in real-time to develop systems. RAD is not

a single methodology but is more a general strategy of developing information

systems. It brings several system development components together.

Object-oriented analysis and development is a brand new methodology.

Although OOP has become popular in the computer world, whether OOA is

superior to traditional methods is still a question mark. However, from the

81/MITSDE

view of OO world, OOA seems having an important role to play in the future.

In this section, we will discuss some widely adopted basic requirements

determination and requirements structuring methods, compare and contrast

those methods and try to find a best way for system requirements analysis.

6.6.1 Requirements Determination

Collection of information is at the core of systems analysis. Information

requirement determination (IRD) is frequently and convincingly presented as

the most critical phase of information system (IS) development, and many IS

failures have been attributed to incomplete and inaccurate information

requirements. System analysts must collect the information about the current

system and how users would like to improve their performance with new

information systems. Accurately understanding users requirements will help

the system developing team deliver a proper system to the end users in limited

time and limited budget. If the user just wants an ant, definitely, an elephant

is improper. There are many methods to collect information. We will discuss

some basic and widely adopted ones of them.

Interviewing

Interviewing is one of the primary ways to gather information about an

information system. A good system analyst must be good at interviewing and

no project can be conducted without interviewing. There are many ways to

arrange an effective interview and no one is superior to others. However,

experienced analysts commonly accept some of the following best practices

for an effective interview:

• Prepare the interview carefully, including appointment, priming question,

checklist, agenda, and questions.

• Listen carefully and take note during the interview (tape record if

possible)

• Review notes within 48 hours after interview

• Be neutral

• Seek diverse views

Questionnaires

Questionnaires have the advantage of gathering information from many people

in a relatively short time and of being less biased in the interpretation of their

results. Choosing the right questionnaire respondents and designing effective

questionnaires are the critical issues in this information collection method.

People usually only use a part of the functions of a system, so they are always

just familiar with a part of the system functions or processes. In most

situations, one copy of questionnaires obviously cannot fit all the users. To

conduct an effective survey, the analyst should group the users properly and

design different questionnaires for different groups. Moreover, the ability to

build good questionnaires is a skill that improves with practice and experience.

When designing questionnaires, the analyst should concern the following

issues at least:

• The ambiguity of questions.

• Consistence of respondents’ answers.

• What kind of questions should be applied, open-ended or close-ended?

• What is the proper length of the questionnaires?

82/MITSDE


Observation

The third one is directly observing users. People are not always very reliable

informants, even when they try to be reliable and tell what they think is the

truth. People often do not have a completely accurate appreciation of what they

do or how they do it. This is especially true concerning infrequent events, issues

from the past, or issues for which people have considerable passion. Since

people cannot always be trusted to reliably interpret and report their own actions,

analysts can supplement and corroborate what people say by watching what

they do or by obtaining relatively objective measures of how people behave in a

work situation. However, observation can cause people to change their normal

operation behaviour. It will make the gathered information biased.

Analysing Procedures and Documents

The fourth one is analysing procedures and documents. By examining the

existing system and organisational documentation, the systems analyst can

find out details about the current system and the organisation these systems

support. In documents, analysts can find information such as problems with

existing systems, opportunities to meet new needs if only certain information

or information processing were available, organisational direction that can

influence the information system requirements, and the reason why current

systems are designed as they are.

However, when analysing those official documentations, analysts should pay

attention to the difference between the systems described on the official

documentations and the practical systems in the real world. For the reason of

inadequacies of formal procedures, individual work habits and preferences,

resistance to control, and other factors, the difference between the so called

formal system and informal system universally exists.

Joint Application Design (JAD)

The fifth one is Joint Application Design (JAD). It is a facilitated, team-based

approach for defining the requirements for new or modified information

systems. JAD was developed at IBM in the late 1970s. The main idea behind

JAD is to bring together the key users, managers, and systems analysts

involved in the analysis of a current system. The primary purpose of using

JAD in the analysis phase is to collect systems requirements simultaneously

from the key people involved with the system. The result is an intense and

structured, but highly effective, process. Having all the key people together

in one place at one time allows analysts to see where there are areas of

agreement and where there are conflicts.

The typical participants in a JAD are: JAD session leader, end users, business

managers, sponsor, system analysts, IS staff, and scribe. The JAD team is a

group of from six to sixteen individuals who all have a stake in designing a

high quality system. Approximately two thirds of the group members are

functional experts, the other one third are systems professionals. JAD sessions

are usually conducted in a location other than the place where the people

involved normally work, and are usually held in special purpose rooms where

participants sit around horseshoe-shaped tables. Involving so many different

kinds of people in one workshop makes effectively and efficiently organising

the JAD session a big challenge.

83/MITSDE

When a JAD is completed, the final result is a set of documents that detail the

workings of the current system related to the study of a replacement system.

These requirements definition document generally includes business activity

model and definitions, data model and definition, data input and output

requirements. It may also include interface requirements, screen and report

layouts, ad hoc query specifications, menus, and security requirements. When

used at a later point in the system development life cycle, a JAD session can

also be used to refine a system prototype, develop new job profiles for system

users, or develop an implementation plan.

However, to exploit the full potential of the JAD, the groupware tools should

be applied in JAD workshop sessions. The use of groupware tools to support

the joint Application Development technique increases the value of this

technique dramatically. When groupware tools are used in an automated JAD

workshop, they greatly facilitate the generation, analysis, and documentation

of information. This is particularly valuable for JAD workshops conducted to

define and build consensus on the requirements for new systems.

Prototyping

The Sixth one is Prototyping. Prototyping is a means of exploring ideas before

you invest in them. Prototyping is the process of building a model of a system.

In terms of an information system, prototypes are employed to help system

designers build an information system that is intuitive and easy to manipulate

for end users. Most system developers believe that the benefits from early

usability data are at least ten times greater than those from late usability

data. Prototyping allows systems analysts quickly show users the basic

requirements for a working version of the desired information system.

This method recognises the difficulty of prescribing in detail a system’s

requirements on paper prior to its construction, and the value of enabling

users to develop their statement of needs dynamically through repeatedly

commenting on an evolving prototype. Prototyping thus integrates systems

analysis, design, and implementation. Prototyping is particularly useful for

systems where requirements are difficult to specify (e.g., decision support

systems) or for solutions for designing the human interface, such as the

screens for data entry, selection menus, and reports. A valuable aspect of

prototyping is that it encourages users to become interested in the

development of a system. This greatly reduces the risk of implementing a

system that is based on incorrect analysis of users’ real needs, and it avoids

the associated cost of major redevelopment. Prototyping is more useful for

small systems; large ones therefore need to be broken down into small

components. However, it remains important to undertake at least a basic

systems analysis prior to starting. Care should be taken to fully finish the

system and write the documentation.

After viewing and testing the prototype, the users usually adjust existing

requirements to new ones. The goal with using prototyping to support

requirement determination is to develop concrete specifications for the ultimate

system, not to build the ultimate system from prototyping. Prototyping is most

useful for requirements determination when user requirements are not clear or

well understood. One or a few users and other stakeholders are involved with

the system, possible designs are complex and require concrete form to fully

84/MITSDE


evaluate. Communication problems have existed in the past between users and

analysts, and tools and data are readily available to rapidly build working systems.

Prototyping comes in many forms - from low tech sketches or paper screens

(Pictive) from which users and developers can paste controls and objects, to

high tech operational systems using CASE (computer-aided software

engineering) or fourth generation languages and everywhere in between. Many

organisations use multiple prototyping tools. For example, some will use paper

in the initial analysis to facilitate concrete user feedback and then later develop

an operational prototype using fourth generation languages, such as Visual

Basic, during the design stage.

When adopting prototyping, analysts should be concerned about the potential

problems about the requirements determination method, such as informal

documentation, ignored subtle but important requirements.

Advantages of Prototyping:

• Reduces development time

• Reduces development costs

• Requires user involvement

• Developers receive quantifiable user feedback

• Facilitates system implementation since users know what to expect

• Results in higher user satisfaction

• Exposes developers to potential future system enhancements.

Disadvantages of Prototyping

• Can lead to insufficient analysis.

• Users expect the performance of the ultimate system to be the same as

the prototype.

• Developers can become too attached to their prototypes.

• Can cause systems to be left unfinished and/or implemented before

they are ready.

• Sometimes leads to incomplete documentation.

• If sophisticated software prototypes (4th GL or CASE Tools) are

employed, the time saving benefit of prototyping can be lost.

• Prototyping is not necessary if the developer is already familiar with

the language ultimately used for system design.

Instead of software prototyping, several information systems consultants and

researchers recommend using “low tech” prototyping tools (also known as

paper prototypes or Pictive), especially for initial systems analysis and design.

The paper approach allows both designers and users to literally cut and paste

the system interface. Object command and controls can be easily and quickly

moved to suit user needs.

Among its many benefits, this approach lowers the cost and time involved in

prototyping, allows for more iterations, and gives developers the chance to

get immediate user feedback on refinements to the design. It effectively

eliminates many of the disadvantages of prototyping since paper prototypes

are inexpensive to create, developers are less likely to become attached to

their work, users do not develop performance expectations, and best of all,

paper prototypes are usually “bug-free” unlike most software prototypes.

85/MITSDE

6.6.2 Choosing the Right Method

When we choose the requirements determination method for a specific project,

there are seven characteristics we should consider. They are Information

Richness, Time Required, Expense, Chance for Follow-up and Probing,

Confidentiality, Involvement of Subject, Potential Audience. Table 6.1 concludes

these characters of previously discussed six requirements determination

methods.

Comparison of Requirement Determination Methods

Characte- Interviews Questionn- Observa- Document JAD Proto-ristics aires tion analysis typing

Information High Medium to High Low(passive) High Medium

Richness low and old to High

Time Can be Low to Can be Low to Dedicated Moderate

Required extensive moderate extensive moderate period of and can

time of be

all kinds extensive

of involved

people

Expense Can be Moderate Can be Low to High High

high high moderate

Chance for Good Limited Good Limited Good Good

Follow-up

and probing

Confi- Interviewee Respondent Observee Depends on All the Usually

dentiality is known to can be is known to nature of people know

interviewer unknown interviewer document know each each

other other

Involve- Interviewee Respondent Interviewees None, no All kinds Users

ment of is involved is passive, involved and clear of people are

Subject and no clear committed commitment are involved

committed commitment depending involved and

on their and commit-

awareness committed ted

of being

observed

Potential Limited Can be Limited Potentially Potentially Limited

Audience numbers, quite large, numbers biased by biased by numbers;

but but lack of and documents the people’s it is

complete response limited selection and reluctance difficult

responses from some time of original to be frank to involve

from those can bias each purpose of on sensitive all

interviewed results documents issues potential

users

Table 6.1 Comparison of requirement determination methods

6.7 Requirements Structuring

In the last section, we discussed about the methods to determine information

system requirements. In this section, we will focus on the widely adopted

methods used to present the requirements. Traditionally, there are three basic

methods for requirements structuring:

• Data flow diagrams: These are widely used for process modelling

• Logic modelling using structural English, decision tables, and decision

trees

• Data modelling using entity and relationship diagrams

86/MITSDE


6.7.1 Data Flow Diagram (DFD)

First, a data flow diagram (DFD) is a graphical tool that allows analysts (and

users) to depict the flow of data in an information system. DFD graphically

represents the functions, or processes, which capture, manipulate, store and

distribute data between a system and its environment and between components

within a system. The final deliverables and outcomes for DFD are:

• Context data flow diagram, which defines the boundary of the system

• DFDs of the current physical system, which is used to determine how

to convert the current system into its replacement

• DFDs of current logical systems

• DFDs of new logical systems

• Thorough descriptions of each DFD component

In a DFD, there are only four symbols that represent the same things: data

flows, data stores, processes, and source/sinks (or external entities). A data

flow can be best understood as data in motion, moving from one place in a

system to another. A data store is data as rest, which may take the form of

many different physical representations. A process is the work or actions

performed on data so that they are transformed, stored, or distributed. Source/

sink is the origin or destination of data, sometimes referred to as external

entities.

Data flow diagrams should be mechanically correct, but they should also

accurately reflect the information system being modelled. To that end, analysts

should check DFDs for completeness and consistency and draw them as if

the system being modelled were timeless. Complete sets of DFDs should

extend to the primitive level where every component reflects certain irreducible

properties. Following the above guidelines, DFDs can aid the analysis process

by analysing the gaps between existing procedures and desired procedures

and between current and new systems.

6.7.2 Logic Modelling

Secondly, logic modelling involves representing the internal structure and

functionality of the processes represented on data flow diagrams. In the

analysis phase, logic modelling will be complete and reasonably detailed, but

it will also be generic in that it will not reflect the structure or syntax of a

particular programming language. There are three traditional tools for logic

modelling: structure English, decision tables and decision trees. Structured

English is a modified form of the English language used to specify the logic

of information system processes. Although there is no single standard,

structured English typically relies on action verbs and noun phrases and

contains no adjectives or adverbs. The decision table is a matrix representation

of the logic of a decision, which specifies the possible conditions for decisions

and the resulting actions. Usually, there are three parts in a decision table:

the condition stubs, the action stubs, and the rules. A decision tree is a

graphical technique that depicts a decision or choice situation as a connected

series of nodes and branches. Decision trees have two main components:

decision points and actions. Nodes represent decision points, while actions

are represented by branches. The comparison among these three is shown in

following table 6.2.

87/MITSDE

Comparison of Requirement Presentation Methods

Criteria Structured English Decision Table Decision Tree

Determining Second Best Third Best Bestconditions &actions

Transforming Best Third Best Bestconditions &actions intosequence

Checking Third Best Best Bestconsistency &completeness

Table 6.2 Comparison of requirement presentation methods

The comparison of decision table and decision trees is shown in table 6.3.

Comparison of Decision Table and Decision Trees

Criteria Decision Tables Decision Trees

Portraying complex logic Best Worst

Portraying simple problems Worst Best

Making decisions Worst Best

More compact Best Worst

Easier to manipulate Best Worst

Table 6.3 Comparison of decision table and decision trees

6.7.3 Data Modelling

Thirdly, data modelling develops the definition, structure, and relationships

within the data. Many analysts believe that a data model is the most important

part of the statement of information system requirements. This belief is based

on the following reasons:

• The characteristics of data captured during data modelling are crucial in

the design of databases, programmes, computer screens, and print reports.

• Data rather than processes are the most complex aspects of many

modern information systems and hence require a central role in

structuring system requirements.

• The characteristics about data (such as length, format, and relationship

with other data) are reasonably permanent.

The most common format used for data modelling is entity-relationship (E-

R) diagramming. The E-R data model is a detailed, logical representation of

the data for an organisation or for a business area. There are three main

constructs in the E-R diagram: data entities, relationships, and their associated

attributes. An entity is a person, place, object event, or concept in the user

environment about which the organisation wishes to maintain data. Each

entity type has a set of attributes associated with it. An attribute is a property

or characteristic of an entity that is of interest to the organisation. Relationships

are the glue that hold together the various components of an E-R model. A

relationship is an association between the instances of one or more entity

types that is of interest to the organisation.

88/MITSDE


6.8 Advanced System Analysis

Now a days, there are other two very widely adopted methods for system

analysis. They are Rapid Application Development (RAD) and Object-oriented

analysis. These two are always labelled as advanced system analysis or modern

system analysis. The popularity of these two methods owes to the high

pressure of today’s quickly changed business environment. The present end-

users cannot wait for two to three years to have a system. So, streamlining

the SDLC and shortening the total SDLC play a critical role in system

development. To achieve this goal, RAD tries to compact several phases into

one single step while OOA try to make the analysis phase seamlessly pass to

the OO design phase.

6.8.1 Rapid Application Development (RAD)

RAD is an approach to developing information systems that promises better

and cheaper systems and more rapid deployment by having systems developers

and end users work together jointly in real time to develop. RAD grew out of

the convergence of two trends:

• The increased speed and turbulence of doing business. As global

competition increases, processes for detecting and satisfying customers

must be redesigned and continuously improved. To do this, information

technology should be merged into business-process design as early as

possible.

• Ready availability of high-powered computer-based tools to support

systems development and easy maintenance.

Compared with seven phases, standard SDLC, RAD SDLC has only four

phases. They are - planning, design, development, and cutover. RAD pushes

analysis and part of design jobs of standard SDLC into one design step.

Actually, RAD is not a single methodology but is instead a general strategy of

developing information systems, which takes into account human factors and

corporate culture as well as technology. To succeed, RAD relies on bringing

together several system development components, such as JAD, prototyping,

and all kinds of traditional requirements structuring methods. It is impossible

to do so without using the high-powered computer-based tools such as visual

tools and integrated CASE tools, which include code generators for creating

code from the design end users and analysts create during prototyping. There

are four necessary pillars for the RAD approach: tools, people, methodology,

and management.

Advantages of RAD:

· Time saving, money saving, human effort saving

· Tighter fit between user requirements and system specifications

· Best fit for quickly changed business environment

· Concentrates on essential system elements from user viewpoint.

Disadvantages of RAD:

· High costs of commitment on the part of key user personnel

· Easy to ignore some issues, such as missing information on underlying

business processes, inconsistent internal designs with and across

systems, lack of scalability, lack of attention to later systems

administration built into the system, etc.

89/MITSDE

In one sentence, RAD heavily depends on JAD and Prototyping, so it inherits

the advantages of these two approaches while it has to tolerate the

disadvantages of the two. Last but not the least, the RAD approach is not

appropriate to all projects. Project scope, size and circumstances all determine

the success of a RAD approach.

6.8.2 Object Oriented Analysis (OOA)

Object oriented system analysis abstracts concepts from the application

domain and describes what the intended system must do, rather than how it

will be done. Instead of using functional decomposition of the system, the

OOA approach focuses on identifying objects and their activities. Using the

Object oriented approach, system analysts model information systems by

identifying a set of objects, along with their attributes and operations that

manipulate the object data. Objects are grouped into classes that have

common properties. Classes are organised into hierarchies, in which the

subclasses inherit the properties, including the data definitions and operations.

The model specifies the functional behaviour of the system, independent of

concerns relating to the environment in which it is to be finally implemented.

The OO analysts need to devote sufficient time to clearly understand the

requirements of the problem and the analysis model should capture those

requirements completely and accurately. The core of OO is reusability. The

whole OO system is built on inheritance, so a subtle misunderstanding of the

basic requirements of the problem may cause the whole system to seem

ridiculous. OOA is inspired by the now a days very popular object-orient

programming (OOP). The traditional system analysis methods cannot adapt

to OOP to make the whole development process smoother and seamless, so

OOA comes up and tries to solve such problems. The outcomes of OOA usually

are considered reusable for the further OO system development phase, such

as OOD and OOP, and these reusability characters can dramatically shorten

the total SDLC.

OOA has it own whole set of modelling tools to represent the system

requirements. They are:

• Use-case diagram helps to generate a requirements analysis model,

which captures the functionalities of the system as seen by external

actors

• Class diagram helps to analyse the objects in the problem domain and

describe their static structure

• State diagram shows how the object transitions from one state to other

states

• Sequence diagram shows the explicit sequencing of messages

The commonly admitted points about OOA advantages in the OO world are:

• An easier modelling process and the ability to tackle more challenging

problem domains

• Improved communication among users, analysis, designers, and

programmers

• Increased consistency among analysis, design, and programming

activities

• Improved quality of system

• Reusability of analysis, design, and programming results

90/MITSDE


So far, although more and more system analysts adopt OOA, whether it is

superior to traditional system analysis is still in hot argument. Although in

the OO world, the above advantage points about OOA are commonly accepted,

there are still a large number of software communities which don’t agree

with them. People may more naturally think in a procedural way than in an

object way. Moreover, it is commonly accepted in the Object-oriented research

field that the methodology of OOA is far from mature and the identification of

object classes remains an art because it is highly dependent on the problem

domain.

Conclusion: There is no official best way of systems analysis, the methods

applied to a project depend on the project context, such as the analyst’s

expertise, user’s favourites, project’s size and complexity. So, a good systems

analyst should be able to use any of these methods on the fly according to the

specific project context.

Although the new system analysis methods come out one by one, the

traditional ways for requirements determination, like inter viewing,

questionnaires, directly observing, and analysing documents can never be

simply replaced. Furthermore, neither in modern requirements determination

methods, such as JAD and prototyping, nor in the now a days advanced system

analysis, such as RAD and OOA, those four types of information collecting

approaches are always the cornerstones, which can never be touched.

As a result of the high changing pace of the business environment, RAD

shows itself dramatically shortening the SDLC. However, from the view of a

system requirements analysis, RAD intensively combines all kinds of system

analysis methodologies into a one-step process by using the now a days high-

powered computer technology. RAD heavily adopts JAD and prototyping as

the two primary ways to gather the requirements, so the merits and drawbacks

of these two methods also can be found in RAD.

OOA may be the real revolution in the system analysis field. However, such a

revolution just happened at the requirements structuring level. It does not

touch the basic requirements determination method, although better

requirements representation can help the requirements determination process

to be more efficient and effective. In order to adapt to the OOP, a whole set of

OOA requirements structuring tools, such as use-case diagram, class diagram,

etc., were developed, which are thoroughly dif ferent to the traditional

requirements structuring tools, such as DFD, structured English, etc. So far,

whether the OOA is better than the traditional analysis methods or not is

still a question mark. However, traditional requirements analysis techniques

were inspired by, and founded on, structured programming concepts. Now a

days, in a programming world that is increasingly turning to object orientation,

such traditional techniques seemed out of date and had to be replaced.

6.9 Managing the MIS Development Project

Traditionally, a project is required to (1) be completed within time, (2) be

completed within budget, and (3) deliver the right product. To an extent these

are conflicting or competing demands, and part of the task of a project manager

in-charge of developing MIS is maintaining a reasonable balance between them.

There is a range of project management software on the market. The simplest

91/MITSDE

programmes enable the manager to list the project’s several components and

track them through estimates of their start dates and duration as well as

monitor their individual progress to completion. Typically this is done through

Gantt charts and the Programme Evaluation and Review Technique (PERT).

Project components can usually be entered in a hierarchy, such as project,

tasks, and activities. For very large and complex projects, such software

support tools are a valuable management aid. They are less useful for small

projects as they incur a considerable overhead in time initially in learning

how to use them and subsequently in entering data and generating and using

the reports.

A person familiar with database software could construct a basic project

management system that records all tasks and activities, their start date and

estimated duration, and their completion. Such a system may lack the Gantt

and PERT charts of the purchased product but can still ser ve project

management well. An additional module can record the “bugs” and user

comments that start emerging on the release of the first prototype. Such a

project tracking database system would record for each problem or bug an

estimate of the time needed to resolve it and the percentage resolved to date.

This enables the system to report at any time, the outstanding resources still

required to completion. The outstanding resources needed and the number of

items provide a useful indicator of progress: both should show a steady decline

if the project is moving forward satisfactorily to conclusion. The flow of user

comments and reports of system faults will initially increase if this process is

going well, but then in time also decline as the system moves closer to users’

needs and a fault-free state.

6.9.1 Who Develops the MIS ?

While the overall responsibility for developing and operating MIS rests with

the top management of the company, several alternatives may need to be

considered for supplementing the resources available within the company.

Particularly, the MIS development and design process calls for professional

expertise and skills in IT and system analysis. Also, new MIS development

presents the company an opportunity to also review and upgrade its business

processes. Again, for this kind of business process reengineering it is

worthwhile for many companies to seek the best available expertise in

business management, which may not be available in the companies. Thus, a

company which embarks on MIS development project has several alternatives

to choose from. These are:

1. Use in-house resources for all MIS design, development and

implementation activities.

2. Use in-house resources for all MIS design, development and

implementation activities except software development.

3. Use in-house resources to develop the overall framework of the MIS

design including the user specifications. This will roughly correspond

to SDLC activities up to systems analysis and design being done in-

house and the detailed system design and implementation being

outsourced.

4. Use in-house resources to do the feasibility study and on that basis

outsource rest of the activities.

92/MITSDE


5. Appoint a management consultant to do the feasibility study, and with

his consulting support, outsource all the other activities.

6. Outsource the total MIS with minimum in-house work, just enough to

guide the terms of business with the party responsible for total MIS

project.

7. Some combination of the first six alternatives described above.

Irrespective of the option selected, there is always a need to involve the users

and other employees in various development activities as we have discussed

in the sections relating to MIS development and management. Also, any of

the MIS development activities require exper tise in IT and systems

methodologies, which, if not available in-house, must be outsourced. To some

extent, line managers can learn some of the expertise with short training and

by working on the MIS development project, and then become valuable

resources for the project. However a total reliance on line managers, in today’s

world of advanced IT and complex business processes, is not likely to produce

acceptable results.

With these general remarks, we will discuss the issues involved in choosing

from the alternatives listed above. In almost all cases the first alternative is

not preferred by any company. While smaller companies lack the necessary

information systems expertise, the larger companies generally prefer to

outsource the detailed systems development work to avoid hiring too many

people, which may not be needed after the MIS project is over. This alternative,

if used at all, is limited to small modifications to existing MIS in companies

having some permanent IT staff.

The second and third alternatives are feasible mostly for bigger companies

having an in-house IT department. The limiting factor here will be the availability

of adequate staff with the necessary IT skills. Also, companies will need to

examine the availability of necessary business management expertise in case

the MIS project involves some business process reengineering.

The fourth alternative is most suitable in a situation where the company has

experienced managers or internal experts that understand well the business

processes as well as opportunities offered by IT. These internal experts will

need to be senior managers with a good grasp of all functions of management,

and must enjoy top management credibility. This alternative may be used by

all sizes of companies that are fortunate to have the kind of personnel described

above. Companies that have a strong IT department in addition to such

personnel, may decide to undertake some additional development activities

in-house, depending upon the resources available.

The fifth alternative is clearly for companies with neither business process

reengineering or IT resources to spare. The sixth alternative is a high risk

alternative and, unless there are some compelling reasons to make an

exception, must be avoided.

Installation of hardware is almost always done by the vendor, who may also

supply some supporting software. These vendors also provide some training

in operation and maintenance of the hardware and software supplied by them.

Wherever available, such resources should be used.

93/MITSDE

In general a company may use one of the following three approaches for

constitution of the MIS project teams:

• Internal, team-based experts

• Internal IT department

• Outsourcing to external consultants

Internal, Team-Based Experts

Advantages

• Often the internal team based experts are highly motivated and

committed to the company.

• Team members have expertise in both, IT and the business. Also, they

understand the company operations and problems best.

• Easiest to integrate with users and managers they’ll need to interact

with.

• Internal teams dominated by line managers are prone to use off-the-

shelf, easier-to-use software than IT professionals and hence likely to

get systems up and running more quickly.

• Most economical over the long term if their skills are fully utilised.

Disadvantages

• Employees with required skills and knowledge may be difficult to find

and keep.

• May not have the specialised skills needed for every project.

• Excludes the internal IT department, which

(a) Knows best the IT infrastructure;

(b) Is responsible for maintaining corporate IT standards and

(c) May one day be asked to maintain an

Internal IT Department

Advantages

• Product is likely to be compatible with other IT systems in the

organisation.

Disadvantages

• Many systems professionals do not understand the specific needs of

users and have little or no knowledge of users’ work.

• Some users have sufficient IT competence to recognise when they are

being inadequately served, which results in dissatisfaction with the IT

department and a preference to develop their own systems.

• Tends to subordinate users desires to their own views.

Outsourcing to External Consultants

Advantages

• It is more cost-effective than own IT department for small businesses.

• Can take advantage of specialised skills which are inefficient to maintain

in-house.

94/MITSDE


• Larger organisations find this preferable when there is a lack of time or

particular skills in the IT department.

• Can offer a combination of range of expertise and experience not available

in the IT department. Many focus on particular industries and have worked

on many sites in that industry (though not often in agricultural research).

• An outsider can introduce more easily unpopular changes deriving from

system development.

• IT department believed to be too technocratic for user-empowered

systems.

Disadvantages

• Unless carefully managed, runs the risk of large expenditure without a

functional system at the end.

• Possible communication problems.

• Might be less committed to solving problems.

• May not understand your business as well as permanent employees.

• Could be more expensive if you need them more than you originally

estimated.

6.9.2 People Side of MIS Development

People are very important components of any MIS. They are also the most

important factor in the MIS development process. The people that need to be

managed during the MIS development project include:

• Top management

• Middle and lower management

• Employees other than managers who will be involved in operation of MIS

• Other stakeholders impacted by the proposed MIS

Involvement of the top management is essential for the success of any major

or even medium sized MIS project. Change in MIS of a company usually

involves some changes in basic business processes. Unless top management

approval is available, it is difficult to agree on and introduce such changes.

Top management support is also required to ensure that the best of managerial

resources in the company are available for the MIS project. An effective design

of MIS is possible only with active involvement of capable senior managers of

the company who understand the business well and have the capability and

willingness to understand and adopt new innovative practices. Unless the top

management backs the MIS project, such inputs from the user managers will

not be forthcoming. Top management approval and close involvement is

absolutely essential when the MIS project aims at business transformation.

Of course, top management are also likely to be users of the new MIS, and

therefore, must accept the final results of the MIS project.

Middle and lower management are the main users of the MIS. They also have

to make a major contribution in identifying and clarifying the user

requirements. Identification of user requirements has always been a tricky

area and frequently the cause of many a dispute between MIS users and

developers from the IT function. In view of the critical importance of this

aspect of MIS project management, we have discussed it in detail in the section

titled “Managing User Expectations”.

95/MITSDE

Middle management also provide the human resources required involved in

the routine operation of an MIS, as well as during the implementation phase

for activities such as master file creation and parallel operation. At times,

employees at lower levels may need to learn new skills and their job profiles

may change significantly. Middle managers are usually the group which is in

a position to reorganise the workforce as required, and to arrange resources

for extra work involved in the development and implementation process. These

managers also play an important role in ensuring acceptance of proposed

MIS by the employees and other stakeholders

Managers are the main source of data for the system, and the MIS needs data

from every manager each year. These requirements will not be met unless

the managers are, and feel, part of the system and are allowed to benefit from

it. The system needs to be demonstrated to them before it is implemented to

show the benefits relevant to them alongside the cost, i.e., their time to provide

information.

One dilemma for line managers in participating in MIS projects is the conflict

between their original discipline, such as manufacturing or marketing, and

the new IT. Time spent on managing information is time taken from pursuing

their conventional functional discipline, and they may therefore suffer reduced

prospects of advancement in their functional area. Therefore they need to be

reassured that their time spent on MIS development is also an important

part of their line job that will enable them to take a fresh look at their operation

and also improve their effectiveness in their line functions.

The operational level employees are essential for the operation of any MIS

operation. Usually they are responsible for feeding the bulk of the input in the

system. They may also be involved in report generation. At times, MIS may

involve computerising some laborious manual jobs, and thereby releasing

some manpower for alternative duties. People may need to learn some new

skills on using the computerised systems as well as for taking up additional

responsibilities. Computerisation often releases people from routine and simple

tasks, giving them an opportunity to devote more of their time to tasks that

are more demanding in terms of using their mental skills and judgment. In

the long term this leads to better job-profile and prospects for the employee

concerned. But in the short-term they may resist this change. There is a

need to use the appropriate human relations approach to help them accept

the changed situation and the added responsibilities. One important thing is

to consult and keep these employees involved and informed from the beginning

and through the entire project process. Springing surprises, even apparently

happy ones, have a tendency to backfire.

Other groups of people like suppliers, customers and statutory agencies, can

also be affected by the operational changes necessary to implement the MIS.

At times, managers in India underestimate the willingness and abilities of

suppliers, customers, and government agencies in India to adopt new

technology. Starting with a negative attitude like this does not help anyone. A

sincere attempt should be made to have a meaningful dialogue with all

stakeholders early in the project. The attempt should be on understanding

their situation as well as explaining your own.

96/MITSDE


Use of project teams is an effective way of obtaining commitment and developing

understanding. The members of the project team may work on the project

full time or part-time depending on the project need and their other

responsibilities.

Successful IT companies are abandoning the old organisation structures where

a client tracking down some information is shunted from department to

department. Instead, individuals have access to pooled knowledge that can

be harnessed to solve problems. Information technology allows individuals

to link to each other and to information repositories. This is likely to

involve change in the way the organisation operates. The contribution of teams

is seen par ticularly in internal projects, such as the development of

information systems.

A user committee enables the views of all the intended groups of users to be

represented. During the establishment of an MIS, the user committee meets

a number of times to monitor and advise on the system and the establishment

process, ensuring that users’ needs are well addressed.

When the system is operational, the committee needs to meet less frequently.

Its role then shifts to monitoring how the system serves its users and agreeing

on behalf of all on any changes to the system. Any suggestions are passed to

the system administrators for implementation. External users may best be

served by occasionally sending them a questionnaire followed up by

consultation by one or two interviewers in their own office.

6.9.3 Managing User Expectations

MIS development projects have a high failure rate because the users of a

system are dissatisfied with it as it does not meet their expectations.

What is the cause and effect relationship between expectations and failure?

No doubt, a poorly designed system will fail to meet expectations. But

sometimes users have unrealistic expectations without regard for constraints

of budget, time, manpower, etc., and the best system that developers could

produce will go unused because it doesn’t meet these high expectations. In

this latter case, the expectations were actually the cause of the failure, not

the other way round. Perception can be more important than reality.

Managers of MIS development projects have two things to manage: the

development of the system and the perception of the system. In earlier sections

we have discussed the methodologies for project development without any

reference to managing user expectations. However it is an integral part of the

MID development project. In this section we will cover this very important

aspect of project development activities.

First we will consider the importance of managing user expectations. Then

we will explore several strategies for managing user expectations. In looking

at these strategies, we will discuss which strategies are appropriate in which

situations. In conclusion, we will contemplate whether there are any “right”

or “better” strategies.

97/MITSDE

Importance of Managing User Expectations

The importance of the users’ involvement has been recognised at least for a

long time. Yet in many traditional discussions of MIS development, it has not

received adequate attention. The available evidence based on experience of

many MIS development projects shows that the apparent cause of many system

failures is user dissatisfaction with system scope, goals, or the system’s general

orientation to the business problem. MIS and MIS implementation failure

may well result from the improper management of user expectations.

In the following sections we will take a look at some techniques for managing

user expectations. We will consider traditional as well as current thinking on

the topic.

Documentation: The traditional approach to managing user expectations

has been a rather legalistic one. “Write down the customer’s requirements

and get the customer to agree with what you wrote.” The idea has been “let’s

make sure we document what we’re doing with the system. Then we will

have the customer sign off on the document. That way we’re covered.”

The documentation ef fort, at least in the beginning, was probably well-

intentioned. Conventional wisdom says that if the requirements of the system

are properly defined in the requirements stage of development, the resulting

system will be right. The inherent assumption is that if the system is designed

right, users will appreciate it.

Managers of system development realised that discrepancies arose between

the computer department’s view of the system and the user’s view. They felt

users didn’t know what they wanted, didn’t know what they needed, and didn’t

know what to expect when their systems were delivered. So project managers

focused on making documentation complete and detailed. The thinking is

“the users do not understand the systems we are creating”.

Even in the most methodically managed projects, stable requirements simply

do not exist. Early efforts to manage the customer focused not on managing

expectations but instead on controlling change. Project managers noticed that

users changed their requirements frequently. To fix the problem, they thought,

we must put restrictions on how changes take place to the system and

formalise the process.

These documentation-oriented methods are also very much practiced today.

They are very suitable in a contracting or consulting type situation in which

the customer is a separate legal entity from the company who is creating the

system for them. In this case, a legal contract is needed, and it is appropriate

to detail the deliverables in documents, legally binding or not. But the legalistic

approach seems less appropriate when the systems department and the users

work for the same organisation. Users may develop negative judgments about

the systems department precisely because they think the systems department

is treating them as adversaries.

A more elementary problem with this type of documentation is that often

users don’t understand it. If the documentation is not helping the users, it

serves only the confrontational purpose of shielding the systems department

from official accusations of incompetence; if no sign-off is obtained, even that

purpose is not served. Documentation remains an important part of the

systems development process, but it does not always serve the purpose of

managing user expectations.

98/MITSDE


Educate Users: The MIS project team must realise that it exists solely to

serve the information needs of users. If some changes are required by the

users they have to accept that and deliver what they need on time. This

approach is more cooperative than insisting that users must specify all their

requirements correctly and completely in advance. But it still doesn’t

emphasise the need for users to know how the IT technology or the systems

people work. Rather than making the processes of the systems department

some sort of mystery, it is better to educate the customer about processes

and the constraints in which systems people work.

The most important area about which to educate customers is the impact of

change. If the users and other stakeholders don’t understand the importance

of a requirements change, requirements discovery can lead to requirements

creep. The project manager must understand the MIS team’s development

lifecycle model and be able to explain it to the customers and stakeholders in

conceptual (rather than technical) terms. Let users know that there is always

a trade-off between cost, speed and reliability, convey the concept of “good-

enough” software. Educate users on how changes affect the cost of the project

and show them the benefit of deferring changes to future releases of the

application. Explain to the users that there will be problems.

It is very important to ensure that the developers are educated. Know the

users and their business well. Users will have more respect for developers

who know their business and will accept bad news from them more readily.

The education of both parties helps in making sure you speak the same

language.

When is the strategy of educating users not appropriate? Well, sometimes

users are going to want the short version of the story, the short answer to

their questions. If you start rambling about the parameters in which you are

working, users may think you are waffling. Also, you are limited in how

much time you can devote to this education process, both of the users’ time

and your time. The golden rule is: use the strategy of education unless you

have a specific reason not to use it.

Communicate Well with Users

Merely viewing the users as those to be educated is still a slightly

condescending approach. The idea behind expectations management is to

orchestrate the relationship. Good communication is central to the

relationship. How can MIS developers develop a good communication

relationship with users?

Honesty and forthrightness tend to work better than secrecy, but when

appropriate, it is all right to be diplomatic. Don’t assume that every request

must be fulfilled, but if possible, don’t just say no to requests that are out-of-

bounds. Instead, suggest a viable alternative. Explain the cost implications

of what they are asking while remaining sympathetic. It’s okay to help users

see your point of view and communicate what is feasible. Being asked to

provide a business justification for technology requests will help to separate

users’ wants from true needs.

In the traditional view of systems development, the requirements could be

gathered early in the process; then the developers would go away and develop

the system and the user might not see them again until the presentation of a

99/MITSDE

finished product. This linear view of systems development has been going out

of favour over the years in support of a more incremental approach. Determining

requirements is often a process of discovery. The contact with the users and

their involvement should be ongoing. Information systems development is

substantially different from many other product development efforts, provides

more opportunities to develop and manage user expectations. User perception

of participation in the development process is the most significant influence

on user satisfaction. Even after the system has been implemented, MIS people

should monitor users to see if they are happy and if requirements are changing,

and act on the feedback. Furthermore, the communication should be two-way.

Regular reporting on project status is essential: report successes, but also

report problems before they become crises.

The tactic of reporting deserves special attention. Keeping users abreast of

developments means they will rest easier, they will not be surprised by

outcomes, and they will be more convinced that the project is being well

managed; as a result, users’ attitudes toward the project will be better. Reports

should list accomplishments, issues, and metrics. Accomplishments can be

mundane but essential such as getting the team e-mail access. Issues are

potential obstacles to the project; this is where it is necessary to warn users

that something bad might happen. The metrics section is perhaps the most

crucial section of the report. It is important to have objective measures for

evaluating the progress of the project. Making goals objectively measurable

goes along with the idea of documenting to manage expectations. If users

know what concrete outcomes to expect, their expectations will be more

realistic. When they see concrete results, they will be more satisfied.

Measurements should address business issues, not merely technical ones.

Like educating users, communicating with users should be done whenever

possible. The only caution is again not to take up excessive amounts of users’

time. Reports should generally be written or electronic documents that are

brief may simply feature bullet-point lists. Such a document gives them freedom

to decide how much time to devote to reading the documents. Meeting weekly

for an hour to tell users how things are going might be excessive. Likewise,

when gathering information, use the most efficient means possible.

Prototyping: We have looked at various strategies for managing user

expectations: Clarify user requirements through detailed documentation. Have

users sign off on the requirements definition as well as any changes. Educate

users on the way systems development works. Communicate with users and

involve them in the process throughout the project life cycle. Report to users

on how the project is coming along. All these strategies may prepare users

to expect what is realistic and be more satisfied with it. If we take these ideas

a step further, wouldn’t it be nice if users could have a preview of what the

system will be like and have the opportunity to comment on it? That is precisely

the idea behind prototyping.

Prototyping means building a working model of the system. A prototype

doesn’t do everything the final system will do. Rather, it simulates some of

the essential features. For example, the user might be able to see how the

interface will look with regards to screen layout, menus, buttons, etc. Maybe

all of the buttons don’t work. Probably, the system is not connected to the

production database, so maybe only some phony data can be retrieved. But

the essence of the system is represented.

100/MITSDE


The prototype can be a great tool for zeroing in on users’ needs. Prototyping

has many benefits. It accommodates the communication style of the user instead

of the developer. The prototype gives the user and the developer some concrete

base to facilitate discussion, greatly alleviating communication problems and

misunderstanding. A prototype is much easier for a user to evaluate than a

requirements definition because it is closer to their everyday experience.

Instead of users being disappointed at the end of a project when the system

doesn’t do what it should, they are excited at being involved with developing

something new. With regard to cost, on the face of it this sounds inefficient

and expensive, but there are few things more expensive than a system which

the users will not use. Research has shown that prototyping leads to better

designs, better matches with user needs, and improved maintainability.

The benefits of prototyping are clear, and we may be tempted to think of the

prototype as a silver bullet. Although Bernard Boar is a strong proponent of

prototyping, he offers guidelines for when to use the technique and when not

to use it. A good candidate system for prototyping is not batch processing in

nature but rather full-screen periodic database reporting and interfacing;

prototyping helps most with developing a good user/machine interface.

Operational support and record management systems are good candidates

while heavily algorithmic systems and those for decision support and ad-hoc

retrieval and analysis are not; in other words, good candidates “are the

business” not “about the business.” Because of the time and resources

necessary, prototyping is not recommended for “crash” projects.

The characteristics of the users are important when deciding whether to use

prototyping. Although satisfying, prototyping requires users to devote

substantial resources to refining the model. Users should be sold on the

prototyping concept, having been dissatisfied with the pre-specification

experience. The users must be willing and able to make decisions. When a

model is ready to be reviewed, the process comes to a loud and visible halt if

nobody will review it.

6.9.4 Critical Issues for MIS Development and Operation

Although many organisations receive significant benefits from their MIS, these

still are high-risk / high-return systems, as shown by the large number of

unsuccessful MIS projects. Not only are MIS prone to fail, they can fail at any

point in the system’s lifetime. This should prompt companies to take the

issue of critical success factors seriously in developing their MIS. The following

is a suggested list-

• The MIS should be developed in response to and / or support a specific

business need. There needs to be a perceived need for such a system

within the organisation

• An executive sponsor who champions the project is crucial. There needs

to be a patron or sponsor in top management. Convinced of the need for

the system, the sponsor is able and willing to demand that the required

inputs for the system are made available and that outputs from the

system are delivered on time. He or she does not necessarily need to be

a direct user but will use, and demand, its outputs. A sponsor needs to

have a good overview of the system, what it entails in staff time, and

what it can do for the organisation and its employees.

101/MITSDE

• Managers and other employees affected by the proposed MIS need to

be integrated into the development and implementation and use of the

system.

• MIS support staff must have the necessary technical, business, and

interpersonal skills.

• MIS should achieve the desired objectives in as simple a way as possible.

Temptation to include more and more data items, or whole new modules,

into the system should generally be avoided. Systems are more likely to

fail due to too great a complexity than to simplicity. One useful rule is

not to admit new entities unless both, use and a user are identified.

• Effective data management is essential for the data to be relevant,

accurate, and attractively presented.

• A prototype must be released soon to capture executive interest while

it is still high.

• The system must be easy to use and navigate, requiring virtually no

training of users.

• Response time must be extremely fast.

• The MIS implementation should itself have goals, defined qualitatively,

quantitatively, and by time.

• Training in effective use of MIS must be provided for all managers

including top management. They all need to have a good knowledge of

the system’s contents and functions in order to exploit the system well

in management processes of planning, budgeting, monitoring, report

writing, and evaluation.

• The MIS should soon produce useful outputs that can be used by all

managers. This is the whole purpose of the system. If neglected, the

support of these constituencies will wane as most MIS information

declines in value with time.

• Once established, the system needs to be institutionalised, i.e., integrated

into the management processes of planning, decision-making, and

monitoring. This is crucial because it fulfills the primary reason for

having an MIS.

Summing Up

This chapter described the processes for designing, developing and

implementing MIS. It identified the difficulties of developing effective MIS,

then it discussed the techniques of determining management information

needs. This included approaches such as business systems planning, critical

success factor (CSF) method, and end/means (E/M) analysis. The chapter

also describes the systems life cycle development (SDLC) methodology as an

ordered approach for developing MIS. It also discussed the systems analysis

and design approach used for design and development of information systems.

Further, it explained the methods of effective management of MIS projects. It

discussed ways of managing user expectations in MIS development projects.

Self-assessment

1. What is the difference between systems analysis and systems design?

102/MITSDE


2. Name and describe various stages of systems development life cycle.

3. What is feasibility? Describe the purpose and areas of study to be

covered in an MIS feasibility study.

4. What is meant by the design stage?

5. Why has prototyping become a popular way to develop e-business

applications? What are the advantages and disadvantages of prototyping?

6. Describe in brief different methods of requirement determination.

7. Discuss the considerations for choosing the right method of requirement

determination.

8. Discuss the importance of people side of MIS development project.

9. How are critical success factors (CSF) used to determine management

information needs?

References

1. James A. Senn. Analysis and Design of Information Systems. Singapore,

McGraw-Hill Publishing Company, Second Edition, 1989.

2. Laudon and Laudon. Management Information System, 7th Edition;

Pearson Education Asia.

3. Robert Schultheis and Mary Sumner. Management Information System.

New Delhi, Tata McGraw-Hill Publishing Company Limited, Second

Edition, 2003.

4. Turban, Leidner, McLean, Wetherbe. Information Technology For

Management. John Wiley & Sons 5th Edition